From syslog-bounces@ietf.org Fri May 2 08:56:48 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E933A6C98; Fri, 2 May 2008 08:56:48 -0700 (PDT) X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E5CF43A6AA1; Fri, 2 May 2008 08:56:47 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080502155647.E5CF43A6AA1@core3.amsl.com> Date: Fri, 2 May 2008 08:56:47 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] Last Call: draft-ietf-syslog-tc-mib (Textual Conventions for Syslog Management) to Proposed Standard X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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 received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following document: - 'Textual Conventions for Syslog Management ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-05-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16034&rfc_flag=0 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 2 09:12:45 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F8F3A6890; Fri, 2 May 2008 09:12:45 -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 75E823A6890 for ; Fri, 2 May 2008 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 aWUNPSC2g56J for ; Fri, 2 May 2008 09:12:43 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id A2A8B3A6882 for ; Fri, 2 May 2008 09:12:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id D9C907AE0D2 for ; Fri, 2 May 2008 18:11:25 +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 ndraZce3MuS2 for ; Fri, 2 May 2008 18:11:25 +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 A4ED37AE0B1 for ; Fri, 2 May 2008 18:11:25 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 May 2008 18:12:42 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transport-tls status - has it died? Thread-Index: Acisb1m2BNVikvxwQMG6YXaM3rw0jg== From: "Rainer Gerhards" To: Subject: [Syslog] transport-tls status - has it died? 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 Chris and David, I notice that -transport-tls will expire by May, 20th. I also notice that nobody yet has acted on mailing list comments (at least not mine, some unacceptable text is still in it). Could you please tell us what the status of this draft is and if it is expected to be updated and brought to the IESG (after all, everything else is waiting in queue for it...). Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 2 09:26:35 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C3328C249; Fri, 2 May 2008 09:26:35 -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 6B1203A6A19 for ; Fri, 2 May 2008 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 ykhTGy8HwphH for ; Fri, 2 May 2008 09:26:34 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 8237628C249 for ; Fri, 2 May 2008 09:26:34 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id LfLa1Z00317dt5G5508a00; Fri, 02 May 2008 16:26:13 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.westchester.pa.mail.comcast.net with comcast id LgSa1Z00D4HwxpC3Z00000; Fri, 02 May 2008 16:26:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=rNloaRmgNmwA:10 a=YhnHCFd2TpwA:10 a=48vgC7mUAAAA:8 a=6UmeXDXnu1vkY6_AoLYA:9 a=nzS2eNagGVXL1MmiK2wA:7 a=ucF9JCJny2Xozj1geHpjPulRu6UA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Rainer Gerhards'" , References: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com> Date: Fri, 2 May 2008 12:26:34 -0400 Message-ID: <00a201c8ac71$49dfba20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com> Thread-Index: Acisb1m2BNVikvxwQMG6YXaM3rw0jgAAYcdQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Syslog] transport-tls status - has it died? 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 -tls- draft is in AD Evaluation. It won't expire while in that state. Miao's day job prevented him from continuing to edit. The chairs have gotten a new co-editor for the document (Joe Saloway). A new revision has been prepared and is being reviewed by the chairs and ADs. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Friday, May 02, 2008 12:13 PM > To: syslog@ietf.org > Subject: [Syslog] transport-tls status - has it died? > > Hi Chris and David, > > I notice that -transport-tls will expire by May, 20th. I also notice > that nobody yet has acted on mailing list comments (at least not mine, > some unacceptable text is still in it). > > Could you please tell us what the status of this draft is and if it is > expected to be updated and brought to the IESG (after all, everything > else is waiting in queue for it...). > > Thanks, > Rainer > _______________________________________________ > 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 Fri May 2 11:25:10 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96EF3A6E2C; Fri, 2 May 2008 11:25:10 -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 C33703A69C7 for ; Fri, 2 May 2008 11:25:09 -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 ndqVooinxLjH for ; Fri, 2 May 2008 11:25:08 -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 C5F503A6E2D for ; Fri, 2 May 2008 11:23:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,428,1204531200"; d="scan'208";a="12563769" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 May 2008 11:23:30 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m42INUFA029474; Fri, 2 May 2008 11:23:30 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m42INUI1023196; Fri, 2 May 2008 18:23:30 GMT Date: Fri, 2 May 2008 11:23:30 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org In-Reply-To: <00a201c8ac71$49dfba20$0600a8c0@china.huawei.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com> <00a201c8ac71$49dfba20$0600a8c0@china.huawei.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2155; t=1209752610; x=1210616610; c=relaxed/simple; s=sjdkim1004; 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]=20transport-tls=20status=20-=2 0has=20it=20died? |Sender:=20; bh=PhKEgnrbY/3caELTASiiiSal3nFoZ7TgAN6pdlUFNmQ=; b=PwWeFTelDhSUeyvNPViHPW1gB5gSQBOPcDGsMwNhgcYsGMXdDR9X6/vNJh LIoU18QvdOWsOIeQh3/rlb+nIogDH5Ey0hamem/9pGc39AgrAk2zQ+VTqE/J 1M1ErkHbJFYMZF3SmoUGOjYuXRYIDSwzwpZViMK1qLrfYYPxE9JEI=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] transport-tls status - has it died? 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 Folks, Apologies for not updating everyone about this sooner. draft-ietf-syslog-protocol and draft-ietf-syslog-transport-udp have been accepted by the IESG and are being held up by draft-ietf-syslog-transport-tls. Our thanks to Miao and Yuzhi for getting that document to this stage. Like David says, Joe is addressing the IESG comments and the WG discussion items. We hope to have a new draft out for WG review soon. David has shepherded draft-ietf-syslog-tc-mib to IETF Last Call. Everyone should have seen that announcement go out earlier today. Please review and send in comments. You can find the status of all of our work through datatracker: https://datatracker.ietf.org/idtracker/ Best regards everyone and have a good weekend, Chris On Fri, 2 May 2008, David Harrington wrote: > Hi, > > The -tls- draft is in AD Evaluation. It won't expire while in that > state. > Miao's day job prevented him from continuing to edit. > The chairs have gotten a new co-editor for the document (Joe Saloway). > A new revision has been prepared and is being reviewed by the chairs > and ADs. > > dbh > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards >> Sent: Friday, May 02, 2008 12:13 PM >> To: syslog@ietf.org >> Subject: [Syslog] transport-tls status - has it died? >> >> Hi Chris and David, >> >> I notice that -transport-tls will expire by May, 20th. I also notice >> that nobody yet has acted on mailing list comments (at least not > mine, >> some unacceptable text is still in it). >> >> Could you please tell us what the status of this draft is and if it > is >> expected to be updated and brought to the IESG (after all, > everything >> else is waiting in queue for it...). >> >> Thanks, >> Rainer >> _______________________________________________ >> 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 Sat May 3 01:26:51 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D46D3A6853; Sat, 3 May 2008 01:26:51 -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 30B343A691A for ; Sat, 3 May 2008 01:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 94OvpQKEYyBP for ; Sat, 3 May 2008 01:26:49 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 9F7053A683A for ; Sat, 3 May 2008 01:26:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id F30207AE1B7 for ; Sat, 3 May 2008 10:25:38 +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 7qoloOEn-jYe for ; Sat, 3 May 2008 10:25:38 +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 ACC697ADFB1 for ; Sat, 3 May 2008 10:25:38 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 3 May 2008 10:26:45 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F3B@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] transport-tls status - has it died? Thread-Index: AcisgaZY46bUnOUWSmOhiaGfPTmHeQAdPu7A References: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com> <00a201c8ac71$49dfba20$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: Subject: Re: [Syslog] transport-tls status - has it died? 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 again, thanks for the update. Just let me tell why I am curios: after waiting for quite a while, I could no longer hold implementation of syslog/TLS in rsyslog [ http://www.rsyslog.com ]. I started roughly a month ago with the TLS bits (the framing is in rsyslog since long, at least well over a year). I have now basically finished it and will release the first version with TLS support most probably on Monday. The first version will address only the basic needs. I started to look at transport-tls yesterday to see what else I need to implement. Obviously, that wasn't that helpful. Anyhow, I am in the need to implement. I would really appreciate if we could see an update ASAP. I also know about at least one other project who is also implementing syslog-tls. Once I have finished all details, it will become quite hard to change things in a way that keeps compatibility. My project will be flagged experimental for roughly 4 to 8 weeks, thereafter I run into that problem. I don't know of the other project. Of course, that is primarily my problem, but I find it quite unfortunate if we end up with multiple incompatible implementations after all that works ... but that's the way it currently looks like... Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, May 02, 2008 8:24 PM > To: syslog@ietf.org > Cc: Rainer Gerhards; David Harrington > Subject: Re: [Syslog] transport-tls status - has it died? > > Hi Folks, > > Apologies for not updating everyone about this sooner. > > draft-ietf-syslog-protocol and draft-ietf-syslog-transport-udp have > been > accepted by the IESG and are being held up by > draft-ietf-syslog-transport-tls. Our thanks to Miao and Yuzhi for > getting > that document to this stage. Like David says, Joe is addressing the > IESG > comments and the WG discussion items. We hope to have a new draft out > for > WG review soon. > > David has shepherded draft-ietf-syslog-tc-mib to IETF Last Call. > Everyone > should have seen that announcement go out earlier today. Please review > and send in comments. > > You can find the status of all of our work through datatracker: > https://datatracker.ietf.org/idtracker/ > > Best regards everyone and have a good weekend, > Chris > > On Fri, 2 May 2008, David Harrington wrote: > > > Hi, > > > > The -tls- draft is in AD Evaluation. It won't expire while in that > > state. > > Miao's day job prevented him from continuing to edit. > > The chairs have gotten a new co-editor for the document (Joe > Saloway). > > A new revision has been prepared and is being reviewed by the chairs > > and ADs. > > > > dbh > > > >> -----Original Message----- > >> From: syslog-bounces@ietf.org > >> [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > >> Sent: Friday, May 02, 2008 12:13 PM > >> To: syslog@ietf.org > >> Subject: [Syslog] transport-tls status - has it died? > >> > >> Hi Chris and David, > >> > >> I notice that -transport-tls will expire by May, 20th. I also notice > >> that nobody yet has acted on mailing list comments (at least not > > mine, > >> some unacceptable text is still in it). > >> > >> Could you please tell us what the status of this draft is and if it > > is > >> expected to be updated and brought to the IESG (after all, > > everything > >> else is waiting in queue for it...). > >> > >> Thanks, > >> Rainer > >> _______________________________________________ > >> 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 Mon May 5 17:53:15 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C4D3A6ECF; Mon, 5 May 2008 17:53:15 -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 E213C28C0F3 for ; Mon, 5 May 2008 17:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 FuLUdk5UVN4E for ; Mon, 5 May 2008 17:53:14 -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 04FAE3A6870 for ; Mon, 5 May 2008 17:53:14 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 May 2008 17:53:12 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m460rCT7017280 for ; Mon, 5 May 2008 17:53:12 -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 m460rCM3021522 for ; Tue, 6 May 2008 00:53:13 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); Mon, 5 May 2008 17:53:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 May 2008 17:53:12 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB05A66BA6@xmb-sjc-236.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] transport-tls status - has it died? Thread-Index: AcisgelnT5on1oI8RLqtQK2JjqskMQCkWezg References: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com><00a201c8ac71$49dfba20$0600a8c0@china.huawei.com> From: "Alexander Clemm (alex)" To: "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 06 May 2008 00:53:12.0750 (UTC) FILETIME=[8F8A3CE0:01C8AF13] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2589; t=1210035192; x=1210899192; 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:=20RE=3A=20[Syslog]=20transport-tls=20status=20-=2 0has=20it=20died? |Sender:=20; bh=qso1Jn15sBjeDnb9E9SCEht8ISslT/8COzPIWc7BR+E=; b=bYPsyxJM5gx3tZ/WKu+uHvZ1IAjm2RrncfWBAGdWVPxX6OXyJzrA199wfx plZwctVxa18TO4pzkoac33GEXB5MjI8ltcS8MsMNq9rSlKPbZt/MwUy3u4nG UChQVDGG2A; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] transport-tls status - has it died? 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 What about draft-ietf-syslog-sign? --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Chris Lonvick (clonvick) Sent: Friday, May 02, 2008 11:24 AM To: syslog@ietf.org Subject: Re: [Syslog] transport-tls status - has it died? Hi Folks, Apologies for not updating everyone about this sooner. draft-ietf-syslog-protocol and draft-ietf-syslog-transport-udp have been accepted by the IESG and are being held up by draft-ietf-syslog-transport-tls. Our thanks to Miao and Yuzhi for getting that document to this stage. Like David says, Joe is addressing the IESG comments and the WG discussion items. We hope to have a new draft out for WG review soon. David has shepherded draft-ietf-syslog-tc-mib to IETF Last Call. Everyone should have seen that announcement go out earlier today. Please review and send in comments. You can find the status of all of our work through datatracker: https://datatracker.ietf.org/idtracker/ Best regards everyone and have a good weekend, Chris On Fri, 2 May 2008, David Harrington wrote: > Hi, > > The -tls- draft is in AD Evaluation. It won't expire while in that > state. > Miao's day job prevented him from continuing to edit. > The chairs have gotten a new co-editor for the document (Joe Saloway). > A new revision has been prepared and is being reviewed by the chairs > and ADs. > > dbh > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards >> Sent: Friday, May 02, 2008 12:13 PM >> To: syslog@ietf.org >> Subject: [Syslog] transport-tls status - has it died? >> >> Hi Chris and David, >> >> I notice that -transport-tls will expire by May, 20th. I also notice >> that nobody yet has acted on mailing list comments (at least not > mine, >> some unacceptable text is still in it). >> >> Could you please tell us what the status of this draft is and if it > is >> expected to be updated and brought to the IESG (after all, > everything >> else is waiting in queue for it...). >> >> Thanks, >> Rainer >> _______________________________________________ >> 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 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 5 23:39:25 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF2028C3BC; Mon, 5 May 2008 23:39:24 -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 E882F3A6A96 for ; Mon, 5 May 2008 23:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 iGKSLNmcje1C for ; Mon, 5 May 2008 23:39:14 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id CD55E28C351 for ; Mon, 5 May 2008 23:39:14 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id N30n1Z0010QkzPwA70K200; Tue, 06 May 2008 06:38:57 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id N6fB1Z0074HwxpC8N00000; Tue, 06 May 2008 06:39:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=G7RtTPnZw4sA:10 a=YhnHCFd2TpwA:10 a=48vgC7mUAAAA:8 a=_rjn9DyZAnsdgQ4JmnkA:9 a=vjJNJY3s0FfZ_wU4brsA:7 a=22rab-ZmW4tj_TOb74z_JEiJrQ8A:4 a=lZB815dzVvQA:10 a=HOt-SvZ3x1UA:10 From: "David Harrington" To: "'Alexander Clemm \(alex\)'" , "'Chris Lonvick \(clonvick\)'" , References: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com><00a201c8ac71$49dfba20$0600a8c0@china.huawei.com> <85B2F271FDF6B949B3672BA5A7BB62FB05A66BA6@xmb-sjc-236.amer.cisco.com> Date: Tue, 6 May 2008 02:39:13 -0400 Message-ID: <029501c8af43$e6bc2a20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB05A66BA6@xmb-sjc-236.amer.cisco.com> Thread-Index: AcisgelnT5on1oI8RLqtQK2JjqskMQCkWezgAAwUR6A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Syslog] transport-tls status - has it died? 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 syslog-sign has a dependency on syslog-tls, so we need to resolve syslog-tls before we can advance syslog-sign. syslog-sign is sitting patiently in the queue to be processed ;-) dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) > Sent: Monday, May 05, 2008 8:53 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: Re: [Syslog] transport-tls status - has it died? > > What about draft-ietf-syslog-sign? > --- Alex > > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf > Of Chris Lonvick (clonvick) > Sent: Friday, May 02, 2008 11:24 AM > To: syslog@ietf.org > Subject: Re: [Syslog] transport-tls status - has it died? > > Hi Folks, > > Apologies for not updating everyone about this sooner. > > draft-ietf-syslog-protocol and > draft-ietf-syslog-transport-udp have been > accepted by the IESG and are being held up by > draft-ietf-syslog-transport-tls. Our thanks to Miao and Yuzhi for > getting that document to this stage. Like David says, Joe is > addressing > the IESG comments and the WG discussion items. We hope to have a new > draft out for WG review soon. > > David has shepherded draft-ietf-syslog-tc-mib to IETF Last Call. > Everyone should have seen that announcement go out earlier today. > Please review and send in comments. > > You can find the status of all of our work through datatracker: > https://datatracker.ietf.org/idtracker/ > > Best regards everyone and have a good weekend, Chris > > On Fri, 2 May 2008, David Harrington wrote: > > > Hi, > > > > The -tls- draft is in AD Evaluation. It won't expire while in that > > state. > > Miao's day job prevented him from continuing to edit. > > The chairs have gotten a new co-editor for the document > (Joe Saloway). > > A new revision has been prepared and is being reviewed by > the chairs > > and ADs. > > > > dbh > > > >> -----Original Message----- > >> From: syslog-bounces@ietf.org > >> [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > >> Sent: Friday, May 02, 2008 12:13 PM > >> To: syslog@ietf.org > >> Subject: [Syslog] transport-tls status - has it died? > >> > >> Hi Chris and David, > >> > >> I notice that -transport-tls will expire by May, 20th. I > also notice > >> that nobody yet has acted on mailing list comments (at least not > > mine, > >> some unacceptable text is still in it). > >> > >> Could you please tell us what the status of this draft is and if it > > is > >> expected to be updated and brought to the IESG (after all, > > everything > >> else is waiting in queue for it...). > >> > >> Thanks, > >> Rainer > >> _______________________________________________ > >> 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 > _______________________________________________ > 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 May 6 05:30:46 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6E328C1B9; Tue, 6 May 2008 05:30:46 -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 84FC33A6DD2 for ; Tue, 6 May 2008 05:30:45 -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 JKsPRGVAkQdq for ; Tue, 6 May 2008 05:30:44 -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 5768B3A6DCF for ; Tue, 6 May 2008 05:30:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,443,1204531200"; d="scan'208";a="25412768" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 06 May 2008 05:30:32 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m46CUWwL028401; Tue, 6 May 2008 05:30:32 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m46CUWDq018139; Tue, 6 May 2008 12:30:32 GMT Date: Tue, 6 May 2008 05:30:32 -0700 (PDT) From: Chris Lonvick To: Alexander Clemm In-Reply-To: <029501c8af43$e6bc2a20$0600a8c0@china.huawei.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com><00a201c8ac71$49dfba20$0600a8c0@china.huawei.com> <85B2F271FDF6B949B3672BA5A7BB62FB05A66BA6@xmb-sjc-236.amer.cisco.com> <029501c8af43$e6bc2a20$0600a8c0@china.huawei.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3617; t=1210077032; x=1210941032; c=relaxed/simple; s=sjdkim1004; 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]=20transport-tls=20status=20-=2 0has=20it=20died? |Sender:=20; bh=XQYdnBIznPyjZsqg4zaMolxXR/6ducRVCrCoURKJvOM=; b=YpynAv6l/gU/RoOgsJ8amobW/Lw2TPxqkeB7PjsCRqleHmxn76dYQqjlGY fz/WAuP/uGicX2umA75OwGC0Fr+j4gJ4AComJ6p8odW5iEoTYUxgFt9cCtMR W5EiWe+HaKk83OI/TB/55fe9SL/NOnNwZwQcO0/fjWw0KSQlO4+i4=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] transport-tls status - has it died? 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, You can see the status of all WG and related documents here: http://tools.ietf.org/wg/syslog/ Thanks, Chris On Tue, 6 May 2008, David Harrington wrote: > syslog-sign has a dependency on syslog-tls, so we need to resolve > syslog-tls before we can advance syslog-sign. syslog-sign is sitting > patiently in the queue to be processed ;-) > > dbh > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) >> Sent: Monday, May 05, 2008 8:53 PM >> To: Chris Lonvick (clonvick); syslog@ietf.org >> Subject: Re: [Syslog] transport-tls status - has it died? >> >> What about draft-ietf-syslog-sign? >> --- Alex >> >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf >> Of Chris Lonvick (clonvick) >> Sent: Friday, May 02, 2008 11:24 AM >> To: syslog@ietf.org >> Subject: Re: [Syslog] transport-tls status - has it died? >> >> Hi Folks, >> >> Apologies for not updating everyone about this sooner. >> >> draft-ietf-syslog-protocol and >> draft-ietf-syslog-transport-udp have been >> accepted by the IESG and are being held up by >> draft-ietf-syslog-transport-tls. Our thanks to Miao and Yuzhi for >> getting that document to this stage. Like David says, Joe is >> addressing >> the IESG comments and the WG discussion items. We hope to have a > new >> draft out for WG review soon. >> >> David has shepherded draft-ietf-syslog-tc-mib to IETF Last Call. >> Everyone should have seen that announcement go out earlier today. >> Please review and send in comments. >> >> You can find the status of all of our work through datatracker: >> https://datatracker.ietf.org/idtracker/ >> >> Best regards everyone and have a good weekend, Chris >> >> On Fri, 2 May 2008, David Harrington wrote: >> >>> Hi, >>> >>> The -tls- draft is in AD Evaluation. It won't expire while in that > >>> state. >>> Miao's day job prevented him from continuing to edit. >>> The chairs have gotten a new co-editor for the document >> (Joe Saloway). >>> A new revision has been prepared and is being reviewed by >> the chairs >>> and ADs. >>> >>> dbh >>> >>>> -----Original Message----- >>>> From: syslog-bounces@ietf.org >>>> [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards >>>> Sent: Friday, May 02, 2008 12:13 PM >>>> To: syslog@ietf.org >>>> Subject: [Syslog] transport-tls status - has it died? >>>> >>>> Hi Chris and David, >>>> >>>> I notice that -transport-tls will expire by May, 20th. I >> also notice >>>> that nobody yet has acted on mailing list comments (at least not >>> mine, >>>> some unacceptable text is still in it). >>>> >>>> Could you please tell us what the status of this draft is and if > it >>> is >>>> expected to be updated and brought to the IESG (after all, >>> everything >>>> else is waiting in queue for it...). >>>> >>>> Thanks, >>>> Rainer >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 May 6 05:38:32 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A043A6C59; Tue, 6 May 2008 05:38:32 -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 D37733A6E40 for ; Tue, 6 May 2008 05:38:27 -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 DSfBq-m3C-IM for ; Tue, 6 May 2008 05:38:24 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 533D628C3E8 for ; Tue, 6 May 2008 05:37:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 3B7A17AE5E5 for ; Tue, 6 May 2008 14:34:45 +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 AavUH5uNTJjR for ; Tue, 6 May 2008 14:34:45 +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 055877AE5E1 for ; Tue, 6 May 2008 14:34:44 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 6 May 2008 14:37:50 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F62@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls, section 4.2 Thread-Index: Acivdf76lZhV7DgWQq6X0iut3++4HA== From: "Rainer Gerhards" To: Subject: [Syslog] -transport-tls, section 4.2 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 there, I have today released a basic version of rsyslog with an experimental first -transport-tls implementation (announcement at http://www.rsyslog.com/Article222.phtml ). I am now digging deeper and refining the implementation. I try to convey some thoughts and ask some questions along this route - in the hopes to gather some feedback. The initial feedback is that it is quite trivial to implement -transport-tls - just as anticipated. But I think it is good to see it works out in practice. My first question is on section 4.2. It does not tell what to do if the TLS handshake fails. One can argue that the second sentence implies that the connection should be dropped on handshake failure. However, this is not explicitly stated. It may be desirable to continue without TLS in that case. When GSSAPI support was implemented in rsyslog, there was a strong community demand for such a fallback mode. Thus, if the GSSAPI handshake fails, and rsyslog is configured accordingly, it falls back to plain TCP syslog (unencrypted). I know this is dangerous, as a man in the middle may force unencrypted transfer in this case. But provided it is an operator-selectable option (and by default off), I think it is an acceptable risk. Question now: how to handle this in spite of -transport-tls? With the current text, would my application compliant to it if it permits to run without TLS support when the handshake fails (in that case obviously not complying to any standard)? I would suggest that this case is being at least mentioned. I would also like to hear some opinions on this topic. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue May 6 06:16:17 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED23628C13A; Tue, 6 May 2008 06:16:16 -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 DEC363A6AA6 for ; Tue, 6 May 2008 06:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-1.818, BAYES_00=-2.599, DC_GIF_UNO_LARGO=2.275, SARE_GIF_ATTACH=1.42] 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 iO80mK5E3ZFB for ; Tue, 6 May 2008 06:08:32 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id B0D8828C1B6 for ; Tue, 6 May 2008 06:08:32 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id NB2Z1Z0081HpZEsA40Ch00; Tue, 06 May 2008 13:08:27 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id ND8S1Z00D4HwxpC8a00000; Tue, 06 May 2008 13:08:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=9CipugyNLtRWfaE4UTkA:9 a=exI_WzE___8wq5tXbiIA:7 a=NWqLe1uALsS2Lyxb8ZC7D8BKkoMA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=tHBMZQXl4ncc2IApK8EA:9 a=uk9E3mWjRYNDS0eXD7DFaTPGqGQA:4 a=CxA2Utj4LuEA:10 a=1Vq_FK4TplAA:10 a=3XJj1cQqCS7ExCSD4MgA:9 a=SygbLF9c_e_CLpvI:18 a=EMK0vftzXiAfPC7E:18 a=Qs8kbmlDcxqIuRYX:18 From: "David Harrington" To: "'Chris Lonvick'" , "'Alexander Clemm'" References: <577465F99B41C842AAFBE9ED71E70ABA308F3A@grfint2.intern.adiscon.com><00a201c8ac71$49dfba20$0600a8c0@china.huawei.com><85B2F271FDF6B949B3672BA5A7BB62FB05A66BA6@xmb-sjc-236.amer.cisco.com><029501c8af43$e6bc2a20$0600a8c0@china.huawei.com> Date: Tue, 6 May 2008 09:08:26 -0400 Message-ID: <029c01c8af7a$46a21f40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_029D_01C8AF58.BF907F40" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcivdQUAvM4G7UcaT1C4uzU8WvkN9QAAnu9g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailman-Approved-At: Tue, 06 May 2008 06:16:15 -0700 Cc: syslog@ietf.org Subject: [Syslog] document status 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 This is a multi-part message in MIME format. ------=_NextPart_000_029D_01C8AF58.BF907F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, To help you understand the status of the drafts, you should definitely look at http://tools.ietf.org/wg/syslog/ as Chris said. To understand the status column, see https://datatracker.ietf.org/images/state_diagram.gif. This is the IETF state diagram. (I also attached it to this email.) The WG is primarily involved in getting an ID to be good enough to move from the upper left hand corner (ID exists) to (Publication Requested). This is the point at which a WG asks that it be published as an RFC. At the bottom of http://tools.ietf.org/wg/syslog/ is a link to a dependency graph showing how our documents relate to each other. In general, a draft cannot advance in the standards track unless the drafts it depends on also have advanced to the same or higher level, so drafts depending on syslog-tls cannot advance until syslog-tls advances. The graph also shows other drafts being worked on related to syslog; they might interest you if you have not seen them yet, and you might want to get involved in those documents or develop your own drafts. Hope this helps, dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Chris Lonvick > Sent: Tuesday, May 06, 2008 8:31 AM > To: Alexander Clemm > Cc: syslog@ietf.org > Subject: Re: [Syslog] transport-tls status - has it died? > > Hi, > > You can see the status of all WG and related documents here: > http://tools.ietf.org/wg/syslog/ > > Thanks, > Chris > > On Tue, 6 May 2008, David Harrington wrote: > > > syslog-sign has a dependency on syslog-tls, so we need to resolve > > syslog-tls before we can advance syslog-sign. syslog-sign is sitting > > patiently in the queue to be processed ;-) > > > > dbh > > > >> -----Original Message----- > >> From: syslog-bounces@ietf.org > >> [mailto:syslog-bounces@ietf.org] On Behalf Of Alexander > Clemm (alex) > >> Sent: Monday, May 05, 2008 8:53 PM > >> To: Chris Lonvick (clonvick); syslog@ietf.org > >> Subject: Re: [Syslog] transport-tls status - has it died? > >> > >> What about draft-ietf-syslog-sign? > >> --- Alex > >> > >> -----Original Message----- > >> From: syslog-bounces@ietf.org > >> [mailto:syslog-bounces@ietf.org] On Behalf > >> Of Chris Lonvick (clonvick) > >> Sent: Friday, May 02, 2008 11:24 AM > >> To: syslog@ietf.org > >> Subject: Re: [Syslog] transport-tls status - has it died? > >> > >> Hi Folks, > >> > >> Apologies for not updating everyone about this sooner. > >> > >> draft-ietf-syslog-protocol and > >> draft-ietf-syslog-transport-udp have been > >> accepted by the IESG and are being held up by > >> draft-ietf-syslog-transport-tls. Our thanks to Miao and Yuzhi for > >> getting that document to this stage. Like David says, Joe is > >> addressing > >> the IESG comments and the WG discussion items. We hope to have a > > new > >> draft out for WG review soon. > >> > >> David has shepherded draft-ietf-syslog-tc-mib to IETF Last Call. > >> Everyone should have seen that announcement go out earlier today. > >> Please review and send in comments. > >> > >> You can find the status of all of our work through datatracker: > >> https://datatracker.ietf.org/idtracker/ > >> > >> Best regards everyone and have a good weekend, Chris > >> > >> On Fri, 2 May 2008, David Harrington wrote: > >> > >>> Hi, > >>> > >>> The -tls- draft is in AD Evaluation. It won't expire while in that > > > >>> state. > >>> Miao's day job prevented him from continuing to edit. > >>> The chairs have gotten a new co-editor for the document > >> (Joe Saloway). > >>> A new revision has been prepared and is being reviewed by > >> the chairs > >>> and ADs. > >>> > >>> dbh > >>> > >>>> -----Original Message----- > >>>> From: syslog-bounces@ietf.org > >>>> [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > >>>> Sent: Friday, May 02, 2008 12:13 PM > >>>> To: syslog@ietf.org > >>>> Subject: [Syslog] transport-tls status - has it died? > >>>> > >>>> Hi Chris and David, > >>>> > >>>> I notice that -transport-tls will expire by May, 20th. I > >> also notice > >>>> that nobody yet has acted on mailing list comments (at least not > >>> mine, > >>>> some unacceptable text is still in it). > >>>> > >>>> Could you please tell us what the status of this draft is and if > > it > >>> is > >>>> expected to be updated and brought to the IESG (after all, > >>> everything > >>>> else is waiting in queue for it...). > >>>> > >>>> Thanks, > >>>> Rainer > >>>> _______________________________________________ > >>>> 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 > >> _______________________________________________ > >> 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 > ------=_NextPart_000_029D_01C8AF58.BF907F40 Content-Type: image/gif; name="ietf_state_diagram.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ietf_state_diagram.gif" R0lGODlhWALCAfcAMf/////3//f39/f33vfv1vfvxvfn7/fn5/fnrffnnPfe1vfOrffOnO/3/+/n ve/ete/GhOfnxufWnOethOelY973/97v797v1t7W1t7GnN69pd69e961lN61c96le9bv3tbnvdbn nNbWnNbO1tbGnNbGhNacc9aUUs7v/87n3s7nxs7etc7Wrc7G1s6lhM6cY86EQsbW58bOxsbGvca9 xsa9tca1c8aMWsaEUr3v/73n1r3GnL291r29nL21vb21hL2ttb2tpb2llL2la72chL2UY72EQrX3 1rXn97Xn57XO77XO1rWEY63n1q291q29ta17Uq1zOaXO/6W91qW1lKWlpaWclKWce6WcY6WMY6WE e6WEY6VzY5zn75zn1pzOtZy91pytnJyljJycc5x7SpxrOZxjKZTO75TO1pS1tZStzpSlvZSlnJSc rZSElJR7Y5R7UpRjKYy974y9nIyt54ylhIyca4x7e4xjWoxjSoxaKYxKOYxCIYS91oSEc4R7hIRr QoRSIXu9vXulznultXulnHullHuchHuUtXuUY3uEUnt7nHt7Y3tzUntrc3tjOXtjKXtaSnOt53Oc Y3OUtXOUnHOEtXNzhHNjY3NKOXM5GGutzmulvWuMnGuMhGuEhGuEc2t7nGOl72OchGOce2OUzmNr hGNrY2NrSmNjc2Nja2NaWmNaQmNSSmNSOWNSKWM5OWM5EGMxKWMxIWMpGGMpCFqc3lqUtVqEtVpz nFpCSlKEc1J7vVJja1JCSlIxEEqEpUqEjEpzc0prpUpajEpSa0pKGEpCMUopMUohCEKExkJrjEJj pUJjc0JaSkJKSkJCY0JCSkJCKUIxSkIhITl7tTlzpTljYzlajDkxGDkhGDkhCDkICDFjpTFCMTEh MSlajClSeylSYylCcylCSik5YykhSikhCCkQMSkIGCFKjCExcyEpMSEhECEICBhKShhCaxghIRgY ShAxShApWhApKRAhEBAIKRAICAgxawgpSgghMQgYSgAIIQAAAAAAACwAAAAAWALCAUAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqVLigU0dWsAwIi2 bMoI+GkBZRwecRU2mLv0rQsHao/+kTtG7M63HAOHJFO3BMADaqUKOoCDDheGWLhCfNP17QicdRjy xENUgSCMfDn4LEuhB1tbgS7+jKFWDUCZcncj0gQgwwcje/9SFRws8AQ5N9KKVUlWCgMZc1AJmKGK wQKBPP/UPZDFC08vWfuquFp2RZezdLxoMiZYJZ63f7hz466CwQCGzr1/Y7jg28IIBTEIYGijWzc7 TAYb6PnHzt44FH912KB2C8AAKOWIPP9jlW5Y2wWwvHWSZW5NLHKn9P34VikTNg2O2lAjJAIdmD3L ZGGOWetEAY8MeqiDgkGGETTYbAJBGCFCEko44UEVUqjhYhtG5yGGHQ5kIQAjZgjiiQ6GmCKHKLK4 4ocwiqgiQQa4aKNANeJ44Y05FtQjjRA92CIAP+54YY+zjXjQIT6McNs/PXTkQzu59aLkSySmZIVu MmDp5ZdghvnllVdaVKSYDJVpEQaryBhjlkAaSWSEPfYygo8oMpajhDVCqOdCI54Z55w3wklQGH4M quhCe+6I5ECC6mioQTKcMtEDQGRalQJALFhDDAr4UAUQS6hp0AwtNIBBAyPQYOpDDej/MhsBMb4q 0ABA3vHERAZoUEUVThjQgAZVYUCDAT0AAawFaCqkgAW2FlTMBZIO1iih1u5Iq0KRugknhEX+Oamh 15Y7EK4NNcCIDx+V+WAlVgwp6biKKtltQve+eJABfgARLaHeVstQuBQZ4MMq2eIbJgFWrBJKCzMS RAA7qzizCivFsGIxxhxj7ArHG2fsDMcZr/Jkc7mx2+yX+U56TMYwezxyxas8U7EbBFiAQc47D1ek GyivIoMVf0hkAB/Y6HBFOohcUXMnM7DyTDFLuPAMLPbYMtEdVTzEZkWmXtmyD734YQUGIP3bMgA+ iOHHKRCvTBEQqZwsBAa94OltpEQg/9KAC70wsggBRPQxmAuWtOVCJwq80csql8RwqxZgLKCFFD1g coolFkzQixpEnHIKGP8WRIAuYE90icqCWeRCKmuEfooaNA1wheahVPAAHql0IjkAGmhuiQFXnJIK GjP8UcEPllzwhikLpuTM2vNe1AC6tx4JMJx9Aplttj32KVuKwu6L0DPXcpSkQdgzmi5CMrjRNaAG PcFKG+/ruyis51Kk5KsqyJvcBri9IBHwgA6hnkMY46eV2EqBAHBElxDYERncgVoSOwQNKKiSKtyB gyAMoQhHCEIrJOpGZKpeARM2G0Gh60fbitP15PUElDUnSi9SE7r+p7+AAax9K2JMDP8NVSKEsIJZ kJLTj4q0xIRY6Hs8iqKcctjD7NloMED0jsKwqEQf7u1F6XOUDN3EQPMFrHvzSpjeFFLEguzQIJGy 0Jm4qLfaTXFcbzxIHr9FP3q1IV5eegYJMZKKCQ7wDkAYpCIXychGlsQP81MU9vzUviFiiyHo80jp GEKGXGwSIae4E8Dk6MPwrbGHPQLiBe5gyAZKLEZ7TOIp9ZdFb9Ekhu6yURhVKEs4DbGWwFyjuPpH Ly9OcoqzGuOHsgjE9ZWSmAoj5r18gBh82MMNPUCbQIqhzYLcIB65sIM2wIEFe1wCXj9IRzEacY6Z AAAB2oDGGNIRDBlAbAYqMEM50iD/gwqUQRxPOEUMZuADH1gACuxIAw3aQlCDEqAGP5DGMA5CgGJU MUJVOKEX/adFNl4URs6EFSt+VDpX6o9PfUyTi+JYS4GAIpITAWJL9diQmRLEphKKJUKoB0EfpvBN GxkMI3rBCqKu4mJHPSpRH5fUpBp1FU816lJZAVWlUrWpWM3qVK2K1V5sa0SVIkg2ElOkGlQhDFb4 lVrV2oYwVKENQrACEMLQhipYQQhrfetZq4BXvuK1DXCVq17Tqte3pjWteJUrXQdL2F/V1QqsS2Aq VtXFHVnIpuN61CWtZ6MR3EGb9qpjoUia0j+Fll4vNJLYCHLEFT6EYHfU0SZrmSM2/32SIAzQRjNc QY8UYKEcFsCCOaBAjxycoByn+IYXyLCOCriAHU3QQzio4QlXUMcb5EAHGiTgH6vw4R+8OClQq3CI hhDgEKtY1Sma8w1LASC9hpLAJSCGhU4I4RLRA4ALjtqJu+yuF7roBSJYANXZDWQBTu0D4FZxvAwc 1ZMmKMYqTNEEwOliEGUEgDMwGE0TGa1DCsyRuTKrvZ3Gdlw9uMS4hnnRaJWokoUy3UBkAAokGhAA X5UXvU4LVDN2dJcpFYgFLjED/nnUidXDLE0PcoE2uSkCeXjGMSzxAylPQw0beIaWB1GASHhjGoTA QCT6IIJe9CASz5iGKSxAhGNc+f8BUnvGEq4gZZtNoxMXiPIz1pAFKRfjCdMBRgUM0OZnEAMDQ5By LnrACjcjYgjpoEcTDELejtz2xHnSSEk7OpFLG7mYGWbfRcQASEfC15ErwcAluklCIHOojUkcX0II gBuVhVqFmhUSH3eN6l6T0KRNLIgP/JDrWd56sycCV48NgBjc4AOHrUPR2u71RDdZ8k3HFC+nJaQT QyJEpoVC6aTEleFIbcvVBdxobNFhQ9xYQFAzjKYtn0lGdWvWRSYKtizjnT91/1hOmD3TEOmY4WYu 8KYsCiNjDG7FGJOkDZdgxB3qQJBVxE0iBaCGLrIhhwYwoRw5GIAm7AKAIcQjFXf/WMNz5XADcvjh HPH4By4y0Q04DKgM44BCOuzRj0tIox+NyIYtyECdfajhu+3YBx0q8oc21GEaKMPfIBvgg/L21NcN AcIdPI31rntdTmp0uP7QXRIIyS/I/u73je2NgTU4425npGja3RhbD/sICBpNe7ynLUViujKLkeqW B1sITe+Fe1C31vW15+0msusaez+qJSk3tEfSilbHdN8xtwA1U3jDcdmYNmlEYAsmDNzhGd4OKi8/ vPaFAOEQEFSymQxSCTek7SE9EJ3ud8973a+i98Dn/TO8sfvfB7/3xj/+KYy/isiupGUjkn3Xpa8Q 6hcz7Z53LcLTeHBdfr6X22Oi/0DgNpBDSD3dyERyjGHN8PUfuSBVqMO1sv39MllS18U8Req9qGwS zxIA8KIoPzIEnkQAV5AKdvAPUwMGJxAP5FAMffAAmCAFA6AFz6ALuNAAu7MMKDAAcOAM0IAGHFAz umA4c0cQVmAFx9Yh5LZkEZJFx8ZChWJ9V7QQ9Hdi+McikFd4+IZp5PKCNSh2ITVA9wZ+OXIHzjdj lqJALtZjGMFDJ8UINiRKixIpgOdjCoEBh5B67adj/NJuuFFqA8EAulAMv/AMirAOBKAH3WAgKLAH vfAI4OBx35AI9LAEUaAOHycFUEAOjbAObHYI1MAOU+MGv7AJv8UDsrAL0kCIxf9wCtQgCCVgDmDA B+ZxEFZgex8SavyGdpinfhTRUjT4ifYmaq/Veno3ElenaRWBAX6wf0pSA5dQPhCxgyiRXrdkBv2Q DeyQC4HhEFkQXgJhBtTBDuaABgnxAsSQXwtxCbtSMKz0ibPiB8/4JlZQCRBxA/hgDnUAc+mQgcCz Df9gHTPwCvGADpeYAb/ADunAGjehD4gQC//QDuWwArDwD+7kgwAohhbBdaBYdh6xik94Eq9ife2z R6PIEBgQBs/ACBZQBTTgAxvkifnyBKAQJoLCCjQAHMJxAcPxGx5pTx6pMyApHCTZkSWZkinpkcNB kiwpHB9pAaeQhHFkRO/WEAb/cI1fx1kOkZAR81GUd4qZVxHtE3n/54RK0lKwViuK5ANbByZptZMg 9ARPuS+CJJVYmZWO9FPod4L78yBugI1H6XDp80lnUnW0yGl3pEZnQlsXsnh2JDA9RngOAmNyKSKp 9UpYOC7OcJMCQQBX+X4/5D6xRT12R4o/CCN7kpdLaWKglmzbp5Y4Rpg95pard0rholPtZ3leVCRA VJaWhSJFKTdhoImNpJNa2RIKYFFs80Gp+ZqwOUKaRXqj1HBl0iNVgA8oYw/2MA0qwIINp3AbtYLV dmKc+XqJ5CLMZBDnRiGY5WGY1X4j8kvyFpoEQZW9gDbDREfg14JgF5lQmFL6/2ZGPVBQT5As5+kD TxAEPbCePtCe6Fme5wkE81mf8ame8pmf+Lmf6dmfQYCf9Bmf65meydIDNsadclmThqeXVpR941Y9 MbhvPnZ/6TcuFLqW4AdHDUAAwsKhBsChG9qhDRCiHWoAJWoAA/ChwpKiIdqiBNAAwiID04APPiAs JeqiIgqiOmqjJEqiKYqiJvqjMDqi3yYSJdIGd3AKL2qKkZk6AzQiPvAPyRlTK8OhlWAafvBHVqAC NrQKKoAwnogQJZAO8UCPCkYNvLgIr6AMEWCO6LAML/AOUtCPBHF2rKd6EtGYIuGTHJUKRXYhNoAP 0/AMvUAN9kAlwkAN83AO5f+gAslQDmBAJFBgG+hADnDwD9TwD9ZABuUgBtRwBgIBA8VFALQQDKDh DfFgCslgDv+QD1TwC2W6D4jwC/OgDeUwBu2QDenQDVmQDtfQiNlgDomQDuyAD4DhJ4JEl6K3lz4l b7DGL73gCGGQL8uabbG0PqswAwbwbtxqo90qLMSxoYPWrdCyrR46rkQiGx1KJyK6oTDqGdsar+Uq ryYar+Jqox86aPG6rSqAOl50oT/CNSG1Syy2k3NUpM3qhJ6Zofyma0V4IUOYUnYJmT7ojyBxChPZ dXT5fdcXnkY2GE9QBSFbCazgMdmpHO/2DCjjDW5gcRT0LyPCJlZwMroRM5X/EAQXJ3a45oQrFqaa x7Od2ZMOkWOOSZkduz/KlBBKyYMuqI+K1ADPYLH+ZpixWREuaxEbwA3m4A3PMAgIkAz7AAYb4A4x Rw6oMA4coA32gA/wAAf2gA74EA5YkA7NQA2IQAb2wI6l8AIDwlw5CBFNJrUoIbWC+xA0uGlYgqAE WRGCQnbViSGZpHZqg3mmtCj9p3YRs4oQcriaRBFbkhvzsHidplJJW5lvIpAmYSuXm7Cg+JyHB5RH 6Wk51XqcyT0+CyayUrW6yxFPoBi7+7vAKyboVrsqVJwQ6gzJdHnGC4MgJrSJ2Ufc5iEHybMFC4RL tqwdpbi2yCJQKCE+4F76/5K8bjJT5UaxQ6ltK8KY12pFapJL1glGTBpryimeDSpjRKSD4Kl+S3t9 llu0X3SXFdqVhdsRuRu8BhwRTjnADHEHZVMJWeoHYWk2blAHbnAIbgDBDpzBE+wGi0DBZuMHtUfB FLwIbhOWWuDAJlTBKmzBFuzBGQzCMBzCHXzBGlwHi1AJRMDCNEwEHTzDKDzBMzzDOozBblDCiwDC NLzBJVzDRYzBSMzDNuzCPFzCFuzELyzDHhzBlSAGSUzBJSwGOmzBXEzCRSzGTpyJMKzFG2zBQqzC IUzDSEzBYXzBKTzHV7zGK2zFMbzB7GBjP9kjtBKxDXchnwkpQIMb7MBqbP90g4vJsU0aRGsERESb YaKbR9g7GJa0sGRphMO5iYM8Gy1FmwAQuL10gydIm6AQBAVRANPBDvNAOhBRAHAAjgWRttkQD+WA jLxinMKkfuJHRRkazNVrYtvpyHc5YqV7L9TGfZeZPo07S7owkwMzLYQ5IsclBtvQD8aYBAIRBddh FZlAHegwB8mADucAD42AD9gAFS8gD0oAAAUABHObDf2QC6+ADUVAD3fxsIzyDPBqAOGaMyoq0Gli U9LZgzhpg0x7vig0MIjH0OErEBfgrwMhujp2mAKBSArsJWQHfVWE0ZgLMJWLtBxVMA1d0hXhDJiQ hIg5EoEZJp1YuET6BL//l4IwJZkc65210j6dSEsOHdIM0Vph95eEHL8PoSvqFiholYJMzdRaagVP nYJPPdVMbUjdcm2IW1kZoSYEYFfX2NTXSARgPdZMXQlxRdYpCC9oXdZrHdZtDdZLXdZnbdOO2Ylt mXbOIM3CHGRnsiecKWLjgrFIBtgk0i3GK5iPnLoLoZ6OcAqUtdCHndj6iL2ZxhCoGRHghtgZXY35 QxPFQAT/0AZOti9QgA5roAnffBBU2QDpAArZedJG0igzJX2bpLoAgAGsacwCgQCyIA53oA3Y0Ah5 mw7A4M1agA/s8A/hIAbuIA7vrAC0IA6LgArsYAf2EA/pEA6NMA4ukLfn/4ANeJC39rAMYKsNSveX NwnSBuAMCAvSDZHXGYsmYXXAIeEH0YhqrpizKQEKLO0Q9/MPTpkKoJCkd8AIoOAIB57gCL7gCV7g qeAINfoPDKzILztvskElzeEINNBkFwEBxaADeDAIIoEAv6A1BmEC5tAFOFkMG20QKh3fiC2Kfadr IOuawImX3de0pVubwbxZJOW66OvR14d3ludMdy0vXNm0GHAKabl5ul1/B6HRdd3jDvG5ucEOeddh 7td439kiwbasGeZKg4Hb21e+KtK4TU6niLneegrAF5XX/Y0Spqff9B0mKgC+GdUs09PiDcHfLtEA l+AHl8DndV4Q1JiV8P+d0KvHGFVQDHDXfTJYdx8VykK5nClCvsZMes7Efpd3UTKQ3LiR5ee7up1s v5uVYrrNYl1oKBcqEIzgL1iIzEnroDveEBigAjCJkhgQA1qoCzZzgY5OUH/Ka7Vpyv9bfe+n6Qcx A1ZQhjPgvsWboQRb0e9XJsyL0xeS6Cmd1YtLEqjbEJc9EQQQBWmmCM/ADoNABM6gDf1ACJqQC0PA DoLwCsSABejQBrHQDXlQDlUgC+HQFhvAHZy6BpehBe1gCkpAEwxgt3pQDQOQIPBMGpq9GMdAE5EL ETwFEaAwpbuMvl7Z7RDhBgWe5gvxomJwClD97YzrJbadEc+g16QrEP7/7H3Xd7AzAspATeqQLG3z WxAyIATFYAXv5ge6gQ9WUCOVcH4SmrQjMhrz4HPHiClVUBUD8bUyNyzcgAi80QAzkCzJEQRA4AQa CAQIJQfma5nj1lpwIn35MpsN8eohZUkIWdSlnjCFfH0Xypjex2JDuD5t4Acqu5vxrW+vws/8C02i N7v5OySGPchZkpc8PxBwDrsDMfP9O5azJpRMGzZbDX7zzbqT8pCjsgajUvrKQvrKAgSoX/qkr1aq X/q/cvqun1ev7/qtD/ujP/uxb/t51fuu3wapv/rKolauouODwqert/FGPeWOf+2HX+tAWxCZSEHw BSEc6r+wHZ0Y0TJ3//+PNvKIcQ4ofrAGyx/9oztAKpAKfny7H7+XKs+KPIklfr4RFh3zFxF/p+AI BvAHK2sAQgAQiwAMJFhwYAODCRUSRHjQYMOBBgAMMadk4SoMCDF5+9fxX7yFABoYMMCo1ylMVupU CdnSZUuJL2XOhKjQ2SkfM0MauOPRZzE/dfZgK5EOnAhtuAxcsGCAiCMWsm6JMWWBgIWMAK5iMIBw QJR/pRoowGBhpAGzABYkK0UEX6kh6MCgFeEIDBRxFqw2HdmAwEimZtuIUWgAg4pVz6zIWBiToU6F NSFPTugYgOXImUU6LCg5oWfOlydj1kyQdME7QEBPXk2588ABCQn4Af/i0nNr1wpB/TvNOndhzr0X XsB0CsPvgQSQ/45N8GbO5SGX3AHliLojUHcYVb+Tyk/27dSzg+IOKtUd7eSxY79zivr57d7HpxfP fr568fTHV2cc3f9/AAMUcECdQFGNQAENKAbB/y5YpbA6/jiOQQoXasOKCgd8BifbAGhuMw8fKsgx EkU0LaLHUDxRtBFXbJHFxlxUkUXPhANRIeVCgzGkHGUs6MOHgNyxR4KEfNGgEnVMsrKFWhMyx4Y+ 9Cok3BK6g6UbfQRACG+KOaYYZ1gp5hkxndHFGTPTLObMNdE8k8xninFFzTNZecbNZ7yx85nEzPQS zDft/DNNMp0hE8z/O/mM801nxmTFGxoKIqA/gvzA8jNMSwNABhp64dMHGSiV8RSPqJHBMYxGJIOd bKbppIKCXFgDVshMgCaHgYyIxxt2cgHtgT9QaCkV6Db70EjRapJsw0gzdPZZaKOVdlpqAbjjCcis qMSgATT5Z5p2xHFjm3jS2UeRcsZAZpAyyoklHnaaEUIbePHxZp42+BgH1wVkUWYIeioYoAx1BhLh m1WokUacbPrJxh5sanG4n2PYWeMRc+zAh51z9NEGmzF6TcgPn0r+p4VqFfIBQ4VYsSBllwhAWSFH aKiSMmcwKRYyiIRriMgdWwK6SB1DRFJGKX0LDSIoiYZNaaZ/jPE1/4KallRqE3cUMmqFhHQMyByF i+m2ostOESLJxjby2hTDTsiKXnzowYcngqAbCB/y1jtvvPeWm4Yn+tb7ib0J99uHGRD32/DBD298 77nplttwwnu5tKWGqozyaBVrEptqG6OT4Y6XZZLs5hSfNnvKIwHIOdKGQv8P9Zg7tD1AZDOkvdrd c4f5tzvScK230HdXCINpPGJMhjbc6AUTkmTPEiZqezN+eiR5OskNKyYcUHqz/ct5Z5maq3H6Kq0/ 23duww/a6s+dbnungz60bGjb7U8IyNidBg1t+Rmtf2WTjNU85yPMjO12Lxkg5yBiIPdRLXVZe4ll MEO2oM3oeqPpy/9fSDKAppiFABWIXlMq4JcQdoUAKiThVQwAQgY1kEoOfMzWckcaIJHmgCnaWkHG Nxn20QRzpmuJkYx0s9wFcYJdy9QSlwhA1+zuej0LoASbFEAFUsZ8VywNRC7BpzK9SRfHMNSZdPGM Z5iRjGd80zHSWEZCiXGNcDzjG+0oRjqa6U5iRKMZ4wjHN9aRj30EpCDp2Ec03pGQcLqjHgOpyEXu aZCNbKQhF4nHNM7xjJI0ExkZ6cdM5vGOmiykJ9VYxj6a0lB7mmMo/fgmdugsZb0b0AbpB0QBKVEn uvzdLXViSwIBs5eUEaYTZyig0w2TZ8pkZjOd+UxoRlOa04ymBtr/IAQwSIYsNXkAEGjlEgwIwQkN 0UAMEqKBKpjTABpYw8seUAUejASd5jTICISwhHVWoQrtJMg8DcACfabTPzPoRUs2kApcAQABdnLj GZKThUR2AiIFgAMdIDKAe+rECm6oGhC8gY+OXA40pHmCR47hg64AgKALsYEuNjEQJjzDjb4ayBBo CpkBWIGeA4kAHvpAkCxYwngzAMWL0le2LN7yfNijYVOVyiSmGhWqR8VeUqe2VKpi1SVW7dxWkRpB Gk31dsUM0AiEWRb/0E4F7DDZP87oBzf4Aa5yjWsl6hpXN9Thrn6wa17halcx/AGvg60DXP2KV75q 4RB0LawbVrGt/4e0x3uQUYF1JCMDdlhhrnjVq2HnatfGRiiumo1rYfnqhsOK4a97RaxdDRvauLYh Es9IRVw3y1dMMIKau+Vtb33725TxBFtjBStBWtDWf3ijuAzUiQWBsxwZdsYKbU2HDky0GigSsEnN sczN0sa5GVkxaM5tYnh3dJrvtg694A3velsHXPhqJTRblCCRMhcS7gYQg/ItovuSecSZFAN/FTKA H0QVX/88oQ4IJsgITuEaKHwjBwN4BTHG8A0qtMMevCBCOnbhB0QgBAHJ+MdLAXCDafRCF40QRxt0 oYtz4KIM4GDBN9QAhXGI4RtNwEI5ygAPFMAAHgmFjAGeQaAw/P+jF0KwEvlmogFq/DQL5nhCMjjx in+MYwS1KMYhFmHOgf0DG7DigJ2oIYxjVGMB0rCEHqoxAlqQghqlAEAZivEIdRRAFsCIAjhioIld HAMYBBBDG2qxj2k8Iw/zQMOMoUwKbbDDG+XQwjEk4QF2qEAT1QCmM1L6rBkwQjvpsc52MJGeU4t6 O6UGD6rTo2ruwFrWow6PqdMzAsiE4Q9QlV8DQ9dD7DXADUIYaeq6a+whckaG91UdslNHADccSLzG FEnuGpDfqIZGh5J6BnL/8aBkv0YiHEjGPhBBBnuwQxwz0AM5niGFgZggHsnoRgPgHGIooKMLAHCA K9jRjnHoIN//2YDHDmjxj1zkgR3sUEqxs32ZI09bWTKZbnKtULqBsC2DFDzNBRWSgWT0oxN6gNcy YNWtfrCjHE3ggDSyMQ8lXBsK8cjGOGTwCHghwgX/ZvgN/kGPJHBRqkI3r0g8PfFpy8QNPmHHMdpA gCpwlII3akiEjzENRFTgBnnKxQ+mMY1jdEIL0piGN+ig7PIO5BLD9a+nGbwQNxziFAq4HvsIkJ1K 1IaZZNWUQTBwh8m+fVrABJ/gm8n3cBfdt72YAbW1azQQdXx1OJq64jvei8C3CAOsmBqvr/e1oXN1 vNrWERXfm/Eg8LroyRS3llj/mCU9UUSxLxp28Zt4occeIbRH/9/sXT/13f9evMFfPfBhVPjHQ57q wTEm12CELKTzt6tEd8ixiu6DQ3z6mOU7kneFiByI0GAVJGkAh2Qi+r4rfn+dX+7pX7J59qff8VkD Zmt2Vzyvhk9zWvq+0tpPQVuKPtWjvtWQHfbhO+RrtsITwJDQLPnLEF4KkF4omQcTvARkIoOYAdKJ FtxAPOZ6Jg/UHcrwuAfMjRCMjgiMliA6hWYJq5mQHdZpEl2wgAGIhXRrB1wgg3UgAD7oBiiYhyWA gnI4hWmYA2qoA3ZABA5Yu0h4mGooAnpQAz4QBldQBwWAg3KwA3l4gh6EFQTAMm9Ih3DQgnPoh3ZA h18ABxWQhf9lUIRpqIBHAIciwId4sAdzkIZ4QIdlmAFN6AYy+Ad02Jh4wIWWswUAYEHm2C6XoC/2 0bgiG8BfqprnMh70azYdSUFeSq/tY8D2qSLo60QS/B0lOrbUsT9MIQAVwABVXEVWbEVXXMULYMVY lEVXnMVZfEVczEVV/AuZoI0TBK4GGD/DY5Aq8INhPEZkZDArOIRvaKtUqIFeoLuEgAJzyAEHkAVe KIJqHIgHyIR40IZ9+CkASABkoLOBgIKN+QcZ+4h+QIQ8gAYdM0J2wIdhwINySIFHwAaQm4d0aIY/ jAd1VAgHgYxDuBQSbKAc6sTIMwigSSoYZC/3Q8RwEz3yGrr/tKO27Eov1jG94UuNKgEwEAGNAau8 SMwSDAA3/1CAbxqQtAgQH7gEDFwIUmG6bJABDCiGwCuBbyAEFSADeiADc0AEm8wCdPACDMgDkwOA EUiGTngCHrCAF3g5fMCFgXABdBCECtiAXikDZRgBWEiDK6AGbyAGFsgESdAAXfiCLJC0XFjJgRCw gZiBUAmCYmCFJ8C42kMmZzKel/xFabqAS8C1ZESQk0xGC9AFAnEBU6CVCTAFImOmKpgGU2ME92CE S4ArlhlMzeyl7HIIA8C8XrNEokM/BkwSjkw6rYg4F3GvbeMc+soax7CaCRI93+nMvquJS3CysvlE 5Quf18wS//URSMRMiAKIhEQrhjogBgwoglxwgWbIASbIBRDIA2/wBjrLgkSDhifABDpggFNQgiu4 OkLAgEjwhmdYgivIhQfAhD7wgGVoAThINDWAA6XIA0LYgGkIBTLTBW8YBh1wAZnKBSE4hRj4AeXU A2iIAYSACCA4BEhMO02sPOt7QbSbvxtJoPjLoJr4TQmCIv5ZkYvqxB0KUYikPtcAgl2LLwtYhbay hxbMv830pdLThdXIRP8DENS5wJCQgWzwiXi4HPjS0UV0Fr+kECEdUiKaxOlzoprQrAMDjcRYBSmd 0lXoBSm10iktBlRYBV3oBVbAUioNUzGlUjBNDCs9UyqtS/8xrcsyLYYxfdM3ZQdpey4YVUBjqsTh Y74GjT3H4ET+600LnR7M4E3RvDbjK5ogKKq0Ez2rwbboMr0IDcnkANHqEyvUjMkK3ThNvZodsU1m c5ECnKAapZ4mwlA6TUETvR0bWYWZaQ3SIIAZeBkDqAEL6KYneIKZAYAI8AEgeAInaAoNWAKt0BsZ mIEWaIAayBsZIADJOQwgKFYLUABlRVaUqQG3nD+E8IM1SM2SkbqCkIEqAIJTWAVn6AGSwL1aSrYG KMZVuINYJACuKKAIytG8hC4tCokquAPU2dA/Pb+FEBJrmzpUdb8k7dAPvEhS3FTRVFhMVb/tK1HX GNiLdNj/hwWQpbsAaClSnfgDTDiwaAKCS8DTQEXSlCnGANmvik0rHD1YYoovU6wWiU3V/0tZdAUA k10FjN2+I7URjW2uSiC2G72RCc1QzPABfb1U9fvU7dMWndiASKs3D/CGb5gGNYjaYzCHQVgAVyiG XijPb8iFHUjQDIAGH6DOaegDFziGb0iHW7AlK8hM7sMauZW4kizRmH2WUHQ2iL1Ifm2i+ovRmcCA QxBMgjiFXAVcnbCAP/CDSyiGf7CHYbpJatko35qBrHgbb0Vczf0tnnWa1my2kRTRJbXUgqBc+8OA VNC+JZJNJS3YKhrZ3/ABe3hcNSBSQE0bGi3Fs5kRr1kJ/5v1iWdIqUoggp410oJwA8KQEbUxEVN1 wayhL3mdSNGdiQHrTN6TIsg7yNJ73Ri8H9JjL1MtXmXCgOzAy8lYUd9KFQ8xg3LQJxrAAD34uSd4 BXrwg2QIBm0gB1aYBj+QBVsYgEcoB4sYADMAhwZgAGoYhV8oB1YgBzAACwGGgXBghHRQMWL4gWwo BzHYBnD4JkfMDUdgO50AzMxzCcr9JSJoAxUQgkqwgoQigLetBBloAA6wq53SAD9ogyWAYTdoJyHQ AaiLgQJwg3GCjOHdXCSmpiQCr+AsWKUdCAxwhBLGvT6tPMtwBN0EkdfMooSNrtRJSGiiHQ/1kZpw EE78u//DJcnTNEGaldQKtb0FIlXPo1vNuKGJpRFk6RGAHUBOlE2JiFQtNi/Q67sLhF5BztT++p07 6IE4rlnkeII/QD4n+Y39SzYdfb1lkr2QuBKFyGGdCF0Z3dflWECSrdPhIdjZKVSWzWTc8z5OTWSr GsVVhkQFSpr0+0jOyd1Z/rX1u1Q8xT7i8S87bWPpc6/3guNk41DspaBiyFkAUAHAa2TZ6GXPjUku vj1//VeFzD9DLWVqNhsOhVBJpObNQeVVJlHSrb3aZAjfAZI9rjZsrjyUfbg1Rg4ZQEl7deLfkB2e wEl5Rk0jio7mVb0qHk3OkM1KvgDEVBAZndvm22ZjeV3//dql6Wvnp5qM0PWMoQFj8FtY5+0+Spbm /vuql7jb3WKEkrkE8X0mDJCrI03ihfCBfxBhzcUA4HUDbLmABfkPG0CHRRADeksBInCDKqCCZNCH M8DhNlCCB2iDKnCC/9BWmD7GVGg8g7ABebAIrVjFBogAVbQABJAGmiIAMriHVdgGczBKVWwAIRQD anAoAICBfkiFVUiHbsAKVdSKFigLw/CLjIBXtFpFA9DGJjAMFWiABngAC9CDcjghhlRNmrDopEtA C/CBYtACFUiRgW6van4vt/Fo9grV+Ctoo322GiovDKreJaKvgt6MmIg6j00IDGAHY0yIFuAUGRgB GggV/xrQbdze7d4Gbt7G7RGQS98OldvmlBHglORObuAG7tsGbt+G7t+e7uUegc+FaCQSVWBrWG9W InTWZvOqZ6zZbKbCvjuQK7g6hMX9g0O4zMWNq/eWq/hm7/T2g0XwA/ZeXPZmXP3+g/t2A3Y4hf8u cPieqz9Y3ALv7/0ucP5270uw7/e+b7lqgxgtsEOwDlCYYsjQK4VQXwSBskHQBHh5BjB4gEjoiGXA g2/oArQ0uwqRXIPwAUao7ZaAZhufah1HYtKIiYrkNR83qtM4hQO75tGlkSBPlh8naWV5TaQbZDEe 5hLlvYdriZ7wCG+IZIRYBcGUjIBOkQnAh2VI7xiY4f9JsYARqAEZuAAyKAcMONYHOFbcNgAjoIc1 gAM1mBQ19ws1l4GWzFv2sgDOEwkDOAVvQIeOqMCr+ufJkz8vXkj9Y+IsoaIdQlrNoD1A5yGH/t6m Yp8mjmUm6cDp7W6GZWORjojxW2lL92Y5rltW39uRTrqVcQO7IoKf5p5KiLq84h5aH+qN0paN+lla f9thx/Vfb+FKwIN/OAVkF4Jhz+EWDnZij/ZKEINeH/ZfN3Ze16uNKrTUM+dmMumVNXUO7CXhAO97 9Q0jeWntvoxi+ONmU1r9YcjQvmPlK+cLdWiyAcl5Z3SmglSZpdRDFulgvgyANJl4mJA1Ttjki/RN be3/Q3U2ZN7bHl+aY95EOnVYR4XNAOIfUgev/3EfQAeaT6W9UY0MUrflktTESS51o/vbB7SRD71U 623oKAdthYX4VuboY7qZ+CGIJzhapAVk1IZdSIy+UKxkysMpMg43L2/ocy7pfI51jJxNzhD3kM/Q aREOt5tl/7jbea4gAkE+drddhegBRXV5AglY8VYm2mlilY2vst9c1vVuGXKEtnqGkXxirw8mnKcQ 22z7CkGdL38vGmfSb/6NEN7xvo9RVe8lXbhcs1EQ+4oWS1muYvIcZ2D8YTzMavlgADACdOAEIeAD eGAEdFCxYoAEP4sFT5AGczgF2qIGQRgAPQCHTCCH/zDQBTkYCA54a4PJX1eYh0v4hkp4hXIggmlA hXR4BmmYh1M4BovifOoPkA3J4s4IXuYr1YNuCrNSyp+xABlogRRAcwy4gK4YgRF4GQzYKQDg6vdX /wtgiqsAcpI0MgDBgPEHV0EZg1ABCAUNABAsaKAgwQEEDwIYiBAAw4IOCQ5U+BBhxIsMJya8+DAi R4oALGIs+dFjQ4IyTqGc6DDjyIchC5IUeeeJxJMmDWoUGRFmSqAzZV7kSIAoUoc1Y3YsihJizp0F j/J8WNNl1KFPEYa0qDUl16gXLW5EarbB1axOUzo7RWMr3Lhy5RpYBXQu3rx69+5t4MbPJTF3+RIu bP8YLisLhwuDAlJ4VZt/QPzcuQPK8qU7jC4zusT5MihMhxxVvowT351TGBazbj0XQzHXsmc/fEb7 aVsfW1+qhbp7ocjgW/20qQpWOHC4IbF6VKpzufGvZ6P+NNscQ6+bZZk6HEoWecSlU5Gj9JpcrMc7 VcgjJDl04mCUN9f2ROjMyr82q8JOhWLuySvroEBeEJc0YA8oqhk2kAUWjKAABhZggMEFE0o4ISjP rPJMKj0A8UQQuuFV0XllEcDOPymmmM0TBlgQG31WEWBUgw3MaIABDeAIAAEWvOTQjD266CJEDTbU o48GCPkeciEZYBt/43lUnU4P5XbbYgac0gJK8WH/SVN5c0nHHmFjPoXBX3B5+WVeVfhxmJlbgSIi XwZUUYUVVrRBRCV56plnJUJY0YszbeRpqBtCVIInoHiueV5rj+YVJ0IY7CfXDekAQ0Y6uOgxTgUU zPNFJvDA0U8vsoTDxzyKxFPKDfHsAss8FeioSScsfOOHNOSs4o0z8UADizPUwEMGPrxoQg4r0+jS TjCwyJOEXAQUIx5TsjmDCZ1zpUVmSygRcIkM6PlmXLhVVtWdutlCFxeJYIJLUkbbZZvtXV9NhAEo q1l3HJVcfSeVb/C1C1u7zTWlHFyNKeeemmb50I6K/9ijS7kEHwfpSe+ey7FUzPEHE0dAkcwjjhYM /6nyACrbWIGLBMCs8pA5yjzkzTQbMLMBVlyS4wU26ogzzDXr7GPOOQ459NAX2KyjyAtvLDVYSzm0 LZ3SceRcXgQYcMGgE1KK71NavXuXvXSVWfZFVOE1GNcfS4RfxSr6q/C/WsFtLkJzdinX2HJ2S/Wk 8IKMkAyTrXIKARjMGONTMAVMnscxnnye2TvNVPlOGNQRxJhMss1mlJAT9Mwpg/M1wx2KEZZR4KSz GTsAlWghFZX1YmTw1sFFjbbB5zoZFPE/8Y7WMwMZ4MdbI2LZGKVfYSt7X3n5cModflxA/VRi+OG9 G3WE74cV5KdyyvmnOHI397JPP+Vc22aslwK95P9YvV7vH57u7Etd7hEN6vYPdnhDBodwA95ko5UX EBAdm6Dd2rbyDCu4gXYQlIvDGJawCGpsY4G74HG+kieHyMAeKWJHNtowP770rmNfShttJNWewhUj dXvxg+rap8MvWQEUzbuIDO4wkzzdZgBkGKA22FGIWMTDHvPIAUE8wA5E7CAT6+gBNfowBHr0QBbx SMc1HvEPinlCFhbbhxxu0wBn7BCDOGkjHKkHigHegX1xvCMet9KWH24FJABoQS8SSB+r/S2EJvEY DCPHnuk9SnnOQJtweJNHOC0mdsGL5OgAJi8v+a1JYnFbU9iFLkNapXTgEiXi0FExe7DDDy3wQyX/ LnKCZ1ziG10YgB6wAYACaAMRBBkCPuyBDk6UoR+n0BQZxnEFc4ghGeWQhjm+gIdQFDMNrNCFOY5Q BmXi4xnUKAcUEbKKKshAF/GoWzqiQkhzHaSF3BEkKFMyvUtSxZ3Tc5uX9ji1EfkBJ71Q0RuPBBG0 QEV5PBrI445C0IMo5H4DQShEG2Keo+TIIgOo6EB54tCgRDQvGGDEIVw3yZGSVHadLOkNU6GCp/hg PQ9pwx8kcpD7zVRHGb1fQYn3o4bUlCI9zahNlecQVmAAhHKhQR0uwYiiotQ1NeQj/6KKEAoCIAr6 kAEZ+tGHDeCDHfiARyTKwYJkkOMU5vgBOsAA/4NyVIIW8dCGPqA4gCiMIwl82Ec29kEIPYADIQ+g BjZUIIt5SOEE5ZBCAtAxiCj0gxHamEc2ynHEafyjG3DARzbQAY5KIFBM65IS5wZzOfHEhyPmcVe6 GIlJ4fEnnjxai5cuKaXVZrImB3HE4FwrlJwMzGz6O9glVqqxwOmOb4msQkwBQMGZFNd54MJbIvV2 kQu44Y2So44n2QO74CQSYhvT54I829TCSJI2XjltdPooSLn99m1Pce0p8dJe8fIFeuvdinjmG6aL nGIEhgvvveLCOpHGpaWp8dpE6hng+XKkGI8b71bmE9+8XCmT7eTY5tATNfXe97n/5RuI98mf8v/O 618Bpo901tnhbLnWqDPsYMT2iUqyEU7CHvSIFWIZYsCZUsStyVxB/ACEBlwARSryxiH8a0oSF7JM qxCgxXTBDphoAhsykEELCKCHf6wDA3TNQjyKwYpeoKIcDXCBLYtQDiiE+RfdyII5wmkGcKAgR0YI MzWawQdrVIAD6OhDBqiRjlxU4DgZLN3m9FdhDsomkfhrtFQjDb+91ITBHpY0o3foaOcixMYy8a4V 6gDh2xyiOBokGHyTE7pTc0QGT3iCD4Ag6zXE+kOyvjWtq1DrNMj61beWdRqmwbxbp6HWt37CsYnd a1sDodhAWIOHzCRDh9Qwh6O+Nrazre3COML/MdpugJEFOINtkxuIf0iFtcsNAF24pU5mWQpJ1hmv 30w6TiXjrryqIm+Q6auUcKn0/giatwQyeXL10bBH3sec4XlQv3HTL0E8TcremDg+e4NxJo9z5Sv/ wRmseEYvZoCBKyvZvS9mz8P9TeL3YWAGKpDBCPywIVaEQQY0KHnhwHJdTaJrw6q+dDzHhLpuuVjd Rj860mVz0qQzvelIrzZ9C/YtE4OF4ZOuenZN6ccma448kBROcy2M7x1zOujYCk/UX7vPRh5y6qLc Dr00WHSn62XudL+7j/Gu973zve9+/7vRt5O2r0uSxEMR/NjJhHid97hgP//Y4cdu+Ho/frv1/yk8 pCLP+M0rXvKZp7zjIQ/6xXd+85O/fOUbv/jTPyf1IF7951Efesu3fvaq97zoC1KAAE1ID+IQgjS8 kQsW0OIfndBFNqZxCxck0RudwEAevPGMQbhgGqxAxJmfsQYzjOMO7UgHJzhCBmy4IBm8+MUysMCO U1ADEa8oRySW8QN2DAIhN5hiLJaBgR3wQR0osAE0REIx2IE29EHLfUoMrBrWJccMsMMqrEIx9MID FsME9gIrROAqSGAEjpkuSCAEVuAEQqAFYqAGWmAvdGAIimAGfpyotU0V4NTAUQQGtIhwNGAGiuCY feAGlmAOUqAK4qAHUuAOAuEH/uAQ6qAJEv+hDz4DI/jY/5gOhmUcwfTb1T2XdDUeuDwh1ckNFR6c FXJd3l3hjonhF1Zh3vEEAcCBswRDn32cJVSABzxDJUTCM0zfDESCLhQDIhDAGxTDM4CBC5hCOGWA LjyDM4RCBRQAJoABAUQC9g2AFmjIM9ABB+ShJTRAFhwDMcgAHDyDLhBDGsDBMBAEAZABh0gBApyC FBBECZiCD+QBh6DAA+BBGrXGDKTCVpwAYREEA1DDJgDA/a0iAbDKIfyBEnhAPKwCO1zCKwCDHqCD PdCDHWwDO0gZNfxDKYiQG4RBMUBZum3FE0BZL/gAKHjEX0nZKm5TBUQALQADWmCBOQwBOmT/wz/g AloYATAg4yBAwTPIQj+cwzg0Aj6MAxzYgz2YgxrUwj+kwzsowR4sQxYE0z/wQvmZEDgU2kP4gBAB Hkd2pEfyXckQgBU8A5RhwlY8AA8ACQ1UARA4wUTMQA9UQRA4gQbIgAXUAA3IQAwQQA1UAQ1UQA08 QcshG4EJB1UBwAhYwTkBFF9UQcXEQxX410q0jQ8MCAE8QQXQwK0lIEE8gEvOwEyKFAb4QAXMwBIA AEzGWgpoABhggIcoAQBoQBJEAA1YgAYoAQak5AzIABOQwx1sA51dhA80Ib0RToh1hRSai8JJ1WKu V2NCzmP+S2Sa0mQqZmKSR2WSR6rJ2H5t/6HaxKAX8lzOcd7+mFxBjAA+1E1Ripg7bcyTrcKMsYbW yB4UqtGT/MMdYCTCZRrmyF3tQQ5zTZhxCad2EefaGWdw+hjnhB5w0iZoftZ6Jee9KVJzqJjv0NfY kN5OXBxzkmbGxWZcBBEJudSl0cU/VYw32NG2daH1hFuKxIMM7ZDdkV3asVAl3Scl5Wf7bKZ8maZn It3cxWdBuAmbGIAJVcwd9EkVzGfg9cmg1A2UkNtHnQKFYgIjUOgpWCiGamiFXmiGeuiHbqiHgiiI ciiHhmiHiqiKoiiLciiJnsKb6NAdFIP4HNAigE8lwBIshc9f2E6O+qgfuMGPugGO6uiQ1v8B+QTp j+5oHSyC+IjBAe0ojoKPkyopk7rBAdVojxKBk25plxopjx6QjXoPkHLWkyZpJXiDgH4kX5zCCn1M bBHGKqgnbZjJFXJOhq3YDBDmd4pF0bWmxswAS+wFFHxDDLCANgwDFnTVF8gCL5gAO4CBB7SDKFyE IjYBERADBmTBKhzDM0CDDECBZaXDOkQCMVCBLnjDNHCCAkTfNCzDgOiFAbARFz4FesnNUywdXmgA NXACBpQBPTxBMvwDMGABPchAO66AJlzkRXDAMUxDMYTiNHgDNGCAGlJrDkyANxwDNDRBFgxDAeAB ImTBtELDGTDAMXjDMBiACzxrLnBAHXr/Qy8cAzZgABZMwzOEQgZ8nPBxwDmgEWE42Gyw3nFA3H+W 5odxXbtNnGhCZ3FphRhYwXMmrG4xpjpNxyi9nUH0k0yNWGiK3RlWTaRNpZ+SiQvU4TMQGgekQp/p ghoEYjiJi7iKwCnQgQvogjPogiVgQS5EACsQAx50Qg+cQhK4wLvKgjfYw2HBmIlEaJWIjKPRjYrg AyPohsRtnVg8QLM8AzHEwANgAhoQAB7kAgbgQR98hQtsyDN4AiNYgiKqARyUggJEQh+4gDN8qhRA gCFOHxMQGhyoQQY4wzG44806w7umwhlkAS88wCk4wRDUYScwrhS4QCpY6zPUohcCxTMQ/9jWORxC +EGU+cBEHKVejGUP0EAMyMUM2AqPFYSEgedUJdckuQF5cmQD1MGQJV0DjMEffEPFDGphcIAbLEGK KUqhEQARFKMbpG5cPEALzOeT1CYWDqgAPUNMSRz1YACXeIQQOEGW2CQcPRIlkaMjXEYqkCSU/YPE 7gUfNEMiUgMrtAM7sMMzHMKGUIMzZIMoIMAv2AJfCBleyEAgta4UrilXuEkvCER9WocBG+xDEIAM rAIA39GmcRhSHoMABQHwylYf8cEylAA1yEEESEMq8EE1OMQD0MI+HMM99MEDyMItNEARoEMXAAAC wAIuMIA3hAI1oEEB7BkUjAMR2AM5TP9DL6ziGPKHBdiFjAZU4o3mu+VBOGxRDATa2Q7AK3QDLo2D HuxDHV5iGj5DZOUBEU9DKtwBOyTBDeTDCNBC+HndKCWMFoovbxaEGKjvm7aBHwyNztRMyigJjuyM 0rxMIEMNjhhyH9vIH/sxzTSAevDYnh5Oir0Y1tIWw17EyMEczBEAI+ztHVxZwnGhpanaDAhqzjrD HbQAycmAAlzmxlQyk5kh3wAZb4iBGAzEBXyDXajAM4zAxv2yDOzlXgIzMPuyJmOZDGSyKh+zMauy Ma8yM0OzMT8zMQezNQuzMAOzDxwDUnDnBokFKLjSxmWzNVezOZ9zNU+zzUkzO2uyOkf/M5apwM2h Mz2X8zUDczYP88ZNw2puEAcbcB6B0DPky8JYXShTJ/wQ11MQaHD4j3KIwSq86QLHSNxQZhz33Cx3 3e3WLoPinc/FHox1NJs+2pgA9ONBlyXfXlycHVws7EceQu3CBYGKdNPN6UjfNE7nNJv40Fo48Iq1 lwL22FDocUtErOhgIe2ZNKfFEPYWJnnhJ4BRZ3I6hefKJlQ/tX5iNccIqAEHNX658tT49EOkwrid HMjg0/SWjmiBnVk4GpMtMUesAs5RnFSPBf+cDRhKBLYgJlIshaU8VMLCaZVUshkaFDsRzG6dGq5W 9CGNjrSJpkFPjk1xnWRb3HZyhWWP/1Jic9hsRto8NfR5rFNGTF3j3ar0AoAQdNZNV4EYoC+UPQPt 6vRWhIEV0LRs3zZu+12ODeyXMCgGuDZ60ulVu4ZWiDVcDLRWY5pS0yfGLQbELTeAxtFaT/RKk5uZ kK4TtoT+lBe8EQQGqMA0u5w7i7cvl7fI7eUIkHcynzfMvVx5w9wIjBwGewMNOHM8w/N7j9wIrEB7 jzd+kxx5i4VpN4XBvXJxFpIjx/RF/2bY9TSkoHXIqp1ar8W8aSFp8mcI6Y945CmkxGlewzGIl6d0 dpBXA8dMoNe8TZg3E7hnTqc/fyxCYIJEg5ZZp4vJ6MRAD8AvlIMb0AI8qIATGMBeGv+BOSDCE6CA fzzBKaDBA8gaCihAEFSBE9jrPVjCGyDCAAABS0qIhwAB8w4ALZRDGGQVHYCllxtAly8BBtBAA5hl XD6bBTzAnfDAA/wCOLTADFQBVhYAEGhBMvhvf0FncLjNu3x2WiOHroISafsYimMXWL/LV2waYdP4 eu0cwR2OeEC4uSwnc2d4ulR4UrTNpWPmTuz11QXMRAx4w9rLdKd6YJcnQbjpSOlCAyCALORCQbzA OdgDPlgDFAxQPWZBOVABNaSBK/xDPAzDZVEML9hAOoSDLFjDEKTDF90CFpQDBsxZoQ1ALPACABhW FUjDFzWDHbiDPaRDNzh7POADOCz/ADWwQzosAx6kw0GCgR70AyhIAzvYQy7kAbJjIwAEerbpam4X vME/hcDS3azOBXJ3OmFo+kHUgKzdycTz2hNQPEt+iK6xJEtevK4x27NpOceL/LJVgTdk/Br82sVr eUtdfEt5CMevQRBo/Mhn/MivvJbDGgEvtXLGBUMr9ofPBkCbCVAnd8LaKR4VN6ZNNFBYZ4idQvrG AzvQKRTYg9THgyQUQWrWYxQEJlgkQDJcPSI8AjgUwK1v0xPwVVgRATvUQTq0Q5HDQTRlAjhofTz8 KzosAwtQA66HhaXEGMkaJin9D+3ZtmEYACvA4M4r0GxJmm2ly2ZyxCPXHgzNGAcv/5m8cDrlcND7 LPqN4WqBiwS2TB18lYXn7xyTfMu+gTauCkejZyFCKBhBXMAnEwQ9pog3qHYxbA/Qq9FhLDzZycDP GD62+UCMHjw4B4FrSIpxs51ISun3BKn4TD+RSr/1j0/5VAL4ICmPRj/2w5L3eE/5IGn2iz/4u8EY oCn672j6l4/7q3/4J2n2z7VcMMI/iIFEO0MrpwRaNIrXAkQbK5WeVHjgJoyaBgAAGBAysEoMhgCE xFgIQIEVK20sTvT48eNFkKssgJwoQ8wlkQxXmnT5EmZMmTNpzmRVsmbMljN35oxpAOYpGi97+jQK gMBRpTQbrLrgsqjHAVCXVmVoQf+X1Ykv0vXrA4DDqVOplmg4hSnVGQ13/FTxIxbMg0UxHlya8eZU KAwcej3aB0brxyd/chqYwe5fYsWK7QH1uAHdpTHJcBVh16mNDDjmcgDQYmnhg2TAZLQAIa1UAWql GHpAh+ZBHnamNFV7QI2UNnbPivn5ZUsDujr4yHmD5gSkrkUaA4OM2hy6c6YTn1yC+ZyqR8fRi2Jn aMVN9qXYveskWrXlwhmgzLOc2HPhVOnXP8qnD/JC1ukmCZAZRpcVYLBIJx52EHnhn3nYKcWEZ3J4 4BV22MEFgAWkGaeCDbz5Zpo04CjQHMBkKo+hKqwjCgMZ7sDAI8TYsUIBj4rpAYP/Gm28EcccddyR xx59vPEZBXbabqbtthOJyI+SFC+6l5Y0qScMVtGuSI8u6o4/k5LcKSr73ptoBiv8YBIAL10yk6Ht vEwqzS+dM5PNi+QjsSH3vkSTIQ1SCYlKhvAc0kqe3GwzUADSY0hKQ++byDH4YFqSTqQw4NJJDAzY CYg76MSypkgjPS+nixotlM9H55tPVEbtPLLUJ/sEaVQ7faLBD1ebvHUmGU7Blddej6LVVl9vvWBK kAqA4xlkyEnEHAyiAIcJcqSAYhpF4Glggm/SSGYTEdAJYzUGqOmEmjNEsISPf57xJhVF1pmBlk2M GAePf7wxTo9uMJDllhfm6cwA/zg2hGYHbeIxrpdvYsCCHhn43cktYSWemOKKLfbIAj98kCnYpf4E VSpCF8Kgl44/lQlPrVKuk+OQJ0rZgmJkbRlkLQVtb6ILnjHAAgIsUMACA4QO2meehz7aaKEvEFro CghgOuikj24AaqODjjpprJHOGumonbbagDBOhHJQJUt92SQ8jTxVUZfLNPvmmaGz7+Qq0/5J1pY6 hvTVBqwIY1S6/Twb7b7lDgnNnrabwR527EnnnydkmJxFmBInO7srX/KSVUUFv5vUmjnupfJFTSW0 bJflTJ1t1k9/Fe62kUIsMRkOv32pzmUXndPQd7+9d9cHl71jVd2W+9DY2Y7V7f+VKH3bdSQLN16r 6kxW+dZnFkusdOovlrjumEa4Q4XvUd+P16hWImB7xTaeOPzCfC3+Vjrpv/X+1y/2IRUrzF9KBon5 xv8I6KsGiKEKBVTgUnygqQU+EIIRlGBVVuakJ5xlaS5ZxaSUkgFYAGMhHvDGuoiBAoa4YF3PIIZE XAKFTkSFA3E5hYhGRCaGIGQiGLjAHbKRmPIVim9Myp/wYOIW59XHJbprE6DaZqYGqE100Gvd9GTy hDuYDnY+8Y6rKqi/j7CJiizrUhTLZquTFWWILLPZzJ6IRJwl0XsgsQ8YfSc9nfhMATHYIKqAyJAo /IMd6fgXE8qxhAxoYxgLGYL/OdJQowpEAR3xGMQVuJGKX3SDD92AAzm+8Ip1QIEdqdAGMPIAjR5Q Axe0uAULYmGNVwzjNJbw3SzrALn2AXIVhxhBFXoAhEthLot1PNvz1BhHAAChGGJgm3dWh8RUTcc+ 8llSsICiud9h7gmOOFUQCSfFy00RmOdj3U4+VijO2UlxcCyjm7qIHeYdb3d6E55InvmcdMbzgas4 hR/42U9//pOfbjjEH/wgUIIatKADDahCA5rQSyT0oAxFqBsgWlGEQvQOh8joRv/J0IbqIoEeAUIv /hEekMkAFI7wQ/cmmER+HiKNLa1KFQgjU5veFKcLbMk5r5lTN7Ajpgp0FKys/5CKWp1KfaijJhl/ pxEmMhN3NVTnGmXFzRJdUapZCiZ0yNkpqzDxbEHFXTOxGLdS0VF57+liT9e6VepZU61mzRs6S5W8 tg2VIX74B04GBdffJbWnUb3nM4sZOgP4ABQyKN6T7Dmfd7qqKd1DIxHj40aapKwnn/smTbX6Kp6u BE2fYwgYiQQpLxHTSatSXWqbuDm5ESlxZtqSZdeXOmlSFmQpU6IU3fQk+pF1ibAClaveycYoMnYi PtiVfmIF2dRdL7B9zVxWtXSIkA5qTl6kZ1oDu5CNDC+c4FwnSMRgUppoQA290kALlAIe6p3WrMUt 7Hxky5K1xkq3wBOuofCUXf+mdPGbaKWuVJ2YUwLqjCG6MjDF2tJSAvjBdv/D4UweEAt6sCIegigC PSwwBHpA4V8nKIcVpCEKE3zjQcmwRRTegcospGM305AGIiwQC1w88Y8Yosl3F9xjH18MuEaZ7Cxb d8RuusS9E0mydGli1d/BKSaCa+tztrQKAlAZb0chkkhacAr5zleY7oGvkithN49wwBI4gUAoTIir Zy5pIERpa1mFhdfS3m7MRASJgOcMTNgO2GNGQWsb5yqrOPH2mraaZlxB56QwmFckp4iw8SprTFL1 BK26q+/uvkzoIzekh7f0wXbDmLrgxe4iYiKydKA4u8exYwY+8EGsAcAcO2X/QBqR7AQW7BFJNRSh cZLMQDbiEQ9ODKEcGIDCMojQDnbEgxcPyPU7nHCDeFAjHCx4RTzSQY5s6KMPFJAQOaogC26Dwwbp 2IcgBlXeVdMM0Vsu9Wv3+6ZhhmyLbvLrF+v95VL5V8CoI7W81Xhocaq2bWL9sUv8AASYyOASCl84 URixGCvE71Y+GFOTGnCHW+4sDG0AiQPekIo7LIIKliAAEdbAAUSggOUReAMoUhEDApT8DojIQJqJ gIgIXCEVlajAAsaCCAJo4Qw7t4AW4nKHUyBCBn+gy1yIAAolmMTdE9f61rXeVVw1OLxWUObCWbEc gWhEIGlH+0bc8BC1t8EN/1U4+0asUAW6t+HsbRDD3em+drXzXSPT6AG8P6IAmWmlAQ33iPaecWUl +68mBugBCz/ygDt0pCoPUIhP3AB5jhvQKhLPSX51ajEiCZiwstv32v4KTuTujga9aLJHSOa9JE05 zPLzyCpGwJACRKEf3phGH1iQjHiYowqx2Mcx0lGJX1x7H25IRvDbkQ/AECAK+zBFL7TRCVn0Ixv7 SNgT8gUFcWjhHI4rhysQUYZ9VEEXg5jIJd4n3o9EbJ57dsMT6LRkSzPkNm5BD7AhBYygHKQAADSA GgZBAR/hH6DBGXqhMzKAFXSBHYpBGthhFZ7BFFQpBNgBDChgHhCQuzwizv8ETopmq9HEo55KUI12 aqoQxyfMRLMOrqe647buqlWoinX8y3NCx53oTWQQLbrkyLhOKwejigr8gHSOLHhOYQYubZxS0Lj4 q9BGKyZW4Yfq5FKqqSEKQBOsoQHG0FCExj1+KbgWYgxJSw0dQ2jU0FBa4g6egMjQZDuqoMzqCrwA YAa0iXiY7Dt6QQiqIAzqbhALsQoGsQrkTgjaYBEfERIjURITcRIrcRENkRDrDhEVMQwesRfyMAah RwWbCa5UkNL2MBTBbFD8jcliBYwOpcCuyY7k6a2WKXaca5Yw7oEwIKN00SfGZwu5zqsMTCB4og6u SxiTURmX8WKKizyWKWX/UgYDQIGD3gh/QKEG9Gwm+oy3oOrToit57AqcNgUVDcDWXGIaYyT/qAuv Tu3dmGrf4kgcL+v/vBEV3zGqbCiMyFEboyt/SM0F7S+cjKy1dvAPW28IuZDH3MoL2ybgfqe5TK3t CLKYNk0Hxay3lqebInJRmOfOyGS3jJBtUKohPYIRkCO4Vu15wIpUPjK88g0fkWd4ksoHjayx8oan oMeOykkKVdG/WuIhCe1JHjLeziS8EvIHdaLVniMa3ao5gGIOx4Mbv9EkgACmcEX0eGUqJcYR6u8k ZI8Z/2crWyp/xlLrslJYLNInMIAVrBGeKsYHrtLMwpKryKgY1JEhWKEa/wPSzerSssBxbgIt9JiK O7RI98KSRKLi9vjtJYRCPKCrp4onfp4gmYjM03Dmz2wQIWOyZk7GPtTkL2Hl8ABA8aiy0oAMVFCr CO8Jd7LSF8GHT6IpH+lRH4swNHuFKOdtNpNSJ81mSOrA4ebxHrcjKF+HFlPvVKxgFQYvi5KEOFPy GwMnjmiwNr3oKOaRWAzlIXoHrmhxiggOEDVTjDhT36yE9PBprO7RCbvJO7sLI6GE9ADyG5vJOZks 9b5piooiCd/TN23qGOnSJDCAn9AQQP8HCEChCQtUQReUQUvPBhmnfZ6h96ZTKxYzblZGOBmiDVih Bwh0I93yTuDx/wKDFf9fgn9OgaWG8fPUiSLPAxXuwGes5ALAUjWZgkDlszBJcw2UwuvQw7Wywyzp 5L7g5yhXsE8o8g8SIx48j3VsZc7oE9AsCzw5BQP0btLYk84G7t7GsxbfKyOn8DZlxwf+4bpYslAI 0kxBCwVFESdHdCKC4JYS4xkMk1Q2wByQAwroQRMAiR1kDBg8AB/ioR3KAZQGoQLW8TnA7nzYBDJV kLhOcZYCzskwJyc5sjxxJxa5NCZSoQYW4pcaxTGm4peopiFI9VNZIlSTklSd55ccLyk81QpXtVS5 cFaBIge9MD+e0Xza4BTcIAqx51bMsjnGFBlzp4BS7RBOQUh2AgPsITH/7OEUJhQr6scyceUPipVa a4InYbNXXjMVrpQhbMAcrm4AXEAXqOEfhAHGLmMGfiGREpAavoIhwqKHcsFdfgAduoAhTgCQsoEd KkEW/qGHxIEaEEERzIEKkKEUJsAbFmEbuG0fGqFxyqENNqMOHrYd+kEW5iENXqEcDlVJVuE1KyYl MGHjICgpvNDxTlUNRdUKq2kA4mMhVnZmRcKKqKZmZzVlPVVmkaJlWcZVebZNYhY6nuBkGxRpk1Ym HLMvBfIjNqAcro4waeIZPiUHnwqeQrLeXEIGqmMVyIelZDM6eM9XFBARYoEciqEX0uAF7OEZssEc BIEMuk0a/kJYMGA0/4lwJnrADTz0Ud2U6zpnbwA3dD7ze+zQOo+SRCQVp3oBXP/HjsJK9ahSN7e2 RemDZxTgElahGOruCYIgQwHgGJ61Ckpnjyb3uQ7HjhSQE2LhAlchFLRAG8gBFvqhE/LgH4ohG9JB GXjwBk8HA+YUKZ5AexKDGlriAhaxF4phBl6PR4Wwj3wiqEh1P3CxH2+nRI0SVFZGaz0iNy9y3yK3 qmTSpqJVaZXxEuJU+FIUaTFgGrwhThnhfOeXfrm1SJlERT4FLbW3zvR2PMgIRyO3BapgKECiFyaU ziZiA2Z3GkIhAsoAHMhAHTSAEZiPHBphHGxAHpQABsohDSJBGtIhgv/pAQhoYRSOYRlmQBaGAQvQ oQoe4WPNqUjzwyWAoICd1kd55W+/6nQu9359B3HJM3EPkrXcamRtc42Qcy67o2p/mLCGjDv/EkcN DnTSKHQTWIk583Qr5ojicTdzIlH0C3snglG3FAXx09Soyh3lEzvQatBKzSV/FHydMnFrtGyeVCSX JNPWU8/wSrt8l1GaeDNxxofFyQd/+CXVM9GEZ0n8CzyFCJCPuCaqwJb2t0mChSnlGNFwMCEx2SXo yK4amXLNtCC1UZQLR3cyC25E4iG/VxYpl/Uec8EMgBVAtn5vGTrGdHu8gb1w2Zd/+cecdyUaEjIN xRlcWRWrkE7/Nyb/iLKCWDnKCPdwrnYwU9HSZkAGZK0OVoEGZs0HHnc3F4uOI0+R3xIVqRNyo7Qn hayI0/go0BiRWTBMkZiZwayCnhl16MgAnCF58gyd90x1361G24l8662MLYdtzjPhEE88d7MoEKs9 HrmgtVUPwyumQBMip8vSdgKUVaU8gMsiMXprkaKgV48/RZKUW1OTc9F7UWdlDvp6haoYLBmYb7mB ahqnc9rHJNlK+Lk60SdUFjR8aDo6IBqChFWCIsWTj9VYQfR56TJJ9riUlSo9B8AZ3ikex6gg1fST yfgog9jIDlkjV7mhC0syxwuQ3Vl0BOxmXwKmZRkhkVqn5/rHlNh5/wOLiguZIcSAMbYHFJM5jxea rA2HneLIepETssQanbjXPN9xmPdxJsvRjQArsPjHdylljhhTU+8AW+nas4VRL8v6f/RqMdiBpz8b qiHMfOgPtVtbGFehF24YJggAA2i7Zy7gZ3AbaBRAty+At2tbhwwAA3IbuPFoaYJbt69mFeylBYT7 Z3QIuC8gug3guGmbtn17aXz7Z3Kbu3n7ubdbJO/xiqc2mqXXmmfJS+Sau2AwZ/RjLgmnRkHB4TyH D8ChATgAD3JBDLbBccZBDwDJHm63QPohF5IBH55BGrqBCezhG8hBXjVAG4KBEc5hGZJhH/BhHvyA HZqADD7MXu4hF//0oB+oYR/ktUixLIFNpz1VfPaiMzAem7zbWcYJ5xhOwSuh4qq/2CROQBw6Q0mM ABva7CUe4A983AA8oB3gVv5epgyWoQjGga8oVzucYXyJCBdFy7zTyut0Va3PJzO7/EynB8brxPDS 0wqpWrPrLSqVBGgw4FBp2wCcpgLesAGWJmpmtgIagABSwJYBwAJY2QKWRs8twFIG/c8BoEbIMMxf 8I0eO4sZOZi09ow+1B/hmklW3BT9LQhn5hmYNiZ2xipEjMQkwQXMQV8HIArKQQ1qgAOyYR5YAR3m QBd6IRnyQQyyoRQWggNGwwcewRzgoB9oXRhQARsYps+1bGc0Bw7/62QMGSEVxOLZ2aIOCkoMiLq8 UQZX1sqPrWJazWfN8dGOediprzOeg9UvZzzGpfx/isHGR8QbxALe4x3e9Une610sHAHenx3e8V0s 0MLez+Lf+13fxyLgC97epwHMrUIGOs8NQOEU/Oe0U5ypf3qLdZw8ieTbg1qII961KzcwFFqBigET bpwsQR2CNn2+xptra6AXGKFGWG2ZtxKe7csWzdlOsDy0lYJ+wFO+l+IZ3GBDpmE3ssHbiuMb7uV9 kX5DhO9ehI/ohW9GJDQVT+3RQYbU3vqU4yiMOb6lRHacv55InMHTzSyOyVkmSJIvQ7E+jUmJiAnG cRQpaYK2e4Gz/8nbrh1LzHuwJemZfJ0hbKv8JrPWPXpemV+CFdrgH9qgWKriCUChAezh2dk3rc+b 1E5zpIMsfHkLb3OiAGShcdABEVbiBoJByAGgAN5ARB7A3NihHbDh0BkCCoahYyTgG2jIKAxgFTx0 yKbZddid5CcIE8C5402iCur+fO9gvs0HFH6fJlbBCsh08V3CCP4BHI5dpO7AAP6BCU/hD+7gDkDB +/3A+xnB+7+//M2fLchHphqgHXJ3DFYijGkCAXQBGEZLD8YhDH5hGaJAHa7gGwBCCpRpK37xqgBA Aa1bAIrQg2IPmixxqMbt0LXq3Dtd6HodK5YuFxl0cgAQILLICf+AlSxbugRgYFWDlzRr2qxZ7JSP mzx7+oTJcmZLDHcwCP3p8ujRnwaQOmVJoKXSpwCWOgXCqgpVp1ZpNhiwVSpNR09edg1blWVTl3fK 1lxrdiWrNv+qsELLEggoA/8uncKANzBLGVWArKmCOHHhKm38rFrF6nGxyI+dPaa86p/mzZyf8YRL 9WxowUBhspopOq1Yn1Od6QxKc63oo6C7nk3tGfbq3brjrpbtNSnvlWBvpgZd02pqnxZq3LkQPLZN q8ij+oSb2mqVSy+LC+/t0vrUlV3bugTO81glb9+ysWPnPhs5dtTeZ3NvP397+PGf3XkG2G5LUafW d6qRZyBS2bX/ZEA8/6AD4FCrqIYeSw/o0sYv9FABDTX2TPPIPJXUMg8m+LBzzjiyLAMCNaXc8M8z 2oxjgUm07KNLP3XI0g81//RiDzvuPHMMO8fggwsf/WTTDyvpPEONPkkcOF5Vpw03nnfEJedSTjsJ ttxWdbSBVpjnccmTlqTRpOZWyP0ExCFvJrjmmtutOad0LJlX501WaOZNFXky1WeheGFQzFvR3Ybg VFB8k4NvQtFWoG8GKPdWbgwaupJrX3IalhhWgEpqqab+5IMfp/Zpgaar0nSHVqv+ydlmrr6K61OI AjDApTB99etKvjYwbFVNHTsTskChRmGywfoKbbJCRRssUATM/3StsSbBdGupOdHAmoJbHjinUEQZ 1ROmwk73lJk8VUlnd6+ClmcLjDR1VpsHIviTu/yuhIkMaG61IFtu7XtTcXAN2tIp/9hziQFtsALu TYMKpe+739lmU7npxuuvcUhZ4UaueGXsk6efDQebwgLyOlQvdyCkG7wtobzupiKz2VuFleZMoEvF qXtz0Qdap+e/4BkwwxPPPMwZO9iVxjLPFtMkXkvP+DqubwjDHJSa6s7EZ829TVq10jxZYIUuoAiq ts5Gz7ayztlpiTRUdRPd8cAGGvBEUWhT3a+i0VH5HXrILSz3TMVg8mmhBBzyxx2gpGJ5xSZvzvmq VdjTWd6dv/8U6+gs+RG56T0ZwAgojlziR+x+1Kh67T/JcEcltnPuZeHgrTTDKqr67hTDcr80tdEs 4ZwzoRrfRIAB0VsQffXSU3+99dEbwP0F3DdgvffRi2+ABdyff2kP9nzTAvjdcz/9+9pjb4D32d9P APbTb3/p/nBVcYi0EcwpoAjC78IUMroZykxWAUIbrNCLVcwgegOsiZaWE7KVVA8DvTjFKazQBuM9 r4JeQ95qFOg3ljgDE+AKk3eGtpIwDC9xPyvNVNqEHu8wKk3L45fxksc3sDmlTSQT4Nc2IA81mGEf dDBDOWKgghaYDw6I8AA7+vAGSxBABSNQwaUe0AIMoIsD5yj/RxIwIAMMmA8DF7CAUGDwj3xYYABl 2EcvpIGOM+DFAKyoUatWg7Q8ie13yKlSAdmlPOYZbzxVshmW+MXA4VigCs+wgsCSVpvfzWAGftCF MyoxghFccoF9oxDLYNgmStUwKczTTSFXuZLeNQ+RACDKKAdUtaOAZVoJi9vxfNcVlGWyboSDyj+K IYQwjHIlVqjDKjnmkgwkoxoPSIY6IqCHf7DjH5yQRS5sgA9hwAIcWKAHBswAjizYAx34wAZCZpCM PpCRHfYghgnmoUcAFOAV46gCHNAhCD3s4xjpIEekVHmmWQLgGA0oW4GCaUKzXPAl1gFN6eKl0Igi 7E2i+9rF/4D2r8UtLaE8oYEftHIUAlRBBS0hgF/M5zwSzvJuxIsLDLu2rZjiUmjKU+FrfFmTrWVw d0S1CQ1qtRl0FEMMRd1dTGhH1DukrqlUtYkuovK0Wp1CVlXtKqdco7kUAoARYQ1X3DJmpmEyDDRo 9Yno1IQzApwUqitxg2ZOEdZKEMGRX0PkPaXAAGqYoxHzGEQJqGEKXTyjCXkYxxXYcQYNUIMTcMiH EbQZpEWgghpNKuwL0CGFnZayJ1u7Wk17ctOWHJJUrRSX2kQ4mqTBSqs0GGox+zoc7+ALtcQEag9H iBa44uSnxtESI4CgNoh6pa0762vQXtZTGx4Oli3FRICo+/8SEHoVgaRaBV0ZKUSvVSehy3GoagqG yLOIdF/H0Y2WkocwMRRFjWK0wAjUqIAY5BcDBhBjG0fQ3wvwFwMxiIAazWcBMdKXvglmY4MX/OAE t1GMxbhu83jpXOYFsSuBVBpsJ2ra21aUJirLqE2K0VGvOtW7Km6xi1ti3hcjBQNj8AOZXGIF3Z3H DP8oxVey6Y10gINmWEgHfcAB1QEYwbHmUEKddEHXHoBCM+ywrYwNBVY3uYGrVzbVcgzgDCsbMbZ9 4u5pQxwW2AI3xl0O73n8gNTN9AI0CUjGPGQ0jgg8gh5WeIQ58lmEedCMD+XwAzWEQYZxDEEfYkgG MaKwDzn/QIAa4cgCO4Zh6V1oQx1DSIcppFGOSLWEFamI88PaMAI/nGIVq+7FDPq3O6u0tlCPm2pz AWCBO1xSrlIrIUZF86b3VgqhdNKSsHsD4pb4ABQkZdlzybvKN4nWZ7hVXJ3W6ls333akVdFhz2B8 MGlPF7q/RdhSXPZapSnAB7p+SWa0+akHkobavivfz2ayCgsDYAR1QAdDqSIDGvjAMk+QwTBJijE0 dYXezQYpy+ZUYoW+knBV2CZnGNEAkvnxe5cq37XyB74aXet8CA45yWFCPWKZvHwdrxH3EGK+jnM8 5gj+HgEqwL1KlAynRztEvsedU0ACdTzUJlrRf8cbj/UW/3Fo/jX0pDLrpcQ44buJiroGVRtvbxtr flAJwbjnxptLD+c17x6xSj5ylpvvuB7HOfzcTj2cgw98ZB+5yvMHW9GGRmKrEMMyibaUtehrJuju aZtSe3QVQm6PDjP1P8IAAXM8YxmZmAY0dnCKI40DD+L4QTKAAYdy/OAeodjDPLTAjkr4OQc/LscX qLEMIVAjGK8wRyVQsBIomIMVp5jGK6zxgn6kot+IKEM57ICPeKRjH48INR+WkYV4VCIP5aiEf1x3 B9gdwoBt7n6bHWFrFfvhCWI2Ve4m5H2eBEHH6Zfl6n5ZEyuMKjAM0MYz2OFOkzFhGhWYiRAWQUvl h11Dlf8lZcJz2OUTg4cXkQRcI7RauDVmsmU3SKcaGMAIMfB+DcdwhnMTbbBzzGQFMOVs6dZcG0hm SVEFYnBwPzFIGIUXz0BcCZhtrpV+z2RWE2cTKSZdHlVCKFQhotWCksKBZyNEg5MzWkc4GPZLC8cS D+hLGKZevgUXqaU0QsEIn2KExQRfcSNuvgQXGHAK1NYUFqALhzBV/sJhPNUSM1ADPrADPjADPtAD AgeHPlCHcYiHdXiHd0gDNDANYWCHcfiGeTgDPQCHhpiHgSiHdviGbgiHWMcuGRNxGSSAayKAi0SD JxgYlQiBvtY561U7d4BcLjg6J9U5VPcSGIB+YTEAh3D/Cm5QB6P4FD3gBj1AYnQlY6AQfnjhfjXo i24iVmCSgaoza8XTgKABCrLoE1bwB79Iin8gKwbQC1TWFBgACvpGKmHgBiTjih50CnfQAI1XK6tQ Bb2QLSzBB/PQC7sABhPADt7ADqBAC//QCdpAT8XQCMv3DNxgD+6gDkWwTv+QC1cAKSthBvBQBa5A D3kQkJ3AB9oUZOQgC8DAAtRABy7hCGVFGjlRAwZYbqSCXmbViRr1HccWXScTbTN4bw2XW7fWNUo3 ksrRgiY4J2rWhAezjDNEHLFgDqfwCvugBgRQXwogchGgBbnQX2xkEvUFAA+AAWUAD7i3AL9QClAQ D70g/wv/0AczAQHnoA9LEAXjgAIKNhMYoAI1ogAYAAfmkANCiS4YAAK/MAwvcQhu4A1xppPEkydi 5gibwQ6s0D4rkW9LAUYyIAP3hQEV8AAxsJgJJgMtUAERgIEGMALg0z4jMAP3ZQGB2ZQYKCwz8Jj1 RSwzwEbNh3sGs4AkFoPJoUhIJ1pIY2ZiCDJes2FPR0vPpIDN4zIo9JHK1YUbNRyyoSZ5wjhM9y+F V0y61IAxqVpfAltWkJcI8ApzSQHmsAi/MA/aUA46UAb/0A10lA96EA/toA9h8ArokA3msAvnEA/4 MA6RMpWlUGTPkJ59sBIQwA6DAAH48A540A/egA6dIP9Q6ZmPymcOc7AN7KAN4pAJ/5AN/8AL/+IH yigs5+NrooWGJKkxKMaJJpOM4JGbFDiJzkiiJWqiYaGLTlFEJ2oTfrAGLFonlTB/V5ZlH2NixEYn /rKFTUeBD6eGpKF1NmkgnJihTqeSUniksykvQ3g8omhl0BQ3QYRbpcYZ2VAM5Bil0GWE7WVBJ6lm DAimkGQ200UUVYCLVWijPZpmNNGLGrVLP5oxQppcZ/ZbPiiEzvU3YzouqBhRUJqmvJEvNoGcNaWE PrNDG7MoYgp/XzMTh6R3N0qKLqkuGGBxm5ENZwp0FzpdGPSjvPmSvwSKIeVLaGQFxfAELSCnAzha s1T/nK5JEzD4KamKK8W4Kv7SgrTKObiKFzqIMLoKjGrKE2yWiREYFg3gDR94JgQACh60jZXAfanp i6LiBqr2jVwDo2y6mteqrdtKoqLIrU9RBW6wCHUgrnXgQZjACN6IruhCeM4yLcACLMriKxWFLdLS A+e6rOhal3XpB5Ugq9/6EjCokZG6dcOZpcgWiUb0r5m6dTtIg8n2pwhIirhqbJaosME5bBELbjR0 gM92OBhKsGr6UUT1qHvEkhPIKSIkGki4qj61i4x6koW3W2qohHP6sb6lgyvIXgnym6IDbJ64N4Iq gQ0rqouap3vasTzEL8zVsm5mUeGWQsoZHSNmbhXb/7A4moUriV0wGVOuWkoJNIwlyW3aRoJp8UJA 57HJoyY1CrBt67bdZ4d2+ARxG4d6GLd0q4h5K3B0mLd3+wR8q4d127d3G7dza7d0KAOKWLcCl7h3 G4eA6wMCNwN7i7d1K7iC67h4a7c+UAN0WLeNG7eNC7iPS7iXe7egC7qEy7l324Y+YLieS7hP0LmZ u7mnS7tym7eYq7ubS7qRa4eJ+wTYKBy++qPFO6RWQ7YMCzZS2rJFKoNUkXWNI1PQFi97OTDEW0G8 KrFvm34d6rbey73hK77jS77la77ni77pq77ry77t677vC78k6wHaEA/s0A+I4K4n0A2nORMcgA5o EP94uhEBD3m/MgAF7LAJS+EC2/AP5YAGHnAO3qkCefAP+9AHEPwP4uBkLDHA/0APVfALmtEPglAV DJAMcSQDD6kZg2BmARiyRQusu4GDIzTDJfjC5HLDWKuXOWyDIlnDtPTDAxPEhzPE4sXDCuW8RXy0 MfxtxIrDTnwWD/AKyrASJzAP3tCT0/AFejAPrBAPlwBqVnAOxZAJ8qAIRoYP4oAJZSQIQjEDtQAO KPAA1NDG58EE7YALsnALIvANumAOR0AG60A9UIAOg6AaMBBqeuBOG1AOYAAAHBAKFvDG/aBHEjAN LNy0N+FfCqZgAsbJn7zJnQzKngzKnEzKbFTKO2r/KKFsyqX8yad8yqzsyqgsyq88y7X8pcK4iboM rb3skb5crLz8y8OsoVbZQelQDKiADs5QDmC5D6sQD9cgC+VQB9pADtLAD3YQD9MgDeHwBuYwJQ2w AMmwD6nwojRAC5ugAJFQxy+AD/MACk5QBuSgkFbgaMlgDVDQwJ4gA2+QCyuxAexQDNSACwhADbnQ v9CQB+zQC+yACwXwC93gveymYlXQjC5RCZmBk0jhA8fEVMp2ByQ6A6kQvyVt0oZiAFqABmjhAmpQ KjWbhDTACDdxAuYgBSthwthwBzOCewRgBvkwrU5gmExTA29QCgRgiDIAArKgDhhQA3+LqSzRBs4E /zjTUCu7OChBUCvZ8GoyjTXdKcgAUAbs4AmuAFAz4QK54NRzSzsjkAINQAPUIwMq4LoYUALokAsE EIdK8AC0EAyn2gBM0Akq8LjQEYc1sARdQQOnoDGq/DGO3dhMHBeQLTKUzS6WzSWYHRyaPdmSLRyc /dme/Rsn+63eKxoWAAQzbRMnUH26QAwuIA2iAADVedMEoAfs8AzFAAZ09A/g8ACxMAyPoE3NMAOy kE5GRg5gkBpV4CCm5g2rYBmWwQrPAN2VUd3OwApXepdxxg6M/RLVOQeygAsAAAXigBDehBBQUA7q FA/lYJ+PDA2KgA6gwAry6Qr4QA9iQA2d8AjrUP8DjLAGnzcE8gAGZoANlpYGegAPUZAPMqAHYvkv M9AL02uCvlbhdHLhGDuSGg62KCuSDvfhDhuxGU5ISephTPyzIc4VmeySRKviqyMGflCp/8BsNkEB 83DTAIAA5HwM/4AL2KIH/TAN3oANV4AOrGAPphAL1UAG9kCeX3Cep6AN6GAPt7DcqvIH280ZFLrh HV0r3nBSjvASCXDQPkAG5gAGURAk7ZAPnllORJAM2/TjK6EH5vAEsQAOMxAL/YAP/EAF1DAPeZAO 8TAPa0ALnCACBG7gY/ANgKwONjDo/wDhLiEDJH3Sl47pAAs+xeB4ll5mdbIGOmkAfrDdXCZWXs7/ Dn4AFxSNK2K2AceAxYTQFZUOnAd4hBwYp7ZONbmevFNoOLze67ru63oC7Lxe7L+O68ieNMae7G6a ozwnFLw6ONb27Ig6ZsmT4TtEL0O7b1q+GRigGIkBBGHAGEKAGObOGFYABFZA7lYgBFaAGG3Q4+wQ 7olhBYcBQlUQBodRBfke74gRBm2gACFuWwbQ720Q7v4e7mFw70KA8PHeBgHPGOseBg5vV88ABP1O 7lWA7vq+7orR8A+0BvAO74kR8GHw8cs0WisbtsqFZi6/qjA/hDIvWzRPkjbfbDh/PDpfQzxPbsar ocp7myt+s3UCvsLyDVpeDAtbE9P4D6vA9DBq/wE9rhkd6YtEKszBvMtbD8zT6/UqFvUm3mbwogvQ QanpsNGCQSubgQliP27YHrXBWCc00NyaYepaz+LjkWJzkmxUeFt9X7a9WacsCfi13lNS67HhhfiE vxt+H2yN/8R9xbJaW247FDKhWu3JeVuODS9Q6vdJSL2c/xMfSioqEGfeILzQ++JBv5xPIY6bYQ9h P6xEn+nwe/QydvvJC5I58wTcIffRgR4Z53hvMrNrQfyG4yw9avn/ArKaTzUY4Hi50cLVG4FMqPvk e6i88qjZvxIyIH/fTwQy+v3jP/7iH/7kbwXnj/7kL/7rL3/hLwTmL//uP/7xj/7tL38yqv70f//+ +//9AFFJSCUrVqoQAACgQcKEAxg+ZOgQosKJEhcCkDjxoYGHCBtCvMgx4UWIHilCzAhyo8aHDRSc sjCRJEsAImkybDCNnR8ah+7MbHmTJlChQWUWRZp0pIFVVWQ4srdqJUSbU5UWTXk0oYxnNGbQkEED bI2wYM2aDStDLdq0YNOWPQv2q9yza9vaZevDrd67dOOGDfLsKsusWU8CAOVj8GLGjR0/1rgKA+TH JIlSxqz0QrHMSn346RxatFIDl1qMRs1yxCnGTP6Rs4fuDBN81hzI4mXCHbl28s4sfpFrhS4wwSuE NuAsNc07VRhn2MbOGz5lGZLlSwGn3Axa8b7/2cN1efljAnDCN2Y1efx69kNHAtAlsuphnO7f04co oxdLkSFV3gdQPMsmmk+oAoHybyhdYjJqPvHqu68qkiwikCWgRJKBNa0gZAgKcXIAgI9lsqDGG2e+ AcaDdMihJh45MPIBiJgGwCOXMvqpgpVnjmHnH17MAOcKe6zRA5oxzunll3yGQCdJekD8j8OELGCl wI4YstImkjA4CEAALnEOP6EeoKYPAEz4RhBanPHGlXVo+IWdZ9KxZqEZfFiiAQNM8Cabf0iRhZ1V 4rFEj30G7eSVchxpJ5dIsHkgFl7KiKeXdDp5xJxVplnjl338PKWdZ7Qxh5V7CkkmHm308SMZ/3J0 kWcOWtZRYrGFJPPyMgStMqq95ax8yAoxHryJWKQMSEUGKTV6ENiIaEppwCg7q+InypxVyrD7tE2I Bg0HgwIdT/JIZxMmzGmCjH+UeYEdKBkSi0EJ0mlGC3uWyeOfY/ABBsgduBkmE2jE+MYLKOhhwp5i fimnVgtZsmCVmYxNqop/Lj7GGQwWauCOJzb0MiENkmmGEW2wqYEaQmxwJ58akuEEIgx8OG0AKP6Z Jp1djhkGgWRu4aMbGWi5RQ9zMLHHk0bQ0eWcYcoAJwZNhEEFnU3XiGWeY8xphJ0vMunGBWrmSGYe WMoZgxpRTDDnCz3ycThkuQHA9aqMHLqsCv9vZDApISt6eQKINIAAwofBgQg8cB8CP3xxJxAXnPDE C19D8icmj1zyyH2ogvDFnyhGiKs6VsxXjdywwnTVkaoDiNVTW60zijvzoNJtwDlusAYEG62Ni3// /Y5nwnzd9NmXXawYBVCzAnhGRAegjToYM8MedtIRBwWhEKDFFsYOIR6pKg6RFsteMcKPqAs1siKM qgwDKqOLot0w/oSyLMojouYz4BAgmp2WmC4jv145S0v3Y4gKfOCDVdjDHj4A1oEgc7xiLWt/uXoG BhSAAQtgAAMG4CAGLuDBDnJwhCCMAQEwMAILjJCEfgAe8LzxwPOZD4GyK15jdmWUVfighCP/JEAM FFBCC2zQAgRowzNW8YxnsKIYq9DFIXzQgxg9gRExvJg98FEJ++BHD9ioAAFo0Qtp9EMblfqGn4oh DXIcIx3eY9bcwFQUkgABNA+z20PoJ5QGtK9AfYMMt7oYpQdpyw/hm4r9xPQspAgyIuLxgY6w+A+p gGyRCdFDPwTRAD1xpJMX4V4/BgGABySDHdOwB+7uZwEDiISVHIECNlDQAALoqTEiuYBUKFgx4LGj CuqZYxzxiLxCkgEbMXllQ14BjlYupJVaemZNmtlJAzTgAbAgxC6FeZW64bB5WGRHKu44N43wgRyV eIU86iCLebCCGs/4x5ycIY1yoOKNjDnk/w2L5YfS5VAjbeCnP5czPkQKlDEW8MYkn7EfxxBAUVSQ BjGwgI5OaEIfodAeAcqADSw0rADUiFkG0IEGjDDsDe2whCya4QdtFG0efsAHO86xDyk8xgC8E81T LqGRSwRhdQTQQzn8QI1Q4IEdYMAIH4SqDWKoix21seYr4jEPaNghpufIxx20AQp6CkEbucid6roZ mkpcjB2gsEkVxskYbS4mn0nBQCUhlCBGEpM/NLHSDIrhhxlYsELoS99dP1JXvCZEfzjxwR1OcZoN 9cdLIgFkhLaJkroqEiIWsEcvq/CtpMxHRCqQhTl4hIhYVOMiJohHKhiRjG60oBbkCBU4Zv8kjVww gB2I4MM+dKHJKOwDFKSSxjxiIMwdYskZHNsmXW94vLc+iCT8I2eBBlCGfVzCVdKgRxOS2o9jgAcK 8ZhTeAqQh3iUMRHpmEY2wnEHdByBDOsY2TiSQJUAli9kO8TVRex7GGytUiM+eIYuiuEMXTjDGcU4 RjF0ZGBnLPHABIYwhAtcjGc4Y8HOaCKEB2zgZwx4FQl2BYIpzAoDT6OvcOWMQZEShEoo9hSrQEUv IFhLA0R2gnSscQNmsIpTvPgUfhhBJfppPMpeUrAsKQYIp3GxKrSAszicrEANUIy2PsZjr6uyipMy Vhtepb9a1l1RFqQRw3y5eJzcSo/FcGL/WxUFA1bwwykY8UHkgpk0jfkD8bikpx732c9/BnSgBT1o P6eC0INOBSYErehDn6IXa9WImYf5kCAYutGAZvSlG51pTXfa058+NChsjOUo86omWK7SYYorJceG TCRZ2S85i2IAGjyjDhI0UIQwACYG6RBC0C1gAB8ZMkcCYNQPAQIo7LxsYonngACS9LKlvZgv69co 0qpKtfVJx78KqCETk5KAVnGBaYfGB72AHmMMIIY2lLt4BtCFu+U9b3rX297r4YgM0HrkU2vlIoet IbRWfZJW91t9h0j3fXb4hDtga32DzFWvtIXrCRn52HtcxQhkfe/OtBrX16ZvrrvM8XLv/9fjCv81 vwUYcTwW3Nq8ei4hb3KHIfcbeceGVstDjrybAKuPVZAuRD4DQKQo18iA5fYtBzkTK3Ax2AS/oXyi rhWp97vquL761G2ecqtvO+c8Dyy0a2h0qHfd7FjXetb/o3a1NyjtWne72cH+q6SQndqWTAom2Ezy xwRhejcxCN/ZwxHwCd7wh0d84rV8ipqTWeYjH6xzhc3fye98IRi4g3ruU62HB1zW8QO3wQNIwMGC bAD2fTZDGB5zz9u8mliyu1Vef7/Yd3n2Nam9+RJEsVgbdu1/3Xl/bXL72Qsf9sffeqSRj3uvA5/4 uff6TO7W+SIHaCJ9k7yxQQasuy3Lxv8FhwgjSjfwS6pP+YQhrK/7ewoa2Fw/lcd76TcuFNIfS/6l BhAQDoH3qqu7+XdOPvuDu6TAuQD8P/swlv67OwPsrAMUwGizvW2jIAdhtcKqO6XQlQU8OoYQP8V7 jEPwqYTwgZ3yQNSgpRQrwRRUwRVkQaRogz+IO+rTI2HLCpPwto/IPuCjD1pLqHiwh3b4B3bwARuE POI6QMvCGwYMPZiTrIDTFj3hndRjOQ4priW0EroauN67r7gLO9HDv5PICIezoQuKwSJcOQ7xOZBh vZHLtoAjuzQUpqx4NblZw+Wau7Krw/MzOjL8p/1rMwa8QwvECjzSlRlIh0mKoY/pIpv/KDYIhL/7 87+dA4Bn6LUWdLWkKLaim0EM1MRIpLccnDRIJKdCSroLDLP5qwjxcYNB3MDMyLLBuIAlQ8RvqMTq awxBcsTHyESgyDhXtMRfhLjRYY9XzKG2ykTHgMAwWEU2TMVQJCzzmxtQDLmZmI8LQIcYsgfNO0AK scMrOT+qY6SXE0bHM7JbmYz9khZjkcHWW6TOE0eR27qXe7bICj0xBD7UG8NpITpLwhYJcUZQhEYK NDWi4EYmtDno40MLpEbfGyCUaKsqcLpTbEZiXJ1T+J1VyEV6i6DBuDJLzMjloEhfdEZUBMb2gMb4 U7qiUCtyXMJG4iOICDAeWwUee7Fe/5jJPpNJH6NJmtRJm+yxnfxJR5vJXugFXXA0nAzKVfDJnMxJ H9PJoHzKpjyFbDgxbpHCM5y7lgQKUFDEsWMIgINEaLSxG5yK05PALyzFWfsPiplD/Pi45HJAz6Mg oBjLnnvJ5GvLikMe7rOkgtRBv0S/TdzL31uM8fEkDSw7tGyAKqERbzgGclADiDABYtCeM0mFJziF 4WKJB2gDC4ACSzCWAcgDb5iGbwAryDAAIUCqiSiASBilU1AWX8nEA2mOcPvDG8sMQZqfbZo4vxJM M6ygTrzLLtOW7gNEwBRESwpJAMSMkNQ2dqw/8UgMLSuGARiATBiHHtAFcmiEdXgAPf/ohhsIwn8Y Bi2YhjAok0z6B2zIgpj6B0Qog/WMhVy4gnPoEWAogn+Ih38AhoUYgF/ABh+AA3M4hFhAB3sIByxI h/3MBTIohyP4Ig5okXPABlhQlX3wg22oLm1gh3gwhXzpEe+BzXrLs5I00RNF0XlzhMZbFikUxxwk CWcggAF4hW5oJQAgA3p4gljoBiOYBzUoA3jAg3KoAmoYBWqwBCIABUZokmSohh9ABzXgA2HIg3GQ gTx4BkWgBwyAmhmRhWEwgBuYhztwB5uEhl8IBzjJhQGdg1fAhitIByW6hkiAhu7CrWWAgn5QMFTI Bl5wgW0Q0dhMxXoMxd2MS7l5K4H/PEhbTMz7czZRLL22JMlABL+4jLXLCDpTOwnn5De9BMdE4pC+ 4cZKrS9TfMslWoViQIUnWlUYY9VXXdVWXVUnWgUnalUF6wUnYoVewFUFeyJflVVYVdVhDdZYfaJV wDAHJB2wM0a7KQaEwIDhuoga0AshkgG9qAAFkAELoIEKeICwYCWyoAEdMIAaWIIZ2JgVWBwUUIAW sCbNHIARGC4C8AEUeAAfmAEUMIA7+YVlqAB1nYHTmBkasIAB+Apl+QoLuJNuJYC5OA72k0RA1KZ1 7JUS1VS0pMFNJEt2DMzYizb7ysSCbMmUpIg23DhtgkMBNMXIc0bD6AET8aCJSA+N/3CBHemwGHAB XdgRYkgBItiRZdDMCIiEHYEGknqIGzgPAGCCUOgBTHgXACiC0yQMTEAEjbCAeEOKZ1WxZwAFP7iD PzgEP/BaP7iEO/AJsCVbsv3asC3bQ7iEtH1bsb0EnzDbP0Dbt8VbsdVbub1brxUwsnVbumVbs70D T7gDs1Vbn7iEuSXbP/gGQXU3ICDBFKXcyh0NR4ihaQhbBiK3icgCdEiDHpCFZdACagiGO1gCKJgH EBGCNvBPaliGJ5CFXAWHSJkU/ewHS9ioMfgGWWEHe8AGOMCH/cSFDPiFeKATMlhQH4k05UAKZzhM SbSJyPLHRoXRkSzUKNEFcJtYlf94R4gbuCScVPjhuieYXKPQzbPUo/LBNrELO6NjRIe8WFVzD9JL 2f9IX8B6uHSUv4X8ymdhvX20S33aIUldpOrlv4fA3Emyh3SoxIu4AXOIAQb4BlxAEy+opolSgxl4 hGMCgI/ihSEaAD1QBxf4BVwog3FYAj4Ah0zAhjFghzDY1duhUxXoYCy4B2TtBW0YhgygBl54rGdw pmJJjuA04tsUqGcIq9f5spSILMNIifojjUuITQo6RpXTxfh7y8PgFuRMzvmN2FscR8corly8Ylac tWdwgyfoEeC5Iy5LiG89Dh/wIB8IKwwIgirIE4aoAc0EAAXogSrwgRiYgScIAif/0LElwIBufYDO 8SAZaAANWAIAkAEheAIUoNcn8IG42QicMpA72DvLncTl/MUGCChRRuVURgoCoGKGkEW5SghnuAM3 qAQ/cANbtuVbroNbFgNaxuVdroRbFmY/2GVbrmVa5mVf1mVlLmZgzuVj/oNmVmax9QlPdg87skDy 3RYj26NonCuVe7n9osSwu0ryk0Fo9NgwVkcdTAiaE7aEjDJ81F8HNEtAVOV8dMuHwIATm5geGgEV 8KCAToGA9iAX+ueBDugWAGiDBmiCxgCFDiEPUuiJVgGIhmgZaGiJbmiKzqCxA4I7eIhU2BhOxNhe IT9CHIxq60iOVcER5ThSvoqV/2bUSYUyL/OGNigIg3CDNlBGdrMCN1DG9tnpgmiDKhhqnLYCpMZp nDZqpU5qIXADo4bIpk7qn17qnK5qpK5qojaISrhqrZbqqK6EKsAERgjGhEiFi6GGR6ulhBizhygB fDAHV0gHcLgBfCCHZzCFKggUauiHqiUlWtCtZwADTkIAZMCFOI7PbMAHePDjlnhRZ4FjA7AARpjl e+4s5am3j7wJlw7EMcaMM8YhO6JY0ZBG3SEAFISMBNAGeuDkzpCAb6AD0VjJ0bkDRPwHfOhchsgA Dp0GbQjP32lQdQCKB6iFeGCHcdgBWSgHMmCHxAaAIZAH7RkAWUiFV+CFGUiGQv/oDm3oh0uQBVsQ G1S50NV8iGfwg6ZjND+4PcwOxQwhxwHOZ7vqxPZFuXgcOUeA3COctAwE1QDEH+1TSJYAJE99iGLQ RqI7to08wLzsxh2kCucNJD7ABjPohgbIz2nYBnWAAnsgB+zRAnxAhxl6BmoYBx9IBkIognZKh4Rq BlLJhn6YbZfgIMqoFq6LkFNA71VQKAzo6IcQAXQwkxS+gSdJCA7QBnKg6/MYAVogB1AABb5mh30B YgAQgUCBp35IAz04pX8ohEDhETGQBtH6hzmghikvByeYiF7IxR363vPpPXSmaeFcDB8w68ptOvdG CjhOvCKmjIRJr3gQhCL47lf/WIfvuoRMeIc7MIckYAJ2WIRMKIckUJF4GAQyQIdT8IZioIZmwIN4 mG0AaF01h4yPRgpvYQgfaOMgVAGGeGvV4eyJeHU9Z86RuIMeKL2GDEevK0D6KONLLMeJcIO/M+I3 N0MtBExznukdCsMautqQ6fXPxl/qs2+TTu0mdEd9Ir4ij4GFOIF5UIJW6yTdu5/c0ZMbNNkzfAJI S4gqCANhUcqR5kD2po87sEleVUqlxHebVMonundevXd9z/eBv3d/F3h+J8piCPiAz/d971WlVNR2 PNR7lERj30M39M2T7uxQTj+aJkjLgtSvmzsn48Ivq1TRjm8yZuerqAQxAM75/+74+UD5jk8/P//i zuo1yoZpZISIHugFGgACGngCoW8/Fdz5ladC+AtJYunH0VgEXC/JGbhsWqcjbE7BmyI5DyCGp82f PNikiVgDdqf6sVfLo3ir8uO5yOqb4bM8NMZ2iEB1kw4Kk3fG+21UYHd7MQG2hDj7kW3G5COJY7sM sJTvmhDiiUAAXaAGe9AHqyoGbQCHhCmGZBAHMUiHVJCGfOAOTigBcwiDMXeFeCCteXCFcFDepzJ9 hVmRX4CHO7BPfCgHSOiHXviHSiCvUmiAAjCUdjCHNu0Hv04FbiAHY8gHIdiGcPBjkfABR+iibAf8 yvvek9zYk7S+I56bk6Pfb/8cSUz97I31Mri/8zwq7Tkv+2LBBI2jv7P2e/IH46TfOC/WiGfYbQFv +zkXX6THcZXA+mxjgHOYB4Cgxk5RPgxmwGUxJwWKODvoeukqRyMWOWn7qMDKxYBdLlrvMmGDE68Y smaK1s1IxslIOTvpSD57BS5GrFsv4pVqUIAMO13/CtGax8pcL2peoEishS0JgKZOe1xyCqCB1KpO qVrN2hRrVq5ar34NW9WrWKkGtlY9K3VA2bBqrWJ9K5Yr2a91rbLlKretVB+M+AIOLFjws8GGDyNO LNgAK8WOHwMwUAwyZcpkLwNxVHkz586eP4PWSrYXBrBSveodi7ZqXqdysd7/Xe10AOrTd2qols16 quumbH3zNpt2dvDgXGkT1x1ZdFMCrGPvzVrlr+nfvKObBm4Ve/bov7FaR9uA1TNWxXSdd1asvPpn q9in19WeVftVztSTt+8M/X5nvY4V40w86XjzTDGupGeefPipJ1+A8zlT3nrmwUdfMeRd2N8zVvSm nHDF8RWdWndRJRd3WTl3WlNvfWdXdrCtKNuIMWYVHgApqggcWSfC1aFWNubo4nJatWEFj7klFyRf QArWgAHOFVNaWNbFVlaVoMGYVXRVwihXHRzyddyHXeV2pFuDmYnYJf/88wyOoaEZZnNKeojkV0Bi dyVewdnI5G5zCUljYJcJ/xrWlXoa1osKoDFppp9S1cCmpJOuQudhj8L5GKJNuREGc4Zmml2oba0p qTeKnZgmmXBuGuiogGFap2KxhgaeaWQ9cQeOb2HX4pCWivprocHN6FQVk0o6zafercZrbm8C4GuK cckqbHF77UVttIBq9QR1w+Z4Ill9gmoVtDRCFyyI1urZgBXI/tPLtMFq26O14BLr42o4YvVmXefu FR5yq651bbMe3lXsocCOqWWQtgoWXmpygjaDH61qCpkP9kzaS7GuIqaqw00edm5YlbjxlbiAYTxq y70dAi+bbpL8qs03GxbrwnsSrO5giIps8pVAHGIyu3d6RSu92m13CpvnVP9ib3F3UWmncT4r1xrT n5Krlcj6SvaaqDsmN65yYi5Z7cFqN5yVH72s8h47ca9CWlVG02W1lT/2nJ2faGO9XbByWUcu1br1 q2+hegLp58BmMl6zmC/3DcAIlYgBsWgEjKACBp1j8LnnoIv+Oeine1466qp3TnoLTlsR+uql0z77 6rePnnvp825dLsOVlzncV4cIgbPKgbMdZLbHZ5XGHZeGvJjLyK/ru94sc3ZkXStXzrvxTVVxCSNS frUK+Yq1i776X1UCplmpjP99YkR/Lb/9TfkQ1f3789+//20RSnj4Os0MimGFHnxIUXqLjRH+QQ8U AAAK6PAEHuyBiwY0wAP/8biEG9agAhpUgAA0wIAPngAEC/ABGyqQQQNGsAQD9AAIT7CAHuYhhFNI 4QE+AAINGjCDEoKwerHhypcAoIAnDEhSfqgOz4CnpInhqE8kcgoN/HAur7CoetXi0o8COK6XYUuA TgkCKEyTJ4Itz1Ja21Zdhji4T2lxNm4coFf45SqMNW41NspbwQjWKu7w0V614ZbUklcVE1qhGO9h BTvOFxgIfIMQmQAHAJjwjSMAoAzYqAAAhpAOAyECA5nYBSvA8QBMSAMf3ZDFMrIwjSOUQR0Z6EU2 0oELPZSjB94IBTVukQFZWIMP4dgBNXBBSKu4gR0y+8cdLKAA6w1wYEna/5ZYUqUVIPzhAol5VP3q xxy1KE02qAFCGQEDuTvVTHA10huQ6hW9wBhtZNQk22Ho2bschRNPf/qfVRQ4mALIYhg+wAI7JPEC fHgjHfRAQ1M86Q12TAMNGdgGPXJggnRwDBywCMYP3BEPfGADCv9Ixz+sEYV+nEIapRBpO+TRBz4E AwTIMOZh3GAFMRQDXmDywR0uAYo7+OEOi+JnWKxwBwQS9X65SipTm+pU0KTRKW86o/Xs9irKUW4w 7VvRCJ7BsX/UQTQGwIAB/vAMP/hgB6vZnnbqNcdBvqgrJHSPenohBPKxdZ6FXJevAhVIIfZRr/L0 QTnF2UR1aYuP0HJnHP+pqS9aOUttxeoaGxUnG2laTWRZEhEcp9ZZx9JTijkCHPM+W72oSkUGQKgC ENbQ2tW6tgqxdW1sq8Ba29q2DbZdLW55a9vY+na1dfNtbWV72932FrfFxS1zb1vb1bb2thbIyhMc ORdyrsKK05SeY++pmBZYoWiB6VVbfhPZ8jqxcksFmVjCuc9AeVNQU3zYMSkTT1H5SmdSo2x9qTel pxqvDlUA8GH8kArxEhgAVYhagjVW2AZDOMISRtzd9vahNk7PKpX4h3XZCxk+viVLe1URBoDgjCos Kmnr7Btj82VapxDvvzLu0F9FbFkxbnFM6/VsHwNIMXxVDVxiu5fZvDv/sRVb7Up7HGB3LzwseqpY vmWhqjrX1WIbT7gyYuAwzrLqGANc4hRCS4yXgyUDRuxsM3+7HmIIm+WyuFfNXvvZ/eIrPztDuA3/ GMFhvInnzYzgFHVQi/ZeTBkMCLXLNuPpm73baPuVmc2cSZ888evhYZlIcVHdC2ExcIpNXSnTbQkx HbHm47EFoRjF81GVsrhdS82xKYyYgfAwS+obVblt4WmDI2RAA18D+9c1APYMfi2DEcgA2DKoAbJ/ 7WxgI7sFwU72r0fw7GpPW9nLHsGwn+3rO4Q1N15ELDoVd2pCzvFjPQrYfE+rx7VJrVX1WiMgp8ks Jj6aMjI4BQCK8ed8/1di1USl2fdsChiA/mMQnSlAL7NqBQbnO+ISrxNq10ja98731iPG8mkMUCkA zCAV6RW3GWWFYcue91f1KhZ2Al7Nsw0KYVnBwGTKHa3Y2GixHgpDyvgCB2hgwRwpwMI9UiGNcpAh HcR4xTx6oA12sMIe2MjDPqpAi1tAYRxZwAc77GGOX9CjEem4BVVGAAQW8qUNSwRRGNsWzyHjU3Gx 2tKnsrTkXx0pYKL6mo1BXGVuOlqMKYfmq6esHM5aOJ1NCXRTZHAHHg0Zz233o6EvDYAWMILuSC5t lPlShUMYAIuGd0wV1l6WCWjDP+nABhZeoo1x3OAfxUjGOISQDFEsgP8a5HiFPLrgAnfsQwoUwEcx qPEMWeyDFfggOwAwIAMMtErt1mtZpJnsbuW9N7DLUle95Rln/7J61OSeuGOsCgA3iIH887vY/xyB G5xZoeeDKQI9pgsAE8wjB99Dmfr7P2FKg1P4bR5frdU9rdloZYcfeIpUnIIMHJYcjRiSnVvPPEqL wZtp0AC/RUYPzEAA2guTJNaH6Mwd0FrbTKA3oZ+1qFuVVd/ICUsKJkevXJkECpn2wdXNvVyTUU7h cMvJrYqoaVGVWIfO4ZrPaE5gude/qcujgCBiAIkPaEZV7JshBdaR3QsAWV/2yciyVMEz6IIySQo7 jJmkSVpsYAAqtFv/k/GNVDiTBZzLw2mJGzqJAVhA6BmAAVxA6EUGAdjhWdhhHRJAieRhidRhZNDh IZ6FG9ohAdShAehBLnCSVbRBuJ3JZ1mhJWqfGm5XVoWg+GliY93Ty7RgiPifYzRAYWQF45WilYDC Mjng/TQAEJheZTTAV8ELKKwCxDnFA0RCKokDKsiDH/xCN0CBPBwCNTRDI5hDG2SCOGABPRgEODBB PHiCLECDHXzDIbCCJ/xCP2RDP5hCLITDI+yDH2gDKEhDOmTDP2DDNiSjPgBBLIiD/iGT+6ziPebb DDrZkHDckAVZE/mYp2lT9RjcG63LidjIClqWjX2MyFTgHSCL6Wme/1TZnJ38lVOkAhCU1pz4zggs 0zO4wSw2xQT8Q9e9QyOUwwjoATGWQw7wAThggT1Mwzl0g0O5A0Kww0KQQx2kAzugQyXIAjscAzv4 wSsoQxHwgwzQQiXowT4cAzqkgjaggQ3IwxJogjmgQV1Mot/MGYshGXZE1kW6WNuA5aoEkqulC5+M DbBYIWbpxsdIDDTBVVqCCFfgDRne0Y+1BQ0cgiPtxVHhJT61Sl/dGKIkpKPdRSooERZin5J8HwD0 gjbVz18ZgBhUwiogC83EXxb2Fy2WBRw6Rji1oHv52A1qIWO2lyfS2ayc5vp84qs8ZgTUXFk4Q+dR YQ4Ohp/4gB9Ygf8fiIEbVAJvCmcduAFx+iZwCmdvGqdluoE3/MM3FKdN+QFxjgFy9mZv/mZwXqdv aqcfRGcddBhfuNxjGMAhaGRTYGabvIUQ6GKW8VwE3ow9EV6ftWbMTRyo6UhivIlziOXRXGG47JOT eEylNQUGyMsAIkrSDBJaXuDWmF8DhE4LRCJ8bkfoYID9aQUjhokfnKcKFhIGOIMY3ddVuMGAMeAz 7AX/reVqPEAvGUDntABWaIA2cEILTJcCqICNOoUCSNt0YUALQF+EQt8NkAMYcFFxWEFYpWFwxFNd aI1a3NcBFl6duKU+dqUPPiBVXJGlfUg8ESHwXORjUqhTXcAdvGL/YFwCUiVepsSGPwGAGcCDE8hA DHDAJVSRG1zBKZxCJ8TAAuipJUSAFhxCHmQDOoBBtJiBOsgABySDMriAniKCC1hCA3DAIjDBMsSA FpxCKjiBG9DpIqCAC6iBU/iBif7OWFTB83gZhwLGTQXGAyRDLkBCOTiBHswjAGhAMtwCE7ADKqRD PJzDPEgBAGTA07GDJ0TCP3yUONBCM4gBOgwCDJiDkQbGZvqfEgrLKPoPtsplYE6erOgTXpDFfTne 8phJqWZW3QWen3jgRZ5FA66IGZRDJbTBEgBAEfwDOEQAH1SDArzCNfwqO5CDH0gDLgxAHozDikTB PhSDNMyDGPRk/zaYgxhIwzJQgyDAQD7gAdexwzWKQyYo0jPQIwDcwROYGro4hQz05Ub+Svj8oFWA JswNyQPUAj3YAT4MiDVQhQZsQz+cAz2EgTSwgza0JAC0KDucgzi8AYHEwzJcnQigAx1QwD8AQyRi mFxYq16OZcm9ZtmcKpdqUZPaC2oRHmMlzozR5drE5XgRqGtiYmcCz1hdQhBg6HxGRhgYiTnpLZlV hVURABTEAzlkQ0iYQx3oAjS8QjzEQzksQREIBDbMgCtswgDAATsgQlMYQTf4kCwMAhY8Lgp4ADVU 7Qlggwy4QjawAydEQB50gwbAQilIBSiYan1WxdzSblPAq2BsVf+jNYAQyJ/ZTtpg2FERsiX44SDf yk/1QQt59R9PnQIjMMIl+EBlyIAfcCto9AKfFdLf5gSWlMUlzO5hmA9gOF7dAgYG/MEhhGRIXoL6 +kH6LsL71kH8rq932m/9pm/9hqQfLIL76u/9AnBIxm/+emf6EvD+hic+KrD/jNvXbiQQ2gkGhMEq DBrctU0NdsUpaO/xfqkFHy+4HJmP+YEu9IJ71M0qKFLcpHDdkLAJ90IKr3DdrHAvsMILq/ANp3AJ 000O17AiKZIulOAVYikAPMMzXXCBftzYNmj/7QzOmSCABh6haFy1eDDwrJGSdB9FWmQorqFj3oo6 8dd/TiBHbp//ACbPXqjAHbSA1i5pjHjFIYTvjYXmbVoeUWGMAaDiqaErjq0p+UmLoTlpJr4sX4zo kW7tAF2v1qphwjzgAk8FokHf9zQAWjmyUzlJiIpFzFbyJnMyUQ2eheWRFjdyd+WuOuWVYcHaVzyc o+gGYf7nk1Eem80lfI4xm92dXZCTKUPFIDfMJd7aObWtYVziIQsLu0mZHNNJZN2ywaSrigzeyQEz 2Cbo2wpguJrm0gRez5BtnJTFmZkvHWsfZMFs5iAzOEuWJcMnBPNxqorVKvAdeVLMKfMY23VlHRsG d4hpPTkhbgZzDhYZO1kGGU8pgV3AbPLTKgxVJ/fPH8QxADje/0AqdERLNP+I4jEX4IpWxQWsQgMz jHxO8RaSBdFsKTO/W38dIRTTyRwNr8x1JWH+Ixy9BRyPhQFYgan+i8x+tGkGUlp2orldtOZ54F6J pd7ZZhOlXJacXOT0mCAt9WXJrE83aAB9NDeTJars8wBqRfki8v7kz4ia4mfkM5ykSQvcAURPBQlW Hj+7rd32j7y5IFVH9BBjz1tTD+WIjIGGBuCNXFen5lpXRlgjb2KMr1M4wfME9lxX4sQlsuLRNVxP dGLbslAjoHKY3zxX2MgcqTVXDl+7MWr6zEtbdnZMVa4VoRVOdTnLdTuxwvlESQQqTLxRqfFGkegR b+8EdY4Zkv9bgsjAyCedmNcSr1i6CU9Pp+3VdG2anK1/1iUql5vfOfD9VMEYaCvOVNFiP3ZYlJ5T /EEYTPd1e/d3d6uMWeCYNp8jJPR4xxXnIYnAYFk/3hTzBk6ZYRUWG1l4UxnLWkBjgFwqDLV3qdt8 OXeRSTXLatHgpRFoF0oasVw9H/NLx1pUjx+cjbJC/jONKA13AGFp7qOdWccnu0oWA4D0oVN/7gkj e+ZVWEHsJI9XL7EhV1Yfn3QUCVA7MTiJ4HFTzEAvEKBVcyZieBmJr2Zjv/jX6h2OKWG4jphCfhgI YzMfxzeAjYCOq18DHML0gjdl3LgB1OaVc3mXZ0/cqSWB/w7/BiTxIYelzAV1q0nFSj+1OEFo/JC3 ixPHg/+3LNfzLLNtd4UeKDhfI1QOQmYfjbfFl64tgnNNH2eiXmOwMNMY2KZNf2nNrtBgUw/J2nKX dty3IAvWZ0BZ7zRAD0yDNxzDMzDTHSpiYObmfHo1j2BAGxyCflkehqP6n7SxpgcJtNAKFJ5CAu9V N+HmNvc413aynij59dg1Z/iLrTcWXCn4U/XCMh3CPWZg+nl5YBDWYEe0AXwDKDDCHTgCKHz7HaRC T4X7uH97uGOCKfxUuKu7t/+Uubd7ua/7u8+7I5w7t4t7vYP7u4v7HZCDwFU7A2+NtvA2tyxzU3wD vBgx4bh1/6GMdMGsXH1tCgZcArbX+BcfsQhmYvcRfPDwGDADoQz8gxAEkIOzF2H2tKQxS41hpj2w gw9AtAHoAmVkQDKwAzuUw6FKVRmYgxyAxiKsWhO+GvAOPCyPiZQyT37JcYUfvfBSGCgONK2b8wjY 4j+cKSHBJX0xtqBgKwZUQS9It0Wv5vUCNsg8eOP9Q0NX5JoHc9kHho1YQNWzSTEAgX4julWUAFYC gBHQAxzYg3M+gzuQQyU8XTqEAxOcwz/wwoQmBtDbZzbffWcur2cbL9u4lfVV4KVDxrG0SYN52ZFY gSP4wdUHvMirKVs/1W7+Zi+QFLw8g7JUflaUADogQgb8Av847AE79MI0MMIvKIMnQQMrLAMUKARl 7HGodLdjT5gfeIN59Id69EcxAMgzIAh7GAh90NUzQL+DAEj0A4h8uMczZEODRL+DaMh+BAj3p78z YMh9LIiBREh7uH9/8A4+az1KG5IIPYMYBDFp7zZAAADQQODAggIJHjw4AKHCggkbRjToMCHDiQAs HoSI0aGMf1UcPlSY0EBIgRlHRiwpcGXCjRoLotRIYEavYkJkyHho4F/PnuxkGDDwTOHKiykBGEWI gSkGgU0bXCCogKkFACNeJhV50KhSgYdASozoUizHi14XwjSJtqXao25Jcg35cuNLozKz1l1rkhEN hyIuOTX/WbBGjIIF3pzqBUahi0Uz/ugQyGHVqVOmJA/WfBCDjwohHX92WAzt281lT6cGYMXPKQJZ VceWLVvm6dImfTy7MJt37949TvnxO9hCzztAuHqzvJx5c+fPLfdilGr59ObSMZ2iDp0791TewvoW P5480vLlUcI+yMiHww3ylgiEYs+evjCy2NnDNoYbP8YPkrmlggVOYSSdeOIpBYpnxEDHC4FOmEeN GTRZJot22JnnCVfi+cccKr5RYwNy1MgjHnuW+UGbbP7J5ZV/imnEHnTGoQKZf9IZ54iiAHBmJYs2 IqCg27yqaEixINIrpCp6cWOGuRy6Tb236JIrotpiYqms/ynV8+GU2bwqcjCGIJLptixDAsKP89hs s0310LLrJNSOdAhL09rSyizTrkTTvImkNCkhIbU87c6C2HPIBnPAeC2Lb3rJJhdWdNEGnBVgGUag B2ixpoINdNmFmmaoyeWNZ8L4Bg2BbiCnDyGoGUUac1bp5Rl5vvDgQ2QsocCcS7ghZxVoxtDFmXSA wYKcKpIRFppfxIkBCnJy2KqBZwgdDLYp3SzNgBlyq0KFbJHcjFvVGCnmmVWeYWVdZ4x1l113XSkm 3nXbbdfYeo3dtxhWjrEX3meeYcfYVQJG+F98F2bFGXflzZfdVZwJmNJ8F27XGX17gfLPkY5zU+SR zxsANv+8bNOWIkF9O5PHOd2ik09zZXYIlCcVcsANN/xoowctKrECDQ3EuESGBqxowzCBhPDDDRQe sMINMdSoYQ0V2rAKgAXW+IwIJyKowo81GtDgEEXQUUKDOtxoA4UM3DhkiQY4cKMSJR7w44kZeEbD gKbd6JoiVlwmeWQMLrmDkRkONRyAXlRI7dzBFHijiSsKvCONBrRIhRE1GijAj+nAmDzm0w+ygJXz QHnC8ddhj1322Wk/DZM/nqhC9yqC0D13IKrIvQrggQ9e996FH9535ZVHfvfiodcd+DGgqQR44aNX /vfloXdeiOTDmIZcI8+SPC3UkRIT/aQseKIy3ckNqST/OQF1q6RTdJrtXIgeoEYQTcShuwpAIR6I EMIz7rANXjRgA9MohWa4tDKHqE5lVlKIDy7RANPRTE+pIVLNJDieQLGMgwXJFpBISBa47CUkGTFd kkySEW+Z0CSEykvtfMOIEeBwNo1TyJ3UNzMhzkYGQAACKIwFhAtgIH6p8QY+vNEDhfSiBSTcSghD 0j9CxGIZGGhBBUzQizT0gBveaEcpMDCEb+RifVesYEEoOCQZtOMf7BgMBhRgmSeM8CIwrFmYCrUV QBYqLnpaySELaaX5udFjfpII/WIjExnWkJEqHEye9iTBwp3mXCjjoe3y90lRjlIhVbjDHUBxBz+c Ugia/5mGT/4xDT/cL3KOU4AbdOCCS4DCD4iogC5B0YYKFEAMd+iEFeLzOgusQiCpgOU/snEQsV3C D2si5TWxmU1tjsySJcSibFIRymuq70diQUk5Y2aU/bHQY5Y0HQYsgIELjIBixViFH7zxTFgKpk79 lEhXPtYbTAayIeqUIEEMYA99+kQXFliiagZ5OqVE1IPpKyGc3mjBk0zpLm9BIZ0K6UdBfsyH53vL QP/UREeqxaBWUunLlNTIjA4mFTVQzQa9aRqcvomGb4Sk4fygT3tYAQOQs6LMGLAKhxVDCYMhQi6m NAM1VK4PO2XnTIqBASC4QaGw7FhsqpRTRo61m5wEq//+2ohS35QUrTId61tnqtGOinWbDsHEcOqa 12w24A7/sMcp7qCUU9RSPBtoBzHqsIYZUGMTHPiGH7bBjn8EgwzrGAI9eGAEcGghsi2KxT+wQYtb FAEf6NjHJkyQDnvgoxtWdQgGiuGQGZziH1/S621xm1vd6lSilXzkZp5xyPrVLJFt/Kn9XmYlJXEr kS3liEi/qdZ/QlAhq9ihReV3kAmwYxBMaQAT0NEOXGSAHcWQhTgUMY4rsGMNZRiHG0aVDXAUgR40 +EUwZDEMDOgBG1cwxxEqq7UxkVABsY3NmV5isuR+dIYqYWdMkxtdsmpGwYZSi3ogEj+XlWkhKmTw WMn/tNKA3tCnjJwob1zLmzCt4qXf3K0PESyeFJOnF/w0q0MKIIQwVEFpAHAB6AAghDYEbwZOsIAG 2iCEJWBACFUQghNUIAQ1aCAGYbNC1xTQgwoUeZMQNIAzZGy4Gd/0PKUZs4V3y80f3liEZD7qbHzU pi5rZs5s2uCddnpmzawCFFawghgqQYRAB80PYhDD1KZ2aEALWmp+Dpqj/WyFR0Ma0m2I9KQtTWlJ X1pqhka0ogfNGkV/ug1+IEqazxo7PbvVn77haFwzGeFRsnWmZXUxIa2YkDin08Epu6JVyUfScn0s fofi47mUApEYs9rN5HnGP6xQnnW++aQiSfav7dTH/whPMjUfbWKFewozALT4wQTtIJvPbW4X8ibE a6busJ3b61YPsYWDIfc1G8BiVO+b3+V5tnH6HXCBD5zgUYrhJX+LvkTuOrnjK7FvYV3tgApEwwj3 6JZknWAr5onE9KY2WBXQi2emwnzNRk0EBwyTDQdSSQDl7UGni+vs9lZmGtd2BWsTVo2eDoghDCtK i2vSYKfbdBzfOUiRUhtJ+olb2Jo4nTej9AW/dYMdf3q30XzVzWwyrLaG+FuqsFBrprWNJT/qBut8 a9O0W8Rmv0hJly7Qkc3V51B3d8rJg2G1o7oBrlh1wQEvykostCeXCPzhEZ/42q3EhuZx7aBkFtyj O/8e3dyOda+lPrMKn8nMcJ23wa2V7XcfpeNVUp/VFUKDO7R1iEEE/UgpfjoS43nvodeTJ7PS7kJm 5KWWv3Dbh/1RC3LrUMVFZ4fFfUUseUX4r7+5iINUPo8fOGZWHUAxhHTDOge97OaW9cxH//26Yxuu JbX5vHE6bc08YfUWD7/EV+h5idyJ9rffuuhnSuuKUl020WfTsl0s7dKN9LCuZQ6vAXTh3hRvAbPJ BxyBASEwAiVwPCBsT86voGTKjxJwwvaEnGqP6JJP68gv9syurJQt6uAqkTbC96jE+9gpTggKIrxk 8kCIBsft7qTP+ULw/bAr4nrw6lZQB3dOhY6r6z7/7wbH4uiKTyyM4oQmgsPABGa6CaFYjSDix3T0 j65M4hgarMx+CO3EbUqwRD3ADfjYTP1kx+a2RTZ8ABRm5kwc7urETwo/hvn+LuPqJD1iQwEVrv/+ T8WS6w5fbw3Fg+tczU18aAPHIwtRbK1IpnAYsTcEMRIPgv3cRBBzSwCxiRKxaZM0EbdOEE0uMAkt 0K0QsCTize5YauZQ7+fczuUqCAa3onGa7/JuDi08SZN+MAxJUIIcsApJEf9gJojSrywoan2OT+cg b+fupPfkb+2ObhmfSw6xyPVqUC1ycaXQaeiSz52Qzy10L5A4MQ114c5EMPE+kYdWjmQagAYesM1g /ycd3e62CgcTqc0aZwf1fBAHVa3m/igFQ9Dp8K7tiI+4WMj/5tCHoOvjbK8M+WTzHOn89BEj6Aej 3IIGbOvkLGj7OiLSPJLTPDIMPnIkAc0jH43RrIDRUHIkQZIlPVIIJs0jV7IlPzImXVIkN83PxEAn TdIlbTIna3Imd9IlPXIoaXLTZjIlg0bQGA0ma5IoofIoifIno7IqPbIK+NAW5ZEfB6IpRsAZWmCJ mAgJxU/P+CjiJocMcU5kUgynGLHOnoARWG/YTgMU2mMCdcse8fI8agy3ZCCfFsoN9nIwa8cSecgu CTMxFbM3+tJ8knH/hJArJOuZ7sCPXi0YX24Ezf8tpi5TD58PF/vpNnJu22KK7ULRBUfoLDEOAGYg FVDP/KrPIfwgPD7wGefxElPNNtMQ3d5M766RFNOSN2tTIZ4BFKQoN0VwIrPCArqqJ8TA19iNK6cR /NqkpGRROCcnCyfSHzVvLoaiEVvNZYziDlxHI4QCAwxA5waQfWLQANDTAqRr+ljOBlWoHt1vPten Pn+zDuWO2UbPPukS6eDqGU6hPfSSTTAAMJ9zMRn0EU8Nh/gKOQ7iBuIBF3rgF8bBAprmEpZAA6pp EVBAdO6gDTBAC8LADeCgFC5AC3opITIgGYCBCJKhGoTglJyAb46MRLXgDw4Bb6oJEQ60QYVUIIr/ oUBT413saV10oRjspV3UZWKe9Bl6wVj+RV1YgUmp9GCy1El14dniQUudYUrZxVbqaWKotEyjtEqz NEpXgUqvVPLWMzZ3MRXR7xtz7fPYYsSergkXjPvg7yEIwMAS7tygcKPMozYugTYHwBWwYQCygB3E AQ/wIR7YYRpeARxaQBZ2QRfqKB6KIRlwYb+6gQ+6IQL+wAkEQgMiaxrEQQaIoFLKwRG+4QigYB2y wBvSoRzGQBsQhB0eKAdRJ+jUcxcJ8OmGlQO/aSHbSd74pOUYUjdRrrqMFOkaqjwQ7PGEAkq2siDg NDL17zLpRyFd8E5tEzb98zxUJ0g3AxSCQCEe/yAT6OMdoMEJYiE/cqEMwKECNAEYPEAb2oEc2oAa +oAA9AAYXCAd0iFaUhUZVmXcZMEe0mEeKoEWTkQdXEAaEAQRoIAdqGEemmqbPtEiJ+9Yc3PG8gz8 1vE69W4VUuE4N4NwyIMC6MEJ/MwPSkcgjKAcqgUANIA1QMcF6mARZMAD0gEbPgNAmqENpIEeZIA1 3EAFHgEbsIAelkbGYHZIAe/LRAkUJDTMpA1rwbZ2dOEUypOEGO73NiNCrICxigAdkkAgYAAedtYD eoEa+qEQjiEe9gEROICxBMIG6CE+3HMGGmEa7OEaXGEZoKAcqujd8qQlvAFfHqYYEiZgnMFecv9i BjR3cyHqUKlRWePvIUWWZON0IIUxSsDsiuju5Y5xIxJVOHlwDqlPo5TVT7lTB0lMGRvpMv2JTvGz 1VRwXHnTkj5IucxtbO/yDVdhN8aDAsqhCo5BEkyAHd4WAE6gjrKBcu2hHfqBEPaAPpaBA7RBZwWC CdKBHeJhEGxAtQ5XF5ahCNahatuSFUw2aTLNMirDDxrAAF6DTcZRlDhRNbX2k2bzk66zdHHrf2lH XettP2FXNcbWZfdsWwvubN+kJKpAMe7gRMXAxl5nHWUDH2vHura2a8fpWecOPBv4k2oxdk1KdhQ4 JMa2bFlGAXJCBmpgBGSABnKCh3l4BHy4h3v/GIhloAWCWAaAuAV2GIl5uIh7+Bh8gIh9mIiLuIlz QoqBeIqbeIuXOIeDmIdnAAOO63CatkvvQAYIy40wqVDPsYMIcYzhmA6BkSwBIKvA82S8USFed/iG U8zcyCIMyuVQonE2AhY98+JGkIH3rYVXuIWyAnnl85PyjYIDzwAqgWcsw4PD1iTsmIBpczb8gB0O IW54ZhGClmdOuZou2Q9MmWcqwWlYmW384DtSISsVzwLYIW6IwG784JXdIGjZ5pWF2Q9G+RCCVtB6 GZVb2ZfZpphJ2ZlZI5h7eZorAWie+Zd5WZhd2Wm0mTWG2RsoOTV0oWXv75qcQZFVw9g+Zox1/9MA aKAyLI15b60CoxB9xlAhKu5cFaKTYe8oOA94QcaEmVWQekEI/sEbnKGedAEaKMWelrRNl3RJr1QX pvRydaFL/+EPGrNOKawG0cl3Ry/o1AcDmEkxr6XxkLUC1QeSofOTjkGDRKl4dfMgxUMGxMCeZECl nHFcD1gVvbaJTuwgVsEpHs+NNog8hTfoisEKPuIZfOAJntoHpNoJgOAJaACqr/qqfYAGgOCpoTpx AOAfGKExSXdO1M/6qFE24ig2LsA9LcAu0rMolA2exLgoBOyS3roQLTgyTVEhWDqSayecNpmIUOkO cEZIl1eU/uCTZWMVwuAfhKCkQ4IAqIY1//9gZx3iF//hDk5Bk/cSA1YnkmQBG3ZAFsZhBVapEzCg CIbBbE4JDCZAG9ShWgiAFoLhZ9JBELTgDoxmCIjhAoiAt8FmlRbBAjjgDlBBHhhDPJ4BnQUigv0Q gVmCd6kTf4g1u7gvqJ9v4k5zUNEWFoOTJWRgFdxAgjGQK2u3GqmT5vwkFy+hB7R7FtebIonrDj75 +BxSIFihDSBbUEPCATIhHsyhYdPEDf+BOjzbf08GOgv5jzO7BzR5rWPwh34BHQjmEPSgGwCgstyL CNjhDBaXBX5BGQRCAX6BHY5BG7BBBk4FH9BrHPpWwOtAGtIBQ8gBHcBABHAcAN71H4Ahwlr/yumk 8ZvMxN0SYmy7Vh5B9zbbcZaQ84EjqZFLiIIJEQAqwA1WIad7KOtQuIMY+apKAiz02esO7igWe6YR YhX4OwyYiQxlgVIHYTDSoDI3m7xzR3jwvArSwHiMJw16Z8+BYAROgRUmZnKvVKkoZhV8gADgSaUO JRIn8x+OIQxWgqSX/CQGQBcsoSBcoB0oVQ2gABxMgByk4AbGgQVmRQoclhMaYAjMQQyoAR3swRlQ ARtm4BHiAVlcgB2ywRyqgAxORB+WWxL3ujv38a9vy9IGW2RkIBXGwLlFScy3tl19YxXC7qbt7QoQ gcf94GMdwhLtwRE6+5MQxxFSiR14qZru/+AQVond272VZCPSYak4XUHNTG52ip1kkD0DK0hYr24l ZKAXOk67uSW+SSyQ+/naBrA0vpwJ64TMG8AC3CAMcMb4NFPljDwWMzMVjeLMabqDGA+5Usi+9fQt lhrankEGwGXlpRpceHirtxpcfEDmt/oQHKEB7OEONhoUlwIDYqApMCAFgH7o5d0n7OEbHjRA3UgB lkAo7np3AwotfH6yg8J4NUIgdfD0bM+vyRk8PVEI8+IObOo2YSqtvdY//9mBY8MCONuDs5NOQLjL bREADBPNu28wPH6TZOImDtqeDv1JxXQV7GkVBJ/wBf/QbeJKD3zczyNaawcwe8JIG6DAUv9jAQ4h BYggFAjgDRgBE1IBDrDBCrSBHqrgDWrFCbIAEQYAE8DABRC9D1gCDijmElDA9VkBFxRA9nsBDTiA UtgBFzRAqXLBArggUsyhes2FCyfcEWWYbOUzhmPjCZwcEPtNXbcTAFrgEupAKdiK7SSxTeoednKO 5AHxEL7BmgHNDSSNZ0rSbtTfmtkm/YO5bUztGZ4eyuuKr07hsOEodaEOIMg8O8WqF7E84nJQMNck Uy446bKxw/YrFwhqpZhMy1HEXA4ABGLhCvHN0S927Ly5+pfyWDxbBWQB+9WP3Ldj83KYYNcFgM+f QIE+axC0qNGjSH/qOuUjqVEDPokalRr/lGpUn1B/Zm0AxA/QrVOdXv05oGhZqz4HoB1rFi1aAmbD js1aFgBYrEfXZi0K5BDcoHvFsqVqla7WtACo1pV6d++TOz+p3gVwNu1atoL/VIk8ti7Qy4IBVLHn I7Bg0E4JP/161ABqzp9DF8WwKvbRB7oImSCnBEquChug6Yj0zE8kb+TUDPHGbpqlF/a+sRtElEAk RCB0gXnxLRuxGZmeTSciLeUmF8fYjVORB523Zx+N/v3pzPTRxYdtG07sc2lTzLA55VlSAyaFwR0j yFZgUvbJ5uCDEEZY1Gv8dUXhfRJmWJQPXmmIVINFXdKDh7JV8c+J//QCYoYrynYhiUlZ/8AKjIJN 8BuNEErVACtQgdbig/49iBaIkhnl2YAN6GKBbYoB1pplcg0p1l4U4icXa0mttSCMT/jRwIu2wWaf W2PNN6FtF6xilY4+mYnXmfwBGCYoTwSlVmpjsYlUGyj2ech/V1YFp4uCDrqiaRSChsGMEgaG2lpr EprXapw94yaZdk2aqZNKpTIig4gFyClSFFbhpYcvbpllaFSiKmqomsYpZqGy+mSqnVh6qCpSqtIW GqS4kmVkVXfUGWiORfHZ54nsyIAZmLXm6uCPYYJ6mgHe6OJMMaw8w4ozqxzDrTPidssKt95qu4q3 z6D7LbrrfqstK7q812246IJb7jP6jv+r7r7yeusMuwLr0ou42j4T2K6vkhrUUsbiqOFjElds8cUY +9SCHxhkLLGMHgt2yWYh/5QKiqucUvLKFkObIVpt1FGyyxcH6XCugbWo6l4YgILBZZM1HCpoev40 X4GMsXU0UAu6+WbS+dFa2GBxRUthKs4yHe3WlK0qbLCqVbVKxw0X2bV+GI56B8lRmzZmtZv+5Mcq Wbl2iBVk05rnzVFzTbSQYL9K868P0gYs13ImrnfcT8NK9dlh9+epqw7qacCtCsb12pZWwvji4Ip/ XnlVClwyzTHM/aPzh6Ji6uDYabMON+O0+7T2xS5bUAUrVlyQN6+j2sZ5sFMK7bHZs8f/fZkfbOOp eIORe20xxH2vjAHHLGevffbxLIviKaB7zCG1Id++vVMW+HHHHVSc7/77ldyR9fvbs8KU9I5H+RMN PfjQvx/F0EUlCHAZvcRqP4h7TYsilbjogURooqtd6xRXlMCMxnuAAtrXfFTB0AmqWI8z2teetLit jax6IxwQXaSUvJs1wAIyeMYqeuED/81PWpA7DfHyh0LX7ZCCg3pTEEWziuYNEWpDDFDRiLcfH87O KjZDnFPsQwA39KIKVQgf/mK3tQUxUIJnayHcCmQaFYoFicM6VlG+0Scr1OpOmTuc1qYECkAlcYI4 3CFRQChGGNmnR2fUChaBUAUM9GIV/4hcBbhWcS5EsmIVQbAAAS5ggAsQEEfk2xoLZeWywEiyF2tD lBAl1cGk/AVa9tnVlpbyKRp1iX6wjKX2RsCOE7lRlkHpiiwbwEdckoiBrqtDKk4BCj/4QQxO86WQ rOAHR8hMmbCkHv5AIwP5SY9mXmRcg1oVq2cpEU7zCRqWMEUYIXijGPySIb/QuS1drFOd21qnM+Y5 rneuK573xJe45mmwb5yzW8VwhrbYiS94sjOA8XyXQQdqUHgObFuuQGdWnuAIMBZwVmGEFfKicgcg 3BFuevKM67aZH1ECUUIYwAAjiuEHGcwAQNyEVedGqbzQuHQGOJ3BKbbVixlgIEHF8/8mlmbamTke jlr4aZFJJWdECFXzd/SLoPuqlBQhVEJDG7hEBThwCRQw4BIx0EoW1hCBKljgCogQCwHgYIolJQUE eEBEAwZAhETK1UPFgEuatCixXo4QmjqsmO5ScYdkMuxXFhBCylYhgzZUwQ1tsIJkIWuFKlyVlIA9 31I8miFdZhZ3OBKpbCpxy24apQDU8MQryuGJTDSjEemwhzmckIldPOIfAVxGFmJ7D1xsQBvdW0YF AACFf5RjB8moJTA20I54dKM6mWBOHwbwCHUAAAHUAAZeofJYXPKSs591XoQyWRQrpKIOUF2m+k5R J/LKLmMXcu8UJUYU+9lRLvYhrdv/TBtYB1oJSSNsTBqtMtNdXagyicFAOIFiBTdQSlSBuQE6wNGD X+RDBmQwxyqowQlNAMMG7OhDJpYBhXwowAzdgIU4LKAHbAxXA9QQhBHGkYQX0AMO5pDCT27wj2/Y gx46IMM6LAABduCCv0YqhgEIoKIGthCNagSKI4wFtQWDFHhzLGUL5WutPv4EA2nww1LjRgAZnOIZ VsgaX0kYwm/CiYxRZtIPHchD10HxfhGiWHj3zKAGHAJF7EiFmH3SYBIJQQkGEIITADADN4ihDUs4 9AOIkIYqOOEBazCABsDAhG8w4hzhGK4CzNoAITRYCRGwAgraJISPEEAIS6iBG/wA/2lUqYkR942q X/mc2QbI4BJi+EyPTwEVMaSCBrxONoyiSCmo6VmIm/wr7SgU0ziFbS9WWthV9ts1yx1RLDXwXhuT d0oUvuwBblhCCSHETTnGyRungo0B4SQVOBa1UFY5IYDcHaeZvq12FxWvo74t5zx+xgpiIIoulgWZ QDIu2lKcNpvfZO+MNi5uOdPbWzBT7eChhZURWsUF2K1Gzww8c5hdN42oggErrEvc8XiCEDpkMQ7A whvTuOtToCCORT9gFWgIzQJ0oWMIHRYAChMQJ38Y2Kns2nMfjbO5ZUmDQxjgGeK2B3i9fFKNB2U+ TuSbww1eNvFSKEguG5+y+dwAA/+s7xBUqUSfTlVqB1tsA+joAwFcoIs5yCIe+ChH0QHgAWr0Yh0V 0EAy/nGOcfggFuzABzby0A977CMMsviH5eWAsaQrk5cRW/ueMfCHWjJ866JPvWCYHZqRMbDjgdrL odokxiZt1HgSpykFDdClRRfFD/9QU1CscNmJSzEwEEBHKEYwhnSggh2byAA1iBHRNvwiHtrAhzJg 7AUbmAMO8YBGQdLTC3Q8YjpFYAfnobwpcj5F5LnClGgZB8cvao0wHcXo0odG0xUtLVrzx0O1wkAm lx/2d3GDwkuApjLiZTWjdIDJpGXzFXGYUXFhM280dSkEJxUg916R8XQOZ2Bpc2D/jVI1D1Z7QEFa EdIGNAd7/AdGIFEDT0ADNIACD/AEQaAEX8YDRPEANGABP0gANNAAD+ADT2ABGFBDNBADKjADPkAD w6UhRPUMCkCBuuIgmiEbP/IohJNl9DUD6vItjAQu33Iuj0SG3KJI66KGjbQKPtYOiNQLjWSG3FKH ZqhId+gMZmiG6ZVyAXJy0maFsYM0sbJmrCcYfcFlqncxBHAJMgA6VvAMs2ZMlFiJlniJd3AImViJ f3AIszZrnfiJfhCKlEiKo+iJpziJpLiKqGhMnag+mxiLm3iJltiJ2aCI8GU+i+ghbXAIXUg/q6AC uwhYh+g1sEM7CzJm7Wdxc/FD/8qYUURVU2SxRBZYFM+2OJlEFHQmVV3HdRVzgGD0jM24N7Gii9wG dhP3R6wydd2me0CEOV/3gz6BATJQj2HVJjQgAzSwBFaBAS1AAC2wZkDRC8IYFDPQC+xgJlrCRcFT O4AIbboHjoC4RPv3MKfwKX9TFKwAVRkZZxcScE0ngEpHIEXhee44jN6FZIVydEnES00VklLoQQ/i GTJwIvjALf9oK3YHFKgVD+MwV7CADSoABehQCj5RBPKwBjKAARqwLqmgA3CQD97nBERwLqHwAH/Q BC4QChhABKdwCSlABJ3AAYj0DGqAFqsAVCqgC93DLBFYK1wGklIniCfFkmOxWf8RAjLbY5frqD0N QDd0iZKCSSNZmHouUwfidiK6gI5lYA6NYGQDkAndAAAJgBGUMQTpAA27IAbScGRlUAyoMA7eBwXk cAYDgBE3UA6NAA2NMA6YYA5HQAbjMAT0EAM2QA888CbFkJj/EA8tNZgtYxTSNHaJUU3ltpLVExhW hmWgoSoIZoBCZW0QOU5A4QdBMEREUogF52Vh54AJyF8dSUHPyUMVZ1QtVCDME3XTqZ0iVD0EFogg YgAyUAO94A3i9gzAZhUcMA1eYABFAA1NQAb+xA63IBU2MGQ+kQHZ8A3kgAZYgA09AA0yAAXsEA/E UAEEwAq5kAG6MAgIAAv+tAz/mJkSloAWvdByptcn6TCPMjAC9YgBqSCGPqCPBfkqWfGW7PeeaYRk nSNOmqMUeKaSPnEIQtCQgDOXL5M9GOAIfdiNn4WLtMNtUNeXJFKYEiiTRyoxZpaePjEC9nki8YA3 okFzQSUYipgBpnCPRXGMAICiYJpJBlAJbuAGp3AKYvaW2PaLLJIxxXiCX1YbbWpLJ1lvYwdxKoc4 5bkiGuQ4PtBwMGiko0JtDWh83CmNTxapXKSOpgUtbqGLPLQiddEg5emBQtKIp+BWQYF1pUVovkgU /9ZlhaKpD1IMHeMWiYI+d2CnbdBKOJSM5kaRYdKdtbMlHDg5xFkUf+AG9oAi/7pAFEHgDfGiTt3i DBElLviCL+4UrfhiLgRzLtqSrc/ALvECLuxyL/wSMNPKraxQLuJyDGFwR/JZLAt0qLgXZdTyGrda pmTHb8ZzOHypbUZRmN2Ji1KKPzHFPE2aFEBwDDK0L/AirdtyL3ooLuVKMAxrhgKTLxElL+QyLhH1 rQIlUOQwcmaqIQ1AA6egC+hVrzRCiPS6btKkRTKQoiiCAaZCBGoAAEQABnSVsz+hAZXQAD5gARlQ ogkEABngCH2QFA9wBzlQAH+QBArwBzqQFlRLj+EJADMnFuaFbAIJnGAbIaBwnbtYCS/5jVt0B8Ug rLzWAG7wBzckmH3KFi6rAv+8+Q9ucAPi4AfSAA1i8A2FcH3pgAt48Ax2gA/zcArl4ALAZQ/LgAGv kA7sMA9JcF200A+4AAXx8GMrkAfxMFsg8QjLkAfUEAxClgUS0Qvm8Ae08A/B8AjoYA+5wHM5oAfD gAWS+w+IwIJAQQBVEASVUBAY4BoEB05OpmX8KkcFe7yLKnYeKRbP2TnXpkZIRCe490VlJDV41K9R 4Qao15Du542kcgfe0BTcSIFI9JARx35BIQOrMEA01SQV2XGTATVEhYFAEUXceLI04IT+6wNOCApW MAC/gA5rQAbxAAwzAAvF8AvhsArlwALSUApYIJWzdQLw4AjskANMYA6VCwD/ZgAOM4AMiGAAfCAM rgAOQAEB1EAOTwAL8aAGFDAPUoAA36AGUDAOWqAN5MAK0PAI4+AEfKBbHgEF5tAJ7AUEQPAEcbun EwiNQmqoLNswfKmvvVs17DteIlkUh3C2C+kgVWwmqpIm24S/KYevPwEKNVAFwUav0MOyUjyBqCEE xVCkTJc9AIYUHXgxxIe0bVABWGkBBqAFjCAGiFBZXWm2iLACbRADC9AGQSANzfAL/PDBG3CWD+AI nlgBVgAGQeECadAALrAGDYAAlVABBSAGSsABdwAGPeAHl7AEF2AFl+AHaZB+uXAIMRAzYdvL4QWC n9UAkrVnPXAJP9EGbezL/3ZRH4s4t/HbR1ZAQ0Y4zTVUQ0/ghNWczdkcBGMAC72wBthszdXsBP2j zeZ8ztQsztmsBcWQBk5Yy0jKN2hEZ9WSpyQZJyCyM+y5Qbr3xvgMJ/bMFv8mxm4WkfmHIV+ce8Vb SmhRzJyCxtcb0ZhhOEHRBs7wH/y6jJAqz9EpK/7sE37wrm8GUyEodQX7l0GqqA73kfS2RVG2RNuY PPhbv7pXxfc2Lc5DXquTpccaMtkUFE8Xl1dyWD9iAMwMky690SESep9RBXegArgYdmhh0w+iAD5T MgGNgG3mzMrc1V4Ntt+lbL3QxL7ES7lmFDQgaH7wUiVTEHeQCo4ACqeQq/+gwAipwAiMAEqnYNd2 TUxzTUx3DUqpAAp6Xdd3TViHbddy/dagkNh+zQiXQExxbdd3wA5sLTHOzE0ktW+L40TgSL2bmtRX FjejOsWCGIA0E3YIJr1DRNCIQahb3NKa9IC0sjCRM2VTh47SskkXyDRT8xPwGDUBFzl5KlWMIQbF R3Y+YQE+UAx1nLAn6Tc+waZr1wC4JtuBWChcXd0eAqUxmaRX+NUtKyHWOy0EtGRtd97njd7p3d7o /d7n7d4NsN4N1nbzbd/q7d75Dd/67RrnPQAGAN9T9CejPUVWwIJ1SklvGRQnEw+MFRTUnSn2/bJ8 0yPefQdnrYVGwQrGqmz/X5s9qOHdfsiOaCshWvThXnhGwHwUvZgYZeEaXwIXbZcYxHsnamHhdqGN NT7hOK4jPUIUZ/HjUFEZMJ4YcFE3Lo4XdlNaBnAyNHcg0M0iBlABjHAKveAGREBavOoTmLAsxXBL tBoUfDAPWNS/ZiUET6AJ+QAGGnDgGDADaxAEPlAFB64DiXbgKNDBR0AZUTAPi1AG9PAEdF4FMaAB gn4H6dAJVVC1QcCPQAEKW75s7NXdKrdRd3F7Nrq9RQM14Bg9HReNsQqdEEQgXCjcmvLRcilvJF2R EO2jSMqv+pbiVBHc2iPiEJKeCogid2AAV23G7jg4J6uPMvAErECzfWIP//bwOwagB+xg154cBf+A DRZQBuBQBL2ZDvPgDPIABi6ADl8AB/PgA28gDekADljgESBhBCxRuj6AB8dgD+OgB+qgA93uBVBQ DuCugx9YJxjo6jkEAHjppOI98AQPWLxEtqERBjuZFlpQp6egcxPiAm1AIRtgCcNVAFoABiyACXVq CW5VAJhAyh6ACKh6FBywCCXP8GtQFJBlAcfgPQsvS6fgPafgUdRtAGXAEuywDH5ADanQDrlABv+Q C39nD9eAB4jHAd/gBUVAD0OAD7UUDllADq4WBeCwagBwAumwueMACc/FAdsQDinAB/2wCUWRChmu Idst8O61UXQGp+N4gv+yR+FXur38gdpb5H+mjYwSCOz5U4C0TeGwbbI/YaXJCdwxPwCvIJTdHgrn 57iPIO21FZoI3A70sASa2w7hIASyYA+B9xEP8Aub0PQxUACuoA5EgQDc8A/DUAbhsMPsQA9fAAXt gA7l0APS8A/Y/gWZEA/x0Am4aw/pYA0sz5vpMD+cXukCjUOgMfPP8ATE+xPFQLLOu3JiYQPfYJRF AemYmuJwgnaUutqCI0QuKPCPQy3ZqSDzZsYLQtVdl8UjPakhjpwZY5fy+9v/TCxGRGcKbyeLDxA+ yJg7xI3cKmhPpFErdyTPuDzFZM3Too3cM1bHxsUwkg8FgAe/NmGh1yL/ZLcGACSYq6Lnn7hv7FY9 S5WMXTFossolgUIuUbpnz4ppGzZAVjcASZX6+SODhgynp+zFs3cqpVKsSQdk5doV61WlBryOVbpq BFm0adWmBau0wZ0naNtiFZu0rlJdp3ys5dvX71/AgQUPJlzY8GHEiZVeCtK3ihuuQpyArJREw59D Sxo88LMEQI81GNz4aVOB858+BIiMXlMBAAEhS2ZgdpPm6gA3MQwQUYNBy6E2DWaMTlNBiJ86ay4E 8bMoRgE3ldxMzuqmyti5ihGzSnXHEag74MWHJz9+PPnv5e+oB5/ePPv159uDv+Ntr+K89/levet1 61et3MoquwGTAouA/wK7+g+Aq65CkK4EGQQQgP4MDFCuCJN6UEALu5qrQgI7BKutBReUMKv/5hox whUvzK6tBu1S6sHsNqQwLBcv9OqO6yb0qo0/tBPSsEuE4KvCrpDkij8PcTzxRgyXfLLDAhtowABG DEhJxSdjlJItGbELcK68eohSSay2CpGsu9RUMEod+yJxLhP/4tJJH+FUcs0Z0ULTqz/HqrMvG9MM jM++LulxrTbqGPJRwdwwkkWyvPQRUUQhJUuGOyzQNMwvARjUq7zi+vRUVFNVdVVWWwUAlMb44jS9 7kD5jpHwbr0jFfB4xdVWYO84JVdQcOXVO2BByeYfZpl9Jjw/UvmVEf9gccUElGKJDc/Y8br7Lj0Z XBW3UgOY8nTcwPKD09ApxeQQwLvuQjTed+sFFcpR79Uwq7qY9DFQf0WlUskF6eywwj9BDDVPKeWF sl4+F+yv0DjrojhOKrsCxdRQM/2UAHaaFfmfYgIVMuCuLm5y3ZXbBWwuGfxYxTOWRVz4xBbnxJPh Z04xEzGwTB50XojdNbrlmuUkDE03wdy5RX4BjVpg7QgM0WQIGY4QrqmPVtWKkZntBevCPO730q7r TDHprtctdxUepXbZ3k+tTmqVU+LyWGu1CEZ3MLIH29vPkwkbXNC/vXoLiEfXPFwpsJtdJZU/6lg0 47oTx7wvISqJ1o//dzPdO3D89FIrxIBhtFdhHV+c0MR8H4Y9wtj1nTvJnVsmemWHC53r4oJDx5h0 uqemcV99wapd+DHvhXX1geUeC82z6c3OD2ZBx0qGGVZxphcfoPpQepSzpprD/gAOE3WvN99ehie8 fwIqpdu+c+UQm+6Sq7rWxsv0I2nOTgJ0W6UMSMD9tOpxaVGUqojnFf2kRQhuEIMbTnHBVPTgSldK 1QOXNoAGWPCCfxBDJRiHwL4sDzusAKDcoOa+28XwYLk7G++UYiI+3Y9hQ8vK8RgGNbLdJi2+sx3S XpextvQnaCiCId+yQy+BCVFxTJzS8+6lQujdzGYZiuEDtdQABZwC/28XPIQVzGjGMGBNia07nWPO aMYLrmIVvajCBg/ltClibnxvMt+UiAilq0zuZ2mpnQp/x787FpGKxcvjuJYoQy6uBWsLNIzKuILF 6UmvK3dIQxsRyUW7VU1ITnHKU0zZC1Y4QxfOeMYqjlEMVmDklbGM5UxcCUuMqNIZxZjlK2/JikuQ 0gemLFzbIKmWfDnuMKU6Jgqd+UxoRrMwf7icNKXJPmtmkzDqSuDDGBk7AmFykd78kura5S8cPsx1 9VuT/7RiztxlSHlPypfD6PZE99Uwhu6MJDw3t063xI1d7eqf1xa4R1Ddb41T0+cAmwk0PCoSm21q ooMiub9GIo1P3P/sYkab6cH0MZJ5lxynYDCVtXpmso+NTGIA9xlRLR4Qd4gji9rWItBE9rBvfqEk OQl3zoti9J6gTEsNkeRPvulppjHVV51I56UyaVOqU6XqVP1QzapmVatbTQpHf6pH272QnPkjkfmQ dNSsPRJpBX3nDd06w6Qu9XyNXNtCdSrUS+bsrYI6KU//Fc/1JYhPBrDABTCAAUdc8BSMSMUpMKFY xyoWFI9VLCZSQVnKXjCzjNWsYhmB2c5GNrSQ3SxoK6vZxlr2tKeQFmsze4rEhva1pqUta1drWtKe 9rGpTa1iY1vb1YoWt5yFbGM921vRHje5pgWFbI+7WeQ+drKjtSyodEcbWa5J9GX+oSlgBUO87Iiz MCDM0Vpm59HgSdKvivzkXgHp3lOJl6vzpW997Xtf/OZXv/vl71QtFSanthdtHv2SD2maqRoqc8D/ TBDr7oRWAif0XuscnF1Vtrcacbe8HeIhFEWKR6QCdcEOpZIOXdbX/0YYrB9uIkSPlmIVbxGvOHMf PktaP8M88HE9DUyAp6pC+eI4mjwupielymMiEzWoJm3fqQICADs= ------=_NextPart_000_029D_01C8AF58.BF907F40 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_000_029D_01C8AF58.BF907F40-- From syslog-bounces@ietf.org Tue May 6 14:38:27 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1065A28C476; Tue, 6 May 2008 14:38:27 -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 107233A7041 for ; Tue, 6 May 2008 14:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 s1QgNO2VB9aE for ; Tue, 6 May 2008 14:38:25 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 2214F3A6931 for ; Tue, 6 May 2008 14:38:23 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 9E6767AF2A for ; Tue, 6 May 2008 23:38:20 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id k+6AZcOEl0np for ; Tue, 6 May 2008 23:38:08 +0200 (CEST) Received: from [192.168.178.21] (BAE8123.bae.pppool.de [77.132.129.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 98A9C7AF1A for ; Tue, 6 May 2008 23:38:07 +0200 (CEST) Message-ID: <4820CFC1.70404@mschuette.name> Date: Tue, 06 May 2008 23:38:09 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: syslog@ietf.org References: <577465F99B41C842AAFBE9ED71E70ABA308F62@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308F62@grfint2.intern.adiscon.com> Subject: Re: [Syslog] -transport-tls, section 4.2 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 Rainer Gerhards schrieb: > My first question is on section 4.2. It does not tell what to do if the > TLS handshake fails. One can argue that the second sentence implies that > the connection should be dropped on handshake failure. However, this is > not explicitly stated. It may be desirable to continue without TLS in > that case. IMHO the only important point is that a client explicitly configured to use TLS will only send data to an authenticated server, thus it has to abort if the handshake fails. One cannot specify much more, because there are too many possible policies a sysadmin might want to configure; ranging from TLS without client/server-certificates up to his own CA or a predefined list of valid client/server certificates. So it should be left to the implementation to offer different operation modes, for example 'UDP', 'TLS if available', and 'TLS'. Then as a user I might expect a mode 'TLS if available' to continue in TCP or UDP after a failed handshake, while with 'TLS' I have to rely on an abort. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue May 6 14:58:04 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC9E3A704A; Tue, 6 May 2008 14:58:00 -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 2DEC128C258 for ; Tue, 6 May 2008 14:57:57 -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, 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 XKSpWil9G3Uu for ; Tue, 6 May 2008 14:57:55 -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 EF20428C4CF for ; Tue, 6 May 2008 14:55:47 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 May 2008 14:55:38 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m46Ltcwp000718; Tue, 6 May 2008 14:55:38 -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 m46Ltc25011960; Tue, 6 May 2008 21:55:38 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 14:55:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 14:56:25 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308F62@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls, section 4.2 Thread-Index: Acivdf76lZhV7DgWQq6X0iut3++4HAAIg2KA References: <577465F99B41C842AAFBE9ED71E70ABA308F62@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 06 May 2008 21:55:37.0974 (UTC) FILETIME=[EB363160:01C8AFC3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2554; t=1210110938; x=1210974938; c=relaxed/simple; s=sjdkim2002; 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]=20-transport-tls,=20section=20 4.2 |Sender:=20; bh=/68L5Bb/KCnIYQ7jFF8qPUDDRt+RH4FyLNAnlV7PIkI=; b=19unnNEJuvzw5UXHaJpaZ2LjNi49JUwNAKNFXEzv7+RmdrA7NsJV1R7fjM PZJYYd7T/M/rPHKX6NrZRgAfiWZzKgoRYdxX+YQRqhxHprAxYJ7dkrOBUb90 KoCAkP24zX; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] -transport-tls, section 4.2 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 Since Syslog TLS is taking the approach of a separate TCP port for TLS I think it would be more appropriate to reject the connection instead of falling back to insecure. I am inclined to say that if the handshake fails the connection MUST be terminated. If the client wants an insecure session they can connect to the insecure port. Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Tuesday, May 06, 2008 5:38 AM > To: syslog@ietf.org > Subject: [Syslog] -transport-tls, section 4.2 > > Hi there, > > I have today released a basic version of rsyslog with an > experimental first -transport-tls implementation > (announcement at http://www.rsyslog.com/Article222.phtml ). I > am now digging deeper and refining the implementation. I try > to convey some thoughts and ask some questions along this > route - in the hopes to gather some feedback. > > The initial feedback is that it is quite trivial to implement > -transport-tls - just as anticipated. But I think it is good > to see it works out in practice. > > My first question is on section 4.2. It does not tell what to > do if the TLS handshake fails. One can argue that the second > sentence implies that the connection should be dropped on > handshake failure. However, this is not explicitly stated. It > may be desirable to continue without TLS in that case. > > When GSSAPI support was implemented in rsyslog, there was a > strong community demand for such a fallback mode. Thus, if > the GSSAPI handshake fails, and rsyslog is configured > accordingly, it falls back to plain TCP syslog (unencrypted). > I know this is dangerous, as a man in the middle may force > unencrypted transfer in this case. But provided it is an > operator-selectable option (and by default off), I think it > is an acceptable risk. > > Question now: how to handle this in spite of -transport-tls? > With the current text, would my application compliant to it > if it permits to run without TLS support when the handshake > fails (in that case obviously not complying to any standard)? > > I would suggest that this case is being at least mentioned. I > would also like to hear some opinions on this topic. > > Thanks, > Rainer > _______________________________________________ > 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 Wed May 7 02:05:02 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556DE28C59D; Wed, 7 May 2008 02:05:02 -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 DDA9328C5AA for ; Wed, 7 May 2008 02:05:00 -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 TCmxA111GUaM for ; Wed, 7 May 2008 02:04:59 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 2E4BA28C59C for ; Wed, 7 May 2008 02:04:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 9C3A67ADFD2 for ; Wed, 7 May 2008 11:03:39 +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 9VKNMARMjFIA for ; Wed, 7 May 2008 11:03:39 +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 5CA1A7ADD99 for ; Wed, 7 May 2008 11:03:39 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 7 May 2008 11:04:53 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F74@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls, section 4.2 Thread-Index: Acivdf76lZhV7DgWQq6X0iut3++4HAAIg2KAACFiGWA= References: <577465F99B41C842AAFBE9ED71E70ABA308F62@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: Subject: Re: [Syslog] -transport-tls, section 4.2 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 Joe, this sound quite reasonable, especially the "dedicated port" argument is a good one. And, of course, if the -transport-tls connection fails, a local syslog sender may still be configured to fall back to some other mode (e.g RFC 3195 or RFC 3164). It just isn't then using -transport-tls. However, I think this "MUST fail" should be explicitly spelled out in the draft. Otherwise we have some confusion. The issue arose from this conversation with Martin: http://mail-index.netbsd.org/tech-userlevel/2008/05/06/msg000553.html I remember similar discussions when implementing RFC 3195 and they lead to interop problems between different implementations (namely SDSC syslogd vs. liblogging vs. Cisco IOS). In that case, there was a somewhat unclear definition about the session closure (which stems back to RFC 3080 and is not a 3195 issue). Would like to prevent this for -transport-tls if at all possible. OF course, we won't catch anything, but now that we begin implement (and still have a draft and not a final RFC), we should feedback experience into the draft. At least this is my humble POV. Rainer > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, May 06, 2008 11:56 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] -transport-tls, section 4.2 > > Since Syslog TLS is taking the approach of a separate TCP port for TLS > I > think it would be more appropriate to reject the connection instead of > falling back to insecure. I am inclined to say that if the handshake > fails the connection MUST be terminated. If the client wants an > insecure session they can connect to the insecure port. > > Joe > > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > > Sent: Tuesday, May 06, 2008 5:38 AM > > To: syslog@ietf.org > > Subject: [Syslog] -transport-tls, section 4.2 > > > > Hi there, > > > > I have today released a basic version of rsyslog with an > > experimental first -transport-tls implementation > > (announcement at http://www.rsyslog.com/Article222.phtml ). I > > am now digging deeper and refining the implementation. I try > > to convey some thoughts and ask some questions along this > > route - in the hopes to gather some feedback. > > > > The initial feedback is that it is quite trivial to implement > > -transport-tls - just as anticipated. But I think it is good > > to see it works out in practice. > > > > My first question is on section 4.2. It does not tell what to > > do if the TLS handshake fails. One can argue that the second > > sentence implies that the connection should be dropped on > > handshake failure. However, this is not explicitly stated. It > > may be desirable to continue without TLS in that case. > > > > When GSSAPI support was implemented in rsyslog, there was a > > strong community demand for such a fallback mode. Thus, if > > the GSSAPI handshake fails, and rsyslog is configured > > accordingly, it falls back to plain TCP syslog (unencrypted). > > I know this is dangerous, as a man in the middle may force > > unencrypted transfer in this case. But provided it is an > > operator-selectable option (and by default off), I think it > > is an acceptable risk. > > > > Question now: how to handle this in spite of -transport-tls? > > With the current text, would my application compliant to it > > if it permits to run without TLS support when the handshake > > fails (in that case obviously not complying to any standard)? > > > > I would suggest that this case is being at least mentioned. I > > would also like to hear some opinions on this topic. > > > > Thanks, > > Rainer > > _______________________________________________ > > 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 Wed May 7 05:04:12 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A6C28C631; Wed, 7 May 2008 05:04: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 86A243A7122 for ; Wed, 7 May 2008 05:04:09 -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 4pK5kFYoM-su for ; Wed, 7 May 2008 05:04:07 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 1462C3A6D5A for ; Wed, 7 May 2008 05:04:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id F02247ADFF3 for ; Wed, 7 May 2008 14:01:36 +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 EjWsDR9O1tLO for ; Wed, 7 May 2008 14:01:36 +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 B67387ADFD4 for ; Wed, 7 May 2008 14:01:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 7 May 2008 14:04:01 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F86@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls, section 4.3 Thread-Index: AciwOm/5rEmknGGaTFisTkXqajB3lQ== From: "Rainer Gerhards" To: Subject: [Syslog] -transport-tls, section 4.3 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 list, A couple of more things I noticed while implementing: Section 4.3, it is specified: APPLICATION-DATA = 1*SYSLOG-FRAME Is it actually required to check if there is at least one SYSLOG-FRAME in a TLS record? That places some additional burden onto the receiving application AND (this is the biggie) requires the application to know about TLS records. I have abstracted this knowledge onto a driver level and I think others will most probably work with a similar abstraction. Knowing about the TLS records IMO unnecessarily breaks the abstraction layers. So I would prefer a definition that permits empty TLS records (at least from the syslog POV). APPLICATION-DATA = *SYSLOG-FRAME Having said this, I am not even sure if the ABNF "APPLICATION-DATA" relates to the TLS record. It may be useful to clarify. If it specifies the stream from an upper layer perspective, it even more must be "*", because I don't think we should require that in a syslog session always at least one message is transmitted. There may be valid reason that a session is closed without a message being sent over it. Again, section 4.3: It states " SYSLOG-MSG is defined in syslog [2] protocol." However, it does not state what MUST/SHOULD happen if the SYSLOG-MSG is malformed. Possible options are a) ignore this message, but continue receiving b) process the message with another parser (e.g. according to RFC 3164) c) ignore the message and close the connection I think we should specify at least a SHOULD. I envision this to become a big interoperability issue. Section 5 ... is missing a security consideration. An attacker may use a maliciously large MSG-LEN (S. 4.3) in order to try DoS (hoping the implementation tries to malloc memory based on the frame size). While this should be a sufficiently well-known attack, I think it doesn't hurt to mention it. In general, I wonder if we should specify the situation where a TLS session is closed by the server (for whatever reason) and the client re-instantiates the connection. For example, if a client tries to connect to a server, but the handshake fails for a persistent reason (e.g. invalid client credentials), the client will eventually run into an endless loop trying to connect to that server. This could lead to a close-to-DoS. I wonder if it would be useful to specify some rate-limiting or similar mechanism to prevent that situation. At a minimum, I think it would make sense to mention it, so that implementers and knowledgeable operators are aware of the potential problem. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 7 08:00:05 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CFF28C1A7; Wed, 7 May 2008 08:00:05 -0700 (PDT) X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D3CB428C65B; Wed, 7 May 2008 08:00: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: <20080507150001.D3CB428C65B@core3.amsl.com> Date: Wed, 7 May 2008 08:00:01 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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-12.txt Pages : 13 Date : 2008-05-07 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-12.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-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-07075618.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 May 7 08:19:52 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E449928C6A9; Wed, 7 May 2008 08:19:31 -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 2896328C7A7 for ; Wed, 7 May 2008 08:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 mvBBjX9fv0I4 for ; Wed, 7 May 2008 08:18:56 -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 1D6C028C6A7 for ; Wed, 7 May 2008 08:10:53 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 May 2008 08:10:50 -0700 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 m47FAoOX028421 for ; Wed, 7 May 2008 08:10:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m47FAoNe006540 for ; Wed, 7 May 2008 15:10:50 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 08:10:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8B054.88FE20CE" Date: Wed, 7 May 2008 08:11:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AciwU2SMA9ngzRuJQcyXaDJf2Le/XAAAMaDA From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 07 May 2008 15:10:50.0150 (UTC) FILETIME=[88F41C60:01C8B054] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2108; t=1210173050; x=1211037050; c=relaxed/simple; s=sjdkim2002; 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:=20FW=3A=20[Syslog]=20I-D=20Action=3Adraft-ietf-sy slog-transport-tls-12.txt |Sender:=20; bh=EkyR/X5LELz11eIzVWbgXUYTD/jDBFOFsotHlQmvJ1c=; b=IOTYn5OOCA9ScVDRY0R7jZbsktlZSSt1BnaUJPIz/mC15Ncmr0Ge/wU2mt 9ZLei2xNrvIVVkz1Uw5y37bxPNAi0VNAb8gWsTTBuaKHTpaxPQ9x217mQGaS K10D3saE23; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Syslog] FW: I-D Action:draft-ietf-syslog-transport-tls-12.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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B054.88FE20CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just posted a new draft, it still needs some work, but since there are substantive changes in section 4.2 it would be good to get working group feedback. =20 Thanks, Joe -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, May 07, 2008 8:00 AM To: i-d-announce@ietf.org Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt 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-12.txt Pages : 13 Date : 2008-05-07 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-12.t xt 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_001_01C8B054.88FE20CE Content-Type: application/octet-stream; name="draft-ietf-syslog-transport-tls-12.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-syslog-transport-tls-12.URL Content-Disposition: attachment; filename="draft-ietf-syslog-transport-tls-12.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXN5c2xvZy10cmFuc3BvcnQtdGxzLTEyLnR4dA0K ------_=_NextPart_001_01C8B054.88FE20CE 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_001_01C8B054.88FE20CE-- From syslog-bounces@ietf.org Wed May 7 12:20:15 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A463A6C02; Wed, 7 May 2008 12:20:15 -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 451573A6C8E for ; Wed, 7 May 2008 12:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 H9UfK4wipZ72 for ; Wed, 7 May 2008 12:20:12 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 341ED3A6ADD for ; Wed, 7 May 2008 12:20:12 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id NhrV1Z0030EPchoA60DW00; Wed, 07 May 2008 19:19:50 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id NjL71Z00B4HwxpC8M00000; Wed, 07 May 2008 19:20:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=aAD4C1mW_iYA:10 a=BHdMu9g2WwQA:10 a=48vgC7mUAAAA:8 a=magP3rcVfGhYrUzwwK4A:9 a=ra5jIi_vmMM9-nRTTxbY6MQJo9cA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <20080507150001.D3CB428C65B@core3.amsl.com> Date: Wed, 7 May 2008 15:20:07 -0400 Message-ID: <038201c8b077$5d5e3130$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080507150001.D3CB428C65B@core3.amsl.com> Thread-Index: AciwU2ChbEyxpjxnQYqNRgT4AQTQMQAI1mEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: syslog@ietf.org Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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, We have had a bit of dicussion based on implementations, and I welcome that input. The notes you made while doing your implementations might have been based on the -11- draft. Now that a new draft -12- is available, we encourage you to see if the comments are still valid. It would be very helpful if comments are clear about whether they are relevant to -11- or -12-, in case there is a difference. (Obvously, we would like comments to be about -12-, but for a short time won't reject implementation comments based on -11-). Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, May 07, 2008 11:00 AM > To: i-d-announce@ietf.org > Cc: syslog@ietf.org > Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt > > 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-12.txt > Pages : 13 > Date : 2008-05-07 > > 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-12.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 From syslog-bounces@ietf.org Wed May 7 13:06:26 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52853A70DC; Wed, 7 May 2008 13:06: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 EF8E13A7168 for ; Wed, 7 May 2008 13:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 yXT2foXkkWOa for ; Wed, 7 May 2008 13:06:23 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 82C453A6D9C for ; Wed, 7 May 2008 13:06:22 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id NjDo1Z0010QkzPwA604200; Wed, 07 May 2008 20:06:00 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id Nk6J1Z00J4HwxpC8N00000; Wed, 07 May 2008 20:06:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=P9XoPP60ScA9YyVzuOYA:9 a=3FpSyxnPd64nZJw9HHAA:7 a=wVhR_Dr8yEIgnn_i_5Ur0jc-yPsA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 7 May 2008 16:06:18 -0400 Message-ID: <038301c8b07d$d0ba73e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aciwfc/LdMmmHPKNRgGMhVhf1jEPJg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] the state of syslog-tls 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, I have provided similar guidance before, but think I should provide this guidance again, as a gentle reminder. This email will also provide information on the current state of the document. (Because I have sent out this type of email before, I have not "cleared" this message with my co-chair or the responsible AD.) I don't think we ever announced it, but Pasi Eronen is the new responsible AD for the syslog WG, and the shepherding AD for the syslog-tls draft, replacing Sam Hartman who retired from the IESG. Joe Salowey has taken on the editing responsibility for the syslog-tls draft, since Miao and Yuzhi could no longer devote enough time to syslog WG editing (day job got in the way ;-). The syslog-tls draft has been through WGLC and is in AD-Followup state. The document has not been returned to the WG to do with as we please (i.e., it has not been returned to the "ID-Exists" state). Resolving the issues that were raised by multiple IESG members has resulted in significant changes to the technical specification. Joe has published a new revision of the draft at the request of the shepherding AD to allow the WG a chance to review the draft to make sure the WG concurs with the changes. Here is the official definition of AD-Followup: "A generic substate indicating that the shepherding AD has the action item to determine appropriate next steps. In particular, the appropriate steps (and the corresponding next state or substate) depend entirely on the nature of the issues that were raised and can only be decided with active involvement of the shepherding AD. Examples include: - if another AD raises an issue, the shepherding AD may first iterate with the other AD to get a better understanding of the exact issue. Or, the shepherding AD may attempt to argue that the issue is not serious enough to bring to the attention of the authors/WG. - if a documented issue is forwarded to a WG, some further iteration may be needed before it can be determined whether a new revision is needed or whether the WG response to an issue clarifies the issue sufficiently. - when a new revision appears, the shepherding AD will first look at the changes to determine whether they believe all outstanding issues have been raised satisfactorily, prior to asking the ADs who raised the original issues to verify the changes. " It is useful to get input from implementors, and we may make adjustments based on that input - or not. I encourage implementation feedback. Depending on the size and nature of the change and the level of consensus, it might require us to recharter to do a -bis- of the current document. WG members will also have another chance to review the document and raise other issues, when the document goes through IETF Last Call. I am sure Pasi will be watching the curent input and will make a suitable decision about next steps as part of AD-Followup. I hope this is helpful information. Thanks, 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 Wed May 7 13:12:35 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073063A707B; Wed, 7 May 2008 13:12:35 -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 3ABD43A6D7B for ; Wed, 7 May 2008 13:12:32 -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=[AWL=0.000, 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 afTlGtx8-2Vb for ; Wed, 7 May 2008 13:12:13 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 960813A68BF for ; Wed, 7 May 2008 13:11:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 927F97AE0AC for ; Wed, 7 May 2008 22:06:58 +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 RA52pQNZOMYo for ; Wed, 7 May 2008 22:06:58 +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 5BE067AE0AA for ; Wed, 7 May 2008 22:06:58 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 7 May 2008 22:11:24 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F91@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] FW: I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AciwU2SMA9ngzRuJQcyXaDJf2Le/XAAAMaDAAAa2I4AAA90CsA== From: "Rainer Gerhards" To: Subject: [Syslog] FW: FW: I-D Action:draft-ietf-syslog-transport-tls-12.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 Sorry, I accidently did not send this to the list... Rainer > -----Original Message----- > From: Rainer Gerhards > Sent: Wednesday, May 07, 2008 8:29 PM > To: Joseph Salowey (jsalowey) > Subject: RE: [Syslog] FW: I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > Joe, > > Many thanks for taking up this task. I have had a quick look > at the new draft and find it quite well. I'll go through it > in more detail the next days and also will see that I > implement it. I'll post comments as I go along. I expect that > the implementation takes at least two weeks. > > I think our postings crossed - my comments from earlier today > still apply (with possibly one being resolved). I'd > appreciate if they could be considered while reviewing the new draft. > > Thanks, > Rainer > > > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > Behalf Of Joseph Salowey (jsalowey) > > Sent: Wednesday, May 07, 2008 5:12 PM > > To: syslog@ietf.org > > Subject: [Syslog] FW: I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > > > I just posted a new draft, it still needs some work, but since there > > are > > substantive changes in section 4.2 it would be good to get working > > group > > feedback. > > > > Thanks, > > > > Joe > > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > Behalf > > Of Internet-Drafts@ietf.org > > Sent: Wednesday, May 07, 2008 8:00 AM > > To: i-d-announce@ietf.org > > Cc: syslog@ietf.org > > Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt > > > > 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-12.txt > > Pages : 13 > > Date : 2008-05-07 > > > > 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- > > 12.t > > xt > > > > 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 From syslog-bounces@ietf.org Wed May 7 13:39:52 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1837E3A6CFA; Wed, 7 May 2008 13:39:52 -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 253E73A680C for ; Wed, 7 May 2008 13:39:51 -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 peYoXRu8aMC4 for ; Wed, 7 May 2008 13:39:50 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 472F83A67CC for ; Wed, 7 May 2008 13:39:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id A7FF87AD7A9 for ; Wed, 7 May 2008 22:35: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 mIj3JJoqGmw1 for ; Wed, 7 May 2008 22:35:15 +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 6C0C67AD6E4 for ; Wed, 7 May 2008 22:35:15 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 7 May 2008 22:39:37 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F92@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls-12, IP addresses Thread-Index: AciwgnengYGl1+sCRr+5vGq+XE9Bug== From: "Rainer Gerhards" To: Subject: [Syslog] -transport-tls-12, IP addresses 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 Joe, [Editor's Note: How useful is it to match against IP address? Do we expect deployments to issue certificates with IP addresses in them? Are IP addresses typically used in configuration? ] I find this a tough question. In my experience, it is not uncommon to configure forwarding via IP addresses instead of hostnames. One reason for this is because of reliability of the logging system when DNS is not (yet --> system startup) available. On the other hand, I find it even a bit disturbing to have a certificate issued for an IP address. But it may make sense. I personally would expect that operators tend to use hostnames inside the certificate. The problem, of course, would be that the configuration then needs both the name and IP address... I hope this is useful information, even though I am undecided. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 7 14:02:41 2008 Return-Path: X-Original-To: syslog-archive@megatron.ietf.org Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B587E28C5C1; Wed, 7 May 2008 14:02:40 -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 118AA28C54F for ; Wed, 7 May 2008 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 J8L1qBLX5iwV for ; Wed, 7 May 2008 14:02:08 -0700 (PDT) Received: from ext-nj2ut-8.online-age.net (ext-nj2ut-8.online-age.net [64.14.54.238]) by core3.amsl.com (Postfix) with ESMTP id 3D52628C2A6 for ; Wed, 7 May 2008 14:02:00 -0700 (PDT) Received: from int-nj2ut-1.online-age.net (int-nj2ut-1.online-age.net [3.159.237.70]) by ext-nj2ut-8.online-age.net (8.13.6/8.13.6/20051114-SVVS-TLS-DNSBL) with ESMTP id m47L1qnS004855 for ; Wed, 7 May 2008 17:01:52 -0400 Received: from cinmlef09.e2k.ad.ge.com (int-nj2ut-1.online-age.net [3.159.237.70]) by int-nj2ut-1.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id m47L1pS5010167 for ; Wed, 7 May 2008 17:01:51 -0400 Received: from ALPMLVEM05.e2k.ad.ge.com ([3.159.17.55]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 7 May 2008 17:01:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 17:01:50 -0400 Message-ID: <124CF5A7D55D6F43A4FD9437F28254D8B8E9A8@ALPMLVEM05.e2k.ad.ge.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308F92@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls-12, IP addresses Thread-Index: AciwgnengYGl1+sCRr+5vGq+XE9BugAAoK6Q References: <577465F99B41C842AAFBE9ED71E70ABA308F92@grfint2.intern.adiscon.com> From: "Moehrke, John (GE Healthcare)" To: X-OriginalArrivalTime: 07 May 2008 21:01:51.0243 (UTC) FILETIME=[9257DDB0:01C8B085] Subject: Re: [Syslog] -transport-tls-12, IP addresses 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 Neither IP address nor hostname are poor identities. The normal TLS validation proof of possession of the private key is far stronger. I would recommend against requiring IP address or hostname checking. Further I am disturbed at the overly prescriptiveness of this specification. There is no need to include policy decisions like key management in this specification. John > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf > Of Rainer Gerhards > Sent: Wednesday, May 07, 2008 3:40 PM > To: syslog@ietf.org > Subject: [Syslog] -transport-tls-12, IP addresses > > Joe, > > [Editor's Note: How useful is it to match against IP address? Do we > expect deployments to issue certificates with IP addresses in them? > Are IP addresses typically used in configuration? ] > > I find this a tough question. In my experience, it is not uncommon to > configure forwarding via IP addresses instead of hostnames. One reason > for this is because of reliability of the logging system when DNS is not > (yet --> system startup) available. On the other hand, I find it even a > bit disturbing to have a certificate issued for an IP address. But it > may make sense. I personally would expect that operators tend to use > hostnames inside the certificate. The problem, of course, would be that > the configuration then needs both the name and IP address... > > I hope this is useful information, even though I am undecided. > > Rainer > _______________________________________________ > 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 May 8 08:43: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 C1B3D3A7376; Thu, 8 May 2008 08:43: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 494103A6A57 for ; Thu, 8 May 2008 08:43:07 -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=[AWL=0.000, 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 51Zp27yKoVVr for ; Thu, 8 May 2008 08:43:05 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 68CBD28CB99 for ; Thu, 8 May 2008 06:33:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 4BC797AE1D7 for ; Thu, 8 May 2008 15:05:01 +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 PTxbWCPztv2D for ; Thu, 8 May 2008 15:05:01 +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 12A827AE1C3 for ; Thu, 8 May 2008 15:05:01 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 May 2008 15:06:51 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FA4@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls-12, section 4.2.3 (fingerprints) Thread-Index: AcixDGHYAKW3NlsISKSnpPNfuaTo8w== From: "Rainer Gerhards" To: Subject: [Syslog] -transport-tls-12, section 4.2.3 (fingerprints) 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 Joe, I am implementing fingerprint authentication. I have some trouble understanding this text: === Both client and server implementations MUST make the certificate fingerprint available through a management interface. If no other certificate is configured, both client and server implementations MUST support generating a key pair and self-signed certificate. === Especially the "If no other certificate is configured..." part puzzles me. Does that mean that if no certificate is configured, the syslogd is responsible for generating a self-signed certificate automatically? If so, I have concerns if that is the right thing to do. I think certificates should always be generated by an operator. Or does it mean that there must be a management interface to generate self-signed certificates? If so, I assume that this management interface may reside outside of the core syslogd. In rsyslog, I will provide some tools to generate self-signed certificates and obtain the fingerprints (you may want to look at the rough prototypes if I made myself not clear enough: http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools/gnutls;h=1abb246805 546ebd2f1f008a3cf256d5c76b7cbc;hb=HEAD ). Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 8 09:04: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 31E5F28C913; Thu, 8 May 2008 08:46:20 -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 E5F2C28C96C for ; Thu, 8 May 2008 08:46:13 -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=[AWL=0.000, 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 ayklO5Krno9n for ; Thu, 8 May 2008 08:46:12 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 8627928CA12 for ; Thu, 8 May 2008 06:29:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 629527AE65D for ; Thu, 8 May 2008 15:27:57 +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 ENt47VQJbq5k for ; Thu, 8 May 2008 15:27:57 +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 2A15A7AE1C3 for ; Thu, 8 May 2008 15:27:57 +0200 (CEST) Received: from [172.19.2.12] ([172.19.2.12]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 May 2008 15:29:51 +0200 From: Rainer Gerhards To: syslog@ietf.org Organization: Adiscon Date: Thu, 08 May 2008 15:30:26 +0200 Message-Id: <1210253426.22738.503.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 08 May 2008 13:29:51.0988 (UTC) FILETIME=[986BB340:01C8B10F] Subject: [Syslog] -transport-tls-12, section 4.2.3 (fingerprint format) 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, yet another question on the fingerprints. My context is that I am thinking what I need to compare in order to authorize via fingerprints. Text in question is: === The RECOMMENDED mechanism to generate a fingerprint is to take the SHA-1 hash of the certificate and convert the 20 byte result into 20 colon separated, hexadecimal bytes, each represented by 2 uppercase ASCII characters. When a fingerprint value is displayed or configured the algorithm used to generate the fingerprint SHOULD be indicated. === What is "the algorithm used to generate..."? Is it SHA1 et al, thus the hash algorithm used? Or is it actually the algorithm that was used the generate the fingerprint. If it is the former, it sounds like I should compare the hash values and not actually the fingerprints. So 55:D8:43:57:39:6C:23:0F:86:B1:EB:93:1E:F3:09:DE:7B:8B:62:70 55-D8-43-57-39-6C-23-0F-86-B1-EB-93-1E-F3-09-DE-7B-8B-62-70 are identical (it is just RECOMMENDED to use colons). However, this assumes that the fingerprint is always a hash. In this case, I think it would be preferable to talk directly about the hash values. If the fingerprint is not necessarily a hash, I need to compare the actual fingerprint, the ASCII representation. Then, the two strings above would be different. That could cause interop problems. I propose that we strictly define fingerprints to be arbitrarily long printable USASCII. If the fingerprint contains unprintable data, the whole string must be encoded as a set of octets represented by 2 USASCII hex characters delimited by colons - or we may specify this format for all cases. This does not tie us to hashes but prevents interoperability problems due to different formats. Rainer I _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 8 09:11:55 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 D98E23A7207; Thu, 8 May 2008 09:11:55 -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 829003A6EF7 for ; Thu, 8 May 2008 09:11:45 -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 aq0us99l4tVY for ; Thu, 8 May 2008 09:11:44 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id C872928C304 for ; Thu, 8 May 2008 08:53:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,455,1204498800"; d="scan'208";a="45108352" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 08 May 2008 17:53:30 +0200 In-Reply-To: <20080507150001.D3CB428C65B@core3.amsl.com> To: "Joseph Salowey (jsalowey)" , syslog@ietf.org MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Thu, 8 May 2008 11:53:26 -0400 Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 Section 4.2 is better, but it still needs work to separate the policy decisions from the protocol definition. Policy decisions are driven by risk analysis of the assets, threats, and environment (among other things). These are not uniform over all uses of syslog. That makes it important to separate the policy from the protocol, in both the specifications and in the products. In the healthcare environment we use TLS to protect many of our connections. This is both an authentication protection and a confidentiality protection. The policy decisions regarding key management and verification will be very similar for a healthcare use of syslog. Some healthcare sites would reach the same policy decision as is in 4.2, but here are three other policy decisions that are also appropriate: Policy A: The clients are provided with their private keys and the public certificates for their authorized servers by means of physical media, delivered by hand from the security office to the client machine support staff. (The media is often CD-R because it's cheap, easy to create, easy to destroy, and easy to use.) During TLS establishment the clients use their assigned private key and the server confirms that the connection is from a machine with one of the assigned private keys. The client confirms that the server matches one of the provided public certificates by direct matching. This is similar to the fingerprint method, but not the same. My most recent experience was with an installation using this method. We had two hours to install over 100 systems, including the network facilities. This can only be done by removing as many installation schedule dependencies as possible. The media method removed the certificate management dependencies. Policy B: These client systems require safety and functional certification before they are made operational. This is done by inspection by an acceptance team. The acceptance team has a "CA on a laptop". After accepting safety and function, they establish a direct isolated physical connection between the client and the laptop. Then using standard key management tools, the client generates a private key and has the corresponding public certificate generated and signed by the laptop. The client is also provided with a public certificate for the CA that must sign the certs for all incoming connections. During a connection setup the client confirms that the server key has been signed by that CA. This is similar to a trusted anchor, but not the same. There is no chain of trust permitted. The key must have been directly signed by the CA. During connection setup the server confirms that the client cert was signed by the "CA on a laptop". Again, no chain of trust is permitted. This policy is incorporating the extra aspect of "has been inspected by the acceptance team" as part of the authentication meaning. They decided on a policy-risk basis that there was not a need to confirm re-inspection, but the "CA on a laptop" did have a revocation server that was kept available to the servers, so that the acceptance team could revoke at will. Policy C: This system was for a server that accepted connections from several independent organizations. Each organization managed certificates differently, but ensured that the organization-CA had signed all certs used for external communications by that organization. All of the client machines were provided with the certs for the shared servers (by a method similar to the fingerprint method). During TLS connection the clients confirmed that the server cert matched one of the certs on their list. The server confirmed that the client cert had been signed by the CA responsible for that IP subnet. The server was configured with a list of organization CA certs and their corresponding IP subnets. I do not expect any single policy choice to be appropriate for all syslog uses. I think it will be better to encourage a separation of function in products. There is more likely to be a commonality of configuration needs for all users of TLS on a particular system than to find a commonality of needs for all users of syslog. The policy decisions implicit in section 4.2 make good sense for many uses. They are not a complete set. So a phrasing that explains the kinds of maintenance and verification needs that are likely is more appropriate. The mandatory verifications can be separated from the key management system and kept as part of the protocol definition. The policy decisions should be left as important examples. Kind Regards, Robert Horn | Agfa HealthCare Research Scientist | HE/Technology Office T +1 978 897 4860 Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 07660-2199, United States http://www.agfa.com/healthcare/ Click on link to read important disclaimer: http://www.agfa.com/healthcare/maildisclaimer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 8 13:03:22 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 6425128C1E9; Thu, 8 May 2008 13:03:13 -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 0CD1F3A6DCE for ; Thu, 8 May 2008 13:03:01 -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 NeMf-kj8988K for ; Thu, 8 May 2008 13:02:17 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id DAD3C28C135 for ; Thu, 8 May 2008 13:00:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 6B82A7AE1D7; Thu, 8 May 2008 21:57:51 +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 mGcZBEnxWqm9; Thu, 8 May 2008 21:57:51 +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 184E37AE1C3; Thu, 8 May 2008 21:57:51 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 May 2008 22:00:42 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FA9@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls-12, section 4.2.3 (fingerprint format) Thread-Index: AcixD5iBwSKonBf5Rq6vfAE/ROPRgAACXwjQAABA0PAACrkK8A== References: <577465F99B41C842AAFBE9ED71E70ABA308FA6@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" Cc: syslog@ietf.org Subject: Re: [Syslog] -transport-tls-12, section 4.2.3 (fingerprint format) 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 Joe, Back via the list, the list processor seems to have been recovered. Thanks for your speedy reply. > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Thursday, May 08, 2008 4:58 PM > To: Rainer Gerhards > Subject: RE: -transport-tls-12, section 4.2.3 (fingerprint format) > > Hi Rainer, > > Comments below: > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Thursday, May 08, 2008 7:39 AM > > To: Joseph Salowey (jsalowey) > > Subject: FW: -transport-tls-12, section 4.2.3 (fingerprint format) > > > > Hi Joe, > > > > it looks like there is a problem with the IETF list server. > > This and another message did not (yet?) go through. If you've > > got a minute, I would appreciate your thoughts (as I am in > > the middle of the implementation). I'll forward the other one, too. > > > > Thanks, > > Rainer > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Thursday, May 08, 2008 3:30 PM > > > To: syslog@ietf.org > > > Subject: -transport-tls-12, section 4.2.3 (fingerprint format) > > > > > > Hi, > > > > > > yet another question on the fingerprints. My context is that I am > > > thinking what I need to compare in order to authorize via > > fingerprints. > > > > > > Text in question is: > > > > > > === > > > The RECOMMENDED mechanism to generate a fingerprint is to take the > > > SHA-1 hash of the certificate and convert the 20 byte > > result into 20 > > > colon separated, hexadecimal bytes, each represented by 2 > uppercase > > > ASCII characters. When a fingerprint value is displayed or > > configured > > > the algorithm used to generate the fingerprint SHOULD be > indicated. > > > === > > > > > > What is "the algorithm used to generate..."? Is it SHA1 > et al, thus > > > the hash algorithm used? Or is it actually the algorithm > > that was used > > > the generate the fingerprint. > > > > [Joe] the algorithm is SHA1 which is the algorithm used to > generate the > fingerprint (I'm not sure I answered your question). [Rainer] Yes, you answered it, and it is what I expected. I think it may be useful that the hash algorithm is identified and not the algorithm to generate the display text. But that's only an issue if there are multiple ways to encode the display text. > > > > If it is the former, it sounds like I should compare the > > hash values > > > and not actually the fingerprints. So > > > > > > 55:D8:43:57:39:6C:23:0F:86:B1:EB:93:1E:F3:09:DE:7B:8B:62:70 > > > 55-D8-43-57-39-6C-23-0F-86-B1-EB-93-1E-F3-09-DE-7B-8B-62-70 > > > > > > are identical (it is just RECOMMENDED to use colons). > However, this > > > assumes that the fingerprint is always a hash. In this > case, I think > > it > > > would be preferable to talk directly about the hash values. > > > > [Joe] Yes, exactly. I specified the format to be compatible > with common > tools such as openssl and browsers. If another format is better than > that is OK. [Rainer] I think that format is very well. I'd just prefer to have a MUST instead of a RECOMMENDED because I think it isn't useful to allow multiple encodings here and it can cause interop problems. > > > > If the fingerprint is not necessarily a hash, I need to > compare the > > > actual fingerprint, the ASCII representation. Then, the > two strings > > > above would be different. That could cause interop problems. > > > > > > I propose that we strictly define fingerprints to be > > arbitrarily long > > > printable USASCII. If the fingerprint contains unprintable > > data, the > > > whole string must be encoded as a set of octets represented by 2 > > > USASCII hex characters delimited by colons - or we may > specify this > > > format for all cases. This does not tie us to hashes but prevents > > interoperability > > > problems due to different formats. > > > > [Joe] I think I agree with you. The fingerprint should be > general and I > think it should have a consistent format. It is also important to > realize the fingerprint is meaningless unless you know what > has was used > to generate it, so this information needs to be communicated with the > fingerprint. [Rainer] I agree - but that's also the reason why I think we should not permit different was for formatting the fingerprint. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 8 13:06:59 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 61E3A3A68A4; Thu, 8 May 2008 13:06:59 -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 73BC73A6C2F for ; Thu, 8 May 2008 13:06: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 id2REMbBd2tC for ; Thu, 8 May 2008 13:06:55 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 621903A6858 for ; Thu, 8 May 2008 13:06:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id B53947AE1DF; Thu, 8 May 2008 22:03:56 +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 q3TWGNCP8ZjD; Thu, 8 May 2008 22:03:56 +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 7DFB97AE1D7; Thu, 8 May 2008 22:03:56 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 May 2008 22:06:55 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls-12, section 4.2.3 (fingerprints) Thread-Index: AcixDGHYAKW3NlsISKSnpPNfuaTo8wADXRkAAACHySAACqjW8A== References: <577465F99B41C842AAFBE9ED71E70ABA308FA8@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" Cc: syslog@ietf.org Subject: Re: [Syslog] -transport-tls-12, section 4.2.3 (fingerprints) 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 > > > -----Original Message----- > > > From: Rainer Gerhards > > > Sent: Thursday, May 08, 2008 3:07 PM > > > To: syslog@ietf.org > > > Subject: -transport-tls-12, section 4.2.3 (fingerprints) > > > > > > Joe, > > > > > > I am implementing fingerprint authentication. I have some trouble > > > understanding this text: > > > > > > === > > > Both client and server implementations MUST make the certificate > > > fingerprint available through a management interface. If > no other > > > certificate is configured, both client and server > > implementations MUST > > > support generating a key pair and self-signed certificate. > > > === > > > > > > Especially the "If no other certificate is configured..." > > part puzzles > > > me. Does that mean that if no certificate is configured, > the syslogd > > is > > > responsible for generating a self-signed certificate > automatically? > > > > > > If so, I have concerns if that is the right thing to do. I think > > > certificates should always be generated by an operator. > > > > > > Or does it mean that there must be a management interface > > to generate > > > self-signed certificates? If so, I assume that this management > > > interface may reside outside of the core syslogd. In > > rsyslog, I will > > > provide some tools to generate self-signed certificates and > > obtain the > > > fingerprints (you may want to look at the rough prototypes > > if I made > > > myself not clear enough: > > http://git.adiscon.com/?p=rsyslog.git;a=tree;f=tools/gnutls;h= > > 1abb246805 > > 546ebd2f1f008a3cf256d5c76b7cbc;hb=HEAD ). > > > > [Joe] I don't know that we need to restrict this to a particular > implementation. I think it would be good to provide a management > interface to do the generation. It seems that it would be an > acceptable > implementation to auto-generate it as well. [Rainer] As long as the syslogd is not required to auto-generate certs, I am happy enough ;) However, I wonder why it would be useful to auto-generate certs. Probably I am overlooking somehting obvious. But: isn't cert auto-generation equal to no authentication? After all, if a *self-signed* cert is generated by the remote peer AND we accept it, doesn't that essentially mean we accept any peer because the peer can put whatever it likes into the cert? I do not see why this is any better than having no cert at all... Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 8 13:12:53 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 0D3B73A684F; Thu, 8 May 2008 13:12:53 -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 D2B973A684F for ; Thu, 8 May 2008 13:12: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, 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 dzYEyGtGw-o5 for ; Thu, 8 May 2008 13:12:50 -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 8C1023A66B4 for ; Thu, 8 May 2008 13:12:50 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 May 2008 13:12:49 -0700 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 m48KCnvn002494; Thu, 8 May 2008 13:12:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m48KCmxk026608; Thu, 8 May 2008 20:12:49 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); Thu, 8 May 2008 13:12:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 May 2008 13:13:37 -0700 Message-ID: In-Reply-To: <124CF5A7D55D6F43A4FD9437F28254D8B8E9A8@ALPMLVEM05.e2k.ad.ge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls-12, IP addresses Thread-Index: AciwgnengYGl1+sCRr+5vGq+XE9BugAAoK6QADCfSKA= References: <577465F99B41C842AAFBE9ED71E70ABA308F92@grfint2.intern.adiscon.com> <124CF5A7D55D6F43A4FD9437F28254D8B8E9A8@ALPMLVEM05.e2k.ad.ge.com> From: "Joseph Salowey (jsalowey)" To: "Moehrke, John (GE Healthcare)" , X-OriginalArrivalTime: 08 May 2008 20:12:48.0897 (UTC) FILETIME=[E2FB3F10:01C8B147] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2159; t=1210277569; x=1211141569; c=relaxed/simple; s=sjdkim2002; 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]=20-transport-tls-12,=20IP=20ad dresses |Sender:=20; bh=tQtSYAucGpRpLKw+V3gBRg4T8z00xLOTuf2pMBIVA/Q=; b=AgwgHacOq0u3TfnDb1R79ct5uFB9ZrmQ8vpX91WZLm+xBwqnZdDrW7r/VH QEneUXSyCTT8aHPvrv4wnC8OmivvqHeOwGrPyoH+UhOT/YXXCRRKJpbxttF9 9HKS0J+exo; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] -transport-tls-12, IP addresses 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 > > Neither IP address nor hostname are poor identities. The > normal TLS validation proof of possession of the private key > is far stronger. I would recommend against requiring IP > address or hostname checking. > [Joe] Are advocating use of certificate fingerprints (second option)? > Further I am disturbed at the overly prescriptiveness of this > specification. There is no need to include policy decisions > like key management in this specification. > [Joe] Can you elaborate on this a bit? What text do you find problematic? > John > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf > > Of Rainer Gerhards > > Sent: Wednesday, May 07, 2008 3:40 PM > > To: syslog@ietf.org > > Subject: [Syslog] -transport-tls-12, IP addresses > > > > Joe, > > > > [Editor's Note: How useful is it to match against IP address? Do > we > > expect deployments to issue certificates with IP > addresses in them? > > Are IP addresses typically used in configuration? ] > > > > I find this a tough question. In my experience, it is not > uncommon to > > configure forwarding via IP addresses instead of hostnames. > One reason > > for this is because of reliability of the logging system when DNS is > not > > (yet --> system startup) available. On the other hand, I > find it even > a > > bit disturbing to have a certificate issued for an IP > address. But it > > may make sense. I personally would expect that operators > tend to use > > hostnames inside the certificate. The problem, of course, would be > that > > the configuration then needs both the name and IP address... > > > > I hope this is useful information, even though I am undecided. > > > > Rainer > > _______________________________________________ > > 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 Fri May 9 01:31:10 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 A250C3A6993; Fri, 9 May 2008 01:31:10 -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 E0B2128C1A8 for ; Fri, 9 May 2008 01:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 Dp+FpmrkaEWV for ; Fri, 9 May 2008 01:16:39 -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 ED7103A67B0 for ; Fri, 9 May 2008 01:15:35 -0700 (PDT) X-Trace: 77322377/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.32 X-SBRS: None X-RemoteIP: 213.116.60.32 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAIWjI0jVdDwg/2dsb2JhbACLUJ9hBA X-IP-Direction: IN Received: from 1cust32.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.32]) by smtp.pipex.tiscali.co.uk with SMTP; 09 May 2008 09:09:37 +0100 Message-ID: <000401c8b1a3$0b357ee0$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA308F86@grfint2.intern.adiscon.com> Date: Thu, 8 May 2008 17:35:50 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] application data was -transport-tls, section 4.3 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I don't see it; my reading is that application data as defined in this I-D is a complete syslog message which may span TLS records, may be packed many into one TLS record. TLS allows an empty record, ie one with no application data as defined by TLS. So it would be valid to have TLS record one - syslog message 1 fragment 1 TLS record two - no TLS application data TLS record three - syslog message 1 fragment 2, syslog message 2 The only thing that I take this ABNF as requiring is that at least one syslog message be sent in a TLS session:-) Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Wednesday, May 07, 2008 2:04 PM Subject: [Syslog] -transport-tls, section 4.3 > Hi list, > > A couple of more things I noticed while implementing: > > Section 4.3, it is specified: > > APPLICATION-DATA = 1*SYSLOG-FRAME > > Is it actually required to check if there is at least one SYSLOG-FRAME > in a TLS record? That places some additional burden onto the receiving > application AND (this is the biggie) requires the application to know > about TLS records. > > I have abstracted this knowledge onto a driver level and I think others > will most probably work with a similar abstraction. Knowing about the > TLS records IMO unnecessarily breaks the abstraction layers. So I would > prefer a definition that permits empty TLS records (at least from the > syslog POV). > > APPLICATION-DATA = *SYSLOG-FRAME > > Having said this, I am not even sure if the ABNF "APPLICATION-DATA" > relates to the TLS record. It may be useful to clarify. If it specifies > the stream from an upper layer perspective, it even more must be "*", > because I don't think we should require that in a syslog session always > at least one message is transmitted. There may be valid reason that a > session is closed without a message being sent over it. > > Again, section 4.3: > > It states " SYSLOG-MSG is defined in syslog [2] protocol." However, it > does not state what MUST/SHOULD happen if the SYSLOG-MSG is malformed. > Possible options are > > a) ignore this message, but continue receiving > b) process the message with another parser (e.g. according to RFC 3164) > c) ignore the message and close the connection > > I think we should specify at least a SHOULD. I envision this to become a > big interoperability issue. > > > Section 5 > > ... is missing a security consideration. An attacker may use a > maliciously large MSG-LEN (S. 4.3) in order to try DoS (hoping the > implementation tries to malloc memory based on the frame size). While > this should be a sufficiently well-known attack, I think it doesn't hurt > to mention it. > > > In general, I wonder if we should specify the situation where a TLS > session is closed by the server (for whatever reason) and the client > re-instantiates the connection. For example, if a client tries to > connect to a server, but the handshake fails for a persistent reason > (e.g. invalid client credentials), the client will eventually run into > an endless loop trying to connect to that server. This could lead to a > close-to-DoS. I wonder if it would be useful to specify some > rate-limiting or similar mechanism to prevent that situation. At a > minimum, I think it would make sense to mention it, so that implementers > and knowledgeable operators are aware of the potential problem. > > Thanks, > Rainer > > _______________________________________________ > 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 Fri May 9 02:02: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 3316C3A688C; Fri, 9 May 2008 02:02: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 3967E3A67B0 for ; Fri, 9 May 2008 01:44:12 -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 J+z76uI6ScTl for ; Fri, 9 May 2008 01:44:11 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id D56783A67A9 for ; Fri, 9 May 2008 01:44:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id D4E9C7ADEAD; Fri, 9 May 2008 10:23:42 +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 PmB-jAX7uX47; Fri, 9 May 2008 10:23:42 +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 903767AD87B; Fri, 9 May 2008 10:23:42 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 May 2008 10:24:41 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FB1@grfint2.intern.adiscon.com> In-Reply-To: <000401c8b1a3$0b357ee0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] application data was -transport-tls, section 4.3 Thread-Index: AcixrWjD0l+5up68TZ6Os79HK4UMpwAAAkng References: <577465F99B41C842AAFBE9ED71E70ABA308F86@grfint2.intern.adiscon.com> <000401c8b1a3$0b357ee0$0601a8c0@allison> From: "Rainer Gerhards" To: "tom.petch" , Subject: Re: [Syslog] application data was -transport-tls, section 4.3 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 Tom, > I don't see it; my reading is that application data as defined in this > I-D is a > complete syslog message which may span TLS records, may be packed many > into one > TLS record. TLS allows an empty record, ie one with no application > data as > defined by TLS. So it would be valid to have > TLS record one - syslog message 1 fragment 1 > TLS record two - no TLS application data > TLS record three - syslog message 1 fragment 2, syslog message 2 That was one of my interpretations and I am fine with that. > The only thing that I take this ABNF as requiring is that at least one > syslog > message be sent in a TLS session:-) *This* I find problematic. In an implementation, do I need to keep a counter to prevent me from closing a syslog session without sending a single message over it? And, if so, does that mean I need to send a dummy message before closing just to fullfil this requirement? ;) And how should the server react if a session is torn down without a message being sent? Should it treat this as an error? ;) How much simpler would be an implementation if it is permitted to send 0 or more message inside a session... I know I am looking at a very (very!) unusual case. But it may happen. If the draft stays as is, I'll most probably simple ignore the requirement and hope that always at least a single message is sent. But strictly speaking this is not the right thing to do ;) So why not specify it in the way people will implement it in any case? ;) Rainer > > Tom Petch > > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Wednesday, May 07, 2008 2:04 PM > Subject: [Syslog] -transport-tls, section 4.3 > > > > Hi list, > > > > A couple of more things I noticed while implementing: > > > > Section 4.3, it is specified: > > > > APPLICATION-DATA = 1*SYSLOG-FRAME > > > > Is it actually required to check if there is at least one SYSLOG- > FRAME > > in a TLS record? That places some additional burden onto the > receiving > > application AND (this is the biggie) requires the application to know > > about TLS records. > > > > I have abstracted this knowledge onto a driver level and I think > others > > will most probably work with a similar abstraction. Knowing about the > > TLS records IMO unnecessarily breaks the abstraction layers. So I > would > > prefer a definition that permits empty TLS records (at least from the > > syslog POV). > > > > APPLICATION-DATA = *SYSLOG-FRAME > > > > Having said this, I am not even sure if the ABNF "APPLICATION-DATA" > > relates to the TLS record. It may be useful to clarify. If it > specifies > > the stream from an upper layer perspective, it even more must be "*", > > because I don't think we should require that in a syslog session > always > > at least one message is transmitted. There may be valid reason that a > > session is closed without a message being sent over it. > > > > Again, section 4.3: > > > > It states " SYSLOG-MSG is defined in syslog [2] protocol." However, > it > > does not state what MUST/SHOULD happen if the SYSLOG-MSG is > malformed. > > Possible options are > > > > a) ignore this message, but continue receiving > > b) process the message with another parser (e.g. according to RFC > 3164) > > c) ignore the message and close the connection > > > > I think we should specify at least a SHOULD. I envision this to > become a > > big interoperability issue. > > > > > > Section 5 > > > > ... is missing a security consideration. An attacker may use a > > maliciously large MSG-LEN (S. 4.3) in order to try DoS (hoping the > > implementation tries to malloc memory based on the frame size). While > > this should be a sufficiently well-known attack, I think it doesn't > hurt > > to mention it. > > > > > > In general, I wonder if we should specify the situation where a TLS > > session is closed by the server (for whatever reason) and the client > > re-instantiates the connection. For example, if a client tries to > > connect to a server, but the handshake fails for a persistent reason > > (e.g. invalid client credentials), the client will eventually run > into > > an endless loop trying to connect to that server. This could lead to > a > > close-to-DoS. I wonder if it would be useful to specify some > > rate-limiting or similar mechanism to prevent that situation. At a > > minimum, I think it would make sense to mention it, so that > implementers > > and knowledgeable operators are aware of the potential problem. > > > > Thanks, > > Rainer > > > > _______________________________________________ > > 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 Fri May 9 02:16:20 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 E04693A6A06; Fri, 9 May 2008 02:16:20 -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 B2B203A68A5 for ; Fri, 9 May 2008 02:01:30 -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=[AWL=0.000, 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 2Ks1cETrKShj for ; Fri, 9 May 2008 02:01:22 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 7BCDA28C102 for ; Fri, 9 May 2008 02:01:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id B1A3A7AE1C5; Fri, 9 May 2008 10:35:23 +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 FoAc82gmquqF; Fri, 9 May 2008 10:35:23 +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 30BF37ADFBD; Fri, 9 May 2008 10:35:23 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 May 2008 10:36:22 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5ow References: <20080507150001.D3CB428C65B@core3.amsl.com> From: "Rainer Gerhards" To: , "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 all, I agree to Robert, policy decisions need to be separated. I CC Pasi because my comment is directly related to IESG requirements, which IMHO cannot be delivered by *any* syslog TLS document without compromise [comments directly related to IESG are somewhat later, I need to level ground first]. Let me tell the story from my implementor's POV. This is necessarily tied to rsyslog, but I still think there is a lot of general truth in it. So I consider it useful as an example. I took some time yesterday to include the rules laid out in 4.2 into rsyslog design. I quickly came to the conclusion that 4.2. is talking about at least two things: a) low-level handshake validation b) access control In a) we deal with the session setup. Here, I see certificate exchange and basic certificate validation (for example checking the validity dates). In my current POV, this phase ends when the remote peer can positively be identified. Once we have positive identification, b) kicks in. In that phase, we need to check (via ACLs) if the remote peer is permitted to talk to us (or we are permitted to talk to it). Please note that from an architectural POV, this can be abstracted to a higher layer (and in rsyslog it probably will). For that layer, it is quite irrelevant if the remote peer's identity was obtained via a certificate (in the case of transport-tls), a simple reverse lookup (UDP syslog), SASL (RFC 3195) or whatever. What matters is that the ACL engine got a trusted identify from the transport layer and verifies that identity [level of trust varies, obviously]. Most policy decisions happen on that level. There is some grayish between a) and b). For example, I can envision that if there is a syslog.conf rule (forward everything to server.example.net) *.* @@server.example.net The certificate name check for server.example.net (using dNSName extension) could probably be part of a) - others may think it is part of b). Also, even doing a) places some burden onto the system, like the need to have trust anchors configured in order to do the validation. This hints at at least another sub-layer. I think it would be useful to spell out these different entities in the draft. Coming back to policy decisions, one must keep in mind that the IESG explicitly asked for those inside the document. This was done based on the -correct- assumption that today's Internet is no longer a friendly place. So the IESG would like to see a default policy implemented that provides at least a minimum acceptable security standard. Unfortunately, this is not easy to do in the world of syslog. For the home users, we cannot rely on any ability to configure something. For the enterprise folks, we need to have defaults that do not get into their way of doing things [aka "can be easily turned off"]. There is obviously much in between these poles, so it largely depends on the use case. I have begun a wiki page with use cases and hope people will contribute to it. It could lead us to a much better understanding of the needs (and the design decisions that need to be made to deliver these). It is available at http://wiki.rsyslog.com/index.php/TLS_for_syslog_use_cases After close consideration, I think the draft currently fails on addressing the two use cases define above properly. Partly it fails because it is not possible under the current IESG requirement to be safe by default. We cannot be fully safe by default without configuration, so whatever we specify will fail for the home user. A compromise may be to provide "good enough" security in the default policy. I see two ways of doing that: one is to NOT address the Masquerade and Modification threats in the default policy, just the Disclosure threat. That leads us to unauthenticated syslog being the default (contrary to what is currently implemented) [Disclosure is addressed in this scenario as long as the client configs are not compromised, which I find sufficiently enough - someone who can compromise the client config can find other ways to get hold of the syslog message content]. An alternative is to use the way HTTPS works: we only authenticate the server. To authenticate, we need to have trusted certificate inside the server. As we can see in HTTPS, this doesn't really require PKI. It is sufficient to have the server cert singed by one of few globally trusted CAs and have this root certificates distributed with all client installations as part of their setup procedure. This is quite doable. In that scenario, a client can verify a server's identity and the above sample (*.* @server.example.net) could be verified with sufficient trust. The client, however, is still not authenticated. However, the threats we intended to address are almost all addressed, except for the access control issue which is defined as part of the Masquerade threat (which I think is even a different beast and deserves its own threat definition now that I think about it). In short we just have an access control issue in that scenario. Nothing else. The problem, however, is that the server still needs a certificate and now even one that, for a home user, is prohibitively expensive. The end result will be that people turn off TLS, because they neither know how to obtain the certificate nor are willing to trade in a weekend vacation for a certificate ;) In the end result, even that mode will be less useful than anonymous authentication. The fingerprint idea is probably a smart solution to the problem. It depends on the ability to auto-generate a certificate [I expressed that I don't like that idea yesterday, but my thinking has evolved ;)] OR to ship every device/syslogd with a unique certificate. In this case, only minimal interaction is required. The idea obviously is like with SSH: if the remote peer is unknown, the user is queried if the connection request is permitted and if the certificate should be accepted in the future. If so, it is added permanently to the valid certificate store and used in the future to authenticate requests from the same peer. This limits the security weakness to the first session. HOWEVER, the problem with syslog is that the user typically cannot be prompted when the initial connection happens (everything is background activity). So the request must actually be logged and an interface be developed that provides for user notification and the ability to authorize the request. This requires some kind of "unapproved certificate store" plus a management interface for it. Well done, this may indeed enable a home user to gain protection from all three threats without even knowing what he really does. It "just" requires some care in approving new fingerprints, but that's a general problem with human nature that we may tackle by good user interface desig but can't solve from a protocol point of view. The bad thing is that it requires much more change to existing syslogd technology. That, I fear, reduces acceptance rate. Keep in mind that we already have a technically good solution (RFC 3195) which miserably failed in practice due to the fact it required too much change. If I look at *nix implementations, syslogd implementers are probably tempted to "just" log a message telling "could not accept remote connection due to invalid fingerprint xx:xx:..." and leave it to the user to add it to syslog.conf. However, I fear that for most home setups even that would be too much. So in the end effect, in order to avoid user hassle, most vendors would probably default back to UDP syslog and enable TLS only on user request. From my practical perspective this sounds even reasonable (given the needs and imperfections of the real world...). If that assessment is true, we would probably be better off by using anonymous TLS as the default policy, with the next priority on fingerprint authentication as laid out above. A single big switch could change between these two in actual implementations. Those users that "just want to get it running" would never find that switch but still be somewhat protected while the (little) more technically aware can turn it to fingerprint authentication and then will hopefully be able to do the remaining few configuration steps. Another policy is the certificate chain based policy, where using public CAs would make sense to me. To wrap it up: 1. I propose to lower the default level of security for the reasons given. My humble view is that lower default security will result in higher overall security. 2. We should split authentication policies from the protocol itself ... just as suggested by Robert and John. We should define a core set of policies (I think I described the most relevant simple cases above, Robert described some complex ones) and leave it others to define additional policies based on their demand. Policies should go either into their own section OR into their own documents. I have a strong favor of putting them into their own documents if that enables us to finally finish/publish -transport-tls and the new syslog RFC series. If that is not an option, I'd prefer to spend some more work on -transport-tls, even if it delays things further, instead of producing something that does not meet the needs found in practice. Rainer > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of robert.horn@agfa.com > Sent: Thursday, May 08, 2008 5:53 PM > To: Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt > > Section 4.2 is better, but it still needs work to separate the policy > decisions from the protocol definition. Policy decisions are driven by > risk analysis of the assets, threats, and environment (among other > things). These are not uniform over all uses of syslog. That makes it > important to separate the policy from the protocol, in both the > specifications and in the products. > > In the healthcare environment we use TLS to protect many of our > connections. This is both an authentication protection and a > confidentiality protection. The policy decisions regarding key > management > and verification will be very similar for a healthcare use of syslog. > Some > healthcare sites would reach the same policy decision as is in 4.2, but > here are three other policy decisions that are also appropriate: > > Policy A: > The clients are provided with their private keys and the public > certificates for their authorized servers by means of physical media, > delivered by hand from the security office to the client machine > support > staff. (The media is often CD-R because it's cheap, easy to create, > easy > to destroy, and easy to use.) During TLS establishment the clients use > their assigned private key and the server confirms that the connection > is > from a machine with one of the assigned private keys. The client > confirms > that the server matches one of the provided public certificates by > direct > matching. This is similar to the fingerprint method, but not the same. > My > most recent experience was with an installation using this method. We > had > two hours to install over 100 systems, including the network > facilities. > This can only be done by removing as many installation schedule > dependencies as possible. The media method removed the certificate > management dependencies. > > Policy B: > These client systems require safety and functional certification > before > they are made operational. This is done by inspection by an acceptance > team. The acceptance team has a "CA on a laptop". After accepting > safety > and function, they establish a direct isolated physical connection > between > the client and the laptop. Then using standard key management tools, > the > client generates a private key and has the corresponding public > certificate generated and signed by the laptop. The client is also > provided with a public certificate for the CA that must sign the certs > for > all incoming connections. > > During a connection setup the client confirms that the server key has > been > signed by that CA. This is similar to a trusted anchor, but not the > same. > There is no chain of trust permitted. The key must have been directly > signed by the CA. During connection setup the server confirms that the > client cert was signed by the "CA on a laptop". Again, no chain of > trust > is permitted. This policy is incorporating the extra aspect of "has > been > inspected by the acceptance team" as part of the authentication > meaning. > They decided on a policy-risk basis that there was not a need to > confirm > re-inspection, but the "CA on a laptop" did have a revocation server > that > was kept available to the servers, so that the acceptance team could > revoke at will. > > Policy C: > This system was for a server that accepted connections from several > independent organizations. Each organization managed certificates > differently, but ensured that the organization-CA had signed all certs > used for external communications by that organization. All of the > client > machines were provided with the certs for the shared servers (by a > method > similar to the fingerprint method). During TLS connection the clients > confirmed that the server cert matched one of the certs on their list. > The > server confirmed that the client cert had been signed by the CA > responsible for that IP subnet. The server was configured with a list > of > organization CA certs and their corresponding IP subnets. > > I do not expect any single policy choice to be appropriate for all > syslog > uses. I think it will be better to encourage a separation of function > in > products. There is more likely to be a commonality of configuration > needs > for all users of TLS on a particular system than to find a commonality > of > needs for all users of syslog. The policy decisions implicit in > section > 4.2 make good sense for many uses. They are not a complete set. So a > phrasing that explains the kinds of maintenance and verification needs > that are likely is more appropriate. The mandatory verifications can > be > separated from the key management system and kept as part of the > protocol > definition. The policy decisions should be left as important examples. > > Kind Regards, > > Robert Horn | Agfa HealthCare > Research Scientist | HE/Technology Office > T +1 978 897 4860 > > Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, > 07660-2199, United States > http://www.agfa.com/healthcare/ > Click on link to read important disclaimer: > http://www.agfa.com/healthcare/maildisclaimer > _______________________________________________ > 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 Fri May 9 06:31:45 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 C2DF228C1AD; Fri, 9 May 2008 06:31:45 -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 1ED273A6822 for ; Fri, 9 May 2008 06:21:30 -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 rp8xNM40gMNs for ; Fri, 9 May 2008 06:21:29 -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 496E53A6801 for ; Fri, 9 May 2008 06:21:29 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 May 2008 06:20:02 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m49DK2aA004826; Fri, 9 May 2008 06:20:02 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m49DK2dK003589; Fri, 9 May 2008 13:20:02 GMT Date: Fri, 9 May 2008 06:20:02 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA308FA8@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2697; t=1210339202; x=1211203202; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Self-signed=20certs=20-=20was=3A=20Re=3A=20[Sys log]=20-transport-tls-12,=20section=0A=204.2.3=20(fingerprin ts) |Sender:=20; bh=WgFQOC1MxADQIyNu/tpPtdv6lsG3vGvVyWglW7m931s=; b=K8VsXfaRTakPb2n9c8YMNvCgtCgO2ctfjdWSjOePxTtF8pUv+pw5K7hdSi xP0IfDCeErmcX3Da0psPvV45WR4r9UhJXXMdHWkOGidlEyxppU48Q85ARCCB jG9hv+10q4PO/EzfbrZxq8oKWwM3Y5ahSegsOMoIAxQ6CXbZlaF44=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog@ietf.org Subject: [Syslog] Self-signed certs - was: Re: -transport-tls-12, section 4.2.3 (fingerprints) 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, On Thu, 8 May 2008, Rainer Gerhards wrote: > However, I wonder why it would be useful to auto-generate certs. > Probably I am overlooking somehting obvious. But: isn't cert > auto-generation equal to no authentication? After all, if a > *self-signed* cert is generated by the remote peer AND we accept it, > doesn't that essentially mean we accept any peer because the peer can > put whatever it likes into the cert? I do not see why this is any better > than having no cert at all... It minimally protects against masquerade and disclosure, two of the threats we agreed upon. It will also provide a TCP-based transport for anyone who wishes/needs to have a mechanism to throttle the flow of packets for congestion control - something that you cannot do with the UDP transport. Those are the reasons I can think of. You do raise a good point by questioning this and I'd like to see some discussion from the WG. Are these reasons sufficient to keep self-signed certs in the specification? If so, should specific comments be made about their use? WG Chair Hat sort'a on, sort'a off: I'm thinking that a self-signed cert is the method of least effort to provide congestion control for syslog and it should be included in the document just for that reason. This was the objection raised by the Transport ADs when they saw that syslog-transport-udp was the only REQUIRED transport. I agree that self-signed certs don't really provide good protection and that should be noted in the Security Considerations Section. If you don't agree with this, please object now. If you do agree with this, does the following text work: === (Perhaps as a third paragraph in Section 4.2.4) Self-signed certificates will provide minimal protection against modification and disclosure. Their use will not provide effective protection against masqeurade unless they are used with certificate fingerprint authorization lists. The use of self-signed certificates without certificate fingerprint authorization lists is NOT RECOMMENDED. However since tls is a tcp-based protocol, enabling tls, even with self-signed certificates, will effectively enable congestion control in the network. See Section 8.6 of [syslog-protocol]. And perhaps merge the first three sentences of the above with the second paragraph in Sec Considerations section 5.1. Current: The use of self-signed certificates with certificate fingerprint authorization lists provides more protection from masquerade and man- in-the-middle attacks than forgoing certificate validation and authorization. === Thanks, Chris _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 9 06:31:46 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 7C27328C1B8; Fri, 9 May 2008 06:31:46 -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 E3DE53A6822 for ; Fri, 9 May 2008 06:22:36 -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 Bwko7B4UiGS6 for ; Fri, 9 May 2008 06:22:36 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id C87BC3A67FA for ; Fri, 9 May 2008 06:22:35 -0700 (PDT) X-Trace: 24305291/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.117 X-SBRS: None X-RemoteIP: 62.188.135.117 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACvoI0g+vId1/2dsb2JhbACLUZ9WBA X-IP-Direction: IN Received: from 1cust117.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.117]) by smtp.pipex.tiscali.co.uk with SMTP; 09 May 2008 14:01:57 +0100 Message-ID: <020601c8b1cb$e23d3a40$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA308F92@grfint2.intern.adiscon.com> Date: Fri, 9 May 2008 13:54:28 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] -transport-tls-12, IP addresses 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I think that we should allow IP addresses. At the entry level network box, I think that they are widely used. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Wednesday, May 07, 2008 10:39 PM Subject: [Syslog] -transport-tls-12, IP addresses > Joe, > > [Editor's Note: How useful is it to match against IP address? Do we > expect deployments to issue certificates with IP addresses in them? > Are IP addresses typically used in configuration? ] > > I find this a tough question. In my experience, it is not uncommon to > configure forwarding via IP addresses instead of hostnames. One reason > for this is because of reliability of the logging system when DNS is not > (yet --> system startup) available. On the other hand, I find it even a > bit disturbing to have a certificate issued for an IP address. But it > may make sense. I personally would expect that operators tend to use > hostnames inside the certificate. The problem, of course, would be that > the configuration then needs both the name and IP address... > > I hope this is useful information, even though I am undecided. > > Rainer > _______________________________________________ > 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 Fri May 9 06:31:46 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 97D3028C1B4; Fri, 9 May 2008 06:31:46 -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 7A1CB3A68AD for ; Fri, 9 May 2008 06:22:39 -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=[AWL=0.000, 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 58iIYomNLlia for ; Fri, 9 May 2008 06:22:35 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id CBDFF3A6801 for ; Fri, 9 May 2008 06:22:31 -0700 (PDT) X-Trace: 24305265/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.117 X-SBRS: None X-RemoteIP: 62.188.135.117 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACvoI0g+vId1/2dsb2JhbACLUZ9WBA X-IP-Direction: IN Received: from 1cust117.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.117]) by smtp.pipex.tiscali.co.uk with SMTP; 09 May 2008 14:01:55 +0100 Message-ID: <020501c8b1cb$e10f1a80$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA308F86@grfint2.intern.adiscon.com> <000401c8b1a3$0b357ee0$0601a8c0@allison> <577465F99B41C842AAFBE9ED71E70ABA308FB1@grfint2.intern.adiscon.com> Date: Fri, 9 May 2008 13:52:00 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] application data was -transport-tls, section 4.3 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org ---- Original Message ----- From: "Rainer Gerhards" To: "tom.petch" ; Sent: Friday, May 09, 2008 10:24 AM Subject: RE: [Syslog] application data was -transport-tls, section 4.3 Hi Tom, > I don't see it; my reading is that application data as defined in this > I-D is a > complete syslog message which may span TLS records, may be packed many > into one > TLS record. TLS allows an empty record, ie one with no application > data as > defined by TLS. So it would be valid to have > TLS record one - syslog message 1 fragment 1 > TLS record two - no TLS application data > TLS record three - syslog message 1 fragment 2, syslog message 2 That was one of my interpretations and I am fine with that. > The only thing that I take this ABNF as requiring is that at least one > syslog > message be sent in a TLS session:-) *This* I find problematic. In an implementation, do I need to keep a counter to prevent me from closing a syslog session without sending a single message over it? And, if so, does that mean I need to send a dummy message before closing just to fullfil this requirement? ;) And how should the server react if a session is torn down without a message being sent? Should it treat this as an error? ;) How much simpler would be an implementation if it is permitted to send 0 or more message inside a session... I know I am looking at a very (very!) unusual case. But it may happen. If the draft stays as is, I'll most probably simple ignore the requirement and hope that always at least a single message is sent. But strictly speaking this is not the right thing to do ;) So why not specify it in the way people will implement it in any case? ;) Well if two of us can come up with this interpretation, which does seem rather silly, then I think that the text should be changed as you suggested to APPLICATION-DATA = *SYSLOG-FRAME Tom Petch Rainer > > Tom Petch > > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Wednesday, May 07, 2008 2:04 PM > Subject: [Syslog] -transport-tls, section 4.3 > > > > Hi list, > > > > A couple of more things I noticed while implementing: > > > > Section 4.3, it is specified: > > > > APPLICATION-DATA = 1*SYSLOG-FRAME > > > > Is it actually required to check if there is at least one SYSLOG- > FRAME > > in a TLS record? That places some additional burden onto the > receiving > > application AND (this is the biggie) requires the application to know > > about TLS records. > > > > I have abstracted this knowledge onto a driver level and I think > others > > will most probably work with a similar abstraction. Knowing about the > > TLS records IMO unnecessarily breaks the abstraction layers. So I > would > > prefer a definition that permits empty TLS records (at least from the > > syslog POV). > > > > APPLICATION-DATA = *SYSLOG-FRAME > > > > Having said this, I am not even sure if the ABNF "APPLICATION-DATA" > > relates to the TLS record. It may be useful to clarify. If it > specifies > > the stream from an upper layer perspective, it even more must be "*", > > because I don't think we should require that in a syslog session > always > > at least one message is transmitted. There may be valid reason that a > > session is closed without a message being sent over it. > > > > Again, section 4.3: > > > > It states " SYSLOG-MSG is defined in syslog [2] protocol." However, > it > > does not state what MUST/SHOULD happen if the SYSLOG-MSG is > malformed. > > Possible options are > > > > a) ignore this message, but continue receiving > > b) process the message with another parser (e.g. according to RFC > 3164) > > c) ignore the message and close the connection > > > > I think we should specify at least a SHOULD. I envision this to > become a > > big interoperability issue. > > > > > > Section 5 > > > > ... is missing a security consideration. An attacker may use a > > maliciously large MSG-LEN (S. 4.3) in order to try DoS (hoping the > > implementation tries to malloc memory based on the frame size). While > > this should be a sufficiently well-known attack, I think it doesn't > hurt > > to mention it. > > > > > > In general, I wonder if we should specify the situation where a TLS > > session is closed by the server (for whatever reason) and the client > > re-instantiates the connection. For example, if a client tries to > > connect to a server, but the handshake fails for a persistent reason > > (e.g. invalid client credentials), the client will eventually run > into > > an endless loop trying to connect to that server. This could lead to > a > > close-to-DoS. I wonder if it would be useful to specify some > > rate-limiting or similar mechanism to prevent that situation. At a > > minimum, I think it would make sense to mention it, so that > implementers > > and knowledgeable operators are aware of the potential problem. > > > > Thanks, > > Rainer > > > > _______________________________________________ > > 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 Fri May 9 09:48:40 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 9A4F028C0E3; Fri, 9 May 2008 09:48:40 -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 094073A6803 for ; Fri, 9 May 2008 09:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 9phB1UdJsGVZ for ; Fri, 9 May 2008 09:19:31 -0700 (PDT) Received: from ext-ch1gw-7.online-age.net (ext-ch1gw-7.online-age.net [64.37.194.15]) by core3.amsl.com (Postfix) with ESMTP id CE43E3A67CE for ; Fri, 9 May 2008 09:19:30 -0700 (PDT) Received: from int-ch1gw-6.online-age.net (int-ch1gw-6 [3.159.232.70]) by ext-ch1gw-7.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id m49GIYtt032555 for ; Fri, 9 May 2008 12:18:34 -0400 Received: from cinmlef08.e2k.ad.ge.com (int-ch1gw-6 [3.159.232.70]) by int-ch1gw-6.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id m49GGJt7023190 for ; Fri, 9 May 2008 12:16:22 -0400 Received: from ALPMLVEM05.e2k.ad.ge.com ([3.159.17.55]) by cinmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 9 May 2008 12:18:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 12:18:29 -0400 Message-ID: <124CF5A7D55D6F43A4FD9437F28254D8C28025@ALPMLVEM05.e2k.ad.ge.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABLMh4A= References: <20080507150001.D3CB428C65B@core3.amsl.com> <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> From: "Moehrke, John (GE Healthcare)" To: "Rainer Gerhards" , , "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 09 May 2008 16:18:31.0218 (UTC) FILETIME=[525D6920:01C8B1F0] Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 Could someone please point me at the mentioned IESG requirement to include policy decisions? This is a very unusual position. And as your own assessment shows is something that simply will not scale. For example, there are healthcare systems installed on military ships where all network wiring is inside compressed nitrogen casings with sensors. This is clearly a sensitive environment, but they have already managed many of the risks. John > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf > Of Rainer Gerhards > Sent: Friday, May 09, 2008 3:36 AM > To: robert.horn@agfa.com; Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt > > Hi all, > > I agree to Robert, policy decisions need to be separated. I CC Pasi > because my comment is directly related to IESG requirements, which IMHO > cannot be delivered by *any* syslog TLS document without compromise > [comments directly related to IESG are somewhat later, I need to level > ground first]. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 9 10:03:49 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 3F1003A69EF; Fri, 9 May 2008 10:03:49 -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 4E66F3A68D5 for ; Fri, 9 May 2008 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 gaQO+fn3Hjnw for ; Fri, 9 May 2008 09:43:02 -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 76CF63A68D4 for ; Fri, 9 May 2008 09:43:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,461,1204531200"; d="scan'208";a="13061645" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 09 May 2008 09:39:30 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m49GdUVg000974; Fri, 9 May 2008 09:39:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m49GdUC0003900; Fri, 9 May 2008 16:39:30 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 09:39:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 09:40:18 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls-12, section 4.2.3 (fingerprints) Thread-Index: AcixDGHYAKW3NlsISKSnpPNfuaTo8wADXRkAAACHySAACqjW8AArDGeg References: <577465F99B41C842AAFBE9ED71E70ABA308FA8@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" X-OriginalArrivalTime: 09 May 2008 16:39:30.0099 (UTC) FILETIME=[40B76830:01C8B1F3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1212; t=1210351170; x=1211215170; 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-transport-tls-12,=20section=204.2.3=20 (fingerprints) |Sender:=20; bh=j3WqRDCfIKx1ywgxAFCuSr6xgEOBxHLzW13tFQiaook=; b=jX4IHTn+nkUG1v3NzGgTZWXZcFs5/pFWK7Qzd9NX3ztHG7CNzBaJjTO7BQ /sDbXKeRW7osx/HhoLr8VQaBDuB9tXEVXm5wGCeWYT3jFOzFV/0o6fxFbaVM d6DbvacVgQo8u+Y2kCK6b2a0jm4r7yi04T7Pw/iUlQc71bekXn40Y=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] -transport-tls-12, section 4.2.3 (fingerprints) 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 > > [Joe] I don't know that we need to restrict this to a particular > > implementation. I think it would be good to provide a management > > interface to do the generation. It seems that it would be an > > acceptable implementation to auto-generate it as well. > > [Rainer] As long as the syslogd is not required to > auto-generate certs, I am happy enough ;) > > However, I wonder why it would be useful to auto-generate certs. > Probably I am overlooking somehting obvious. But: isn't cert > auto-generation equal to no authentication? After all, if a > *self-signed* cert is generated by the remote peer AND we > accept it, doesn't that essentially mean we accept any peer > because the peer can put whatever it likes into the cert? I > do not see why this is any better than having no cert at all... > [Joe] When I was thinking of auto-generation I was expecting the certificate to be persistent and the fingerprint would be available to be communicated out of band to the verifier. If you generate a new cert each time the process starts and the other side does not know the fingerprint then what you say is true. > Rainer > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 9 10:33:50 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 0D09C3A69F5; Fri, 9 May 2008 10:33:50 -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 D6CC43A681A for ; Fri, 9 May 2008 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=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 5VaMAOV0QVKO for ; Fri, 9 May 2008 10:08:58 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 20F783A67CE for ; Fri, 9 May 2008 10:08:56 -0700 (PDT) X-Trace: 113005126/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.134.26 X-SBRS: None X-RemoteIP: 62.188.134.26 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAAoiJEg+vIYa/2dsb2JhbACLUZ96BA X-IP-Direction: IN Received: from 1cust26.tnt5.lnd4.gbr.da.uu.net (HELO allison) ([62.188.134.26]) by smtp.pipex.tiscali.co.uk with SMTP; 09 May 2008 18:07:04 +0100 Message-ID: <011101c8b1ee$208fffe0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com><00a801c83149$7149e160$6a117c0a@china.huawei.com> <005301c831e3$f559cf20$0601a8c0@pc6> <234801c83214$1a85f320$6502a8c0@china.huawei.com> Date: Fri, 9 May 2008 16:51:23 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] transport-tls-11 review 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org This looks like a suitable message to respond to:-) Yes, Joe has produced a -12 and yes, I understand the state in the state transition diagram of the RFC production process of where we are at. Which means we are only changing things that the IESG have raised as problems. So what are these IESG problems that have causes section 4.2 to acquire these Editors Notes? I cannot find a record of what it is that Pasi or Sam did or did not say to cause this. Any one help me? Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Miao Fuyou'" ; "'Rainer Gerhards'" ; Sent: Thursday, November 29, 2007 1:12 AM Subject: RE: [Syslog] transport-tls-11 review > Hi, > > Let me remind the WG that this document is in IESG review. > > We are no longer doing fine-tuning/wordsmithing. We are fixing the > problems raised by the IESG. So unless the wording is **broken** we > shouldn't be trying to fix it now. > > What IESG-raised issues are we responding to? > > dbh > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, November 28, 2007 12:13 PM > > To: Miao Fuyou; 'Rainer Gerhards'; syslog@ietf.org > > Subject: Re: [Syslog] transport-tls-11 review > > > > > > > > > > > > === > > > > The server MUST be implemented to support certificate and > > certificate > > > > generation, > > > > === > > > > > > > > I do not think it is a MUST that a server must contain code > > > > to generate certificates. This should be left to the > > > > implementation. There is already the requirement to use > > > > certificates, so IMHO it is not the business of an IETF > > > > document to specify how they are provided. For example, I > > > > would provide a helper app with my syslog implementations, > > > > but not include it in the core app - it doesn't belong there. > > > > > > > > > > Need more opinion from the working group. > > > > > > > I agree with Rainer > > > > And I see some idiosynchratic wordings that MIGHT be changed. > > > > 2. Security Requirements for Syslog > > > > syslog messages may pass several hops > > ** not really pass, suggest transit > > > > It is recommended to use dNSName in the certificate rather than > any > > other type subjectAltName for certificate verification, such as > > ipAddress. > > **suggest iPAddress (ie PKI not SNMP) > > > > 4.2.2. Client Identity > > > > If a server authenticates a client and the client presents a > > certificate to the server, the server MUST validate the > > certificate. > > Validation includes constructing a certificate path to one of the > > configured trust anchors and validating that path. > > However, identity > > check is not required even if subjectAltName is presented in the > > certificate. > > **I do not understand how failing to check the identity > > provides protection > > against Masquerade, as we claim in s.2 > > > > SubjectAltName is not necessarily unique for different > > certificates. > > ** suggest The subjectAltName > > > > 5.1. Authentication and Certificates > > > > Mutual authentication means the TLS client and server are > > provisioned with necessary trust roots > > > > **suggest trust anchors as in the next paragraph > > > > . If a server does not > > have a certificate and key/pair configured > > **unclear what the solidus is doing - '/' usually means either/or > > > > The server MUST be implemented to support certificate and > > certificate > > generation, and certificate validation MUST be implemented for > all > > clients. The Syslog client SHOULD be implementated to support > > **implemented > > certificate and certificate generation, and certificate > validation > > SHOULD be inplemented for Syslog server. > > > > **These both read oddly to me - what is the support for certificate > > (certificates?) as distinct from support for certificate > > generation and > > certificate validation? If I support certificate (without > > qualification), then > > I expect that to convey support for every aspect thereof so > > the validation and > > generation is redundant but, as I agreed with Rainer above, I > > think that > > generation should not be a MUST. > > > > Since a receiver may act upon received data, for syslog over > > TLS, it is recommended that the server authenticate the client to > > ensure that information received is authentic. > > > > **this seems to weaken the claim earlier that TLS defends > > against the listed > > threats - by now I am feeling confused about what protection > > is being offered > > by what. To meet the claims of s.2, I think we need both > > server and client to > > check certificates for suitable identities and to follow a > > chain to a trust > > anchor - I have no problem with describing other scenarios > > but think that each > > such scenario should then be qualified with a comment to the > > effect that this > > MAY not defend against threats ... as identified in s.2 > > > > 5.2. Cipher Suites > > > > Operators MAY choose to disable older/weaker cipher > > suites for TLS > > despite the tradeoff of interoperability, for example, if > > the cipher > > suite specified in the specification is found weak in the future. > > > > **suggest > > > > Operators MAY choose to disable cipher suites for TLS > > that are regarded as > > too weak for the environment in which this specification is > > being used, > > especially older cipher suites. This MAY lead to a reduction of > > interoperability. It is likely that, in time, the cipher > > suite specified here > > will become subject to attack and the use of it will too be > > deprecated. > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 9 10:58:16 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 D42A93A6803; Fri, 9 May 2008 10:58:16 -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 08CAA3A68AE for ; Fri, 9 May 2008 10:58:15 -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=[AWL=0.000, 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 9e46WYDneEVx for ; Fri, 9 May 2008 10:58:14 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id E98913A6866 for ; Fri, 9 May 2008 10:57:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 3804A7AE219; Fri, 9 May 2008 18:53:29 +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 yn6iSFNoGqRA; Fri, 9 May 2008 18:53:29 +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 EC5D07AE209; Fri, 9 May 2008 18:53:28 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 May 2008 18:56:24 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FBD@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls-12, section 4.2.3 (fingerprints) Thread-Index: AcixDGHYAKW3NlsISKSnpPNfuaTo8wADXRkAAACHySAACqjW8AArDGegAACqBnA= References: <577465F99B41C842AAFBE9ED71E70ABA308FA8@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" Cc: syslog@ietf.org Subject: Re: [Syslog] -transport-tls-12, section 4.2.3 (fingerprints) 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 Joe and Chris, the mailing list processor seems to be a bit slow these days. I sent a long note this morning telling that I see value in automatically generated self-signed certs. That mail also outlines when and why. Please let me know if you did not receive it. Thanks, Rainer > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Friday, May 09, 2008 6:40 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: -transport-tls-12, section 4.2.3 (fingerprints) > > > > > > [Joe] I don't know that we need to restrict this to a particular > > > implementation. I think it would be good to provide a management > > > interface to do the generation. It seems that it would be an > > > acceptable implementation to auto-generate it as well. > > > > [Rainer] As long as the syslogd is not required to > > auto-generate certs, I am happy enough ;) > > > > However, I wonder why it would be useful to auto-generate certs. > > Probably I am overlooking somehting obvious. But: isn't cert > > auto-generation equal to no authentication? After all, if a > > *self-signed* cert is generated by the remote peer AND we > > accept it, doesn't that essentially mean we accept any peer > > because the peer can put whatever it likes into the cert? I > > do not see why this is any better than having no cert at all... > > > [Joe] When I was thinking of auto-generation I was expecting the > certificate to be persistent and the fingerprint would be available to > be communicated out of band to the verifier. If you generate a new > cert > each time the process starts and the other side does not know the > fingerprint then what you say is true. > > > Rainer > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 9 11:03:51 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 9849428C158; Fri, 9 May 2008 11:03:51 -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 903123A67FA for ; Fri, 9 May 2008 10:41:08 -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=[AWL=0.000, 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 gg5f2p9YAWR8 for ; Fri, 9 May 2008 10:41:07 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id BDC493A67CE for ; Fri, 9 May 2008 10:41:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 015A27AE1F4; Fri, 9 May 2008 18:33: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 k3OnMPc16X7s; Fri, 9 May 2008 18:33:29 +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 BCDBF7AE1C5; Fri, 9 May 2008 18:33:29 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 May 2008 18:36:22 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FBC@grfint2.intern.adiscon.com> In-Reply-To: <124CF5A7D55D6F43A4FD9437F28254D8C28025@ALPMLVEM05.e2k.ad.ge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABLMh4AAAMFzcA== References: <20080507150001.D3CB428C65B@core3.amsl.com> <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> <124CF5A7D55D6F43A4FD9437F28254D8C28025@ALPMLVEM05.e2k.ad.ge.com> From: "Rainer Gerhards" To: "Moehrke, John (GE Healthcare)" , , "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 John, I need to find it inside the mailing list archive. If I remember, it came up during rechartering (2? 3? Years ago). It was along the lines that a secure transport AND secure default for that transport are required. This is the primary reason that -syslog-protocol and -transport-udp can not advance to RFC before -transport-tls is done. Rainer > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] > Sent: Friday, May 09, 2008 6:18 PM > To: Rainer Gerhards; robert.horn@agfa.com; Joseph Salowey (jsalowey); > syslog@ietf.org > Subject: RE: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt > > > Could someone please point me at the mentioned IESG requirement to > include policy decisions? This is a very unusual position. And as your > own assessment shows is something that simply will not scale. > > For example, there are healthcare systems installed on military ships > where all network wiring is inside compressed nitrogen casings with > sensors. This is clearly a sensitive environment, but they have already > managed many of the risks. > > John > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf > > Of Rainer Gerhards > > Sent: Friday, May 09, 2008 3:36 AM > > To: robert.horn@agfa.com; Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: Re: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > > > Hi all, > > > > I agree to Robert, policy decisions need to be separated. I CC Pasi > > because my comment is directly related to IESG requirements, which > IMHO > > cannot be delivered by *any* syslog TLS document without compromise > > [comments directly related to IESG are somewhat later, I need to > level > > ground first]. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 9 11:08:25 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 543BF28C170; Fri, 9 May 2008 11:08:25 -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 5DE2528C125 for ; Fri, 9 May 2008 11:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 281G8QzmIFOK for ; Fri, 9 May 2008 11:08:18 -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 BD3A03A683D for ; Fri, 9 May 2008 11:08:14 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 May 2008 11:07:17 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m49I7He4016200; Fri, 9 May 2008 11:07:17 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m49I7Hut000031; Fri, 9 May 2008 18:07:17 GMT Date: Fri, 9 May 2008 11:07:17 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FBD@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA308FA8@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FBD@grfint2.intern.adiscon.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2169; t=1210356437; x=1211220437; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Missing=20email?=20was=3A=20Re=3A=20[Syslog]=20 -transport-tls-12,=20section=204.2.3=0A=20(fingerprints) |Sender:=20; bh=oOkp5x0db2HExj4il9AbVsaOPG8VuLTkuoB0xp9R2kM=; b=tXh79h7bTrH+h3MhM1wUhqXutW+pv/Y6NCHQK6JOSO+na3v3lnBcMRK3Uq ATJZbkFXEZ1E3PEi48JHjVQqu06/1GgORLMY2nWLB36MC/1jRVdmSxHFmUji +3MLv8NzL6NAOrlVsYMG+q2iMzSQY/WcDRh27tBO9NbjGeB9noR0I=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog@ietf.org Subject: [Syslog] Missing email? was: Re: -transport-tls-12, section 4.2.3 (fingerprints) 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 Rainer, I'm also seeing the list behave slowly. I don't think that I saw any message like that. Can you check the archive and let us know if it's in there? Thanks, Chris On Fri, 9 May 2008, Rainer Gerhards wrote: > Joe and Chris, > > the mailing list processor seems to be a bit slow these days. I sent a > long note this morning telling that I see value in automatically > generated self-signed certs. That mail also outlines when and why. > > Please let me know if you did not receive it. > > Thanks, > Rainer > >> -----Original Message----- >> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] >> Sent: Friday, May 09, 2008 6:40 PM >> To: Rainer Gerhards >> Cc: syslog@ietf.org >> Subject: RE: -transport-tls-12, section 4.2.3 (fingerprints) >> >> >> >>>> [Joe] I don't know that we need to restrict this to a particular >>>> implementation. I think it would be good to provide a management >>>> interface to do the generation. It seems that it would be an >>>> acceptable implementation to auto-generate it as well. >>> >>> [Rainer] As long as the syslogd is not required to >>> auto-generate certs, I am happy enough ;) >>> >>> However, I wonder why it would be useful to auto-generate certs. >>> Probably I am overlooking somehting obvious. But: isn't cert >>> auto-generation equal to no authentication? After all, if a >>> *self-signed* cert is generated by the remote peer AND we >>> accept it, doesn't that essentially mean we accept any peer >>> because the peer can put whatever it likes into the cert? I >>> do not see why this is any better than having no cert at all... >>> >> [Joe] When I was thinking of auto-generation I was expecting the >> certificate to be persistent and the fingerprint would be available to >> be communicated out of band to the verifier. If you generate a new >> cert >> each time the process starts and the other side does not know the >> fingerprint then what you say is true. >> >>> Rainer >>> > _______________________________________________ > 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 Fri May 9 11:12:44 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 2691E28C0E7; Fri, 9 May 2008 11:12:44 -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 A3B1628C0E7 for ; Fri, 9 May 2008 11:12:42 -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 OVSjUyElB4VN for ; Fri, 9 May 2008 11:12:41 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id 6F8B03A687E for ; Fri, 9 May 2008 11:11:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,461,1204498800"; d="scan'208";a="45208301" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 09 May 2008 20:08:25 +0200 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FBD@grfint2.intern.adiscon.com> To: rgerhards@hq.adiscon.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Fri, 9 May 2008 14:08:21 -0400 Cc: syslog@ietf.org Subject: [Syslog] -transport-tls-12, section 4.2 suggestion 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 I like Rainer's proposal. I had forgotten about the IESG desire for an out of box acceptable security. I find this mechanism a bit dubious, but specifying a reasonably secure default configuration as a separate policy section could work. How about a structure like this: In the protocol section, since this is TLS and TLS is certificate oriented, we have the following requirements: - The TLS negotiation SHALL be configurable to verify certificates based on the following rules: - The local side shall negotiate based on a local certificate store. The local certificate store contains a list of certificate/server pairs. - The local side shall verify the remote side matches certificates found in one of three stores: - Specific certs where Certificate X is accepted for remote X. (This is oriented toward self-signed certs) - (optional) Signing certs, where Remote Y is accepted if its cert was signed by Certificate Y. No chain of trust. - (optional) Signing certs, where Remote Z is accepted if its cert was signed by Certificate Z. Chain of trust is accepted. Implementations may add other additional rules for other situations where connections are accepted, but these shall not be the default configuration. I made the use of signed certs optional because it pulls in all the other issues around revocation, etc. I'm not too worried about having a server manage CRLs, updates, etc. but it could be a problem demanding that all clients also manage that. I do worry about all the issues that come up in terms of preserving syslog function during serious network disruptions. I do not want to see my problem reporting facility (syslog) fail just because I lost the PKI servers. I'm think of cases where those servers had been physically destroyed, but 80% of the network still exists, e.g., Katrina. In the policy section, - By default, if verification fails then the connection will be refused. - Other rules may be added, but shall not be the out of box default. - There shall be a maintenance method to create a self-signed cert. There shall be a maintenance method to import a self cert into any of the cert stores. - There may be a maintenance method for adding and removing certs in the other two kinds of cert stores. - There may be other authentication and authorization methods. This then enables a reasonably useful default behavior. With proper instructions a skilled home user could follow these rules. It also enables direct implementation of many enterprise rules, although not all of them. It can encourage developers to split their implementation so that new policy structures do not cause problems with the underlying protocol implementation. The default home user scenario expectation is the following: - Installing a server: - Home user generates a self-signed certificate for the server, files it into the server local certificate store, and saves it for making copies for clients. The corresponding private key lives somewhere in local configuration files and the user can be instructed that they should never ever give that information to other people. - Installing a client: - Home user generates a self-signed certificate for the client, files it into the client local certificate store, and saves it for making copies for servers. Again, private key remains secret in configuration files somewhere. - Home user copies the client self-signed certificate into the server's specific certs for remotes. - Home user copies the server self-signed certificate into the client's specific certs for remotes. This default does not scale to the large enterprise. Adding the two kinds of signed cert stores extends the default configuration to support many, but not all, enterprise policies. There will be other enterprise oriented methods. This default does meet the needs of a small enterprise or skilled home user. By making the default the use of self-signed certificates you avoid all the problems resulting from the absence of syslog oriented PKI infrastructures. Even when there are suitable PKI infrastructures for identity management, these are not generally suitable for applications authentication management. Introducing a PKI dependency will effectively delay the use of syslog-tls for many more years. Using self-signed certificates leaves the home user with the need to copy around these certificates. Moving files from here to there is something that can be handled by media, web aps, etc. This is simplified by the lack of security requirements. All you need is fingerprint display if you have reason to question the copying. It will overwhelm the unskilled home user, but they probably won't be configuring syslog. Someone who is setting up syslog can probably handle instructions for copying certificates from place to place. Self-signed certs may take a few minutes to generate, but they are something that is not overly burdensome for syslog maintenance programs. This also scales to the needs of many service providers. If a service provider is installing thousands of dumb remote systems to unsupported locations (i.e., unskilled home user systems), they can preconfigure the dumb remote with self-signed certificates. Since the rules only require matching, the service provider does not need to try to match hostnames, IP addresses, etc. I would base the cert on the device serial number. This would not be perfect security. I could break into the dumb remote and steal the private key. But it is a huge improvement over the current situation. It does force me to break in, and none of the PKI structures protect against that. Revocation is a bigger administrative problem but you can manage revocation of self-signed certificates for simple situations like this even at the service provider scale. Kind Regards, Robert Horn | Agfa HealthCare Research Scientist | HE/Technology Office T +1 978 897 4860 Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 07660-2199, United States http://www.agfa.com/healthcare/ Click on link to read important disclaimer: http://www.agfa.com/healthcare/maildisclaimer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 9 12:47:00 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 516063A6838; Fri, 9 May 2008 12:47:00 -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 53CFD3A68CC for ; Fri, 9 May 2008 12:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 B0CFOvEfo0+o for ; Fri, 9 May 2008 12:46:57 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id E54F23A6838 for ; Fri, 9 May 2008 12:46:52 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id PUw21Z0050FhH24A50Dc00; Fri, 09 May 2008 19:37:58 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id PXds1Z00L4HwxpC8U00000; Fri, 09 May 2008 19:38:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=aAD4C1mW_iYA:10 a=BHdMu9g2WwQA:10 a=48vgC7mUAAAA:8 a=FAd-VYlxXpiGCaEpZRQA:9 a=H8T257vIQxW6rrqHXLoA:7 a=C6fuXRvHv-BdArMgKjM01wVi1nUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=84tl6Pyz8z4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Rainer Gerhards'" , "'Moehrke, John \(GE Healthcare\)'" , , "'Joseph Salowey \(jsalowey\)'" , References: <20080507150001.D3CB428C65B@core3.amsl.com><577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com><124CF5A7D55D6F43A4FD9437F28254D8C28025@ALPMLVEM05.e2k.ad.ge.com> <577465F99B41C842AAFBE9ED71E70ABA308FBC@grfint2.intern.adiscon.com> Date: Fri, 9 May 2008 15:37:52 -0400 Message-ID: <049301c8b20c$33dd1e20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FBC@grfint2.intern.adiscon.com> Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABLMh4AAAMFzcAAExWgw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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, Acting as co-chair, I request that everybody please read BCP61, found in RFC 3365 - "Strong Security Requirements for Internet Engineering Task Force Standard Protocols". It's short. ;-) If the IESG required strong security features for syslog, then the IESG was probably enforcing the IETF consensus documented in this RFC. This BCP has not been updated or obsoleted to my knowledge. BUT - the IESG **may** be working off a newer consensus, so we may need to see what was said, or get input from our responsible AD. I don't think it says the security features must be enabled by default, or that policy decisions should be included in the protocool specification. It reports IETF rough consensus that "all IETF protocols should operate securely". However, RFC 3365 is also clear that "MUST is for implementers", not users - "it is completely reasonable for security features to be an option that the end user of the protocol may choose to disable." RFC 3365 does not use the word default, nor the word enabled, and in my reading of the document, I see nothing that states that strong security MUST be enabled by default. But please continue checking what was said by the IESG when we rechartered (or whenever it was). David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Friday, May 09, 2008 12:36 PM > To: Moehrke, John (GE Healthcare); robert.horn@agfa.com; > Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > John, > > I need to find it inside the mailing list archive. If I remember, it > came up during rechartering (2? 3? Years ago). It was along the lines > that a secure transport AND secure default for that transport are > required. This is the primary reason that -syslog-protocol and > -transport-udp can not advance to RFC before -transport-tls is done. > > Rainer > > > -----Original Message----- > > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] > > Sent: Friday, May 09, 2008 6:18 PM > > To: Rainer Gerhards; robert.horn@agfa.com; Joseph Salowey > (jsalowey); > > syslog@ietf.org > > Subject: RE: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > > > > > Could someone please point me at the mentioned IESG requirement to > > include policy decisions? This is a very unusual position. > And as your > > own assessment shows is something that simply will not scale. > > > > For example, there are healthcare systems installed on > military ships > > where all network wiring is inside compressed nitrogen casings with > > sensors. This is clearly a sensitive environment, but they have > already > > managed many of the risks. > > > > John > > > > > -----Original Message----- > > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > Behalf > > > Of Rainer Gerhards > > > Sent: Friday, May 09, 2008 3:36 AM > > > To: robert.horn@agfa.com; Joseph Salowey (jsalowey); > syslog@ietf.org > > > Subject: Re: [Syslog] I-D > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > > > Hi all, > > > > > > I agree to Robert, policy decisions need to be separated. > I CC Pasi > > > because my comment is directly related to IESG requirements, which > > IMHO > > > cannot be delivered by *any* syslog TLS document without > compromise > > > [comments directly related to IESG are somewhat later, I need to > > level > > > ground first]. > _______________________________________________ > 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 Fri May 9 13:50:34 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 758D23A6881; Fri, 9 May 2008 13:50:34 -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 C50023A68D2 for ; Fri, 9 May 2008 13:50:32 -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=[AWL=0.000, 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 iN2toIytXeee for ; Fri, 9 May 2008 13:50:31 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 7D02B3A67EC for ; Fri, 9 May 2008 13:50:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 9E6947AE2BC; Fri, 9 May 2008 22:45:08 +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 evNyMAI0RbDO; Fri, 9 May 2008 22:45:08 +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 52C347AE284; Fri, 9 May 2008 22:45:08 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 May 2008 22:48:50 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FC0@grfint2.intern.adiscon.com> In-Reply-To: <049301c8b20c$33dd1e20$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABLMh4AAAMFzcAAExWgwAAP3SgA= References: <20080507150001.D3CB428C65B@core3.amsl.com><577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com><124CF5A7D55D6F43A4FD9437F28254D8C28025@ALPMLVEM05.e2k.ad.ge.com> <577465F99B41C842AAFBE9ED71E70ABA308FBC@grfint2.intern.adiscon.com> <049301c8b20c$33dd1e20$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , "Moehrke, John (GE Healthcare)" , , "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 I went through the mailing list archive, but I did not find one single message wrapping it up. Maybe this here comes close: http://www.ietf.org/mail-archive/web/syslog/current/msg00772.html Getting the whole thing together requires substantial work. I personally do not think this is useful (given what you have posted). If in doubt, we should probably better ask for advise from our current AD. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, May 09, 2008 9:38 PM > To: Rainer Gerhards; 'Moehrke, John (GE Healthcare)'; > robert.horn@agfa.com; 'Joseph Salowey (jsalowey)'; syslog@ietf.org > Subject: RE: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > Hi, > > Acting as co-chair, I request that everybody please read BCP61, found > in RFC 3365 - "Strong Security Requirements for Internet Engineering > Task Force Standard Protocols". It's short. ;-) > > If the IESG required strong security features for syslog, then the > IESG was probably enforcing the IETF consensus documented in this RFC. > This BCP has not been updated or obsoleted to my knowledge. BUT - the > IESG **may** be working off a newer consensus, so we may need to see > what was said, or get input from our responsible AD. > > I don't think it says the security features must be enabled by > default, or that policy decisions should be included in the protocool > specification. It reports IETF rough consensus that "all IETF > protocols should operate securely". However, RFC 3365 is also clear > that "MUST is for implementers", not users - "it is completely > reasonable for security features to be an option that the end user of > the protocol may choose to disable." > > RFC 3365 does not use the word default, nor the word enabled, and in > my reading of the document, I see nothing that states that strong > security MUST be enabled by default. > > But please continue checking what was said by the IESG when we > rechartered (or whenever it was). > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > > Sent: Friday, May 09, 2008 12:36 PM > > To: Moehrke, John (GE Healthcare); robert.horn@agfa.com; > > Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: Re: [Syslog] I-D > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > John, > > > > I need to find it inside the mailing list archive. If I remember, it > > came up during rechartering (2? 3? Years ago). It was along the > lines > > that a secure transport AND secure default for that transport are > > required. This is the primary reason that -syslog-protocol and > > -transport-udp can not advance to RFC before -transport-tls is done. > > > > Rainer > > > > > -----Original Message----- > > > From: Moehrke, John (GE Healthcare) > [mailto:John.Moehrke@med.ge.com] > > > Sent: Friday, May 09, 2008 6:18 PM > > > To: Rainer Gerhards; robert.horn@agfa.com; Joseph Salowey > > (jsalowey); > > > syslog@ietf.org > > > Subject: RE: [Syslog] I-D > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > > > > > > Could someone please point me at the mentioned IESG requirement to > > > include policy decisions? This is a very unusual position. > > And as your > > > own assessment shows is something that simply will not scale. > > > > > > For example, there are healthcare systems installed on > > military ships > > > where all network wiring is inside compressed nitrogen casings > with > > > sensors. This is clearly a sensitive environment, but they have > > already > > > managed many of the risks. > > > > > > John > > > > > > > -----Original Message----- > > > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] > On > > > Behalf > > > > Of Rainer Gerhards > > > > Sent: Friday, May 09, 2008 3:36 AM > > > > To: robert.horn@agfa.com; Joseph Salowey (jsalowey); > > syslog@ietf.org > > > > Subject: Re: [Syslog] I-D > > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > > > > > Hi all, > > > > > > > > I agree to Robert, policy decisions need to be separated. > > I CC Pasi > > > > because my comment is directly related to IESG requirements, > which > > > IMHO > > > > cannot be delivered by *any* syslog TLS document without > > compromise > > > > [comments directly related to IESG are somewhat later, I need to > > > level > > > > ground first]. > > _______________________________________________ > > 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 Fri May 9 14:03:14 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 E6D3F3A6890; Fri, 9 May 2008 14:03:13 -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 839BE3A6890 for ; Fri, 9 May 2008 14:03:04 -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=[AWL=0.000, 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 typqipEbVbmH for ; Fri, 9 May 2008 14:02:59 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 2A0B63A67EC for ; Fri, 9 May 2008 14:02:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 0B6BA7AD770; Fri, 9 May 2008 22:30:48 +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 51ip1GVSaajt; Fri, 9 May 2008 22:30:47 +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 B845C7AD5BD; Fri, 9 May 2008 22:30:47 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 May 2008 22:34:34 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FBF@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Missing email? was: Re: [Syslog] -transport-tls-12, section 4.2.3 (fingerprints) Thread-Index: Acix/4Zg5a4SLD5MRB2lJM0eg9CcUQAFE07g References: <577465F99B41C842AAFBE9ED71E70ABA308FA8@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FBD@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Chris Lonvick" Cc: syslog@ietf.org Subject: Re: [Syslog] Missing email? was: Re: -transport-tls-12, section 4.2.3 (fingerprints) 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 Chris, I just checked that archive. The message is scrambled there: http://www.ietf.org/mail-archive/web/syslog/current/msg01861.html http://www.ietf.org/mail-archive/web/syslog/current/msg01862.html The complete one is containend in my blogpost at http://rgerhards.blogspot.com/2008/05/more-on-syslog-tls-policies-and-ie tf.html Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, May 09, 2008 8:07 PM > To: Rainer Gerhards > Cc: Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Missing email? was: Re: [Syslog] -transport-tls-12, > section 4.2.3 (fingerprints) > > Hi Rainer, > > I'm also seeing the list behave slowly. I don't think that I saw any > message like that. Can you check the archive and let us know > if it's in > there? > > Thanks, > Chris > > On Fri, 9 May 2008, Rainer Gerhards wrote: > > > Joe and Chris, > > > > the mailing list processor seems to be a bit slow these > days. I sent a > > long note this morning telling that I see value in automatically > > generated self-signed certs. That mail also outlines when and why. > > > > Please let me know if you did not receive it. > > > > Thanks, > > Rainer > > > >> -----Original Message----- > >> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > >> Sent: Friday, May 09, 2008 6:40 PM > >> To: Rainer Gerhards > >> Cc: syslog@ietf.org > >> Subject: RE: -transport-tls-12, section 4.2.3 (fingerprints) > >> > >> > >> > >>>> [Joe] I don't know that we need to restrict this to a particular > >>>> implementation. I think it would be good to provide a management > >>>> interface to do the generation. It seems that it would be an > >>>> acceptable implementation to auto-generate it as well. > >>> > >>> [Rainer] As long as the syslogd is not required to > >>> auto-generate certs, I am happy enough ;) > >>> > >>> However, I wonder why it would be useful to auto-generate certs. > >>> Probably I am overlooking somehting obvious. But: isn't cert > >>> auto-generation equal to no authentication? After all, if a > >>> *self-signed* cert is generated by the remote peer AND we > >>> accept it, doesn't that essentially mean we accept any peer > >>> because the peer can put whatever it likes into the cert? I > >>> do not see why this is any better than having no cert at all... > >>> > >> [Joe] When I was thinking of auto-generation I was expecting the > >> certificate to be persistent and the fingerprint would be > available to > >> be communicated out of band to the verifier. If you generate a new > >> cert > >> each time the process starts and the other side does not know the > >> fingerprint then what you say is true. > >> > >>> Rainer > >>> > > _______________________________________________ > > 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 Sat May 10 08:54:31 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 A55DD3A67F1; Sat, 10 May 2008 08:54:31 -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 BC9383A67F1 for ; Sat, 10 May 2008 08:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 gXXT4Fo4DxNc for ; Sat, 10 May 2008 08:54:29 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id EA8063A65A5 for ; Sat, 10 May 2008 08:54:25 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 47F9F7D8A1 for ; Sat, 10 May 2008 17:33:34 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id cGYYMjRbR+rD for ; Sat, 10 May 2008 17:33:22 +0200 (CEST) Received: from [192.168.178.21] (BAEbf33.bae.pppool.de [77.132.191.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 9B4877D884 for ; Sat, 10 May 2008 17:33:21 +0200 (CEST) Message-ID: <4825DC63.8020901@mschuette.name> Date: Sat, 10 May 2008 17:33:23 +0000 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.12 (X11/20080427) MIME-Version: 1.0 To: syslog@ietf.org References: <20080507150001.D3CB428C65B@core3.amsl.com> In-Reply-To: <20080507150001.D3CB428C65B@core3.amsl.com> Subject: [Syslog] lower requirements? (Re: I-D Action:draft-ietf-syslog-transport-tls-12.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 > The transport sender (TLS client) has three different options for > authenticating and authorizing the transport receiver (TLS server). I do not know if this has been discussed previously, but what is your opinion on lower requirements in order to get transport-tls supported by embedded devices, i.e. switches and printers? Scenario: I could imagine a printer (as the client) having a self-signed certificate and no ability to authenticate the server's certificate. As long as the server has a copy of the client's certificate and can verify it, a secure transport is possible. As an admin I would rather configure this one-way authentication and get a TLS-enabled device than having to fall back to UDP. Should this be an allowed scenario to be covered by tls-transport? Scenario2: Say the same printer with its self-signed cert is configurable with a CA-cert that enables it to authenticate the server (but maybe without checking the certificate's CN/dNSName/IP). That would allow a reasonably secure setup. -- Should this be an allowed scenario to be covered by tls-transport? In my opinion it should be, thus I would like to keep the requirements on authentication rules as simple as possible. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Sat May 10 11:25:09 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 E0DA73A6970; Sat, 10 May 2008 11:25:09 -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 2C5AB3A6970 for ; Sat, 10 May 2008 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 IQKvTL0KKgtv for ; Sat, 10 May 2008 11:25:07 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 6826F3A68D4 for ; Sat, 10 May 2008 11:25:07 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 55A497D89F for ; Sat, 10 May 2008 17:33:33 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id X+7yR7RVpYrT for ; Sat, 10 May 2008 17:33:21 +0200 (CEST) Received: from [192.168.178.21] (BAEbf33.bae.pppool.de [77.132.191.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id B110079341 for ; Sat, 10 May 2008 17:33:20 +0200 (CEST) Message-ID: <4825DC61.9000000@mschuette.name> Date: Sat, 10 May 2008 17:33:21 +0000 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.12 (X11/20080427) MIME-Version: 1.0 To: syslog@ietf.org References: <20080507150001.D3CB428C65B@core3.amsl.com> In-Reply-To: <20080507150001.D3CB428C65B@core3.amsl.com> Subject: [Syslog] why fingerprints? (Re: I-D Action:draft-ietf-syslog-transport-tls-12.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 > o Certificate fingerprints: For each transport receiver, the client > is configured with a fingerprint of the server's certificate > (which can be self-signed). This option MUST be supported. Am I the only one who finds this whole fingerprint option completely unnecessary? Is this practice actually used somewhere? I have not heard about this before and get the impression it is only a bad substitute for copying the peer's certificate. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Sun May 11 20:39:05 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 381853A677D; Sun, 11 May 2008 20:39:05 -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 900E43A63CB for ; Sun, 11 May 2008 20:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 Hc7P5+l8ETZD for ; Sun, 11 May 2008 20:39:01 -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 C36793A677D for ; Sun, 11 May 2008 20:39:00 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 May 2008 20:38:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4C3cvZ9023651; Sun, 11 May 2008 20:38:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4C3cvVC006495; Mon, 12 May 2008 03:38:57 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 May 2008 20:38:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 May 2008 20:39:35 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABfCe0A= References: <20080507150001.D3CB428C65B@core3.amsl.com> <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , , X-OriginalArrivalTime: 12 May 2008 03:38:47.0060 (UTC) FILETIME=[AF542540:01C8B3E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18765; t=1210563537; x=1211427537; c=relaxed/simple; s=sjdkim3002; 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-12.txt |Sender:=20; bh=0AhvRdVV79jbufL0nLBWXlLViKucWO5iCCmQxwy3QSs=; b=Ft8+8sHJggNOgFq6hPP1XT/Uc3+/NDo7Tj1rajMXUJOyDXqCrES1kLSs0I LfelQNP90GXEd1EjscOKJ7muE/NPlAnJlEgmh06tkdMidVbahdZtYmtCWOnv Y5du/PXFRB; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 Rainer, Comments inline below: > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, May 09, 2008 1:36 AM > To: robert.horn@agfa.com; Joseph Salowey (jsalowey); syslog@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: RE: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > Hi all, > > I agree to Robert, policy decisions need to be separated. I > CC Pasi because my comment is directly related to IESG > requirements, which IMHO cannot be delivered by *any* syslog > TLS document without compromise [comments directly related to > IESG are somewhat later, I need to level ground first]. > > Let me tell the story from my implementor's POV. This is > necessarily tied to rsyslog, but I still think there is a lot > of general truth in it. So I consider it useful as an example. > > I took some time yesterday to include the rules laid out in > 4.2 into rsyslog design. I quickly came to the conclusion > that 4.2. is talking about at least two things: > > a) low-level handshake validation > b) access control > [Joe] It is possible for the document to separate out authentication/cert validation from authorization. I would note that there tends to be a lot of linkages between the two so this will tend increase the amount of text needed. If the working group wants to do this I can work on it. > In a) we deal with the session setup. Here, I see certificate > exchange and basic certificate validation (for example > checking the validity dates). In my current POV, this phase > ends when the remote peer can positively be identified. > > Once we have positive identification, b) kicks in. In that > phase, we need to check (via ACLs) if the remote peer is > permitted to talk to us (or we are permitted to talk to it). > Please note that from an architectural POV, this can be > abstracted to a higher layer (and in rsyslog it probably > will). For that layer, it is quite irrelevant if the remote > peer's identity was obtained via a certificate (in the case > of transport-tls), a simple reverse lookup (UDP syslog), SASL > (RFC 3195) or whatever. What matters is that the ACL engine > got a trusted identify from the transport layer and verifies > that identity [level of trust varies, obviously]. Most policy > decisions happen on that level. > > There is some grayish between a) and b). For example, I can > envision that if there is a syslog.conf rule (forward everything to > server.example.net) > > *.* @@server.example.net > > The certificate name check for server.example.net (using dNSName > extension) could probably be part of a) - others may think it > is part of b). > > Also, even doing a) places some burden onto the system, like > the need to have trust anchors configured in order to do the > validation. This hints at at least another sub-layer. > > I think it would be useful to spell out these different > entities in the draft. > [Joe] What do you mean by entities. We can define two separate processes that need to happen, but I don't think we want to specify how an implementor must build this. > > Coming back to policy decisions, one must keep in mind that > the IESG explicitly asked for those inside the document. This > was done based on the -correct- assumption that today's > Internet is no longer a friendly place. So the IESG would > like to see a default policy implemented that provides at > least a minimum acceptable security standard. [Joe] I believe this is part of the goal. I think there is also the desire that implementations support some basic level of policy that allows interoperability. Implementations can support other policies, deployers can deploy other policies. > Unfortunately, > this is not easy to do in the world of syslog. For the home > users, we cannot rely on any ability to configure something. > For the enterprise folks, we need to have defaults that do > not get into their way of doing things [aka "can be easily > turned off"]. There is obviously much in between these poles, > so it largely depends on the use case. I have begun a wiki > page with use cases and hope people will contribute to it. It > could lead us to a much better understanding of the needs > (and the design decisions that need to be made to deliver > these). It is available at > > http://wiki.rsyslog.com/index.php/TLS_for_syslog_use_cases > > After close consideration, I think the draft currently fails > on addressing the two use cases define above properly. Partly > it fails because it is not possible under the current IESG > requirement to be safe by default. We cannot be fully safe by > default without configuration, so whatever we specify will > fail for the home user. > > A compromise may be to provide "good enough" security in the > default policy. I see two ways of doing that: one is to NOT > address the Masquerade and Modification threats in the > default policy, just the Disclosure threat. That leads us to > unauthenticated syslog being the default (contrary to what is > currently implemented) [Disclosure is addressed in this > scenario as long as the client configs are not compromised, > which I find sufficiently enough - someone who can compromise > the client config can find other ways to get hold of the > syslog message content]. > [Joe] If you don't address the relevant threats I'm not sure you can call security "good enough". > An alternative is to use the way HTTPS works: we only > authenticate the server. To authenticate, we need to have > trusted certificate inside the server. As we can see in > HTTPS, this doesn't really require PKI. It is sufficient to > have the server cert singed by one of few globally trusted > CAs and have this root certificates distributed with all > client installations as part of their setup procedure. This > is quite doable. In that scenario, a client can verify a > server's identity and the above sample (*.* > @server.example.net) could be verified with sufficient trust. > The client, however, is still not authenticated. However, the > threats we intended to address are almost all addressed, > except for the access control issue which is defined as part > of the Masquerade threat (which I think is even a different > beast and deserves its own threat definition now that I think > about it). In short we just have an access control issue in > that scenario. Nothing else. > [Joe] I think the threat model in the document describes masquerade of the client. Perhaps access control is not the only way to deal with this, perhaps just being able to associate the authenticated identity with the messages is enough, I don't know at this point. > The problem, however, is that the server still needs a > certificate and now even one that, for a home user, is > prohibitively expensive. The end result will be that people > turn off TLS, because they neither know how to obtain the > certificate nor are willing to trade in a weekend vacation > for a certificate ;) In the end result, even that mode will > be less useful than anonymous authentication. > > The fingerprint idea is probably a smart solution to the > problem. It depends on the ability to auto-generate a > certificate [I expressed that I don't like that idea > yesterday, but my thinking has evolved ;)] OR to ship every > device/syslogd with a unique certificate. In this case, only > minimal interaction is required. The idea obviously is like > with SSH: if the remote peer is unknown, the user is queried > if the connection request is permitted and if the certificate > should be accepted in the future. If so, it is added > permanently to the valid certificate store and used in the > future to authenticate requests from the same peer. This > limits the security weakness to the first session. HOWEVER, > the problem with syslog is that the user typically cannot be > prompted when the initial connection happens (everything is > background activity). So the request must actually be logged > and an interface be developed that provides for user > notification and the ability to authorize the request. > > This requires some kind of "unapproved certificate store" > plus a management interface for it. Well done, this may > indeed enable a home user to gain protection from all three > threats without even knowing what he really does. It "just" > requires some care in approving new fingerprints, but that's > a general problem with human nature that we may tackle by > good user interface desig but can't solve from a protocol > point of view. > > The bad thing is that it requires much more change to > existing syslogd technology. That, I fear, reduces acceptance > rate. Keep in mind that we already have a technically good > solution (RFC 3195) which miserably failed in practice due to > the fact it required too much change. > > If I look at *nix implementations, syslogd implementers are > probably tempted to "just" log a message telling "could not > accept remote connection due to invalid fingerprint > xx:xx:..." and leave it to the user to add it to syslog.conf. > However, I fear that for most home setups even that would be > too much. So in the end effect, in order to avoid user > hassle, most vendors would probably default back to UDP > syslog and enable TLS only on user request. > > From my practical perspective this sounds even reasonable > (given the needs and imperfections of the real world...). If > that assessment is true, we would probably be better off by > using anonymous TLS as the default policy, with the next > priority on fingerprint authentication as laid out above. A > single big switch could change between these two in actual > implementations. Those users that "just want to get it running" > would never find that switch but still be somewhat protected while the > (little) more technically aware can turn it to fingerprint > authentication and then will hopefully be able to do the > remaining few configuration steps. Another policy is the > certificate chain based policy, where using public CAs would > make sense to me. > > To wrap it up: > > 1. I propose to lower the default level of security > for the reasons given. > My humble view is that lower default security will result in higher > overall security. > [Joe] I'm not convinced of this. If you use TLS without authentication and authorization you don't really gain any security benefit from it, it is pretty much the equivalent of not running security. It might be reasonable to relax the requirement on being able to do access control on the server, but I think the threat section would need to discuss this. > 2. We should split authentication policies from the protocol itself > ... just as suggested by Robert and John. We should define a core > set of policies (I think I described the most relevant simple > cases above, Robert described some complex ones) and leave it > others to define additional policies based on their demand. > [Joe] We can split the policies, but I don't it will necessarily be as clean as one might hope. I believe the document does have to specify a minimum set of policies that can A) enable interoperable deployment B) provide mitigation against the listed threats Additional policies can be supported and defined (in this document or a separate one). > Policies should go either into their own section OR into > their own documents. I have a strong favor of putting them > into their own documents if that enables us to finally > finish/publish -transport-tls and the new syslog RFC series. > If that is not an option, I'd prefer to spend some more work > on -transport-tls, even if it delays things further, instead > of producing something that does not meet the needs found in practice. > > Rainer > > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > Behalf Of robert.horn@agfa.com > > Sent: Thursday, May 08, 2008 5:53 PM > > To: Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: Re: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > > > Section 4.2 is better, but it still needs work to separate > the policy > > decisions from the protocol definition. Policy decisions are driven > by > > risk analysis of the assets, threats, and environment (among other > > things). These are not uniform over all uses of syslog. That makes > it > > important to separate the policy from the protocol, in both the > > specifications and in the products. > > > > In the healthcare environment we use TLS to protect many of our > > connections. This is both an authentication protection and a > > confidentiality protection. The policy decisions regarding key > > management and verification will be very similar for a > healthcare use > > of syslog. > > Some > > healthcare sites would reach the same policy decision as is in 4.2, > but > > here are three other policy decisions that are also appropriate: > > > > Policy A: > > The clients are provided with their private keys and the public > > certificates for their authorized servers by means of > physical media, > > delivered by hand from the security office to the client machine > > support staff. (The media is often CD-R because it's > cheap, easy to > > create, easy to destroy, and easy to use.) During TLS > establishment > > the clients > use > > their assigned private key and the server confirms that the > connection > > is from a machine with one of the assigned private keys. > The client > > confirms that the server matches one of the provided public > > certificates by direct matching. This is similar to the > fingerprint > > method, but not the > same. > > My > > most recent experience was with an installation using this > method. We > > had two hours to install over 100 systems, including the network > > facilities. > > This can only be done by removing as many installation schedule > > dependencies as possible. The media method removed the certificate > > management dependencies. > > > > Policy B: > > These client systems require safety and functional certification > > before they are made operational. This is done by inspection by an > acceptance > > team. The acceptance team has a "CA on a laptop". After accepting > > safety and function, they establish a direct isolated physical > > connection between the client and the laptop. Then using > standard key > > management tools, the client generates a private key and has the > > corresponding public certificate generated and signed by > the laptop. > > The client is also provided with a public certificate for > the CA that > > must sign the certs for all incoming connections. > > > > During a connection setup the client confirms that the > server key has > > been signed by that CA. This is similar to a trusted > anchor, but not > > the same. > > There is no chain of trust permitted. The key must have been > directly > > signed by the CA. During connection setup the server confirms that > the > > client cert was signed by the "CA on a laptop". Again, no chain of > > trust is permitted. This policy is incorporating the extra > aspect of > > "has been inspected by the acceptance team" as part of the > > authentication meaning. > > They decided on a policy-risk basis that there was not a need to > > confirm re-inspection, but the "CA on a laptop" did have a > revocation > > server that was kept available to the servers, so that the > acceptance > > team could revoke at will. > > > > Policy C: > > This system was for a server that accepted connections > from several > > independent organizations. Each organization managed certificates > > differently, but ensured that the organization-CA had > signed all certs > > used for external communications by that organization. All of the > > client machines were provided with the certs for the shared servers > > (by a method similar to the fingerprint method). During TLS > > connection the clients confirmed that the server cert > matched one of > > the certs on their list. > > The > > server confirmed that the client cert had been signed by the CA > > responsible for that IP subnet. The server was configured > with a list > > of organization CA certs and their corresponding IP subnets. > > > > I do not expect any single policy choice to be appropriate for all > > syslog uses. I think it will be better to encourage a > separation of > > function in products. There is more likely to be a commonality of > > configuration needs for all users of TLS on a particular > system than > > to find a commonality of > > needs for all users of syslog. The policy decisions implicit in > > section > > 4.2 make good sense for many uses. They are not a complete > set. So a > > phrasing that explains the kinds of maintenance and > verification needs > > that are likely is more appropriate. The mandatory > verifications can > > be separated from the key management system and kept as part of the > > protocol definition. The policy decisions should be left > as important > examples. > > > > Kind Regards, > > > > Robert Horn | Agfa HealthCare > > Research Scientist | HE/Technology Office T +1 978 897 4860 > > > > Agfa HealthCare Corporation, 100 Challenger Road, > Ridgefield Park, NJ, > > 07660-2199, United States http://www.agfa.com/healthcare/ Click on > > link to read important disclaimer: > > http://www.agfa.com/healthcare/maildisclaimer > > _______________________________________________ > > 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 Sun May 11 20:51:06 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 77DEC3A6B2F; Sun, 11 May 2008 20:51:06 -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 ABA493A6B2F for ; Sun, 11 May 2008 20:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 DYgNC-zj41Fy for ; Sun, 11 May 2008 20:51:03 -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 B73903A63CB for ; Sun, 11 May 2008 20:51:03 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 May 2008 20:51:00 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4C3p0Hv031912; Sun, 11 May 2008 20:51:00 -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 m4C3p0ZV019242; Mon, 12 May 2008 03:51:00 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); Sun, 11 May 2008 20:51:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 May 2008 20:51:49 -0700 Message-ID: In-Reply-To: <4825DC61.9000000@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] why fingerprints? (Re: I-DAction:draft-ietf-syslog-transport-tls-12.txt) Thread-Index: AciyyzBK3Eg/SPJeQ++EJviVy9+E5gBFvSUA References: <20080507150001.D3CB428C65B@core3.amsl.com> <4825DC61.9000000@mschuette.name> From: "Joseph Salowey (jsalowey)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 12 May 2008 03:51:00.0673 (UTC) FILETIME=[64989B10:01C8B3E3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1808; t=1210564260; x=1211428260; c=relaxed/simple; s=sjdkim4002; 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]=20why=20fingerprints?=20(Re=3A =20I-DAction=3Adraft-ietf-syslog-transport-tls-12.txt) |Sender:=20; bh=1PsbGtPI/taYhu3Lkc3wt+B4JIDL2Y9R+RXtcxTufy8=; b=iZi6FdB8daoJIiLDoPmNmAxEVJ4L29kQ3RzydKimSZ9N0r00WzsRA4zljg 4mKeBxCtdwPc7aVVi6p+LqgGvAnRimwfOl93Oo6NV52CZjDsfwIlgaUz8kSl 2MliibjDO3; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] why fingerprints? (Re: I-DAction:draft-ietf-syslog-transport-tls-12.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org = > -----Original Message----- > From: syslog-bounces@ietf.org = > [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte > Sent: Saturday, May 10, 2008 10:33 AM > To: syslog@ietf.org > Subject: [Syslog] why fingerprints? (Re: = > I-DAction:draft-ietf-syslog-transport-tls-12.txt) > = > > o Certificate fingerprints: For each transport = > receiver, the client > > is configured with a fingerprint of the server's certificate > > (which can be self-signed). This option MUST be supported. > = > Am I the only one who finds this whole fingerprint option = > completely unnecessary? > Is this practice actually used somewhere? I have not heard = > about this before and get the impression it is only a bad = > substitute for copying the peer's certificate. > = [Joe] Fingerprints are essentially equivalent to obtaining the peers certif= icate. The main advantage a fingerprint has is that it is easier both comm= unicate and perform comparison when a human being is involved. The main re= ason for specifying the format is so something that is exported from one im= plementation can be input into another. As has been pointed out on the lis= t there can be other ways of obtaining the necessary peer certificate infor= mation. To some user communities fingerprints would be familiar and conven= ient. = Certificate fingerprints are used in several places today. For example, in= most web browsers you can view the fingerprint of a server certificate. I= n addition SSH uses a similar fingerprint concept for public keys without X= .509 certificates. = > -- > 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 From syslog-bounces@ietf.org Sun May 11 21:10:51 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 E3DA23A6B56; Sun, 11 May 2008 21:10:51 -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 8E5BD3A6B56 for ; Sun, 11 May 2008 21:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 lfAga69IfeDH for ; Sun, 11 May 2008 21:10:49 -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 4C6773A63CB for ; Sun, 11 May 2008 21:10:49 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 May 2008 21:10:46 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4C4AkqP021999; Sun, 11 May 2008 21:10:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m4C4Ak8F009132; Mon, 12 May 2008 04:10:46 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 May 2008 21:09:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 May 2008 21:10:27 -0700 Message-ID: In-Reply-To: <4825DC63.8020901@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] lower requirements? (Re: I-DAction:draft-ietf-syslog-transport-tls-12.txt) Thread-Index: Aciytimmzt8draTQRgGZgwtzc9JnCgBLY2pg References: <20080507150001.D3CB428C65B@core3.amsl.com> <4825DC63.8020901@mschuette.name> From: "Joseph Salowey (jsalowey)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 12 May 2008 04:09:37.0807 (UTC) FILETIME=[FE75B9F0:01C8B3E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2574; t=1210565446; x=1211429446; c=relaxed/simple; s=sjdkim2002; 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]=20lower=20requirements?=20(Re= 3A=20I-DAction=3Adraft-ietf-syslog-transport-tls-12.txt) |Sender:=20; bh=rCfMTdlBvzaf7LH7miDevQA7VXXMKre8p8CidvOxmco=; b=OugI51SrT8Vw5lHONw98tB34JTiuEfJKQ1kokLcCl0hsKsbUou7KvuhPe6 QwGLbXSlf92C3l1Kqsf9BbDpPMNfV3C/Y4bc76nz1P/bKlKQTIgk4IOcA8K1 LKf8cFFlkX; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] lower requirements? (Re: I-DAction:draft-ietf-syslog-transport-tls-12.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org = > -----Original Message----- > From: syslog-bounces@ietf.org = > [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte > Sent: Saturday, May 10, 2008 10:33 AM > To: syslog@ietf.org > Subject: [Syslog] lower requirements? (Re: = > I-DAction:draft-ietf-syslog-transport-tls-12.txt) > = > > The transport sender (TLS client) has three different options for > > authenticating and authorizing the transport receiver = > (TLS server). > = > I do not know if this has been discussed previously, but what = > is your opinion on lower requirements in order to get = > transport-tls supported by embedded devices, i.e. switches = > and printers? > = [Joe] TLS is deployed to mitigate certain threats such as those described i= n the document. If you fail to mitigate these threats then the value of de= ploying TLS is diminished. = > Scenario: > I could imagine a printer (as the client) having a = > self-signed certificate and no ability to authenticate the = > server's certificate. > As long as the server has a copy of the client's certificate = > and can verify it, a secure transport is possible. As an = > admin I would rather configure this one-way authentication = > and get a TLS-enabled device than having to fall back to UDP. > Should this be an allowed scenario to be covered by tls-transport? > = [Joe] The scenario above does not mitigate server masquerade. I'm not sure= this would be generally acceptable. However, I realize there are systems t= hat work much in this way today. = > Scenario2: > Say the same printer with its self-signed cert is = > configurable with a CA-cert that enables it to authenticate = > the server (but maybe without checking the certificate's = > CN/dNSName/IP). > That would allow a reasonably secure setup. -- Should this be = > an allowed scenario to be covered by tls-transport? > In my opinion it should be, thus I would like to keep the = > requirements on authentication rules as simple as possible. > = [Joe] This seems like a workable scenario to me in some environments. Thi= s would require the CA to issue certificates only to authorized parties. P= erhaps the argument can be made to for the configuration of a root as a MUS= T and the specific types of subject Name checks as RECOMMENDED with the app= ropriate security considerations discussion. = > -- = > 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 From syslog-bounces@ietf.org Sun May 11 21:14: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 823093A6824; Sun, 11 May 2008 21:14: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 2051428C175 for ; Sun, 11 May 2008 21:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_35=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 nTzT4l+GiouD for ; Sun, 11 May 2008 21:14:56 -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 3FE703A677D for ; Sun, 11 May 2008 21:14:56 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 May 2008 21:14:53 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4C4EriP018492; Sun, 11 May 2008 21:14:53 -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 m4C4Er82010015; Mon, 12 May 2008 04:14:53 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); Sun, 11 May 2008 21:14:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 May 2008 21:15:42 -0700 Message-ID: In-Reply-To: <020601c8b1cb$e23d3a40$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls-12, IP addresses Thread-Index: Acix7BW0isqNDXPTT2i+gchY/C5PUgB+iXAw References: <577465F99B41C842AAFBE9ED71E70ABA308F92@grfint2.intern.adiscon.com> <020601c8b1cb$e23d3a40$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "tom.petch" , "Rainer Gerhards" , X-OriginalArrivalTime: 12 May 2008 04:14:53.0246 (UTC) FILETIME=[BA79E5E0:01C8B3E6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2348; t=1210565693; x=1211429693; c=relaxed/simple; s=sjdkim4002; 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]=20-transport-tls-12,=20IP=20ad dresses |Sender:=20; bh=DQGpHaUUJoqTCYDacHIbqTOq6W8Rw5dhs3NFF2jdNdI=; b=W5dsI9LgXNSRg27kkSuNSRsnS9W2C9zxszSjYkUR5nRQFFijbRsC2RMcEx 5MAoshzy684imxcoR43/vmthrhf4aQlHuWbI6f1F81IbQDFcJFqFlm0iQoNn pZs2hnVnBG; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] -transport-tls-12, IP addresses 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 Tom, How would you think this would be deployed? In order for an IP address match to be secure in most environments the IP address in the configuration of the transport sender would have to match against an IP address in a subject field within the certificate. Would it be reasonable for a syslog receiver to have a certificate issued to it that has its IP address in a subject field? Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of tom.petch > Sent: Friday, May 09, 2008 4:54 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] -transport-tls-12, IP addresses > > I think that we should allow IP addresses. At the entry > level network box, I think that they are widely used. > > Tom Petch > > > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Wednesday, May 07, 2008 10:39 PM > Subject: [Syslog] -transport-tls-12, IP addresses > > > > Joe, > > > > [Editor's Note: How useful is it to match against IP > address? Do we > > expect deployments to issue certificates with IP > addresses in them? > > Are IP addresses typically used in configuration? ] > > > > I find this a tough question. In my experience, it is not > uncommon to > > configure forwarding via IP addresses instead of hostnames. > One reason > > for this is because of reliability of the logging system > when DNS is > > not (yet --> system startup) available. On the other hand, > I find it > > even a bit disturbing to have a certificate issued for an > IP address. > > But it may make sense. I personally would expect that > operators tend > > to use hostnames inside the certificate. The problem, of > course, would > > be that the configuration then needs both the name and IP address... > > > > I hope this is useful information, even though I am undecided. > > > > Rainer > > _______________________________________________ > > 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 Sun May 11 21:50: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 105DA28C1B7; Sun, 11 May 2008 21:50: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 5E3FA28C1A6 for ; Sun, 11 May 2008 21:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 zLxKJFCLvLl4 for ; Sun, 11 May 2008 21:50:30 -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 010B928C1AE for ; Sun, 11 May 2008 21:50:29 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 May 2008 21:50:26 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4C4oQXl012188; Sun, 11 May 2008 21:50:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4C4oQod023335; Mon, 12 May 2008 04:50:26 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 May 2008 21:50:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 May 2008 21:51:15 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls-12, section 4.2 suggestion Thread-Index: Acix/7ShJomhgzlgS0eKAgKPrhPSlAB6Hyfg References: <577465F99B41C842AAFBE9ED71E70ABA308FBD@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: , X-OriginalArrivalTime: 12 May 2008 04:50:26.0742 (UTC) FILETIME=[B2238D60:01C8B3EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7630; t=1210567826; x=1211431826; c=relaxed/simple; s=sjdkim3002; 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]=20-transport-tls-12,=20section =204.2=20suggestion |Sender:=20; bh=B9Hpnu31KwwzYhk5AGgo/XxcHH9iynGgKQcr0uv7OqA=; b=o07+0+QbCvlRlDjBo+KG/5VJBnZIS1+QnMGBahRe2xd62lGs9YsvIYMliG QSfgi4i+h/n3WGHkij56G0qDEVx9KyPq3fcE57zwRvmG0MyjynCw8waj9t4I VggDwKatOm; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] -transport-tls-12, section 4.2 suggestion 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 Robert, I think this mostly makes sense. Some questions inline below: > > I like Rainer's proposal. I had forgotten about the IESG > desire for an out of box acceptable security. I find this > mechanism a bit dubious, but specifying a reasonably secure > default configuration as a separate policy section could > work. How about a structure like this: > > In the protocol section, since this is TLS and TLS is > certificate oriented, we have the following requirements: > > - The TLS negotiation SHALL be configurable to verify > certificates based on the following rules: > - The local side shall negotiate based on a local > certificate store. > The local certificate store contains a list of > certificate/server pairs. > - The local side shall verify the remote side matches > certificates found in one of three stores: > - Specific certs where Certificate X is accepted for remote X. > (This is oriented toward self-signed certs) > - (optional) Signing certs, where Remote Y is accepted > if its cert was signed by Certificate Y. No chain of trust. > - (optional) Signing certs, where Remote Z is accepted > if its cert was signed by Certificate Z. Chain of trust is accepted. > [Joe] I'm not sure what the different between the last two are. The capability to chain certificates is indicated in the basic constraints extension of a CA certificate and is validated by standard certificate path validation (RFC 5280), is there a reason why this is not sufficient? Perhaps we can collapse the second two into one. > Implementations may add other additional rules for other > situations where connections are accepted, but these shall > not be the default configuration. > [Joe] I believe that the ability to match a Subject name field should be at least RECOMMENDED. > I made the use of signed certs optional because it pulls in > all the other issues around revocation, etc. I'm not too > worried about having a server manage CRLs, updates, etc. but > it could be a problem demanding that all clients also manage > that. I do worry about all the issues that come up in terms > of preserving syslog function during serious network > disruptions. I do not want to see my problem reporting > facility (syslog) fail just because I lost the PKI servers. > I'm think of cases where those servers had been physically > destroyed, but 80% of the network still exists, e.g., Katrina. [Joe] I think having just one mandatory option is fine. > > In the policy section, > > - By default, if verification fails then the connection > will be refused. > - Other rules may be added, but shall not be the out of box default. > > - There shall be a maintenance method to create a self-signed cert. > There shall be a maintenance method to import a self cert > into any of the cert stores. > - There may be a maintenance method for adding and removing > certs in the other two kinds of cert stores. > - There may be other authentication and authorization methods. > > This then enables a reasonably useful default behavior. With > proper instructions a skilled home user could follow these > rules. It also enables direct implementation of many > enterprise rules, although not all of them. It can encourage > developers to split their implementation so that new policy > structures do not cause problems with the underlying protocol > implementation. > > The default home user scenario expectation is the following: > > - Installing a server: > - Home user generates a self-signed certificate for the > server, files it into the server local certificate store, and > saves it for making copies for clients. The corresponding > private key lives somewhere in local configuration files and > the user can be instructed that they should never ever give > that information to other people. > > - Installing a client: > - Home user generates a self-signed certificate for the > client, files it into the client local certificate store, and > saves it for making copies for servers. Again, private key > remains secret in configuration files somewhere. > - Home user copies the client self-signed certificate into > the server's specific certs for remotes. > - Home user copies the server self-signed certificate into > the client's specific certs for remotes. > > This default does not scale to the large enterprise. Adding > the two kinds of signed cert stores extends the default > configuration to support many, but not all, enterprise > policies. There will be other enterprise oriented methods. > > This default does meet the needs of a small enterprise or > skilled home user. By making the default the use of > self-signed certificates you avoid all the problems resulting > from the absence of syslog oriented PKI infrastructures. > Even when there are suitable PKI infrastructures for identity > management, these are not generally suitable for applications > authentication management. Introducing a PKI dependency will > effectively delay the use of syslog-tls for many more years. > > Using self-signed certificates leaves the home user with the > need to copy around these certificates. Moving files from > here to there is something that can be handled by media, web > aps, etc. This is simplified by the lack of security > requirements. All you need is fingerprint display if you > have reason to question the copying. It will overwhelm the > unskilled home user, but they probably won't be configuring > syslog. Someone who is setting up syslog can probably handle > instructions for copying certificates from place to place. > Self-signed certs may take a few minutes to generate, but > they are something that is not overly burdensome for syslog > maintenance programs. > [Joe] This is where a standard fingerprint format can help. > This also scales to the needs of many service providers. If > a service provider is installing thousands of dumb remote > systems to unsupported locations (i.e., unskilled home user > systems), they can preconfigure the dumb remote with > self-signed certificates. Since the rules only require > matching, the service provider does not need to try to match > hostnames, IP addresses, etc. I would base the cert on the > device serial number. This would not be perfect security. [Joe] So in this scenario you match the end entity cert against a local store, correct? >I > could break into the dumb remote and steal the private key. > But it is a huge improvement over the current situation. It > does force me to break in, and none of the PKI structures > protect against that. Revocation is a bigger administrative > problem but you can manage revocation of self-signed > certificates for simple situations like this even at the > service provider scale. > > Kind Regards, > > Robert Horn | Agfa HealthCare > Research Scientist | HE/Technology Office T +1 978 897 4860 > > Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield > Park, NJ, 07660-2199, United States > http://www.agfa.com/healthcare/ Click on link to read > important disclaimer: > http://www.agfa.com/healthcare/maildisclaimer > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 12 02:38:40 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 10F963A6785; Mon, 12 May 2008 02:38:40 -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 9911C3A6785 for ; Mon, 12 May 2008 02:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.82 X-Spam-Level: X-Spam-Status: No, score=-3.82 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_00=-2.599, J_CHICKENPOX_41=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 iygKhbpgxZD5 for ; Mon, 12 May 2008 02:38:36 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 312303A6782 for ; Mon, 12 May 2008 02:38:36 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4C7Cmd3025022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 May 2008 10:16:02 +0300 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4C7C7Lc022915; Mon, 12 May 2008 02:12:38 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 10:12:36 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 10:12:36 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 10:12:35 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7297B110@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Self-signed certs - was: Re: -transport-tls-12, section 4.2.3 (fingerprints) Thread-index: Acix3XszHfw9sQFKQ+SREuAvKpjgPgCIQ3sQ References: <577465F99B41C842AAFBE9ED71E70ABA308FA8@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA308FAA@grfint2.intern.adiscon.com> From: "Pasi.Eronen@nokia.com" To: , X-OriginalArrivalTime: 12 May 2008 07:12:36.0562 (UTC) FILETIME=[8E4ECB20:01C8B3FF] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Self-signed certs - was: Re: -transport-tls-12, section 4.2.3 (fingerprints) 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, I think the real difference here is not "CA-issued certs" vs. "self-signed certs", but "accepting any cert" vs. "accepting certs you can verify (as trusted peers according to your local policy)". We definitely want to discourage blindly accepting any certificate (CA-issued or self-signed); but when properly verified, self-signed certificates are not any less secure than CA-issued ones. Best regards, Pasi > -----Original Message----- > From: Chris Lonvick > Sent: 09 May, 2008 16:20 > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: [Syslog] Self-signed certs - was: Re: > -transport-tls-12, section 4.2.3 (fingerprints) > > Hi, > > On Thu, 8 May 2008, Rainer Gerhards wrote: > > > However, I wonder why it would be useful to auto-generate certs. > > Probably I am overlooking somehting obvious. But: isn't cert > > auto-generation equal to no authentication? After all, if a > > *self-signed* cert is generated by the remote peer AND we accept > > it, doesn't that essentially mean we accept any peer because the > > peer can put whatever it likes into the cert? I do not see why > > this is any better than having no cert at all... > > It minimally protects against masquerade and disclosure, two of the > threats we agreed upon. It will also provide a TCP-based transport > for anyone who wishes/needs to have a mechanism to throttle the flow > of packets for congestion control - something that you cannot do > with the UDP transport. > > Those are the reasons I can think of. You do raise a good point by > questioning this and I'd like to see some discussion from the WG. > Are these reasons sufficient to keep self-signed certs in the > specification? If so, should specific comments be made about their > use? > > WG Chair Hat sort'a on, sort'a off: I'm thinking that a self-signed > cert is the method of least effort to provide congestion control for > syslog and it should be included in the document just for that > reason. This was the objection raised by the Transport ADs when > they saw that syslog-transport-udp was the only REQUIRED transport. > I agree that self-signed certs don't really provide good protection > and that should be noted in the Security Considerations Section. If > you don't agree with this, please object now. > > If you do agree with this, does the following text work: > === > (Perhaps as a third paragraph in Section 4.2.4) > > Self-signed certificates will provide minimal protection against > modification and disclosure. Their use will not provide effective > protection against masqeurade unless they are used with certificate > fingerprint authorization lists. The use of self-signed > certificates without certificate fingerprint authorization lists is > NOT RECOMMENDED. However since tls is a tcp-based protocol, > enabling tls, even with self-signed certificates, will effectively > enable congestion control in the network. See Section 8.6 of > [syslog-protocol]. > > And perhaps merge the first three sentences of the above with > the second paragraph in Sec Considerations section 5.1. Current: > The use of self-signed certificates with certificate fingerprint > authorization lists provides more protection from > masquerade and man-in-the-middle attacks than forgoing certificate > validation and authorization. > === > > Thanks, > Chris _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 12 02:42:52 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 B8B3C3A67AC; Mon, 12 May 2008 02:42:52 -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 083F93A67AC for ; Mon, 12 May 2008 02:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.99 X-Spam-Level: X-Spam-Status: No, score=-3.99 tagged_above=-999 required=5 tests=[AWL=-1.391, 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 h8Rsx1dW8eKG for ; Mon, 12 May 2008 02:42:48 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 003F03A6785 for ; Mon, 12 May 2008 02:42:47 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4C78wfQ021587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 May 2008 10:09:00 +0300 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4C75fxu016574; Mon, 12 May 2008 02:05:42 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 10:04:50 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 10:04:50 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 10:04:50 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7297B0ED@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-index: AcixJ3rNzgthskVtQ8m7H5WWMUT9mgC0i9Bw References: <20080507150001.D3CB428C65B@core3.amsl.com> From: "Pasi.Eronen@nokia.com" To: , , X-OriginalArrivalTime: 12 May 2008 07:04:50.0038 (UTC) FILETIME=[783CE160:01C8B3FE] X-Nokia-AV: Clean Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 Robert, Section 4.2 includes some requirements for "management interface for policy decisions" because we need interoperabile security. Since TLS doesn't really verify the certificate (except extracting the public key), in order to get two something-over-TLS implementations to interoperate, you still need to specify how to configure one end to accept the certificate of the other end. Traditionally, the answer has been "just read the PKIX documents", but for small syslog deployments, we really need something more deployable. The fingerprint check in draft version -12 attempts to fill this gap. It's definitely not perfect, or the only possible solution; as you note, it's very similar to actually copying the certificate (your Policy A below). The current text requires management interface support for displaying and configuring fingerprints (instead of displaying and configuring whole certificates) because it was assumed that for many command line and web-based management interfaces, it's much simpler to cut-and-paste a short ASCII string instead of a binary file. (And this should make it more deployable for small syslog environments.) However, it would be perfectly fine to have a management interface that also supports exporting/importing whole certificates. Also, Section 4.2 does not require that a particular deployment actually uses any of the mandatory-to-implement mechanisms, so all your policies A/B/C would be OK. (Also, while Section 4.2 currently has both certification path validation and fingerprints as mandatory-to-implement, it's not totally out-of-the-question that only one of them would be a MUST, and the other one a SHOULD.) Best regards, Pasi > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of ext robert.horn@agfa.com > Sent: 08 May, 2008 18:53 > To: Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > Section 4.2 is better, but it still needs work to separate the > policy decisions from the protocol definition. Policy decisions are > driven by risk analysis of the assets, threats, and environment > (among other things). These are not uniform over all uses of > syslog. That makes it important to separate the policy from the > protocol, in both the specifications and in the products. > > In the healthcare environment we use TLS to protect many of our > connections. This is both an authentication protection and a > confidentiality protection. The policy decisions regarding key > management and verification will be very similar for a healthcare > use of syslog. Some healthcare sites would reach the same policy > decision as is in 4.2, but here are three other policy decisions > that are also appropriate: > > Policy A: > The clients are provided with their private keys and the public > certificates for their authorized servers by means of physical > media, delivered by hand from the security office to the client > machine support staff. (The media is often CD-R because it's cheap, > easy to create, easy to destroy, and easy to use.) During TLS > establishment the clients use their assigned private key and the > server confirms that the connection is from a machine with one of > the assigned private keys. The client confirms that the server > matches one of the provided public certificates by direct matching. > This is similar to the fingerprint method, but not the same. My most > recent experience was with an installation using this method. We > had two hours to install over 100 systems, including the network > facilities. This can only be done by removing as many installation > schedule dependencies as possible. The media method removed the > certificate management dependencies. > > Policy B: > These client systems require safety and functional certification > before they are made operational. This is done by inspection by an > acceptance team. The acceptance team has a "CA on a laptop". After > accepting safety and function, they establish a direct isolated > physical connection between the client and the laptop. Then using > standard key management tools, the client generates a private key > and has the corresponding public certificate generated and signed by > the laptop. The client is also provided with a public certificate > for the CA that must sign the certs for all incoming connections. > > During a connection setup the client confirms that the server key > has been signed by that CA. This is similar to a trusted anchor, > but not the same. There is no chain of trust permitted. The key > must have been directly signed by the CA. During connection setup > the server confirms that the client cert was signed by the "CA on a > laptop". Again, no chain of trust is permitted. This policy is > incorporating the extra aspect of "has been inspected by the > acceptance team" as part of the authentication meaning. They > decided on a policy-risk basis that there was not a need to confirm > re-inspection, but the "CA on a laptop" did have a revocation server > that was kept available to the servers, so that the acceptance team > could revoke at will. > > Policy C: > This system was for a server that accepted connections from > several independent organizations. Each organization managed > certificates differently, but ensured that the organization-CA had > signed all certs used for external communications by that > organization. All of the client machines were provided with the > certs for the shared servers (by a method similar to the fingerprint > method). During TLS connection the clients confirmed that the > server cert matched one of the certs on their list. The server > confirmed that the client cert had been signed by the CA responsible > for that IP subnet. The server was configured with a list of > organization CA certs and their corresponding IP subnets. > > I do not expect any single policy choice to be appropriate for all > syslog uses. I think it will be better to encourage a separation of > function in products. There is more likely to be a commonality of > configuration needs for all users of TLS on a particular system than > to find a commonality of needs for all users of syslog. The policy > decisions implicit in section 4.2 make good sense for many uses. > They are not a complete set. So a phrasing that explains the kinds > of maintenance and verification needs that are likely is more > appropriate. The mandatory verifications can be separated from the > key management system and kept as part of the protocol definition. > The policy decisions should be left as important examples. > > Kind Regards, > > Robert Horn | Agfa HealthCare > Research Scientist | HE/Technology Office > T +1 978 897 4860 > > Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield > Park, NJ, > 07660-2199, United States > http://www.agfa.com/healthcare/ > Click on link to read important disclaimer: > http://www.agfa.com/healthcare/maildisclaimer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 12 04:54:03 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 416493A68C3; Mon, 12 May 2008 04:54:03 -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 DF9FF3A6885 for ; Mon, 12 May 2008 04:54:01 -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 w7+5cgZLAzl8 for ; Mon, 12 May 2008 04:54:00 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id D45A23A6863 for ; Mon, 12 May 2008 04:53:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,473,1204498800"; d="scan'208";a="45300817" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 12 May 2008 13:53:20 +0200 In-Reply-To: To: jsalowey@cisco.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Mon, 12 May 2008 07:53:17 -0400 Cc: syslog@ietf.org Subject: Re: [Syslog] -transport-tls-12, section 4.2 suggestion 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 Some inline responses below. Plus an explanation of the difference in chain of trust. The situation that I have seen is one where there are certificate issuer policy disagreements. One CA (I'll call it Region 1) issues certificates that permit chain of trust by allowing further signatures. The other CA (I'll call them Region 2) says that Region 1 is not allowed to issue certificates for Region 2. This is just part of a much bigger turf war between Region 1 and Region 2. Server does not want to get into the middle of the turf wars between Region 1 and Region2. In theory, the complexity of policy disagreements can be unbounded. In practice, I've found it sufficient to have two extra rules that over-ride the contents of the certificate. I limit the ability to sign other certificates. This seems to eliminate most of these policy overlaps. I also limit the scope of certificate authority to a list of IP subnets. These two seem to be sufficient to limit the scope of a certificate to just those machines that are within the policy domain of the source of certificates. If you think it would be easier to standardize the ability to configure a list of IP subnets rather than chaining constraints, that would be just as effective. It's a little more work to configure properly, but it deals with a wider range of policy disagreements. Kind Regards, Robert Horn | Agfa HealthCare Research Scientist | HE/Technology Office T +1 978 897 4860 Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 07660-2199, United States http://www.agfa.com/healthcare/ Click on link to read important disclaimer: http://www.agfa.com/healthcare/maildisclaimer "Joseph Salowey (jsalowey)" wrote on 05/12/2008 12:51:15 AM: > Hi Robert, > > I think this mostly makes sense. Some questions inline below: > > > > I like Rainer's proposal. I had forgotten about the IESG > > desire for an out of box acceptable security. I find this > > mechanism a bit dubious, but specifying a reasonably secure > > default configuration as a separate policy section could > > work. How about a structure like this: > > > > In the protocol section, since this is TLS and TLS is > > certificate oriented, we have the following requirements: > > > > - The TLS negotiation SHALL be configurable to verify > > certificates based on the following rules: > > - The local side shall negotiate based on a local > > certificate store. > > The local certificate store contains a list of > > certificate/server pairs. > > - The local side shall verify the remote side matches > > certificates found in one of three stores: > > - Specific certs where Certificate X is accepted for remote X. > > (This is oriented toward self-signed certs) > > - (optional) Signing certs, where Remote Y is accepted > > if its cert was signed by Certificate Y. No chain of trust. > > - (optional) Signing certs, where Remote Z is accepted > > if its cert was signed by Certificate Z. Chain of trust is accepted. > > > [Joe] I'm not sure what the different between the last two are. The > capability to chain certificates is indicated in the basic constraints > extension of a CA certificate and is validated by standard certificate > path validation (RFC 5280), is there a reason why this is not > sufficient? Perhaps we can collapse the second two into one. > > > Implementations may add other additional rules for other > > situations where connections are accepted, but these shall > > not be the default configuration. > > > [Joe] I believe that the ability to match a Subject name field should be > at least RECOMMENDED. > > > I made the use of signed certs optional because it pulls in > > all the other issues around revocation, etc. I'm not too > > worried about having a server manage CRLs, updates, etc. but > > it could be a problem demanding that all clients also manage > > that. I do worry about all the issues that come up in terms > > of preserving syslog function during serious network > > disruptions. I do not want to see my problem reporting > > facility (syslog) fail just because I lost the PKI servers. > > I'm think of cases where those servers had been physically > > destroyed, but 80% of the network still exists, e.g., Katrina. > > [Joe] I think having just one mandatory option is fine. > > > > > In the policy section, > > > > - By default, if verification fails then the connection > > will be refused. > > - Other rules may be added, but shall not be the out of box default. > > > > - There shall be a maintenance method to create a self-signed cert. > > There shall be a maintenance method to import a self cert > > into any of the cert stores. > > - There may be a maintenance method for adding and removing > > certs in the other two kinds of cert stores. > > - There may be other authentication and authorization methods. > > > > This then enables a reasonably useful default behavior. With > > proper instructions a skilled home user could follow these > > rules. It also enables direct implementation of many > > enterprise rules, although not all of them. It can encourage > > developers to split their implementation so that new policy > > structures do not cause problems with the underlying protocol > > implementation. > > > > The default home user scenario expectation is the following: > > > > - Installing a server: > > - Home user generates a self-signed certificate for the > > server, files it into the server local certificate store, and > > saves it for making copies for clients. The corresponding > > private key lives somewhere in local configuration files and > > the user can be instructed that they should never ever give > > that information to other people. > > > > - Installing a client: > > - Home user generates a self-signed certificate for the > > client, files it into the client local certificate store, and > > saves it for making copies for servers. Again, private key > > remains secret in configuration files somewhere. > > - Home user copies the client self-signed certificate into > > the server's specific certs for remotes. > > - Home user copies the server self-signed certificate into > > the client's specific certs for remotes. > > > > This default does not scale to the large enterprise. Adding > > the two kinds of signed cert stores extends the default > > configuration to support many, but not all, enterprise > > policies. There will be other enterprise oriented methods. > > > > This default does meet the needs of a small enterprise or > > skilled home user. By making the default the use of > > self-signed certificates you avoid all the problems resulting > > from the absence of syslog oriented PKI infrastructures. > > Even when there are suitable PKI infrastructures for identity > > management, these are not generally suitable for applications > > authentication management. Introducing a PKI dependency will > > effectively delay the use of syslog-tls for many more years. > > > > Using self-signed certificates leaves the home user with the > > need to copy around these certificates. Moving files from > > here to there is something that can be handled by media, web > > aps, etc. This is simplified by the lack of security > > requirements. All you need is fingerprint display if you > > have reason to question the copying. It will overwhelm the > > unskilled home user, but they probably won't be configuring > > syslog. Someone who is setting up syslog can probably handle > > instructions for copying certificates from place to place. > > Self-signed certs may take a few minutes to generate, but > > they are something that is not overly burdensome for syslog > > maintenance programs. > > > > [Joe] This is where a standard fingerprint format can help. > [rjh] I'm a little surprised that this has not been standardized somewhere in the PKI standards, but I've not found it yet. We really shouldn't be dealing with this inside syslog. The needs go far beyond syslog and it will be a problem if different applications use different forms. Is there some way to shift this over to be their problem and get a common solution? Are we already unable to specify a common solution because of an installed base of disagreement between CAs and fingerprint algorithms? What I've seen from other certificate tools is the dual display of MD5 and SHA1 fingerprints, both in the numeric pair notation. Could some similar approach be used? > > This also scales to the needs of many service providers. If > > a service provider is installing thousands of dumb remote > > systems to unsupported locations (i.e., unskilled home user > > systems), they can preconfigure the dumb remote with > > self-signed certificates. Since the rules only require > > matching, the service provider does not need to try to match > > hostnames, IP addresses, etc. I would base the cert on the > > device serial number. This would not be perfect security. > > [Joe] So in this scenario you match the end entity cert against a local > store, correct? [rjh] Yes. That's one reason for scalability problems, but the service provider for dumb remotes generally has a database of many properties that are unique to each remote. This adds one more item to that list, but since the provider is the issuer it can be prepopulated and maintained easily. > > >I > > could break into the dumb remote and steal the private key. > > But it is a huge improvement over the current situation. It > > does force me to break in, and none of the PKI structures > > protect against that. Revocation is a bigger administrative > > problem but you can manage revocation of self-signed > > certificates for simple situations like this even at the > > service provider scale. > > > > Kind Regards, > > > > Robert Horn | Agfa HealthCare > > Research Scientist | HE/Technology Office T +1 978 897 4860 > > > > Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield > > Park, NJ, 07660-2199, United States > > http://www.agfa.com/healthcare/ Click on link to read > > important disclaimer: > > http://www.agfa.com/healthcare/maildisclaimer > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 12 13:05:32 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 E5BB13A67C0; Mon, 12 May 2008 13:05:32 -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 813373A67A2 for ; Mon, 12 May 2008 13:05:30 -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 UYRyic18UpEF for ; Mon, 12 May 2008 13:05:27 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id BFFEB3A67C0 for ; Mon, 12 May 2008 13:05:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 5ED4C7AD8C0; Mon, 12 May 2008 22:01:08 +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 RpjMzfQwJVZD; Mon, 12 May 2008 22:01:08 +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 CF82B7AD667; Mon, 12 May 2008 22:01:07 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 May 2008 22:05:18 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FC3@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABfCe0AAmYDUoA== References: <20080507150001.D3CB428C65B@core3.amsl.com> <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , , Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 Joe, Comments inline below.... > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Monday, May 12, 2008 5:40 AM > To: Rainer Gerhards; robert.horn@agfa.com; syslog@ietf.org > Cc: Pasi.Eronen@nokia.com > Subject: RE: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Friday, May 09, 2008 1:36 AM > > To: robert.horn@agfa.com; Joseph Salowey (jsalowey); syslog@ietf.org > > Cc: Pasi.Eronen@nokia.com > > Subject: RE: [Syslog] I-D > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > Hi all, > > > > I agree to Robert, policy decisions need to be separated. I > > CC Pasi because my comment is directly related to IESG > > requirements, which IMHO cannot be delivered by *any* syslog > > TLS document without compromise [comments directly related to > > IESG are somewhat later, I need to level ground first]. > > > > Let me tell the story from my implementor's POV. This is > > necessarily tied to rsyslog, but I still think there is a lot > > of general truth in it. So I consider it useful as an example. > > > > I took some time yesterday to include the rules laid out in > > 4.2 into rsyslog design. I quickly came to the conclusion > > that 4.2. is talking about at least two things: > > > > a) low-level handshake validation > > b) access control > > > [Joe] It is possible for the document to separate out > authentication/cert validation from authorization. I would note that > there tends to be a lot of linkages between the two so this will tend > increase the amount of text needed. If the working group wants to do > this I can work on it. > > > In a) we deal with the session setup. Here, I see certificate > > exchange and basic certificate validation (for example > > checking the validity dates). In my current POV, this phase > > ends when the remote peer can positively be identified. > > > > Once we have positive identification, b) kicks in. In that > > phase, we need to check (via ACLs) if the remote peer is > > permitted to talk to us (or we are permitted to talk to it). > > Please note that from an architectural POV, this can be > > abstracted to a higher layer (and in rsyslog it probably > > will). For that layer, it is quite irrelevant if the remote > > peer's identity was obtained via a certificate (in the case > > of transport-tls), a simple reverse lookup (UDP syslog), SASL > > (RFC 3195) or whatever. What matters is that the ACL engine > > got a trusted identify from the transport layer and verifies > > that identity [level of trust varies, obviously]. Most policy > > decisions happen on that level. > > > > There is some grayish between a) and b). For example, I can > > envision that if there is a syslog.conf rule (forward everything to > > server.example.net) > > > > *.* @@server.example.net > > > > The certificate name check for server.example.net (using dNSName > > extension) could probably be part of a) - others may think it > > is part of b). > > > > Also, even doing a) places some burden onto the system, like > > the need to have trust anchors configured in order to do the > > validation. This hints at at least another sub-layer. > > > > I think it would be useful to spell out these different > > entities in the draft. > > > [Joe] What do you mean by entities. We can define two separate > processes that need to happen, but I don't think we want to > specify how > an implementor must build this. I meant a) low-level handshake validation b) access control I still think there is a fundamental difference between verifying the name that is given in the config file and verifying higher level access control. But, of course, we do not/can not define application design. I just thought it would be usefule to spell out there is a difference. > > Coming back to policy decisions, one must keep in mind that > > the IESG explicitly asked for those inside the document. This > > was done based on the -correct- assumption that today's > > Internet is no longer a friendly place. So the IESG would > > like to see a default policy implemented that provides at > > least a minimum acceptable security standard. > > [Joe] I believe this is part of the goal. I think there is also the > desire that implementations support some basic level of policy that > allows interoperability. Implementations can support other policies, > deployers can deploy other policies. > > > Unfortunately, > > this is not easy to do in the world of syslog. For the home > > users, we cannot rely on any ability to configure something. > > For the enterprise folks, we need to have defaults that do > > not get into their way of doing things [aka "can be easily > > turned off"]. There is obviously much in between these poles, > > so it largely depends on the use case. I have begun a wiki > > page with use cases and hope people will contribute to it. It > > could lead us to a much better understanding of the needs > > (and the design decisions that need to be made to deliver > > these). It is available at > > > > http://wiki.rsyslog.com/index.php/TLS_for_syslog_use_cases > > > > After close consideration, I think the draft currently fails > > on addressing the two use cases define above properly. Partly > > it fails because it is not possible under the current IESG > > requirement to be safe by default. We cannot be fully safe by > > default without configuration, so whatever we specify will > > fail for the home user. > > > > A compromise may be to provide "good enough" security in the > > default policy. I see two ways of doing that: one is to NOT > > address the Masquerade and Modification threats in the > > default policy, just the Disclosure threat. That leads us to > > unauthenticated syslog being the default (contrary to what is > > currently implemented) [Disclosure is addressed in this > > scenario as long as the client configs are not compromised, > > which I find sufficiently enough - someone who can compromise > > the client config can find other ways to get hold of the > > syslog message content]. > > > [Joe] If you don't address the relevant threats I'm not sure you can > call security "good enough". I can do this because, from a practical perspective, what most people are concerned with is confidentiallity. Let me ask a question: how can we say HTTPS is secure? After all, the HTTPS client is almost never authenticated against the server. From my practical perspective, HTTPS-like security, easily enabled by default even for the unskilled user is much better than "full" security that only exists in theory - because people turn it off. Security is only as good as the humans using it... > > > An alternative is to use the way HTTPS works: we only > > authenticate the server. To authenticate, we need to have > > trusted certificate inside the server. As we can see in > > HTTPS, this doesn't really require PKI. It is sufficient to > > have the server cert singed by one of few globally trusted > > CAs and have this root certificates distributed with all > > client installations as part of their setup procedure. This > > is quite doable. In that scenario, a client can verify a > > server's identity and the above sample (*.* > > @server.example.net) could be verified with sufficient trust. > > The client, however, is still not authenticated. However, the > > threats we intended to address are almost all addressed, > > except for the access control issue which is defined as part > > of the Masquerade threat (which I think is even a different > > beast and deserves its own threat definition now that I think > > about it). In short we just have an access control issue in > > that scenario. Nothing else. > > > [Joe] I think the threat model in the document describes masquerade of > the client. IMHO the document MUST describe masquerade of both client and server. Server masquerade is very serious. >Perhaps access control is not the only way to deal with > this, perhaps just being able to associate the authenticated identity > with the messages is enough, I don't know at this point. See my comment above. > > > The problem, however, is that the server still needs a > > certificate and now even one that, for a home user, is > > prohibitively expensive. The end result will be that people > > turn off TLS, because they neither know how to obtain the > > certificate nor are willing to trade in a weekend vacation > > for a certificate ;) In the end result, even that mode will > > be less useful than anonymous authentication. > > > > The fingerprint idea is probably a smart solution to the > > problem. It depends on the ability to auto-generate a > > certificate [I expressed that I don't like that idea > > yesterday, but my thinking has evolved ;)] OR to ship every > > device/syslogd with a unique certificate. In this case, only > > minimal interaction is required. The idea obviously is like > > with SSH: if the remote peer is unknown, the user is queried > > if the connection request is permitted and if the certificate > > should be accepted in the future. If so, it is added > > permanently to the valid certificate store and used in the > > future to authenticate requests from the same peer. This > > limits the security weakness to the first session. HOWEVER, > > the problem with syslog is that the user typically cannot be > > prompted when the initial connection happens (everything is > > background activity). So the request must actually be logged > > and an interface be developed that provides for user > > notification and the ability to authorize the request. > > > > This requires some kind of "unapproved certificate store" > > plus a management interface for it. Well done, this may > > indeed enable a home user to gain protection from all three > > threats without even knowing what he really does. It "just" > > requires some care in approving new fingerprints, but that's > > a general problem with human nature that we may tackle by > > good user interface desig but can't solve from a protocol > > point of view. > > > > The bad thing is that it requires much more change to > > existing syslogd technology. That, I fear, reduces acceptance > > rate. Keep in mind that we already have a technically good > > solution (RFC 3195) which miserably failed in practice due to > > the fact it required too much change. > > > > If I look at *nix implementations, syslogd implementers are > > probably tempted to "just" log a message telling "could not > > accept remote connection due to invalid fingerprint > > xx:xx:..." and leave it to the user to add it to syslog.conf. > > However, I fear that for most home setups even that would be > > too much. So in the end effect, in order to avoid user > > hassle, most vendors would probably default back to UDP > > syslog and enable TLS only on user request. > > > > From my practical perspective this sounds even reasonable > > (given the needs and imperfections of the real world...). If > > that assessment is true, we would probably be better off by > > using anonymous TLS as the default policy, with the next > > priority on fingerprint authentication as laid out above. A > > single big switch could change between these two in actual > > implementations. Those users that "just want to get it running" > > would never find that switch but still be somewhat > protected while the > > (little) more technically aware can turn it to fingerprint > > authentication and then will hopefully be able to do the > > remaining few configuration steps. Another policy is the > > certificate chain based policy, where using public CAs would > > make sense to me. > > > > To wrap it up: > > > > 1. I propose to lower the default level of security > > for the reasons given. > > My humble view is that lower default security will > result in higher > > overall security. > > > [Joe] I'm not convinced of this. If you use TLS without > authentication > and authorization you don't really gain any security benefit > from it, it > is pretty much the equivalent of not running security. Again, this leads to the conlusion that HTTPS is not running security. > It might be > reasonable to relax the requirement on being able to do access control > on the server, but I think the threat section would need to discuss > this. As the discusion shows, the threat section seems to be imprecise. It should discuss the threats in the context of who is protected - client or server. Obviously, server masquerade is different from server masquerade. Again, I don't think that server masquerade is less serious. Just think of hosts/dns spoof attacks fooling the client into sending data to the wrong server. Rainer > > > 2. We should split authentication policies from the protocol itself > > ... just as suggested by Robert and John. We should > define a core > > set of policies (I think I described the most relevant simple > > cases above, Robert described some complex ones) and leave it > > others to define additional policies based on their demand. > > > [Joe] We can split the policies, but I don't it will necessarily be as > clean as one might hope. I believe the document does have to > specify a > minimum set of policies that can > > A) enable interoperable deployment > B) provide mitigation against the listed threats > > Additional policies can be supported and defined (in this > document or a > separate one). > > > Policies should go either into their own section OR into > > their own documents. I have a strong favor of putting them > > into their own documents if that enables us to finally > > finish/publish -transport-tls and the new syslog RFC series. > > If that is not an option, I'd prefer to spend some more work > > on -transport-tls, even if it delays things further, instead > > of producing something that does not meet the needs found > in practice. > > > > > > Rainer > > > > > > > -----Original Message----- > > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > > Behalf Of robert.horn@agfa.com > > > Sent: Thursday, May 08, 2008 5:53 PM > > > To: Joseph Salowey (jsalowey); syslog@ietf.org > > > Subject: Re: [Syslog] I-D > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > > > Section 4.2 is better, but it still needs work to separate > > the policy > > > decisions from the protocol definition. Policy decisions > are driven > > by > > > risk analysis of the assets, threats, and environment > (among other > > > things). These are not uniform over all uses of syslog. > That makes > > it > > > important to separate the policy from the protocol, in both the > > > specifications and in the products. > > > > > > In the healthcare environment we use TLS to protect many of our > > > connections. This is both an authentication protection and a > > > confidentiality protection. The policy decisions regarding key > > > management and verification will be very similar for a > > healthcare use > > > of syslog. > > > Some > > > healthcare sites would reach the same policy decision as > is in 4.2, > > but > > > here are three other policy decisions that are also appropriate: > > > > > > Policy A: > > > The clients are provided with their private keys and > the public > > > certificates for their authorized servers by means of > > physical media, > > > delivered by hand from the security office to the client machine > > > support staff. (The media is often CD-R because it's > > cheap, easy to > > > create, easy to destroy, and easy to use.) During TLS > > establishment > > > the clients > > use > > > their assigned private key and the server confirms that the > > connection > > > is from a machine with one of the assigned private keys. > > The client > > > confirms that the server matches one of the provided public > > > certificates by direct matching. This is similar to the > > fingerprint > > > method, but not the > > same. > > > My > > > most recent experience was with an installation using this > > method. We > > > had two hours to install over 100 systems, including the network > > > facilities. > > > This can only be done by removing as many installation schedule > > > dependencies as possible. The media method removed the > certificate > > > management dependencies. > > > > > > Policy B: > > > These client systems require safety and functional > certification > > > before they are made operational. This is done by > inspection by an > > acceptance > > > team. The acceptance team has a "CA on a laptop". After > accepting > > > safety and function, they establish a direct isolated physical > > > connection between the client and the laptop. Then using > > standard key > > > management tools, the client generates a private key and has the > > > corresponding public certificate generated and signed by > > the laptop. > > > The client is also provided with a public certificate for > > the CA that > > > must sign the certs for all incoming connections. > > > > > > During a connection setup the client confirms that the > > server key has > > > been signed by that CA. This is similar to a trusted > > anchor, but not > > > the same. > > > There is no chain of trust permitted. The key must have been > > directly > > > signed by the CA. During connection setup the server > confirms that > > the > > > client cert was signed by the "CA on a laptop". Again, > no chain of > > > trust is permitted. This policy is incorporating the extra > > aspect of > > > "has been inspected by the acceptance team" as part of the > > > authentication meaning. > > > They decided on a policy-risk basis that there was not a need to > > > confirm re-inspection, but the "CA on a laptop" did have a > > revocation > > > server that was kept available to the servers, so that the > > acceptance > > > team could revoke at will. > > > > > > Policy C: > > > This system was for a server that accepted connections > > from several > > > independent organizations. Each organization managed > certificates > > > differently, but ensured that the organization-CA had > > signed all certs > > > used for external communications by that organization. > All of the > > > client machines were provided with the certs for the > shared servers > > > (by a method similar to the fingerprint method). During TLS > > > connection the clients confirmed that the server cert > > matched one of > > > the certs on their list. > > > The > > > server confirmed that the client cert had been signed by the CA > > > responsible for that IP subnet. The server was configured > > with a list > > > of organization CA certs and their corresponding IP subnets. > > > > > > I do not expect any single policy choice to be > appropriate for all > > > syslog uses. I think it will be better to encourage a > > separation of > > > function in products. There is more likely to be a > commonality of > > > configuration needs for all users of TLS on a particular > > system than > > > to find a commonality of > > > needs for all users of syslog. The policy decisions implicit in > > > section > > > 4.2 make good sense for many uses. They are not a complete > > set. So a > > > phrasing that explains the kinds of maintenance and > > verification needs > > > that are likely is more appropriate. The mandatory > > verifications can > > > be separated from the key management system and kept as > part of the > > > protocol definition. The policy decisions should be left > > as important > > examples. > > > > > > Kind Regards, > > > > > > Robert Horn | Agfa HealthCare > > > Research Scientist | HE/Technology Office T +1 978 897 4860 > > > > > > Agfa HealthCare Corporation, 100 Challenger Road, > > Ridgefield Park, NJ, > > > 07660-2199, United States http://www.agfa.com/healthcare/ > Click on > > > link to read important disclaimer: > > > http://www.agfa.com/healthcare/maildisclaimer > > > _______________________________________________ > > > 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 Mon May 12 15:17:00 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 C57DA28C28A; Mon, 12 May 2008 15:17:00 -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 F04E53A67B7 for ; Mon, 12 May 2008 15:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 wJDKWzYB3jf9 for ; Mon, 12 May 2008 15:16:57 -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 CDD913A6767 for ; Mon, 12 May 2008 15:16:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,475,1204531200"; d="scan'208";a="67056691" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 12 May 2008 15:16:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4CMGuvY001855; Mon, 12 May 2008 15:16:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4CMGtKB012753; Mon, 12 May 2008 22:16:55 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 15:16:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 15:17:44 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FC3@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABfCe0AAmYDUoAAETG6A References: <20080507150001.D3CB428C65B@core3.amsl.com> <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FC3@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , , X-OriginalArrivalTime: 12 May 2008 22:16:55.0821 (UTC) FILETIME=[E358ABD0:01C8B47D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3310; t=1210630616; x=1211494616; 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-12.txt |Sender:=20; bh=X7Pmc/EDLvOueQWF/ObFjqEipm2JI5xjWz67CwpGB1Q=; b=a29uOUFHIHHZ4NWHgYJJdl1l5o0d3u3eDW1BU4E/PzG91aEx8V82cHoPkD K3PqtuikGhK/KFSC3CJaHZjWQplE++FQY7XB5g1MZUQjpvJ6g7cKAI7EcRMR VZJ895zHyRicv3AbTk9ydPv5okfoNtgQyoIFeQrO5gm8QxX0mTFAk=; 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-12.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 Rainer, Comments below: > > > http://wiki.rsyslog.com/index.php/TLS_for_syslog_use_cases > > > > > > After close consideration, I think the draft currently fails on > > > addressing the two use cases define above properly. > Partly it fails > > > because it is not possible under the current IESG > requirement to be > > > safe by default. We cannot be fully safe by default without > > > configuration, so whatever we specify will fail for the home user. > > > > > > A compromise may be to provide "good enough" security in > the default > > > policy. I see two ways of doing that: one is to NOT address the > > > Masquerade and Modification threats in the default > policy, just the > > > Disclosure threat. That leads us to unauthenticated > syslog being the > > > default (contrary to what is currently implemented) > [Disclosure is > > > addressed in this scenario as long as the client configs are not > > > compromised, which I find sufficiently enough - someone who can > > > compromise the client config can find other ways to get > hold of the > > > syslog message content]. > > > > > [Joe] If you don't address the relevant threats I'm not > sure you can > > call security "good enough". > > I can do this because, from a practical perspective, what > most people are concerned with is confidentiallity. Let me > ask a question: how can we say HTTPS is secure? After all, > the HTTPS client is almost never authenticated against the > server. From my practical perspective, HTTPS-like security, > easily enabled by default even for the unskilled user is much > better than "full" security that only exists in theory - > because people turn it off. Security is only as good as the > humans using it... > [Joe] We are not talking about HTTPS we are talking about syslog. What applies to one may not necessarily apply to the other (HTTP provides other ways to authenticate the client etc.). In addition HTTPS authenticates the server in most cases. In any case, I don't think you can claim confidentiality if you do not take care of masquerade or man-in-the-middle as either will result in a breach of confidentiality, you are still vulnerable to active attackers. I believe that implementations need to support mutual authentication and authorization with certificates. The recommended mechanisms for this probably still need some discussion, however I think it is important to provide this capability. I think what is more to the point in the current discussion is what is required by default. I would like to suggest that server authentication, certificate path validation and authorization be required by default, because I without this I don't think any security goals are met. I would also suggest that by default clients should present and authenticate with a certificate, however a server does not necessarily need to perform path validation or authorization, it can just record the certificate (or fingerprint) that carries the public key used in the authentication so it can be validated at a later time. This requires configuration on the client, but not necessarily on the server. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 12 22:46:01 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 6E99828C2C3; Mon, 12 May 2008 22:46:01 -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 5B1F328C2C3 for ; Mon, 12 May 2008 22:45: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=[AWL=0.000, 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 2zbVG1q2L2CM for ; Mon, 12 May 2008 22:45:58 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 2803228C2AB for ; Mon, 12 May 2008 22:45:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 2ECAA7ADFD3; Tue, 13 May 2008 07:43:07 +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 mzuA-OkcdREZ; Tue, 13 May 2008 07:43:07 +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 E39BA7ADD46; Tue, 13 May 2008 07:43:06 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 13 May 2008 07:43:46 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FC5@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABfCe0AAmYDUoAAETG6AABAwLkA= References: <20080507150001.D3CB428C65B@core3.amsl.com> <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FC3@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , , Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.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 Joe, [big snip] > [Joe] We are not talking about HTTPS we are talking about syslog. What > applies to one may not necessarily apply to the other (HTTP provides > other ways to authenticate the client etc.). In addition HTTPS > authenticates the server in most cases. In any case, I don't think you > can claim confidentiality if you do not take care of masquerade or > man-in-the-middle as either will result in a breach of confidentiality, > you are still vulnerable to active attackers. > > I believe that implementations need to support mutual authentication > and > authorization with certificates. The recommended mechanisms for this > probably still need some discussion, however I think it is important to > provide this capability. I think what is more to the point in the > current discussion is what is required by default. That is what I was talking about. I do not say that I do not like full blown security. What I say is that I prefer weaker security even for the unskilled user in favor of no security. As I wrote, my suggestions were for the default case. > I would like to > suggest that server authentication, certificate path validation and > authorization be required by default, because I without this I don't > think any security goals are met. I would also suggest that by default > clients should present and authenticate with a certificate, however a > server does not necessarily need to perform path validation or > authorization, it can just record the certificate (or fingerprint) that > carries the public key used in the authentication so it can be > validated > at a later time. > > This requires configuration on the client, but not necessarily on the > server. The server needs to be configured with the client identities. Anyhow... I think we have exchanged enough arguments for now. We are right now obviously looking from different angles (skilled users via home users), which makes it hard to come to a conclusion. At least I will now continue to implement the current draft. I can always add different authentication modes later, so it doesn't hurt to implement a basic set. Plus, the draft allows for anonymous authentication. I'll make it very easy to turn this on, what probably solves the home user problem I see. I'll post notes if I come along anything noteworthy during implementation. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue May 13 03:50:10 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 AE92B3A67A5; Tue, 13 May 2008 03:50:10 -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 0CA6E3A67A5 for ; Tue, 13 May 2008 03:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_35=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 81Q-xT18INrj for ; Tue, 13 May 2008 03:50:08 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id EC2F43A67A1 for ; Tue, 13 May 2008 03:50:06 -0700 (PDT) X-Trace: 26327891/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.74 X-SBRS: None X-RemoteIP: 62.188.135.74 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAL8OKUg+vIdK/2dsb2JhbACLUaERBA X-IP-Direction: IN Received: from 1cust74.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.74]) by smtp.pipex.tiscali.co.uk with SMTP; 13 May 2008 11:48:48 +0100 Message-ID: <021a01c8b4dd$ef034480$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , References: <577465F99B41C842AAFBE9ED71E70ABA308F92@grfint2.intern.adiscon.com> <020601c8b1cb$e23d3a40$0601a8c0@allison> Date: Tue, 13 May 2008 11:36:43 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] -transport-tls-12, IP addresses 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: "tom.petch" ; "Rainer Gerhards" ; Sent: Monday, May 12, 2008 6:15 AM Subject: RE: [Syslog] -transport-tls-12, IP addresses Hi Tom, How would you think this would be deployed? In order for an IP address match to be secure in most environments the IP address in the configuration of the transport sender would have to match against an IP address in a subject field within the certificate. Would it be reasonable for a syslog receiver to have a certificate issued to it that has its IP address in a subject field? yes, I do think that it would be reasonable:-) It comes back to the environment in which I see syslog, of large numbers of low function devices with little infrastructure. Gold standard security needs PKI, CRLs, (secure) DNS etc which is great for full function devices. Entry level security operates with IP addresses - which must already be known to the syslog originator - and shared certs, self-signed certs, +/- fingerprints etc so I think that IP address as an identity should be allowed. Tom Petch Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of tom.petch > Sent: Friday, May 09, 2008 4:54 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] -transport-tls-12, IP addresses > > I think that we should allow IP addresses. At the entry > level network box, I think that they are widely used. > > Tom Petch > > > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Wednesday, May 07, 2008 10:39 PM > Subject: [Syslog] -transport-tls-12, IP addresses > > > > Joe, > > > > [Editor's Note: How useful is it to match against IP > address? Do we > > expect deployments to issue certificates with IP > addresses in them? > > Are IP addresses typically used in configuration? ] > > > > I find this a tough question. In my experience, it is not > uncommon to > > configure forwarding via IP addresses instead of hostnames. > One reason > > for this is because of reliability of the logging system > when DNS is > > not (yet --> system startup) available. On the other hand, > I find it > > even a bit disturbing to have a certificate issued for an > IP address. > > But it may make sense. I personally would expect that > operators tend > > to use hostnames inside the certificate. The problem, of > course, would > > be that the configuration then needs both the name and IP address... > > > > I hope this is useful information, even though I am undecided. > > > > Rainer > > _______________________________________________ > > 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 Wed May 14 01:22:49 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 A6B693A682A; Wed, 14 May 2008 01:22:49 -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 81F953A682A for ; Wed, 14 May 2008 01:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 dPkukL47Z706 for ; Wed, 14 May 2008 01:22:45 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5DE3A6823 for ; Wed, 14 May 2008 01:22:44 -0700 (PDT) X-Trace: 26928105/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.143.35 X-SBRS: None X-RemoteIP: 62.188.143.35 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEM+Kkg+vI8j/2dsb2JhbACLU6IiBA X-IP-Direction: IN Received: from 1cust35.tnt14.lnd4.gbr.da.uu.net (HELO allison) ([62.188.143.35]) by smtp.pipex.tiscali.co.uk with SMTP; 14 May 2008 09:21:48 +0100 Message-ID: <003801c8b592$8f963e20$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , "syslog" References: <20080507150001.D3CB428C65B@core3.amsl.com><577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA308FC3@grfint2.intern.adiscon.com> Date: Wed, 14 May 2008 09:14:00 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" ; ; Sent: Tuesday, May 13, 2008 12:17 AM Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt > Hi Rainer, > > Comments below: > > > [Joe] We are not talking about HTTPS we are talking about syslog. What > applies to one may not necessarily apply to the other (HTTP provides > other ways to authenticate the client etc.). In addition HTTPS > authenticates the server in most cases. In any case, I don't think you > can claim confidentiality if you do not take care of masquerade or > man-in-the-middle as either will result in a breach of confidentiality, > you are still vulnerable to active attackers. > > I believe that implementations need to support mutual authentication and > authorization with certificates. The recommended mechanisms for this > probably still need some discussion, however I think it is important to > provide this capability. I think what is more to the point in the > current discussion is what is required by default. I would like to > suggest that server authentication, certificate path validation and > authorization be required by default, because I without this I don't > think any security goals are met. I would also suggest that by default > clients should present and authenticate with a certificate, however a > server does not necessarily need to perform path validation or > authorization, it can just record the certificate (or fingerprint) that > carries the public key used in the authentication so it can be validated > at a later time. Joe I am concerned, as I think Robert is, about the mixing of protocol and policy; the former we should define, the latter I am dubious about, seeing it as a moving target as practices change (one day we may have widespread PKI - or maybe not:-); at least we should separate it out, section 5 not section 4. I remain concerned about the number of changes proposed in -12. Reviewing -11, last November, we did discuss whether or not the I-D should give guidance on certificate management and the views I saw then said not. In fact, dbh asked what IESG-raised issues are we responding to, that is, given the status of the I-D, the only issues should be IESG ones. Then, I could answer that question, now I cannot and so wonder what drives these changes Historically, the November 2005 IETF meeting led to a proposed charter which was rejected by the IESG for lacking a mandatory-to-implement security mechanism. Our AD then guided us through developing a threat model, the rough consensus on which I believe this I-D accurately records. This led to a charter which was acceptable to the IESG. So that threat model - section 2 - for me is a given. Change that and you change the charter:-) During the discussions on threats, rough consensus emerged for TLS. There was no discussion about how authentication would be done, no discussion of how strong the security should be. The first draft of this I-D took certificates for granted but did debate the need for client-side authentication. By -11, I thought that we had a reasonable consensus and should only change what the IESG wants us to; and that I do not see. Tom Petch . > > This requires configuration on the client, but not necessarily on the > server. > > _______________________________________________ > 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 Wed May 14 05:08:21 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 31A9C3A687F; Wed, 14 May 2008 05:08:21 -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 5C3213A687F for ; Wed, 14 May 2008 05:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 tFiyoCOyXY5Q for ; Wed, 14 May 2008 05:08:18 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id E8E7D3A6867 for ; Wed, 14 May 2008 05:08:17 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id RQ6J1Z00m0S2fkCA600300; Wed, 14 May 2008 12:07:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id RQ7Q1Z00U4HwxpC8V00000; Wed, 14 May 2008 12:07:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=WWLg-UQFwiUA:10 a=hfXpDYVANRYc4cT53FwA:9 a=JAg1TsURFvh7AGnYkeUTqoxXJFEA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <1696498986EFEC4D9153717DA325CB729CB573@vaebe104.NOE.Nokia.com> Date: Wed, 14 May 2008 08:07:24 -0400 Message-ID: <070301c8b5bb$1342dd00$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1696498986EFEC4D9153717DA325CB729CB573@vaebe104.NOE.Nokia.com> Thread-Index: Aci0N7lgnIHQrINwTQGnz5RzGRCwJQBfHmZgAAFdxRA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: syslog@ietf.org Subject: Re: [Syslog] syslog/tls policies and use cases 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, So I go buy a Linksys or Netgear router or other consumer gear. I slip the CD into the drive and run software to install the management GUI on my PC. That software is used to perform an initial configuration of the device, such as enabling DHCP, setting WEP keys, and so on. This same software can presumably generate a key and "copy the fingerprint" to the device, right? Clueless operator needs not be involved. The Internet is secure. right? 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 Wed May 14 09:32: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 6837F3A6940; Wed, 14 May 2008 09:32: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 C6EC43A6940 for ; Wed, 14 May 2008 09:32:10 -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 huxyRCQ3aEco for ; Wed, 14 May 2008 09:32:09 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id A8F623A693B for ; Wed, 14 May 2008 09:32:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 7CEF67ADD63; Wed, 14 May 2008 18:26:42 +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 bRATJR6SxWkn; Wed, 14 May 2008 18:26:42 +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 4FA247ADD2D; Wed, 14 May 2008 18:26:42 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 14 May 2008 18:29:44 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FE7@grfint2.intern.adiscon.com> In-Reply-To: <070301c8b5bb$1342dd00$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] syslog/tls policies and use cases Thread-Index: Aci0N7lgnIHQrINwTQGnz5RzGRCwJQBfHmZgAAFdxRAACXflQA== References: <1696498986EFEC4D9153717DA325CB729CB573@vaebe104.NOE.Nokia.com> <070301c8b5bb$1342dd00$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , , Cc: syslog@ietf.org Subject: Re: [Syslog] syslog/tls policies and use cases 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 > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of David Harrington > Sent: Wednesday, May 14, 2008 2:07 PM > To: Pasi.Eronen@nokia.com; clonvick@cisco.com > Cc: syslog@ietf.org > Subject: Re: [Syslog] syslog/tls policies and use cases > > Hi, > > So I go buy a Linksys or Netgear router or other consumer gear. > I slip the CD into the drive and run software to install the > management GUI on my PC. > That software is used to perform an initial configuration of the > device, such as enabling DHCP, setting WEP keys, and so on. > This same software can presumably generate a key and "copy the > fingerprint" to the device, right? > Clueless operator needs not be involved. The Internet is secure. > > right? Mostly ;) What the clueless user still needs to do is 1) copy the server's fingerprint to the client 2) configure the server to accept the client's fingerprint Rainer > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > _______________________________________________ > 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 Wed May 14 11:31:53 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 352343A6940; Wed, 14 May 2008 11:31:53 -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 00D273A6940; Wed, 14 May 2008 11:31:49 -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=[AWL=0.000, 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 jY9t7un3rAon; Wed, 14 May 2008 11:31:49 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id 971C63A6781; Wed, 14 May 2008 11:31:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,487,1204498800"; d="scan'208";a="45529690" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 14 May 2008 20:30:54 +0200 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FE7@grfint2.intern.adiscon.com> To: rgerhards@hq.adiscon.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Wed, 14 May 2008 14:30:52 -0400 Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] syslog/tls policies and use cases 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 syslog-bounces@ietf.org wrote on 05/14/2008 12:29:44 PM: > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > Behalf Of David Harrington > > Sent: Wednesday, May 14, 2008 2:07 PM > > To: Pasi.Eronen@nokia.com; clonvick@cisco.com > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] syslog/tls policies and use cases > > > > Hi, > > > > So I go buy a Linksys or Netgear router or other consumer gear. > > I slip the CD into the drive and run software to install the > > management GUI on my PC. > > That software is used to perform an initial configuration of the > > device, such as enabling DHCP, setting WEP keys, and so on. > > This same software can presumably generate a key and "copy the > > fingerprint" to the device, right? > > Clueless operator needs not be involved. The Internet is secure. > > > > right? > > Mostly ;) What the clueless user still needs to do is > > 1) copy the server's fingerprint to the client > 2) configure the server to accept the client's fingerprint > Another minor correction. The dumb gear sends its certificate to the server, and gets its certificate from the server. (I would suggest by a reasonably secure means, such as https.) You then use the fingerprints to make sure that the right certificates were copied. R Horn > Rainer > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > _______________________________________________ > > 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 Wed May 14 11:49:25 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 177CC3A6842; Wed, 14 May 2008 11:49:25 -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 CAFC83A6811; Wed, 14 May 2008 11:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 aE3TxEtj3+Iq; Wed, 14 May 2008 11:49:21 -0700 (PDT) Received: from mail.hq.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by core3.amsl.com (Postfix) with ESMTP id 1C26C3A6781; Wed, 14 May 2008 11:49:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 534509C793; Wed, 14 May 2008 22:05:17 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06201-07; Wed, 14 May 2008 22:05:12 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D0D5D9C782; Wed, 14 May 2008 22:05:12 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 14 May 2008 20:48:25 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FEE@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] syslog/tls policies and use cases Thread-Index: Aci18kSZ3ouQWWI4Rb2k744CxsivGgAACtfw References: <577465F99B41C842AAFBE9ED71E70ABA308FE7@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] syslog/tls policies and use cases 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 > > > So I go buy a Linksys or Netgear router or other consumer gear. > > > I slip the CD into the drive and run software to install the > > > management GUI on my PC. > > > That software is used to perform an initial configuration of the > > > device, such as enabling DHCP, setting WEP keys, and so on. > > > This same software can presumably generate a key and "copy the > > > fingerprint" to the device, right? > > > Clueless operator needs not be involved. The Internet is secure. > > > > > > right? > > > > Mostly ;) What the clueless user still needs to do is > > > > 1) copy the server's fingerprint to the client > > 2) configure the server to accept the client's fingerprint > > > [Robert] > Another minor correction. The dumb gear sends its certificate to the > server, and gets its certificate from the server. (I would > suggest by a > reasonably secure means, such as https.) You then use the > fingerprints to > make sure that the right certificates were copied. > > R Horn [Rainer] But that, of course, requires that we specify a protocol for certificate/fingerprint exchange. The current draft does not provide this. And, to be honest, I find that is way too much "just" to get TLS protected syslog... If we do not specify a protocol for certificate copying, I can not envison how the low end device will copy certificates to e.g. syslog-ng, MonitorWare, Kiwi, rsyslog, msyslog, WinSyslog, ... They all have quite different concepts. So my conlusion is that the operator must do it - at least for the forseable future... Even if the copy *could* happen (and it can't), you still need a GUI frontend for the syslog to display and accept it. Such a GUI is uncommon for *nix syslogds. Rainer > > > Rainer > > > > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > > > > > > > > > > > _______________________________________________ > > > 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 Wed May 14 13:04:25 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 9A4653A690E; Wed, 14 May 2008 13:04:22 -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 44EF33A690E for ; Wed, 14 May 2008 13:03:45 -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 vmlAwzUFfkWl for ; Wed, 14 May 2008 13:03:37 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id B21793A6781 for ; Wed, 14 May 2008 13:03:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,488,1204498800"; d="scan'208";a="45536159" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 14 May 2008 22:02:26 +0200 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308FEE@grfint2.intern.adiscon.com> To: rgerhards@hq.adiscon.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Wed, 14 May 2008 16:02:24 -0400 Cc: syslog@ietf.org Subject: Re: [Syslog] syslog/tls policies and use cases 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 "Rainer Gerhards" wrote on 05/14/2008 02:48:25 PM: > > > > So I go buy a Linksys or Netgear router or other consumer gear. > > > > I slip the CD into the drive and run software to install the > > > > management GUI on my PC. > > > > That software is used to perform an initial configuration of the > > > > device, such as enabling DHCP, setting WEP keys, and so on. > > > > This same software can presumably generate a key and "copy the > > > > fingerprint" to the device, right? > > > > Clueless operator needs not be involved. The Internet is secure. > > > > > > > > right? > > > > > > Mostly ;) What the clueless user still needs to do is > > > > > > 1) copy the server's fingerprint to the client > > > 2) configure the server to accept the client's fingerprint > > > > > > [Robert] > > Another minor correction. The dumb gear sends its certificate to the > > server, and gets its certificate from the server. (I would > > suggest by a > > reasonably secure means, such as https.) You then use the > > fingerprints to > > make sure that the right certificates were copied. > > > > R Horn > > [Rainer] > But that, of course, requires that we specify a protocol for > certificate/fingerprint exchange. The current draft does not provide > this. And, to be honest, I find that is way too much "just" to get TLS > protected syslog... > [rjh] In practice, I do use http or https. My Linksys router speaks http. My firewall speaks http and https. Configuration micro-server and micro-browser applications are very commonplace. The dumb device micro-servers are not flexible full function servers. They are highly restricted and just for configuration purposes. At the syslog server level, you have full function browsers. I do think that we will always have people involved, but can keep the configuration simple. For the low end device I can see two viable common approaches for server configuration: 1) The operator at the server uses their browser to go to the device and copy the client certificate into a local store on the server. This can be very heavily automated by the server software or very lightly automated. I would leave the details out of this protocol level document. The dumb device can have documentation that says where the certificate will be found, and it can be described for human finding on the micro-server. The certificates can be public information and they are reasonably small. I've found it quite practical to copy them around using minimal browser and server software. All the browsers include certificate examination tools, so I use them to check certificates if I think it is justified. In most cases I don't bother because I have other reasons to believe that I've used the right certificates. The operator also copies their syslog deamon certificate to the dumb device using a browser. Again, the micro-server on the dumb device has an upload capability on the appropriate web page. The operator just clicks it, gets their local browser file selection interface, navigates to the right directory, picks their server certificate, and sends it. If you want more automation, javascript technology, ajax, etc. are quite capable of taking the same underlying "move around certificates" and presenting a very sophisticated interface. The major enabler for this would be a separate RFC that specifies the locations for the certificates. E.g., if we said there will be an "http://stupid.device.IP/syslog/my-certificate" for the device certificate, and a "http://smarter.server.IP/syslog/list-of-clients/certificate-OID" where client certificates were stored, then you could fully automate this. I do not think that the operational environment and policy ramifications are sufficiently well understood to write such an RFC at this time. I think it is reasonable to say "you will be able to copy in and out certificates". For a while we have more operator involvement, but it is just at the level of copying files to and from documented locations, perhaps with the aid of a browser and basic web pages for configuration. 2) The server just trusts everyone, and uses the certificate information or certificate to notice any changes. This can be strengthened by having a user switch for "trust only clients on the list" and "trust everyone". You start in trust only the list, get the new dumb device set up, switch to trust everyone, send a syslog message, and switch back to trust only the list. If you got more than one new client during that trust everyone period I would flag this as a problem, remove the new clients from the list, and say to the operator "try again, there were two new client attempts, not just the one." The TLS and existing client list lets you do this without interfering with traffic for the already configured clients. The decision between 1) and 2) are a policy tradeoff between installation operator cost and likelihood of failure. Option 1) also allows me to consider things like pre-configuration. In large networks we have pre-configuration servers (using LDAP and other mechanisms) where the network designer pre-configures all the equipment. Then when the physical equipment arrives, the operator just downloads the configuration. Pre-configuration is an enterprise only solution. I don't see home users or small users finding it feasible. It does do nicely for the very dumb devices that are deployed by service provider enterprises. Then the "how to install process" for the home user is actually downloading the preconfigured information and uploading relevant information. Again, this kind of high automation will make sense for enterprises, not home users, and doesn't belong in a protocol specification. I personally prefer 1), but this is on a policy basis. The protocol document should enable the implementation of either policy. R Horn > If we do not specify a protocol for certificate copying, I can not > envison how the low end device will copy certificates to e.g. syslog-ng, > MonitorWare, Kiwi, rsyslog, msyslog, WinSyslog, ... They all have quite > different concepts. So my conlusion is that the operator must do it - at > least for the forseable future... > > Even if the copy *could* happen (and it can't), you still need a GUI > frontend for the syslog to display and accept it. Such a GUI is uncommon > for *nix syslogds. > > Rainer > > > > > Rainer > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > ietfdbh@comcast.net > > > > dharrington@huawei.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Thu May 15 11:02: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 530CF3A6970; Thu, 15 May 2008 11:02: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 549703A693C for ; Thu, 15 May 2008 11:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 3KyyHfVo52-v for ; Thu, 15 May 2008 11:02:20 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id BA94C3A6888 for ; Thu, 15 May 2008 11:02:20 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id Rs1g1Z0071GXsucAA09400; Thu, 15 May 2008 18:02:15 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id Ru2B1Z0024HwxpC8T00000; Thu, 15 May 2008 18:02:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=BADePFR4w3MA:10 a=_FMh2nk8A7-pj9NjLREA:9 a=WmpYkHaHJySgUQxV94AA:7 a=P2R5pV__3fkTAXNCv5WVamCAad0A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Thu, 15 May 2008 14:02:10 -0400 Message-ID: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci2tcvqceaP6oScSc+DZiE7D64PrA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] Document shepherd report of AD concerns 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, Tom asked for a review of the IESG concerns. As document shepherd, let me address that question. This email shows the AD comments as the draft progressed since -11-. Some WG input was also taken into consideration during the document revisions. Following the publication of -11-, Sam Hartman said: "Dave, the syslog tls document is much clearer and I think it does a good job of specifying what implementations need to do. I think this is a huge improvement. However I have two major problems. 1) The default/recommended configuration requires managed trust anchors, a working DNS deployment and certificates provisioned to syslog servers. I do not find it plausible that operators will actually do this and so I do not find the specification credible. 2) The spec talks about caching of certificates in a manner similar to ssh, but does not discuss operational concerns such as key rollover. Jeff, any chance you could help the syslog working group understand the tradeoffs around leap of faith? " Jeff Hutzelman provided expert advice on behalf of Sam: "I can try. It may be worth noting that I don't think ssh talks much about server key rollover, and it certainly isn't done much in practice. What does happen is server keys changing because of a machine being reinstalled or some similar event. The approaches open to SSH in that case (prompt the user, or just notify them and fail so they can fix it and try again) don't work so well with syslog, where the originator of a message likely can't fix the problem, and the way to notify the person who can is to send a syslog message!" Then the AD token passed from Sam to Pasi, who suggested: "Here's one idea how to handle certificates for TLS in order to make it reasonably secure (in most cases), yet also deployable: - When a tranport sender configures the address of transport receiver, and enables TLS, allow the following choices: 1) configure set of trust anchors, and a name to be matched against the cert. If the transport receiver address is configured as DNS name, this name would usually be the same one. If the transport receiver address is configured as IP address, this one could be IP address (but could be also a domain name). (Note: in no situation, the result of A/AAAA or PTR lookup would be used when checking the certificate. This part of the current spec isn't correct.) 2) configure the "certificate fingerprint" of the peer (typically a 40-digit hex string). Cut-and-pasting that from one SSH window to another isn't the world's friendliest UI, but would be doable by admins, and is couple of orders of magnitude less work than setting up a real PKI. 3) configure "anything goes, don't verify the cert" (obviously, not very secure; SHOULD NOT be done) - A transport receiver would have similar choices: 1) configure set of trust anchors, and a list of names (or wildcards matching names) to be matched against the certificates; everyone listed here would be OK. 2) configure list of certificate fingerprints that are OK. 3) configure list of transport (IP) addresses/netmasks that are allowed to send messages regardless of the certificate (obviously, not very secure; SHOULD NOT be done) - I've intentionally omitted "SSH style leap of faith" (called "MAY cache the certificate presented by its peer so it can compare the certificate with what is presented in subsequent connections" in current spec). . It could be added (but has some operational issues); or we could specify slightly similar (but not quite) functionality where instead of typing in the 40-digit fingerprint, the management interface would fetch the fingerprint from the peer, show it to the administrator, and the admin would then compare it against something (e.g., what he/she sees in some other SSH window), and confirm that they match. There are some issues with this, though.... (user studies made with similar approaches show that most users click "yes, they match" even when shown two totally different values). - We probably need to require that everyone must be able to generate a keypair and self-signed certificate, and calculate/display the fingerprint of the certificate (in some management interface). Has something like this (in particular, using the fingerprint in cases where deploying PKI isn't feasible) suggested before? Do you think it would be operationally workable? If you think this might make sense, I can post something on the mailing list, too. But this is just one preliminary idea -- if there are other ideas that would solve the issues, I'm in no way saying it must be done this way." Joe did a revision which Paso reviewed, and commented: "Joe: thanks for working on this; I think we're making good progress, and I'm optimistic that we could get this draft done soon. However, some of the TLS/certificate related text in version -11 was *really*...err... unclear, so I think we need to rewrite it to some extent before taking it to the WG list (fortunately, the whole text is only two pages, so this shouldn't be too much effort). We also have an option (fingerprints) that wasn't present before, so we need to recheck the WG consensus anyway. Some proposed text fragments from me (Joe, please feel free to edit as you like): 4.2 TLS typically uses certificates to authenticate peers. Authentication and authorization of the TLS server (transport receiver) is described in Section 4.2.1; authentication and authorization of the TLS client (transport sender) is described in Section 4.2.2. 4.2.1 Server authentication/authorization The transport sender (TLS client) has three different options for authenticating and authorizing the transport receiver (TLS server): (Pasi's note: it could be sufficient is one of the following two is a MUST, and the other one is a SHOULD.) o Certification path validation and subject name verification: the client is configured with one or more trust anchors, and for each transport receiver, the name to be matched against the certificate. This option MUST be supported. o Certificate fingerprints: For each transport receiver, the client is configured with a fingerprint of the server's certificate (which can be self-signed). This option MUST be supported. o No server authentication/authorization: The client is configured to accept any certificate from the server. This option MAY be supported, but MUST NOT be enabled by default. For certification path validation, client implementations MUST provide a mechanism for configuring one or more trust anchors, and MUST perform certification path validation as specified in [RFC3280bis]. For subject name verification, client implementations MUST support configuring, for each transport receiver, the name to be matched against the certificate. This name may be the host name or IP address used when opening the TCP connection, or a distinct host name (...details of name matching...MUST support DNS names, probably others can be MAY...) To support certificate fingerprints, client implementations MUST support configuring, for each transport receiver, a fingerprint of the server certificate. See Section 4.2.3 for details. If server authentication/authorization fails, the client SHOULD log the error in some form or another (...more text...) 4.2.2 Client authentication/authorization The transport receiver (TLS server) has three different options for authenticating and authorizing the transport sender (TLS client). (Pasi's note: it could be sufficient is one of the following two is a MUST, and the other one is a SHOULD.) o Certification path validation and subject name verification: the server is configured with one or more trust anchors, and a set of names (or wildcard patterns) to be matched against the certificates. This option MUST be supported. o Certificate fingerprints: The server is configured with the fingerprints of client certificates. This option MUST be supported. o No client authentication/authorization (or authorization based only on connection source IP address): This option MAY be supported, but MUST NOT be enabled by default. Certification path validation and subject name verification work as described in Section 4.2.1 above, with following addition: (...locally configured client name can be a wildcard; different from wildcard-in-cert case...) To support certificate fingerprints, server implementations MUST support configuring with a list of fingerprints of authorized certificates. See Section 4.2.3 cor details. 4.2.3 Certificate fingerprints Both client and server implementations MUST make the certificate fingerprint available through a management interface. If no other certificate is configured, both client and server implementations MUST support generating a key pair and self-signed certificate. " and after Joe did some additioon revising, Pasi said: "I'd be interested in getting the WG's opinion on this (in particular, the fingerprint stuff) as soon as possible." At this point, Joe revised and published the draft and we brought it to the WG for comment. Hope this helps 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 Thu May 15 12:36:40 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 ACE543A6A2E; Thu, 15 May 2008 12:36:40 -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 E56313A6A2E for ; Thu, 15 May 2008 12:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.559, 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 Vj1uUAE5hjxt for ; Thu, 15 May 2008 12:36:37 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9DFA23A6A2C for ; Thu, 15 May 2008 12:36:36 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4FJaB8g028974; Thu, 15 May 2008 22:36:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 22:35:25 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 22:35:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 May 2008 22:35:24 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A13634@vaebe104.NOE.Nokia.com> In-Reply-To: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Document shepherd report of AD concerns Thread-Index: Aci2tcvqceaP6oScSc+DZiE7D64PrAAC00GQ References: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com> From: To: , X-OriginalArrivalTime: 15 May 2008 19:35:25.0600 (UTC) FILETIME=[D2C38A00:01C8B6C2] X-Nokia-AV: Clean Subject: Re: [Syslog] Document shepherd report of AD concerns 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 To add to David's email, and Tom's concern that "[we] should only change what the IESG wants us to to; and that I do not see": All the changes in version -12 were done in response to my (and earlier Sam's) AD review comments. However, based on the recent discussions, it's clear that the text isn't final yet, and needs some improvement. The intent of 4.2.1/4.2.2 was to specify a minimum level needed for interoperability, not to prevent deployments for making their own policy decisions. That minimum level can be pretty small -- and there's some room for discussing what exactly it should be -- but it must provide reasonable security for many typical syslog uses (and in this particular case, having a full-fledged PKI as the only approach isn't really a credible solution). Perhaps we could rephrase the text to make this more clear, and also explain the motivation for these requirements. Here's a first shot at that text -- feedback is welcome. To prevent disclosure of syslog message contents, the transport sender (TLS client) has to verify that it is sending the messages to an authorized transport receiver (TLS server). Typically, a client application using TLS achieves this by performing certification path validation (using previously configured trust anchors), and comparing the certificate subject name against the expected server name (or a list of authorized server names). Syslog transport senders MUST support this approach. The minimum requirements for certification path validation and subject name comparison are specified later in this section. However, syslog is frequently used in environments where assuming PKI deployment is not realistic. Thus, an alternative that provides a reasonable level of security, while being simple to deploy, is desired. This document requires that syslog transport senders MUST support a mechanism where the authorized transport receivers are identified by certificate fingerprints. The minimum requirements for this mechanism are specified in Section 4.2.3. However, these requirements are intended to specify only a minimum level of compliance required for interoperability. Implementations MAY support additional mechanisms for expressing more complex policies, validating certificates, and determining whether a certificate represents an authorized transport receiver. There can be extreme situations where it is not feasible to verify that the transport sender is communicating with an authorized transport receiver. A syslog implementation MAY provide an option to skip this verification (i.e., accept any server certificate). This option MUST NOT be enabled by default. Best regards, Pasi > -----Original Message----- > From: David Harrington > Sent: 15 May, 2008 21:02 > To: syslog@ietf.org > Subject: [Syslog] Document shepherd report of AD concerns > > Hi, > > Tom asked for a review of the IESG concerns. > As document shepherd, let me address that question. > > This email shows the AD comments as the draft progressed since -11-. > Some WG input was also taken into consideration during the document > revisions. > > Following the publication of -11-, Sam Hartman said: > "Dave, the syslog tls document is much clearer and I think it does a > good job of specifying what implementations need to do. > I think this is a huge improvement. > > However I have two major problems. > > 1) The default/recommended configuration requires managed trust > anchors, a working DNS deployment and certificates provisioned to > syslog servers. I do not find it plausible that operators will > actually do this and so I do not find the specification credible. > > 2) The spec talks about caching of certificates in a manner similar to > ssh, but does not discuss operational concerns such as key > rollover. Jeff, any chance you could help the syslog working > group understand the tradeoffs around leap of faith? > " > > Jeff Hutzelman provided expert advice on behalf of Sam: > "I can try. It may be worth noting that I don't think ssh talks much > about > server key rollover, and it certainly isn't done much in practice. > What > does happen is server keys changing because of a machine being > reinstalled > or some similar event. The approaches open to SSH in that case > (prompt the > user, or just notify them and fail so they can fix it and try again) > don't > work so well with syslog, where the originator of a message likely > can't > fix the problem, and the way to notify the person who can is to send a > > syslog message!" > > Then the AD token passed from Sam to Pasi, who suggested: > "Here's one idea how to handle certificates for TLS in order to make > it reasonably secure (in most cases), yet also deployable: > > - When a tranport sender configures the address of transport receiver, > and enables TLS, allow the following choices: > > 1) configure set of trust anchors, and a name to be matched against > the cert. If the transport receiver address is configured as DNS > name, this name would usually be the same one. If the transport > receiver address is configured as IP address, this one could > be IP address (but could be also a domain name). > > (Note: in no situation, the result of A/AAAA or PTR lookup > would be used when checking the certificate. This part of the > current spec isn't correct.) > > 2) configure the "certificate fingerprint" of the peer (typically > a 40-digit hex string). Cut-and-pasting that from one SSH window > to another isn't the world's friendliest UI, but would be doable > by admins, and is couple of orders of magnitude less work than > setting up a real PKI. > > 3) configure "anything goes, don't verify the cert" (obviously, > not very secure; SHOULD NOT be done) > > - A transport receiver would have similar choices: > > 1) configure set of trust anchors, and a list of names (or > wildcards matching names) to be matched against the > certificates; everyone listed here would be OK. > > 2) configure list of certificate fingerprints that are OK. > > 3) configure list of transport (IP) addresses/netmasks that are > allowed to send messages regardless of the certificate > (obviously, not very secure; SHOULD NOT be done) > > - I've intentionally omitted "SSH style leap of faith" (called "MAY > cache the certificate presented by its peer so it can compare the > certificate with what is presented in subsequent connections" in > current spec). . > > It could be added (but has some operational issues); or we could > specify slightly similar (but not quite) functionality where instead > of typing in the 40-digit fingerprint, the management interface > would fetch the fingerprint from the peer, show it to the > administrator, > and the admin would then compare it against something (e.g., what > he/she sees in some other SSH window), and confirm that they match. > There are some issues with this, though.... (user studies made with > similar approaches show that most users click "yes, they match" even > when shown two totally different values). > > - We probably need to require that everyone must be able to generate a > keypair and self-signed certificate, and calculate/display the > fingerprint of the certificate (in some management interface). > > Has something like this (in particular, using the fingerprint in > cases where deploying PKI isn't feasible) suggested before? Do > you think it would be operationally workable? > > If you think this might make sense, I can post something on the > mailing list, too. But this is just one preliminary idea -- if > there are other ideas that would solve the issues, I'm in no way > saying it must be done this way." > > Joe did a revision which Paso reviewed, and commented: > "Joe: thanks for working on this; I think we're making good > progress, and I'm optimistic that we could get this draft > done soon. > > However, some of the TLS/certificate related text in version -11 > was *really*...err... unclear, so I think we need to rewrite > it to some extent before taking it to the WG list (fortunately, > the whole text is only two pages, so this shouldn't be > too much effort). We also have an option (fingerprints) > that wasn't present before, so we need to recheck the WG > consensus anyway. > > Some proposed text fragments from me (Joe, please feel free > to edit as you like): > > 4.2 > > TLS typically uses certificates to authenticate > peers. Authentication and authorization of the TLS server > (transport receiver) is described in Section 4.2.1; authentication > and authorization of the TLS client (transport sender) is described > in Section 4.2.2. > > 4.2.1 Server authentication/authorization > > The transport sender (TLS client) has three different options for > authenticating and authorizing the transport receiver (TLS server): > > (Pasi's note: it could be sufficient is one of the following > two is a MUST, and the other one is a SHOULD.) > > o Certification path validation and subject name verification: the > > client is configured with one or more trust anchors, and for > each transport receiver, the name to be matched against the > certificate. This option MUST be supported. > > o Certificate fingerprints: For each transport receiver, the > client > is configured with a fingerprint of the server's certificate > (which can be self-signed). This option MUST be supported. > > o No server authentication/authorization: The client is configured > > to accept any certificate from the server. This option > MAY be supported, but MUST NOT be enabled by default. > > For certification path validation, client implementations MUST > provide a mechanism for configuring one or more trust anchors, and > MUST perform certification path validation as specified in > [RFC3280bis]. > > For subject name verification, client implementations MUST support > configuring, for each transport receiver, the name to be matched > against the certificate. This name may be the host name or IP > address used when opening the TCP connection, or a distinct host > name (...details of name matching...MUST support DNS names, > probably others can be MAY...) > > To support certificate fingerprints, client implementations MUST > support configuring, for each transport receiver, a fingerprint of > the server certificate. See Section 4.2.3 for details. > > If server authentication/authorization fails, the client SHOULD log > the error in some form or another (...more text...) > > 4.2.2 Client authentication/authorization > > The transport receiver (TLS server) has three different options for > authenticating and authorizing the transport sender (TLS client). > > (Pasi's note: it could be sufficient is one of the following > two is a MUST, and the other one is a SHOULD.) > > o Certification path validation and subject name verification: > the server is configured with one or more trust anchors, > and a set of names (or wildcard patterns) to be matched > against the certificates. This option MUST be supported. > > o Certificate fingerprints: The server is configured with the > fingerprints of client certificates. This option MUST be > supported. > > o No client authentication/authorization (or authorization > based only on connection source IP address): This option MAY > be supported, but MUST NOT be enabled by default. > > Certification path validation and subject name verification work > as described in Section 4.2.1 above, with following addition: > (...locally configured client name can be a wildcard; different > from wildcard-in-cert case...) > > To support certificate fingerprints, server implementations MUST > support configuring with a list of fingerprints of authorized > certificates. See Section 4.2.3 cor details. > > 4.2.3 Certificate fingerprints > > Both client and server implementations MUST make the certificate > fingerprint available through a management interface. If no other > certificate is configured, both client and server implementations > MUST support generating a key pair and self-signed certificate. > > this should be compatible with the way e.g. current web browsers > calculate fingerprints> " > > and after Joe did some additioon revising, Pasi said: > "I'd be interested in getting the WG's opinion on this (in > particular, the fingerprint stuff) as soon as possible." > > At this point, Joe revised and published the draft and we brought it > to the WG for comment. > > Hope this helps > > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > 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 May 15 13:22:21 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 D1B6D3A6910; Thu, 15 May 2008 13:22:21 -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 1CE6A3A6900 for ; Thu, 15 May 2008 13:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 o0ekAO1rPJqU for ; Thu, 15 May 2008 13:22:15 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 809AD3A68EC for ; Thu, 15 May 2008 13:22:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 5CD377ADB1E; Thu, 15 May 2008 22:16:34 +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 DBtqKqh1I-s5; Thu, 15 May 2008 22:16:32 +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 53B227ADADB; Thu, 15 May 2008 22:16:32 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 15 May 2008 22:22:09 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309019@grfint2.intern.adiscon.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72A13634@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Document shepherd report of AD concerns Thread-Index: Aci2tcvqceaP6oScSc+DZiE7D64PrAAC00GQAAC2PMA= References: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13634@vaebe104.NOE.Nokia.com> From: "Rainer Gerhards" To: , , Subject: Re: [Syslog] Document shepherd report of AD concerns 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 Pasi and David, Thanks for the recent clarifications. > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com > Sent: Thursday, May 15, 2008 9:35 PM > To: ietfdbh@comcast.net; syslog@ietf.org > Subject: Re: [Syslog] Document shepherd report of AD concerns > > > To add to David's email, and Tom's concern that "[we] should only > change what the IESG wants us to to; and that I do not see": > > All the changes in version -12 were done in response to my (and > earlier Sam's) AD review comments. However, based on the recent > discussions, it's clear that the text isn't final yet, and needs > some improvement. > > The intent of 4.2.1/4.2.2 was to specify a minimum level needed for > interoperability, not to prevent deployments for making their own > policy decisions. That minimum level can be pretty small -- and > there's some room for discussing what exactly it should be -- but it > must provide reasonable security for many typical syslog uses (and in > this particular case, having a full-fledged PKI as the only approach > isn't really a credible solution). > > Perhaps we could rephrase the text to make this more clear, and > also explain the motivation for these requirements. Here's a first > shot at that text -- feedback is welcome. > > To prevent disclosure of syslog message contents, the transport > sender (TLS client) has to verify that it is sending the messages > to an authorized transport receiver (TLS server). > > Typically, a client application using TLS achieves this by > performing certification path validation (using previously > configured trust anchors), and comparing the certificate subject > name against the expected server name (or a list of authorized > server names). > > Syslog transport senders MUST support this approach. The minimum > requirements for certification path validation and subject name > comparison are specified later in this section. > > However, syslog is frequently used in environments where assuming > PKI deployment is not realistic. Thus, an alternative that provides > a reasonable level of security, while being simple to deploy, is > desired. This document requires that syslog transport senders MUST > support a mechanism where the authorized transport receivers are > identified by certificate fingerprints. The minimum requirements > for this mechanism are specified in Section 4.2.3. > > However, these requirements are intended to specify only a minimum > level of compliance required for interoperability. Implementations > MAY support additional mechanisms for expressing more complex > policies, validating certificates, and determining whether a > certificate represents an authorized transport receiver. > > There can be extreme situations where it is not feasible to verify > that the transport sender is communicating with an authorized > transport receiver. A syslog implementation MAY provide an option > to skip this verification (i.e., accept any server certificate). > This option MUST NOT be enabled by default. This text is along a fine line of differences: it talks about the sender checking the server. It is the same model that HTTPS uses (sorry, but this *is* the analogy). The server is authenticated but the client not. The text is NOT talking about the server authenticating the client. Let's look at a syslog.conf line: *.* @@ Where server is the remote server's name or IP address. This is (extended) rsyslog syntax, but in essence it is the same for all implementations. What always must be configured is the name of the server. So it is quite easy to check the server identity (again, just like https) - we can simply compare the name from the cert to what was configured as . Note that this process is fully automatic if the sender ships with a set of trusted root certs (like web browsers do) and the server operator obtained a cert from one of those authorities. As I said myself, a home user is not likely to pay the associated fee, but a small biz may do. The advantage is obvious, because we have instant security without any need to configure anything (that would not be configured in any case). A server cert fingerprint requires a bit more of configuration, but can obviously be a good solution in scenarios where neiterh PKI nor paid public certs are available. If we look at the server, there is no such semi-automatic authentication available. The client can not actually be authenticated. We have a hop by hop archetecture and we have no required indication of relays inside the message. So for the server, we can not have a check if client is authentic (is who it claims it is) but instead we can just have access control - we can check if the client is permitted to send to us. IMHO this is different from verifying authenticity. In a relay chain, the relay may still receive spoofed messages from a relay in front of it. So we can not autenticate the messages themselfs but only provide access control for the machine that is connecting to us. Once we are beyond that stage, we may still receive spoofed, faked, whatever messages. We can only trust messages if all relays in the chain are configured with TLS and the same access control. For *nix based syslogds, even that does not help, because the message on the OS log socket may already be spoofed. Thus, I consider authenticating the originator or relay to the receiver (or relay) quite less important than authenticating the server to the client. This is the reason that I propose to not only split these two modes (as already happened), but have different minimal requirements for them. A useful mode to actually authenticate messages is to check the hostname provided inside the message against the clients certificate. Of course, this only work on the first hop after the originator, only if we have syslog-protcol formatted messages and is still somewhat vulnerable to local log injection in a *nix environment (there is no cure against that). If one thinks along these lines, it would be quite useful to have an additional access policy the requires a given server to accept only a given set of hostnames from a remote client (those that it is permitted to relay from). This check is probably more useful than the initial cert-based access control check because it (somewhat) protects against injecting malicious messages (somewhat, because it still depends on the full chain being properly protected, it is just easier to detect simpler attacks, what I find useful). Just my 2cts... Again, I can live with whatever we specify, because I can extend it and the current text provides good enough opportunity to switch back to anonymous authentication by a simple on/off switch (which defaults to "security on"). But I think it would be useful to get the best possible defaults. I fear that too-tight requirements are counter-productive and people will simply turn that switch to "off" instead of investigating and properly configuring. Rainer > > Best regards, > Pasi > > > -----Original Message----- > > From: David Harrington > > Sent: 15 May, 2008 21:02 > > To: syslog@ietf.org > > Subject: [Syslog] Document shepherd report of AD concerns > > > > Hi, > > > > Tom asked for a review of the IESG concerns. > > As document shepherd, let me address that question. > > > > This email shows the AD comments as the draft progressed > since -11-. > > Some WG input was also taken into consideration during the document > > revisions. > > > > Following the publication of -11-, Sam Hartman said: > > "Dave, the syslog tls document is much clearer and I think it does a > > good job of specifying what implementations need to do. > > I think this is a huge improvement. > > > > However I have two major problems. > > > > 1) The default/recommended configuration requires managed trust > > anchors, a working DNS deployment and certificates provisioned to > > syslog servers. I do not find it plausible that operators will > > actually do this and so I do not find the specification credible. > > > > 2) The spec talks about caching of certificates in a manner > similar to > > ssh, but does not discuss operational concerns such as key > > rollover. Jeff, any chance you could help the syslog working > > group understand the tradeoffs around leap of faith? > > " > > > > Jeff Hutzelman provided expert advice on behalf of Sam: > > "I can try. It may be worth noting that I don't think ssh > talks much > > about > > server key rollover, and it certainly isn't done much in practice. > > What > > does happen is server keys changing because of a machine being > > reinstalled > > or some similar event. The approaches open to SSH in that case > > (prompt the > > user, or just notify them and fail so they can fix it and try again) > > don't > > work so well with syslog, where the originator of a message likely > > can't > > fix the problem, and the way to notify the person who can > is to send a > > > > syslog message!" > > > > Then the AD token passed from Sam to Pasi, who suggested: > > "Here's one idea how to handle certificates for TLS in > order to make > > it reasonably secure (in most cases), yet also deployable: > > > > - When a tranport sender configures the address of > transport receiver, > > and enables TLS, allow the following choices: > > > > 1) configure set of trust anchors, and a name to be > matched against > > the cert. If the transport receiver address is > configured as DNS > > name, this name would usually be the same one. If the transport > > receiver address is configured as IP address, this one could > > be IP address (but could be also a domain name). > > > > (Note: in no situation, the result of A/AAAA or PTR lookup > > would be used when checking the certificate. This part of the > > current spec isn't correct.) > > > > 2) configure the "certificate fingerprint" of the peer (typically > > a 40-digit hex string). Cut-and-pasting that from one > SSH window > > to another isn't the world's friendliest UI, but would > be doable > > by admins, and is couple of orders of magnitude less work than > > setting up a real PKI. > > > > 3) configure "anything goes, don't verify the cert" (obviously, > > not very secure; SHOULD NOT be done) > > > > - A transport receiver would have similar choices: > > > > 1) configure set of trust anchors, and a list of names (or > > wildcards matching names) to be matched against the > > certificates; everyone listed here would be OK. > > > > 2) configure list of certificate fingerprints that are OK. > > > > 3) configure list of transport (IP) addresses/netmasks that are > > allowed to send messages regardless of the certificate > > (obviously, not very secure; SHOULD NOT be done) > > > > - I've intentionally omitted "SSH style leap of faith" (called "MAY > > cache the certificate presented by its peer so it can compare the > > certificate with what is presented in subsequent connections" in > > current spec). . > > > > It could be added (but has some operational issues); or we could > > specify slightly similar (but not quite) functionality > where instead > > of typing in the 40-digit fingerprint, the management interface > > would fetch the fingerprint from the peer, show it to the > > administrator, > > and the admin would then compare it against something (e.g., what > > he/she sees in some other SSH window), and confirm that > they match. > > There are some issues with this, though.... (user studies > made with > > similar approaches show that most users click "yes, they > match" even > > when shown two totally different values). > > > > - We probably need to require that everyone must be able to > generate a > > keypair and self-signed certificate, and calculate/display the > > fingerprint of the certificate (in some management interface). > > > > Has something like this (in particular, using the fingerprint in > > cases where deploying PKI isn't feasible) suggested before? Do > > you think it would be operationally workable? > > > > If you think this might make sense, I can post something on the > > mailing list, too. But this is just one preliminary idea -- if > > there are other ideas that would solve the issues, I'm in no way > > saying it must be done this way." > > > > Joe did a revision which Paso reviewed, and commented: > > "Joe: thanks for working on this; I think we're making good > > progress, and I'm optimistic that we could get this draft > > done soon. > > > > However, some of the TLS/certificate related text in version -11 > > was *really*...err... unclear, so I think we need to rewrite > > it to some extent before taking it to the WG list (fortunately, > > the whole text is only two pages, so this shouldn't be > > too much effort). We also have an option (fingerprints) > > that wasn't present before, so we need to recheck the WG > > consensus anyway. > > > > Some proposed text fragments from me (Joe, please feel free > > to edit as you like): > > > > 4.2 > > > > TLS typically uses certificates to authenticate > > peers. Authentication and authorization of the TLS server > > (transport receiver) is described in Section 4.2.1; > authentication > > and authorization of the TLS client (transport sender) > is described > > in Section 4.2.2. > > > > 4.2.1 Server authentication/authorization > > > > The transport sender (TLS client) has three different options for > > authenticating and authorizing the transport receiver > (TLS server): > > > > (Pasi's note: it could be sufficient is one of the following > > two is a MUST, and the other one is a SHOULD.) > > > > o Certification path validation and subject name > verification: the > > > > client is configured with one or more trust anchors, and for > > each transport receiver, the name to be matched against the > > certificate. This option MUST be supported. > > > > o Certificate fingerprints: For each transport receiver, the > > client > > is configured with a fingerprint of the server's certificate > > (which can be self-signed). This option MUST be supported. > > > > o No server authentication/authorization: The client is > configured > > > > to accept any certificate from the server. This option > > MAY be supported, but MUST NOT be enabled by default. > > > > For certification path validation, client implementations MUST > > provide a mechanism for configuring one or more trust > anchors, and > > MUST perform certification path validation as specified in > > [RFC3280bis]. > > > > For subject name verification, client implementations > MUST support > > configuring, for each transport receiver, the name to be matched > > against the certificate. This name may be the host name or IP > > address used when opening the TCP connection, or a distinct host > > name (...details of name matching...MUST support DNS names, > > probably others can be MAY...) > > > > To support certificate fingerprints, client implementations MUST > > support configuring, for each transport receiver, a > fingerprint of > > the server certificate. See Section 4.2.3 for details. > > > > If server authentication/authorization fails, the client > SHOULD log > > the error in some form or another (...more text...) > > > > 4.2.2 Client authentication/authorization > > > > The transport receiver (TLS server) has three different > options for > > authenticating and authorizing the transport sender (TLS client). > > > > (Pasi's note: it could be sufficient is one of the following > > two is a MUST, and the other one is a SHOULD.) > > > > o Certification path validation and subject name verification: > > the server is configured with one or more trust anchors, > > and a set of names (or wildcard patterns) to be matched > > against the certificates. This option MUST be supported. > > > > o Certificate fingerprints: The server is configured with the > > fingerprints of client certificates. This option MUST be > > supported. > > > > o No client authentication/authorization (or authorization > > based only on connection source IP address): This option MAY > > be supported, but MUST NOT be enabled by default. > > > > Certification path validation and subject name verification work > > as described in Section 4.2.1 above, with following addition: > > (...locally configured client name can be a wildcard; different > > from wildcard-in-cert case...) > > > > To support certificate fingerprints, server implementations MUST > > support configuring with a list of fingerprints of authorized > > certificates. See Section 4.2.3 cor details. > > > > 4.2.3 Certificate fingerprints > > > > Both client and server implementations MUST make the certificate > > fingerprint available through a management interface. If no other > > certificate is configured, both client and server implementations > > MUST support generating a key pair and self-signed certificate. > > > > > this should be compatible with the way e.g. current web browsers > > calculate fingerprints> " > > > > and after Joe did some additioon revising, Pasi said: > > "I'd be interested in getting the WG's opinion on this (in > > particular, the fingerprint stuff) as soon as possible." > > > > At this point, Joe revised and published the draft and we brought it > > to the WG for comment. > > > > Hope this helps > > > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > _______________________________________________ > > 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 Fri May 16 01:35:54 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 B3A6D3A6AF8; Fri, 16 May 2008 01:35:54 -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 8457D3A6AF8 for ; Fri, 16 May 2008 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 WMcZtWXuXrZI for ; Fri, 16 May 2008 01:35:52 -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 51CC33A6AF3 for ; Fri, 16 May 2008 01:35:51 -0700 (PDT) X-Trace: 81453076/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.122.133 X-SBRS: None X-RemoteIP: 62.188.122.133 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABPkLEg+vHqF/2dsb2JhbACLWKMCAw X-IronPort-AV: E=Sophos;i="4.27,496,1204502400"; d="scan'208";a="81453076" X-IP-Direction: IN Received: from 1cust133.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.133]) by smtp.pipex.tiscali.co.uk with SMTP; 16 May 2008 09:35:38 +0100 Message-ID: <002501c8b726$d1e75c60$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA308FE7@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA308FEE@grfint2.intern.adiscon.com> Date: Fri, 16 May 2008 09:29:46 +0200 MIME-Version: 1.0 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/tls policies and use cases 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Rainer I do not think that Robert or David is suggesting that we standardise this, just that this is close to what already happens when I customise an entry level box, using proprietary tools. (I have even used SNMP to do something like this, it happened to be the protocol that the manufacturer provided). So yes, I do see this as a viable way forward (but would not want to see more than a passing reference to it, or an overview, in section 5 of the I-D). If such a mechanism is to be standardised, then it should IMO be a pkix-like group, or a non-IETF one focussed on configuration. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Cc: ; Sent: Wednesday, May 14, 2008 8:48 PM Subject: Re: [Syslog] syslog/tls policies and use cases > > > > So I go buy a Linksys or Netgear router or other consumer gear. > > > > I slip the CD into the drive and run software to install the > > > > management GUI on my PC. > > > > That software is used to perform an initial configuration of the > > > > device, such as enabling DHCP, setting WEP keys, and so on. > > > > This same software can presumably generate a key and "copy the > > > > fingerprint" to the device, right? > > > > Clueless operator needs not be involved. The Internet is secure. > > > > > > > > right? > > > > > > Mostly ;) What the clueless user still needs to do is > > > > > > 1) copy the server's fingerprint to the client > > > 2) configure the server to accept the client's fingerprint > > > > > > [Robert] > > Another minor correction. The dumb gear sends its certificate to the > > server, and gets its certificate from the server. (I would > > suggest by a > > reasonably secure means, such as https.) You then use the > > fingerprints to > > make sure that the right certificates were copied. > > > > R Horn > > [Rainer] > But that, of course, requires that we specify a protocol for > certificate/fingerprint exchange. The current draft does not provide > this. And, to be honest, I find that is way too much "just" to get TLS > protected syslog... > > If we do not specify a protocol for certificate copying, I can not > envison how the low end device will copy certificates to e.g. syslog-ng, > MonitorWare, Kiwi, rsyslog, msyslog, WinSyslog, ... They all have quite > different concepts. So my conlusion is that the operator must do it - at > least for the forseable future... > > Even if the copy *could* happen (and it can't), you still need a GUI > frontend for the syslog to display and accept it. Such a GUI is uncommon > for *nix syslogds. > > Rainer > > > > > Rainer > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > ietfdbh@comcast.net > > > > dharrington@huawei.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 16 06:45:55 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 A48D13A69AB; Fri, 16 May 2008 06:45:55 -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 3D18D3A69AB for ; Fri, 16 May 2008 06:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 MHyFuPPzbxKw for ; Fri, 16 May 2008 06:45:48 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id CA0823A68FF for ; Fri, 16 May 2008 06:45:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id C55277ADCFA for ; Fri, 16 May 2008 15:45:39 +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 CdVM+V+Av0wP for ; Fri, 16 May 2008 15:45:37 +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 ADA3C7ADCD2 for ; Fri, 16 May 2008 15:45:37 +0200 (CEST) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {07455FF6-31C5-447D-AC09-52AF0E6A0CEF} Content-class: urn:content-classes:message x-cr-hashedpuzzle: S28= AQbP BBhO DEk2 Dtpu EcyQ FJhT FhFo F2pA GFfk GTnI GvOj HAm8 ITm9 I8Mc LD/t; 1; cwB5AHMAbABvAGcAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {07455FF6-31C5-447D-AC09-52AF0E6A0CEF}; cgBnAGUAcgBoAGEAcgBkAHMAQABoAHEALgBhAGQAaQBzAGMAbwBuAC4AYwBvAG0A; Fri, 16 May 2008 13:45:35 GMT; dAByAGEAbgBzAHAAbwByAHQALQB0AGwAcwAgAHYAcwAuACAAcwB5AHMAbABvAGcALQBzAGkAZwBuAA== Date: Fri, 16 May 2008 15:45:35 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309028@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transport-tls vs. syslog-sign Thread-Index: Aci3Wx4yCJZn4rAuTiSF7WEJa3jkMg== From: "Rainer Gerhards" To: Subject: [Syslog] transport-tls vs. syslog-sign 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 all, I did a cross-check today between the two drafts. Both require certificates. Syslog-sign actually includes distribution policies in section 5. There is a huge difference between the ways certificates are handled in both drafts. Implementing both will at least require duplicate/different code for like tasks. Same goes for the administration. I have not yet a solution proposal, but I would like to make the WG aware of this fact. What are your thoughts? Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 16 07:28:54 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 9A1EC3A6993; Fri, 16 May 2008 07:28:54 -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 DBC9A3A6993; Fri, 16 May 2008 07:28:52 -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=[AWL=0.000, 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 9Kjy4xIB9aiQ; Fri, 16 May 2008 07:28:52 -0700 (PDT) Received: from mornm02-out.agfa.com (mornm02-out.agfa.com [134.54.1.77]) by core3.amsl.com (Postfix) with ESMTP id 81B173A67A1; Fri, 16 May 2008 07:28:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,497,1204498800"; d="scan'208";a="40283756" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm02-out.agfa.com with ESMTP; 16 May 2008 16:28:23 +0200 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309028@grfint2.intern.adiscon.com> To: rgerhards@hq.adiscon.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Fri, 16 May 2008 10:28:20 -0400 Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] transport-tls vs. syslog-sign 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 > [Rainer] Hi all, > > I did a cross-check today between the two drafts. Both require > certificates. Syslog-sign actually includes distribution policies in > section 5. There is a huge difference between the ways certificates are > handled in both drafts. > > Implementing both will at least require duplicate/different code for > like tasks. Same goes for the administration. I have not yet a solution > proposal, but I would like to make the WG aware of this fact. > > What are your thoughts? > [RJHorn] To some degree you are describing the present state of implementation for certificate and key management. It's a mess. I expect that in the end this will generalize into: - For each different application purpose (browsing, signing, prescribing, logging, payments, ...) there will be stores for - Private key information (used locally to sign, etc.) - Trusted individual certificates (e.g., self-signed but not restricted to self-signed) - Trusted signing certificates - Anchors of Trust With luck there will emerge common maintenance methods, but they sure aren't there now. For each browser I've got a different maintenance method for trusted signers, trusted individual certificates, and private key information. I don't have any browsers that actually manage usig an anchor of trust. And that is for the single application purpose of browsing. The browsers are all different. The nature and meanings of trust is dependent on the application purpose, so you should not have a single single store. We will always need a way to have different stores for different purposes. Meanwhile, we struggle with every implementation having different maintenance methods. At least they agree on the PKCS format for exchanging these elements. I don't see syslog as the proper venue for doing more than defining use cases for this. Longer term, I hope that a common agreement emerges on how to name and organize these stores so that common maintenance can be implemented. For the specifics of sign vs transport, is there an application difference between being an authenticated sender of messages, and being an authenticated signer of messages? I think that there is, so they do need to be separate stores. I haven't looked at the details of functionality required by sign because I haven't had any real uses yet for signing the messages. The differences should be reducable to using different stores for key and certificate information, and performing different operations (e.g., signing) on the messages. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 16 08:06:57 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 913623A6B30; Fri, 16 May 2008 08:06:57 -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 D49BE28C197; Fri, 16 May 2008 08:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 oORJLiNZRuey; Fri, 16 May 2008 08:06:53 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 652743A68D2; Fri, 16 May 2008 08:06:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id C6E937AD812; Fri, 16 May 2008 17:06:36 +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 U-+GIwxe9hW2; Fri, 16 May 2008 17:06:36 +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 7418E7AD491; Fri, 16 May 2008 17:06:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 May 2008 17:06:45 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30902C@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] transport-tls vs. syslog-sign Thread-Index: Aci3Y3f480di08aZQDiECPfyxujeBAAAEeog References: <577465F99B41C842AAFBE9ED71E70ABA309028@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] transport-tls vs. syslog-sign 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 Robert, thanks again for the excellent description. My comments below... > -----Original Message----- > From: robert.horn@agfa.com [mailto:robert.horn@agfa.com] > Sent: Friday, May 16, 2008 4:28 PM > To: Rainer Gerhards > Cc: syslog@ietf.org; syslog-bounces@ietf.org > Subject: Re: [Syslog] transport-tls vs. syslog-sign > > > [Rainer] Hi all, > > > > I did a cross-check today between the two drafts. Both require > > certificates. Syslog-sign actually includes distribution policies in > > section 5. There is a huge difference between the ways certificates > are > > handled in both drafts. > > > > Implementing both will at least require duplicate/different code for > > like tasks. Same goes for the administration. I have not yet a > solution > > proposal, but I would like to make the WG aware of this fact. > > > > What are your thoughts? > > > > [RJHorn] > > To some degree you are describing the present state of implementation > for > certificate and key management. It's a mess. > > I expect that in the end this will generalize into: > > - For each different application purpose (browsing, signing, > prescribing, > logging, payments, ...) there will be stores for > - Private key information (used locally to sign, etc.) > - Trusted individual certificates (e.g., self-signed but not > restricted > to self-signed) > - Trusted signing certificates > - Anchors of Trust > > With luck there will emerge common maintenance methods, but they sure > aren't there now. For each browser I've got a different maintenance > method for trusted signers, trusted individual certificates, and > private > key information. I don't have any browsers that actually manage usig > an > anchor of trust. And that is for the single application purpose of > browsing. The browsers are all different. > > The nature and meanings of trust is dependent on the application > purpose, > so you should not have a single single store. We will always need a > way > to have different stores for different purposes. Meanwhile, we struggle > with every implementation having different maintenance methods. At > least > they agree on the PKCS format for exchanging these elements. I don't > see > syslog as the proper venue for doing more than defining use cases for > this. Longer term, I hope that a common agreement emerges on how to > name > and organize these stores so that common maintenance can be > implemented. > > For the specifics of sign vs transport, is there an application > difference > between being an authenticated sender of messages, and being an > authenticated signer of messages? I think that there is, so they do > need > to be separate stores. I haven't looked at the details of > functionality > required by sign because I haven't had any real uses yet for signing > the > messages. The differences should be reducable to using different > stores > for key and certificate information, and performing different > operations > (e.g., signing) on the messages. [Rainer] The differences I see is that between the two there are differences in what modes can be used. For example -sign -transport-tls x.509 yes yes fingerprints no yes openPgP yes no (other) yes (N/A) Also, -sign specifies how certificates are distributed (section 5.2, 5.3 among others). -transport-tls does not talk about certificate distribution. In fact, -sign focuses very much on the distribution. -sign also describes something that one could call a threat model in its security considerations (section 8). There is a strong overlap between these two. For example, -sign 8.8 is addressed in -tls 3 (confidentiality) and could be referenced as a solution. On the other hand, -tls does not spell out countermeasures found in -sign against the remaining threats. So I think it is more than just different stores. I think both drafts define the threat model, talk about authentication, and talk (or be silent) on certificate distribution. There are just a number of differences between them. As I outlined in my mail yesterday, -tls cannot really authenticate the originator. -sign can do that. -sign cannot provide confidentiality. -tls can do that. So a really secure system would need to utilize both. Then, it would at least be useful to have the same set of drafts reuse some ideas. Even the relationship between those two is not spelled out... If this inconsistency is acceptable in order to finally get things done, that's fine with me. I just wanted to make sure everybody is aware of that situation. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 16 08:16:55 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 A9E8D28C203; Fri, 16 May 2008 08:16:55 -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 223BA28C203; Fri, 16 May 2008 08:16:54 -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=[AWL=0.000, 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 K7Xs0tRW+79Q; Fri, 16 May 2008 08:16:53 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id 6CB7D28C1FD; Fri, 16 May 2008 08:16:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,498,1204498800"; d="scan'208";a="45710897" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 16 May 2008 17:16:06 +0200 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30902C@grfint2.intern.adiscon.com> To: rgerhards@hq.adiscon.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Fri, 16 May 2008 11:16:02 -0400 Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] transport-tls vs. syslog-sign 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 "Rainer Gerhards" wrote on 05/16/2008 11:06:45 AM: > > [Rainer] > The differences I see is that between the two there are differences in > what modes can be used. For example > > -sign -transport-tls > x.509 yes yes > fingerprints no yes > openPgP yes no > (other) yes (N/A) > > Also, -sign specifies how certificates are distributed (section 5.2, 5.3 > among others). -transport-tls does not talk about certificate > distribution. In fact, -sign focuses very much on the distribution. > ... > > As I outlined in my mail yesterday, -tls cannot really authenticate the > originator. -sign can do that. -sign cannot provide confidentiality. > -tls can do that. So a really secure system would need to utilize both. > Then, it would at least be useful to have the same set of drafts reuse > some ideas. Even the relationship between those two is not spelled > out... I make this distinction on authentication. -tls authenticates the sender of the message. -sign authenticates the contents and creator of the message. Both have their uses, and they are independent concepts. I find in practice that for syslog style operation I am usually satisfied with -tls plus the knowledge that the sender has done whatever is appropriate to ensure that message contents are appropriate. But, there are other syslog situations where that is not a reasonable assumption, and -sign is then needed. R Horn _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 16 08:42:44 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 ADE0C3A68D2; Fri, 16 May 2008 08:42:44 -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 379633A68F5 for ; Fri, 16 May 2008 08:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 4hjVX5K2srca for ; Fri, 16 May 2008 08:42:42 -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 5CFB03A68B2 for ; Fri, 16 May 2008 08:42:40 -0700 (PDT) X-Trace: 81705201/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.143.218 X-SBRS: None X-RemoteIP: 62.188.143.218 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8EAK5HLUg+vI/a/2dsb2JhbACLWKI6Aw X-IronPort-AV: E=Sophos;i="4.27,498,1204502400"; d="scan'208";a="81705201" X-IP-Direction: IN Received: from 1cust218.tnt14.lnd4.gbr.da.uu.net (HELO allison) ([62.188.143.218]) by smtp.pipex.tiscali.co.uk with SMTP; 16 May 2008 16:42:14 +0100 Message-ID: <030001c8b762$74c05960$0601a8c0@allison> From: "tom.petch" To: , , "syslog" References: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13634@vaebe104.NOE.Nokia.com> Date: Fri, 16 May 2008 16:37:16 +0200 MIME-Version: 1.0 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 Subject: [Syslog] Terminology was Re: Document shepherd report of AD concerns 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I think that whatever we say should use consistent terminology. 'Authorization' seems out of place. I am well familiar with it from SNMP and isms, as well as from RFC2828, and think that authentication is enough here, as it is for TLS documents and syslog-protocol. client and transport sender get used interchangeably, which I think impedes understanding. After the initial paranthetic reference to client and server in this section, I think that we should only use transport sender and transport receiver. Tom Petch ----- Original Message ----- From: To: ; Sent: Thursday, May 15, 2008 9:35 PM Subject: Re: [Syslog] Document shepherd report of AD concerns > To add to David's email, and Tom's concern that "[we] should only > change what the IESG wants us to to; and that I do not see": > > All the changes in version -12 were done in response to my (and > earlier Sam's) AD review comments. However, based on the recent > discussions, it's clear that the text isn't final yet, and needs > some improvement. > > The intent of 4.2.1/4.2.2 was to specify a minimum level needed for > interoperability, not to prevent deployments for making their own > policy decisions. That minimum level can be pretty small -- and > there's some room for discussing what exactly it should be -- but it > must provide reasonable security for many typical syslog uses (and in > this particular case, having a full-fledged PKI as the only approach > isn't really a credible solution). > > Perhaps we could rephrase the text to make this more clear, and > also explain the motivation for these requirements. Here's a first > shot at that text -- feedback is welcome. > > To prevent disclosure of syslog message contents, the transport > sender (TLS client) has to verify that it is sending the messages > to an authorized transport receiver (TLS server). > > Typically, a client application using TLS achieves this by > performing certification path validation (using previously > configured trust anchors), and comparing the certificate subject > name against the expected server name (or a list of authorized > server names). > > Syslog transport senders MUST support this approach. The minimum > requirements for certification path validation and subject name > comparison are specified later in this section. > > However, syslog is frequently used in environments where assuming > PKI deployment is not realistic. Thus, an alternative that provides > a reasonable level of security, while being simple to deploy, is > desired. This document requires that syslog transport senders MUST > support a mechanism where the authorized transport receivers are > identified by certificate fingerprints. The minimum requirements > for this mechanism are specified in Section 4.2.3. > > However, these requirements are intended to specify only a minimum > level of compliance required for interoperability. Implementations > MAY support additional mechanisms for expressing more complex > policies, validating certificates, and determining whether a > certificate represents an authorized transport receiver. > > There can be extreme situations where it is not feasible to verify > that the transport sender is communicating with an authorized > transport receiver. A syslog implementation MAY provide an option > to skip this verification (i.e., accept any server certificate). > This option MUST NOT be enabled by default. > > Best regards, > Pasi > > > -----Original Message----- > > From: David Harrington > > Sent: 15 May, 2008 21:02 > > To: syslog@ietf.org > > Subject: [Syslog] Document shepherd report of AD concerns > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 16 08:42:44 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 CE17B3A6B39; Fri, 16 May 2008 08:42:44 -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 C409F3A68B2 for ; Fri, 16 May 2008 08:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 dhEntdxX8eJr for ; Fri, 16 May 2008 08:42:42 -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 523873A68D2 for ; Fri, 16 May 2008 08:42:42 -0700 (PDT) X-Trace: 81705258/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.143.218 X-SBRS: None X-RemoteIP: 62.188.143.218 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8EAK5HLUg+vI/a/2dsb2JhbACLWKI6Aw X-IronPort-AV: E=Sophos;i="4.27,498,1204502400"; d="scan'208";a="81705258" X-IP-Direction: IN Received: from 1cust218.tnt14.lnd4.gbr.da.uu.net (HELO allison) ([62.188.143.218]) by smtp.pipex.tiscali.co.uk with SMTP; 16 May 2008 16:42:34 +0100 Message-ID: <030101c8b762$75f61a40$0601a8c0@allison> From: "tom.petch" To: , , "syslog" References: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13634@vaebe104.NOE.Nokia.com> Date: Fri, 16 May 2008 16:37:24 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] Document shepherd report of AD concerns 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Thanks for that, it does allay my concerns (back in November, I got the impression we were being discouraged from making suggestions and one of my suggestions, close to the last post on -11, was for self-signed certs with finger prints:-) I would go for self-signed cert with finger prints as the minimum acceptable, with full PKI and leap of faith as the others to mention, essentially as drafted in -12. But I do think that -12 gives the wrong impression, that the full weight of PKI, or self-generating certificates, must be born by whoever is writing the syslog daemon:-) That I think is wrong. Rather, if the box has PKI, well and good, use it, it will be there for other applications too. And, as David has suggested, the box will most likely be initially configured by a standalone laptop and that will be the one doing the generating, or provision of the trust anchors, again not just for syslog. For me, this new material belongs in 5 not 4. I think 4 as it was in -11 lays down what an implementor of syslog should do, and that the additional material belongs in 5, as policy, important to consider but the concern of another (part of the) organisation. Fundamentally, someone else should be doing this, a policies in security working group, perhaps a spinoff from pkix or tls (which I know ekr will reject out of hand:-). We are the wrong people, IMO, to be proposing resolutions to such questions; it should be being done for us by those whose primary role is security, not network management. Finally, Rainer, as ever, is doing a grand job of keeping our feet on the ground, what is realistic, but, at the time of rchartering, there were three others who said they would implement this. I would love to hear their thoughts on these very implementation-oriented issues. Tom Petch ----- Original Message ----- From: To: ; Sent: Thursday, May 15, 2008 9:35 PM Subject: Re: [Syslog] Document shepherd report of AD concerns > To add to David's email, and Tom's concern that "[we] should only > change what the IESG wants us to to; and that I do not see": > > All the changes in version -12 were done in response to my (and > earlier Sam's) AD review comments. However, based on the recent > discussions, it's clear that the text isn't final yet, and needs > some improvement. > > The intent of 4.2.1/4.2.2 was to specify a minimum level needed for > interoperability, not to prevent deployments for making their own > policy decisions. That minimum level can be pretty small -- and > there's some room for discussing what exactly it should be -- but it > must provide reasonable security for many typical syslog uses (and in > this particular case, having a full-fledged PKI as the only approach > isn't really a credible solution). > > Perhaps we could rephrase the text to make this more clear, and > also explain the motivation for these requirements. Here's a first > shot at that text -- feedback is welcome. > > To prevent disclosure of syslog message contents, the transport > sender (TLS client) has to verify that it is sending the messages > to an authorized transport receiver (TLS server). > > Typically, a client application using TLS achieves this by > performing certification path validation (using previously > configured trust anchors), and comparing the certificate subject > name against the expected server name (or a list of authorized > server names). > > Syslog transport senders MUST support this approach. The minimum > requirements for certification path validation and subject name > comparison are specified later in this section. > > However, syslog is frequently used in environments where assuming > PKI deployment is not realistic. Thus, an alternative that provides > a reasonable level of security, while being simple to deploy, is > desired. This document requires that syslog transport senders MUST > support a mechanism where the authorized transport receivers are > identified by certificate fingerprints. The minimum requirements > for this mechanism are specified in Section 4.2.3. > > However, these requirements are intended to specify only a minimum > level of compliance required for interoperability. Implementations > MAY support additional mechanisms for expressing more complex > policies, validating certificates, and determining whether a > certificate represents an authorized transport receiver. > > There can be extreme situations where it is not feasible to verify > that the transport sender is communicating with an authorized > transport receiver. A syslog implementation MAY provide an option > to skip this verification (i.e., accept any server certificate). > This option MUST NOT be enabled by default. > > Best regards, > Pasi > > > -----Original Message----- > > From: David Harrington > > Sent: 15 May, 2008 21:02 > > To: syslog@ietf.org > > Subject: [Syslog] Document shepherd report of AD concerns > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 16 09:57:57 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 855C93A680C; Fri, 16 May 2008 09:57:57 -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 95FC63A680C; Fri, 16 May 2008 09:57:56 -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 PRndrDI2EVnf; Fri, 16 May 2008 09:57:55 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id 9C5EA3A67A1; Fri, 16 May 2008 09:57:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,498,1204498800"; d="scan'208";a="45718421" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 16 May 2008 18:57:46 +0200 In-Reply-To: <030101c8b762$75f61a40$0601a8c0@allison> To: "tom.petch" MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Fri, 16 May 2008 12:57:31 -0400 Cc: syslog , syslog-bounces@ietf.org Subject: Re: [Syslog] Document shepherd report of AD concerns 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 >[tom.petch] > > Fundamentally, someone else should be doing this, a policies in > security working > group, perhaps a spinoff from pkix or tls (which I know ekr will reject out of > hand:-). We are the wrong people, IMO, to be proposing resolutions to such > questions; it should be being done for us by those whose primary role is > security, not network management. > > I wasn't part of that group, but I am part of the policy world. It makes sense for the syslog group to jointly with some policy people propose that "this is a reasonable risk analysis for the use cases that drive our protocol". The purpose of this risk analysis is the derivation of the underlying protocol requirements. But then, it is just the protocol requirements that remain normative. The risk analysis lives on for reviewers, so that they have context, and for future users so that they can assess whether their real world implementation risks are significantly different. If the real world is different, it just means that you need to re-assess whether syslog-tls will meet your needs, will need some extra mitigations, or whatever. This keeps the policy and risk assessment portion non-normative. So when I review something like this for policy I want to see the analysis, but not see it become normative. Real normative policy work does not belong in SDOs at all. It belongs in legislatures, regulatory groups, and business management. I've seen far too many efforts (past and present) where people attempt to use SDOs to bypass the public political process. They think that making it standard lets them bypass the ugly and difficult problems of dealing with the parliamentary process. It doesn't work. It just means that the standards become inconsistent with laws and regulations. That means that implementations become inconsistent. The SDO policy thought needs to reflect instead the consideration "what are the range of potential policies that will apply" and make sure that the protocol is able to support the bulk of those policies. The extra from the IESG seems to be that there be some reasonable baseline policy that is a reasonable subset of the bulk of the policies, and mandate that at least that much be supported. That's where I end up with the basic notion of having the various certificate stores, some sort of certificate store management, and protocol enforcement of certificate verification. That leaves a baseline mandatory policy assumption that there will be bidirectional certificate verification within the protocol. All the rest of policy becomes the rules around certificate stores and store management. Those don't belong in syslog standard beyond the requirement that they exist somehow. Yes, I wish there were more agreement on the policies and the resulting needs for stores and store management. I can see syslog contributing it's use cases and examples to those needs. I don't see it incorporating them into the standard, or being the right group to define them. I would not divorce the policy work completely. Most of the security policy work in SDOs has been dealing with human identity management for various authentication and authorization purposes. That is a very different application than syslog. Those use cases do not map well onto the automated machine logging application. R Horn _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Sun May 18 18:00:27 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 7E9A328C552; Sun, 18 May 2008 18:00:27 -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 AC9E73A6E07 for ; Sun, 18 May 2008 18:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_35=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 VEWX66Qz4t75 for ; Sun, 18 May 2008 18:00:20 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 8E3C43A6E05 for ; Sun, 18 May 2008 18:00:17 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id TBnG1Z00G0mlR8UA608g00; Mon, 19 May 2008 01:00:18 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id TD0F1Z0074HwxpC8X00000; Mon, 19 May 2008 01:00:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=3eE4wd4Ds5QA:10 a=33PIcei3YQYA:10 a=tIOeAW5T6Ji6E_wyu48A:9 a=8__EUUAQaO27I3m43AoA:7 a=I2BuDl3euW9JL3UwaxeTmZcT8RoA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=84tl6Pyz8z4A:10 a=1pxjJC3EenQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'syslog'" References: <030101c8b762$75f61a40$0601a8c0@allison> Date: Sun, 18 May 2008 21:00:12 -0400 Message-ID: <089901c8b94b$b4478190$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci3df8p2OlCH5k3Q3WGGffPakaRRAB05lLw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] MUST is for implementers, not users. 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, speaking as a contributor ... I do not believe we should be trying to standardize policy. Policy is a deployment issue, not an implementation issue. Our goal should be to provide a mandatory-to-implement mechanism that operators can enable if desired to protect their messages. Whether the mechanism is enabled or disabled by default is a decision that operator/purchasers should discuss with the implemeter/vendors. It should not be a requirement of the protocol, or the IESG. There are multiple environments that use syslog. I do not think it is important to solve the security of syslog messages for environments where there is no knowledgeable operator. If the operator of a SOHO device is not clueful enough to cut-and-paste a fingerprint, I doubt they are clueful enough (or motivated enough) to interpret system logs. I think the OpSec WG is a much better place to discuss policies and best current practices for logging, including default security settings. This WG should focus only on the mandatory-to-implement security mechanisms to make it possible for users to address, in a stndardized manner, security issues in system logging. MUST is for implementers, not users. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: robert.horn@agfa.com [mailto:robert.horn@agfa.com] > Sent: Friday, May 16, 2008 12:58 PM > To: tom.petch > Cc: ietfdbh@comcast.net; Pasi.Eronen@nokia.com; syslog; > syslog-bounces@ietf.org > Subject: Re: [Syslog] Document shepherd report of AD concerns > > >[tom.petch] > > > > Fundamentally, someone else should be doing this, a policies in > > security working > > group, perhaps a spinoff from pkix or tls (which I know ekr > will reject > out of > > hand:-). We are the wrong people, IMO, to be proposing > resolutions to > such > > questions; it should be being done for us by those whose > primary role is > > security, not network management. > > > > > > I wasn't part of that group, but I am part of the policy > world. It makes > sense for the syslog group to jointly with some policy people > propose that > "this is a reasonable risk analysis for the use cases that drive our > protocol". The purpose of this risk analysis is the > derivation of the > underlying protocol requirements. But then, it is just the protocol > requirements that remain normative. The risk analysis lives on for > reviewers, so that they have context, and for future users so > that they > can assess whether their real world implementation risks are > significantly > different. If the real world is different, it just means > that you need to > re-assess whether syslog-tls will meet your needs, will need > some extra > mitigations, or whatever. This keeps the policy and risk assessment > portion non-normative. So when I review something like this > for policy I > want to see the analysis, but not see it become normative. > > Real normative policy work does not belong in SDOs at all. > It belongs in > legislatures, regulatory groups, and business management. > I've seen far > too many efforts (past and present) where people attempt to > use SDOs to > bypass the public political process. They think that making > it standard > lets them bypass the ugly and difficult problems of dealing with the > parliamentary process. It doesn't work. It just means that > the standards > become inconsistent with laws and regulations. That means that > implementations become inconsistent. The SDO policy thought needs to > reflect instead the consideration "what are the range of potential > policies that will apply" and make sure that the protocol is able to > support the bulk of those policies. The extra from the IESG > seems to be > that there be some reasonable baseline policy that is a > reasonable subset > of the bulk of the policies, and mandate that at least that much be > supported. > > That's where I end up with the basic notion of having the various > certificate stores, some sort of certificate store management, and > protocol enforcement of certificate verification. That > leaves a baseline > mandatory policy assumption that there will be bidirectional > certificate > verification within the protocol. All the rest of policy becomes the > rules around certificate stores and store management. Those > don't belong > in syslog standard beyond the requirement that they exist > somehow. Yes, I > wish there were more agreement on the policies and the > resulting needs for > stores and store management. I can see syslog contributing > it's use cases > and examples to those needs. I don't see it incorporating > them into the > standard, or being the right group to define them. > > I would not divorce the policy work completely. Most of the security > policy work in SDOs has been dealing with human identity > management for > various authentication and authorization purposes. That is a very > different application than syslog. Those use cases do not > map well onto > the automated machine logging application. > > R Horn > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 19 01:07: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 D10C03A6850; Mon, 19 May 2008 01:07:38 -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 E0F593A69BB for ; Mon, 19 May 2008 01:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 Au1CBMnZThET for ; Mon, 19 May 2008 01:07:32 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5286F3A6850 for ; Mon, 19 May 2008 01:07:20 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4J86Ftu010410; Mon, 19 May 2008 03:07:05 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 11:06:26 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 11:06:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 May 2008 11:06:24 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A5347E@vaebe104.NOE.Nokia.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309019@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Document shepherd report of AD concerns Thread-Index: Aci2tcvqceaP6oScSc+DZiE7D64PrAAC00GQAAC2PMAAr8EzcA== References: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13634@vaebe104.NOE.Nokia.com> <577465F99B41C842AAFBE9ED71E70ABA309019@grfint2.intern.adiscon.com> From: To: , , X-OriginalArrivalTime: 19 May 2008 08:06:25.0739 (UTC) FILETIME=[3BF059B0:01C8B987] X-Nokia-AV: Clean Subject: Re: [Syslog] Document shepherd report of AD concerns 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 Rainer Gerhards wrote: > This text is along a fine line of differences: it talks about the > sender checking the server. It is the same model that HTTPS uses > (sorry, but this *is* the analogy). The server is authenticated but > the client not. > > The text is NOT talking about the server authenticating the client. Yes, the text was intended to clarify Section 4.2.1; Section 4.2.2 also needs similar clarifications (although as you note, the text isn't necessarily identical, and different requirements for minimal compliance could be specified). > Let's look at a syslog.conf line: > > *.* @@ > > Where server is the remote server's name or IP address. This is > (extended) rsyslog syntax, but in essence it is the same for all > implementations. What always must be configured is the name of the > server. > > So it is quite easy to check the server identity (again, just like > https) - we can simply compare the name from the cert to what was > configured as . Note that this process is fully automatic if > the sender ships with a set of trusted root certs (like web browsers > do) and the server operator obtained a cert from one of those > authorities. As I said myself, a home user is not likely to pay the > associated fee, but a small biz may do. The advantage is obvious, > because we have instant security without any need to configure > anything (that would not be configured in any case). > > A server cert fingerprint requires a bit more of configuration, but > can obviously be a good solution in scenarios where neiterh PKI nor > paid public certs are available. > > If we look at the server, there is no such semi-automatic > authentication available. The client can not actually be > authenticated. We have a hop by hop archetecture and we have no > required indication of relays inside the message. So for the server, > we can not have a check if client is authentic (is who it claims it > is) but instead we can just have access control - we can check if > the client is permitted to send to us. IMHO this is different from > verifying authenticity. In a relay chain, the relay may still > receive spoofed messages from a relay in front of it. So we can not > autenticate the messages themselfs but only provide access control > for the machine that is connecting to us. Once we are beyond that > stage, we may still receive spoofed, faked, whatever messages. We > can only trust messages if all relays in the chain are configured > with TLS and the same access control. For *nix based syslogds, even > that does not help, because the message on the OS log socket may > already be spoofed. > > Thus, I consider authenticating the originator or relay to the > receiver (or relay) quite less important than authenticating the > server to the client. > > This is the reason that I propose to not only split these two modes > (as already happened), but have different minimal requirements for > them. > > A useful mode to actually authenticate messages is to check the > hostname provided inside the message against the clients > certificate. Of course, this only work on the first hop after the > originator, only if we have syslog-protcol formatted messages and is > still somewhat vulnerable to local log injection in a *nix > environment (there is no cure against that). If one thinks along > these lines, it would be quite useful to have an additional access > policy the requires a given server to accept only a given set of > hostnames from a remote client (those that it is permitted to relay > from). This check is probably more useful than the initial > cert-based access control check because it (somewhat) protects > against injecting malicious messages (somewhat, because it still > depends on the full chain being properly protected, it is just > easier to detect simpler attacks, what I find useful). So far, the security checks in -transport-tls draft have been solely at the *transport* level, and not concerned with the contents of the message. (The security considerations text needs to explicitly say this, though -- currently, it doesn't.) Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 19 01:34:45 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 EF6E73A6AA4; Mon, 19 May 2008 01:34:44 -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 DBA3D28C136 for ; Mon, 19 May 2008 01:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_35=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 oXHIAepzVW6x for ; Mon, 19 May 2008 01:34:43 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E26113A6861 for ; Mon, 19 May 2008 01:34:42 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4J8Wv6b005902; Mon, 19 May 2008 03:34:37 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 11:34:27 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 11:34:27 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 May 2008 11:34:25 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A53500@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Document shepherd report of AD concerns Thread-Index: Aci3df/fv9kzp8M3Rt6hSBuImU1MOACEr6vQ References: <030101c8b762$75f61a40$0601a8c0@allison> From: To: X-OriginalArrivalTime: 19 May 2008 08:34:27.0325 (UTC) FILETIME=[263E02D0:01C8B98B] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Document shepherd report of AD concerns 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 Robert, We're not attempting to specify policies that deployments are required to use; we're specifying minimal requirements for management interfaces to allow interoperability. Such work does belong in the IETF. Best regards, Pasi > -----Original Message----- > From: ext robert.horn@agfa.com [mailto:robert.horn@agfa.com] > Sent: 16 May, 2008 19:58 > To: tom.petch > Cc: ietfdbh@comcast.net; Eronen Pasi (Nokia-NRC/Helsinki); > syslog; syslog-bounces@ietf.org > Subject: Re: [Syslog] Document shepherd report of AD concerns > > >[tom.petch] > > > > Fundamentally, someone else should be doing this, a policies in > > security working group, perhaps a spinoff from pkix or tls (which > > I know ekr will reject out of hand:-). We are the wrong people, > > IMO, to be proposing resolutions to such questions; it should be > > being done for us by those whose primary role is security, not > > network management. > > > > > > I wasn't part of that group, but I am part of the policy world. It > makes sense for the syslog group to jointly with some policy people > propose that "this is a reasonable risk analysis for the use cases > that drive our protocol". The purpose of this risk analysis is the > derivation of the underlying protocol requirements. But then, it is > just the protocol requirements that remain normative. The risk > analysis lives on for reviewers, so that they have context, and for > future users so that they can assess whether their real world > implementation risks are significantly different. If the real world > is different, it just means that you need to re-assess whether > syslog-tls will meet your needs, will need some extra mitigations, > or whatever. This keeps the policy and risk assessment portion > non-normative. So when I review something like this for policy I > want to see the analysis, but not see it become normative. > > Real normative policy work does not belong in SDOs at all. It > belongs in legislatures, regulatory groups, and business management. > I've seen far too many efforts (past and present) where people > attempt to use SDOs to bypass the public political process. They > think that making it standard lets them bypass the ugly and > difficult problems of dealing with the parliamentary process. It > doesn't work. It just means that the standards become inconsistent > with laws and regulations. That means that implementations become > inconsistent. The SDO policy thought needs to reflect instead the > consideration "what are the range of potential policies that will > apply" and make sure that the protocol is able to support the bulk > of those policies. The extra from the IESG seems to be that there > be some reasonable baseline policy that is a reasonable subset of > the bulk of the policies, and mandate that at least that much be > supported. > > That's where I end up with the basic notion of having the various > certificate stores, some sort of certificate store management, and > protocol enforcement of certificate verification. That leaves a > baseline mandatory policy assumption that there will be > bidirectional certificate verification within the protocol. All the > rest of policy becomes the rules around certificate stores and store > management. Those don't belong in syslog standard beyond the > requirement that they exist somehow. Yes, I wish there were more > agreement on the policies and the resulting needs for stores and > store management. I can see syslog contributing it's use cases and > examples to those needs. I don't see it incorporating them into the > standard, or being the right group to define them. > > I would not divorce the policy work completely. Most of the > security policy work in SDOs has been dealing with human identity > management for various authentication and authorization purposes. > That is a very different application than syslog. Those use cases > do not map well onto the automated machine logging application. > > R Horn _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 19 14:31: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 19B4C3A6B2C; Mon, 19 May 2008 14:31: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 6FEAB3A6B2C for ; Mon, 19 May 2008 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 tGcDdPRMzOjM for ; Mon, 19 May 2008 14:31:37 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 780743A6B1E for ; Mon, 19 May 2008 14:31:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id F35AA7AD9A5 for ; Mon, 19 May 2008 23:31:34 +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 SXjpEIRQmOLs for ; Mon, 19 May 2008 23:31:34 +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 AA11F7AD87B for ; Mon, 19 May 2008 23:31:34 +0200 (CEST) Received: from 172.19.0.6 ([172.19.0.6]) by grfint2.intern.adiscon.com ([172.19.0.6]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 May 2008 21:31:34 +0000 MIME-Version: 1.0 From: "Rainer Gerhards" Message-ID: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> Date: Mon, 19 May 2008 23:30:48 +0200 Importance: normal X-Priority: 3 To: Thread-Topic: Fingerprint/handshake Thread-Index: Aci597ZxZLhWgaMcSke8NLzWgHaUOA== Subject: [Syslog] Fingerprint/handshake 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 Quick question: must the fingerprint check be done as part of the TLS handshake? Or must (can?) it be done after the handshake completed? From the draft i got the impression it must be done inside the handshake and handshake must fail if fingerprint auth fails. A clarification would be most appreciated. Thanks, rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue May 20 02:51:35 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 909963A6BC2; Tue, 20 May 2008 02:51:35 -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 2170B28C150 for ; Tue, 20 May 2008 02:51:34 -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 EHZJVcziO6pw for ; Tue, 20 May 2008 02:51:32 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 48E193A69ED for ; Tue, 20 May 2008 02:51:31 -0700 (PDT) X-Trace: 118739325/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.130.111 X-SBRS: None X-RemoteIP: 62.188.130.111 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACA8Mkg+vIJv/2dsb2JhbACLYKIkAw X-IronPort-AV: E=Sophos;i="4.27,515,1204502400"; d="scan'208";a="118739325" X-IP-Direction: IN Received: from 1cust111.tnt1.lnd4.gbr.da.uu.net (HELO allison) ([62.188.130.111]) by smtp.pipex.tiscali.co.uk with SMTP; 20 May 2008 10:51:16 +0100 Message-ID: <007501c8ba56$08f225a0$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" References: <577465F99B41C842AAFBE9ED71E70ABA309028@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA30902C@grfint2.intern.adiscon.com> Date: Tue, 20 May 2008 10:43:43 +0200 MIME-Version: 1.0 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] transport-tls vs. syslog-sign 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Rainer I am uncomfortable with the statement that TLS cannot authenticate the originator. It is true insofar as TLS is transport level and so cannot authenticate the message origin but I think that you are suggesting more than that. The fact that when relays are involved, it only authenticates the last hop is worth a mention, but for me is not relevant. I see (or don't see:-) relays as rare and esoteric so security that works well in their absence is still very good security (for me). I appreciate that for others, relays are essential. Also, I can conceive of the initial hops being in a trusted location so that it is only the final hop where security is of concern, so even with relays, TLS may provide security just where it is needed. And, if the topology is the other way round, where it is the latter hops which are in a trusted location - which seems to me less likely - then it is the first hop that needs the security in which case it is the first relay that needs to perform the certificate check. Whatever, I do see the checking of the authenticity of the client as important, in fact as the most important part of this I-D. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Cc: ; Sent: Friday, May 16, 2008 5:06 PM Subject: Re: [Syslog] transport-tls vs. syslog-sign > Hi Robert, > > thanks again for the excellent description. My comments below... > > > -----Original Message----- > > From: robert.horn@agfa.com [mailto:robert.horn@agfa.com] > > Sent: Friday, May 16, 2008 4:28 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org; syslog-bounces@ietf.org > > Subject: Re: [Syslog] transport-tls vs. syslog-sign > > > > > [Rainer] Hi all, > > > > > > I did a cross-check today between the two drafts. Both require > > > certificates. Syslog-sign actually includes distribution policies in > > > section 5. There is a huge difference between the ways certificates > > are > > > handled in both drafts. > > > > > > Implementing both will at least require duplicate/different code for > > > like tasks. Same goes for the administration. I have not yet a > > solution > > > proposal, but I would like to make the WG aware of this fact. > > > > > > What are your thoughts? > > > > > > > [RJHorn] > > > > To some degree you are describing the present state of implementation > > for > > certificate and key management. It's a mess. > > > > I expect that in the end this will generalize into: > > > > - For each different application purpose (browsing, signing, > > prescribing, > > logging, payments, ...) there will be stores for > > - Private key information (used locally to sign, etc.) > > - Trusted individual certificates (e.g., self-signed but not > > restricted > > to self-signed) > > - Trusted signing certificates > > - Anchors of Trust > > > > With luck there will emerge common maintenance methods, but they sure > > aren't there now. For each browser I've got a different maintenance > > method for trusted signers, trusted individual certificates, and > > private > > key information. I don't have any browsers that actually manage usig > > an > > anchor of trust. And that is for the single application purpose of > > browsing. The browsers are all different. > > > > The nature and meanings of trust is dependent on the application > > purpose, > > so you should not have a single single store. We will always need a > > way > > to have different stores for different purposes. Meanwhile, we > struggle > > with every implementation having different maintenance methods. At > > least > > they agree on the PKCS format for exchanging these elements. I don't > > see > > syslog as the proper venue for doing more than defining use cases for > > this. Longer term, I hope that a common agreement emerges on how to > > name > > and organize these stores so that common maintenance can be > > implemented. > > > > For the specifics of sign vs transport, is there an application > > difference > > between being an authenticated sender of messages, and being an > > authenticated signer of messages? I think that there is, so they do > > need > > to be separate stores. I haven't looked at the details of > > functionality > > required by sign because I haven't had any real uses yet for signing > > the > > messages. The differences should be reducable to using different > > stores > > for key and certificate information, and performing different > > operations > > (e.g., signing) on the messages. > > [Rainer] > The differences I see is that between the two there are differences in > what modes can be used. For example > > -sign -transport-tls > x.509 yes yes > fingerprints no yes > openPgP yes no > (other) yes (N/A) > > Also, -sign specifies how certificates are distributed (section 5.2, 5.3 > among others). -transport-tls does not talk about certificate > distribution. In fact, -sign focuses very much on the distribution. > > -sign also describes something that one could call a threat model in its > security considerations (section 8). There is a strong overlap between > these two. For example, -sign 8.8 is addressed in -tls 3 > (confidentiality) and could be referenced as a solution. On the other > hand, -tls does not spell out countermeasures found in -sign against the > remaining threats. > > So I think it is more than just different stores. I think both drafts > define the threat model, talk about authentication, and talk (or be > silent) on certificate distribution. There are just a number of > differences between them. > > As I outlined in my mail yesterday, -tls cannot really authenticate the > originator. -sign can do that. -sign cannot provide confidentiality. > -tls can do that. So a really secure system would need to utilize both. > Then, it would at least be useful to have the same set of drafts reuse > some ideas. Even the relationship between those two is not spelled > out... > > If this inconsistency is acceptable in order to finally get things done, > that's fine with me. I just wanted to make sure everybody is aware of > that situation. > > Rainer > _______________________________________________ > 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 Wed May 21 10:54: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 C7F1028C1D9; Wed, 21 May 2008 10:54: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 6CC253A6938; Wed, 21 May 2008 10:54:38 -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 AgFI3pb-CI1p; Wed, 21 May 2008 10:54:37 -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 3FD3328C208; Wed, 21 May 2008 10:54:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,521,1204531200"; d="scan'208";a="48924390" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 21 May 2008 10:54:41 -0700 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 m4LHsffm031373; Wed, 21 May 2008 10:54:41 -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 m4LHsfqj001169; Wed, 21 May 2008 17:54:41 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); Wed, 21 May 2008 10:54:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 May 2008 10:54:40 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB05BE1AEE@xmb-sjc-236.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] transport-tls vs. syslog-sign Thread-Index: Aci3aDqwZnGZQ3yJSNCCSHMXpPIyTwEAn4+w References: <577465F99B41C842AAFBE9ED71E70ABA30902C@grfint2.intern.adiscon.com> From: "Alexander Clemm (alex)" To: , X-OriginalArrivalTime: 21 May 2008 17:54:41.0511 (UTC) FILETIME=[BEAF3F70:01C8BB6B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2439; t=1211392481; x=1212256481; 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]=20transport-tls=20vs.=20syslog -sign |Sender:=20; bh=KV6gZPBxyNNrMCh52+zm3JilxyrtIjImcSRLEBgFpb4=; b=Y2MFhmoUbrJXesyk2uwa1M2QSVKqG6cD//AUvJQa+2N6ejGe5+ByEyWdxr 00PuEHAMvesqNCzGnF5w2zDebsdhrZxSDHu10HodwCBVQHhiVvIjGvzikldA 1kRCuSPuvq; Authentication-Results: sj-dkim-3; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] transport-tls vs. syslog-sign 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 I agree it might be a good idea to spell out the relationship between the two. We can add a section to syslog-sign, or presumably add a section to both that "mirror" each other. Both have different uses, so I am not sure how much effort should be spent beyond that - I am concerned despite the best intentions, it might turn out to not be really helpful in the end and merely slow things down. --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of robert.horn@agfa.com Sent: Friday, May 16, 2008 8:16 AM To: rgerhards@hq.adiscon.com Cc: syslog@ietf.org; syslog-bounces@ietf.org Subject: Re: [Syslog] transport-tls vs. syslog-sign "Rainer Gerhards" wrote on 05/16/2008 11:06:45 AM: > > [Rainer] > The differences I see is that between the two there are differences in > what modes can be used. For example > > -sign -transport-tls > x.509 yes yes > fingerprints no yes > openPgP yes no > (other) yes (N/A) > > Also, -sign specifies how certificates are distributed (section 5.2, 5.3 > among others). -transport-tls does not talk about certificate > distribution. In fact, -sign focuses very much on the distribution. > ... > > As I outlined in my mail yesterday, -tls cannot really authenticate the > originator. -sign can do that. -sign cannot provide confidentiality. > -tls can do that. So a really secure system would need to utilize both. > Then, it would at least be useful to have the same set of drafts reuse > some ideas. Even the relationship between those two is not spelled > out... I make this distinction on authentication. -tls authenticates the sender of the message. -sign authenticates the contents and creator of the message. Both have their uses, and they are independent concepts. I find in practice that for syslog style operation I am usually satisfied with -tls plus the knowledge that the sender has done whatever is appropriate to ensure that message contents are appropriate. But, there are other syslog situations where that is not a reasonable assumption, and -sign is then needed. R Horn _______________________________________________ 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 May 22 23:30: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 0BF0A28C1E0; Thu, 22 May 2008 23:30:04 -0700 (PDT) X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6A40E3A6C58; Thu, 22 May 2008 23:30: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: <20080523063001.6A40E3A6C58@core3.amsl.com> Date: Thu, 22 May 2008 23:30:01 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-tc-mib-08.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 : Textual Conventions for Syslog Management Author(s) : G. Mansfield Filename : draft-ietf-syslog-tc-mib-08.txt Pages : 16 Date : 2008-05-22 This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-08.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-tc-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-22232328.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 Thu May 22 23:44:51 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 87E283A6C54; Thu, 22 May 2008 23:44:51 -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 3C06D3A69AA for ; Thu, 22 May 2008 23:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 puIwVJKOpOPP for ; Thu, 22 May 2008 23:44:49 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id C658D28C217 for ; Thu, 22 May 2008 23:44:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id B09FB7AD812 for ; Fri, 23 May 2008 08:44:06 +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 2SRrebCzcV4O for ; Fri, 23 May 2008 08:44:06 +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 776F07AD7FE for ; Fri, 23 May 2008 08:44:06 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 May 2008 08:44:04 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30907A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fingerprint vs PSK Thread-Index: Aci8oGRObqEB2pUTRk6FebVbBeIPng== From: "Rainer Gerhards" To: Subject: [Syslog] fingerprint vs PSK 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 all, in my implementation effort (now mostly completed), I asked several people for advise on implementing fingerprints. In almost all cases the initial reply was "why use non-standard fingerprints when we have PSK"? I know that RFC 4279 in section 1.1 says: If the main goal is to avoid Public-Key Infrastructures (PKIs), another possibility worth considering is using self-signed certificates with public key fingerprints. Instead of manually configuring a shared secret in, for instance, some configuration file, a fingerprint (hash) of the other party's public key (or certificate) could be placed there instead. However, I think it would be useful to add some short text why fingerprints are more desirable. And the real question is: are they actually more desirable? Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 23 01:08: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 C4F9B3A69FC; Fri, 23 May 2008 01:08: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 6A2EF3A69FC for ; Fri, 23 May 2008 01:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 aWKq-rKM2f+B for ; Fri, 23 May 2008 01:08:46 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D363E3A6912 for ; Fri, 23 May 2008 01:08:45 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4N87sRb000816; Fri, 23 May 2008 11:08:39 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 May 2008 11:08:25 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 May 2008 11:08:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 11:08:24 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72B35DF7@vaebe104.NOE.Nokia.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30907A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] fingerprint vs PSK Thread-Index: Aci8oGRObqEB2pUTRk6FebVbBeIPngACbyLA References: <577465F99B41C842AAFBE9ED71E70ABA30907A@grfint2.intern.adiscon.com> From: To: , X-OriginalArrivalTime: 23 May 2008 08:08:25.0411 (UTC) FILETIME=[2CEBD930:01C8BCAC] X-Nokia-AV: Clean Subject: Re: [Syslog] fingerprint vs PSK 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 If you have one transport sender and one transport receiver, there's probably no big difference (except that most TLS implementations, at least in their official releases, don't support RFC 4279 yet). If you have a large number of transport senders, things get different. Especially if you're satisfied with authenticating only the server, PSKs would mean more administrative work (when new clients are added), since it has to be configured on both ends (while the server fingerprint needs to be configured only on the new client -- and since it's not secret, you can e.g. put it in your installation scripts or instructions). (That said, it's clear that fingerprints are not the *only* possible solution here -- but I'd really like to pick one option that's good enough and get this document published, rather than spend lot of time analyzing all the possible solutions.) Best regards, Pasi > -----Original Message----- > From: ext Rainer Gerhards > Sent: 23 May, 2008 09:44 > To: syslog@ietf.org > Subject: [Syslog] fingerprint vs PSK > > Hi all, > > in my implementation effort (now mostly completed), I asked several > people for advise on implementing fingerprints. In almost all > cases the > initial reply was "why use non-standard fingerprints when we > have PSK"? > I know that RFC 4279 in section 1.1 says: > > If the main goal is to avoid Public-Key Infrastructures (PKIs), > another possibility worth considering is using self-signed > certificates with public key fingerprints. Instead of manually > configuring a shared secret in, for instance, some configuration > file, a fingerprint (hash) of the other party's public key (or > certificate) could be placed there instead. > > However, I think it would be useful to add some short text why > fingerprints are more desirable. And the real question is: are they > actually more desirable? > > Rainer > _______________________________________________ > 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 Fri May 23 01:16:46 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 B9C263A6BB8; Fri, 23 May 2008 01:16:46 -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 7E06D3A6BB0 for ; Fri, 23 May 2008 01:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 nW1xrqClaXK9 for ; Fri, 23 May 2008 01:16:44 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 4BBD13A6996 for ; Fri, 23 May 2008 01:16:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id AB5827ADAA1; Fri, 23 May 2008 10:16:39 +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 Xrj7ElDUD072; Fri, 23 May 2008 10:16:39 +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 4F04F7AD959; Fri, 23 May 2008 10:16:39 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 23 May 2008 10:16:38 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30907F@grfint2.intern.adiscon.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72B35DF7@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] fingerprint vs PSK Thread-Index: Aci8oGRObqEB2pUTRk6FebVbBeIPngACbyLAAAC4ExA= References: <577465F99B41C842AAFBE9ED71E70ABA30907A@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB72B35DF7@vaebe104.NOE.Nokia.com> From: "Rainer Gerhards" To: , Subject: Re: [Syslog] fingerprint vs PSK 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 Pasi, inline... > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Friday, May 23, 2008 10:08 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] fingerprint vs PSK > > > If you have one transport sender and one transport receiver, there's > probably no big difference (except that most TLS implementations, > at least in their official releases, don't support RFC 4279 yet). A very good point indeed. > If you have a large number of transport senders, things get different. > Especially if you're satisfied with authenticating only the server, > PSKs would mean more administrative work (when new clients are added), > since it has to be configured on both ends (while the server > fingerprint needs to be configured only on the new client -- and since > it's not secret, you can e.g. put it in your installation scripts or > instructions). > > (That said, it's clear that fingerprints are not the *only* possible > solution here -- but I'd really like to pick one option that's > good enough and get this document published, rather than spend > lot of time analyzing all the possible solutions.) > Thanks for the explanation. I agree to one good enough solution is fine. I would suggest to add a few sentences on the reasoning to the ID. Rainer > Best regards, > Pasi > > > -----Original Message----- > > From: ext Rainer Gerhards > > Sent: 23 May, 2008 09:44 > > To: syslog@ietf.org > > Subject: [Syslog] fingerprint vs PSK > > > > Hi all, > > > > in my implementation effort (now mostly completed), I asked several > > people for advise on implementing fingerprints. In almost all > > cases the > > initial reply was "why use non-standard fingerprints when we > > have PSK"? > > I know that RFC 4279 in section 1.1 says: > > > > If the main goal is to avoid Public-Key Infrastructures (PKIs), > > another possibility worth considering is using self-signed > > certificates with public key fingerprints. Instead of manually > > configuring a shared secret in, for instance, some configuration > > file, a fingerprint (hash) of the other party's public key (or > > certificate) could be placed there instead. > > > > However, I think it would be useful to add some short text why > > fingerprints are more desirable. And the real question is: are they > > actually more desirable? > > > > Rainer > > _______________________________________________ > > 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 Fri May 23 04:22:31 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 A69B03A6C84; Fri, 23 May 2008 04:22:31 -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 44F323A6BCE for ; Fri, 23 May 2008 04:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GXH1akUjoi1f for ; Fri, 23 May 2008 04:22:29 -0700 (PDT) Received: from ext-ch1gw-7.online-age.net (ext-ch1gw-7.online-age.net [64.37.194.15]) by core3.amsl.com (Postfix) with ESMTP id 67E9A3A6C85 for ; Fri, 23 May 2008 04:22:29 -0700 (PDT) Received: from int-ch1gw-5.online-age.net (int-ch1gw-5 [3.159.232.69]) by ext-ch1gw-7.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id m4NBMQQ4030821 for ; Fri, 23 May 2008 07:22:28 -0400 Received: from cinmlef08.e2k.ad.ge.com (int-ch1gw-5 [3.159.232.69]) by int-ch1gw-5.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id m4NBMOSO012584 for ; Fri, 23 May 2008 07:22:25 -0400 (EDT) Received: from ALPMLVEM05.e2k.ad.ge.com ([3.159.17.55]) by cinmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 23 May 2008 07:22:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 07:22:21 -0400 Message-ID: <124CF5A7D55D6F43A4FD9437F28254D8E9B700@ALPMLVEM05.e2k.ad.ge.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30907A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] fingerprint vs PSK Thread-Index: Aci8oGRObqEB2pUTRk6FebVbBeIPngAJfizw References: <577465F99B41C842AAFBE9ED71E70ABA30907A@grfint2.intern.adiscon.com> From: "Moehrke, John (GE Healthcare)" To: X-OriginalArrivalTime: 23 May 2008 11:22:24.0520 (UTC) FILETIME=[465EF080:01C8BCC7] Subject: Re: [Syslog] fingerprint vs PSK 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 Great question... No they are not... You can still use certificates without needing an expensive PKI. Self-signed certificates managed manually (trust). Rob and I keep trying to tell you this, and we have provided white papers explaining scalability and management methods. I recommend that you do NOT invent something special for syslog. Choose certificates and be done. John > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf > Of Rainer Gerhards > Sent: Friday, May 23, 2008 1:44 AM > To: syslog@ietf.org > Subject: [Syslog] fingerprint vs PSK > > Hi all, > > in my implementation effort (now mostly completed), I asked several > people for advise on implementing fingerprints. In almost all cases the > initial reply was "why use non-standard fingerprints when we have PSK"? > I know that RFC 4279 in section 1.1 says: > > If the main goal is to avoid Public-Key Infrastructures (PKIs), > another possibility worth considering is using self-signed > certificates with public key fingerprints. Instead of manually > configuring a shared secret in, for instance, some configuration > file, a fingerprint (hash) of the other party's public key (or > certificate) could be placed there instead. > > However, I think it would be useful to add some short text why > fingerprints are more desirable. And the real question is: are they > actually more desirable? > > Rainer > _______________________________________________ > 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 Fri May 23 09: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 709AF3A6CBF; Fri, 23 May 2008 09: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 69A6E3A6CBF for ; Fri, 23 May 2008 09:27:25 -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 J79twun2YB-Y for ; Fri, 23 May 2008 09:27:24 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id B49CE3A6B95 for ; Fri, 23 May 2008 09:27:24 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 081DEFAB863; Fri, 23 May 2008 09:27:22 -0700 (PDT) Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Fri, 23 May 2008 09:27:24 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 23 May 2008 09:27:24 -0700 Message-Id: <59D6C5FB-88A1-453D-B06D-7CC42293468A@callas.org> From: Jon Callas To: "Moehrke, John (GE Healthcare)" In-Reply-To: <124CF5A7D55D6F43A4FD9437F28254D8E9B700@ALPMLVEM05.e2k.ad.ge.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 23 May 2008 09:27:18 -0700 References: <577465F99B41C842AAFBE9ED71E70ABA30907A@grfint2.intern.adiscon.com> <124CF5A7D55D6F43A4FD9437F28254D8E9B700@ALPMLVEM05.e2k.ad.ge.com> X-Mailer: Apple Mail (2.919.2) Cc: syslog@ietf.org Subject: Re: [Syslog] fingerprint vs PSK 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 On May 23, 2008, at 4:22 AM, Moehrke, John (GE Healthcare) wrote: > Great question... No they are not... You can still use certificates > without needing an expensive PKI. Self-signed certificates managed > manually (trust). Rob and I keep trying to tell you this, and we have > provided white papers explaining scalability and management methods. I > recommend that you do NOT invent something special for syslog. Choose > certificates and be done. Let me agree and add that you can also set up your own private PKI, which I mean to be different in that you spin your own root and the root signs the other certs. That way, they're not self-signed -- they descend from a root, it's just your root. Jon _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 23 11:19: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 52E1828C278; Fri, 23 May 2008 11:19: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 2DC2728C2F9 for ; Fri, 23 May 2008 11:19:53 -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 QYS++m0VD6bJ for ; Fri, 23 May 2008 11:19:51 -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 30F4F28C313 for ; Fri, 23 May 2008 11:19:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,531,1204531200"; d="scan'208";a="71790863" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 May 2008 11:19:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4NIJiOb007228; Fri, 23 May 2008 11:19:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m4NIJiZj015476; Fri, 23 May 2008 18:19:44 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 May 2008 11:19:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 11:20:30 -0700 Message-ID: In-Reply-To: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Fingerprint/handshake Thread-Index: Aci597ZxZLhWgaMcSke8NLzWgHaUOAABInCQ References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 23 May 2008 18:19:44.0429 (UTC) FILETIME=[9351D5D0:01C8BD01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1172; t=1211566784; x=1212430784; 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]=20Fingerprint/handshake |Sender:=20; bh=tpomNV1A82IxdbiE1f688WQFue+nXqQiB8bRkJNkRHM=; b=X5jQjvhOJrsxEfZylGMSr3YiTz8HmrPzJamxfblV6VIqlKbaFsJdun+WHA 1VQ7AMtIVqI5GQ6f9o+YYNaLREFwsC6hd5AmE7cyanBjtS0suniGky9VR/Sa RrHIuR+PpDlvtAWo/lRxs3nTzipivXS+N0vCT3+sHCWezY2rJiFhU=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] Fingerprint/handshake 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 The fingerprint check should be done where certificate validation would be done. This is typically done within the handshake itself, because if the validation fails you do not want to send or receive data on the connection. I suppose you could implement the check after the handshake, but you need to make sure you do not send or receive application before successful validation has occurred. Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, May 19, 2008 2:31 PM > To: syslog@ietf.org > Subject: [Syslog] Fingerprint/handshake > > Quick question: must the fingerprint check be done as part of > the TLS handshake? Or must (can?) it be done after the > handshake completed? > > From the draft i got the impression it must be done inside > the handshake and handshake must fail if fingerprint auth fails. > > A clarification would be most appreciated. > > Thanks, > rainer > _______________________________________________ > 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 Fri May 23 11:40:09 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 E2BCE28C2ED; Fri, 23 May 2008 11:40:09 -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 AB2523A6BBC for ; Fri, 23 May 2008 11:40:08 -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 E7fhTcSKLHZ9 for ; Fri, 23 May 2008 11:40:07 -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 93B3F3A6BD1 for ; Fri, 23 May 2008 11:40:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,531,1204531200"; d="scan'208";a="71796555" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 May 2008 11:40:06 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4NIe65q008517 for ; Fri, 23 May 2008 11:40:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4NIe6K0008764 for ; Fri, 23 May 2008 18:40:06 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 May 2008 11:40:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 11:40:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some revised text for syslog TLS Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86Vg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 23 May 2008 18:40:06.0002 (UTC) FILETIME=[6B6F1520:01C8BD04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10124; t=1211568006; x=1212432006; 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:=20Some=20revised=20text=20for=20syslog=20TLS |Sender:=20; bh=+/+Bjd2R6y1WOcE6JxvbEtbj5NFy99zmcDus6rG0MIQ=; b=JZKKwbj15ye8WKWCyW8g5C2urRrxCcCTHlpkgr3gCxFivVRnxALdoAZzHk toQ5KdzCdPTzKThKoy4Js/pNs2l2SWD5tNYicuhV/pSo4EvwFgUIx7TmYWJ/ 7dJX/wtwHLpj96d33j5Gzs1fBXC3nDAvofkKP9kmdKSh0YrdZL9D4=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Syslog] Some revised text for syslog TLS 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 I reworked some of the text to try to capture the discussions in the working group. I broke out the mechanical part of the validation from the policy. There is some redundancy between the security considerations section and the new policy section. I tried to focus the requirements language on implementation requirements to enable secure interoperability vs. deployment options. We are not finished yet, but I think it is a step in the right direction. Cheers, Joe 4.2.1 Certificate-Based Authentication Both syslog transport sender (TLS Client) and syslog transport receiver (TLS server) MUST implement certificate-based authentication. This consists validating proof of possession of the private key corresponding to the public key in the certificate. To ensure interoperability between clients and servers, the following methods for certificate validation are mandatory to implement: o Certificate path validation: the client is configured with one or more trust anchors. Additional policy controls needed for authorizing the syslog transport sender and syslog transport receiver are described in Section 5. This method is useful where there is a PKI deployment. o End-Entity Certificate Matching: The transport receiver or transport sender is configured with information necessary to match the end-entity certificates of its authorized peers (which can be self-signed). Implementations MUST support certificate fingerprints in section 4.2.3 and MAY allow other formats for end-entity certificates such as a DER encoded certificate. This method provides an alternative to a PKI that is simpler to deploy and still maintains a reasonable level of security. Both transport receiver and transport sender implementations MUST provide a means to generate a key pair and self-signed certificate in the case that a key pair and certificate are not available through another mechanism. 4.2.2 Certificate Fingerprints Both client and server implementations MUST make the certificate fingerprint for their certificates available through a management interface. The mechanism to generate a fingerprint is to take the hash of the certificate using a cryptographically strong algorithm and convert the result into colon separated, hexadecimal bytes, each represented by 2 uppercase ASCII characters. When a fingerprint value is displayed or configured the fingerprint is prepended with an ASCII label identifying the hash function followed by a colon. Implementations MUST support SHA-1 as the hash algorithm and use the ASCII label "SHA1" to identify the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the length of the corresponding fingerprint string is 64 characters. An example certificate fingerprint is: SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D During validation the hash is extracted from the fingerprint and compared against the hash calculated over the received certificate. [sections skipped] 5. Security Policies Different environments have different security requirements and therefore would deploy different security policies. This section provides discusses some of the security policies that may be implemented by syslog transport receivers and syslog transport senders. The security policies describe the requirements for authentication, credential validation and authorization. The list of policies in this section is not exhaustive and other policies may be implemented. 5.1 Recommended Security Policy The recommended security policy provides protection against the threats in section 2. This policy requires authentication, certificate validation and authorization of both the syslog transport sender and syslog transport receiver. If there is a failure in the authentication, certificate validation or authorization then the connection is closed. Authorization requires the capability to authorize individual hosts as transport receivers and transport senders. When end-entity certificate matching is used, authentication and certificate validation are sufficient to authorize and entity. When certificate path validation MUST support the following authorization mechanisms: o Host-name-based authorization where the host name of the authorized peer is compared against the subject fields in the certificate. For the purpose of interoperability, implementations MUST support matching the host name against a SubjectAltName field with a type of dNSName and SHOULD support checking hostname against the Common Name portion of the Subject Distinguished Name. Matching for certificate credentials is performed using the matching rules specified by [3]. If more than one host name identity is present in the certificate a match in any one of the set is considered acceptable. Implementations also MAY support wildcards to match a range of values. For example, names to be matched against a certificate may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. Wildcards make it possible to deploy trust-root-based authorization where all credentials issued by a particular CA trust root are authorized. o IP-address-based authorization where the IP address configured for the authorized peer is compared against the subject fields in the certificate. Implementations MUST support matching the IP address against a SubjectAltName field of type iPAddress and MAY support checking the configured IP address against the Common Name portion of the Subject Distinguished Name. Matching for certificate credentials is performed using the matching rules specified by [3]. If more than one IP Address identity is present in the certificate a match in any one of the set is considered acceptable. Implementations MAY also support authorization based on other attributes. For example, the authorization of a device Serial Number against the SerialNumber portion of the Subject Distinguished Name or restrictions on the depth of a certificate chain. Implementations MUST support this policy and it is recommended that this be the default policy. 5.2 Liberal Validation of a Syslog Transport Sender In some environments, the authenticity of syslog data is not important or it is verifiable by other means, so transport receivers may accept data from any transport sender. To achieve this, the transport receiver performs authentication and certificate consistency checks and forgoes the validation of the certificate chain and authorization. In this case, the transport receiver is authorized, however this policy does not protect against the threat of transport sender masquerade described in Section 2. The use of this policy is generally not recommended for this reason. If this policy is used, the transport receiver SHOULD record the end-entity certificate for the purpose of correlating it with the sent data. 5.3 Liberal Validation of a Syslog Transport Receiver In some environments the confidentiality syslog data is not important so data may be sent to any transport receiver. To achieve this the transport sender performs authentication certificate consistency checks and forgoes validation of the certificate chain and authorization. While this policy does authorize the transport sender, it does not protect against the threat of transport receiver masquerade described in Section 2, leaving the data sent vulnerable to disclosure and modification. The use of this policy is generally not recommended for this reason. 5.4 Liberal Syslog Transport Receiver and Sender Validation In environments where security is not a concern at all the transport receiver and transport sender authenticate each other and perform certificate consistency checks and may forgo validation of the certificate chain and authorization. This policy does not protect against any of the threats described in section 2 and is therefore not recommended. 6. Security Considerations 6.1 Deployment Issues Section 5 discusses various security policies that may be deployed. The only configuration that mitigates the threats described in Section 2 is the recommended policy defined in section 5.1. This is the recommended configuration for deployments. If the transport receiver chooses not to fully authenticate, validate and authorize the transport sender it may receive data from an attacker. Unless it has another way of authenticating the source of the data, the data should not be trusted. This is especially important if the syslog data is going to be used to detect and react to security incidents. The transport receiver may also increase its vulnerability to denial of service, resource consumption and other attacks if it does not authenticate the transport sender. Because of the increased vulnerability to attack, this type of configuration is not recommended. If the transport sender chooses not to fully authenticate, validate and authorize the syslog transport receiver then it may send data to an attacker. This may disclose sensitive data within the log information that is useful to an attacker resulting in further compromises within the system. If a transport sender operates in this mode it should limit the data it sends to data that is not valuable to an attacker. In practice this is very difficult to achieve, so this type of configuration is not recommended. Forgoing authentication, validation and/or authorization on both sides allows for man-in-the-middle, masquerade and other types of attacks that can completely compromise integrity and confidentiality of the data. This type of configuration is not recommended. 6.2 Cipher Suites [I think the mandatory to implement algorithm should be defined in section 4.2 instead of the security considerations section] _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Sun May 25 23:46:01 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 27FF83A6B3A; Sun, 25 May 2008 23:46:01 -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 C20193A6859 for ; Sun, 25 May 2008 23:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 NM6M732A-BEl for ; Sun, 25 May 2008 23:45:57 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 2B26D3A6B4D for ; Sun, 25 May 2008 23:45:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id EC77E7AE2BC; Mon, 26 May 2008 08:45:53 +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 xq4VKS0EKz0M; Mon, 26 May 2008 08:45:53 +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 A8DA57AE284; Mon, 26 May 2008 08:45:53 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 May 2008 08:45:54 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Fingerprint/handshake Thread-Index: Aci597ZxZLhWgaMcSke8NLzWgHaUOAABInCQAT9t6xA= References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] Fingerprint/handshake 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 Joe, inline > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Friday, May 23, 2008 8:21 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Fingerprint/handshake > > The fingerprint check should be done where certificate validation would > be done. This is typically done within the handshake itself, I agree to this, but have found this to be problematic with some TLS libraries. Of course, that doesn't mean the standard needs to change, but I would still like to provide some implementation feedback. With GnuTLS, for example, you can do the final authentication only after the handshake [1]. With NSS, it can be done during the handshake. As of my understanding, OpenSSL does support it after the handshake only (but I have not actually used OpenSSL, this is based on my understanding after reading doc). This brings me to the conclusion that, at least in some environments I may be forced to delay the authentication check to after the handshake. > because if > the validation fails you do not want to send or receive data on the > connection. I suppose you could implement the check after the > handshake, but you need to make sure you do not send or receive > application before successful validation has occurred. This is where it gets really problematic. We get into a race condition here. Remember that syslog is simplex and works without any app-level acks (in -transport-tls). If the client authenticates the server, everything is fine. Authentication fails, client never sends data and the session is terminated. Everything is fine. But if the server authenticates the client (and authentication fails), the client will still receive the server's TLS Finished message. After that, the server drop connection. HOWEVER, the client blindly sending data doesn't know this until at least the second message sent (due to local buffering at the client). *After* some messages, the client gets a connection broken indication, but at this point it is too late to react intelligently. In essence, those messages sent after the initial handshake are lost. Even worse, the client "gets the impression" that the remote server is accepting its connection requests. This is because there is no failure indication after the handshake. This can lead to more frequent retries. This problem is rooted in the underlying plain tcp transport. I have described it in [2]. It's inherent to all plain tcp syslog implementations. RFC3195 is a cure for it. With TLS auth, it just gets to a new magnitude as it will now happen every time during a failed authentication. This is not a theoretic issue but one I can reliable reproduce in my lab with actual software. Actually, I am unable to NOT reproduce it - there is no work-around for this problem (at least I have found none). Again, I am not trying to say we need to change anything. I am providing real world feedback. It may be worth, however, adding a note or two to the I-D describing these issues. Rainer [1] http://lists.gnu.org/archive/html/help-gnutls/2008-05/msg00017.html (full conversation, long) [2] http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.ht ml _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Sun May 25 23:55:03 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 D41C53A68CB; Sun, 25 May 2008 23:55:03 -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 0110A3A6859 for ; Sun, 25 May 2008 23:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 6OutYx4q8Ugi for ; Sun, 25 May 2008 23:55:02 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 2FB803A67AF for ; Sun, 25 May 2008 23:55:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id A31C47AE2BC for ; Mon, 26 May 2008 08:55:02 +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 g87qpyzftfSU for ; Mon, 26 May 2008 08:55:02 +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 744EC7AE284 for ; Mon, 26 May 2008 08:55:02 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 May 2008 08:55:02 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309092@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: same certificate for client and sender? Thread-Index: Aci+/Wv05mX/uIqNQPCrPGQr9wEUdQ== From: "Rainer Gerhards" To: Subject: [Syslog] same certificate for client and sender? 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 all, If I look at a relay, it is both a transport receiver and transport sender. And, of course, it is a single software entity. In my implementation I am currently using a single certificate on relays - both being used for the sender as well as the receiver. While this is natural, I am not sure if it is secure. Could you advise on what is reasonable secure in a relay environment? Note, however, that using different certificates may finally disable any remaining auto-configuration capabilities (which I have with a single certificate). Feedback is appreciated. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 00:18:56 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 6BC443A6A37; Mon, 26 May 2008 00:18:56 -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 ED81F3A6B1B for ; Mon, 26 May 2008 00:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 PBkNCTChTf4Z for ; Mon, 26 May 2008 00:18:55 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id BE52B3A67E9 for ; Mon, 26 May 2008 00:18:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id CFB3F7AE2BC; Mon, 26 May 2008 09:18:49 +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 R5W3E6T3rVED; Mon, 26 May 2008 09:18:49 +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 933907AE284; Mon, 26 May 2008 09:18:49 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 May 2008 09:18:53 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86VgB+nRUA References: From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] Some revised text for syslog TLS 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 Joe, I like this new text. I am snipping everything below except the one thing that drives a question: > o IP-address-based authorization where the IP address configured > for the authorized peer is compared against the subject fields in the > certificate. Implementations MUST support matching the IP address > against a SubjectAltName field of type iPAddress and MAY support > checking the configured IP address against the Common Name portion of > the Subject Distinguished Name. Matching for certificate credentials > is > performed using the matching rules specified by [3]. If more than one > IP Address identity is present in the certificate a match in any one of > the set is considered acceptable. I know that you asked about the usefulness of IP based authentication before. I am now at a point where I have actually finished my implementation and I am "polishing" it. On my agenda is now a as good as possible *automatic* authentication. For the client to authorize the server, it is quite easy. There usually is something like *.* @@192.0.2.1 In this case, I can take the destination ("192.0.2.1") and verify it against the server's certificate. Provided we use a common root CA, this setup is fully automatic. So supporting IPs is quite useful in this scenario. Please note that operators tend to use IP addresses over hostnames because of reliability reasons and early startup capability of the syslogd (before DNS resolutions is available). So this is of practical relevance. In case of the server authenticating the client, there is no such obvious choice. I could use the remote client's IP address (provided by the transport stack) and verify that it matches the IP address inside the certificate. However, is this really useful? IMO, this is more or less a check if the remote cert is signed by a common CA. Something that may be useful, but does not depend on the client's IP be known. Do you or somebody else on this list (Tom?) have a clue why it may be useful to carry out such a check? Back on the topic of easy but still secure configuration, I could envision taken the reverse DNS name of the transport sender and checking that against the identity presented in the certificate. Anyone any thoughts/comments on this? Again, all of this assumes a common root CA and certificates signed by it (not necessarily full PKI, but an "in-house CA"). Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 02:35:02 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 36D073A68ED; Mon, 26 May 2008 02:35:02 -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 4CA9D3A68ED for ; Mon, 26 May 2008 02:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 oASjaqj6pCaS for ; Mon, 26 May 2008 02:35:00 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 3DD683A68C8 for ; Mon, 26 May 2008 02:34:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 672537AD8BB; Mon, 26 May 2008 11:34:50 +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 7sEAxLlRYW+z; Mon, 26 May 2008 11:34:50 +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 2BADB7AD6BB; Mon, 26 May 2008 11:34:50 +0200 (CEST) MIME-Version: 1.0 x-cr-puzzleid: {CA17C618-493A-4698-9046-CC4530F9BD65} X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message x-cr-hashedpuzzle: BMxa BWud CPMA DyRr EIfm E/+s GNnu Hoia IbFm KWgY L39P MghS PPz5 Qp01 T6WN W7i+; 2; agBzAGEAbABvAHcAZQB5AEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBzAHkAcwBsAG8AZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {CA17C618-493A-4698-9046-CC4530F9BD65}; cgBnAGUAcgBoAGEAcgBkAHMAQABoAHEALgBhAGQAaQBzAGMAbwBuAC4AYwBvAG0A; Mon, 26 May 2008 09:34:53 GMT; UgBFADoAIABbAFMAeQBzAGwAbwBnAF0AIABTAG8AbQBlACAAcgBlAHYAaQBzAGUAZAAgAHQAZQB4AHQAIABmAG8AcgAgAHMAeQBzAGwAbwBnACAAVABMAFMA Date: Mon, 26 May 2008 11:34:53 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30909A@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86VgCDuzKQ References: From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] Some revised text for syslog TLS 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 One more comment while implementing it: > 4.2.2 Certificate Fingerprints > > Both client and server implementations MUST make the certificate > fingerprint for their certificates available through a management > interface. > > The mechanism to generate a fingerprint is to take the hash of the > certificate using a cryptographically strong algorithm and convert the > result into colon separated, hexadecimal bytes, each represented by 2 > uppercase ASCII characters. When a fingerprint value is displayed or > configured the fingerprint is prepended with an ASCII label identifying > the hash function followed by a colon. Implementations MUST support > SHA-1 as the hash algorithm and use the ASCII label "SHA1" to identify > the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the > length of the corresponding fingerprint string is 64 characters. An > example certificate fingerprint is: > > SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D > > > During validation the hash is extracted from the fingerprint and > compared against the hash calculated over the received certificate. The text above makes it really easy to implement, as there is no longer a doubt about what the actual format should look like. Also, adding the hash algo as first field of the fingerprint cleans up a lot of code. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 02:37:32 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 9C5263A6ACC; Mon, 26 May 2008 02:37:32 -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 B35CF3A6ACC for ; Mon, 26 May 2008 02:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 wGTtwgY40YJD for ; Mon, 26 May 2008 02:37:30 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id CB9CE3A69A0 for ; Mon, 26 May 2008 02:37:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 0FDE77AD8BB for ; Mon, 26 May 2008 11:37:20 +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 2c53JW5UetaG for ; Mon, 26 May 2008 11:37:19 +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 D48687AD6BB for ; Mon, 26 May 2008 11:37:19 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 May 2008 11:37:30 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30909C@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft references Thread-Index: Aci/FB4KzRkxn2c1Sh++RztGcg90jA== From: "Rainer Gerhards" To: Subject: [Syslog] draft references 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, -transport-tls references a number of drafts, e.g. draft-ietf-pkix-rfc3280bis-11. Is this strictly necessary? I am asking because transport-tls is holding the rest of the syslog RFC series. I would prefer to have it ready for publication immediately after discussion instead of itself being waiting on some other unfinished work. Of course, if it is vital, there is no way around... Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 02:46: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 E94933A6A76; Mon, 26 May 2008 02:46: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 BA05C3A698E for ; Mon, 26 May 2008 02:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 rwfLUnWfWNN1 for ; Mon, 26 May 2008 02:46:32 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id CFF4D3A6A76 for ; Mon, 26 May 2008 02:46:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 19D847AE20A for ; Mon, 26 May 2008 11:46:21 +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 UKSo951-9pVW for ; Mon, 26 May 2008 11:46:21 +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 DB6927AE209 for ; Mon, 26 May 2008 11:46:20 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 May 2008 11:46:26 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30909E@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: certificate version question Thread-Index: Aci/FV2p9vTpyaKcQLWADmgYncgUrQ== From: "Rainer Gerhards" To: Subject: [Syslog] certificate version question 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 all, maybe a dumb question: is any certificate version to be supported. Or is it x.509 v3 or v3+ only? I am asking because some of the references seem to be assume v3. I have to admit I do not know what is the difference between e.g. v2 and v3, and so I thought I just ask... So far I accept any version, as long as it has the required fields. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 04:39:10 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 1AA4B3A68B9; Mon, 26 May 2008 04:39:10 -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 C7A803A6B80 for ; Mon, 26 May 2008 04:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 wyDtxVF1eIrw for ; Mon, 26 May 2008 04:39:09 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0A5363A6B8D for ; Mon, 26 May 2008 04:39:08 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4QBcKFV028380; Mon, 26 May 2008 06:39:06 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:38:49 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:38:49 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 14:38:48 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72B36950@vaebe104.NOE.Nokia.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30909C@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft references Thread-Index: Aci/FB4KzRkxn2c1Sh++RztGcg90jAAEKD6w References: <577465F99B41C842AAFBE9ED71E70ABA30909C@grfint2.intern.adiscon.com> From: To: , X-OriginalArrivalTime: 26 May 2008 11:38:49.0390 (UTC) FILETIME=[10A36CE0:01C8BF25] X-Nokia-AV: Clean Subject: Re: [Syslog] draft references 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 The -pkix-rfc3280bis draft is already out (RFC 5280), and the other normative one (-tls-rfc4346-bis) should be out any day now. So they won't be holding the -transport-tls draft. Best regards, Pasi > -----Original Message----- > From: Rainer Gerhards > Sent: 26 May, 2008 12:38 > To: syslog@ietf.org > Subject: [Syslog] draft references > > Hi, > > -transport-tls references a number of drafts, e.g. > draft-ietf-pkix-rfc3280bis-11. > > Is this strictly necessary? I am asking because transport-tls is > holding the rest of the syslog RFC series. I would prefer to have it > ready for publication immediately after discussion instead of itself > being waiting on some other unfinished work. Of course, if it is > vital, there is no way around... > > Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 04:42:43 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 64E443A6B61; Mon, 26 May 2008 04:42:43 -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 BD43E3A6B8D for ; Mon, 26 May 2008 04:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 ur9PscykXPP8 for ; Mon, 26 May 2008 04:42:41 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BE3443A6B81 for ; Mon, 26 May 2008 04:42:40 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4QBgXh6013641; Mon, 26 May 2008 14:42:36 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:42:30 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:42:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 14:42:29 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72B36962@vaebe104.NOE.Nokia.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30909E@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] certificate version question Thread-Index: Aci/FV2p9vTpyaKcQLWADmgYncgUrQAD80XA References: <577465F99B41C842AAFBE9ED71E70ABA30909E@grfint2.intern.adiscon.com> From: To: , X-OriginalArrivalTime: 26 May 2008 11:42:30.0030 (UTC) FILETIME=[94266AE0:01C8BF25] X-Nokia-AV: Clean Subject: Re: [Syslog] certificate version question 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 TLS supports only X509v3 certificates (*) -- but this doesn't really matter, because nobody has used v1 or v2 in ages. (* It also supports OpenPGP certificates, but I guess this detail isn't relevant here.) Best regards, Pasi > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of ext Rainer Gerhards > Sent: 26 May, 2008 12:46 > To: syslog@ietf.org > Subject: [Syslog] certificate version question > > Hi all, > > maybe a dumb question: is any certificate version to be > supported. Or is it x.509 v3 or v3+ only? I am asking because some > of the references seem to be assume v3. I have to admit I do not > know what is the difference between e.g. v2 and v3, and so I thought > I just ask... > > So far I accept any version, as long as it has the required fields. > > Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 04:50:09 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 6F0453A6B96; Mon, 26 May 2008 04:50:09 -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 ABA3F3A67F1 for ; Mon, 26 May 2008 04:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 d2+uiKXgKZSi for ; Mon, 26 May 2008 04:50:03 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id E5A9028C1C9 for ; Mon, 26 May 2008 04:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 1BE067AE316; Mon, 26 May 2008 13:48:06 +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 McmgYaXCO9oY; Mon, 26 May 2008 13:48:06 +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 D7BE27AE30A; Mon, 26 May 2008 13:48:05 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 May 2008 13:48:38 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3090A6@grfint2.intern.adiscon.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72B36962@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] certificate version question Thread-Index: Aci/FV2p9vTpyaKcQLWADmgYncgUrQAD80XAAABFuVA= References: <577465F99B41C842AAFBE9ED71E70ABA30909E@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB72B36962@vaebe104.NOE.Nokia.com> From: "Rainer Gerhards" To: Cc: syslog@ietf.org Subject: Re: [Syslog] certificate version question 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 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Monday, May 26, 2008 1:42 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] certificate version question > > TLS supports only X509v3 certificates (*) -- but this doesn't > really matter, because nobody has used v1 or v2 in ages. OK, as I said: a dumb question ;) > (* It also supports OpenPGP certificates, but I guess this > detail isn't relevant here.) Well... I think there is no MUST NOT in -transport-tls that prohibits to use them? I am thinking about adding support for them as an extended option. Rainer > > Best regards, > Pasi > > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of ext Rainer Gerhards > > Sent: 26 May, 2008 12:46 > > To: syslog@ietf.org > > Subject: [Syslog] certificate version question > > > > Hi all, > > > > maybe a dumb question: is any certificate version to be > > supported. Or is it x.509 v3 or v3+ only? I am asking because some > > of the references seem to be assume v3. I have to admit I do not > > know what is the difference between e.g. v2 and v3, and so I thought > > I just ask... > > > > So far I accept any version, as long as it has the required fields. > > > > Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 05:28:49 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 D89033A6A0C; Mon, 26 May 2008 05:28:49 -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 A9F263A6A0C for ; Mon, 26 May 2008 05:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 bwKdyaZXSHKt for ; Mon, 26 May 2008 05:28:47 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 83DCB3A68A9 for ; Mon, 26 May 2008 05:28:47 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4QCSZFe013416; Mon, 26 May 2008 15:28:46 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 15:28:34 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 15:28:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 15:28:33 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86VgB+nRUAAArie5A= References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> From: To: , X-OriginalArrivalTime: 26 May 2008 12:28:34.0614 (UTC) FILETIME=[03F87560:01C8BF2C] X-Nokia-AV: Clean Subject: Re: [Syslog] Some revised text for syslog TLS 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 Rainer Gerhards wrote: > I know that you asked about the usefulness of IP based > authentication before. I am now at a point where I have actually > finished my implementation and I am "polishing" it. On my agenda is > now a as good as possible *automatic* authentication. > > For the client to authorize the server, it is quite easy. There > usually is something like > > *.* @@192.0.2.1 > > In this case, I can take the destination ("192.0.2.1") and verify it > against the server's certificate. Provided we use a common root CA, > this setup is fully automatic. So supporting IPs is quite useful in > this scenario. Please note that operators tend to use IP addresses > over hostnames because of reliability reasons and early startup > capability of the syslogd (before DNS resolutions is available). So > this is of practical relevance. I agree that in some situations, we don't want to depend on DNS. However, this is somewhat orthogonal to what the certificate contains. AFAIK certificates containing IP addresses are quite rare; host names are much common. To support such situation -- while still avoiding dependency on DNS -- it would be useful if you could configure the IP address (used for opening the connection) and server name (compared against the certificate, but not looked up from DNS) separately. I don't know what that would look like in your configuration file syntax, but maybe something like *.* @@192.0.2.1[syslogsrv2.example.com] > In case of the server authenticating the client, there is no such > obvious choice. I could use the remote client's IP address (provided > by the transport stack) and verify that it matches the IP address > inside the certificate. However, is this really useful? IMO, this is > more or less a check if the remote cert is signed by a common CA. > Something that may be useful, but does not depend on the client's IP > be known. > > Do you or somebody else on this list (Tom?) have a clue why it may be > useful to carry out such a check? It doesn't seem very useful to me... I guess you could have a local "wildcard" or "netmask" saying that only clients from 192.0.2.* are allowed to connect; if your certificates contain IP addresses, presumably you'd use the address in the certificate (and not the transport) for that check. (But as I said, certificates containing IP addresses are not common.) > Back on the topic of easy but still secure configuration, I could > envision taken the reverse DNS name of the transport sender and > checking that against the identity presented in the > certificate. Anyone any thoughts/comments on this? This doesn't seem very useful to me, and AFAIK no such thing is done in other protocols using TLS/certificates. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 05:59:41 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 274223A67F2; Mon, 26 May 2008 05:59:41 -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 739CC3A67A9 for ; Mon, 26 May 2008 05:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 GxKesyfd8Dyd for ; Mon, 26 May 2008 05:59:38 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 18D923A67D9 for ; Mon, 26 May 2008 05:59:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id D8C957AE344; Mon, 26 May 2008 14:58:34 +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 lMdlbUQYkNVY; Mon, 26 May 2008 14:58:34 +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 8B6E37AE342; Mon, 26 May 2008 14:58:34 +0200 (CEST) Received: from [172.19.2.12] ([172.19.2.12]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 14:59:35 +0200 From: Rainer Gerhards To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com> References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com> Organization: Adiscon Date: Mon, 26 May 2008 14:59:52 +0200 Message-Id: <1211806792.27593.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 26 May 2008 12:59:35.0757 (UTC) FILETIME=[594C57D0:01C8BF30] Cc: syslog@ietf.org Subject: Re: [Syslog] Some revised text for syslog TLS 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 Pasi, inline... On Mon, 2008-05-26 at 15:28 +0300, Pasi.Eronen@nokia.com wrote: > Rainer Gerhards wrote: > > > I know that you asked about the usefulness of IP based > > authentication before. I am now at a point where I have actually > > finished my implementation and I am "polishing" it. On my agenda is > > now a as good as possible *automatic* authentication. > > > > For the client to authorize the server, it is quite easy. There > > usually is something like > > > > *.* @@192.0.2.1 > > > > In this case, I can take the destination ("192.0.2.1") and verify it > > against the server's certificate. Provided we use a common root CA, > > this setup is fully automatic. So supporting IPs is quite useful in > > this scenario. Please note that operators tend to use IP addresses > > over hostnames because of reliability reasons and early startup > > capability of the syslogd (before DNS resolutions is available). So > > this is of practical relevance. > > I agree that in some situations, we don't want to depend on > DNS. However, this is somewhat orthogonal to what the certificate > contains. > > AFAIK certificates containing IP addresses are quite rare; host names > are much common. Please keep in mind that my message was related to the question if there is a use case for using IPs inside a certificate. As I said above, there is. > To support such situation -- while still avoiding > dependency on DNS -- it would be useful if you could configure the IP > address (used for opening the connection) and server name (compared > against the certificate, but not looked up from DNS) separately. > > I don't know what that would look like in your configuration file > syntax, but maybe something like > > *.* @@192.0.2.1[syslogsrv2.example.com] rsyslog of course supports this. The actual syntax is: $ActionSendStreamDriverAuthMode x509/name # soon to be default $ActionSendStreamDriverPermittedPeer syslogsrv2.example.com *.* @@192.0.2.1 The $ActionSendStreamDriverPermittedPeer directive can be specified multiple times, for example when talking to an active/passive cluster with different identities (or whatever else may come up). To prevent relying on tcp, one could also add syslogsrv2.example.com to /etc/hosts, which would also lead to *.* @@syslogsrv2.example.com In any case, the goal is to have automatic authentication, and this works well with a common trusted CA. An "in-house" CA may also issue certificates with IP addresses. > > In case of the server authenticating the client, there is no such > > obvious choice. I could use the remote client's IP address (provided > > by the transport stack) and verify that it matches the IP address > > inside the certificate. However, is this really useful? IMO, this is > > more or less a check if the remote cert is signed by a common CA. > > Something that may be useful, but does not depend on the client's IP > > be known. > > > > Do you or somebody else on this list (Tom?) have a clue why it may be > > useful to carry out such a check? > > It doesn't seem very useful to me... I guess you could have a local > "wildcard" or "netmask" saying that only clients from 192.0.2.* are > allowed to connect; if your certificates contain IP addresses, > presumably you'd use the address in the certificate (and not the > transport) for that check. (But as I said, certificates containing > IP addresses are not common.) Even if the certificate has an IP - does that really gain me something? I think using the certificate's IP doesn't provide me any additional security in this case. I think this authentication is not useful and the server really can not automatically be configured to detect permitted remote clients - except for wildcard names. (as a side-note, rsyslog allows a mode where it just checks the validity of the remote certificate - so a common CA can be used to automatically authorize a broad range of machines). > > > Back on the topic of easy but still secure configuration, I could > > envision taken the reverse DNS name of the transport sender and > > checking that against the identity presented in the > > certificate. Anyone any thoughts/comments on this? > > This doesn't seem very useful to me, and AFAIK no such thing > is done in other protocols using TLS/certificates. Plus, it would again introduce the DNS dependency. So that's probably a bad idea. But after this conversation: is there really any use case for IP addresses in the certificate? I begin to get the feeling that we should probably remove the text about them - there are ample work-arounds to achieve the same, mostly better, effect. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 06:06:24 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 7A0C73A694B; Mon, 26 May 2008 06:06:24 -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 C8AE53A67D9 for ; Mon, 26 May 2008 06:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 OE6oqr3VCzrg for ; Mon, 26 May 2008 06:06:21 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 694F13A67F2 for ; Mon, 26 May 2008 06:06:21 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4QD6Bg9023045; Mon, 26 May 2008 16:06:19 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 16:06:09 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 16:06:09 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 16:06:08 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72B36AAC@vaebe104.NOE.Nokia.com> In-Reply-To: <1211806792.27593.11.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci/MF7jy1NVEensQ7+a4dvkqdLN3wAAGezQ References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com> <1211806792.27593.11.camel@localhost.localdomain> From: To: X-OriginalArrivalTime: 26 May 2008 13:06:09.0243 (UTC) FILETIME=[43D58AB0:01C8BF31] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Some revised text for syslog TLS 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 Rainer Gerhards wrote: > Please keep in mind that my message was related to the question if > there is a use case for using IPs inside a certificate. As I said > above, there is. Ok. Do you think this use case is important enough to keep this feature (checking IPAddress subjectAltName) as part of the "MUST implement" baseline? (Joe's latest text already has other forms of name comparison as optional: "Implementations MAY also support authorization based on other attributes. For example, the authorization of a device Serial Number against the SerialNumber portion of the Subject Distinguished Name [...]") > > To support such situation -- while still avoiding dependency on > > DNS -- it would be useful if you could configure the IP address > > (used for opening the connection) and server name (compared > > against the certificate, but not looked up from DNS) separately. > > > > I don't know what that would look like in your configuration file > > syntax, but maybe something like > > > > *.* @@192.0.2.1[syslogsrv2.example.com] > > rsyslog of course supports this. The actual syntax is: > > $ActionSendStreamDriverAuthMode x509/name # soon to be default > $ActionSendStreamDriverPermittedPeer syslogsrv2.example.com > *.* @@192.0.2.1 Ok, good to know. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 06:26:01 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 383583A695C; Mon, 26 May 2008 06:26:01 -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 EF82F3A67D9 for ; Mon, 26 May 2008 06:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 f1sdwc60ngf9 for ; Mon, 26 May 2008 06:25:59 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 2F2623A68F2 for ; Mon, 26 May 2008 06:25:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 4FB737AE377 for ; Mon, 26 May 2008 15:24:56 +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 bTXPo8066uRr for ; Mon, 26 May 2008 15:24:56 +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 178847AE342 for ; Mon, 26 May 2008 15:24:56 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 May 2008 15:26:00 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3090A9@grfint2.intern.adiscon.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72B36AAC@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci/MF7jy1NVEensQ7+a4dvkqdLN3wAAGezQAABeseA= References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com> <1211806792.27593.11.camel@localhost.localdomain> <1696498986EFEC4D9153717DA325CB72B36AAC@vaebe104.NOE.Nokia.com> From: "Rainer Gerhards" To: Subject: Re: [Syslog] Some revised text for syslog TLS 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 > > Please keep in mind that my message was related to the question if > > there is a use case for using IPs inside a certificate. As I said > > above, there is. > > Ok. Do you think this use case is important enough to keep this > feature (checking IPAddress subjectAltName) as part of the "MUST > implement" baseline? No, I don't think it is a MUST. > (Joe's latest text already has other forms of name comparison as > optional: "Implementations MAY also support authorization based on > other attributes. For example, the authorization of a device Serial > Number against the SerialNumber portion of the Subject Distinguished > Name [...]") This should take care of it well enough. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 08:00:52 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 069C83A69B8; Mon, 26 May 2008 08:00:52 -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 50CD63A6BBB for ; Mon, 26 May 2008 08:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 wopxZZkoo17G for ; Mon, 26 May 2008 08:00:45 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id C5FB03A69B8 for ; Mon, 26 May 2008 08:00:44 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 00DD71E357C for ; Mon, 26 May 2008 17:00:46 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id Eo8bu6-IvDEb for ; Mon, 26 May 2008 17:00:25 +0200 (CEST) Received: from [192.168.178.21] (BAA18c6.baa.pppool.de [77.128.24.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 093B81E36CA for ; Mon, 26 May 2008 17:00:22 +0200 (CEST) Message-ID: <483AD08A.9090407@mschuette.name> Date: Mon, 26 May 2008 17:00:26 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Some revised text for syslog TLS 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 Rainer Gerhards schrieb: > scenario. Please note that operators tend to use IP addresses over > hostnames because of reliability reasons and early startup capability of > the syslogd (before DNS resolutions is available). So this is of > practical relevance. As noted later this will require the IP adresses to be included in the x509 certificates. The usual verification against the Common Name requires DNS. > In case of the server authenticating the client, there is no such > obvious choice. I could use the remote client's IP address (provided by > the transport stack) and verify that it matches the IP address inside > the certificate. However, is this really useful? I think it is necessary since it is a mutual authentication: the client verifies the server, and the server verifies the client. Each Authentication has two steps: 1. verify the trust path to the cert (either by CA signature, having the cert itself configured as a trust anchor, or having its fingerprint) and 2. check if the cert matches the requesting host (by IP or DNS, by Common Name or subjectAltName). > IMO, this is more or > less a check if the remote cert is signed by a common CA. Something that > may be useful, but does not depend on the client's IP be known. > Do you or somebody else on this list (Tom?) have a clue why it may be > useful to carry out such a check? Maybe the second step should be configurable (like the first one) since it is comes down to policy, but the question is: Do you accept a connection from client A if it shows a certificate from client B? You might want to if you use only one cert for all clients, but if every client has its own cert then you might not, because this situation indicates a serious misconfiguration or intrusion. > Back on the topic of easy but still secure configuration, I could > envision taken the reverse DNS name of the transport sender and checking > that against the identity presented in the certificate. Anyone any > thoughts/comments on this? Ack. I am going to do the same. > Again, all of this assumes a common root CA and certificates signed by > it (not necessarily full PKI, but an "in-house CA"). Either that or a collection af all involved certificates. It should not make a difference if a common CA is the trust anchor or if every cert itself is. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon May 26 15:15:41 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 3C8F328C1EB; Mon, 26 May 2008 15:15:41 -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 DD45528C1EB for ; Mon, 26 May 2008 15:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jwzh+F4dQ0II for ; Mon, 26 May 2008 15:15:34 -0700 (PDT) Received: from ext-nj2ut-5.online-age.net (ext-nj2ut-5.online-age.net [64.14.54.234]) by core3.amsl.com (Postfix) with ESMTP id C033D28C1AE for ; Mon, 26 May 2008 15:15:33 -0700 (PDT) Received: from int-nj2ut-5.online-age.net (int-nj2ut-5.online-age.net [3.159.237.74]) by ext-nj2ut-5.online-age.net (8.13.6/8.13.6/20051114-SVVS-TLS-DNSBL) with ESMTP id m4QMFYHG025187 for ; Mon, 26 May 2008 18:15:34 -0400 Received: from cinmlef11.e2k.ad.ge.com (int-nj2ut-5.online-age.net [3.159.237.74]) by int-nj2ut-5.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id m4QMFXwT024369 for ; Mon, 26 May 2008 18:15:34 -0400 Received: from ALPMLVEM05.e2k.ad.ge.com ([3.159.17.55]) by cinmlef11.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 May 2008 18:15:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 18:15:32 -0400 Message-ID: <124CF5A7D55D6F43A4FD9437F28254D8EED6CB@ALPMLVEM05.e2k.ad.ge.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86VgB+nRUAAB+j5bA= References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> From: "Moehrke, John (GE Healthcare)" To: "Rainer Gerhards" , "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 26 May 2008 22:15:33.0681 (UTC) FILETIME=[042B9A10:01C8BF7E] Subject: Re: [Syslog] Some revised text for syslog TLS 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 I have said this before, but people continue to go down this path... The TLS authentication has already proven that the 'other' side holds the private key... this is cryptographically secure authentication... Adding a check of the IP address or DNS address adds very very little value, and is not cryptographically secure (unless using Secure DNS). Therefore there is little value to adding IP or hostname checking, and lots of ways it will break (NAT, DHCP, etc). John > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf > Of Rainer Gerhards > Sent: Monday, May 26, 2008 2:19 AM > To: Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] Some revised text for syslog TLS > > Joe, > > I like this new text. > > I am snipping everything below except the one thing that drives a > question: > > > o IP-address-based authorization where the IP address configured > > for the authorized peer is compared against the subject fields in the > > certificate. Implementations MUST support matching the IP address > > against a SubjectAltName field of type iPAddress and MAY support > > checking the configured IP address against the Common Name portion of > > the Subject Distinguished Name. Matching for certificate credentials > > is > > performed using the matching rules specified by [3]. If more than one > > IP Address identity is present in the certificate a match in any one > of > > the set is considered acceptable. > > I know that you asked about the usefulness of IP based authentication > before. I am now at a point where I have actually finished my > implementation and I am "polishing" it. On my agenda is now a as good as > possible *automatic* authentication. > > For the client to authorize the server, it is quite easy. There usually > is something like > > *.* @@192.0.2.1 > > In this case, I can take the destination ("192.0.2.1") and verify it > against the server's certificate. Provided we use a common root CA, this > setup is fully automatic. So supporting IPs is quite useful in this > scenario. Please note that operators tend to use IP addresses over > hostnames because of reliability reasons and early startup capability of > the syslogd (before DNS resolutions is available). So this is of > practical relevance. > > In case of the server authenticating the client, there is no such > obvious choice. I could use the remote client's IP address (provided by > the transport stack) and verify that it matches the IP address inside > the certificate. However, is this really useful? IMO, this is more or > less a check if the remote cert is signed by a common CA. Something that > may be useful, but does not depend on the client's IP be known. > > Do you or somebody else on this list (Tom?) have a clue why it may be > useful to carry out such a check? > > Back on the topic of easy but still secure configuration, I could > envision taken the reverse DNS name of the transport sender and checking > that against the identity presented in the certificate. Anyone any > thoughts/comments on this? > > Again, all of this assumes a common root CA and certificates signed by > it (not necessarily full PKI, but an "in-house CA"). > > Thanks, > Rainer > _______________________________________________ > 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 Mon May 26 16:23:14 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 B7F453A6BF4; Mon, 26 May 2008 16:23:14 -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 985793A6BF4 for ; Mon, 26 May 2008 16:23:13 -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 3I5TG2+Te7tl for ; Mon, 26 May 2008 16:23:12 -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 48A083A6B8F for ; Mon, 26 May 2008 16:23:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,545,1204531200"; d="scan'208";a="104204313" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 May 2008 16:23:14 -0700 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 m4QNNE66007457; Mon, 26 May 2008 16:23:14 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4QNNDKk027951; Mon, 26 May 2008 23:23:14 GMT Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 May 2008 19:23:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 19:23:35 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312204FB5D64@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <124CF5A7D55D6F43A4FD9437F28254D8EED6CB@ALPMLVEM05.e2k.ad.ge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86VgB+nRUAAB+j5bAAAgUOIA== References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <124CF5A7D55D6F43A4FD9437F28254D8EED6CB@ALPMLVEM05.e2k.ad.ge.com> From: "Anton Okmyanskiy (aokmians)" To: "Moehrke, John (GE Healthcare)" , "Rainer Gerhards" , "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 26 May 2008 23:23:13.0580 (UTC) FILETIME=[780F06C0:01C8BF87] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5784; t=1211844194; x=1212708194; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmyanskiy=20(aokmians)=22=20 |Subject:=20RE=3A=20[Syslog]=20Some=20revised=20text=20for= 20syslog=20TLS |Sender:=20; bh=qJQbv60o6/A/BM8osAhy78g/Kcjv/7YsoeT2hVHSMzw=; b=BbEAi+P2rIIz5oN8p9hcWBGZybu+WyCd5gOj6RnNjwuE8kycC0hJiF5aND 4zomstU5NnxCvS0vdENVGuJik/e9/Jcg4znF5uR6WS+Y0nqBffjJ+5N89pK5 nTTy3wCxBx; Authentication-Results: sj-dkim-2; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] Some revised text for syslog TLS 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 The bottom line is that when you use a certificate to authenticate the client, the trusted identity of the client that gets recorded in the messages must be derived from certificate, not from other source like IP address or whatever device or DNS says device might be. This can be handled by specifying appropriate tags (structured data ID) for certificate fields and recommending that those are added to the message (or updated) by the receiver if certificate-based authenticate is used. This would prevent the case of some client using legitimate (but stolen) certificate, and then indicating identity of another device in the message itself. If such behavior were allowed, then when certificate is stolen (but not yet put on certificate revocation list), this would extend the security threat to a wider scope of issues because we are allowing one device to masquerade as any other device. Note, that we need structured data field IDs not only for certificate Common Name (CN), but also for fields such as fingerprint. When one certificate is revoked and a new one issues, I believe the new one can have the same common name. In that case, if the receiver wants to identify which exact certificate the client used, you need to see the fingerprint or other similar certificate fields. We had a use-case with customer where such information was needed with TLS (albeit not in syslog context). Regards, Anton. > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Moehrke, John > (GE Healthcare) > Sent: Monday, May 26, 2008 3:16 PM > To: Rainer Gerhards; Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] Some revised text for syslog TLS > > I have said this before, but people continue to go down this path... > > The TLS authentication has already proven that the 'other' > side holds the private key... this is cryptographically > secure authentication... > > Adding a check of the IP address or DNS address adds very > very little value, and is not cryptographically secure > (unless using Secure DNS). > > Therefore there is little value to adding IP or hostname > checking, and lots of ways it will break (NAT, DHCP, etc). > > John > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf > > Of Rainer Gerhards > > Sent: Monday, May 26, 2008 2:19 AM > > To: Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: Re: [Syslog] Some revised text for syslog TLS > > > > Joe, > > > > I like this new text. > > > > I am snipping everything below except the one thing that drives a > > question: > > > > > o IP-address-based authorization where the IP address > configured > > > for the authorized peer is compared against the subject fields in > the > > > certificate. Implementations MUST support matching the > IP address > > > against a SubjectAltName field of type iPAddress and MAY support > > > checking the configured IP address against the Common Name portion > of > > > the Subject Distinguished Name. Matching for certificate > credentials > > > is > > > performed using the matching rules specified by [3]. If more than > one > > > IP Address identity is present in the certificate a match > in any one > > of > > > the set is considered acceptable. > > > > I know that you asked about the usefulness of IP based > authentication > > before. I am now at a point where I have actually finished my > > implementation and I am "polishing" it. On my agenda is now > a as good > as > > possible *automatic* authentication. > > > > For the client to authorize the server, it is quite easy. There > usually > > is something like > > > > *.* @@192.0.2.1 > > > > In this case, I can take the destination ("192.0.2.1") and > verify it > > against the server's certificate. Provided we use a common root CA, > this > > setup is fully automatic. So supporting IPs is quite useful in this > > scenario. Please note that operators tend to use IP addresses over > > hostnames because of reliability reasons and early startup > capability > of > > the syslogd (before DNS resolutions is available). So this is of > > practical relevance. > > > > In case of the server authenticating the client, there is no such > > obvious choice. I could use the remote client's IP address (provided > by > > the transport stack) and verify that it matches the IP > address inside > > the certificate. However, is this really useful? IMO, this > is more or > > less a check if the remote cert is signed by a common CA. Something > that > > may be useful, but does not depend on the client's IP be known. > > > > Do you or somebody else on this list (Tom?) have a clue why > it may be > > useful to carry out such a check? > > > > Back on the topic of easy but still secure configuration, I could > > envision taken the reverse DNS name of the transport sender and > checking > > that against the identity presented in the certificate. Anyone any > > thoughts/comments on this? > > > > Again, all of this assumes a common root CA and > certificates signed by > > it (not necessarily full PKI, but an "in-house CA"). > > > > Thanks, > > Rainer > > _______________________________________________ > > 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 Mon May 26 22:52: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 7E7013A6B4C; Mon, 26 May 2008 22:52: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 2EA303A6B3A for ; Mon, 26 May 2008 22:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 47cyAMdLsePZ for ; Mon, 26 May 2008 22:52:36 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 56F2328C208 for ; Mon, 26 May 2008 22:52:21 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4R5pO9Z018052; Tue, 27 May 2008 08:51:45 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 May 2008 08:51:30 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 May 2008 08:51:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 May 2008 08:51:28 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72BDC304@vaebe104.NOE.Nokia.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312204FB5D64@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86VgB+nRUAAB+j5bAAAgUOIAAN6Qxg References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com><124CF5A7D55D6F43A4FD9437F28254D8EED6CB@ALPMLVEM05.e2k.ad.ge.com> <98AE08B66FAD1742BED6CB9522B7312204FB5D64@xmb-rtp-20d.amer.cisco.com> From: To: , X-OriginalArrivalTime: 27 May 2008 05:51:29.0948 (UTC) FILETIME=[B5C6ADC0:01C8BFBD] X-Nokia-AV: Clean Subject: Re: [Syslog] Some revised text for syslog TLS 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 Anton, If you want to work on specifying such structured data fields, that's fine (I agree that they could useful in many situations); but it's way too late to add anything this big to the syslog-transport-tls draft. So this would be a separate document. Best regards, Pasi > -----Original Message----- > From: Anton Okmyanskiy (aokmians) > Sent: 27 May, 2008 02:24 > To: Moehrke, John (GE Healthcare); Rainer Gerhards; Joseph > Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] Some revised text for syslog TLS > > The bottom line is that when you use a certificate to authenticate > the client, the trusted identity of the client that gets recorded in > the messages must be derived from certificate, not from other source > like IP address or whatever device or DNS says device might be. > > This can be handled by specifying appropriate tags (structured data > ID) for certificate fields and recommending that those are added to > the message (or updated) by the receiver if certificate-based > authenticate is used. > > This would prevent the case of some client using legitimate (but > stolen) certificate, and then indicating identity of another device > in the message itself. If such behavior were allowed, then when > certificate is stolen (but not yet put on certificate revocation > list), this would extend the security threat to a wider scope of > issues because we are allowing one device to masquerade as any other > device. > > Note, that we need structured data field IDs not only for > certificate Common Name (CN), but also for fields such as > fingerprint. When one certificate is revoked and a new one issues, > I believe the new one can have the same common name. In that case, > if the receiver wants to identify which exact certificate the client > used, you need to see the fingerprint or other similar certificate > fields. We had a use-case with customer where such information was > needed with TLS (albeit not in syslog context). > > Regards, > Anton. > > > > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Moehrke, John > > (GE Healthcare) > > Sent: Monday, May 26, 2008 3:16 PM > > To: Rainer Gerhards; Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: Re: [Syslog] Some revised text for syslog TLS > > > > I have said this before, but people continue to go down > this path... > > > > The TLS authentication has already proven that the 'other' > > side holds the private key... this is cryptographically > > secure authentication... > > > > Adding a check of the IP address or DNS address adds very > > very little value, and is not cryptographically secure > > (unless using Secure DNS). > > > > Therefore there is little value to adding IP or hostname > > checking, and lots of ways it will break (NAT, DHCP, etc). > > > > John > > > > > -----Original Message----- > > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > Behalf > > > Of Rainer Gerhards > > > Sent: Monday, May 26, 2008 2:19 AM > > > To: Joseph Salowey (jsalowey); syslog@ietf.org > > > Subject: Re: [Syslog] Some revised text for syslog TLS > > > > > > Joe, > > > > > > I like this new text. > > > > > > I am snipping everything below except the one thing that drives a > > > question: > > > > > > > o IP-address-based authorization where the IP address > > configured > > > > for the authorized peer is compared against the subject > fields in > > the > > > > certificate. Implementations MUST support matching the > > IP address > > > > against a SubjectAltName field of type iPAddress and > MAY support > > > > checking the configured IP address against the Common > Name portion > > of > > > > the Subject Distinguished Name. Matching for certificate > > credentials > > > > is > > > > performed using the matching rules specified by [3]. > If more than > > one > > > > IP Address identity is present in the certificate a match > > in any one > > > of > > > > the set is considered acceptable. > > > > > > I know that you asked about the usefulness of IP based > > authentication > > > before. I am now at a point where I have actually finished my > > > implementation and I am "polishing" it. On my agenda is now > > a as good > > as > > > possible *automatic* authentication. > > > > > > For the client to authorize the server, it is quite easy. There > > usually > > > is something like > > > > > > *.* @@192.0.2.1 > > > > > > In this case, I can take the destination ("192.0.2.1") and > > verify it > > > against the server's certificate. Provided we use a > common root CA, > > this > > > setup is fully automatic. So supporting IPs is quite > useful in this > > > scenario. Please note that operators tend to use IP > addresses over > > > hostnames because of reliability reasons and early startup > > capability > > of > > > the syslogd (before DNS resolutions is available). So this is of > > > practical relevance. > > > > > > In case of the server authenticating the client, there is no such > > > obvious choice. I could use the remote client's IP > address (provided > > by > > > the transport stack) and verify that it matches the IP > > address inside > > > the certificate. However, is this really useful? IMO, this > > is more or > > > less a check if the remote cert is signed by a common CA. > Something > > that > > > may be useful, but does not depend on the client's IP be known. > > > > > > Do you or somebody else on this list (Tom?) have a clue why > > it may be > > > useful to carry out such a check? > > > > > > Back on the topic of easy but still secure configuration, I could > > > envision taken the reverse DNS name of the transport sender and > > checking > > > that against the identity presented in the certificate. > Anyone any > > > thoughts/comments on this? > > > > > > Again, all of this assumes a common root CA and > > certificates signed by > > > it (not necessarily full PKI, but an "in-house CA"). > > > > > > Thanks, > > > Rainer > > > _______________________________________________ > > > 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 > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue May 27 10:22:18 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 A03253A6AF6; Tue, 27 May 2008 10:22:18 -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 C00A13A6AE7 for ; Tue, 27 May 2008 10:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 1BHKwKwIxySX for ; Tue, 27 May 2008 10:22:16 -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 88CB23A6AF6 for ; Tue, 27 May 2008 10:22:16 -0700 (PDT) X-Trace: 87546738/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.43 X-SBRS: None X-RemoteIP: 62.188.135.43 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFTgO0g+vIcr/2dsb2JhbACLb6IaAw X-IronPort-AV: E=Sophos;i="4.27,549,1204502400"; d="scan'208";a="87546738" X-IP-Direction: IN Received: from 1cust43.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.43]) by smtp.pipex.tiscali.co.uk with SMTP; 27 May 2008 18:22:18 +0100 Message-ID: <007701c8c015$2e530ca0$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , "Joseph Salowey \(jsalowey\)" , References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> Date: Tue, 27 May 2008 18:05:58 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] Some revised text for syslog TLS 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Going back to the first question... Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" ; Sent: Monday, May 26, 2008 9:18 AM Subject: Re: [Syslog] Some revised text for syslog TLS > Joe, > > I like this new text. > > I am snipping everything below except the one thing that drives a > question: > > > o IP-address-based authorization where the IP address configured > > for the authorized peer is compared against the subject fields in the > > certificate. Implementations MUST support matching the IP address > > against a SubjectAltName field of type iPAddress and MAY support > > checking the configured IP address against the Common Name portion of > > the Subject Distinguished Name. Matching for certificate credentials > > is > > performed using the matching rules specified by [3]. If more than one > > IP Address identity is present in the certificate a match in any one > of > > the set is considered acceptable. > > I know that you asked about the usefulness of IP based authentication > before. I am now at a point where I have actually finished my > implementation and I am "polishing" it. On my agenda is now a as good as > possible *automatic* authentication. > > For the client to authorize the server, it is quite easy. There usually > is something like > > *.* @@192.0.2.1 > > In this case, I can take the destination ("192.0.2.1") and verify it > against the server's certificate. Provided we use a common root CA, this > setup is fully automatic. So supporting IPs is quite useful in this > scenario. Please note that operators tend to use IP addresses over > hostnames because of reliability reasons and early startup capability of > the syslogd (before DNS resolutions is available). So this is of > practical relevance. > > In case of the server authenticating the client, there is no such > obvious choice. I could use the remote client's IP address (provided by > the transport stack) and verify that it matches the IP address inside > the certificate. However, is this really useful? IMO, this is more or > less a check if the remote cert is signed by a common CA. Something that > may be useful, but does not depend on the client's IP be known. > > Do you or somebody else on this list (Tom?) have a clue why it may be > useful to carry out such a check? You have lost me here. Suppose I am a server and I want to check that syslog only comes from someone I trust so I will configure an identifier in the server and want security credentials to authenticate an assertion of that identity. The IP address is the identity, and the certificate the security credential. Or the host name is the identity and the certificate the security credential. Or the MAC address is the identity and the certificate the security credential. I do not see a difference (except that some identities are commoner than others as Pasi points out). Tom Petch > > Back on the topic of easy but still secure configuration, I could > envision taken the reverse DNS name of the transport sender and checking > that against the identity presented in the certificate. Anyone any > thoughts/comments on this? > > Again, all of this assumes a common root CA and certificates signed by > it (not necessarily full PKI, but an "in-house CA"). > > Thanks, > Rainer > _______________________________________________ > 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 May 27 10:22:25 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 D0F3D3A6C34; Tue, 27 May 2008 10:22:25 -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 18A8D3A6C38 for ; Tue, 27 May 2008 10:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 TWRPVRqleMZN for ; Tue, 27 May 2008 10:22:23 -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 079EC3A6C35 for ; Tue, 27 May 2008 10:22:22 -0700 (PDT) X-Trace: 87546775/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.43 X-SBRS: None X-RemoteIP: 62.188.135.43 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFTgO0g+vIcr/2dsb2JhbACLb6IaAw X-IronPort-AV: E=Sophos;i="4.27,549,1204502400"; d="scan'208";a="87546775" X-IP-Direction: IN Received: from 1cust43.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.43]) by smtp.pipex.tiscali.co.uk with SMTP; 27 May 2008 18:22:26 +0100 Message-ID: <007901c8c015$3283be00$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , References: Date: Tue, 27 May 2008 18:15:28 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] Some revised text for syslog TLS 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Joe Looks good. Once we have sorted out the technicalities eg fingerprints and iPAddress, you might consider some polishing of the text, in two regards. In places, I have a sense of a security expert (which you are) talking to a security expert (which I am not) and think the text needs clarifying. eg "This consists validating proof of possession of the private key corresponding to the public key in the certificate". If this sentence were absent, I would not have noticed it; being there, I stop and think, what is it telling me, am I missing something? Or "Certificate path validation: the client is configured with one or more trust anchors"; ditto, if that were absent, I would not have noticed. And, as in the first sentence I quote, there seem to be some words or phrases missing; as I say, let's sort out any technical changes and then I will revisit the wording Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: Sent: Friday, May 23, 2008 8:40 PM Subject: [Syslog] Some revised text for syslog TLS > I reworked some of the text to try to capture the discussions in the > working group. I broke out the mechanical part of the validation from > the policy. There is some redundancy between the security > considerations section and the new policy section. I tried to focus the > requirements language on implementation requirements to enable secure > interoperability vs. deployment options. We are not finished yet, but I > think it is a step in the right direction. > > Cheers, > > Joe > > 4.2.1 Certificate-Based Authentication > > Both syslog transport sender (TLS Client) and syslog transport receiver > (TLS server) MUST implement certificate-based authentication. This > consists validating proof of possession of the private key corresponding > to the public key in the certificate. To ensure interoperability > between clients and servers, the following methods for certificate > validation are mandatory to implement: > > o Certificate path validation: the client is configured with one or > more trust anchors. Additional policy controls needed for authorizing > the syslog transport sender and syslog transport receiver are described > in Section 5. This method is useful where there is a PKI deployment. > > o End-Entity Certificate Matching: The transport receiver or > transport sender is configured with information necessary to match the > end-entity certificates of its authorized peers (which can be > self-signed). Implementations MUST support certificate fingerprints in > section 4.2.3 and MAY allow other formats for end-entity certificates > such as a DER encoded certificate. This method provides an alternative > to a PKI that is simpler to deploy and still maintains a reasonable > level of security. > > Both transport receiver and transport sender implementations MUST > provide a means to generate a key pair and self-signed certificate in > the case that a key pair and certificate are not available through > another mechanism. > > 4.2.2 Certificate Fingerprints > > Both client and server implementations MUST make the certificate > fingerprint for their certificates available through a management > interface. > > The mechanism to generate a fingerprint is to take the hash of the > certificate using a cryptographically strong algorithm and convert the > result into colon separated, hexadecimal bytes, each represented by 2 > uppercase ASCII characters. When a fingerprint value is displayed or > configured the fingerprint is prepended with an ASCII label identifying > the hash function followed by a colon. Implementations MUST support > SHA-1 as the hash algorithm and use the ASCII label "SHA1" to identify > the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the > length of the corresponding fingerprint string is 64 characters. An > example certificate fingerprint is: > > SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D > > > During validation the hash is extracted from the fingerprint and > compared against the hash calculated over the received certificate. > > [sections skipped] > > 5. Security Policies > > Different environments have different security requirements and > therefore would deploy different security policies. This section > provides discusses some of the security policies that may be implemented > by syslog transport receivers and syslog transport senders. The > security policies describe the requirements for authentication, > credential validation and authorization. The list of policies in this > section is not exhaustive and other policies may be implemented. > > 5.1 Recommended Security Policy > > The recommended security policy provides protection against the threats > in section 2. This policy requires authentication, certificate > validation and authorization of both the syslog transport sender and > syslog transport receiver. If there is a failure in the > authentication, certificate validation or authorization then the > connection is closed. > > Authorization requires the capability to authorize individual hosts as > transport receivers and transport senders. When end-entity certificate > matching is used, authentication and certificate validation are > sufficient to authorize and entity. When certificate path validation > MUST support the following authorization mechanisms: > > o Host-name-based authorization where the host name of the > authorized peer is compared against the subject fields in the > certificate. For the purpose of interoperability, implementations MUST > support matching the host name against a SubjectAltName field with a > type of dNSName and SHOULD support checking hostname against the Common > Name portion of the Subject Distinguished Name. Matching for > certificate credentials is performed using the matching rules specified > by [3]. If more than one host name identity is present in the > certificate a match in any one of the set is considered acceptable. > Implementations also MAY support wildcards to match a range of values. > For example, names to be matched against a certificate may contain the > wildcard character * which is considered to match any single domain name > component or component fragment. E.g., *.a.com matches foo.a.com but > not bar.foo.a.com. f*.com matches foo.com but not bar.com. Wildcards > make it possible to deploy trust-root-based authorization where all > credentials issued by a particular CA trust root are authorized. > > o IP-address-based authorization where the IP address configured > for the authorized peer is compared against the subject fields in the > certificate. Implementations MUST support matching the IP address > against a SubjectAltName field of type iPAddress and MAY support > checking the configured IP address against the Common Name portion of > the Subject Distinguished Name. Matching for certificate credentials is > performed using the matching rules specified by [3]. If more than one > IP Address identity is present in the certificate a match in any one of > the set is considered acceptable. > > Implementations MAY also support authorization based on other > attributes. For example, the authorization of a device Serial Number > against the SerialNumber portion of the Subject Distinguished Name or > restrictions on the depth of a certificate chain. > > Implementations MUST support this policy and it is recommended that this > be the default policy. > > 5.2 Liberal Validation of a Syslog Transport Sender > > In some environments, the authenticity of syslog data is not important > or it is verifiable by other means, so transport receivers may accept > data from any transport sender. To achieve this, the transport receiver > performs authentication and certificate consistency checks and forgoes > the validation of the certificate chain and authorization. In this > case, the transport receiver is authorized, however this policy does not > protect against the threat of transport sender masquerade described in > Section 2. The use of this policy is generally not recommended for this > reason. If this policy is used, the transport receiver SHOULD record > the end-entity certificate for the purpose of correlating it with the > sent data. > > 5.3 Liberal Validation of a Syslog Transport Receiver > > In some environments the confidentiality syslog data is not important so > data may be sent to any transport receiver. To achieve this the > transport sender performs authentication certificate consistency checks > and forgoes validation of the certificate chain and authorization. > While this policy does authorize the transport sender, it does not > protect against the threat of transport receiver masquerade described in > Section 2, leaving the data sent vulnerable to disclosure and > modification. The use of this policy is generally not recommended for > this reason. > > 5.4 Liberal Syslog Transport Receiver and Sender Validation > > In environments where security is not a concern at all the transport > receiver and transport sender authenticate each other and perform > certificate consistency checks and may forgo validation of the > certificate chain and authorization. This policy does not protect > against any of the threats described in section 2 and is therefore not > recommended. > > 6. Security Considerations > > 6.1 Deployment Issues > > Section 5 discusses various security policies that may be deployed. The > only configuration that mitigates the threats described in Section 2 is > the recommended policy defined in section 5.1. This is the recommended > configuration for deployments. > > If the transport receiver chooses not to fully authenticate, validate > and authorize the transport sender it may receive data from an attacker. > Unless it has another way of authenticating the source of the data, the > data should not be trusted. This is especially important if the syslog > data is going to be used to detect and react to security incidents. The > transport receiver may also increase its vulnerability to denial of > service, resource consumption and other attacks if it does not > authenticate the transport sender. Because of the increased > vulnerability to attack, this type of configuration is not recommended. > > If the transport sender chooses not to fully authenticate, validate and > authorize the syslog transport receiver then it may send data to an > attacker. This may disclose sensitive data within the log information > that is useful to an attacker resulting in further compromises within > the system. If a transport sender operates in this mode it should limit > the data it sends to data that is not valuable to an attacker. In > practice this is very difficult to achieve, so this type of > configuration is not recommended. > > Forgoing authentication, validation and/or authorization on both sides > allows for man-in-the-middle, masquerade and other types of attacks that > can completely compromise integrity and confidentiality of the data. > This type of configuration is not recommended. > > 6.2 Cipher Suites > > [I think the mandatory to implement algorithm should be defined in > section 4.2 instead of the security considerations section] > > > _______________________________________________ > 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 May 27 10:22:28 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 EF4973A6C3E; Tue, 27 May 2008 10:22:27 -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 C502D3A6C2F for ; Tue, 27 May 2008 10:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 MiQiaFiqIZ6m for ; Tue, 27 May 2008 10:22:20 -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 2228F3A6950 for ; Tue, 27 May 2008 10:22:19 -0700 (PDT) X-Trace: 87546762/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.43 X-SBRS: None X-RemoteIP: 62.188.135.43 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFTgO0g+vIcr/2dsb2JhbACLb6IaAw X-IronPort-AV: E=Sophos;i="4.27,549,1204502400"; d="scan'208";a="87546762" X-IP-Direction: IN Received: from 1cust43.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.43]) by smtp.pipex.tiscali.co.uk with SMTP; 27 May 2008 18:22:21 +0100 Message-ID: <007801c8c015$31cb1c60$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com><1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com><1211806792.27593.11.camel@localhost.localdomain><1696498986EFEC4D9153717DA325CB72B36AAC@vaebe104.NOE.Nokia.com> <577465F99B41C842AAFBE9ED71E70ABA3090A9@grfint2.intern.adiscon.com> Date: Tue, 27 May 2008 18:06:45 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] Some revised text for syslog TLS 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Monday, May 26, 2008 3:26 PM Subject: Re: [Syslog] Some revised text for syslog TLS > > > Please keep in mind that my message was related to the question if > > > there is a use case for using IPs inside a certificate. As I said > > > above, there is. > > > > Ok. Do you think this use case is important enough to keep this > > feature (checking IPAddress subjectAltName) as part of the "MUST > > implement" baseline? > > No, I don't think it is a MUST. > But I would like it to be a SHOULD. Tom Petch > > (Joe's latest text already has other forms of name comparison as > > optional: "Implementations MAY also support authorization based on > > other attributes. For example, the authorization of a device Serial > > Number against the SerialNumber portion of the Subject Distinguished > > Name [...]") > > This should take care of it well enough. > > Rainer > _______________________________________________ > 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 Wed May 28 01:03:22 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 862523A6C9C; Wed, 28 May 2008 01:03:21 -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 CA9C83A6C8F for ; Wed, 28 May 2008 01:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 1P7q9C9v8F79 for ; Wed, 28 May 2008 01:02:32 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id EAA223A6C9B for ; Wed, 28 May 2008 01:00:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 9F1E47AD6DD for ; Wed, 28 May 2008 09:59:56 +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 F0YoOhd4WppR for ; Wed, 28 May 2008 09:59:56 +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 623637AD5EF for ; Wed, 28 May 2008 09:59:56 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 10:00:59 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3090BD@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls-12+ implementation report Thread-Index: AcjAmPdiFYKDfN+KRvuk1IlWewm81w== From: "Rainer Gerhards" To: Subject: [Syslog] -transport-tls-12+ implementation report 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 WG, I have finished my implementation of -transport-tls-12 plus Joe's latest text. I have written an implementation report which you can find at http://blog.gerhards.net/2008/05/syslog-transport-tls-12-implementation. html This post is rather long. But it sums up my experience of roughly three weeks of implementation, so it needs to be. I have identified a number of problem spots, defined a rsyslog-specific policy suitable for many use cases and come to the conclusion that -transport-tls is doing quite well. If you have any feedback on the report, I would love to hear it. Please note that the report's intension is not to mandate changes to -transport-tls but to provide honest feedback from someone who implemented it. Joe's latest text is quite OK, the only change I would very much like to see is to remove the MUST on ipAddress authentication. Please note that the implementation is actually available to anyone. You can simply download it from http://www.rsyslog.com. I know of at least one actual deployment by a real user and expect the number to grow in the coming weeks. I will also continue to fine-tune the implementation and, if at all possible, keep up with changes to the draft. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 01:36:45 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 53F283A6C9E; Wed, 28 May 2008 01:36:45 -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 E04F33A6BAA for ; Wed, 28 May 2008 01:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Mii8Ui0r7eAK for ; Wed, 28 May 2008 01:36:35 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 9EEC83A6CB2 for ; Wed, 28 May 2008 01:35:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id A13B97AD6D3; Wed, 28 May 2008 10:34:44 +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 NhdKyDMxzZ7B; Wed, 28 May 2008 10:34:44 +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 67FD27AD5EF; Wed, 28 May 2008 10:34:44 +0200 (CEST) Content-class: urn:content-classes:message Date: Wed, 28 May 2008 10:35:55 +0200 MIME-Version: 1.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3090C1@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <007701c8c015$2e530ca0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: AcjALtaDi4KPokoPR+WREK3X8REvbQAbZb0g References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <007701c8c015$2e530ca0$0601a8c0@allison> From: "Rainer Gerhards" To: "tom.petch" , "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] Some revised text for syslog TLS 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 Tom, inline... > > Do you or somebody else on this list (Tom?) have a clue why it may be > > useful to carry out such a check? (EDIT: check of IP address) > > You have lost me here. Suppose I am a server and I want to check that > syslog > only comes from someone I trust so I will configure an identifier in > the server > and want security credentials to authenticate an assertion of that > identity. > The IP address is the identity, and the certificate the security > credential. > > Or the host name is the identity and the certificate the security > credential. > > Or the MAC address is the identity and the certificate the security > credential. > > I do not see a difference (except that some identities are commoner > than others > as Pasi points out). What is common is a big point. I think ipAddress inside certificates is quite uncommon, so this may be a good indication that it doesn't justify a MUST. I have also thought about when this may be used at all. IMHO, this makes only sense if the transport sender uses a proxy or is behind NAT. Using a proxy for syslog senders is extremely uncommon. Being behind NAT is uncommon (usually, syslog is not transmitted to the public Internet). The remaining threat I see is that someone on the same local network poisons ARP with a spoofed IP address and they tries to fool the syslog server in listening to it. While possible, I think this is also quite remote (but remote is not a good argument when it comes to security, I know). What matters more is that this attack will NOT work if the subject's name is checked against the certificate. So what is the extra benefit of authorizing based on IP address? What is the advantage of it? Is that so important that every syslog application implementing MUST support it? I am even in doubt if if justifies a SHOULD. To me it looks MAY would be sufficient, and this is covered by the text. So I think the whole paragraph on ipAddress authentication can simply be removed. As a side-note, authentication based on IP addresses is even problematic. In my experience IP ranges are more likely to change than names, so sticking with names reduces the administrative cost when a change is needed. Rainer > > Tom Petch _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 06:24:02 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 D540E3A69EA; Wed, 28 May 2008 06:24:02 -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 5878A3A69EA; Wed, 28 May 2008 06:24:01 -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 X3+WE-QSUPs1; Wed, 28 May 2008 06:23:55 -0700 (PDT) Received: from mornm02-out.agfa.com (mornm02-out.agfa.com [134.54.1.77]) by core3.amsl.com (Postfix) with ESMTP id 13E9C3A698B; Wed, 28 May 2008 06:23:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,555,1204498800"; d="scan'208";a="41090824" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm02-out.agfa.com with ESMTP; 28 May 2008 15:23:48 +0200 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA3090C1@grfint2.intern.adiscon.com> To: rgerhards@hq.adiscon.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Wed, 28 May 2008 09:23:43 -0400 Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] Some revised text for syslog TLS 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 The new text looks close. I agree with Rainer that the MUST on checking IP Address should drop to a MAY, or better yet be removed entirely. It could be subsumed within the general ability to check various content fields within the certificate. I find that CN is much more useful. A MAY for CN checking makes much more sense to me. I think that this is just a leftover from someone's particular use case, rather than based on a real security analysis. Passing the certificate test means that both sides have demonstrated that they know their own private keys. That is the good mandatory check. If either side does not know their own private key you have strong evidence that they are not who they claim to be. The real system will always know its own private keys. IP address is just a special case. Passing the certificate test does not mean 100% certainty for authentication. There is always the risk that the machine has not protected its private keys. They can be stolen and the machine can be penetrated. Perhaps someone could explain why the presence of the IP Address in the certificate should automatically imply that security has been compromised. Plus why does matching IP address in certificate and network eliminate that implication. I can think of special use cases where this is the case, but by making it a MUST the RFC makes this is a global statement. In practice, if the MUST goes through I'll just make formal policy recommendations that healthcare never include IP Address in certificates. This is a reasonable recommendation anyhow. In the present world of NAT, DHCP, IPv6 negotiation, mobile machines, etc. the IP address is rather unstable. It doesn't make sense to put it into certificates. If really pressed, I might mention that there is also a minor bug in the syslog-tls RFC. Kind Regards, Robert Horn | Agfa HealthCare Research Scientist | HE/Technology Office T +1 978 897 4860 Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 07660-2199, United States http://www.agfa.com/healthcare/ Click on link to read important disclaimer: http://www.agfa.com/healthcare/maildisclaimer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 07:57:20 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 5402C3A6A8C; Wed, 28 May 2008 07:57:20 -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 B60B43A6A8C for ; Wed, 28 May 2008 07:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 gn+bMkdApTRl for ; Wed, 28 May 2008 07:57:13 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id C521928C13D for ; Wed, 28 May 2008 07:57:12 -0700 (PDT) X-Trace: 35087263/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.30 X-SBRS: None X-RemoteIP: 213.116.60.30 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEACMPPUjVdDwe/2dsb2JhbACLaqJUAw X-IronPort-AV: E=Sophos;i="4.27,555,1204502400"; d="scan'208";a="35087263" X-IP-Direction: IN Received: from 1cust30.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.30]) by smtp.pipex.tiscali.co.uk with SMTP; 28 May 2008 15:57:14 +0100 Message-ID: <009a01c8c0ca$14fb4f00$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , "Joseph Salowey \(jsalowey\)" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <007701c8c015$2e530ca0$0601a8c0@allison> <577465F99B41C842AAFBE9ED71E70ABA3090C1@grfint2.intern.adiscon.com> Date: Wed, 28 May 2008 15:51:24 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] Some revised text for syslog TLS 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Inline Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "tom.petch" ; "Joseph Salowey (jsalowey)" ; Sent: Wednesday, May 28, 2008 10:35 AM Subject: RE: [Syslog] Some revised text for syslog TLS Tom, inline... > > Do you or somebody else on this list (Tom?) have a clue why it may be > > useful to carry out such a check? (EDIT: check of IP address) > > You have lost me here. Suppose I am a server and I want to check that > syslog > only comes from someone I trust so I will configure an identifier in > the server > and want security credentials to authenticate an assertion of that > identity. > The IP address is the identity, and the certificate the security > credential. > > Or the host name is the identity and the certificate the security > credential. > > Or the MAC address is the identity and the certificate the security > credential. > > I do not see a difference (except that some identities are commoner > than others > as Pasi points out). What is common is a big point. I think ipAddress inside certificates is quite uncommon, so this may be a good indication that it doesn't justify a MUST. I have also thought about when this may be used at all. IMHO, this makes only sense if the transport sender uses a proxy or is behind NAT. Using a proxy for syslog senders is extremely uncommon. Being behind NAT is uncommon (usually, syslog is not transmitted to the public Internet). The remaining threat I see is that someone on the same local network poisons ARP with a spoofed IP address and they tries to fool the syslog server in listening to it. While possible, I think this is also quite remote (but remote is not a good argument when it comes to security, I know). What matters more is that this attack will NOT work if the subject's name is checked against the certificate. So what is the extra benefit of authorizing based on IP address? What is the advantage of it? Is that so important that every syslog application implementing MUST support it? I am even in doubt if if justifies a SHOULD. To me it looks MAY would be sufficient, and this is covered by the text. So I think the whole paragraph on ipAddress authentication can simply be removed. As a side-note, authentication based on IP addresses is even problematic. In my experience IP ranges are more likely to change than names, so sticking with names reduces the administrative cost when a change is needed. I encounter networks where the devices do not have names, in any meaningful manner (perhaps just a default sysName left in by the manufacturer). Boxes are identified by address, layer 2 - MAC - or layer 3 - IP. What I am resisting is the need to allocate and maintain a namespace where none exists at present. This use of IP address is independent of what appears in the IP header of the packet; here it is serving as an identity for the box not as something to put in the source field of the IP header. In theory, if the IP address of the device changed, then you could keep the old address as an identity but I think that would be too bizarre. Tom Petch Rainer > > Tom Petch _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 08:40:55 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 F2C673A69F3; Wed, 28 May 2008 08:40:54 -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 17F183A6830 for ; Wed, 28 May 2008 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 J3qkzB4PbpBZ for ; Wed, 28 May 2008 08:40:52 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 77A9B3A69F3 for ; Wed, 28 May 2008 08:40:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 3655F7AD620 for ; Wed, 28 May 2008 17:38:17 +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 ynvCZib-BxeA for ; Wed, 28 May 2008 17:38:17 +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 0BB2E7AD60D for ; Wed, 28 May 2008 17:38:17 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 May 2008 17:40:56 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -transport-tls references to "matching rules" Thread-Index: AcjA2TgdxM9hxz6gQfGWuoXCPTGvZA== From: "Rainer Gerhards" To: Subject: [Syslog] -transport-tls references to "matching rules" 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, -transport-tls refers (as [3] to RFC 5280), e.g. "Matching for certificate credentials is performed using the matching rules specified by [3]." I am revisiting 5280 to find the matching rules for ipAddress. However, this is a nearly 150 page document and I admit I do not know its ins and outs. It would be really helpful if a section is mentioned inside the reference so that one can quickly look up the rules. And, a hopefully quick question, where do I find the rules for ipAddress? I was unable to bring it up on a quick look. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 08:55:00 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 C96673A6CA9; Wed, 28 May 2008 08:54:59 -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 3751F3A6AC7 for ; Wed, 28 May 2008 08:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_35=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 eU3yyvOZk2CF for ; Wed, 28 May 2008 08:54:55 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id D13BE28C12F for ; Wed, 28 May 2008 08:50:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 564E17AD762; Wed, 28 May 2008 17:47:45 +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 Ud7tVOKrenN1; Wed, 28 May 2008 17:47:45 +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 1E2C17AD6FB; Wed, 28 May 2008 17:47:45 +0200 (CEST) Received: from [172.19.2.1] ([172.19.2.1]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 May 2008 17:50:26 +0200 From: Rainer Gerhards To: "tom.petch" In-Reply-To: <009a01c8c0ca$14fb4f00$0601a8c0@allison> References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <007701c8c015$2e530ca0$0601a8c0@allison> <577465F99B41C842AAFBE9ED71E70ABA3090C1@grfint2.intern.adiscon.com> <009a01c8c0ca$14fb4f00$0601a8c0@allison> Date: Wed, 28 May 2008 17:50:28 +0200 Message-Id: <1211989828.16825.14.camel@rgf9dev.intern.adiscon.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 (2.22.1-2.fc9) X-OriginalArrivalTime: 28 May 2008 15:50:26.0706 (UTC) FILETIME=[8C2A8720:01C8C0DA] Cc: syslog Subject: Re: [Syslog] Some revised text for syslog TLS 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 Tom, On Wed, 2008-05-28 at 15:51 +0200, tom.petch wrote: > I encounter networks where the devices do not have names, in any meaningful > manner (perhaps just a default sysName left in by the manufacturer). Boxes are > identified by address, layer 2 - MAC - or layer 3 - IP. What I am resisting is > the need to allocate and maintain a namespace where none exists at present. > > This use of IP address is independent of what appears in the IP header of the > packet; here it is serving as an identity for the box not as something to put in > the source field of the IP header. In theory, if the IP address of the device > changed, then you could keep the old address as an identity but I think that > would be too bizarre. > > Tom Petch I see your point. I always looked from the security perspective, but that isn't what you are trying to achieve. It is the need not to start another new name space... OK. >From the implementors POV, I think ipAddress will bring in another set of matching rules (you've probably seen my other message on this topic). I have seen that, for example, I must support IP range matching. It also looks like I need to do netmask based matching. Of course, all of this is not rocket science. It may even be already used in other parts of the same program. I still wonder if we should really require every implementation to carry all that additional code just to permit this scenario which, to be honest, seems to be a quite uncommon case. May it be a good work-around to simply use the reverse DNS ptr names as the subject alt name? Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 17:31:50 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 383A43A6A50; Wed, 28 May 2008 17:31:50 -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 EDEA73A6A8C for ; Wed, 28 May 2008 17:31:48 -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 BUBS3Y2FUq0R for ; Wed, 28 May 2008 17:31:46 -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 A83AF28C149 for ; Wed, 28 May 2008 17:30:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,558,1204531200"; d="scan'208";a="105275231" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 May 2008 17:30:55 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4T0UtHT030993; Wed, 28 May 2008 17:30:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4T0UtdC022486; Thu, 29 May 2008 00:30:55 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 17:30:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 17:31:41 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Fingerprint/handshake Thread-Index: Aci597ZxZLhWgaMcSke8NLzWgHaUOAABInCQAT9t6xAAii+fYA== References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 29 May 2008 00:30:55.0113 (UTC) FILETIME=[41BF4790:01C8C123] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4090; t=1212021055; x=1212885055; c=relaxed/simple; s=sjdkim3002; 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]=20Fingerprint/handshake |Sender:=20; bh=TK+uPQFiOBlzyT5hvr4T+VoTYwmU17vOA5DIDDr2ZOo=; b=AJSG8D2jrXxBxLzIggNLI68CFEWJdeOk9Bp0XKJyV4iHL9CN1DfrghSefP DziwJvU8A+BgoLx6zry8XT9n5YVIrcKpvvhGn2aeGy8TfkDKUey7C3JZEiUR 7DJQribA5B; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Syslog] Fingerprint/handshake 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 Rainer, A TLS alert could be sent by the server indicating the error condition. Would this help? Joe > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Sunday, May 25, 2008 11:46 PM > To: Joseph Salowey (jsalowey); syslog@ietf.org > Subject: RE: [Syslog] Fingerprint/handshake > > Hi Joe, > > inline > > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Friday, May 23, 2008 8:21 PM > > To: Rainer Gerhards; syslog@ietf.org > > Subject: RE: [Syslog] Fingerprint/handshake > > > > The fingerprint check should be done where certificate validation > would > > be done. This is typically done within the handshake itself, > > I agree to this, but have found this to be problematic with > some TLS libraries. Of course, that doesn't mean the standard > needs to change, but I would still like to provide some > implementation feedback. > > With GnuTLS, for example, you can do the final authentication > only after the handshake [1]. With NSS, it can be done during > the handshake. As of my understanding, OpenSSL does support > it after the handshake only (but I have not actually used > OpenSSL, this is based on my understanding after reading > doc). This brings me to the conclusion that, at least in some > environments I may be forced to delay the authentication > check to after the handshake. > [Joe] Its been a while since I used OpenSSL, but if I remember correctly they do have hooks in the certificate validation code. > > because if > > the validation fails you do not want to send or receive data on the > > connection. I suppose you could implement the check after the > > handshake, but you need to make sure you do not send or receive > > application before successful validation has occurred. > > This is where it gets really problematic. We get into a race > condition here. Remember that syslog is simplex and works > without any app-level acks (in -transport-tls). > > If the client authenticates the server, everything is fine. > Authentication fails, client never sends data and the session > is terminated. Everything is fine. > > But if the server authenticates the client (and > authentication fails), the client will still receive the > server's TLS Finished message. After that, the server drop > connection. HOWEVER, the client blindly sending data doesn't > know this until at least the second message sent (due to > local buffering at the client). *After* some messages, the > client gets a connection broken indication, but at this point > it is too late to react intelligently. In essence, those > messages sent after the initial handshake are lost. Even > worse, the client "gets the impression" that the remote > server is accepting its connection requests. This is because > there is no failure indication after the handshake. This can > lead to more frequent retries. > > This problem is rooted in the underlying plain tcp transport. > I have described it in [2]. It's inherent to all plain tcp > syslog implementations. RFC3195 is a cure for it. With TLS > auth, it just gets to a new magnitude as it will now happen > every time during a failed authentication. > > This is not a theoretic issue but one I can reliable > reproduce in my lab with actual software. Actually, I am > unable to NOT reproduce it - there is no work-around for this > problem (at least I have found none). > > Again, I am not trying to say we need to change anything. I > am providing real world feedback. It may be worth, however, > adding a note or two to the I-D describing these issues. > > Rainer > > [1] > http://lists.gnu.org/archive/html/help-gnutls/2008-05/msg00017.html > (full conversation, long) > [2] > http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp > -syslog.ht > ml > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 17:37: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 C93603A6A91; Wed, 28 May 2008 17:37: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 17B983A680C for ; Wed, 28 May 2008 17:37:42 -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 eRyHqpqvJtIC for ; Wed, 28 May 2008 17:37:41 -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 2D1DD3A6A91 for ; Wed, 28 May 2008 17:37:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,558,1204531200"; d="scan'208";a="105277583" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 May 2008 17:37:45 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4T0bjRW013676; Wed, 28 May 2008 17:37:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4T0bjFo026373; Thu, 29 May 2008 00:37:45 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 17:37:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 17:38:32 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309092@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] same certificate for client and sender? Thread-Index: Aci+/Wv05mX/uIqNQPCrPGQr9wEUdQCJhIaQ References: <577465F99B41C842AAFBE9ED71E70ABA309092@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 29 May 2008 00:37:45.0475 (UTC) FILETIME=[36578D30:01C8C124] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1390; t=1212021465; x=1212885465; c=relaxed/simple; s=sjdkim4002; 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]=20same=20certificate=20for=20c lient=20and=20sender? |Sender:=20; bh=/Tn3InX8jDNWbK087oYbUU4/u24XRzNYObG98/yVkrs=; b=q+lXiMoqBU86ATzytuYNuov6TGpOqUW0CeZnUOi68bIA8TP1rgaY+y5ejk 9i6rMRCbYha1cirQGVf/cyKyhAXFcmqHia/vb2w6Z5QGCYkuXCFiCQaJVuAY i33RU38BBx; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] same certificate for client and sender? 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 I don't see a security issue with using the same certificate for both receiver and sender in the case of a relay. It would be possible to create a policy based on a certificate extension that would limit the use of a certificate to a receiver or sender, but this is not specified in the current proposal. Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Sunday, May 25, 2008 11:55 PM > To: syslog@ietf.org > Subject: [Syslog] same certificate for client and sender? > > Hi all, > > If I look at a relay, it is both a transport receiver and > transport sender. And, of course, it is a single software > entity. In my implementation I am currently using a single > certificate on relays - both being used for the sender as > well as the receiver. While this is natural, I am not sure if > it is secure. > > Could you advise on what is reasonable secure in a relay environment? > Note, however, that using different certificates may finally > disable any remaining auto-configuration capabilities (which > I have with a single certificate). > > Feedback is appreciated. > > Rainer > _______________________________________________ > 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 Wed May 28 17:41: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 79BA83A685F; Wed, 28 May 2008 17:41: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 58C903A680C for ; Wed, 28 May 2008 17:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 YSRfmr5uws5l for ; Wed, 28 May 2008 17:41:31 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C92A43A6CDD for ; Wed, 28 May 2008 17:41:16 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4T0fKIB023916; Thu, 29 May 2008 03:41:21 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 May 2008 03:41:20 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 May 2008 03:41:20 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 03:41:19 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72C23647@vaebe104.NOE.Nokia.com> In-Reply-To: <1211989828.16825.14.camel@rgf9dev.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Some revised text for syslog TLS Thread-Index: AcjA25o5SvsKHLcmRiu2OdsTwNcRMgARPIcw References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com><007701c8c015$2e530ca0$0601a8c0@allison><577465F99B41C842AAFBE9ED71E70ABA3090C1@grfint2.intern.adiscon.com><009a01c8c0ca$14fb4f00$0601a8c0@allison> <1211989828.16825.14.camel@rgf9dev.intern.adiscon.com> From: To: X-OriginalArrivalTime: 29 May 2008 00:41:20.0342 (UTC) FILETIME=[B669A760:01C8C124] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Some revised text for syslog TLS 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 Rainer Gerhards wrote: > May it be a good work-around to simply use the reverse DNS ptr names > as the subject alt name? No, I don't think this would be a good work-around. An implementation should never compare the result of a PTR lookup against a host name in the certificate (doing so would give the impression that it's done for some security reason, but it doesn't seem to provide any security benefit). Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed May 28 18:00:41 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 293023A6969; Wed, 28 May 2008 18:00:41 -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 A30863A6807 for ; Wed, 28 May 2008 18:00:34 -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 nJ39N-sMZVwQ for ; Wed, 28 May 2008 18:00:30 -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 29BA03A6B92 for ; Wed, 28 May 2008 17:59:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,558,1204531200"; d="scan'208";a="73386332" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 28 May 2008 17:59:58 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4T0xwss019425; Wed, 28 May 2008 17:59:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4T0xw0c010246; Thu, 29 May 2008 00:59:58 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 17:59:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 18:00:45 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls references to "matching rules" Thread-Index: AcjA2TgdxM9hxz6gQfGWuoXCPTGvZAATJaYQ References: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 29 May 2008 00:59:58.0651 (UTC) FILETIME=[50FA10B0:01C8C127] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1510; t=1212022798; x=1212886798; 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]=20-transport-tls=20references= 20to=20=22matching=20rules=22 |Sender:=20; bh=gQvfbCWgjhqT4tPqQEZlfsiy1DBLPM9G5MMHUNAokaY=; b=LaT2ZZICRq+5dL9RjGVyEvRAombbHZJ+a3G2lMmjudE7FbXkWQWhI5K1lh zKJYzF0cY3e3MRLA48NEB+9WAZ6lX91DrARGK85/b8Redk2X15vkZYbEbdor 5DAoB23ibDAlA4DtRk8gzb1zy0jdvXW3XtYNiO1ZmQoORkSm544Ho=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] -transport-tls references to "matching rules" 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 The only place 5280 goes into great detail about matching is with internationalized names. I don't think it specifies any specific rules for matching the iPaddress within a subjectAltName. This is left up to the definition by the application making use of the certificates. I'm not sure we need to standardize matching behavior unless it affects the representation within the certificates (for example including wildcards in the identities). Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, May 28, 2008 8:41 AM > To: syslog@ietf.org > Subject: [Syslog] -transport-tls references to "matching rules" > > Hi, > > -transport-tls refers (as [3] to RFC 5280), e.g. "Matching > for certificate credentials is performed using the matching > rules specified by [3]." I am revisiting 5280 to find the > matching rules for ipAddress. However, this is a nearly 150 > page document and I admit I do not know its ins and outs. It > would be really helpful if a section is mentioned inside the > reference so that one can quickly look up the rules. > > And, a hopefully quick question, where do I find the rules > for ipAddress? I was unable to bring it up on a quick look. > > Thanks, > Rainer > _______________________________________________ > 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 Wed May 28 18:09:22 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 907A63A67EB; Wed, 28 May 2008 18:09:22 -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 9E15E3A67EB; Wed, 28 May 2008 18:09:21 -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 p-wOCg9L4Taf; Wed, 28 May 2008 18:09:15 -0700 (PDT) Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75]) by core3.amsl.com (Postfix) with ESMTP id D053C3A67AA; Wed, 28 May 2008 18:09:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,558,1204498800"; d="scan'208";a="46616318" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm01-out.agfa.com with ESMTP; 29 May 2008 03:09:05 +0200 In-Reply-To: To: jsalowey@cisco.com MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Wed, 28 May 2008 21:09:01 -0400 Cc: syslog@ietf.org, syslog-bounces@ietf.org Subject: Re: [Syslog] same certificate for client and sender? 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 I've seen security policies go both ways on this, so it's best for syslog to remain silent. There are times when the relay should use the same cert for both and other times when it should be different. Kind Regards, Robert Horn | Agfa HealthCare Research Scientist | HE/Technology Office T +1 978 897 4860 Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 07660-2199, United States http://www.agfa.com/healthcare/ Click on link to read important disclaimer: http://www.agfa.com/healthcare/maildisclaimer "Joseph Salowey (jsalowey)" Sent by: syslog-bounces@ietf.org 05/28/2008 08:38 PM To "Rainer Gerhards" , cc Subject Re: [Syslog] same certificate for client and sender? I don't see a security issue with using the same certificate for both receiver and sender in the case of a relay. It would be possible to create a policy based on a certificate extension that would limit the use of a certificate to a receiver or sender, but this is not specified in the current proposal. Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Sunday, May 25, 2008 11:55 PM > To: syslog@ietf.org > Subject: [Syslog] same certificate for client and sender? > > Hi all, > > If I look at a relay, it is both a transport receiver and > transport sender. And, of course, it is a single software > entity. In my implementation I am currently using a single > certificate on relays - both being used for the sender as > well as the receiver. While this is natural, I am not sure if > it is secure. > > Could you advise on what is reasonable secure in a relay environment? > Note, however, that using different certificates may finally > disable any remaining auto-configuration capabilities (which > I have with a single certificate). > > Feedback is appreciated. > > Rainer > _______________________________________________ > 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 Wed May 28 23:21:15 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 53BAA28C221; Wed, 28 May 2008 23:21:15 -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 BB58828C235 for ; Wed, 28 May 2008 23:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 Q5a7MJz03DL8 for ; Wed, 28 May 2008 23:21:13 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 9E0BE28C219 for ; Wed, 28 May 2008 23:21:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 0E3977AD71D; Thu, 29 May 2008 08:19:56 +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 bQVaHBUA0kJn; Thu, 29 May 2008 08:19:55 +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 BFD317AC275; Thu, 29 May 2008 08:19:55 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 08:21:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3090E0@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -transport-tls references to "matching rules" Thread-Index: AcjA2TgdxM9hxz6gQfGWuoXCPTGvZAATJaYQAAuFRYA= References: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" Cc: syslog@ietf.org Subject: Re: [Syslog] -transport-tls references to "matching rules" 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 Mhhh... Wouldn't it then be appropriate to drop these sentences from transport-tls: ### Matching for certificate credentials is performed using the matching rules specified by [3]. ### They created the impression (at least for me), I need to look up the rule in 5280 in order to implement -tls correctly. As you now say, this is not the case (it may be with internationalized names on subject name matching, but it seems not to be in other cases, namely for ipAddress, where it is specified, too). Rainer > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Thursday, May 29, 2008 3:01 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] -transport-tls references to "matching rules" > > The only place 5280 goes into great detail about matching is with > internationalized names. I don't think it specifies any specific rules > for matching the iPaddress within a subjectAltName. This is left up > to > the definition by the application making use of the certificates. I'm > not sure we need to standardize matching behavior unless it affects the > representation within the certificates (for example including wildcards > in the identities). > > Joe > > > > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > > Sent: Wednesday, May 28, 2008 8:41 AM > > To: syslog@ietf.org > > Subject: [Syslog] -transport-tls references to "matching rules" > > > > Hi, > > > > -transport-tls refers (as [3] to RFC 5280), e.g. "Matching > > for certificate credentials is performed using the matching > > rules specified by [3]." I am revisiting 5280 to find the > > matching rules for ipAddress. However, this is a nearly 150 > > page document and I admit I do not know its ins and outs. It > > would be really helpful if a section is mentioned inside the > > reference so that one can quickly look up the rules. > > > > And, a hopefully quick question, where do I find the rules > > for ipAddress? I was unable to bring it up on a quick look. > > > > Thanks, > > Rainer > > _______________________________________________ > > 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 May 29 00:48:05 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 538473A6982; Thu, 29 May 2008 00:48:05 -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 CD8033A6998 for ; Thu, 29 May 2008 00:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 RH0HeFkEVSjp for ; Thu, 29 May 2008 00:48:03 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 06E2928C1BE for ; Thu, 29 May 2008 00:45:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id D20727AD809; Thu, 29 May 2008 09:43:42 +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 XA6hHlDTmQIz; Thu, 29 May 2008 09:43:42 +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 9AC897AD770; Thu, 29 May 2008 09:43:42 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 09:45:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA3090E1@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Fingerprint/handshake Thread-Index: Aci597ZxZLhWgaMcSke8NLzWgHaUOAABInCQAT9t6xAAii+fYAAPM9Dg References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , Subject: Re: [Syslog] Fingerprint/handshake 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 Inline... > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Thursday, May 29, 2008 2:32 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Fingerprint/handshake > = > Hi Rainer, > = > A TLS alert could be sent by the server indicating the error condition. > Would this help? That's an interesting idea. Let me give it a try. Will provide feedback whe= n I have done this. In any case, if it turns out to be a problem with one l= ibrary, we may be better of mandating that all verification is done during = the handshake... > = > Joe > = > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Sunday, May 25, 2008 11:46 PM > > To: Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: RE: [Syslog] Fingerprint/handshake > > > > Hi Joe, > > > > inline > > > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Friday, May 23, 2008 8:21 PM > > > To: Rainer Gerhards; syslog@ietf.org > > > Subject: RE: [Syslog] Fingerprint/handshake > > > > > > The fingerprint check should be done where certificate validation > > would > > > be done. This is typically done within the handshake itself, > > > > I agree to this, but have found this to be problematic with > > some TLS libraries. Of course, that doesn't mean the standard > > needs to change, but I would still like to provide some > > implementation feedback. > > > > With GnuTLS, for example, you can do the final authentication > > only after the handshake [1]. With NSS, it can be done during > > the handshake. As of my understanding, OpenSSL does support > > it after the handshake only (but I have not actually used > > OpenSSL, this is based on my understanding after reading > > doc). This brings me to the conclusion that, at least in some > > environments I may be forced to delay the authentication > > check to after the handshake. > > > [Joe] Its been a while since I used OpenSSL, but if I remember > correctly > they do have hooks in the certificate validation code. [Rainer] From what I have seen in the doc, this does not permit to do all checks. Mo= st importantly, it looked like I am not able to check the fingerprint and s= ubject name. But fortunately Martin Sch=FCtte is using openSSL for his impl= ementation and I hope he can provide feedback on this in the not so distant= future. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 29 01:12:10 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 0520B3A696F; Thu, 29 May 2008 01:12:10 -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 21A5B3A6918 for ; Thu, 29 May 2008 01:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.595 X-Spam-Level: ** X-Spam-Status: No, score=2.595 tagged_above=-999 required=5 tests=[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 1Px8prVjtx9i for ; Thu, 29 May 2008 01:12:08 -0700 (PDT) Received: from lists.balabit.hu (support.balabit.hu [195.70.41.86]) by core3.amsl.com (Postfix) with ESMTP id 50BDC3A696F for ; Thu, 29 May 2008 01:12:07 -0700 (PDT) Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 0DBBE2760CE for ; Thu, 29 May 2008 10:12:04 +0200 (CEST) From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA3090E1@grfint2.intern.adiscon.com> References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA3090E1@grfint2.intern.adiscon.com> Date: Thu, 29 May 2008 10:12:04 +0200 Message-Id: <1212048724.28540.29.camel@bzorp.balabit> Mime-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] Fingerprint/handshake 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 On Thu, 2008-05-29 at 09:45 +0200, Rainer Gerhards wrote: > Inline... > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Thursday, May 29, 2008 2:32 AM > > To: Rainer Gerhards; syslog@ietf.org > > Subject: RE: [Syslog] Fingerprint/handshake > > > > Hi Rainer, > > > > A TLS alert could be sent by the server indicating the error condition. > > Would this help? > That's an interesting idea. Let me give it a try. Will provide feedback when I have done this. In any case, if it turns out to be a problem with one library, we may be better of mandating that all verification is done during the handshake... By the way, I've read in your implementation report that it is not possible to terminate the handshake with OpenSSL either. This is not the case, you can do that. -- Bazsi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 29 03:44:45 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 4468A3A6B5F; Thu, 29 May 2008 03:44:45 -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 BF5903A6B47 for ; Thu, 29 May 2008 03:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 n6QwL+RjTR0u for ; Thu, 29 May 2008 03:44:43 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id BFFCF28C249 for ; Thu, 29 May 2008 03:44:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id D64F07AD8BB; Thu, 29 May 2008 12:41:43 +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 0HG2xxOZXg6R; Thu, 29 May 2008 12:41:43 +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 978587AD809; Thu, 29 May 2008 12:41:43 +0200 (CEST) Received: from [172.19.2.1] ([172.19.2.1]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 May 2008 12:44:07 +0200 From: Rainer Gerhards To: Balazs Scheidler In-Reply-To: <1212048724.28540.29.camel@bzorp.balabit> References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA3090E1@grfint2.intern.adiscon.com> <1212048724.28540.29.camel@bzorp.balabit> Date: Thu, 29 May 2008 12:44:07 +0200 Message-Id: <1212057848.16825.16.camel@rgf9dev.intern.adiscon.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 (2.22.1-2.fc9) X-OriginalArrivalTime: 29 May 2008 10:44:07.0599 (UTC) FILETIME=[EBC71BF0:01C8C178] Cc: syslog@ietf.org Subject: Re: [Syslog] Fingerprint/handshake 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 On Thu, 2008-05-29 at 10:12 +0200, Balazs Scheidler wrote: > On Thu, 2008-05-29 at 09:45 +0200, Rainer Gerhards wrote: > > Inline... > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Thursday, May 29, 2008 2:32 AM > > > To: Rainer Gerhards; syslog@ietf.org > > > Subject: RE: [Syslog] Fingerprint/handshake > > > > > > Hi Rainer, > > > > > > A TLS alert could be sent by the server indicating the error condition. > > > Would this help? > > > That's an interesting idea. Let me give it a try. Will provide feedback when I have done this. In any case, if it turns out to be a problem with one library, we may be better of mandating that all verification is done during the handshake... > > By the way, I've read in your implementation report that it is not > possible to terminate the handshake with OpenSSL either. This is not the > case, you can do that. Ah, good to know. So it looks like this is a single-library problem, about which the standard should obviously not care. Bazsi, could you do me a favor and let me know which callback you use, so that I can get to the specifics (also for the GnuTLS folks). I'd really appreciate that. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 29 05:18:10 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 AD9BE28C274; Thu, 29 May 2008 05:18:10 -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 0427D28C275 for ; Thu, 29 May 2008 05:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044] 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 akj3HcYciFZy for ; Thu, 29 May 2008 05:18:08 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 0263F28C190 for ; Thu, 29 May 2008 05:18:07 -0700 (PDT) X-Trace: 122181302/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.122.241 X-SBRS: None X-RemoteIP: 62.188.122.241 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIM1Pkg+vHrx/2dsb2JhbABBiyyjZAM X-IronPort-AV: E=Sophos;i="4.27,561,1204502400"; d="scan'208";a="122181302" X-IP-Direction: IN Received: from 1cust241.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.241]) by smtp.pipex.tiscali.co.uk with SMTP; 29 May 2008 12:53:29 +0100 Message-ID: <000d01c8c179$92441c80$0601a8c0@allison> From: "tom.petch" To: "Moehrke, John \(GE Healthcare\)" , "Rainer Gerhards" , "Joseph Salowey \(jsalowey\)" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <124CF5A7D55D6F43A4FD9437F28254D8EED6CB@ALPMLVEM05.e2k.ad.ge.com> Date: Thu, 29 May 2008 09:54:07 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] Some revised text for syslog TLS 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org ----- Original Message ----- From: "Moehrke, John (GE Healthcare)" To: "Rainer Gerhards" ; "Joseph Salowey (jsalowey)" ; Sent: Tuesday, May 27, 2008 12:15 AM Subject: Re: [Syslog] Some revised text for syslog TLS > I have said this before, but people continue to go down this path... > > The TLS authentication has already proven that the 'other' side holds > the private key... this is cryptographically secure authentication... > True, but authentication of what? This logic says you might as well use naked public/private keys, as SSH does. For me, the point of all the extra hassle of certificates is that the keys are bound to an identity/identifier so you can tell, to some degree (depending on what checks the CA has performed) to whom you are talking. Then it becomes a question of what identifier to use, CN, MAC, etc. At something of a tangent, I see work in RIPE (and the IETF) to use (R)PKI to secure the routing system so it will become possible to authenticate the assignee of an IP address. Not directly applicable, but encouraging both for the use of PKI and for the acceptability of IP addresses therein. Tom Petch > Adding a check of the IP address or DNS address adds very very little > value, and is not cryptographically secure (unless using Secure DNS). > > Therefore there is little value to adding IP or hostname checking, and > lots of ways it will break (NAT, DHCP, etc). > > John > > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf > > Of Rainer Gerhards > > Sent: Monday, May 26, 2008 2:19 AM > > To: Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: Re: [Syslog] Some revised text for syslog TLS > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 29 05:18: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 D9A9E28C27A; Thu, 29 May 2008 05:18: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 CC5BC28C190 for ; Thu, 29 May 2008 05:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=1.322, 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 iaE16t-Yf1-S for ; Thu, 29 May 2008 05:18:08 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 9956B28C274 for ; Thu, 29 May 2008 05:18:08 -0700 (PDT) X-Trace: 122181314/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.122.241 X-SBRS: None X-RemoteIP: 62.188.122.241 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAIM1Pkg+vHrx/2dsb2JhbACLbaNkAw X-IronPort-AV: E=Sophos;i="4.27,561,1204502400"; d="scan'208";a="122181314" X-IP-Direction: IN Received: from 1cust241.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.241]) by smtp.pipex.tiscali.co.uk with SMTP; 29 May 2008 12:53:31 +0100 Message-ID: <000e01c8c179$9325f100$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , "Joseph Salowey \(jsalowey\)" , References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA3090E1@grfint2.intern.adiscon.com> Date: Thu, 29 May 2008 11:14:27 +0200 MIME-Version: 1.0 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 Subject: Re: [Syslog] Fingerprint/handshake 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Rainer I wonder how a similar problem is handled. Every so often, I see the performance of https: access go to pot, and when I look, yes there is a multi-megabyte CRL being downloaded before the authentication can complete. I assume that you cannot know what certs you will get, so cannot preload the CRLs so this is an inevitable part of PKI (and one I suspect will become a significant problem). Any idea what happens? Does the TLS exchange get hel= d up? Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" ; Sent: Thursday, May 29, 2008 9:45 AM Subject: Re: [Syslog] Fingerprint/handshake Inline... > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Thursday, May 29, 2008 2:32 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Fingerprint/handshake > > Hi Rainer, > > A TLS alert could be sent by the server indicating the error condition. > Would this help? That's an interesting idea. Let me give it a try. Will provide feedback whe= n I have done this. In any case, if it turns out to be a problem with one libra= ry, we may be better of mandating that all verification is done during the handshake... > > Joe > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Sunday, May 25, 2008 11:46 PM > > To: Joseph Salowey (jsalowey); syslog@ietf.org > > Subject: RE: [Syslog] Fingerprint/handshake > > > > Hi Joe, > > > > inline > > > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Friday, May 23, 2008 8:21 PM > > > To: Rainer Gerhards; syslog@ietf.org > > > Subject: RE: [Syslog] Fingerprint/handshake > > > > > > The fingerprint check should be done where certificate validation > > would > > > be done. This is typically done within the handshake itself, > > > > I agree to this, but have found this to be problematic with > > some TLS libraries. Of course, that doesn't mean the standard > > needs to change, but I would still like to provide some > > implementation feedback. > > > > With GnuTLS, for example, you can do the final authentication > > only after the handshake [1]. With NSS, it can be done during > > the handshake. As of my understanding, OpenSSL does support > > it after the handshake only (but I have not actually used > > OpenSSL, this is based on my understanding after reading > > doc). This brings me to the conclusion that, at least in some > > environments I may be forced to delay the authentication > > check to after the handshake. > > > [Joe] Its been a while since I used OpenSSL, but if I remember > correctly > they do have hooks in the certificate validation code. [Rainer] From what I have seen in the doc, this does not permit to do all checks. Mo= st importantly, it looked like I am not able to check the fingerprint and subj= ect name. But fortunately Martin Sch=FCtte is using openSSL for his implementat= ion and I hope he can provide feedback on this in the not so distant future. Rainer _______________________________________________ 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 May 29 06:42: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 CFADE3A6880; Thu, 29 May 2008 06:42: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 C0F843A6914; Thu, 29 May 2008 06:42:03 -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 gAmsMlXDcfh0; Thu, 29 May 2008 06:41:58 -0700 (PDT) Received: from mornm02-out.agfa.com (mornm02-out.agfa.com [134.54.1.77]) by core3.amsl.com (Postfix) with ESMTP id D3DC83A6919; Thu, 29 May 2008 06:41:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,561,1204498800"; d="scan'208";a="41188490" Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm02-out.agfa.com with ESMTP; 29 May 2008 15:41:47 +0200 In-Reply-To: <000d01c8c179$92441c80$0601a8c0@allison> To: "tom.petch" MIME-Version: 1.0 Message-ID: From: robert.horn@agfa.com Date: Thu, 29 May 2008 09:41:43 -0400 Cc: syslog , syslog-bounces@ietf.org Subject: Re: [Syslog] Some revised text for syslog TLS 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 [tom-petch]> > True, but authentication of what? This logic says you might as well use naked > public/private keys, as SSH does. For me, the point of all the > extra hassle of > certificates is that the keys are bound to an identity/identifier so you can > tell, to some degree (depending on what checks the CA has performed) > to whom you > are talking. Then it becomes a question of what identifier to use, CN, MAC, > etc. You live in a radically different threat-asset environment than healthcare I can tell. In our environment the SSH process would do fine for about half the users, and the official root CA approach is appropriate to about 0% of the users. The value of using the certificates for all of them is software development. Certificates are a widely supported mechanism in most security libraries. There is no comparable alternative for a standard format. The half of our world that deals with authentication out of band can use certificates and ignore all the extraneous infrastructure. Out of band mechanisms are very significant in healthcare. We have all sorts of patient safety issues that must be managed. For example, any hardware change (even just a board swap) can require safety retesting for patient contact devices. Adding machine identification and authentication to that process is a low cost addition. It's much cheaper than building up a suitable PKI infrastructure for the smaller sites. The official root CA approach is a non-starter because in the other half of our world where chain of trust does make sense, the usual root CAs haven't a clue. Do you really think that Verisign knows whether that PC in my local hospital has been configured for the admitting clerk's desk or for the surgical suite? They do not and they do not want to keep track of that information. There is a completely different chain of trust used in hospitals and clinics. The trusted anchor is part of the hospital and clinic organization. It coordinates with the Bio-med department regarding device allocation. It does know what machines are assigned where and for what purposes. In healthcare you pick a trusted anchor that knows these things. It will not chain outside the healthcare organization. This organization might be rather large when you get into various national health systems, but the anchor is within the healthcare system. R Horn _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 29 08:22:56 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 AE03C3A6AB0; Thu, 29 May 2008 08:22:56 -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 A275A3A6BB2 for ; Thu, 29 May 2008 08:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=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 AhHguz5H6VA3 for ; Thu, 29 May 2008 08:22:42 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBA528C0E8 for ; Thu, 29 May 2008 08:21:48 -0700 (PDT) X-Trace: 35693215/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.113 X-SBRS: None X-RemoteIP: 213.116.60.113 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAH9mPkjVdDxx/2dsb2JhbACLbaQPAw X-IronPort-AV: E=Sophos;i="4.27,562,1204502400"; d="scan'208";a="35693215" X-IP-Direction: IN Received: from 1cust113.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.113]) by smtp.pipex.tiscali.co.uk with SMTP; 29 May 2008 16:21:43 +0100 Message-ID: <009f01c8c196$a8d14000$0601a8c0@allison> From: "tom.petch" To: "Rainer Gerhards" , "Joseph Salowey \(jsalowey\)" References: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA3090E0@grfint2.intern.adiscon.com> Date: Thu, 29 May 2008 16:15:20 +0200 MIME-Version: 1.0 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@ietf.org Subject: Re: [Syslog] -transport-tls references to "matching rules" 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I think that the I-D has got a bit mangled. I liked, and may have been responsible for, the reference to RFC2818 as being an example of the checks to perform on a certificate, written about a well-known application by someone familiar with TLS:-) This was the basis for our validation rules, CN deprecated, subjectAltName must be used as an identity etc and it helped (me) to know where they came from. The mention of certificates warranted a reference and that was provided by RFC3280. This reference was never about validation rules. We did not used to have certificate path validation. We do now and I do not know a good reference for it; I agree that RFC3280 et seq is not it. This lack I see as a(nother?) deficiency on the part of the security engineers:-( Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" Cc: Sent: Thursday, May 29, 2008 8:21 AM Subject: Re: [Syslog] -transport-tls references to "matching rules" > Mhhh... Wouldn't it then be appropriate to drop these sentences from > transport-tls: > > ### > Matching for certificate credentials is performed using the > matching rules specified by [3]. > ### > > They created the impression (at least for me), I need to look up the > rule in 5280 in order to implement -tls correctly. As you now say, this > is not the case (it may be with internationalized names on subject name > matching, but it seems not to be in other cases, namely for ipAddress, > where it is specified, too). > > Rainer > > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Thursday, May 29, 2008 3:01 AM > > To: Rainer Gerhards; syslog@ietf.org > > Subject: RE: [Syslog] -transport-tls references to "matching rules" > > > > The only place 5280 goes into great detail about matching is with > > internationalized names. I don't think it specifies any specific > rules > > for matching the iPaddress within a subjectAltName. This is left up > > to > > the definition by the application making use of the certificates. > I'm > > not sure we need to standardize matching behavior unless it affects > the > > representation within the certificates (for example including > wildcards > > in the identities). > > > > Joe > > > > > > > > > -----Original Message----- > > > From: syslog-bounces@ietf.org > > > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > > > Sent: Wednesday, May 28, 2008 8:41 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] -transport-tls references to "matching rules" > > > > > > Hi, > > > > > > -transport-tls refers (as [3] to RFC 5280), e.g. "Matching > > > for certificate credentials is performed using the matching > > > rules specified by [3]." I am revisiting 5280 to find the > > > matching rules for ipAddress. However, this is a nearly 150 > > > page document and I admit I do not know its ins and outs. It > > > would be really helpful if a section is mentioned inside the > > > reference so that one can quickly look up the rules. > > > > > > And, a hopefully quick question, where do I find the rules > > > for ipAddress? I was unable to bring it up on a quick look. > > > > > > Thanks, > > > Rainer > > > _______________________________________________ > > > 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 Thu May 29 14:34:07 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 D7C413A69B8; Thu, 29 May 2008 14:34:07 -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 73A443A69B8 for ; Thu, 29 May 2008 14:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 VppXnMHWdIrL for ; Thu, 29 May 2008 14:34:05 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id E8DEB3A6BCA for ; Thu, 29 May 2008 14:34:03 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id EB7B51E6A78 for ; Thu, 29 May 2008 23:34:01 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id BrFi5e1DKbFk for ; Thu, 29 May 2008 23:33:50 +0200 (CEST) Received: from [192.168.178.21] (BAA0909.baa.pppool.de [77.128.9.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 67CDC1E6A74 for ; Thu, 29 May 2008 23:33:48 +0200 (CEST) Message-ID: <483F213E.8060101@mschuette.name> Date: Thu, 29 May 2008 23:33:50 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <577465F99B41C842AAFBE9ED71E70ABA309093@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72B36A0B@vaebe104.NOE.Nokia.com> Subject: Re: [Syslog] Some revised text for syslog TLS 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 Pasi.Eronen@nokia.com schrieb: > AFAIK certificates containing IP addresses are quite rare; host names > are much common. To support such situation -- while still avoiding > dependency on DNS -- it would be useful if you could configure the IP > address (used for opening the connection) and server name (compared > against the certificate, but not looked up from DNS) separately. Having the iPAddress inside the certificate solves this nicely, without additional configuration. > I don't know what that would look like in your configuration file > syntax, but maybe something like > *.* @@192.0.2.1[syslogsrv2.example.com] One question here: Why is it required to use hostnames only insted of the Distinguished Name of the certificate? -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu May 29 22:17:31 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 588B83A6B08; Thu, 29 May 2008 22:17:31 -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 9436C28C158 for ; Thu, 29 May 2008 22:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.296 X-Spam-Level: * X-Spam-Status: No, score=1.296 tagged_above=-999 required=5 tests=[AWL=1.300, 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 tjZbbKH5xUEu for ; Thu, 29 May 2008 22:17:29 -0700 (PDT) Received: from lists.balabit.hu (support.balabit.hu [195.70.41.86]) by core3.amsl.com (Postfix) with ESMTP id 86CE73A685C for ; Thu, 29 May 2008 22:17:28 -0700 (PDT) Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 4602C2760CA for ; Fri, 30 May 2008 07:17:26 +0200 (CEST) From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <1212057848.16825.16.camel@rgf9dev.intern.adiscon.com> References: <003901c8b9f7$b671959d$060013ac@intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA309090@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA3090E1@grfint2.intern.adiscon.com> <1212048724.28540.29.camel@bzorp.balabit> <1212057848.16825.16.camel@rgf9dev.intern.adiscon.com> Date: Fri, 30 May 2008 07:17:22 +0200 Message-Id: <1212124642.7808.5.camel@bzorp.balabit> Mime-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] Fingerprint/handshake 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 On Thu, 2008-05-29 at 12:44 +0200, Rainer Gerhards wrote: > On Thu, 2008-05-29 at 10:12 +0200, Balazs Scheidler wrote: > > On Thu, 2008-05-29 at 09:45 +0200, Rainer Gerhards wrote: > > > Inline... > > > > -----Original Message----- > > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > > Sent: Thursday, May 29, 2008 2:32 AM > > > > To: Rainer Gerhards; syslog@ietf.org > > > > Subject: RE: [Syslog] Fingerprint/handshake > > > > > > > > Hi Rainer, > > > > > > > > A TLS alert could be sent by the server indicating the error condition. > > > > Would this help? > > > > > That's an interesting idea. Let me give it a try. Will provide feedback when I have done this. In any case, if it turns out to be a problem with one library, we may be better of mandating that all verification is done during the handshake... > > > > By the way, I've read in your implementation report that it is not > > possible to terminate the handshake with OpenSSL either. This is not the > > case, you can do that. > > Ah, good to know. So it looks like this is a single-library problem, > about which the standard should obviously not care. > > Bazsi, could you do me a favor and let me know which callback you use, > so that I can get to the specifics (also for the GnuTLS folks). I'd > really appreciate that. > In OpenSSL the complete peer validation process can be changed by using SSL_CTX_set_cert_verify_callback(), it gets X509_STORE populated with the peer supplied key chain and returns whether the validation failed. If the callback returns failure, an alarm is sent back to the peer depending on the error code that is returned by this callback. -- Bazsi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri May 30 02:19: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 AE3433A685D; Fri, 30 May 2008 02:19: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 73D923A685D for ; Fri, 30 May 2008 02:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Bo+rOsszs1Zi for ; Fri, 30 May 2008 02:19:31 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 288303A683B for ; Fri, 30 May 2008 02:19:31 -0700 (PDT) X-Trace: 122682215/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.54 X-SBRS: None X-RemoteIP: 213.116.60.54 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAJ5jP0jVdDw2/2dsb2JhbACLb6M1Aw X-IronPort-AV: E=Sophos;i="4.27,565,1204502400"; d="scan'208";a="122682215" X-IP-Direction: IN Received: from 1cust54.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.54]) by smtp.pipex.tiscali.co.uk with SMTP; 30 May 2008 10:19:23 +0100 Message-ID: <018501c8c22d$35038880$0601a8c0@allison> From: "tom.petch" To: References: Date: Fri, 30 May 2008 10:11:01 +0200 MIME-Version: 1.0 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] Some revised text for syslog TLS 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Understand. I too do not see root CAs like Verisign being much involved; rather, a large enterprise will have its own CA, which makes it easier to use things other than names. But I still see them checking that the identity in the certificate is as expected, rather than just checking that certificate is technically valid. I recall the issue of 'private' PKI(!) coming up before on this list, and I recall one use case, raised by Anton, where the box serial number as inserted by the manufacturer was also inserted into the certificate installed on the box. (Anton was also a driver for generic certificates). So I see a use case for checking the identity, as well as circumstances, such as yours, where it will not be performed. Tom Petch ----- Original Message ----- From: To: "tom.petch" Cc: "Moehrke, John (GE Healthcare)" ; "Joseph Salowey (jsalowey)" ; "Rainer Gerhards" ; "syslog" ; Sent: Thursday, May 29, 2008 3:41 PM Subject: Re: [Syslog] Some revised text for syslog TLS > [tom-petch]> > > True, but authentication of what? This logic says you might as well use > naked > > public/private keys, as SSH does. For me, the point of all the > > extra hassle of > > certificates is that the keys are bound to an identity/identifier so you > can > > tell, to some degree (depending on what checks the CA has performed) > > to whom you > > are talking. Then it becomes a question of what identifier to use, CN, > MAC, > > etc. > > You live in a radically different threat-asset environment than healthcare > I can tell. In our environment the SSH process would do fine for about > half the users, and the official root CA approach is appropriate to about > 0% of the users. The value of using the certificates for all of them is > software development. Certificates are a widely supported mechanism in > most security libraries. There is no comparable alternative for a > standard format. The half of our world that deals with authentication out > of band can use certificates and ignore all the extraneous infrastructure. > Out of band mechanisms are very significant in healthcare. We have all > sorts of patient safety issues that must be managed. For example, any > hardware change (even just a board swap) can require safety retesting for > patient contact devices. Adding machine identification and authentication > to that process is a low cost addition. It's much cheaper than building > up a suitable PKI infrastructure for the smaller sites. > > The official root CA approach is a non-starter because in the other half > of our world where chain of trust does make sense, the usual root CAs > haven't a clue. Do you really think that Verisign knows whether that PC > in my local hospital has been configured for the admitting clerk's desk or > for the surgical suite? They do not and they do not want to keep track of > that information. There is a completely different chain of trust used in > hospitals and clinics. The trusted anchor is part of the hospital and > clinic organization. It coordinates with the Bio-med department regarding > device allocation. It does know what machines are assigned where and for > what purposes. > > In healthcare you pick a trusted anchor that knows these things. It will > not chain outside the healthcare organization. This organization might be > rather large when you get into various national health systems, but the > anchor is within the healthcare system. > > R Horn > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog