From clonvick@cisco.com Mon Jun 1 13:02:44 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B713A6A20 for ; Mon, 1 Jun 2009 13:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 isyOcRPdeN-v for ; Mon, 1 Jun 2009 13:02:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DC74A3A6FC9 for ; Mon, 1 Jun 2009 13:02:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,286,1241395200"; d="scan'208";a="171172983" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2009 20:02:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n51K2d3Y016493 for ; Mon, 1 Jun 2009 13:02:39 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n51K2dAg021078 for ; Mon, 1 Jun 2009 20:02:39 GMT Date: Mon, 1 Jun 2009 13:02:38 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5496; t=1243886559; x=1244750559; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20syslog=20WG=20Rechartering=20Discussion |Sender:=20; bh=dSum3/tbgzbWOhMQ88RPR0kzFeQXQSPJSgMteaKBAh0=; b=s3QH9MRXBCo9C7CTOUgdRURSLqHehCQTKOChDd61lrVfIYbU4/w4RtVonA h893sQqXJyPUjmgpskjOZR0xSrxbrm+yuIh2Tf3xCDTed1pkM17d3Is+DfLZ y8/epUaNzQ; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Syslog] syslog WG Rechartering Discussion X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 20:02:44 -0000 Hi Folks, David and I are going to open the discussion about rechartering. Below are some ideas that we've seen on the list that may fit into a charter for a new syslog Working Group. These seem to fit better in the Operations and Management Area than in the Security Area so we are asking the ADs to move the WG to there when we do recharter. We'd like to get the discussion started now on this mailing list and have a WG meeting in Stockholm to discuss rechartering issues. We hope that by having a real meeting, we can draw in more OPS people who are willing to work on these items, and/or to craft additional goals for syslog. Please send your comments in about this and help move syslog forward. Fundamentals - Documenting how a syslog relay is supposed to work. RFC3164 says that a relay MAY change the header information in a syslog message. This needs to be reexamined since syslog-sign mandates that no changes are allowed in the whole syslog message between the sender and the device that validates the detached signatures. - A DHC option for a syslog receiver. Write an ID that standardizes how DHCP should specify a syslog server and associated transport (udp, tls, beep) in a URI format. - The OpSec WG was planning to develop a draft about log event taxonomy (what to log). This work should be compared to the syslog-alarm draft from Sharon and Rainer, which defines categories for the alarm that are fairly consistent with the ALARM-MIB and ITU alarm categories. There is also CEE work that is also trying to define catagories of what to log. Architecture - An informational document that describes how each of the header fields should be used. The technical information is in RFC 5424 but could use some further explanation. - Possibly combined with the previous topic, a "practical usage guide" would be a good document for implementors and coders. - A relook at the PRI values. There are currently 7 Severity levels and 21 Facilities. The Facilities are ill-defined and out of date. The information there could be better described in SDEs. We kept the historical PRI values so that we would have a smooth(er) transition from historical syslog to the IETF standard syslog. That has worked as current syslog receivers do receive syslog messages in the new format. Transport - Documenting a TCP transport for syslog. There are many implementations in the wild right now with two major variants. The problem between them is the delimiter; prevalently a CR (I believe) is used to separate multiple messages within a single TCP packet. The minor-use implementation does not have a delimiter and just assumes one message per packet. This will be relatively easy to straighten out. - Finish syslog-transport-dtls. There are two individual submissions which may be combined and moved into the WG. - We should do something with syslog/BEEP. Should we declare the current syslog/BEEP historic? and/or should we start an effort to publish an update? Ancillary - There are other documents in the OPSAWG which might be better reviewed in the new syslog WG, if they have not already completed reviews elsewhere: - Alarms in SYSLOG - Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications - It would be good to encourage other groups to bring drafts of Structured Data implementations to Syslog WG for review. These would likely not be Syslog WG documents but the documents would benefit from being reviewed by the Syslog WG. - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create SDEs to report that a series of messages have been dropped by a sender. This document defines special syslog messages called Discard messages for carrying logs loss statistics which indicate how many logs (in terms of facility level or/and severity level) were discarded by the syslog sender before they had a chance to hit the wire connected to the syslog receiver during a particular period in an extreme case. The statistics information Disard messages convey is of interest to syslog receivers and helpful for later on audit. - draft-dulaunoy-syslog-geolocation-00 proposes adding geographic meta information to syslog messages. This might be done using SDEs - In an earlier version of netconf, there was work to correlate between the information models of alarms from different NM interfaces. Part of the purpose was to ease correlation of event reports for the same event via different NM interfaces. - Benoit Claise proposed making ipfix a general purpose reporting protocol. Such a protocol might replace or supplement syslog. There may be benefit to utilizing ipfix for carrying syslog information, so there might be benefit to defining a way to convert syslog content into ipfix formats, or to modify ipfix PDUs to carry syslog formats (both the human-readable message part and the SDEs). This was a brand new proposal at IETF 74, so has not had much discussion yet. We can discuss this to see if there would be interest in such a direction. Thanks, Chris & David From j.schoenwaelder@jacobs-university.de Mon Jun 1 13:19:24 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43913A6C47 for ; Mon, 1 Jun 2009 13:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 5VyQdBs4RHOh for ; Mon, 1 Jun 2009 13:19:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8910E3A6991 for ; Mon, 1 Jun 2009 13:18:47 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79303C0052; Mon, 1 Jun 2009 22:18:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UeBGxd84mlSv; Mon, 1 Jun 2009 22:18:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42778C0043; Mon, 1 Jun 2009 22:18:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2BF80B2B0D2; Mon, 1 Jun 2009 22:18:45 +0200 (CEST) Date: Mon, 1 Jun 2009 22:18:45 +0200 From: Juergen Schoenwaelder To: Chris Lonvick Message-ID: <20090601201845.GA19838@elstar.local> Mail-Followup-To: Chris Lonvick , "syslog@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "syslog@ietf.org" Subject: Re: [Syslog] syslog WG Rechartering Discussion X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 20:19:25 -0000 On Mon, Jun 01, 2009 at 10:02:38PM +0200, Chris Lonvick wrote: > Ancillary > - There are other documents in the OPSAWG which might be better reviewed > in the new syslog WG, if they have not already completed reviews > elsewhere: > - Mapping Simple Network Management Protocol (SNMP) Notifications to > SYSLOG Messages > - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > Network Management Protocol (SNMP) Notifications The two SNMP mapping documents have (as far as I can tell) passed OPSAWG last call and likely move to the IESG and into IETF wide last call soon. So people should better take a look at these documents now since these documents likely move faster than this rechartering process. Here are the URLs: http://tools.ietf.org/wg/opsawg/draft-ietf-opsawg-syslog-msg-mib/ http://tools.ietf.org/wg/opsawg/draft-ietf-opsawg-syslog-snmp/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From hongyanfeng@huaweisymantec.com Thu Jun 4 03:27:59 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7563828C280 for ; Thu, 4 Jun 2009 03:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 k-Y0JmYd-rl9 for ; Thu, 4 Jun 2009 03:27:57 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 8515128C29F for ; Thu, 4 Jun 2009 03:27:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKP00HQGMEMNM00@hstga01-in.huaweisymantec.com> for syslog@ietf.org; Thu, 04 Jun 2009 18:27:58 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKP000RMMELDO00@hstml02-in.huaweisymantec.com> for syslog@ietf.org; Thu, 04 Jun 2009 18:27:58 +0800 (CST) Received: from [10.27.154.136] by hstml02-in.huaweisymantec.com (mshttpd); Thu, 04 Jun 2009 18:27:57 +0800 From: fenghongyan To: Chris Lonvick Message-id: Date: Thu, 04 Jun 2009 18:27:57 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Cc: syslog@ietf.org Subject: Re: [Syslog] syslog WG Rechartering Discussion X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 10:27:59 -0000 Hi Chris, I will submit an update of my proposal later. Before that, I would like anyone here to discuss what changes I need to make to merge Rainer and Tom's draft, that I can write in my new revision. I recalled that I wrote a mail before to review Rainer and Tom's draft, I asked some questions and can be concluded as below: 1. If it is necessary for "a syslog server should be a DTLS client"? 2. If we need ask different "registered port number" for DTLS different transport mapping (udp/sctp...) ? 3. If we need consistent syslog/dtls commands with syslog/tls ? 4. Anything else I need to cover from that covered in Rainer and Tom's ? I will update my proposal according to the consensus of discussions on these items. and at the time, I welcome any comments on my proposal, thanks. The original mail I list here for your information. -----Original Message----- Date: Sun, 12 Apr 2009 00:20:28 +0800 From: fenghongyan Subject: [Syslog] Review of draft-petch-gerhards-syslog-transport-dtls-01.txt" To: syslog@ietf.org Message-ID: Content-Type: text/plain; charset=us-ascii Hi, I read this proposal "draft-petch-gerhards-syslog-transport-dtls-01", I have some comments on it: Those changes I made in my new version this draft is also need to make, I think. section 1.3 The security discussion is similar as stated in syslog/tls, Pasi recommended simply pointer to syslog/tls would be better. section 1.4 This is covered in syslog/tls; a pointer to that document would work. section 2.1 I don't see if there's a necessary for a syslog server should be a DTLS client. In my understanding, a dtls request is alway initiate by a dtls client, if syslog server being dtls client, how does a server know which client want to connect to it? I think RFC5425 has state authentication in very detail and come up the corresponding security policy. Also, fingerprint is aim to cover the case you discussed in your draft having a certificate url authentication. A pointer to that document would work. section 2.2 I think a udp "registered port number" is required to assign for udp mapping and a sctp "registered port number" is required to assign for sctp mapping respectively. section 2.3 I claimed in my proposal to minimize the operation and security where both syslog/tls and syslog/dtls are supported, why do you need write the commands in your proposal? section 2.6, section 2.8 It is covered in syslog/tls security policy; a pointer to that document would work. Thanks Linda > > Message: 1 > Date: Mon, 1 Jun 2009 13:02:38 -0700 (PDT) > From: Chris Lonvick > Subject: [Syslog] syslog WG Rechartering Discussion > To: syslog@ietf.org > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > Hi Folks, > > David and I are going to open the discussion about rechartering. > Below > are some ideas that we've seen on the list that may fit into a > charter for > a new syslog Working Group. These seem to fit better in the > Operations > and Management Area than in the Security Area so we are asking the > ADs to > move the WG to there when we do recharter. > > We'd like to get the discussion started now on this mailing list and > have > a WG meeting in Stockholm to discuss rechartering issues. We hope > that by > having a real meeting, we can draw in more OPS people who are willing > to > work on these items, and/or to craft additional goals for syslog. > > Please send your comments in about this and help move syslog forward. > > > > Fundamentals > - Documenting how a syslog relay is supposed to work. RFC3164 says > that a > relay MAY change the header information in a syslog message. This > needs > to be reexamined since syslog-sign mandates that no changes are allowed > in the whole syslog message between the sender and the device that > validates the detached signatures. > - A DHC option for a syslog receiver. Write an ID that standardizes how > DHCP should specify a syslog server and associated transport (udp, > tls, > beep) in a URI format. > - The OpSec WG was planning to develop a draft about log event taxonomy > (what to log). This work should be compared to the syslog-alarm draft > from Sharon and Rainer, which defines categories for the alarm > that are > fairly consistent with the ALARM-MIB and ITU alarm categories. > There is > also CEE work that is also trying to define catagories of what to > log. > > > Architecture > - An informational document that describes how each of the header fields > should be used. The technical information is in RFC 5424 but > could use > some further explanation. > - Possibly combined with the previous topic, a "practical usage guide" > would be a good document for implementors and coders. > - A relook at the PRI values. There are currently 7 Severity levels > and > 21 Facilities. The Facilities are ill-defined and out of date. The > information there could be better described in SDEs. We kept the > historical PRI values so that we would have a smooth(er) > transition from > historical syslog to the IETF standard syslog. That has worked as > current syslog receivers do receive syslog messages in the new format. > > > Transport > - Documenting a TCP transport for syslog. There are many implementations > in the wild right now with two major variants. The problem > between them > is the delimiter; prevalently a CR (I believe) is used to separate > multiple messages within a single TCP packet. The minor-use > implementation does not have a delimiter and just assumes one message > per packet. This will be relatively easy to straighten out. > - Finish syslog-transport-dtls. There are two individual submissions > which may be combined and moved into the WG. > - We should do something with syslog/BEEP. Should we declare the current > syslog/BEEP historic? and/or should we start an effort to publish > an > update? > > > Ancillary > - There are other documents in the OPSAWG which might be better reviewed > in the new syslog WG, if they have not already completed reviews > elsewhere: > - Alarms in SYSLOG > - Mapping Simple Network Management Protocol (SNMP) Notifications > to > SYSLOG Messages > - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > Network Management Protocol (SNMP) Notifications > - It would be good to encourage other groups to bring drafts of Structured > Data implementations to Syslog WG for review. These would likely > not be > Syslog WG documents but the documents would benefit from being reviewed > by the Syslog WG. > - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create > SDEs to report that a series of messages have been dropped by > a > sender. This document defines special syslog messages called > Discard messages for carrying logs loss statistics which indicate > how many logs (in terms of facility level or/and severity level) > were discarded by the syslog sender before they had a chance > to hit > the wire connected to the syslog receiver during a particular > period > in an extreme case. The statistics information Disard messages > convey is of interest to syslog receivers and helpful for > later on > audit. > - draft-dulaunoy-syslog-geolocation-00 proposes adding > geographic meta > information to syslog messages. This might be done using SDEs > - In an earlier version of netconf, there was work to correlate between > the information models of alarms from different NM interfaces. > Part of > the purpose was to ease correlation of event reports for the same > event > via different NM interfaces. > - Benoit Claise proposed making ipfix a general purpose reporting > protocol. Such a protocol might replace or supplement syslog. There > may be benefit to utilizing ipfix for carrying syslog information, > so > there might be benefit to defining a way to convert syslog content > into > ipfix formats, or to modify ipfix PDUs to carry syslog formats > (both the > human-readable message part and the SDEs). This was a brand new > proposal at IETF 74, so has not had much discussion yet. We can discuss > this to see if there would be interest in such a direction. > > > Thanks, > Chris & David > From bazsi@balabit.hu Mon Jun 8 09:21:49 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C395C3A6A14 for ; Mon, 8 Jun 2009 09:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] 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 o12M66KJ8xVp for ; Mon, 8 Jun 2009 09:21:48 -0700 (PDT) Received: from lists.balabit.hu (support.balabit.hu [195.70.41.86]) by core3.amsl.com (Postfix) with ESMTP id 7FBBC3A68E5 for ; Mon, 8 Jun 2009 09:21:47 -0700 (PDT) Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 4DFC713A1FD for ; Mon, 8 Jun 2009 18:21:50 +0200 (CEST) From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: Content-Type: text/plain Date: Mon, 08 Jun 2009 14:10:17 +0000 Message-Id: <1244470217.5465.70.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: Re: [Syslog] syslog WG Rechartering Discussion X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 16:21:49 -0000 On Mon, 2009-06-01 at 13:02 -0700, Chris Lonvick wrote: > Hi Folks, > > David and I are going to open the discussion about rechartering. Below > are some ideas that we've seen on the list that may fit into a charter for > a new syslog Working Group. These seem to fit better in the Operations > and Management Area than in the Security Area so we are asking the ADs to > move the WG to there when we do recharter. > > We'd like to get the discussion started now on this mailing list and have > a WG meeting in Stockholm to discuss rechartering issues. We hope that by > having a real meeting, we can draw in more OPS people who are willing to > work on these items, and/or to craft additional goals for syslog. > > Please send your comments in about this and help move syslog forward. > > > > Fundamentals > - Documenting how a syslog relay is supposed to work. RFC3164 says that a > relay MAY change the header information in a syslog message. This needs > to be reexamined since syslog-sign mandates that no changes are allowed > in the whole syslog message between the sender and the device that > validates the detached signatures. there are other relay specific discrepancies, like how Structured Data is supposed to work in relaying scenarios. For example sequenceId is hop-by-hop or end-to-end. And what if the relay drops some messages because of filtering? > - A DHC option for a syslog receiver. Write an ID that standardizes how > DHCP should specify a syslog server and associated transport (udp, tls, > beep) in a URI format. > - The OpSec WG was planning to develop a draft about log event taxonomy > (what to log). This work should be compared to the syslog-alarm draft > from Sharon and Rainer, which defines categories for the alarm that are > fairly consistent with the ALARM-MIB and ITU alarm categories. There is > also CEE work that is also trying to define catagories of what to log. > > > Architecture > - An informational document that describes how each of the header fields > should be used. The technical information is in RFC 5424 but could use > some further explanation. > - Possibly combined with the previous topic, a "practical usage guide" > would be a good document for implementors and coders. > - A relook at the PRI values. There are currently 7 Severity levels and > 21 Facilities. The Facilities are ill-defined and out of date. The > information there could be better described in SDEs. We kept the > historical PRI values so that we would have a smooth(er) transition from > historical syslog to the IETF standard syslog. That has worked as > current syslog receivers do receive syslog messages in the new format. The key here is probably a process to define new facility codes by IANA If there's a process, it does not really matter if it uses numeric codes (e.g. the current PRI field), or textual (perhaps in an SDE). > > > Transport > - Documenting a TCP transport for syslog. There are many implementations > in the wild right now with two major variants. The problem between them > is the delimiter; prevalently a CR (I believe) is used to separate > multiple messages within a single TCP packet. The minor-use > implementation does not have a delimiter and just assumes one message > per packet. This will be relatively easy to straighten out. > - Finish syslog-transport-dtls. There are two individual submissions > which may be combined and moved into the WG. > - We should do something with syslog/BEEP. Should we declare the current > syslog/BEEP historic? and/or should we start an effort to publish an > update? Application layer acks is present in the BEEP transport, but the message formatting is ancient (basically the same as RFC3164, e.g. without year, timezone, etc). I guess a BEEP transport with an updated message format would be interesting. Also, on-the-line compression support is requested by a lot of people. > > > Ancillary > - There are other documents in the OPSAWG which might be better reviewed > in the new syslog WG, if they have not already completed reviews > elsewhere: > - Alarms in SYSLOG > - Mapping Simple Network Management Protocol (SNMP) Notifications to > SYSLOG Messages > - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > Network Management Protocol (SNMP) Notifications > - It would be good to encourage other groups to bring drafts of Structured > Data implementations to Syslog WG for review. These would likely not be > Syslog WG documents but the documents would benefit from being reviewed > by the Syslog WG. > - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create > SDEs to report that a series of messages have been dropped by a > sender. This document defines special syslog messages called > Discard messages for carrying logs loss statistics which indicate > how many logs (in terms of facility level or/and severity level) > were discarded by the syslog sender before they had a chance to hit > the wire connected to the syslog receiver during a particular period > in an extreme case. The statistics information Disard messages > convey is of interest to syslog receivers and helpful for later on > audit. > - draft-dulaunoy-syslog-geolocation-00 proposes adding geographic meta > information to syslog messages. This might be done using SDEs > - In an earlier version of netconf, there was work to correlate between > the information models of alarms from different NM interfaces. Part of > the purpose was to ease correlation of event reports for the same event > via different NM interfaces. > - Benoit Claise proposed making ipfix a general purpose reporting > protocol. Such a protocol might replace or supplement syslog. There > may be benefit to utilizing ipfix for carrying syslog information, so > there might be benefit to defining a way to convert syslog content into > ipfix formats, or to modify ipfix PDUs to carry syslog formats (both the > human-readable message part and the SDEs). This was a brand new > proposal at IETF 74, so has not had much discussion yet. We can discuss > this to see if there would be interest in such a direction. -- Bazsi From Pasi.Eronen@nokia.com Tue Jun 9 00:45:27 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5618F3A69ED for ; Tue, 9 Jun 2009 00:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TY-iGArn6UvD for ; Tue, 9 Jun 2009 00:45:26 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 25B023A68EC for ; Tue, 9 Jun 2009 00:45:25 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n597iwT7030405; Tue, 9 Jun 2009 10:45:22 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:45:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:45:04 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 9 Jun 2009 09:45:03 +0200 From: To: , Date: Tue, 9 Jun 2009 09:45:02 +0200 Thread-Topic: Syslog-sign -26 Thread-Index: Acm2p7iG06BHWwBZTUmHor6uUdYqsAoT5d+wAnch3UA= Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AFED455@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F22149EE@NOK-EUMSG-01.mgdnok.nokia.com> <85B2F271FDF6B949B3672BA5A7BB62FB07C98B0C@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB07C98B0C@xmb-sjc-236.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jun 2009 07:45:04.0285 (UTC) FILETIME=[33957CD0:01C9E8D6] X-Nokia-AV: Clean Subject: Re: [Syslog] Syslog-sign -26 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 07:45:27 -0000 Alexander Clemm wrote: > The most important issue concerned the issue of having multiple > signers. After some contemplating, I decided that this can be > resolved quite simply by clarifying that the combination of APP-NAME > and PROCID refers to a unique signer (no, I didn't introduce it as a > new term, it's still originator), and needs to be consistent between > Certificate Block and Signature Block messages. If multiple > originators are used, they each in effect have their own "scope" - > they each have their own Payload Block and Signature Blocks etc. > > The algorithm in section 7 can stay the same, but I added some > clarification also there about how to identify/distinguish between > different originators, and the fact that consistency between > Certificate Block and Signature Block messages with regards to the > originator needs to be checked. Hmmm... the major challenge in -25 was that although Payload/Signature Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal syslog messages do not. So it seems you cannot separate the stored=20 log files by originator, and process the parts one by one. If I understand you right, you're saying Section 7 does *not* in fact assume that you can separate the normal syslog messages by originator? BTW, version -26 is still silent about whether a single originator can sign the same set of messages using different algorithms (VER), and if it can, whether these are same Signature Groups (with same message number space) or different. What's your proposal for=20 addressing this -- or do you think signing using multiple algorithm doesn't have to be supported? Best regards, Pasi From cfinss@dial.pipex.com Wed Jun 10 12:33:26 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877E93A697E for ; Wed, 10 Jun 2009 12:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599] 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 weYqOFISbMm0 for ; Wed, 10 Jun 2009 12:33:25 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 8DCC13A67B2 for ; Wed, 10 Jun 2009 12:33:24 -0700 (PDT) X-Trace: 221807447/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.2/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.2 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEAIenL0o+vGQC/2dsb2JhbACDKVKLQ65oknIIhAUF X-IronPort-AV: E=Sophos;i="4.42,197,1243810800"; d="scan'208";a="221807447" X-IP-Direction: IN Received: from 1cust2.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.2]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Jun 2009 20:33:20 +0100 Message-ID: <004901c9e9f9$c6ab1880$0601a8c0@allison> From: "tom.petch" To: "fenghongyan" , "Chris Lonvick" References: Date: Wed, 10 Jun 2009 19:54:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: syslog Subject: Re: [Syslog] syslog WG Rechartering Discussion X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 19:33:26 -0000 --- Original Message ----- From: "fenghongyan" To: "Chris Lonvick" Cc: Sent: Thursday, June 04, 2009 12:27 PM > Hi Chris, > > I will submit an update of my proposal later. > > Before that, I would like anyone here to discuss what changes I need to make to merge Rainer and Tom's draft, > that I can write in my new revision. > > I recalled that I wrote a mail before to review Rainer and Tom's draft, > I asked some questions and can be concluded as below: > > 1. If it is necessary for "a syslog server should be a DTLS client"? > 2. If we need ask different "registered port number" for DTLS different transport mapping (udp/sctp...) ? > 3. If we need consistent syslog/dtls commands with syslog/tls ? > 4. Anything else I need to cover from that covered in Rainer and Tom's ? > > I will update my proposal according to the consensus of discussions on these items. > and at the time, I welcome any comments on my proposal, thanks. Linda I think that the problem is that there is not a quorum with which to form a rough consensus at this time ( much as I wish that there were). I would like a Working Group to agree to take on this work, and then to raise these questions. You and me and Rainer and David and Chris ... is not enough, IMO, for the IETF to make decisions on eg, the idea of having TLS client/server role negotiable by a protocol. This is an old idea, which I happen to think a good one for syslog, but it needs input from others to say yes, go with it, or no, not good because .... So the current step for me is to draft a proposed revision to the charter, within which syslog over DTLS is a bullet item (as Chris and David have done), and see if that revised charter finds favour and then proceed from there. Tom Petch > > The original mail I list here for your information. > > -----Original Message----- > Date: Sun, 12 Apr 2009 00:20:28 +0800 > From: fenghongyan > Subject: [Syslog] Review of > draft-petch-gerhards-syslog-transport-dtls-01.txt" > To: syslog@ietf.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Hi, > > I read this proposal "draft-petch-gerhards-syslog-transport-dtls-01", > I have some comments on it: > > Those changes I made in my new version this draft is also need to make, I think. > > > section 1.3 > The security discussion is similar as stated in syslog/tls, Pasi > recommended simply pointer to syslog/tls would be better. > > section 1.4 > This is covered in syslog/tls; a pointer to that document would work. > > section 2.1 > I don't see if there's a necessary for a syslog server should be a DTLS client. > In my understanding, a dtls request is alway initiate by a dtls client, if syslog server being dtls client, > how does a server know which client want to connect to it? > I think RFC5425 has state authentication in very detail and come up the corresponding security policy. > Also, fingerprint is aim to cover the case you discussed in your draft having a certificate url authentication. > A pointer to that document would work. > > section 2.2 > I think a udp "registered port number" is required to assign for udp mapping and > a sctp "registered port number" is required to assign for sctp mapping respectively. > > section 2.3 > I claimed in my proposal to minimize the operation and security where > both syslog/tls and syslog/dtls are supported, why do you need write > the commands in your proposal? > > section 2.6, section 2.8 > It is covered in syslog/tls security policy; a pointer to that document would work. > > > > > > > > Thanks > Linda > > > > > > Message: 1 > > Date: Mon, 1 Jun 2009 13:02:38 -0700 (PDT) > > From: Chris Lonvick > > Subject: [Syslog] syslog WG Rechartering Discussion > > To: syslog@ietf.org > > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > > Hi Folks, > > > > David and I are going to open the discussion about rechartering. > > Below > > are some ideas that we've seen on the list that may fit into a > > charter for > > a new syslog Working Group. These seem to fit better in the > > Operations > > and Management Area than in the Security Area so we are asking the > > ADs to > > move the WG to there when we do recharter. > > > > We'd like to get the discussion started now on this mailing list and > > have > > a WG meeting in Stockholm to discuss rechartering issues. We hope > > that by > > having a real meeting, we can draw in more OPS people who are willing > > to > > work on these items, and/or to craft additional goals for syslog. > > > > Please send your comments in about this and help move syslog forward. > > > > > > > > Fundamentals > > - Documenting how a syslog relay is supposed to work. RFC3164 says > > that a > > relay MAY change the header information in a syslog message. This > > needs > > to be reexamined since syslog-sign mandates that no changes are allowed > > in the whole syslog message between the sender and the device that > > validates the detached signatures. > > - A DHC option for a syslog receiver. Write an ID that standardizes how > > DHCP should specify a syslog server and associated transport (udp, > > tls, > > beep) in a URI format. > > - The OpSec WG was planning to develop a draft about log event taxonomy > > (what to log). This work should be compared to the syslog-alarm draft > > from Sharon and Rainer, which defines categories for the alarm > > that are > > fairly consistent with the ALARM-MIB and ITU alarm categories. > > There is > > also CEE work that is also trying to define catagories of what to > > log. > > > > > > Architecture > > - An informational document that describes how each of the header fields > > should be used. The technical information is in RFC 5424 but > > could use > > some further explanation. > > - Possibly combined with the previous topic, a "practical usage guide" > > would be a good document for implementors and coders. > > - A relook at the PRI values. There are currently 7 Severity levels > > and > > 21 Facilities. The Facilities are ill-defined and out of date. The > > information there could be better described in SDEs. We kept the > > historical PRI values so that we would have a smooth(er) > > transition from > > historical syslog to the IETF standard syslog. That has worked as > > current syslog receivers do receive syslog messages in the new format. > > > > > > Transport > > - Documenting a TCP transport for syslog. There are many implementations > > in the wild right now with two major variants. The problem > > between them > > is the delimiter; prevalently a CR (I believe) is used to separate > > multiple messages within a single TCP packet. The minor-use > > implementation does not have a delimiter and just assumes one message > > per packet. This will be relatively easy to straighten out. > > - Finish syslog-transport-dtls. There are two individual submissions > > which may be combined and moved into the WG. > > - We should do something with syslog/BEEP. Should we declare the current > > syslog/BEEP historic? and/or should we start an effort to publish > > an > > update? > > > > > > Ancillary > > - There are other documents in the OPSAWG which might be better reviewed > > in the new syslog WG, if they have not already completed reviews > > elsewhere: > > - Alarms in SYSLOG > > - Mapping Simple Network Management Protocol (SNMP) Notifications > > to > > SYSLOG Messages > > - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > > Network Management Protocol (SNMP) Notifications > > - It would be good to encourage other groups to bring drafts of Structured > > Data implementations to Syslog WG for review. These would likely > > not be > > Syslog WG documents but the documents would benefit from being reviewed > > by the Syslog WG. > > - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create > > SDEs to report that a series of messages have been dropped by > > a > > sender. This document defines special syslog messages called > > Discard messages for carrying logs loss statistics which indicate > > how many logs (in terms of facility level or/and severity level) > > were discarded by the syslog sender before they had a chance > > to hit > > the wire connected to the syslog receiver during a particular > > period > > in an extreme case. The statistics information Disard messages > > convey is of interest to syslog receivers and helpful for > > later on > > audit. > > - draft-dulaunoy-syslog-geolocation-00 proposes adding > > geographic meta > > information to syslog messages. This might be done using SDEs > > - In an earlier version of netconf, there was work to correlate between > > the information models of alarms from different NM interfaces. > > Part of > > the purpose was to ease correlation of event reports for the same > > event > > via different NM interfaces. > > - Benoit Claise proposed making ipfix a general purpose reporting > > protocol. Such a protocol might replace or supplement syslog. There > > may be benefit to utilizing ipfix for carrying syslog information, > > so > > there might be benefit to defining a way to convert syslog content > > into > > ipfix formats, or to modify ipfix PDUs to carry syslog formats > > (both the > > human-readable message part and the SDEs). This was a brand new > > proposal at IETF 74, so has not had much discussion yet. We can discuss > > this to see if there would be interest in such a direction. > > > > Thanks, > > Chris & David From alex@cisco.com Thu Jun 11 23:29:32 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7AE28C133 for ; Thu, 11 Jun 2009 23:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cwdF2Je1tY2w for ; Thu, 11 Jun 2009 23:29:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4FFF028C12C for ; Thu, 11 Jun 2009 23:29:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,207,1243814400"; d="scan'208,217";a="198873577" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2009 06:29:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5C6TWWs005024; Thu, 11 Jun 2009 23:29:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5C6TW8O010736; Fri, 12 Jun 2009 06:29:32 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 23:29:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EB27.241CC9EF" Date: Thu, 11 Jun 2009 23:28:19 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB07E6021E@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Syslog-sign-26 Thread-Index: AcnrJvowC/Va+9apR+yYkjg/opAkBw== From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 12 Jun 2009 06:29:32.0073 (UTC) FILETIME=[256A1190:01C9EB27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10252; t=1244788172; x=1245652172; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20Re=3A=20Syslog-sign-26 |Sender:=20; bh=wvZmlOE9SXhtfT5MgonfwiNnpNnJbXXgTA+UVxe5SD4=; b=RfTgS4bQTpGbTfND7PoBxE4mIIAB50UCqBuO3AnUoAjeRWzTuZmUZx09YE 8ndVhBAjaFKmp+WVdNxsZTtQAuLANEsOTmLeh0Hzk4D7n4T3H4+9KXPLtagA L20zIhhivq; Authentication-Results: sj-dkim-3; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign-26 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 06:29:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EB27.241CC9EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Pasi, =20 I guess any confusion stems from the use of the word "originator". Therefore, let me use the term "signer" for the purposes of this discussion. A signer signs syslog-messages using a specific algorithm; it is an "originator" of syslog-sign messages. A single host can host multiple signers, which then each use their own Signature Groups and algorithms. The syslog-sign messages can be attributed to a specific signer using (HOSTNAME, APP-NAME, PROCID). Section 7 does say that you can separate syslog-sign messages according to signer, using this triple. (It is the syslog-sign messages you are concerned about; you separate the syslog-sign messages by signers. You can separate the "normal" messages by virtue of who signed them.) So, in summary, the ability to be able to use different algorithms to sign messages is supported, but the corresponding syslog-sign messages need to use different (HOSTNAME,APP-NAME,PROCID) to be able to distinguish which is used where. =20 =20 Now, the question is whether to equate "signer" with "originator". If you equate them, then each signer would be considered its own originator of its own syslog messages. However, you can also simply regard it from the perspective that the same originator can in effect incorporate multiple signers, if wanting to use multiple algorithms concurrently. It doesn't really matter - just like with "normal" syslog messages without syslog sign you don't really distinguish if there are multiple originators on the same host or only one - the syslog message does not contain an "originator-ID" but (HOSTNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you support the ability to sign messages using different algorithms from the same host. =20 =20 Does this clarify? --- Alex =20 =20 Pasi Eronen wrote: "Hmmm... the major challenge in -25 was that although Payload/Signature Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal syslog messages do not. So it seems you cannot separate the stored=20 log files by originator, and process the parts one by one. =20 If I understand you right, you're saying Section 7 does *not* in fact assume that you can separate the normal syslog messages by originator? =20 BTW, version -26 is still silent about whether a single originator can sign the same set of messages using different algorithms (VER), and if it can, whether these are same Signature Groups (with same message number space) or different. What's your proposal for=20 addressing this -- or do you think signing using multiple algorithm doesn't have to be supported?" =20 ------_=_NextPart_001_01C9EB27.241CC9EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Pasi,

 

