From syslog-bounces@ietf.org Wed Oct 1 10:45:08 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AC53A6C67; Wed, 1 Oct 2008 10:45:08 -0700 (PDT) X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 299873A67B3; Wed, 1 Oct 2008 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081001174505.299873A67B3@core3.amsl.com> Date: Wed, 1 Oct 2008 10:45:02 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-14.txt 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: , Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : TLS Transport Mapping for Syslog Author(s) : M. Fuyou, et al. Filename : draft-ietf-syslog-transport-tls-14.txt Pages : 15 Date : 2008-10-01 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-01103413.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@ietf.org Wed Oct 1 13:40:36 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA3C3A69DF; Wed, 1 Oct 2008 13:40:36 -0700 (PDT) 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 F17113A69DF for ; Wed, 1 Oct 2008 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 qrornb89Wwce for ; Wed, 1 Oct 2008 13:40:34 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 97CA43A67A6 for ; Wed, 1 Oct 2008 13:40:33 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so260320fkq.5 for ; Wed, 01 Oct 2008 13:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=9xwQuqKbjla3yW6HmMobF1NVaPlTBzMZfXENDs0dw+4=; b=IBeEN1J9SNjPi+xo1KXRfXtkh3MJbIcd0NPBdc+FUddQ+9YP560w+23LHhCPIiYjEE P6UBYV5zU0OecxFE5aFaGbd4sGOnhUTtZbWdE8DyL34Jd9Svbx0nMjmBHnShYmQs5HwM eZQnreEnLChhfwkYB0PhkfGlIvey4AiSS1PYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=snloheeAH4ulo/KmpcWUf1S8VfjK9OqrXxfa2ff+GrkJkMI+663NAG9aAtneLGIMaX o2fIh8xhX50Dy88RLgjjPg8L323KlhpP9zq3kBtKYyeIAqrF115O4zslf06tk32SGDCq Aldr86rMo76vGnj24WKfAjxyPAELwEZ8tTerI= Received: by 10.180.218.16 with SMTP id q16mr4892434bkg.64.1222893656759; Wed, 01 Oct 2008 13:40:56 -0700 (PDT) Received: by 10.180.251.9 with HTTP; Wed, 1 Oct 2008 13:40:56 -0700 (PDT) Message-ID: Date: Wed, 1 Oct 2008 22:40:56 +0200 From: Badra To: syslog@ietf.org In-Reply-To: <20081001174505.299873A67B3@core3.amsl.com> MIME-Version: 1.0 References: <20081001174505.299873A67B3@core3.amsl.com> Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-14.txt 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: , Content-Type: multipart/mixed; boundary="===============1188839576==" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org --===============1188839576== Content-Type: multipart/alternative; boundary="----=_Part_69583_1983204.1222893656774" ------=_Part_69583_1983204.1222893656774 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, In section 4.4, the following text was removed: When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. In RFC 5256, Section 7.2.1: The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. The actual version doesn't discuss what will happen to the pending writes. Please clarify which of the above two texts is applied. I guess the second, right? Best regards Badra 2008/10/1 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Security Issues in Network Event Logging > Working Group of the IETF. > > > Title : TLS Transport Mapping for Syslog > Author(s) : M. Fuyou, et al. > Filename : draft-ietf-syslog-transport-tls-14.txt > Pages : 15 > Date : 2008-10-01 > > This document describes the use of Transport Layer Security (TLS) to > provide a secure connection for the transport of syslog messages. > This document describes the security threats to syslog and how TLS > can be used to counter such threats. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-14.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog ------=_Part_69583_1983204.1222893656774 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
In section 4.4, the following text was removed:
 
   When the client has received the close_notify alert from the server and
   still has pending data to send, it SHOULD send the pending data before
   sending the close_notify alert.
In RFC 5256, Section 7.2.1:
 
   The other party MUST respond with a close_notify alert of its own and
   close down the connection immediately, discarding any pending writes.
 
The actual version doesn't discuss what will happen to the pending writes. Please clarify which of the above two texts is applied. I guess the second, right?
 
Best regards
Badra
 

 
2008/10/1 <Internet-Drafts@ietf.org>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.


       Title           : TLS Transport Mapping for Syslog
       Author(s)       : M. Fuyou, et al.
       Filename        : draft-ietf-syslog-transport-tls-14.txt
       Pages           : 15
       Date            : 2008-10-01