I guess any confusion stems from the use of the = word “originator”.  Therefore, let me use the term “signer” for the purposes of = this discussion.  A signer signs syslog-messages using a specific = algorithm; it is an “originator” of syslog-sign messages.  A single = host can host multiple signers, which then each use their own Signature Groups = and algorithms.  The syslog-sign messages can be attributed to a specific signer using (HOSTNAME, APP-NAME, PROCID).  Section 7 does say that you can = separate syslog-sign messages according to signer, using this triple.  (It = is the syslog-sign messages you are concerned about; you separate the = syslog-sign messages by signers.  You can separate the “normal” = messages by virtue of who signed them.)  So, in summary, the ability to be able = to use different algorithms to sign messages is supported, but the = corresponding syslog-sign messages need to use different (HOSTNAME,APP-NAME,PROCID) to = be able to distinguish which is used where. 

 

Now, the question is whether to equate = “signer” with “originator”.  If you equate them, then each = signer would be considered its own originator of its own syslog messages.  = However, you can also simply regard it from the perspective that the same originator = can in effect incorporate multiple signers, if wanting to use multiple = algorithms concurrently.   It doesn’t really matter – just = like with “normal” syslog messages without syslog sign you don’t = really distinguish if there are multiple originators on the same host or only = one – the syslog message does not contain an “originator-ID” but = (HOSTNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you support the ability to sign = messages using different algorithms from the same host.  =  

 

Does this clarify?

--- Alex

 

 

Pasi Eronen wrote:

“Hmmm... the major challenge in -25 was that although = Payload/Signature

Block identify the originator (HOSTNAME,APP-NAME,PROCID), = normal

syslog messages do not. So it seems you cannot separate the stored =

log files by originator, and process the parts one by = one.

 

If I understand you right, you're saying Section 7 does = *not*

in fact assume that you can separate the normal syslog = messages

by originator?

 

BTW, version -26 is still silent about whether a single = originator

can sign the same set of messages using different algorithms = (VER),

and if it can, whether these are same Signature Groups (with = same

message number space) or different. What's your proposal for =

addressing this -- or do you think signing using multiple = algorithm

doesn't have to be supported?”

 

------_=_NextPart_001_01C9EB27.241CC9EF-- From glenn@cysols.com Mon Jun 15 18:21:54 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076F03A6A92 for ; Mon, 15 Jun 2009 18:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_55=0.6] 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 C-632W7E4msK for ; Mon, 15 Jun 2009 18:21:53 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id 934DF3A6A56 for ; Mon, 15 Jun 2009 18:21:52 -0700 (PDT) Received: from [127.0.0.1] (cysvpn09.priv.cysol.co.jp [192.168.0.96]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.3/8.14.3) with ESMTP id n5D9aq8e036365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jun 2009 18:36:55 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4A337334.5020101@cysols.com> Date: Sat, 13 Jun 2009 18:36:52 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Chris Lonvick References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: Re: [Syslog] syslog WG Rechartering Discussion X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 01:21:54 -0000 Hi Chris. We also have the Syslog-MIB work (draft-ietf-syslog-device-mib-17.txt) that is currently on hold. A lot of work and discussion has gone into the document. Do we want to move this onto the next charter or, do it in the current WG ? I think that with another push we can take this through, now that we understand Syslog better. Glenn > Hi Folks,Chris Lonvick wrote: > > David and I are going to open the discussion about rechartering. Below > are some ideas that we've seen on the list that may fit into a charter > for a new syslog Working Group. These seem to fit better in the > Operations and Management Area than in the Security Area so we are > asking the ADs to move the WG to there when we do recharter. > > We'd like to get the discussion started now on this mailing list and > have a WG meeting in Stockholm to discuss rechartering issues. We hope > that by having a real meeting, we can draw in more OPS people who are > willing to work on these items, and/or to craft additional goals for > syslog. > > Please send your comments in about this and help move syslog forward. > > > > Fundamentals > - Documenting how a syslog relay is supposed to work. RFC3164 says that a > relay MAY change the header information in a syslog message. This needs > to be reexamined since syslog-sign mandates that no changes are allowed > in the whole syslog message between the sender and the device that > validates the detached signatures. > - A DHC option for a syslog receiver. Write an ID that standardizes how > DHCP should specify a syslog server and associated transport (udp, tls, > beep) in a URI format. > - The OpSec WG was planning to develop a draft about log event taxonomy > (what to log). This work should be compared to the syslog-alarm draft > from Sharon and Rainer, which defines categories for the alarm that are > fairly consistent with the ALARM-MIB and ITU alarm categories. There is > also CEE work that is also trying to define catagories of what to log. > > > Architecture > - An informational document that describes how each of the header fields > should be used. The technical information is in RFC 5424 but could use > some further explanation. > - Possibly combined with the previous topic, a "practical usage guide" > would be a good document for implementors and coders. > - A relook at the PRI values. There are currently 7 Severity levels and > 21 Facilities. The Facilities are ill-defined and out of date. The > information there could be better described in SDEs. We kept the > historical PRI values so that we would have a smooth(er) transition from > historical syslog to the IETF standard syslog. That has worked as > current syslog receivers do receive syslog messages in the new format. > > > Transport > - Documenting a TCP transport for syslog. There are many implementations > in the wild right now with two major variants. The problem between them > is the delimiter; prevalently a CR (I believe) is used to separate > multiple messages within a single TCP packet. The minor-use > implementation does not have a delimiter and just assumes one message > per packet. This will be relatively easy to straighten out. > - Finish syslog-transport-dtls. There are two individual submissions > which may be combined and moved into the WG. > - We should do something with syslog/BEEP. Should we declare the current > syslog/BEEP historic? and/or should we start an effort to publish an > update? > > > Ancillary > - There are other documents in the OPSAWG which might be better reviewed > in the new syslog WG, if they have not already completed reviews > elsewhere: > - Alarms in SYSLOG > - Mapping Simple Network Management Protocol (SNMP) Notifications to > SYSLOG Messages > - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > Network Management Protocol (SNMP) Notifications > - It would be good to encourage other groups to bring drafts of Structured > Data implementations to Syslog WG for review. These would likely not be > Syslog WG documents but the documents would benefit from being reviewed > by the Syslog WG. > - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create > SDEs to report that a series of messages have been dropped by a > sender. This document defines special syslog messages called > Discard messages for carrying logs loss statistics which indicate > how many logs (in terms of facility level or/and severity level) > were discarded by the syslog sender before they had a chance to hit > the wire connected to the syslog receiver during a particular period > in an extreme case. The statistics information Disard messages > convey is of interest to syslog receivers and helpful for later on > audit. > - draft-dulaunoy-syslog-geolocation-00 proposes adding geographic meta > information to syslog messages. This might be done using SDEs > - In an earlier version of netconf, there was work to correlate between > the information models of alarms from different NM interfaces. Part of > the purpose was to ease correlation of event reports for the same event > via different NM interfaces. > - Benoit Claise proposed making ipfix a general purpose reporting > protocol. Such a protocol might replace or supplement syslog. There > may be benefit to utilizing ipfix for carrying syslog information, so > there might be benefit to defining a way to convert syslog content into > ipfix formats, or to modify ipfix PDUs to carry syslog formats (both the > human-readable message part and the SDEs). This was a brand new > proposal at IETF 74, so has not had much discussion yet. We can discuss > this to see if there would be interest in such a direction. > > > Thanks, > Chris & David > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From Washam.Fan@huaweisymantec.com Tue Jun 16 20:59:54 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69B73A6822 for ; Tue, 16 Jun 2009 20:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[AWL=-1.201, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 mcoSmzEZFNF0 for ; Tue, 16 Jun 2009 20:59:53 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id A9DC73A63EC for ; Tue, 16 Jun 2009 20:59:53 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLD001A273UWO90@hstga02-in.huaweisymantec.com> for syslog@ietf.org; Wed, 17 Jun 2009 11:59:54 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLD00D2173U7310@hstml01-in.huaweisymantec.com> for syslog@ietf.org; Wed, 17 Jun 2009 11:59:54 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 17 Jun 2009 11:59:54 +0800 From: WashamFan To: syslog@ietf.org Message-id: Date: Wed, 17 Jun 2009 11:59:54 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [Syslog] Comments on syslog-sign-26 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:59:54 -0000 Hi, I'd like issue some concerns here. 1. the text below is from sec 4.2.4 Note that the Global Block Counter crosses Signature Groups; it allows one to roughly synchronize when two messages were sent, even though they went to different collectors and are part of different Signature Groups. But I am still not quite clear about what the GBC field is for. IMO, removing this field does not matter much. Or could you elaborate on how it help sync? 2. sec 6.1.1: Does certResendDelay or certResendCount refine the resending behavior after the first normal message is sent or before that or both? Are you saying resending Payload periodically in a long lived reboot session? 3. sec 6.1.2: Why not introduce a param called sigMaxCount to specify the max count of hashes in a Signature Block message? 4. signer vs. originator an originator is specified as (hostname, app-name, procid) triple. So does a signer? If yes. then an originator can not have multiple signers in the same time, but multiple originators can share the same signer. In the latter case, should every originator exchange its Payload independently? washam From Pasi.Eronen@nokia.com Wed Jun 17 10:45:35 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF4E3A6E7A for ; Wed, 17 Jun 2009 10:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zILm1Nz+V2qF for ; Wed, 17 Jun 2009 10:45:28 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DD8A33A691D for ; Wed, 17 Jun 2009 10:45:27 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5HHhPWc032578; Wed, 17 Jun 2009 20:43:38 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 20:43:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 20:43:17 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 17 Jun 2009 19:43:17 +0200 From: To: Date: Wed, 17 Jun 2009 19:43:15 +0200 Thread-Topic: Syslog-sign-26 Thread-Index: AcnrJvowC/Va+9apR+yYkjg/opAkBwESGFgg Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6B0FAA15@NOK-EUMSG-01.mgdnok.nokia.com> References: <85B2F271FDF6B949B3672BA5A7BB62FB07E6021E@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB07E6021E@xmb-sjc-236.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB773A6B0FAA15NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2009 17:43:17.0846 (UTC) FILETIME=[191E3F60:01C9EF73] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign-26 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:45:35 -0000 --_000_808FD6E27AD4884E94820BC333B2DB773A6B0FAA15NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex, Thanks for the explanation - it did indeed clarify things, and seems to pro= vide a simple way to fix the situation! The word "originator" comes from RFC 5424, and the current version of syslo= g-sign seems to assume that originator both originates normal syslog messag= es *and* signs them (originates Signature/Certificate Block messages). But = your explanation -- a single originator (of normal syslog messages) could e= ven have multiple signers (with different APP-NAME,PROCID) that sign the *s= ame* normal syslog messages (with different algorithms) -- would seem to cl= arify things. However, this does require some changes to the draft, right? (introducing t= he term "signer", and replacing some instances of "originator" with "signer= ") Best regards, Pasi From: ext Alexander Clemm (alex) [mailto:alex@cisco.com] Sent: 12 June, 2009 09:28 To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: syslog@ietf.org Subject: Re: Syslog-sign-26 Hello Pasi, I guess any confusion stems from the use of the word "originator". Therefo= re, let me use the term "signer" for the purposes of this discussion. A si= gner signs syslog-messages using a specific algorithm; it is an "originator= " of syslog-sign messages. A single host can host multiple signers, which = then each use their own Signature Groups and algorithms. The syslog-sign m= essages can be attributed to a specific signer using (HOSTNAME, APP-NAME, P= ROCID). Section 7 does say that you can separate syslog-sign messages acco= rding to signer, using this triple. (It is the syslog-sign messages you ar= e concerned about; you separate the syslog-sign messages by signers. You c= an separate the "normal" messages by virtue of who signed them.) So, in su= mmary, the ability to be able to use different algorithms to sign messages = is supported, but the corresponding syslog-sign messages need to use differ= ent (HOSTNAME,APP-NAME,PROCID) to be able to distinguish which is used wher= e. Now, the question is whether to equate "signer" with "originator". If you = equate them, then each signer would be considered its own originator of its= own syslog messages. However, you can also simply regard it from the pers= pective that the same originator can in effect incorporate multiple signers= , if wanting to use multiple algorithms concurrently. It doesn't really m= atter - just like with "normal" syslog messages without syslog sign you don= 't really distinguish if there are multiple originators on the same host or= only one - the syslog message does not contain an "originator-ID" but (HOS= TNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you support th= e ability to sign messages using different algorithms from the same host. Does this clarify? --- Alex Pasi Eronen wrote: "Hmmm... the major challenge in -25 was that although Payload/Signature Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal syslog messages do not. So it seems you cannot separate the stored log files by originator, and process the parts one by one. If I understand you right, you're saying Section 7 does *not* in fact assume that you can separate the normal syslog messages by originator? BTW, version -26 is still silent about whether a single originator can sign the same set of messages using different algorithms (VER), and if it can, whether these are same Signature Groups (with same message number space) or different. What's your proposal for addressing this -- or do you think signing using multiple algorithm doesn't have to be supported?" --_000_808FD6E27AD4884E94820BC333B2DB773A6B0FAA15NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alex,

 =

Thanks for the explanati= on - it did indeed clarify things, and seems to provide a simple way to fix the situation!

 =

The word "originato= r" comes from RFC 5424, and the current version of syslog-sign seems to assume that originator both originates normal syslog messages *and* signs them (originates Signature/Certificate Block messages). But your explanation -- = a single originator (of normal syslog messages) could even have multiple sign= ers (with different APP-NAME,PROCID) that sign the *same* normal syslog message= s (with different algorithms) -- would seem to clarify things.

 =

However, this does requi= re some changes to the draft, right? (introducing the term "signer", and replacing some instances of "originator" with "signer")=

 =

Best regards,=

Pasi

 =

 =

From: ext Alexander= Clemm (alex) [mailto:alex@cisco.com]
Sent: 12 June, 2009 09:28
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: syslog@ietf.org
Subject: Re: Syslog-sign-26

 

Hello Pasi,

 

I guess any confusion stems from the use of the word “originator”.  Therefore, let me use the term “signer” for the purposes of this discussion.  A signer si= gns syslog-messages using a specific algorithm; it is an “originator̶= 1; of syslog-sign messages.  A single host can host multiple signers, whi= ch then each use their own Signature Groups and algorithms.  The syslog-s= ign messages can be attributed to a specific signer using (HOSTNAME, APP-NAME, PROCID).  Section 7 does say that you can separate syslog-sign message= s according to signer, using this triple.  (It is the syslog-sign messag= es you are concerned about; you separate the syslog-sign messages by signers.  You can separate the “normal” messages by virtue= of who signed them.)  So, in summary, the ability to be able to use diffe= rent algorithms to sign messages is supported, but the corresponding syslog-sign messages need to use different (HOSTNAME,APP-NAME,PROCID) to be able to distinguish which is used where. 

 

Now, the question is whether to equate “signer&#= 8221; with “originator”.  If you equate them, then each signer w= ould be considered its own originator of its own syslog messages.  However,= you can also simply regard it from the perspective that the same originator can= in effect incorporate multiple signers, if wanting to use multiple algorithms concurrently.   It doesn’t really matter – just like = with “normal” syslog messages without syslog sign you don’t re= ally distinguish if there are multiple originators on the same host or only one – the syslog message does not contain an “originator-ID” = but (HOSTNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you suppor= t the ability to sign messages using different algorithms from the same host.   

 

Does this clarify?

--- Alex

 

 

Pasi Eronen wrote:

“Hmmm... the major challenge in -25 was that although Payload/Signature

Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal

syslog messages do not. So it seems you cannot separate the stored

log files by originator, and process the parts one by one.

 

If I understand you right, you're saying Section 7 does *not*

in fact assume that you can separate the normal syslog messages

by originator?

 

BTW, version -26 is still silent about whether a single originator

can sign the same set of messages using different algorithms (VER),<= /span>

and if it can, whether these are same Signature Groups (with same

message number space) or different. What's your proposal for

addressing this -- or do you think signing using multiple algorithm<= /p>

doesn't have to be supported?”

 

--_000_808FD6E27AD4884E94820BC333B2DB773A6B0FAA15NOKEUMSG01mgd_-- From clonvick@cisco.com Wed Jun 17 15:21:51 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF2E3A6D8B for ; Wed, 17 Jun 2009 15:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 eJ7GlXLZsPJa for ; Wed, 17 Jun 2009 15:21:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13E503A6ECA for ; Wed, 17 Jun 2009 15:21:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,239,1243814400"; d="scan'208";a="326147778" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Jun 2009 22:22:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5HMM3ef009067; Wed, 17 Jun 2009 15:22:03 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5HMM3iw023749; Wed, 17 Jun 2009 22:22:03 GMT Date: Wed, 17 Jun 2009 15:22:03 -0700 (PDT) From: Chris Lonvick To: WashamFan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2138; t=1245277323; x=1246141323; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Comments=20on=20syslog-sign- 26 |Sender:=20; bh=Lv3aB9qnJWJY4nTqMMWQBo7QWEJ4AA2mEAZoufGXY7M=; b=ddY9niIDd9wUIHtK2Q2leB2L1/TmFuZlPkfBudkieyg7pKyizoBLktkasr Hx8cd3/NacnOOotbg9d5Qia1T9jCUvgm4BAwcwVFV1vTHk9Z+5YL5/dHP9Nb FIow4/Zyz0; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Comments on syslog-sign-26 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 22:21:52 -0000 Hi, On Wed, 17 Jun 2009, WashamFan wrote: > Hi, > > I'd like issue some concerns here. > > 1. the text below is from sec 4.2.4 > > Note that the Global Block Counter crosses Signature Groups; it > allows one to roughly synchronize when two messages were sent, even > though they went to different collectors and are part of different > Signature Groups. > > But I am still not quite clear about what the GBC field is for. IMO, > removing this field does not matter much. Or could you elaborate > on how it help sync? Let's say that you have SG=3 with PRIs <50 going to one collector and PRIs >50 going to a different one. The first collector would get some GBCs and the other collector would get different ones. Perhaps: one gets 1,3,5,7,9,11,12,13,14,15,16,17,18 two gets 0,2,4,6,8,10,19 >From that, you can sort'a tell what's going on, and that you havn't lost any. > > 2. sec 6.1.1: > > Does certResendDelay or certResendCount refine the resending > behavior after the first normal message is sent or before that or > both? Are you saying resending Payload periodically in a long lived > reboot session? Like this: http://www.ietf.org/mail-archive/web/syslog/current/msg02332.html Does the document need more clarification on this? > > 3. sec 6.1.2: > > Why not introduce a param called sigMaxCount to specify the > max count of hashes in a Signature Block message? That's limited by the overall length of the syslog message. > > 4. signer vs. originator > an originator is specified as (hostname, app-name, procid) triple. > So does a signer? If yes. then an originator can not have multiple > signers in the same time, but multiple originators can share the > same signer. In the latter case, should every originator exchange > its Payload independently? That's the discussion going on between Pasi and Alex on the list right now. > > washam > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > Many thanks for your review and comments. Regards, Chris From Washam.Fan@huaweisymantec.com Wed Jun 17 20:09:48 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFF328C18C for ; Wed, 17 Jun 2009 20:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 F8RnXaueZxfO for ; Wed, 17 Jun 2009 20:09:47 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 9AA4928C14D for ; Wed, 17 Jun 2009 20:09:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLE0001RZGDCQ20@hstga01-in.huaweisymantec.com> for syslog@ietf.org; Thu, 18 Jun 2009 11:09:49 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLE003YVZGDY600@hstml01-in.huaweisymantec.com> for syslog@ietf.org; Thu, 18 Jun 2009 11:09:49 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 18 Jun 2009 11:09:49 +0800 From: WashamFan To: Chris Lonvick Message-id: Date: Thu, 18 Jun 2009 11:09:49 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: References: Cc: syslog@ietf.org Subject: [Syslog] config params for cert block[Was:Re: Comments on syslog-sign-26] X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 03:09:48 -0000 Hi, > > 2. sec 6.1.1: > > > > Does certResendDelay or certResendCount refine the resending > > behavior after the first normal message is sent or before that or > > both? Are you saying resending Payload periodically in a long lived > > reboot session? > > Like this: > http://www.ietf.org/mail-archive/web/syslog/current/msg02332.html > Does the document need more clarification on this? This URL offers a good explanation of config params for sig block. Thanks. But my concern was related to cert block, actually. Let me express in a clearer way: There are three params defined. "certInitialRepeat" indicates how many copies of Payload should be sent beforehand. But there is not clear that how to send those copies, one after one immediately or between interval? It seems "certResendDelay" and "certResendCount" have nothing to do with *pre-historical* resending behavior, although I am not sure it was the intent. Since there is no counterpart to "sigNumberResends" for cert block, then I assume, if "certResend*" params are greater than 0, then Payload will be resent periodically until "session" is broken. Right? washam From Washam.Fan@huaweisymantec.com Wed Jun 17 20:45:18 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC363A6A5D for ; Wed, 17 Jun 2009 20:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.238 X-Spam-Level: X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 t5OLL18LkvFZ for ; Wed, 17 Jun 2009 20:45:18 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id BCA9E3A69AD for ; Wed, 17 Jun 2009 20:45:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLF000DL13JCQ20@hstga01-in.huaweisymantec.com> for syslog@ietf.org; Thu, 18 Jun 2009 11:45:19 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLF004Z313JRW00@hstml01-in.huaweisymantec.com> for syslog@ietf.org; Thu, 18 Jun 2009 11:45:19 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 18 Jun 2009 11:45:19 +0800 From: WashamFan To: Pasi.Eronen@nokia.com Message-id: Date: Thu, 18 Jun 2009 11:45:19 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <808FD6E27AD4884E94820BC333B2DB773A6B0FAA15@NOK-EUMSG-01.mgdnok.nokia.com> References: <85B2F271FDF6B949B3672BA5A7BB62FB07E6021E@xmb-sjc-236.amer.cisco.com> <808FD6E27AD4884E94820BC333B2DB773A6B0FAA15@NOK-EUMSG-01.mgdnok.nokia.com> Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign-26 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 03:45:19 -0000 Hi, It seems to me that both "originator" and "signer" are identified by (HOSTNAME, APP-NAME, PROCID) triple. So how to understand an originator across multiple signers? In the other hand, does it make sense a signer across multiple originators. Imagine that, a syslog daomon collects logs from multiple applications with different APP-NAME per application, and the syslog daemon signs all the logs with different APP-NAMEs In that case, does each originator exchange its cert blocks independently? washam ----- Original Message ----- From: Pasi.Eronen@nokia.com Date: Thursday, June 18, 2009 1:45 am Subject: Re: [Syslog] Syslog-sign-26 To: alex@cisco.com Cc: syslog@ietf.org > Hi Alex, > > Thanks for the explanation - it did indeed clarify things, and seems > to provide a simple way to fix the situation! > > The word "originator" comes from RFC 5424, and the current version of > syslog-sign seems to assume that originator both originates normal > syslog messages *and* signs them (originates Signature/Certificate > Block messages). But your explanation -- a single originator (of > normal syslog messages) could even have multiple signers (with > different APP-NAME,PROCID) that sign the *same* normal syslog messages > (with different algorithms) -- would seem to clarify things. > > However, this does require some changes to the draft, right? > (introducing the term "signer", and replacing some instances of > "originator" with "signer") > > Best regards, > Pasi > > > From: ext Alexander Clemm (alex) [mailto:alex@cisco.com] > Sent: 12 June, 2009 09:28 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: syslog@ietf.org > Subject: Re: Syslog-sign-26 > > Hello Pasi, > > I guess any confusion stems from the use of the word "originator". > Therefore, let me use the term "signer" for the purposes of this > discussion. A signer signs syslog-messages using a specific > algorithm; it is an "originator" of syslog-sign messages. A single > host can host multiple signers, which then each use their own > Signature Groups and algorithms. The syslog-sign messages can be > attributed to a specific signer using (HOSTNAME, APP-NAME, PROCID). > Section 7 does say that you can separate syslog-sign messages > according to signer, using this triple. (It is the syslog-sign > messages you are concerned about; you separate the syslog-sign > messages by signers. You can separate the "normal" messages by virtue > of who signed them.) So, in summary, the ability to be able to use > different algorithms to sign messages is supported, but the > corresponding syslog-sign messages need to use different > (HOSTNAME,APP-NAME,PROCID) to be able to distinguish which is used where. > > Now, the question is whether to equate "signer" with "originator". > If you equate them, then each signer would be considered its own > originator of its own syslog messages. However, you can also simply > regard it from the perspective that the same originator can in effect > incorporate multiple signers, if wanting to use multiple algorithms > concurrently. It doesn't really matter - just like with "normal" > syslog messages without syslog sign you don't really distinguish if > there are multiple originators on the same host or only one - the > syslog message does not contain an "originator-ID" but > (HOSTNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you > support the ability to sign messages using different algorithms from > the same host. > > Does this clarify? > --- Alex > > > Pasi Eronen wrote: > "Hmmm... the major challenge in -25 was that although Payload/Signature > Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal > syslog messages do not. So it seems you cannot separate the stored > log files by originator, and process the parts one by one. > > If I understand you right, you're saying Section 7 does *not* > in fact assume that you can separate the normal syslog messages > by originator? > > BTW, version -26 is still silent about whether a single originator > can sign the same set of messages using different algorithms (VER), > and if it can, whether these are same Signature Groups (with same > message number space) or different. What's your proposal for > addressing this -- or do you think signing using multiple algorithm > doesn't have to be supported?" > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From Washam.Fan@huaweisymantec.com Wed Jun 17 20:53:54 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC793A6A5A for ; Wed, 17 Jun 2009 20:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] 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 BLYcd9UgjnXf for ; Wed, 17 Jun 2009 20:53:54 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 18ACF3A6A5D for ; Wed, 17 Jun 2009 20:53:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLF000GY1HVCQ20@hstga01-in.huaweisymantec.com> for syslog@ietf.org; Thu, 18 Jun 2009 11:53:56 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLF003561HVJO10@hstml01-in.huaweisymantec.com> for syslog@ietf.org; Thu, 18 Jun 2009 11:53:55 +0800 (CST) Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 18 Jun 2009 11:53:55 +0800 From: WashamFan To: Chris Lonvick Message-id: Date: Thu, 18 Jun 2009 11:53:55 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: References: Cc: syslog@ietf.org Subject: [Syslog] GBC field [Was:Re: Comments on syslog-sign-26] X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 03:53:55 -0000 Hi, > > 1. the text below is from sec 4.2.4 > > > > Note that the Global Block Counter crosses Signature Groups; it > > allows one to roughly synchronize when two messages were sent, even > > though they went to different collectors and are part of different > > Signature Groups. > > > > But I am still not quite clear about what the GBC field is for. IMO, > > removing this field does not matter much. Or could you elaborate > > on how it help sync? > > Let's say that you have SG=3 with PRIs <50 going to one collector and > PRIs > >50 going to a different one. The first collector would get some > GBCs and > the other collector would get different ones. Perhaps: > one gets 1,3,5,7,9,11,12,13,14,15,16,17,18 > two gets 0,2,4,6,8,10,19 > From that, you can sort'a tell what's going on, and that you havn't > lost > any. I am sorry, it seems a little bit hard for me to understand. for collectors, they can tell what sig they lost without GBC. for senders, they have no idea sig blocks lost or not since syslog is a simplex protocol. One more thing, dose the re-sent sig block have the same GBC as the original one? washam From Pasi.Eronen@nokia.com Thu Jun 18 12:19:06 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482A828C377 for ; Thu, 18 Jun 2009 12:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 xh74htX5qMCw for ; Thu, 18 Jun 2009 12:19:05 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D0CDE3A68CE for ; Thu, 18 Jun 2009 12:18:52 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5IJIVoJ000665; Thu, 18 Jun 2009 22:18:48 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 22:17:10 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 22:17:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 22:16:55 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 18 Jun 2009 21:16:54 +0200 From: To: Date: Thu, 18 Jun 2009 21:16:53 +0200 Thread-Topic: [Syslog] Syslog-sign-26 Thread-Index: AcnvxzqVNor8JnmIS3S2atlvi9rTFwAgXp1Q Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6B13799B@NOK-EUMSG-01.mgdnok.nokia.com> References: <85B2F271FDF6B949B3672BA5A7BB62FB07E6021E@xmb-sjc-236.amer.cisco.com> <808FD6E27AD4884E94820BC333B2DB773A6B0FAA15@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jun 2009 19:16:55.0120 (UTC) FILETIME=[57AFFD00:01C9F049] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign-26 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:19:06 -0000 WashamFan wrote: > Hi, >=20 > It seems to me that both "originator" and "signer" are identified > by (HOSTNAME, APP-NAME, PROCID) triple. So how to understand > an originator across multiple signers? >=20 > In the other hand, does it make sense a signer across multiple > originators. Imagine that, a syslog daomon collects logs from > multiple applications with different APP-NAME per application, > and the syslog daemon signs all the logs with different APP-NAMEs > In that case, does each originator exchange its cert blocks > independently? My expectation was that the syslog daemon would use its own APP-NAME ("syslogd" or something) and PROCID for the Certificate/Signature Block messages, not the APP-NAME from the messages being signed ("sendmail" or "crond" or something). Best regards, Pasi