This document describes the use of Transport Layer Security (TLS) to
provide a secure connection for the transport of syslog messages.
This document describes the security threats to syslog and how TLS
can be used to counter such threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog
------=_Part_69583_1983204.1222893656774-- --===============1188839576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog --===============1188839576==-- From syslog-bounces@ietf.org Wed Oct 1 13:58:30 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677B83A69FA; Wed, 1 Oct 2008 13:58:30 -0700 (PDT) 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 1BB273A69FA for ; Wed, 1 Oct 2008 13:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 lf9JTfQXozAC for ; Wed, 1 Oct 2008 13:58:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 50CE03A694D for ; Wed, 1 Oct 2008 13:58:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,346,1220227200"; d="scan'208";a="105898200" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2008 20:58:52 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m91Kwpqt015123; Wed, 1 Oct 2008 13:58:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m91KwpnC014860; Wed, 1 Oct 2008 20:58:51 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 13:58:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Oct 2008 13:58:50 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-14.txt thread-index: AckkBgfudxfSLowuSAqHu6kjRZ0UlQAAjcNA References: <20081001174505.299873A67B3@core3.amsl.com> From: "Joseph Salowey (jsalowey)" To: "Badra" , X-OriginalArrivalTime: 01 Oct 2008 20:58:51.0304 (UTC) FILETIME=[81D09A80:01C92408] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2476; t=1222894731; x=1223758731; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Syslog]=20I-D=20Action=3Adraft-ietf-sy slog-transport-tls-14.txt |Sender:=20; bh=/hbZDctkQaTbSCMk6dI4uxU3J8+RWE1NrJUQo5BLQCE=; b=ZIh6vLd/lSNr+DFjmxuCwwc3BOP2aMpkEaYfyp3yf9eeoDHOtjla4dzfJy tgrRyOF4dKJMhhTBg/y+7DY57HLZg4T6XZ/+LFyxE9ezE/JS8UTd09qTPPK9 2ut1MnmrytVbtQHLGb5ZemWJoTWPKHTHFagUY9WM5NxRr90j4ics4=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-14.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Yes, we removed the text that conflicted with 5246 so now all that applies is 5246. > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Badra > Sent: Wednesday, October 01, 2008 1:41 PM > To: syslog@ietf.org > Subject: Re: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-14.txt > > Hi, > > In section 4.4, the following text was removed: > > When the client has received the close_notify alert from > the server and > still has pending data to send, it SHOULD send the pending > data before > sending the close_notify alert. > > In RFC 5256, Section 7.2.1: > > The other party MUST respond with a close_notify alert of > its own and > close down the connection immediately, discarding any > pending writes. > > The actual version doesn't discuss what will happen to the > pending writes. Please clarify which of the above two texts > is applied. I guess the second, right? > > Best regards > Badra > > > > 2008/10/1 > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Security Issues in > Network Event Logging Working Group of the IETF. > > > Title : TLS Transport Mapping for Syslog > Author(s) : M. Fuyou, et al. > Filename : draft-ietf-syslog-transport-tls-14.txt > Pages : 15 > Date : 2008-10-01 > > This document describes the use of Transport Layer > Security (TLS) to > provide a secure connection for the transport of syslog > messages. > This document describes the security threats to syslog > and how TLS > can be used to counter such threats. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpor > t-tls-14.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII > version of the > Internet-Draft. > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Oct 2 00:42:23 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3D63A6841; Thu, 2 Oct 2008 00:42:23 -0700 (PDT) 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 4DD0A3A6831 for ; Thu, 2 Oct 2008 00:42:22 -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 PnBWmr1fPZ2U for ; Thu, 2 Oct 2008 00:42:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1567E3A69FB for ; Thu, 2 Oct 2008 00:42:21 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25A0CC0020 for ; Thu, 2 Oct 2008 09:41:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LbUfVQPev0vq; Thu, 2 Oct 2008 09:41:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD814C006C; Thu, 2 Oct 2008 09:41:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3E9317E0290; Thu, 2 Oct 2008 09:41:45 +0200 (CEST) Date: Thu, 2 Oct 2008 09:41:45 +0200 From: Juergen Schoenwaelder To: syslog@ietf.org Message-ID: <20081002074145.GB26849@elstar.local> Mail-Followup-To: syslog@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Syslog] semantics of the origin SD-ID X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi, I have a question concerning the semantics of the origin SD-ID defined in section 7.2 of . The text talks about the "originator" of a message. The definition of "originator" is provided in section 3: o An "originator" generates syslog content to be carried in a message. I am facing a situation which looks as follows: box A box B +-------+ non-syslog +-------+ syslog | | ----------------> | T | -----------> ... +-------+ notification +-------+ message I have an event notification originating from box A that is received by box B via a non-syslog protocol. Box B runs a translator T turning the non-syslog event notification into a syslog message. If I take the text in the syslog specs literally, then the origin SD-ID likely identifies the (syslog) originator, that is box B. However, the text in 7.2 also says: Specifying any of these parameters is primarily an aid to log analyzers and similar applications. Since the true origin of the event carried in the syslog message is box A, a log analyzer might be better served by being able to identify box A as the origin of the content carried in the syslog message, even though the first hop in the forwarding chain was not really a syslog message. What do the syslog experts think - should the origin SD-ID identify box A or box B in the example above? /js PS: The background behind this question is work proposed to the OPSAWG on mapping SNMP notifications to SYSLOG messages and I like to clarify in the mapping what the semantic of the origin SD-ID is in this context (). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Oct 2 00:53:48 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED8528C1FC; Thu, 2 Oct 2008 00:53:48 -0700 (PDT) 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 817A328C1FC for ; Thu, 2 Oct 2008 00:53:47 -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 XoN04HI0ktX8 for ; Thu, 2 Oct 2008 00:53:46 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 4472828C1E5 for ; Thu, 2 Oct 2008 00:53:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 340A67AC076; Thu, 2 Oct 2008 09:51:22 +0200 (CEST) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE0C3IbC9v9J; Thu, 2 Oct 2008 09:51:22 +0200 (CEST) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id CDA187AC073; Thu, 2 Oct 2008 09:51:21 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 2 Oct 2008 09:53:45 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F272@grfint2.intern.adiscon.com> In-Reply-To: <20081002074145.GB26849@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] semantics of the origin SD-ID Thread-Index: AckkYnmHEB0UOYXUSZatR+qkaVDnVQAANsYw References: <20081002074145.GB26849@elstar.local> From: "Rainer Gerhards" To: Cc: syslog@ietf.org Subject: Re: [Syslog] semantics of the origin SD-ID 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi J=FCrgen, the upcoming syslog rfc series is still missing two documents, I think: one= on relay behavior and one on gateway behavior. So let me express my person= al view as I can not cite anything that underwent discussion. In the gateway case you describe, I would think that the origin SD-ID shoul= d contain identification of the original originator, provided that this ide= ntification is known with sufficient trust (which it is in case of SNMP, I = think). Also thanks for making me aware of draft-marinov-syslog-snmp-02.txt, this l= ooks like useful work. Rainer > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, October 02, 2008 9:42 AM > To: syslog@ietf.org > Subject: [Syslog] semantics of the origin SD-ID > = > Hi, > = > I have a question concerning the semantics of the origin SD-ID defined > in section 7.2 of . The text talks > about the "originator" of a message. The definition of "originator" is > provided in section 3: > = > o An "originator" generates syslog content to be carried in a > message. > = > I am facing a situation which looks as follows: > = > box A box B > +-------+ non-syslog +-------+ syslog > | | ----------------> | T | -----------> ... > +-------+ notification +-------+ message > = > I have an event notification originating from box A that is received > by box B via a non-syslog protocol. Box B runs a translator T turning > the non-syslog event notification into a syslog message. If I take the > text in the syslog specs literally, then the origin SD-ID likely > identifies the (syslog) originator, that is box B. However, the text > in 7.2 also says: > = > Specifying any of these parameters is primarily an aid to log > analyzers and similar applications. > = > Since the true origin of the event carried in the syslog message is > box A, a log analyzer might be better served by being able to identify > box A as the origin of the content carried in the syslog message, even > though the first hop in the forwarding chain was not really a syslog > message. > = > What do the syslog experts think - should the origin SD-ID identify > box A or box B in the example above? > = > /js > = > PS: The background behind this question is work proposed to the OPSAWG > on mapping SNMP notifications to SYSLOG messages and I like to > clarify in the mapping what the semantic of the origin SD-ID is in > this context (). > = > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Oct 2 02:49:08 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBA63A6C14; Thu, 2 Oct 2008 02:49:08 -0700 (PDT) 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 498633A69C2 for ; Thu, 2 Oct 2008 02:49:07 -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=[AWL=0.000, 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 7cwZJwUiewzN for ; Thu, 2 Oct 2008 02:49:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 75BC03A6C14 for ; Thu, 2 Oct 2008 02:49:06 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFC51C001D; Thu, 2 Oct 2008 11:48:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OaH8hTXh+FUf; Thu, 2 Oct 2008 11:48:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0B27C006E; Thu, 2 Oct 2008 11:48:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D13E7E117B; Thu, 2 Oct 2008 11:48:07 +0200 (CEST) Date: Thu, 2 Oct 2008 11:48:07 +0200 From: Juergen Schoenwaelder To: Rainer Gerhards Message-ID: <20081002094807.GA27019@elstar.local> Mail-Followup-To: Rainer Gerhards , syslog@ietf.org References: <20081002074145.GB26849@elstar.local> <577465F99B41C842AAFBE9ED71E70ABA44F272@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F272@grfint2.intern.adiscon.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: syslog@ietf.org Subject: Re: [Syslog] semantics of the origin SD-ID X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org On Thu, Oct 02, 2008 at 09:53:45AM +0200, Rainer Gerhards wrote: > Also thanks for making me aware of draft-marinov-syslog-snmp-02.txt, > this looks like useful work. Please let the OPSAWG an their chairs know since they need to determine concensus whether this document is taken on as an OPSAWG work item. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Oct 2 03:03:58 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A723A6B42; Thu, 2 Oct 2008 03:03:58 -0700 (PDT) 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 156563A6B42; Thu, 2 Oct 2008 03:03:57 -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 ol-pPBkaEsNF; Thu, 2 Oct 2008 03:03:56 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id D30DE3A6803; Thu, 2 Oct 2008 03:03:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 879C67AC072; Thu, 2 Oct 2008 12:00:30 +0200 (CEST) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3CoctrQjBoc; Thu, 2 Oct 2008 12:00:30 +0200 (CEST) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id 09D957AC065; Thu, 2 Oct 2008 12:00:28 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 2 Oct 2008 12:03:35 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F278@grfint2.intern.adiscon.com> In-Reply-To: <20081002094807.GA27019@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: relevance of draft-marinov-syslog-snmp-02.txt Thread-Index: AckkdMK+s0brotLvT4mNDY3Fd0KNHgAAFsGA References: <20081002074145.GB26849@elstar.local> <577465F99B41C842AAFBE9ED71E70ABA44F272@grfint2.intern.adiscon.com> <20081002094807.GA27019@elstar.local> From: "Rainer Gerhards" To: , Cc: syslog@ietf.org Subject: [Syslog] relevance of draft-marinov-syslog-snmp-02.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi OPSAWG, I am a syslog implementor and would like to endorse the work planned to support mapping of SNMP to syslog. There are already implementations available, those that I know out of my head are Kiwi Syslog, WinSyslog, MonitorWare Agent and rsyslog (default or to-become default on many linux distributions). I am sure there are also plenty of others. I think Cisco has created a private syslog MIB, at least I think I remember we used it some time ago. I am the author of rsyslog. While I have not written the SNMP plugins, I know from discussions that having no standard MIB for syslog messages causes each vendor to define its own or (mis)use some private extension of other vendors (as we initially did). Similar issues exist on the receiving side. While probably not mainstream, there are a number of installations who do syslog-to-snmp (and vice versa) processing. So there is operator demand for this kind of mapping. Best regards, Rainer Gerhards > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, October 02, 2008 11:48 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] semantics of the origin SD-ID > > On Thu, Oct 02, 2008 at 09:53:45AM +0200, Rainer Gerhards wrote: > > > Also thanks for making me aware of draft-marinov-syslog-snmp-02.txt, > > this looks like useful work. > > Please let the OPSAWG an their chairs know since they need to > determine concensus whether this document is taken on as an OPSAWG > work item. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Oct 8 08:08:47 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A165C28C1B2; Wed, 8 Oct 2008 08:08:47 -0700 (PDT) X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3A3B03A6BDE; Wed, 8 Oct 2008 08:08:45 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20081008150846.3A3B03A6BDE@core3.amsl.com> Date: Wed, 8 Oct 2008 08:08:46 -0700 (PDT) Cc: syslog mailing list , Internet Architecture Board , syslog chair , RFC Editor Subject: [Syslog] Protocol Action: 'TLS Transport Mapping for Syslog' to Proposed Standard 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org The IESG has approved the following document: - 'TLS Transport Mapping for Syslog ' as a Proposed Standard This document is the product of the Security Issues in Network Event Logging Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-14.txt Technical Summary This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. Working Group Summary There was controversy around the IPR statement from Huawei from this document. The Working Group examined the issue and came to consensus that the statement would be accepted. There was some controversy around the use of a special character to denote the end of the payload, or a counter at the start of the payload to indicate the length of the payload. The Working Group has consent that a counter is the best mechanism. There was also some controversy about the use of a dedicated port for this initial version of syslog over TLS. The consensus was that a dedicated port should be requested and that there should be no indication of version. The consequence of this is that any future change to the mapping of syslog over TLS, which is considered very unlikely, might require a different port number. This lack of a version number in the mapping of the application protocol to a transport is consistent in how syslog is mapped to UDP, and is also consistent with similar mappings of ISMS and netconf. Support for certificate fingerprint matching was added to address concerns from the ADs (Sam and Pasi) about deployability in small environments without a PKI. Other alternatives for providing "good enough" level of security without a PKI were discussed as well. Document Quality This protocol has very similar characteristics to implementations of syslog over SSL that are available at this time. Members of the Working Group have noted that it should be a very small change to bring those implementations in line with this specification. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. A group of university researchers have implemented this protocol and found that it is practicable. Another member of the WG has indicated that he is currently implementing the protocol as well. Personnel Chris Lonvick is the Document Shepherd; Pasi Eronen is the Responsible AD. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Oct 8 08:27:26 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6033A6BC0; Wed, 8 Oct 2008 08:27:26 -0700 (PDT) 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 BBF983A6BC0 for ; Wed, 8 Oct 2008 08:27:24 -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 O3hGeK5Ds499 for ; Wed, 8 Oct 2008 08:27:19 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DAE723A6784 for ; Wed, 8 Oct 2008 08:27:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,379,1220227200"; d="scan'208";a="22794418" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 08 Oct 2008 15:26:46 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m98FQkKB004655 for ; Wed, 8 Oct 2008 08:26:46 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m98FQkFs007175 for ; Wed, 8 Oct 2008 15:26:46 GMT Date: Wed, 8 Oct 2008 08:26:46 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3891; t=1223479606; x=1224343606; 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:=20Protocol=20Action=3A=20'TLS=20Transport=20Mappi ng=20for=20Syslog'=20to=20Proposed=0A=20Standard=20=20(fwd) |Sender:=20; bh=hhsbBxVCAaNL6ZZsOq/MFjZSpQVDpSpc9YA3LTPIWNc=; b=kqkGhJQK/m/XWNJ95JDTO4lttPbz2rHvmzOkCja0/Vfuh+Qe0U8ichziKG z9r47vde9vNPkfiNjHC2jx7AvrE6nuQTeiaXUy6zQehlEQxml5OykYJpY12W m3U16lju+6; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Syslog] Protocol Action: 'TLS Transport Mapping for Syslog' to Proposed Standard (fwd) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Folks, Pop the champagne corks. :-) This frees up draft-ietf-syslog-protocol draft-ietf-syslog-transport-udp so that all three can now become standards track RFCs. Our thanks to Rainer and Anton for being patient with those documents while we worked our way through -transport-tls. We now have one more item to complete in our charter: syslog-sign. We've gotten a list of review items back from Pasi, and Alex is now working on addressing those. Please review and comment on this when he gets proposals to the list. Many thanks, Chris ---------- Forwarded message ---------- Date: Wed, 8 Oct 2008 08:08:46 -0700 (PDT) From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , syslog mailing list , syslog chair Subject: Protocol Action: 'TLS Transport Mapping for Syslog' to Proposed Standard The IESG has approved the following document: - 'TLS Transport Mapping for Syslog ' as a Proposed Standard This document is the product of the Security Issues in Network Event Logging Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-14.txt Technical Summary This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. Working Group Summary There was controversy around the IPR statement from Huawei from this document. The Working Group examined the issue and came to consensus that the statement would be accepted. There was some controversy around the use of a special character to denote the end of the payload, or a counter at the start of the payload to indicate the length of the payload. The Working Group has consent that a counter is the best mechanism. There was also some controversy about the use of a dedicated port for this initial version of syslog over TLS. The consensus was that a dedicated port should be requested and that there should be no indication of version. The consequence of this is that any future change to the mapping of syslog over TLS, which is considered very unlikely, might require a different port number. This lack of a version number in the mapping of the application protocol to a transport is consistent in how syslog is mapped to UDP, and is also consistent with similar mappings of ISMS and netconf. Support for certificate fingerprint matching was added to address concerns from the ADs (Sam and Pasi) about deployability in small environments without a PKI. Other alternatives for providing "good enough" level of security without a PKI were discussed as well. Document Quality This protocol has very similar characteristics to implementations of syslog over SSL that are available at this time. Members of the Working Group have noted that it should be a very small change to bring those implementations in line with this specification. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. A group of university researchers have implemented this protocol and found that it is practicable. Another member of the WG has indicated that he is currently implementing the protocol as well. Personnel Chris Lonvick is the Document Shepherd; Pasi Eronen is the Responsible AD. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Oct 8 20:28:39 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E5B3A67FF; Wed, 8 Oct 2008 20:28:39 -0700 (PDT) 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 08C5C3A67FF for ; Wed, 8 Oct 2008 20:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 VnnnrqsmSkDA for ; Wed, 8 Oct 2008 20:28:37 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 619BC3A67AF for ; Wed, 8 Oct 2008 20:28:37 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id QTU51a00C0x6nqcA3TVLut; Thu, 09 Oct 2008 03:29:20 +0000 Received: from Harrington73653 ([208.253.76.35]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id QTUx1a0060lhtQY8YTVCNV; Thu, 09 Oct 2008 03:29:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=0m4JAqMaZaxhdYT44WsA:9 a=GjRc3HBlQZ-wKfx7mAukFc9C-ccA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=6bqG61NMjcsA:10 From: "David B Harrington" To: Date: Wed, 8 Oct 2008 23:28:55 -0400 Message-ID: <000d01c929bf$354a8ba0$efa911ac@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckpcBzl6RfKSa7BQI6KJ3Ps2bEzIw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] syslog/tls approved 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Congratulations to the WG, Syslog/TLS has been approved. Good work everyone. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Oct 10 05:36:42 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9904B3A685D; Fri, 10 Oct 2008 05:36:42 -0700 (PDT) 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 6C3A73A685D for ; Fri, 10 Oct 2008 05:36:41 -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 vZl4nACv1Y2z for ; Fri, 10 Oct 2008 05:36:40 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id A2FED3A684C for ; Fri, 10 Oct 2008 05:36:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 0A4F07AFF4E; Fri, 10 Oct 2008 14:33:15 +0200 (CEST) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E02rR4wvVkb; Fri, 10 Oct 2008 14:33:14 +0200 (CEST) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id C430C7AFF34; Fri, 10 Oct 2008 14:33:14 +0200 (CEST) Received: from [172.19.2.4] ([172.19.2.4]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Oct 2008 14:36:17 +0200 From: Rainer Gerhards To: David B Harrington In-Reply-To: <000d01c929bf$354a8ba0$efa911ac@china.huawei.com> References: <000d01c929bf$354a8ba0$efa911ac@china.huawei.com> Date: Fri, 10 Oct 2008 14:36:17 +0200 Message-Id: <1223642177.23821.9.camel@rgf9dev.intern.adiscon.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) X-OriginalArrivalTime: 10 Oct 2008 12:36:17.0957 (UTC) FILETIME=[CABCBD50:01C92AD4] Cc: syslog@ietf.org Subject: Re: [Syslog] syslog/tls approved 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi everyone, a bit late, but I would also like to thank everybody for their good work. And, as Chris suggested, I'll get myself involved with a small bottle over the weekend ;) Thanks again, Rainer On Wed, 2008-10-08 at 23:28 -0400, David B Harrington wrote: > Congratulations to the WG, Syslog/TLS has been approved. > Good work everyone. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Oct 14 18:24:12 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3819F3A6B18; Tue, 14 Oct 2008 18:24:12 -0700 (PDT) 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 0A4A528C1F4 for ; Tue, 14 Oct 2008 18:24:11 -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 mbf38CIDP9ds for ; Tue, 14 Oct 2008 18:24:09 -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 B7EA33A63EC for ; Tue, 14 Oct 2008 18:24:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,412,1220227200"; d="scan'208";a="91006099" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2008 01:25:06 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9F1P6XY011635; Tue, 14 Oct 2008 18:25:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9F1P6p7013253; Wed, 15 Oct 2008 01:25:06 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.1830); Tue, 14 Oct 2008 18:25:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 18:25:05 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0687E88A@xmb-sjc-236.amer.cisco.com> In-Reply-To: <45c8c21a0808111721h7619593lb2c6314de3a7bcf0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: RSA support? Thread-Index: Acj8EXYB1k92Pq6JSyuFXeMIGd1NXwyT8e2A References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org><48938517.9070002@mschuette.name><1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com><48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org><48A03553.3040509@mschuette.name> <45c8c21a0808111721h7619593lb2c6314de3a7bcf0@mail.gmail.com> From: "Alexander Clemm (alex)" To: "Richard Graveman" , "Jon Callas" X-OriginalArrivalTime: 15 Oct 2008 01:25:06.0660 (UTC) FILETIME=[DB3D3A40:01C92E64] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2425; t=1224033906; x=1224897906; c=relaxed/simple; s=sjdkim2002; 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=20[Syslog]=20Syslog-sign=3A=20RSA=20suppo rt? |Sender:=20; bh=3PEtoNvSLXL2nH2by+mOvl7F+u5DEeiHhaXjs/7pjGA=; b=crjxPs5hI0W0bDkDrK24LzyocElAlLsHmDGph83UW6w/TogYCAr9giwLQz jGyt08S9z5pog1RtRO38BWsC08px16OaKZnZcnUVZLxgkvNmsXryNo/vUlqz dBmYCr8Zdp; Authentication-Results: sj-dkim-2; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org What did we decide? Keep things as they are, or add optional support for R= SA per the text suggested by Martin? = I believe the consensus is to stick with DSA only; anything else would cons= titute an additional feature. = Thanks --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Richard Graveman Sent: Monday, August 11, 2008 5:22 PM To: Jon Callas Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? I agree with Jon on all counts. A good reason for the choice exists, the draft has been stable for years, no security issue is raised, keep it simple, and who wants to start discussing which of the three are MUST, SHOULD, or MAY? Richard Graveman On Mon, Aug 11, 2008 at 5:47 PM, Jon Callas wrote: > > On Aug 11, 2008, at 5:49 AM, Martin Sch=FCtte wrote: > >> Jon Callas schrieb: >>> >>> But that's what the existing consensus is. Do we have to, at this late >>> date, throw out the existing consensus and put in RSA and CAs? >> >> I think we can agree not to have any notion of CAs in syslog-sign, >> besides the simple fact that users of PKIX and OpenPGP keys might use one >> witout affecting syslog-sign. >> >> >> But what would be necessary to include RSA and ECDSA? As far as I see we >> just had to assign two additional VERsion digits values for the Signature >> Scheme. > > I agree that it's not all that difficult to add it in, but the draft has > gone this far with WG consensus that it is not needed. I don't think we c= an > add it without pulling it out of last call and re-opening it up. I might = be > wrong, but nonetheless, Pasi Eronen asked the question of why it was > DSA-only, and we answered. I don't believe we have to add in RSA. During > last call, ADs ask a number of good, tough questions that don't require > negating the WG consensus. And since the document in its present state is= a > product of WG consensus, we need a semblance of that to add in a major new > feature like a new public key algorithm. > > Jon > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Oct 14 18:30:33 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9C33A6784; Tue, 14 Oct 2008 18:30:33 -0700 (PDT) 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 6880C3A6784 for ; Tue, 14 Oct 2008 18:30:32 -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 foH4wzncUy87 for ; Tue, 14 Oct 2008 18:30:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B7C3E3A63EC for ; Tue, 14 Oct 2008 18:30:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,412,1220227200"; d="scan'208";a="49023233" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 Oct 2008 01:31:29 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9F1VTsq004936 for ; Tue, 14 Oct 2008 18:31:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9F1VTAx016490 for ; Wed, 15 Oct 2008 01:31:29 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 18:31:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 18:31:28 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0687E897@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Syslog-sign: versioning Thread-Index: AckuZb7dWc66ybHXTRi5A4melQItPQ== From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 15 Oct 2008 01:31:29.0511 (UTC) FILETIME=[BF6FA770:01C92E65] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=408; t=1224034289; x=1224898289; c=relaxed/simple; s=sjdkim4002; 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:=20Syslog-sign=3A=20versioning |Sender:=20; bh=ha2B7UXk6SXWpdUJVfgmFNTlpVyWnqRmUr+xm90uAQs=; b=OzEfYNQ2ICvdCWJfzN79lI132z8G7cKUscQzEN+7jZBRwC92Bj26jGj8Nf DUcnUaIKuBz5BjP1EO49kBdqUcfaflEpVkRIGZg7+QNKLbS3x2aB5rauv9Ol FvHKqtXOGm; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Syslog] Syslog-sign: versioning 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi, The question was raised as to whether it should be a requirement to allow for extensions of the SDEs used in syslog-sign. This concerns section 4.2.1. As it stands, extensions or modifications of the SDE will require revving up the version. Also, proprietary implementations can always add an additional proprietary SDE, which syslog-sign does not preclude. Objections/comments? --- Alex _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Oct 14 23:59:04 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091B228C198; Tue, 14 Oct 2008 23:59:04 -0700 (PDT) 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 C293A28C1A3 for ; Tue, 14 Oct 2008 23:59:02 -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 PjAgqWmq+DKJ for ; Tue, 14 Oct 2008 23:59:02 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id 204DA28C198 for ; Tue, 14 Oct 2008 23:59:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id E71822E076; Wed, 15 Oct 2008 00:03:28 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 43476-06; Wed, 15 Oct 2008 00:03:26 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id B669D2E06C; Wed, 15 Oct 2008 00:03:26 -0700 (PDT) Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Tue, 14 Oct 2008 23:00:49 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 14 Oct 2008 23:00:49 -0700 Message-Id: From: Jon Callas To: "Alexander Clemm (alex)" In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0687E88A@xmb-sjc-236.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 23:59:51 -0700 References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org><48938517.9070002@mschuette.name><1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com><48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org><48A03553.3040509@mschuette.name> <45c8c21a0808111721h7619593lb2c6314de3a7bcf0@mail.gmail.com> <85B2F271FDF6B949B3672BA5A7BB62FB0687E88A@xmb-sjc-236.amer.cisco.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: Maia Mailguard Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org On Oct 14, 2008, at 6:25 PM, Alexander Clemm (alex) wrote: > What did we decide? Keep things as they are, or add optional > support for RSA per the text suggested by Martin? > > I believe the consensus is to stick with DSA only; anything else > would constitute an additional feature. As do I. I am not opposed to the feature, it's just not something you put in after WGLC. Jon _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Oct 17 11:07:19 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DEF3A6AD9; Fri, 17 Oct 2008 11:07:19 -0700 (PDT) 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 D55F33A6AD9 for ; Fri, 17 Oct 2008 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 8okLu8yP+pGV for ; Fri, 17 Oct 2008 11:07:16 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B91FF3A67E9 for ; Fri, 17 Oct 2008 11:07:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,433,1220227200"; d="scan'208";a="49366073" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2008 18:08:21 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9HI8LNo024563; Fri, 17 Oct 2008 11:08:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m9HI8LsG003123; Fri, 17 Oct 2008 18:08:21 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 11:08:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 11:07:40 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0687F53D@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4897B3F6.9050705@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Multiple signers on host? Thread-Index: Acj2nuSbSZc/+/UkRWGsmmjO8PQlEA540bTA References: <1696498986EFEC4D9153717DA325CB72013502F1@vaebe104.NOE.Nokia.com><488C530F.3090101@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB0620D1BE@xmb-sjc-236.amer.cisco.com><489708E8.80400@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB062692A8@xmb-sjc-236.amer.cisco.com> <4897B3F6.9050705@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 17 Oct 2008 18:08:21.0448 (UTC) FILETIME=[56F47480:01C93083] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6019; t=1224266901; x=1225130901; 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=20[Syslog]=20Syslog-sign=3A=20Multiple=20 signers=20on=20host? |Sender:=20; bh=RtiQj8HY0nKr3XXi9JuVNFQsF+c3JnyQmV2bImxhGJU=; b=c0ijKJev340T7RmsS2aOHUXlJf7OF4NPFimysvBZ/Naff3uOjagRrKBOmM 4GdapagePUsWkvOKxG96d8Awvia9fw0LnASS55ZxY7soW0ilCTd2Tbg9Lw+Y W9GBYmas4E; Authentication-Results: sj-dkim-3; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org There is one additional aspect, concerning consistency of APP-NAME and PROC= ID between Signature Block and = Certificate Block messages. There is currently no statement regarding this,= although I believe it makes sense. = I am putting the following text - please let me know if there are objection= s: In section 5.3.1 (on Certification Block messages): Syslog-sign does not mandate particular values for these fields; howe= ver, = for consistency, implementations MUST use the = same value for APP-NAME, PROCID, and MSGID fields for = every Certificate Block message, whichever values are chosen. = To allow for the possibility of multiple originators per host, = the combination of APP-NAME, PROCID, and MSGID MUST be unique for each= such originator. = If an originator daemon is restarted, it MAY use a new PROCID for what= is otherwise the = same originator. The combination of APP-NAME and PROCID MUST = be the same that is used for Signature Block messages of the same orig= inator; however, a different MSGID MAY be used. = In section 4.1: (on Signature Block messages): = This specification does not mandate particular values for these fields;= however, = for consistency, originators MUST use the = same values for APP-NAME, PROCID, and MSGID fields for = every Signature Block message that is sent, whichever values are chosen= . = To allow for the possibility of multiple originators per host, = the combination of APP-NAME, PROCID, and MSGID MUST be unique for each = such originator. = If an originator daemon is restarted, it MAY use a new PROCID for what = is otherwise the = same originator. = In section 4.2.2 (on reboot sessions): If a reboot of an originator takes place, Signature Block messages MAY= use a new PROCID. = However, Signature Block messages of the same originator MUST continue= to use the = same APP-NAME and MSGID, in order = to prevent collectors from mistaking the originator. = --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Monday, August 04, 2008 6:59 PM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? Alexander Clemm (alex) schrieb: > It is possible to differentiate different signers by saying APP-NAME > and PROCID are relevant and MUST be used consistently. It would then > also imply that different signers can "reuse" the same SPRI, > providing they indicate SG=3D3 when establishing the signature group. Different signers can also use the same SG. Otherwise it would be = impossible to have a central log server for many clients (=3Dsigners) ;) > Not sure if it was intentional, but you bring up a notion of a > duration of a signature group. This is a different notion than what > we have right now. We only have a notion of a reboot session. At > the beginning of the reboot session, the payload blocks are sent for > the various signature groups. So, the duration is "global" for an > originator, not differentiated between signature groups. Now, in > principle it is certainly possible to change the semantics of "reboot > session" to that of "signature group session". It does open up a lot > of other questions and add complexity, as now a multitude of reboot > sessions needs to be kept track of. Is this really required? It > would seem that we should stick to the simple semantics of reboot > session. Different signers can of course have their own reboot It was unintentional. From the perspective of the originator I implicitly assumed the RSID is = a global state and a "reboot event" affects all signature groups. But now that I think of it I do not see that it makes a big difference = whether "signature group session" were allowed. The sender can use whatever it wants, so the focus has to be on the = receiver/verifier and the protocol has to limit its complexity. Our receiver already has to process different message streams, keep = track of multiple signature groups from different originators, check = every signature block's attributes for validity, and recognize new = reboot sessions from a sender. Now what constraints do we have when we have when assuming a = "sender-global" reboot session? And which constraints disappear when we = allow "signature group sessions"? I see only the difference between a) finding the signature group and = comparing the RSID and b) using the RSID as part of the identifier to = find the signature group. That certainly does not change the overall = complexity. --- Just to make my position clear: I think a "sender-global" reboot session = is just fine; I do not see a serious use case for "signature group = sessions" and have no intent to 'push' this into the standard. But on the other hand I do not I do not see a reason to limit the = possible options without an apparent reason. --- With regard to the notion of a reboot session I would like to revise my = previous definition of signature group identifiers to use a more = hierarchical approach: ORIGINATOR :=3D (HOSTNAME, APP-NAME, PROCID) REBOOT_SESSION :=3D (ORIGINATOR, VER, RSID) signature group :=3D (REBOOT_SESSION, SG, SPRI) Is that closer to your conception? I am only a bit undecided whether VER identifies a REBOOT_SESSION or a = signature group inside the REBOOT_SESSION. > sessions. So, your text is basically okay, but I would argue that > the last sentence must read "To allow multiple originators per host, > the values of APP-NAME and PROCID MUST be unique for the duration of > the reboot session." That's fine with me. -- = Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog