From syslog-bounces@lists.ietf.org Mon Jan 02 05:42:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtN97-0007ZR-GN; Mon, 02 Jan 2006 05:42:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtN96-0007YC-I3 for syslog@megatron.ietf.org; Mon, 02 Jan 2006 05:42:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12928 for ; Mon, 2 Jan 2006 05:41:18 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtNDd-0003Sb-3S for syslog@ietf.org; Mon, 02 Jan 2006 05:47:46 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id CB34E27C02C for ; Mon, 2 Jan 2006 11:36:12 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24073-02 for ; Mon, 2 Jan 2006 11:36:12 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9191E27C02B for ; Mon, 2 Jan 2006 11:36:12 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jan 2006 11:41:36 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jan 2006 11:41:31 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: TIMESTAMP and leap seconds Thread-Index: AcYPiRf7ApYn2aaJTU2lmv3YiiNzhQ== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 02 Jan 2006 10:41:36.0924 (UTC) FILETIME=[1B476DC0:01C60F89] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] TIMESTAMP and leap seconds X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi all, first of all, I would like to whish a happy new year to each of you! I am now back in the office and at final edits to syslog-protocol. I discovered one more thing: The current draft supports leap seconds. There already is a lot of discussion whether or not leap seconds should be introduced in the future. However, the way leap seconds are handled will be largely invisible to a syslog sender (except where it is sitting on a time-tracking device, which is highly unlikely). On the other hand, leap second processing can be pretty complicated at the receiver side. I expect that most implementations will not abide strict handling in any case. As such, I suggest that leap second support be removed from the TIMESTAMP. Similarily, a sender with unknown time should then not use the special TIMESTAMP but "-", which also keeps it consistent with the rest of the header NIL values. If nobody objects, I'll change this during the edit. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 03 04:32:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtiWh-0001gz-JO; Tue, 03 Jan 2006 04:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtiWe-0001fQ-W3 for syslog@megatron.ietf.org; Tue, 03 Jan 2006 04:32:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26791 for ; Tue, 3 Jan 2006 04:31:03 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Etibt-0003bS-89 for syslog@ietf.org; Tue, 03 Jan 2006 04:37:42 -0500 Received: (qmail 34370 invoked from network); 3 Jan 2006 09:32:06 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 3 Jan 2006 09:32:06 -0000 X-pair-Authenticated: 222.152.148.36 From: "Andrew Ross" To: "'Rainer Gerhards'" Subject: RE: [Syslog] TIMESTAMP and leap seconds Date: Tue, 3 Jan 2006 22:32:02 +1300 Organization: Kiwi Enterprises Message-ID: <000501c61048$8eb2cc90$d9a8a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, Happy new year! Your idea of ignoring the leap seconds sounds very sensible to me. Cheers Andrew -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards Sent: Monday, 2 January 2006 11:42 p.m. To: syslog@ietf.org Subject: [Syslog] TIMESTAMP and leap seconds Hi all, first of all, I would like to whish a happy new year to each of you! I am now back in the office and at final edits to syslog-protocol. I discovered one more thing: The current draft supports leap seconds. There already is a lot of discussion whether or not leap seconds should be introduced in the future. However, the way leap seconds are handled will be largely invisible to a syslog sender (except where it is sitting on a time-tracking device, which is highly unlikely). On the other hand, leap second processing can be pretty complicated at the receiver side. I expect that most implementations will not abide strict handling in any case. As such, I suggest that leap second support be removed from the TIMESTAMP. Similarily, a sender with unknown time should then not use the special TIMESTAMP but "-", which also keeps it consistent with the rest of the header NIL values. If nobody objects, I'll change this during the edit. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 03 15:50:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ett7S-0003l0-8m; Tue, 03 Jan 2006 15:50:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ett6e-0003Yg-00; Tue, 03 Jan 2006 15:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28607; Tue, 3 Jan 2006 15:48:54 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EttBu-0003BM-Op; Tue, 03 Jan 2006 15:55:36 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ett6Y-00006S-1W; Tue, 03 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jan 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-16.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.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 : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-16.txt Pages : 45 Date : 2006-1-3 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. The layered architecture also provides a solid basis that allows code to be written once instead of multiple times, once for each syslog feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-3114546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-3114546.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Thu Jan 05 16:20:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EucWp-0003JE-0i; Thu, 05 Jan 2006 16:20:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EucWl-0003HU-0y for syslog@megatron.ietf.org; Thu, 05 Jan 2006 16:20:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20651 for ; Thu, 5 Jan 2006 16:18:49 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuccP-0005jf-GB for syslog@ietf.org; Thu, 05 Jan 2006 16:26:00 -0500 Received: from pc6 (1Cust165.tnt9.lnd4.gbr.da.uu.net [62.188.138.165]) by galaxy.systems.pipex.net (Postfix) with SMTP id 30653E0006E0 for ; Thu, 5 Jan 2006 21:19:41 +0000 (GMT) Message-ID: <001601c61234$f7e335e0$0601a8c0@pc6> From: "Tom Petch" To: References: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> Date: Thu, 5 Jan 2006 21:16:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] draft-ietf-syslog-device-mib-07.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I have had a look at the syslog MIB, and am confused, at a fairly fundamental level, about the relationship of the MIB to the other documents, RFC3164 and syslog-protocol. The last two have a common framework/architecture, spelt out at the beginning of each, with a common terminology of device, relay, collector, server. The MIB is different. Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group of syslog devices' and 'One or more syslog devices which may be on the same host'. '"facilities" generate messages indicating their own status or the occurance of events. These messages are handled by what has come to be known as the syslog process or device' Which leaves me with the impression of a loosely-coupled system of hosts communicating via proprietary protocols with multiple instances of a syslog daemon per host forwarding messages onward. Really? could be but I think I am lost here and that the introduction should be recast in the language of RFC3164/syslog-protocol (even if it is intending to convey the above). Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 05 17:12:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EudLJ-0007Sm-Ld; Thu, 05 Jan 2006 17:12:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EudLH-0007OX-KG for syslog@megatron.ietf.org; Thu, 05 Jan 2006 17:12:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00297 for ; Thu, 5 Jan 2006 17:11:04 -0500 (EST) Received: from stratton-three-twelve.mit.edu ([18.187.6.57] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EudR2-0000as-Ea for syslog@ietf.org; Thu, 05 Jan 2006 17:18:17 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AC2FCE0053; Thu, 5 Jan 2006 17:12:15 -0500 (EST) To: syslog@ietf.org From: Sam Hartman Date: Thu, 05 Jan 2006 17:12:15 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Syslog] Charter comments from IESG Review X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi. The IESg reviewed the proposed syslog charter at today's telechat and decided that it requires revision. The main concern seems to be the lack of a mandatory to implement security mechanism. I indicated this might be the case in the Vancouver meeting. so, you definitely need to have some sort of mandatory to implement security mechanism. I'm not quite sure what needs to be said about this in the charter. But the working group will need to: 1) Identify a threat model for syslog 2) Define mechanisms to address these threats. So, questions for the threat model include things like whether confidentiality is important or whether integrity of mesages is sufficient. Depending on the threat model here are some possible solutions: 1) Require some transport like syslog over TLS|DTLS be implemented. 2) Require that all senders implement signatures stored in structured data as an option. I don't think you need to commit to one of these options now. However, you do need to reflect the security issues in the charter. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 06 13:17:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euw9l-0006te-JX; Fri, 06 Jan 2006 13:17:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euw9i-0006sy-1F for syslog@megatron.ietf.org; Fri, 06 Jan 2006 13:17:39 -0500 Received: from usscmail7.hds.com (usscmail7.hds.com [63.74.235.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19736 for ; Fri, 6 Jan 2006 13:16:21 -0500 (EST) Received: from mail.hds.com (usscmail9 [10.1.6.230]) by usscmail7.hds.com (8.11.7p1+Sun/8.11.5) with ESMTP id k06IH5G01546 for ; Fri, 6 Jan 2006 10:17:05 -0800 (PST) Received: from usscceb101.corp.hds.com (USSCCNETSLB08-VLAN4.hds.com [10.1.6.68]) by mail.hds.com (8.11.5-p0-rfc19719/8.11.5) with ESMTP id k06IHXb03629 for ; Fri, 6 Jan 2006 10:17:33 -0800 (PST) Received: from USSCCEVS102.corp.hds.com ([10.1.52.225]) by usscceb101.corp.hds.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jan 2006 10:17:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jan 2006 10:17:04 -0800 Message-ID: <45D4D9EBC6EF8D418F584D3D3F6AFC1C9291FD@USSCCEVS102.corp.hds.com> Thread-Topic: Syslog Threat Modeling Thread-Index: AcYS7WV0YINO6zHnR8yMr4WQna+fog== From: "Eric Hibbard" To: X-OriginalArrivalTime: 06 Jan 2006 18:17:04.0584 (UTC) FILETIME=[657C6C80:01C612ED] Cc: Subject: [Syslog] Syslog Threat Modeling X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1107173136==" Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1107173136== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C612ED.658D1C61" This is a multi-part message in MIME format. ------_=_NextPart_001_01C612ED.658D1C61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If a threat model for Syslog is required, I would be very interested in helping out. Let me know. =20 -Eric =20 Eric A. Hibbard, CISSP, ISSAP, ISSMP, ISSEP Senior Director, Data Networking Technology Chair, SNIA Security Technical Work Group =20 Office of the CTO HITACHI DATA SYSTEMS 750 Central Expressway, MS 3407 Santa Clara, CA 95050-2627 P 408.970.7979/ F 408.562.5477 eric.hibbard@hds.com =20 =20 ------_=_NextPart_001_01C612ED.658D1C61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If a = threat model=20 for Syslog is required, I would be very interested in helping out. Let = me=20 know.
 
-Eric
 
Eric A. Hibbard, CISSP, ISSAP, ISSMP,=20 ISSEP
Senior = Director,=20 Data Networking Technology
Chair, SNIA Security Technical = Work=20 Group
 
Office of the = CTO
HITACHI DATA=20 SYSTEMS
750 Central = Expressway, MS=20 3407
Santa=20 Clara, CA 95050-2627
P 408.970.7979/ F = 408.562.5477
eric.hibbard@hds.com
 
------_=_NextPart_001_01C612ED.658D1C61-- --===============1107173136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --===============1107173136==-- From syslog-bounces@lists.ietf.org Fri Jan 06 13:25:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwH2-0000x2-S8; Fri, 06 Jan 2006 13:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwH1-0000ww-21 for syslog@megatron.ietf.org; Fri, 06 Jan 2006 13:25:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20370 for ; Fri, 6 Jan 2006 13:23:55 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwMw-00026f-Dg for syslog@ietf.org; Fri, 06 Jan 2006 13:31:19 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 06 Jan 2006 10:25:01 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k06IP0WG005374; Fri, 6 Jan 2006 10:25:00 -0800 (PST) Date: Fri, 6 Jan 2006 10:25:00 -0800 (PST) From: Chris Lonvick To: Sam Hartman Subject: Re: [Syslog] Charter comments from IESG Review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Sam, On Thu, 5 Jan 2006, Sam Hartman wrote: > > > Hi. The IESg reviewed the proposed syslog charter at today's telechat > and decided that it requires revision. The main concern seems to be > the lack of a mandatory to implement security mechanism. I indicated > this might be the case in the Vancouver meeting. > > so, you definitely need to have some sort of mandatory to implement > security mechanism. I'm not quite sure what needs to be said about > this in the charter. > But the working group will need to: > > 1) Identify a threat model for syslog Is Section 8 in draft-ietf-syslog-protocol-16.txt sufficient? Alternatively, Section 6 in RFC 3164 is fairly comprehensive. > > > 2) Define mechanisms to address these threats. > > So, questions for the threat model include things like whether > confidentiality is important or whether integrity of mesages is > sufficient. > > Depending on the threat model here are some possible solutions: > > 1) Require some transport like syslog over TLS|DTLS be implemented. RFC 3195 requires the use of RFC 3080 which requires TLS. > > 2) Require that all senders implement signatures stored in structured > data as an option. That's likely addressed through syslog-sign. > > I don't think you need to commit to one of these options now. > However, you do need to reflect the security issues in the charter. The questions for you: - Do we need to produce a threat model in a new document? - Can we state that the threats will be addresses in syslog-sign and 3195bis? I will also note that there is a group of implementors who have already done syslog/tls. I suspect they would like to codify this in a standard and that may also address the threats. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 06 13:48:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwdK-0004Rh-Ml; Fri, 06 Jan 2006 13:48:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwdI-0004RY-7g for syslog@megatron.ietf.org; Fri, 06 Jan 2006 13:48:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22018 for ; Fri, 6 Jan 2006 13:46:55 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwjB-0002oE-Em for syslog@ietf.org; Fri, 06 Jan 2006 13:54:20 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2006 10:47:59 -0800 X-IronPort-AV: i="3.99,339,1131350400"; d="scan'208"; a="388310737:sNHT43856700" Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k06IlxWG018487 for ; Fri, 6 Jan 2006 10:47:59 -0800 (PST) Date: Fri, 6 Jan 2006 10:47:59 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-16.txt (fwd) X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Folks, This is it. We need people to review this and get back to the WG. When you reivew it, either send in notes about issues, or respond by saying that you have reviewed it. (We DO need "me too's".) Thanks, Chris ---------- Forwarded message ---------- Date: Tue, 03 Jan 2006 15:50:02 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: syslog@ietf.org Subject: I-D ACTION:draft-ietf-syslog-protocol-16.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 : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-16.txt Pages : 45 Date : 2006-1-3 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. The layered architecture also provides a solid basis that allows code to be written once instead of multiple times, once for each syslog feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 06 14:36:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxNd-00078y-Tp; Fri, 06 Jan 2006 14:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxNb-00077s-CG for syslog@megatron.ietf.org; Fri, 06 Jan 2006 14:36:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28443 for ; Fri, 6 Jan 2006 14:34:46 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuxTW-0005E7-8F for syslog@ietf.org; Fri, 06 Jan 2006 14:42:11 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D0F46E0075; Fri, 6 Jan 2006 14:36:03 -0500 (EST) To: Chris Lonvick Subject: Re: [Syslog] Charter comments from IESG Review References: From: Sam Hartman Date: Fri, 06 Jan 2006 14:36:03 -0500 In-Reply-To: (Chris Lonvick's message of "Fri, 6 Jan 2006 10:25:00 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Chris" == Chris Lonvick writes: Chris> Is Section 8 in draft-ietf-syslog-protocol-16.txt Chris> sufficient? Alternatively, Section 6 in RFC 3164 is fairly Chris> comprehensive. Both of these look good. My main question with them is whether you believe it is a requirement to address all these threats or whether addressing a subset is sufficient. >> >> >> 2) Define mechanisms to address these threats. >> >> So, questions for the threat model include things like whether >> confidentiality is important or whether integrity of mesages is >> sufficient. >> >> Depending on the threat model here are some possible solutions: >> >> 1) Require some transport like syslog over TLS|DTLS be >> implemented. Chris> RFC 3195 requires the use of RFC 3080 which requires TLS. Noted. >> 2) Require that all senders implement signatures stored in >> structured data as an option. Chris> That's likely addressed through syslog-sign. Agreed. >> I don't think you need to commit to one of these options now. >> However, you do need to reflect the security issues in the >> charter. Chris> The questions for you: Chris> - Do we need to produce a threat model in a new document? No, although you probably need to decide which threats you are addressing. Chris> - Can we state that the threats will be addresses in Chris> syslog-sign and 3195bis? I will also note that there is a Chris> group of implementors who have already done syslog/tls. I Chris> suspect they would like to codify this in a standard and Chris> that may also address the threats. You need to require everyone who implements syslog-protocol to implement your mandatory to implement security mechanism. That could be syslog-sign or 3195bis, but you'd have to actually make that normative requirement in protocol. I think the real question here is what mechanism can you choose that people will actually implement. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 06 15:49:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuyWS-0002WC-Pt; Fri, 06 Jan 2006 15:49:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuyWR-0002W1-Cz for syslog@megatron.ietf.org; Fri, 06 Jan 2006 15:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06799 for ; Fri, 6 Jan 2006 15:47:58 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuycN-0008JS-0P for syslog@ietf.org; Fri, 06 Jan 2006 15:55:25 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2006 15:48:04 -0500 X-IronPort-AV: i="3.99,339,1131339600"; d="scan'208"; a="79689560:sNHT31130328" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k06KltJl009272 for ; Fri, 6 Jan 2006 15:48:02 -0500 (EST) 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.211); Fri, 6 Jan 2006 15:47:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jan 2006 15:47:41 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122EA53DC@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Sec 6.1: Truncation Thread-Index: AcYS8k5MFvQCqVz3RJqX9nFzDRup+wACkoPg From: "Anton Okmianski \(aokmians\)" To: X-OriginalArrivalTime: 06 Jan 2006 20:47:46.0073 (UTC) FILETIME=[72A22890:01C61302] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] Sec 6.1: Truncation X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer and all: I started reading draft #16. Since we are revisiting everything... I am = not very comfortable with the current truncation rules.=20 "Receivers SHOULD follow this order of preference when it comes to = truncation: 1) No truncation 2) Truncation by dropping SD-ELEMENTs 3) If 2) not sufficient, truncate MSG" I don't think that this is a good recommendation. I would assume that = in many cases people would try to tokenize more important data into = structured data and use message text as a secondary user-friendly = description. For example, for LINK_DOWN message, I would probably encode = link ID in the structured elements as this is something that should be = readily available for receivers. The MSGID could be "LINK_DOWN" and the = MSG text may simply be "Link down". If you truncate the structured = data, it makes it harder.=20 I also think, in general it is useful to put more important data first, = which is another reason for putting more valuable data into structured = data in a more compact way. =20 Additionally, structured data can be used to provide message length or = digest, which can help receiver to determine if message was truncated.=20 Also, I think this statement is very convoluted: "Please note that it is possible that the MSG field is truncated without = dropping any SD-PARAMS. This is the case if a message with an empty = STRUCTURED-DATA field must be truncated." I think I understand what you are driving at, but I don't see it as = adding any requirements or clarification.=20 This sentence is not clear although I know what you are trying to say: "The limits below are minimum maximum lengths, not maximum length." I propose replacing the entire section 6.1 with this text: "Syslog message limits are dictated by the syslog transport mapping in = use. Each transport mapping MUST define the minimum required message = length support. Any syslog transport mapping MUST support messages of up = to and including 480 octets in length.=20 Any syslog receiver MUST be able to accept messages of up to and = including 480 octets in length. All receiver implementations SHOULD be = able to accept messages of up to and including 2048 octets in length. = Receivers MAY receive messages larger than 2048 octets in length. If a = receiver receives a message with a length larger than it supports, the = receiver MAY discard the message or truncate the payload. =20 If truncation is performed by the receiver, it MUST first truncate the = MSG field as necessary to meet the supported length limit. If truncation = of the entire MSG field is not sufficient, then additionally, the = STRUCTURED-DATA field MUST be truncated by removing one or more = SD-ELEMENT fields. A minimum number of SD-ELEMENT fields MUST be = truncated starting from the end as necessary to meet the supported = length limit. SD-ELEMENT field can't be truncated partially. If all = SD-ELEMENT fields are removed, NILVALUE MUST be specified for = STRUCTURED-DATA field. Truncation of HEADER field MUST NOT be = performed." =20 BTW, in your text or mine, what happens if message is malformed? A = proxy won't be able to truncate it properly then. We don't want to = prevent it from truncating it in some way and sending the message = further, I would think. At least you will see something at the final = destination, which maybe more useful than nothing. If we just made = truncation a simple take the first X octets out of Y octets, it would = not be an issue, but then proxy would be allowed to turn a well-formed = message into malformed message upon truncation. =20 What do you think? Thanks, Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 06 16:16:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euyww-0001pL-Ag; Fri, 06 Jan 2006 16:16:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euywu-0001pF-8h for syslog@megatron.ietf.org; Fri, 06 Jan 2006 16:16:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12221 for ; Fri, 6 Jan 2006 16:15:19 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euz2q-000248-4E for syslog@ietf.org; Fri, 06 Jan 2006 16:22:46 -0500 Received: from pc6 (1Cust94.tnt105.lnd4.gbr.da.uu.net [213.116.58.94]) by ranger.systems.pipex.net (Postfix) with SMTP id A01D9E0003F6; Fri, 6 Jan 2006 21:16:14 +0000 (GMT) Message-ID: <03e701c612fd$a71c1860$0601a8c0@pc6> From: "Tom Petch" To: , "Sam Hartman" References: Subject: Re: [Syslog] Charter comments from IESG Review Date: Fri, 6 Jan 2006 21:12:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam I struggle to think what a security system would look like when the protocol is purely simplex, apart from a MAC to give integrity with some shared secret transmitted totally out of band. Are there any examples of simplex security elsewhere in the IETF? Tom Petch ----- Original Message ----- From: "Sam Hartman" To: Sent: Thursday, January 05, 2006 11:12 PM Subject: [Syslog] Charter comments from IESG Review > > > Hi. The IESg reviewed the proposed syslog charter at today's telechat > and decided that it requires revision. The main concern seems to be > the lack of a mandatory to implement security mechanism. I indicated > this might be the case in the Vancouver meeting. > > so, you definitely need to have some sort of mandatory to implement > security mechanism. I'm not quite sure what needs to be said about > this in the charter. > But the working group will need to: > > 1) Identify a threat model for syslog > > > 2) Define mechanisms to address these threats. > > So, questions for the threat model include things like whether > confidentiality is important or whether integrity of mesages is > sufficient. > > Depending on the threat model here are some possible solutions: > > 1) Require some transport like syslog over TLS|DTLS be implemented. > > 2) Require that all senders implement signatures stored in structured > data as an option. > > I don't think you need to commit to one of these options now. > However, you do need to reflect the security issues in the charter. > > --Sam > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 06 16:27:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euz7g-0006zT-TN; Fri, 06 Jan 2006 16:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euz7f-0006wr-Kc for syslog@megatron.ietf.org; Fri, 06 Jan 2006 16:27:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13020 for ; Fri, 6 Jan 2006 16:26:26 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuzDd-0002QE-O7 for syslog@ietf.org; Fri, 06 Jan 2006 16:33:53 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7AA10E0053; Fri, 6 Jan 2006 16:27:41 -0500 (EST) To: "Tom Petch" Subject: Re: [Syslog] Charter comments from IESG Review References: <03e701c612fd$a71c1860$0601a8c0@pc6> From: Sam Hartman Date: Fri, 06 Jan 2006 16:27:41 -0500 In-Reply-To: <03e701c612fd$a71c1860$0601a8c0@pc6> (Tom Petch's message of "Fri, 6 Jan 2006 21:12:34 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Tom" == Tom Petch writes: Tom> Sam I struggle to think what a security system would look Tom> like when the protocol is purely simplex, apart from a MAC to Tom> give integrity with some shared secret transmitted totally Tom> out of band. By this do you mean without two-way communication? If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jan 07 06:00:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvBoe-0004tK-G4; Sat, 07 Jan 2006 06:00:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvBoc-0004oz-9x for syslog@megatron.ietf.org; Sat, 07 Jan 2006 06:00:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00887 for ; Sat, 7 Jan 2006 05:59:33 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvBuc-0007QG-9H for syslog@ietf.org; Sat, 07 Jan 2006 06:07:08 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k07B0M26015704; Sat, 7 Jan 2006 22:00:22 +1100 (EST) From: Darren Reed Message-Id: <200601071059.k07AxoYD015272@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Sec 6.1: Truncation In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122EA53DC@xmb-rtp-20d.amer.cisco.com> To: "Anton Okmianski (aokmians)" Date: Sat, 7 Jan 2006 21:59:50 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > Rainer and all: .. > "Receivers SHOULD follow this order of preference when it comes to truncation: > > 1) No truncation > 2) Truncation by dropping SD-ELEMENTs > 3) If 2) not sufficient, truncate MSG" > > I don't think that this is a good recommendation. Is this likely to be how people implement truncation ? I'm more inclined to believe that truncation will happen when the incoming message is too big for a buffer, so you start reading in data (and dropping it) until you reach the end of the buffer. The above requirement forces everyone to accept all maximum length messages before deciding one is too big. > I also think, in general it is useful to put more important data first, Agreed. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jan 07 16:26:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvLZl-0000PQ-40; Sat, 07 Jan 2006 16:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvLZj-0000Oz-Ai for syslog@megatron.ietf.org; Sat, 07 Jan 2006 16:26:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05787 for ; Sat, 7 Jan 2006 16:24:53 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvLfs-00079d-NI for syslog@ietf.org; Sat, 07 Jan 2006 16:32:34 -0500 Received: from pc6 (1Cust131.tnt102.lnd4.gbr.da.uu.net [213.116.52.131]) by ranger.systems.pipex.net (Postfix) with SMTP id 81201E00077F; Sat, 7 Jan 2006 21:25:48 +0000 (GMT) Message-ID: <019201c613c8$2581fa60$0601a8c0@pc6> From: "Tom Petch" To: "Sam Hartman" References: <03e701c612fd$a71c1860$0601a8c0@pc6> Subject: Re: [Syslog] Charter comments from IESG Review Date: Sat, 7 Jan 2006 21:22:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Sam Hartman" To: "Tom Petch" Cc: Sent: Friday, January 06, 2006 10:27 PM Subject: Re: [Syslog] Charter comments from IESG Review > >>>>> "Tom" == Tom Petch writes: > > Tom> Sam I struggle to think what a security system would look > Tom> like when the protocol is purely simplex, apart from a MAC to > Tom> give integrity with some shared secret transmitted totally > Tom> out of band. > > By this do you mean without two-way communication? > Yes, I meant without two-way communication > If so, yes, both S/MIME and OpenPGP support this model. However I'll > point oun that it is not a requirement that syslog work that way; for > example RFC 3195 certainly has connections. > I'll look at those, thanks. I agree syslog could be, perhaps should be for meaningful security, but often at present is not, so I wanted to see what security was possible with just one way communication Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 03:09:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evs63-0008M6-AL; Mon, 09 Jan 2006 03:09:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evs60-0008L2-VY for syslog@megatron.ietf.org; Mon, 09 Jan 2006 03:09:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24794 for ; Mon, 9 Jan 2006 03:08:22 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvsBw-0004JI-8q for syslog@ietf.org; Mon, 09 Jan 2006 03:16:21 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id F30AF27C02A; Mon, 9 Jan 2006 09:02:56 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11637-06; Mon, 9 Jan 2006 09:02:56 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id A472727C007; Mon, 9 Jan 2006 09:02:56 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 09:08:40 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter comments from IESG Review MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 09:08:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E419F@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Charter comments from IESG Review Thread-Index: AcYSRX0hHnTLxFYcTcijIGj1zaRKiQCqzqtg From: "Rainer Gerhards" To: "Sam Hartman" , X-OriginalArrivalTime: 09 Jan 2006 08:08:40.0832 (UTC) FILETIME=[E6CB2800:01C614F3] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Sam & WG, I understand the reasoning behind requiring a security mechanism. I just want to remind everyone that a major drawback in Vancouver was that we had lost some backwards-compatibility to existing syslog implementations. The weeks after Vancouver we worked hard to find a minimum consensus on how we could provide the needed backwards compatibility. When we mandate a security mechanism, we must be very careful not to invalidate all these attempts. Why? Simply because any transport-layer requirement (DTSL, SSL, SSH, whatever) would NOT be compatible with currently existing syslog implementations. So due to this requirement, we can not create a backwards-compatible spec (not even in the sense that existing receivers can put messages in the right bins). So in my point of view the only option is to use structured-data embedded signatures. As they do not modify the message format AND work over UDP, they allow old receivers to receive messages and put them into the right bins while new receivers can enjoy their benefits. In my point of view, anything further (like required confidentiality) conflicts with the backwards-compatibility approach and thus with the rest of the new charter. So I propose we update the charter to include that item and make sure syslog-sign advances. Syslog-protocol can than require all messages to be signed via syslog-sign. Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Thursday, January 05, 2006 11:12 PM > To: syslog@ietf.org > Subject: [Syslog] Charter comments from IESG Review >=20 >=20 >=20 > Hi. The IESg reviewed the proposed syslog charter at today's telechat > and decided that it requires revision. The main concern seems to be > the lack of a mandatory to implement security mechanism. I indicated > this might be the case in the Vancouver meeting. >=20 > so, you definitely need to have some sort of mandatory to implement > security mechanism. I'm not quite sure what needs to be said about > this in the charter. > But the working group will need to: >=20 > 1) Identify a threat model for syslog >=20 >=20 > 2) Define mechanisms to address these threats. >=20 > So, questions for the threat model include things like whether > confidentiality is important or whether integrity of mesages is > sufficient. >=20 > Depending on the threat model here are some possible solutions: >=20 > 1) Require some transport like syslog over TLS|DTLS be implemented. >=20 > 2) Require that all senders implement signatures stored in structured > data as an option. >=20 > I don't think you need to commit to one of these options now. > However, you do need to reflect the security issues in the charter. >=20 > --Sam >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 03:12:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evs8N-0000G3-Qm; Mon, 09 Jan 2006 03:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evs8M-0000FJ-A0 for syslog@megatron.ietf.org; Mon, 09 Jan 2006 03:12:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24894 for ; Mon, 9 Jan 2006 03:10:48 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvsEd-0004O2-5i for syslog@ietf.org; Mon, 09 Jan 2006 03:18:47 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 35ECD27C02A; Mon, 9 Jan 2006 09:05:59 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11637-07; Mon, 9 Jan 2006 09:05:59 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id F318A27C007; Mon, 9 Jan 2006 09:05:58 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 09:11:43 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter comments from IESG Review MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 09:11:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E41A0@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Charter comments from IESG Review Thread-Index: AcYS7sA1hs3tzMpQQuCvNbQeXuDKjgCBXLtQ From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 09 Jan 2006 08:11:43.0312 (UTC) FILETIME=[538F6500:01C614F4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris,=20 > > 1) Require some transport like syslog over TLS|DTLS be implemented. >=20 > RFC 3195 requires the use of RFC 3080 which requires TLS. small glitch: RFC 3080 provides support for a TLS profile, but it does not mandate it. Most existing RFC 3195 implementations do NOT support the TLS tuning profile. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 03:15:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvsBc-0000fu-T2; Mon, 09 Jan 2006 03:15:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvsBb-0000fp-Db for syslog@megatron.ietf.org; Mon, 09 Jan 2006 03:15:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25043 for ; Mon, 9 Jan 2006 03:14:09 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvsHY-0004Rs-9P for syslog@ietf.org; Mon, 09 Jan 2006 03:22:08 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 49DC327C02A; Mon, 9 Jan 2006 09:09:00 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11637-09; Mon, 9 Jan 2006 09:09:00 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1040827C007; Mon, 9 Jan 2006 09:08:59 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 09:14:44 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter comments from IESG Review MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 09:14:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E41A1@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Charter comments from IESG Review Thread-Index: AcYT0Ub++HOyLVJMS4atE4n04gbZsgBI0lJQ From: "Rainer Gerhards" To: "Tom Petch" , "Sam Hartman" X-OriginalArrivalTime: 09 Jan 2006 08:14:44.0555 (UTC) FILETIME=[BF96E1B0:01C614F4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, > > If so, yes, both S/MIME and OpenPGP support this model. =20 > However I'll > > point oun that it is not a requirement that syslog work=20 > that way; for > > example RFC 3195 certainly has connections. > > > I'll look at those, thanks. I agree syslog could be, perhaps=20 > should be for > meaningful security, but often at present is not, so I wanted=20 > to see what > security was > possible with just one way communication They use pre-shared secrets. It's probably best if you look at syslog-sign, which provides the necessary mechanisms for syslog. Please note that it still transmits data in clear-text (which I consider a requirement to remain backwards-compatible). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 07:06:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evvne-00082b-GM; Mon, 09 Jan 2006 07:06:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evvnc-00082W-OT for syslog@megatron.ietf.org; Mon, 09 Jan 2006 07:06:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09369 for ; Mon, 9 Jan 2006 07:05:37 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evvu7-0002Nn-J2 for syslog@ietf.org; Mon, 09 Jan 2006 07:13:39 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id DEA39E0053; Mon, 9 Jan 2006 07:06:40 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] Charter comments from IESG Review References: <577465F99B41C842AAFBE9ED71E70ABA0E419F@grfint2.intern.adiscon.com> From: Sam Hartman Date: Mon, 09 Jan 2006 07:06:40 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E419F@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Mon, 9 Jan 2006 09:08:39 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Rainer" == Rainer Gerhards writes: Rainer> Hi Sam & WG, I understand the reasoning behind requiring a Rainer> security mechanism. I just want to remind everyone that a Rainer> major drawback in Vancouver was that we had lost some Rainer> backwards-compatibility to existing syslog Rainer> implementations. Rainer> The weeks after Vancouver we worked hard to find a minimum Rainer> consensus on how we could provide the needed backwards Rainer> compatibility. Rainer> When we mandate a security mechanism, we must be very Rainer> careful not to invalidate all these attempts. Agreed. Rainer> Why? Simply Rainer> because any transport-layer requirement (DTSL, SSL, SSH, Rainer> whatever) would NOT be compatible with currently existing Rainer> syslog implementations. So due to this requirement, we can Rainer> not create a backwards-compatible spec (not even in the Rainer> sense that existing receivers can put messages in the Rainer> right bins). Let's be clear about what backward compatibility we're looking for. Do we require that new senders be able to be configured to talk to old receivers? Or do we require that old receivers be able to put any message from a new sender into the right place? In particular what you're seeming to say implies that we cannot define new transports because doing so would be backward incompatible. I don't think that is what we said. If we do define a new transport, presumably both UDP and the secure transport would be mandatory to implement. Rainer> So in my point of view the only option is to Rainer> use structured-data embedded signatures. As they do not Rainer> modify the message format AND work over UDP, they allow Rainer> old receivers to receive messages and put them into the Rainer> right bins while new receivers can enjoy their benefits. This is a valid approach. This means delaying protocol until syslog-sign is ready. Note that Russ, Bill Fenner and I have serious questions about syslog-sign because it does not reuse CMS, OpenPGP or some other format. We would need these questions answered before it could go forward in its current form. You would also need to make syslog-sign mandatory to implement and would need to believe that people wern't going to just ignore that. Rainer> In my point of view, anything further (like required Rainer> confidentiality) conflicts with the Rainer> backwards-compatibility approach and thus with the rest of Rainer> the new charter. I'm going to ask you to do the analysis in terms of what is required from a security standpoint. If that analysis ends up being incompatible with backward compatibility requirements, then we'll have to evaluate tradeoffs. However if there is a solution compatible both ith security and backward compatibility, that's better. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 07:07:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvvoG-0008FM-Mj; Mon, 09 Jan 2006 07:07:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvvoF-0008FD-UM for syslog@megatron.ietf.org; Mon, 09 Jan 2006 07:07:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09389 for ; Mon, 9 Jan 2006 07:06:16 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evvuk-0002OH-MM for syslog@ietf.org; Mon, 09 Jan 2006 07:14:18 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BC5C9E0053; Mon, 9 Jan 2006 07:07:34 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] Charter comments from IESG Review References: <577465F99B41C842AAFBE9ED71E70ABA0E41A1@grfint2.intern.adiscon.com> From: Sam Hartman Date: Mon, 09 Jan 2006 07:07:34 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E41A1@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Mon, 9 Jan 2006 09:14:43 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Rainer" == Rainer Gerhards writes: Rainer> Tom, >> > If so, yes, both S/MIME and OpenPGP support this model. >> However I'll > point oun that it is not a requirement that >> syslog work that way; for > example RFC 3195 certainly has >> connections. >> > >> I'll look at those, thanks. I agree syslog could be, perhaps >> should be for meaningful security, but often at present is not, >> so I wanted to see what security was possible with just one way >> communication Rainer> They use pre-shared secrets. Not typically. They typically use public keys. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 08:00:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvwdE-0001ek-Er; Mon, 09 Jan 2006 08:00:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evwd8-0001d8-Fy for syslog@megatron.ietf.org; Mon, 09 Jan 2006 08:00:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12207 for ; Mon, 9 Jan 2006 07:58:50 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evwj6-0003pN-GU for syslog@ietf.org; Mon, 09 Jan 2006 08:06:53 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 583C727C02A; Mon, 9 Jan 2006 13:53:35 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19583-01; Mon, 9 Jan 2006 13:53:35 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 195BD27C007; Mon, 9 Jan 2006 13:53:35 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 13:59:20 +0100 Subject: RE: [Syslog] Charter comments from IESG Review MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 13:59:31 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E41B9@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Charter comments from IESG Review Thread-Index: AcYVFUlfv4LTpW6QStep+Aveubf2eQABt5Hg From: "Rainer Gerhards" To: "Sam Hartman" X-OriginalArrivalTime: 09 Jan 2006 12:59:20.0374 (UTC) FILETIME=[81921560:01C6151C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Monday, January 09, 2006 1:08 PM > To: Rainer Gerhards > Cc: Tom Petch; syslog@ietf.org > Subject: Re: [Syslog] Charter comments from IESG Review >=20 > >>>>> "Rainer" =3D=3D Rainer Gerhards = writes: >=20 > Rainer> Tom, > >> > If so, yes, both S/MIME and OpenPGP support this model. > >> However I'll > point oun that it is not a requirement that > >> syslog work that way; for > example RFC 3195 certainly has > >> connections. > >> > > >> I'll look at those, thanks. I agree syslog could be, perhaps > >> should be for meaningful security, but often at present is not, > >> so I wanted to see what security was possible with just one way > >> communication >=20 > Rainer> They use pre-shared secrets. >=20 > Not typically. > They typically use public keys. >=20 Sorry, yes, I was totally wrong in my wording. What I intended to say was that the keys are exchanged on a medium different then the current session (e.g. key servers). So this means some other protocol is required to obtain that information (and it is processed "outside" of the syslog protocol). Thus, I wanted to say, it does not necessarily need to change the simplex nature of syslog (but some initial negotiation is necessary, which I do not think to be a problem). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 08:14:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evwqp-0004kf-BT; Mon, 09 Jan 2006 08:14:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evwqm-0004iq-0q for syslog@megatron.ietf.org; Mon, 09 Jan 2006 08:14:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13735 for ; Mon, 9 Jan 2006 08:12:56 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvwxG-0004Pj-I9 for syslog@ietf.org; Mon, 09 Jan 2006 08:20:59 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 29B0CE0053; Mon, 9 Jan 2006 08:14:05 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] Charter comments from IESG Review References: <577465F99B41C842AAFBE9ED71E70ABA0E41B9@grfint2.intern.adiscon.com> From: Sam Hartman Date: Mon, 09 Jan 2006 08:14:05 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E41B9@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Mon, 9 Jan 2006 13:59:31 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Rainer" == Rainer Gerhards writes: Rainer> Sorry, yes, I was totally wrong in my wording. What I Rainer> intended to say was that the keys are exchanged on a Rainer> medium different then the current session (e.g. key Rainer> servers). This is not typically how things work for S/MIME. In S/MIME I will typically inclue a certificate (which includes my public key) in-band with some signature data. If I was generating a lot of signatures I might only sometimes include my certificate to save on space and bandwith. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 08:24:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evx0F-0006py-6m; Mon, 09 Jan 2006 08:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evx0C-0006pt-U9 for syslog@megatron.ietf.org; Mon, 09 Jan 2006 08:24:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14268 for ; Mon, 9 Jan 2006 08:22:41 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evx6C-0004fM-4P for syslog@ietf.org; Mon, 09 Jan 2006 08:30:44 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 781D927C02A; Mon, 9 Jan 2006 14:17:32 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19583-04; Mon, 9 Jan 2006 14:17:32 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 338B327C007; Mon, 9 Jan 2006 14:17:32 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 14:23:15 +0100 Subject: RE: [Syslog] Charter comments from IESG Review MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 14:23:29 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E41BA@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Charter comments from IESG Review Thread-Index: AcYVFTKTCBaPmeCiRzWMaKhbDpDpxQACP55Q From: "Rainer Gerhards" To: "Sam Hartman" X-OriginalArrivalTime: 09 Jan 2006 13:23:16.0017 (UTC) FILETIME=[D947D210:01C6151F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam,=20 > Rainer> Why? Simply > Rainer> because any transport-layer requirement (DTSL, SSL, SSH, > Rainer> whatever) would NOT be compatible with currently existing > Rainer> syslog implementations. So due to this requirement, we can > Rainer> not create a backwards-compatible spec (not even in the > Rainer> sense that existing receivers can put messages in the > Rainer> right bins).=20 >=20 > Let's be clear about what backward compatibility we're looking for. > Do we require that new senders be able to be configured to talk to old > receivers? =20 I depens on what you mean with that - if "to be configured to talk to old receivers" means they must not use -protocol but rfc 3164 instead, this is not what was discussed on this list (-protocol-14 had addressed this already). > Or do we require that old receivers be able to put any > message from a new sender into the right place? Not over any transport, but the core need behind the recent changes was that -protocol/-transport-udp messages should allow an old sender to put it into the right bin. This implies plain text transmission. >=20 > In particular what you're seeming to say implies that we cannot define > new transports because doing so would be backward incompatible. I > don't think that is what we said. >=20 > If we do define a new transport, presumably both UDP and the secure > transport would be mandatory to implement. This looks like I misunderstood your intension. I thought that unsecured UDP should no longer be supported. So what you actually said is that we can go ahead with the unsecured UDP as long as we also mandate a (different) secure transport. If that is the case, I am reliefed, because this is something that can practically be done. And, yes, configuring a sender to use unsecured udp (-transport-udp) for one target and a secured transport for another target is definitely a good option. We just need to be able to interoperate with the "unsecured plain text udp syslog world". Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 08:36:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvxBr-0000bG-Mb; Mon, 09 Jan 2006 08:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvxBp-0000b6-HY for syslog@megatron.ietf.org; Mon, 09 Jan 2006 08:36:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14921 for ; Mon, 9 Jan 2006 08:34:41 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvxIL-0004zI-0V for syslog@ietf.org; Mon, 09 Jan 2006 08:42:45 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2AC17E0053; Mon, 9 Jan 2006 08:35:56 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] Charter comments from IESG Review References: <577465F99B41C842AAFBE9ED71E70ABA0E41BA@grfint2.intern.adiscon.com> From: Sam Hartman Date: Mon, 09 Jan 2006 08:35:56 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E41BA@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Mon, 9 Jan 2006 14:23:29 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Rainer" == Rainer Gerhards writes: Rainer> This looks like I misunderstood your intension. I thought Rainer> that unsecured UDP should no longer be supported. That was not my intent. Rainer> So what Rainer> you actually said is that we can go ahead with the Rainer> unsecured UDP as long as we also mandate a (different) Rainer> secure transport. What I said is that you need to have a mandatory-to-implement mode of operation that meets your security goals. You can certainly support transport-udp. One way to do this is to have a new secure transport. Another way to do this (assuming you decide confidentiality need not be a security goal) is to use something like syslog-sign. Personally I think a new transport might be more important than syslog-sign but so long as the WG clearly articulates its security goals, those goals make sense, and the wg then meets the goals, the preference between syslog-sign and transport is a WG matter. Also, I agree that you have described the threats to syslog in adequate detail already; the question is which threats do you want toaddress. You do need to explain that in your documents and you need to justify that decision. So, how much needs to be done for the charter? Well, I'd like text added to the deliverable for -protocol noting that it will require a secure mode of operation. If you are going to decide that syslog-sign is the right path, then you should add text about that to the charter. I don't think you need to choose a transport before chartering, although I caution that transport wars are a good way to lose WG momentum; look at the ISMS work over the past few IETFs for an example. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 10:44:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzCM-0000gc-9B; Mon, 09 Jan 2006 10:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzCL-0000gX-89 for syslog@megatron.ietf.org; Mon, 09 Jan 2006 10:44:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23003 for ; Mon, 9 Jan 2006 10:43:22 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzIr-0000A4-2X for syslog@ietf.org; Mon, 09 Jan 2006 10:51:25 -0500 Received: from pc6 (1Cust181.tnt7.lnd4.gbr.da.uu.net [62.188.136.181]) by blaster.systems.pipex.net (Postfix) with SMTP id 9FABDE00039A; Mon, 9 Jan 2006 15:44:20 +0000 (GMT) Message-ID: <01c601c6152a$c6304620$0601a8c0@pc6> From: "Tom Petch" To: "Sam Hartman" References: <577465F99B41C842AAFBE9ED71E70ABA0E41BA@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Charter comments from IESG Review Date: Mon, 9 Jan 2006 15:40:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam I was about to say that we were getting into useful detail but that we could sort out the charter without it, but you seem to saying not. That is, I was hoping that where the charter says The goal of this working group is to address the security and integrity problems it might say The goal of this working group is to identify the security problems, perform a threat analysis and document a solution to the perceived threats, without committing us to either a -sign or a secure transport approach (and yes, we did start the transport wars, some time ago, with SSH v TLS:-( Tom Petch ----- Original Message ----- From: "Sam Hartman" To: "Rainer Gerhards" Cc: Sent: Monday, January 09, 2006 2:35 PM Subject: Re: [Syslog] Charter comments from IESG Review > >>>>> "Rainer" == Rainer Gerhards writes: > > Rainer> This looks like I misunderstood your intension. I thought > Rainer> that unsecured UDP should no longer be supported. > > That was not my intent. > > Rainer> So what > Rainer> you actually said is that we can go ahead with the > Rainer> unsecured UDP as long as we also mandate a (different) > Rainer> secure transport. > > > What I said is that you need to have a mandatory-to-implement mode of > operation that meets your security goals. You can certainly support > transport-udp. One way to do this is to have a new secure transport. > Another way to do this (assuming you decide confidentiality need not > be a security goal) is to use something like syslog-sign. > > Personally I think a new transport might be more important than > syslog-sign but so long as the WG clearly articulates its security > goals, those goals make sense, and the wg then meets the goals, the > preference between syslog-sign and transport is a WG matter. > > > > Also, I agree that you have described the threats to syslog in > adequate detail already; the question is which threats do you want > toaddress. You do need to explain that in your documents and you need > to justify that decision. > > So, how much needs to be done for the charter? Well, I'd like text > added to the deliverable for -protocol noting that it will require a > secure mode of operation. If you are going to decide that syslog-sign > is the right path, then you should add text about that to the charter. > I don't think you need to choose a transport before chartering, > although I caution that transport wars are a good way to lose WG > momentum; look at the ISMS work over the past few IETFs for an > example. > > --Sam > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 10:44:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzCW-0000hI-2s; Mon, 09 Jan 2006 10:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzCU-0000hC-A6 for syslog@megatron.ietf.org; Mon, 09 Jan 2006 10:44:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23013 for ; Mon, 9 Jan 2006 10:43:31 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzJ0-0000Ab-Nm for syslog@ietf.org; Mon, 09 Jan 2006 10:51:35 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Jan 2006 07:44:41 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k09FidWF024458; Mon, 9 Jan 2006 07:44:40 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 10:44:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Sec 6.1: Truncation Date: Mon, 9 Jan 2006 10:44:38 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122EA568F@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYS8k5MFvQCqVz3RJqX9nFzDRup+wACkoPgAH4rzAAADy9LcA== From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 09 Jan 2006 15:44:39.0211 (UTC) FILETIME=[99A87FB0:01C61533] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: I agree - this is better than a convoluted rule.=20 I think we only have any business in defining truncation for relays. = For collectors, we have tried to stay away from describing how messages = are stored. =20 For relays, I think it would be useful to state that relay can't just = drop arbitrary message parts. Your statements about "some parts ... are = lost" may be interpreted that way.=20 I would recommend that we state that any truncation must happen at the = end of the message, which I think is what truncation means to a lot of = people anyway. This would prevent an implementation which prefers to = throw out STRUCTURED-DATA before the MSG content. A consistent behavior = is useful for interop and, in particular, may help in dealing with = security issues.=20 Thanks, Anton.=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Monday, January 09, 2006 3:21 AM > To: Anton Okmianski (aokmians) > Subject: RE: [Syslog] Sec 6.1: Truncation >=20 > Anton, Darren, >=20 > I agree that the truncation rule is probably not really=20 > useful, even confusing. I think it is hard to predict for any=20 > potential message if the more interesting content is in=20 > STRUCTURED-DATA or in the MSG part. > For example, with our current SD-IDs, I'd prefer to trunctate=20 > them instead of MSG. Obviously, the case is different for=20 > your LINKDOWN sample. I also agree with Darren that=20 > truncation probably happens on the transport layer, the=20 > application may not even see the full message. >=20 > My conclusion, however, is slightly different: I recommend=20 > now that we remove truncation rules from -protocol. We should=20 > just say that truncation might happen and that in this case=20 > some parts of the message are lost - what is at the=20 > discretion of the receiver. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton Okmianski=20 > > (aokmians) > > Sent: Friday, January 06, 2006 9:48 PM > > To: syslog@ietf.org > > Subject: [Syslog] Sec 6.1: Truncation > >=20 > > Rainer and all: > >=20 > > I started reading draft #16. Since we are revisiting=20 > everything... I=20 > > am not very comfortable with the current truncation rules. > >=20 > > "Receivers SHOULD follow this order of preference when it comes to=20 > > truncation: > >=20 > > 1) No truncation > > 2) Truncation by dropping SD-ELEMENTs > > 3) If 2) not sufficient, truncate MSG" > >=20 > > I don't think that this is a good recommendation. I would=20 > assume that=20 > > in many cases people would try to tokenize more important data into=20 > > structured data and use message text as a secondary user-friendly=20 > > description. For example, for LINK_DOWN message, I would probably=20 > > encode link ID in the structured elements as this is something that=20 > > should be readily available for receivers. The MSGID could be=20 > > "LINK_DOWN" and the MSG text may simply be "Link down". If you=20 > > truncate the structured data, it makes it harder. > >=20 > > I also think, in general it is useful to put more important data=20 > > first, which is another reason for putting more valuable data into=20 > > structured data in a more compact way. > >=20 > > Additionally, structured data can be used to provide=20 > message length or=20 > > digest, which can help receiver to determine if message was=20 > truncated. > >=20 > > Also, I think this statement is very convoluted: > >=20 > > "Please note that it is possible that the MSG field is truncated=20 > > without dropping any SD-PARAMS. This is the case if a=20 > message with an=20 > > empty STRUCTURED-DATA field must be truncated." > >=20 > > I think I understand what you are driving at, but I don't see it as=20 > > adding any requirements or clarification. > >=20 > > This sentence is not clear although I know what you are=20 > trying to say: > >=20 > > "The limits below are minimum maximum lengths, not maximum length." > >=20 > > I propose replacing the entire section 6.1 with this text: > >=20 > > "Syslog message limits are dictated by the syslog transport=20 > mapping in=20 > > use. Each transport mapping MUST define the minimum=20 > required message=20 > > length support. Any syslog transport mapping MUST support=20 > messages of=20 > > up to and including 480 octets in length. > >=20 > > Any syslog receiver MUST be able to accept messages of up to and=20 > > including 480 octets in length. All receiver=20 > implementations SHOULD=20 > > be able to accept messages of up to and including 2048 octets in=20 > > length. Receivers MAY receive messages larger than 2048 octets in=20 > > length. If a receiver receives a message with a length=20 > larger than it=20 > > supports, the receiver MAY discard the message or truncate the=20 > > payload. > >=20 > > If truncation is performed by the receiver, it MUST first=20 > truncate the=20 > > MSG field as necessary to meet the supported length limit. If=20 > > truncation of the entire MSG field is not sufficient, then=20 > > additionally, the STRUCTURED-DATA field MUST be truncated=20 > by removing=20 > > one or more SD-ELEMENT fields. A minimum number of=20 > SD-ELEMENT fields=20 > > MUST be truncated starting from the end as necessary to meet the=20 > > supported length limit. SD-ELEMENT field can't be truncated=20 > partially. > > If all SD-ELEMENT fields are removed, NILVALUE MUST be=20 > specified for=20 > > STRUCTURED-DATA field. Truncation of HEADER > > field MUST NOT be performed." =20 > >=20 > > BTW, in your text or mine, what happens if message is malformed? A=20 > > proxy won't be able to truncate it properly then. We don't want to=20 > > prevent it from truncating it in some way and sending the message=20 > > further, I would think. At least you will see something at=20 > the final=20 > > destination, which maybe more useful than nothing. If we just made=20 > > truncation a simple take the first X octets out of Y=20 > octets, it would=20 > > not be an issue, but then proxy would be allowed to turn a=20 > well-formed > > message into malformed message upon truncation. =20 > >=20 > > What do you think? > >=20 > > Thanks, > > Anton.=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 10:49:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzGr-0001Ru-Tg; Mon, 09 Jan 2006 10:49:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzGp-0001Rj-QP for syslog@megatron.ietf.org; Mon, 09 Jan 2006 10:49:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23469 for ; Mon, 9 Jan 2006 10:48:01 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzMq-0000Kh-2y for syslog@ietf.org; Mon, 09 Jan 2006 10:56:04 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 46AD227C02A; Mon, 9 Jan 2006 16:42:50 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21879-05; Mon, 9 Jan 2006 16:42:50 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D1FE227C007; Mon, 9 Jan 2006 16:42:49 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jan 2006 16:48:36 +0100 Subject: RE: [Syslog] Sec 6.1: Truncation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2006 16:48:41 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E41C5@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYS8k5MFvQCqVz3RJqX9nFzDRup+wACkoPgAH4rzAAADy9LcAAAdK/g From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" X-OriginalArrivalTime: 09 Jan 2006 15:48:36.0469 (UTC) FILETIME=[27133250:01C61534] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Rainer: >=20 > I agree - this is better than a convoluted rule.=20 >=20 > I think we only have any business in defining truncation for=20 > relays. For collectors, we have tried to stay away from=20 > describing how messages are stored. =20 >=20 > For relays, I think it would be useful to state that relay=20 > can't just drop arbitrary message parts. Your statements=20 > about "some parts ... are lost" may be interpreted that way.=20 Actually, this was what I meant ;) [I saw a number of use cases where it would make sense to strip some known-not-so-relavant SD-IDs to be strippedd], but ... >=20 > I would recommend that we state that any truncation must=20 > happen at the end of the message, which I think is what=20 > truncation means to a lot of people anyway. This would=20 > prevent an implementation which prefers to throw out=20 > STRUCTURED-DATA before the MSG content. A consistent=20 > behavior is useful for interop and, in particular, may help=20 > in dealing with security issues. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... this is more important. I now agree with your point. As a side-note, we had the idea that relay operations may become a separate document, so I would prefer not to dig too deep into relay behaviour. To specify what you recommend, this is not necessary, so this is not really a discussion topic here. Rainer=20 >=20 > Thanks, > Anton.=20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Monday, January 09, 2006 3:21 AM > > To: Anton Okmianski (aokmians) > > Subject: RE: [Syslog] Sec 6.1: Truncation > >=20 > > Anton, Darren, > >=20 > > I agree that the truncation rule is probably not really=20 > > useful, even confusing. I think it is hard to predict for any=20 > > potential message if the more interesting content is in=20 > > STRUCTURED-DATA or in the MSG part. > > For example, with our current SD-IDs, I'd prefer to trunctate=20 > > them instead of MSG. Obviously, the case is different for=20 > > your LINKDOWN sample. I also agree with Darren that=20 > > truncation probably happens on the transport layer, the=20 > > application may not even see the full message. > >=20 > > My conclusion, however, is slightly different: I recommend=20 > > now that we remove truncation rules from -protocol. We should=20 > > just say that truncation might happen and that in this case=20 > > some parts of the message are lost - what is at the=20 > > discretion of the receiver. > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton=20 > Okmianski=20 > > > (aokmians) > > > Sent: Friday, January 06, 2006 9:48 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] Sec 6.1: Truncation > > >=20 > > > Rainer and all: > > >=20 > > > I started reading draft #16. Since we are revisiting=20 > > everything... I=20 > > > am not very comfortable with the current truncation rules. > > >=20 > > > "Receivers SHOULD follow this order of preference when it=20 > comes to=20 > > > truncation: > > >=20 > > > 1) No truncation > > > 2) Truncation by dropping SD-ELEMENTs > > > 3) If 2) not sufficient, truncate MSG" > > >=20 > > > I don't think that this is a good recommendation. I would=20 > > assume that=20 > > > in many cases people would try to tokenize more important=20 > data into=20 > > > structured data and use message text as a secondary user-friendly=20 > > > description. For example, for LINK_DOWN message, I would probably=20 > > > encode link ID in the structured elements as this is=20 > something that=20 > > > should be readily available for receivers. The MSGID could be=20 > > > "LINK_DOWN" and the MSG text may simply be "Link down". If you=20 > > > truncate the structured data, it makes it harder. > > >=20 > > > I also think, in general it is useful to put more important data=20 > > > first, which is another reason for putting more valuable=20 > data into=20 > > > structured data in a more compact way. > > >=20 > > > Additionally, structured data can be used to provide=20 > > message length or=20 > > > digest, which can help receiver to determine if message was=20 > > truncated. > > >=20 > > > Also, I think this statement is very convoluted: > > >=20 > > > "Please note that it is possible that the MSG field is truncated=20 > > > without dropping any SD-PARAMS. This is the case if a=20 > > message with an=20 > > > empty STRUCTURED-DATA field must be truncated." > > >=20 > > > I think I understand what you are driving at, but I don't=20 > see it as=20 > > > adding any requirements or clarification. > > >=20 > > > This sentence is not clear although I know what you are=20 > > trying to say: > > >=20 > > > "The limits below are minimum maximum lengths, not=20 > maximum length." > > >=20 > > > I propose replacing the entire section 6.1 with this text: > > >=20 > > > "Syslog message limits are dictated by the syslog transport=20 > > mapping in=20 > > > use. Each transport mapping MUST define the minimum=20 > > required message=20 > > > length support. Any syslog transport mapping MUST support=20 > > messages of=20 > > > up to and including 480 octets in length. > > >=20 > > > Any syslog receiver MUST be able to accept messages of up to and=20 > > > including 480 octets in length. All receiver=20 > > implementations SHOULD=20 > > > be able to accept messages of up to and including 2048 octets in=20 > > > length. Receivers MAY receive messages larger than 2048 octets in=20 > > > length. If a receiver receives a message with a length=20 > > larger than it=20 > > > supports, the receiver MAY discard the message or truncate the=20 > > > payload. > > >=20 > > > If truncation is performed by the receiver, it MUST first=20 > > truncate the=20 > > > MSG field as necessary to meet the supported length limit. If=20 > > > truncation of the entire MSG field is not sufficient, then=20 > > > additionally, the STRUCTURED-DATA field MUST be truncated=20 > > by removing=20 > > > one or more SD-ELEMENT fields. A minimum number of=20 > > SD-ELEMENT fields=20 > > > MUST be truncated starting from the end as necessary to meet the=20 > > > supported length limit. SD-ELEMENT field can't be truncated=20 > > partially. > > > If all SD-ELEMENT fields are removed, NILVALUE MUST be=20 > > specified for=20 > > > STRUCTURED-DATA field. Truncation of HEADER > > > field MUST NOT be performed." =20 > > >=20 > > > BTW, in your text or mine, what happens if message is=20 > malformed? A=20 > > > proxy won't be able to truncate it properly then. We=20 > don't want to=20 > > > prevent it from truncating it in some way and sending the message=20 > > > further, I would think. At least you will see something at=20 > > the final=20 > > > destination, which maybe more useful than nothing. If we=20 > just made=20 > > > truncation a simple take the first X octets out of Y=20 > > octets, it would=20 > > > not be an issue, but then proxy would be allowed to turn a=20 > > well-formed > > > message into malformed message upon truncation. =20 > > >=20 > > > What do you think? > > >=20 > > > Thanks, > > > Anton.=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 09 10:53:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzL7-0002Qy-2w; Mon, 09 Jan 2006 10:53:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzL5-0002Qt-Mt for syslog@megatron.ietf.org; Mon, 09 Jan 2006 10:53:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24182 for ; Mon, 9 Jan 2006 10:52:25 -0500 (EST) Received: from stratton-five-twenty.mit.edu ([18.187.7.9] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzRb-0000g0-Ke for syslog@ietf.org; Mon, 09 Jan 2006 11:00:28 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 32707E0077; Mon, 9 Jan 2006 10:53:37 -0500 (EST) To: "Tom Petch" Subject: Re: [Syslog] Charter comments from IESG Review References: <577465F99B41C842AAFBE9ED71E70ABA0E41BA@grfint2.intern.adiscon.com> <01c601c6152a$c6304620$0601a8c0@pc6> From: Sam Hartman Date: Mon, 09 Jan 2006 10:53:37 -0500 In-Reply-To: <01c601c6152a$c6304620$0601a8c0@pc6> (Tom Petch's message of "Mon, 9 Jan 2006 15:40:46 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Tom" == Tom Petch writes: Tom> without committing us to either a -sign or a secure transport Tom> approach (and yes, we did start the transport wars, some time Tom> ago, with SSH v TLS:-( I really think that you need to identify your deliverables in the charter. Either sign is or is not a critical path deliverable. (Similarly, if you go the transport route, you need a critical path deliverable of a secure transport.) --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 04:52:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGB1-0004RR-A2; Tue, 10 Jan 2006 04:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGAz-0004RL-J7 for syslog@megatron.ietf.org; Tue, 10 Jan 2006 04:52:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18424 for ; Tue, 10 Jan 2006 04:51:06 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwGHe-0003Jx-88 for syslog@ietf.org; Tue, 10 Jan 2006 04:59:19 -0500 Subject: RE: [Syslog] Charter comments from IESG Review From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E419F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E419F@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Tue, 10 Jan 2006 10:52:12 +0100 Message-Id: <1136886732.5149.66.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: > Of course, a threat model should also be developed, but please keep in > mind that anything other than signatures breaks what this WG has fought > for since Vancouver. > > syslog-protocol should be finished (I hope we are there soon) as well as > syslog-transport-udp. Then, these both should be taken to a rest and > syslog-sign be modified in the sense of -transport and being worked on. > I think this can probably done quickly, because -sign is almost complete > and just needs to be modified to take advantage of -protocol. > > To be honest, though, I have to admit that I expect many of the upcoming > implementations to violate syslog-protocol by just implementing > -protocol and -transport-udp, but not -sign. But that's probably not > something to care about... I know that some other mails discussed the same topic and a misunderstanding has already been resolved about whether to support transport-udp or not. I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. And in addition they address a different problem: 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 04:54:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGDJ-0004lR-IT; Tue, 10 Jan 2006 04:54:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGDH-0004lL-P7 for syslog@megatron.ietf.org; Tue, 10 Jan 2006 04:54:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18518 for ; Tue, 10 Jan 2006 04:53:28 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwGJQ-0003Md-V5 for syslog@ietf.org; Tue, 10 Jan 2006 05:01:42 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id ABC6627C029; Tue, 10 Jan 2006 10:48:06 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04602-05; Tue, 10 Jan 2006 10:48:06 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6DC0127C007; Tue, 10 Jan 2006 10:48:06 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 10:53:54 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter comments from IESG Review MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2006 10:53:52 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E41DE@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Charter comments from IESG Review Thread-Index: AcYVy43+28guhrFJQxi63cBp1FRaYQAACiyA From: "Rainer Gerhards" To: "Balazs Scheidler" X-OriginalArrivalTime: 10 Jan 2006 09:53:54.0141 (UTC) FILETIME=[C43B68D0:01C615CB] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I agree with Balazs suggestion and his reasoning. Rainer=20 > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Tuesday, January 10, 2006 10:52 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] Charter comments from IESG Review >=20 > On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: >=20 > > Of course, a threat model should also be developed, but=20 > please keep in > > mind that anything other than signatures breaks what this=20 > WG has fought > > for since Vancouver. > >=20 > > syslog-protocol should be finished (I hope we are there=20 > soon) as well as > > syslog-transport-udp. Then, these both should be taken to a rest and > > syslog-sign be modified in the sense of -transport and=20 > being worked on. > > I think this can probably done quickly, because -sign is=20 > almost complete > > and just needs to be modified to take advantage of -protocol. > >=20 > > To be honest, though, I have to admit that I expect many of=20 > the upcoming > > implementations to violate syslog-protocol by just implementing > > -protocol and -transport-udp, but not -sign. But that's probably not > > something to care about... >=20 > I know that some other mails discussed the same topic and a > misunderstanding has already been resolved about whether to support > transport-udp or not. >=20 > I would say that addressing the security concerns at the=20 > transport level > is way easier management and implementation wise than implementing > syslog-sign. And in addition they address a different problem: >=20 > 1) transport level implements security mechanisms on a per hop-by-hop > basis, the message itself is not authenticated, each of the relay > stations can modify the message >=20 > 2) syslog-sign implements per-message, end-to-end=20 > authenticity where the > relay hosts cannot modify messages as they are individually signed by > their origin. >=20 > So I'd go with using TLS/DTLS on the transport first and then possibly > adapting syslog-sign when the transport issues are resolved. >=20 > --=20 > Bazsi >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 06:04:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHJ1-0002zc-B6; Tue, 10 Jan 2006 06:04:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHIz-0002yE-Hx for syslog@megatron.ietf.org; Tue, 10 Jan 2006 06:04:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22065 for ; Tue, 10 Jan 2006 06:03:24 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHPd-00052k-Dx for syslog@ietf.org; Tue, 10 Jan 2006 06:11:39 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k0AB2vSW018824; Tue, 10 Jan 2006 22:02:57 +1100 (EST) From: Darren Reed Message-Id: <200601101102.k0AB2eZd015152@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Charter comments from IESG Review In-Reply-To: <1136886732.5149.66.camel@bzorp.balabit> To: Balazs Scheidler Date: Tue, 10 Jan 2006 22:02:40 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: > > I would say that addressing the security concerns at the transport level > is way easier management and implementation wise than implementing > syslog-sign. I disagree with the statement about management as the problem is the same for using a secure protocol at either transport or application level. > 1) transport level implements security mechanisms on a per hop-by-hop > basis, the message itself is not authenticated, each of the relay > stations can modify the message > > 2) syslog-sign implements per-message, end-to-end authenticity where the > relay hosts cannot modify messages as they are individually signed by > their origin. > > So I'd go with using TLS/DTLS on the transport first and then possibly > adapting syslog-sign when the transport issues are resolved. (1) and (2) are complimentary and one do not exclude the other from being necessary. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 06:19:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHX7-0006RF-Jx; Tue, 10 Jan 2006 06:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHX5-0006R9-9r for syslog@megatron.ietf.org; Tue, 10 Jan 2006 06:19:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22878 for ; Tue, 10 Jan 2006 06:17:59 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHdG-0005Q4-Bs for syslog@ietf.org; Tue, 10 Jan 2006 06:26:14 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 427B127C029; Tue, 10 Jan 2006 12:12:48 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05666-06; Tue, 10 Jan 2006 12:12:48 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id F331227C007; Tue, 10 Jan 2006 12:12:47 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jan 2006 12:18:36 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter comments from IESG Review MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2006 12:18:34 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E41E5@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Charter comments from IESG Review Thread-Index: AcYV1aM+FAF53DAFSFiCJ49rdmV8rwAAYIfw From: "Rainer Gerhards" To: "Darren Reed" , "Balazs Scheidler" X-OriginalArrivalTime: 10 Jan 2006 11:18:36.0893 (UTC) FILETIME=[99C9D0D0:01C615D7] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > 1) transport level implements security mechanisms on a per=20 > hop-by-hop > > basis, the message itself is not authenticated, each of the relay > > stations can modify the message > >=20 > > 2) syslog-sign implements per-message, end-to-end=20 > authenticity where the > > relay hosts cannot modify messages as they are individually=20 > signed by > > their origin. > >=20 > > So I'd go with using TLS/DTLS on the transport first and=20 > then possibly > > adapting syslog-sign when the transport issues are resolved. >=20 > (1) and (2) are complimentary and one do not exclude the other > from being necessary. That's right. But if I need to pick one, I'd go for TLS/DTLS, because I think that encryption is more desirable. If we include two deliverables in the charter, we can go for both of them. As Sam suggested, the threat model and what we think of being most important (to address) is the core need to do. I think Chris is already working on something and I'd like to hear the chair's comment before we go into detail. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 11:27:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMLY-0005V4-Vf; Tue, 10 Jan 2006 11:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMLX-0005Uj-VU for syslog@megatron.ietf.org; Tue, 10 Jan 2006 11:27:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18615 for ; Tue, 10 Jan 2006 11:26:24 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMSF-00083c-Nd for syslog@ietf.org; Tue, 10 Jan 2006 11:34:41 -0500 Subject: Re: [Syslog] Charter comments from IESG Review From: Balazs Scheidler To: Darren Reed In-Reply-To: <200601101102.k0AB2eZd015152@firewall.reed.wattle.id.au> References: <200601101102.k0AB2eZd015152@firewall.reed.wattle.id.au> Content-Type: text/plain Date: Tue, 10 Jan 2006 17:27:30 +0100 Message-Id: <1136910450.12950.4.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-01-10 at 22:02 +1100, Darren Reed wrote: > > On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: > > > > I would say that addressing the security concerns at the transport level > > is way easier management and implementation wise than implementing > > syslog-sign. > > I disagree with the statement about management as the problem is the > same for using a secure protocol at either transport or application > level. My reasoning is that people are "used to" encrypting channels with SSL, they are used to the PKI requirements it involves, they are familiar with SSL cipher suites, CA verification parameters and the like, in summary SSL/TLS itself is a familiar cryptographic framework. Syslog-sign on the other hand is different, it is true that it is going to use X.509 PKI, but all the other familiarity is gone. My point regarding managebility is that network operators use TLS already with a lot of applications (HTTPS is the primer example), compared to this using syslog/TLS is simple. > > > 1) transport level implements security mechanisms on a per hop-by-hop > > basis, the message itself is not authenticated, each of the relay > > stations can modify the message > > > > 2) syslog-sign implements per-message, end-to-end authenticity where the > > relay hosts cannot modify messages as they are individually signed by > > their origin. > > > > So I'd go with using TLS/DTLS on the transport first and then possibly > > adapting syslog-sign when the transport issues are resolved. > > (1) and (2) are complimentary and one do not exclude the other > from being necessary. True, (1) and (2) are independent, my point was to give priority to the first one as it already solves a lot of problems and will help us keep focused. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 11:33:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMQx-0008GA-C2; Tue, 10 Jan 2006 11:33:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMQw-0008Fa-6N for syslog@megatron.ietf.org; Tue, 10 Jan 2006 11:33:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19213 for ; Tue, 10 Jan 2006 11:31:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMXc-0008JB-Pw for syslog@ietf.org; Tue, 10 Jan 2006 11:40:16 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2006 08:33:05 -0800 X-IronPort-AV: i="3.99,351,1131350400"; d="scan'208"; a="389868440:sNHT35180394" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0AGX4WG001491; Tue, 10 Jan 2006 08:33:04 -0800 (PST) Date: Tue, 10 Jan 2006 08:33:04 -0800 (PST) From: Chris Lonvick To: Balazs Scheidler Subject: Re: [Syslog] Charter comments from IESG Review In-Reply-To: <1136910450.12950.4.camel@bzorp.balabit> Message-ID: References: <200601101102.k0AB2eZd015152@firewall.reed.wattle.id.au> <1136910450.12950.4.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, On Tue, 10 Jan 2006, Balazs Scheidler wrote: > On Tue, 2006-01-10 at 22:02 +1100, Darren Reed wrote: >>> On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: >>> >>> I would say that addressing the security concerns at the transport level >>> is way easier management and implementation wise than implementing >>> syslog-sign. >> >> I disagree with the statement about management as the problem is the >> same for using a secure protocol at either transport or application >> level. > > My reasoning is that people are "used to" encrypting channels with SSL, > they are used to the PKI requirements it involves, they are familiar > with SSL cipher suites, CA verification parameters and the like, in > summary SSL/TLS itself is a familiar cryptographic framework. > > Syslog-sign on the other hand is different, it is true that it is going > to use X.509 PKI, but all the other familiarity is gone. My point > regarding managebility is that network operators use TLS already with a > lot of applications (HTTPS is the primer example), compared to this > using syslog/TLS is simple. Agreed. I'm trying to work up a note that documents that. > >> >>> 1) transport level implements security mechanisms on a per hop-by-hop >>> basis, the message itself is not authenticated, each of the relay >>> stations can modify the message >>> >>> 2) syslog-sign implements per-message, end-to-end authenticity where the >>> relay hosts cannot modify messages as they are individually signed by >>> their origin. >>> >>> So I'd go with using TLS/DTLS on the transport first and then possibly >>> adapting syslog-sign when the transport issues are resolved. >> >> (1) and (2) are complimentary and one do not exclude the other >> from being necessary. > > True, (1) and (2) are independent, my point was to give priority to the > first one as it already solves a lot of problems and will help us keep > focused. Agreed as well. I appreciate this input and I'll have a proposal out as soon as I can get it. :) Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 11:48:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMfG-0005Vj-4p; Tue, 10 Jan 2006 11:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMfE-0005V9-Sw for syslog@megatron.ietf.org; Tue, 10 Jan 2006 11:48:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20253 for ; Tue, 10 Jan 2006 11:46:45 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMly-0000Jv-G5 for syslog@ietf.org; Tue, 10 Jan 2006 11:55:03 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2006 08:47:55 -0800 X-IronPort-AV: i="3.99,351,1131350400"; d="scan'208"; a="389880017:sNHT32774408" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0AGltju022118; Tue, 10 Jan 2006 08:47:55 -0800 (PST) Date: Tue, 10 Jan 2006 08:47:54 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: hartmans-ietf@mit.edu Subject: [Syslog] Threat model and charter X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi All, I'd like to address this topic in three parts: 1) The threat model and what threats we feel are important to address 2) How we should address those threats 3) Wording our charter == 1 == I'd like to review the on-the-wire threats documented in RFC 3164 and see what we want to address. >From RFC 3164 Section 6: 6.2 Message Authenticity (incl. Forgery) 6.3 Sequenced Delivery (incl. Replaying) 6.4 Reliable Delivery 6.5 Message Integrity 6.6 Message Observation 6.7 Message Prioritization and Differentiation Including a per-message signing mechanisms would address message authenticity (6.2). However, that would require key maintenance and would require a lot of touching of the end-points. That seems to be counter-productive to current implementations of syslog. I've found that many are willing to put up with unauthenticated messages rather than to have to step up their maintenance of those systems. [ TLS is not required to authenticate the client. SSH can (SHOULD) [ require that the user authenticate to the server. Utilizing SSH could [ provide a mechanism to address 6.2, but again that seems to be higher [ maintenance than what most people would like to do for syslog. Sequenced delivery (6.3) will be addressed by the eventID SD element in syslog-protocol. [ syslog-sign will additionally address this by including the engineID. [ Additionally, a REQUIRED secure transport would ensure proper [ sequencing but would not alone provide stored-message sequence [ verification. Reliable delivery (6.4), message integrity (6.5), and message observation (6.6) may be addressed through the use of a REQUIRED secure transport. [ Both SSH and TLS will provide this as long as they use sufficiently [ appropriate ciphers. Message prioritization and differentiation are not entirely protocol issues and they are addressed in RFC 3195. [ I suggest that we drop this as a threat that we will address. If we agree that message authenticity is not going to be in the critical path of the current effort in the WG, then we can conclude that our threats can be addressed by a REQUIRED secure transport. Sequenced Delivery Reliable Delivery Message Integrity Message Observation == 2 == The discussion of a secure transport has come up before. Most of the list requested that TLS be considered if we do go down that path. The reasoning was that TLS is already in wide use to transport syslog messages and implementors would really like to continue using that. SSH as a transport is acceptable but seems to require a higher level of operations support than TLS. There are also no currently known implementaitons of syslog/SSH. I'd suggest that we REQUIRE the use of TLS to address the identified threats. If future implementors feel that it will be beneficial to merge isms, netconf and syslog, then the work that they are currently doing to bind their protocols to SSH will pave the way and a future effort can document that. With that being said, however, it appears that Sam will allow some discussion of a secure transport if we can address the threats in our charter. If so, then we can abstract the secure transport for the time. I will still continue to say that syslog-sign provides mechanisms that will be beneficial to the community. It will provide device authentication, stored-message integrity, stored-message integrity, and stored-message sequence verification. These cannot be as well addressed with per-message signing. Since this will require high-touch maintenance I will suggest that it be taken out of the critical path of our charter. (We'll leave it for the end and see how many people contribute to it and indicate that they will implement it.) == 3 == Proposed charter revision below: --vvv-- Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in the INFORMATIONAL RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the at the start. Additional testing has shown that as long as the is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the at the start of the message and will introduce protocol versioning. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. The threats that this WG will primarily address are sequenced delivery (including replay attacks), reliable delivery, message integrity, and message observation. These attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. The threat that this group will not primarily address is that of message authentication. The Working Group expects that requiring key maintenence for syslog senders would hamper the acceptance of a new protocol. However, there does still remain an interest in providing message authentication and a mechanism to verify the integrity and sequence of stored messages. The Working Group feels that these aspects may be addressed by a dissociated signature upon sent messages. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that requires a secure transport for the delivery of syslog messages. - A document will be produced to describe the MIB for syslog entities. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. Milestones: Mar 2006 Submit Syslog Protocol to IESG for consideration as a PROPOSED STANDARD. Mar 2006 Submit Syslog UDP Transport Mapping to IESG for consideration as a PROPOSED STANDARD. Jul 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit a document that requires a reliable transport for syslog to the IESG as a PROPOSED STANDARD. Nov 2006 Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD. ---^^^--- == x == I've given the secure transport document a deadline of November of this year. It should be a simple document to write if we can quickly agree to the use of a transport. However, we will need to find a document author. Comments and thoughts would be appreciated. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 13:00:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNnm-0004Ju-0C; Tue, 10 Jan 2006 13:00:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNnj-0004Gw-OU for syslog@megatron.ietf.org; Tue, 10 Jan 2006 13:00:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25216 for ; Tue, 10 Jan 2006 12:59:36 -0500 (EST) Received: from stratton-three-twelve.mit.edu ([18.187.6.57] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwNuT-0002WW-9z for syslog@ietf.org; Tue, 10 Jan 2006 13:07:54 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 87843E0053; Tue, 10 Jan 2006 13:00:47 -0500 (EST) To: Chris Lonvick References: From: Sam Hartman Date: Tue, 10 Jan 2006 13:00:47 -0500 In-Reply-To: (Chris Lonvick's message of "Tue, 10 Jan 2006 08:47:54 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: syslog@ietf.org Subject: [Syslog] Re: Threat model and charter X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi. Can you explain what actions on a part of an attacker are prevented in terms of attacks on message integrity without authenticating the source of the message? In general, the security community is very suspicious of mechanisms that provide integrity without authentication. If you are going to propose such a mechanism then you need to explain why it is appropriate in your environment. In effect, in terms of integrity, it sounds like you say that it is important for a sender to know that the message has been transported to the receiver unmodified. However since the receiver does not know who is sending it the message, the receiver cannot know anything about the integrity of the message. It may be a bit more complicated than that. If the message contains confidential information that an attacker could not have generated then the receiver may actually know that the message is unmodified without knowing who generated it. However it seems like your proposal does not protect against a number of attacks. In particular, an attacker can generate messages appearing to come from any source and containing content of the attacker's choosing. This combined with the ability to suppress messages sounds like enough to get around any message integrity you might have. Also, I'd reword the charter bullet regarding the secure transport. You want a bullet claiming that you will write a document describing a secure transport. Actually requiring the secure transport be implemented happens in the protocol document. As a result, you cannot submit syslog-protocol to the IESG until this transport document is written. It might be possible for the protocol document not to discuss mandatory transports at all and for there to be a later applicability statement for syslog requiring protocol, the secure transport and UDP. RFC 2026 does allow that structure but I don't know of any WG who has actually done things that way. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 10 13:33:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOIw-0004p9-Eu; Tue, 10 Jan 2006 13:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOIu-0004nE-Ef for syslog@megatron.ietf.org; Tue, 10 Jan 2006 13:33:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27791 for ; Tue, 10 Jan 2006 13:31:48 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwOPb-0003cB-W5 for syslog@ietf.org; Tue, 10 Jan 2006 13:40:07 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 10 Jan 2006 10:32:54 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0AIWsju004468; Tue, 10 Jan 2006 10:32:54 -0800 (PST) Date: Tue, 10 Jan 2006 10:32:54 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: hartmans-ietf@mit.edu Subject: [Syslog] Re: Threat model and charter X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Working Group, I'll pass this along to those people who have already implemented syslog/TLS(SSL). Please be specific about why you did this. Thanks, Chris On Tue, 10 Jan 2006, Sam Hartman wrote: > Hi. > > Can you explain what actions on a part of an attacker are prevented in > terms of attacks on message integrity without authenticating the > source of the message? > > In general, the security community is very suspicious of mechanisms > that provide integrity without authentication. If you are going to > propose such a mechanism then you need to explain why it is > appropriate in your environment. > > In effect, in terms of integrity, it sounds like you say that it is > important for a sender to know that the message has been transported > to the receiver unmodified. However since the receiver does not know > who is sending it the message, the receiver cannot know anything about > the integrity of the message. > > It may be a bit more complicated than that. If the message contains > confidential information that an attacker could not have generated > then the receiver may actually know that the message is unmodified > without knowing who generated it. > > However it seems like your proposal does not protect against a number > of attacks. In particular, an attacker can generate messages > appearing to come from any source and containing content of the > attacker's choosing. This combined with the ability to suppress > messages sounds like enough to get around any message integrity you > might have. > > > Also, I'd reword the charter bullet regarding the secure transport. > You want a bullet claiming that you will write a document describing a > secure transport. Actually requiring the secure transport be > implemented happens in the protocol document. As a result, you cannot > submit syslog-protocol to the IESG until this transport document is > written. It might be possible for the protocol document not to > discuss mandatory transports at all and for there to be a later > applicability statement for syslog requiring protocol, the secure > transport and UDP. RFC 2026 does allow that structure but I don't > know of any WG who has actually done things that way. > > --Sam > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 04:38:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwcRM-0000Ee-D5; Wed, 11 Jan 2006 04:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwcRK-0000ET-Jd for syslog@megatron.ietf.org; Wed, 11 Jan 2006 04:38:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27676 for ; Wed, 11 Jan 2006 04:37:26 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwcXe-0004nd-He for syslog@ietf.org; Wed, 11 Jan 2006 04:45:53 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 2254027C05A; Wed, 11 Jan 2006 10:32:05 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20001-03; Wed, 11 Jan 2006 10:32:05 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id AE37B27C059; Wed, 11 Jan 2006 10:32:04 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 10:37:56 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 10:37:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYWFFx3Is6MkJyPTLqc2+30Mr9QqQAeWY2A From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 11 Jan 2006 09:37:56.0098 (UTC) FILETIME=[B39B6620:01C61692] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I can probably not comment on everything in the conversation between Chris and Sam, but I can put in some real-world experience. With syslog, we have not (yet) natively implemented TLS (this is planned, but if an I-D will surface, we'll probably wait a little bit and try to do it "the standards way"). However, we support syslog over SSL/TLS with the help of the stunnel tool. This option is quite popular. Besides that it requires a second software, you can think of it as being an syslog/TLS implementation (this is also the reason we are not really pressed in implementing it natively). It is true, TLS does not necessarily provide peer authentication. Many folks have deployed it without authentication because their primary threat is the clear text message transport. They do not want the data to be visible to an onlooker. Unauthenticated TLS works well with that. These systems are often inside the local Intranet, only. Some of them guard the syslogd via firewall rules, others allow only specific senders and again others combine these two methods. As the underlying transport is (non-standard) syslog/plain tcp, it is not trivial to spoof a sender IP address, so this level of "authentication" is usually considered to be sufficient. It is also extremly esay to implement, which explains its popularity. However, it *is* possible to authenticate the peers via X.509 certificates. Any TLS implementation can do client and server certificate verification as part of the session setup process. To the best of my knowledge, some folks use this feature with stunnel. So the server accepts messages only from clients which are authenticated via their certificate (their certificate-based names are configured at the server side). Please note that this does not authenticate a specific *user* but rather a sender machine (or process). In my point of view, this is not a disadvantage but a requirement. Syslog senders need to be capable of automatically restarting and thus some authentication information must be stored at the client (please note that for highest security, you can protect the certificate with a passphrase so that upon machine startup an operator must manually enter it - this option is IMHO impractical for syslog, but I wanted to state it). Based on this experience, I would recommend the following: #1 REQUIRE (unauthenticated) TLS to address 6.4 Reliable Delivery 6.6 Message Observation #2 RECOMMEND / allow certificate-based authentication during TLS session setup to address 6.5 Message Integrity 6.3.4 Replaying 6.2 Message Authenticity 8.8. Misconfiguration (from -protocol-16, solved partly) 8.11. Denial of Service (from -protocol-16, mitigated) [all section numbers are from RFC 3164 except otherwise noted] The important point is that I recommend NOT to mandate authentication, as the operational overhead might not be desirable for an operator (practice tells me this). On the other hand, it might make sense to mandate that a -transport-tls (let me call it so for now) compliant implementation MUST support #2, but MUST be configurable to not use it. That way, we would require that each implementation supports full security but do not force the operator to use it. However, I am not sure if such wording is within the scope of the IETF. Programatically, implementing #2 is pretty easy when #1 is done. So #2 should technically not cause any loss of implementor acceptance. I am not expert enough to tell what other subleties TLS might have in stock. I am talking on my practical experience ;) -transport-tls would need to have two parts: #1 framing (how to place -transport messages into the stream) #2 tls specific wording If it helps, I would be available to work on #1, but #2 is most probably above my head. As -transport-tls calls to a final solution to the dangling framing issue, it technically makes sense to hold final submission of -protocol until this has been solved. The framing discussion might be more productive if we are somewhat flexible in the -protocol area (namely: ending terminator, we have only a very weak consensus on this). I do not see any big problem when we hold submission of -protocol and -transport-udp unless -transport-tls is finished. Except, of course, all milestones must be moved accordingly. In any case, we should still finish work on -protocol and -transport-udp NOW and then concentrate on -transport-tls. Changes to -protocol should only be made if there is really good reasoning to do so. Given the wide deployment of SSL/TLS syslog and the low deployment of SSH (I think Kiwi uses it optionally), I'd strongly recommend taking the TLS route. Implementor acceptance will probably be much greater thanks to the well-known, well-used, well-available and quite good openssl library. I do not see what SSH would offer us that TLS can not do. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Tuesday, January 10, 2006 7:33 PM > To: syslog@ietf.org > Cc: hartmans-ietf@mit.edu > Subject: [Syslog] Re: Threat model and charter >=20 > Hi Working Group, >=20 > I'll pass this along to those people who have already implemented=20 > syslog/TLS(SSL). Please be specific about why you did this. >=20 > Thanks, > Chris >=20 > On Tue, 10 Jan 2006, Sam Hartman wrote: >=20 > > Hi. > > > > Can you explain what actions on a part of an attacker are=20 > prevented in > > terms of attacks on message integrity without authenticating the > > source of the message? > > > > In general, the security community is very suspicious of mechanisms > > that provide integrity without authentication. If you are going to > > propose such a mechanism then you need to explain why it is > > appropriate in your environment. > > > > In effect, in terms of integrity, it sounds like you say that it is > > important for a sender to know that the message has been transported > > to the receiver unmodified. However since the receiver=20 > does not know > > who is sending it the message, the receiver cannot know=20 > anything about > > the integrity of the message. > > > > It may be a bit more complicated than that. If the message contains > > confidential information that an attacker could not have generated > > then the receiver may actually know that the message is unmodified > > without knowing who generated it. > > > > However it seems like your proposal does not protect=20 > against a number > > of attacks. In particular, an attacker can generate messages > > appearing to come from any source and containing content of the > > attacker's choosing. This combined with the ability to suppress > > messages sounds like enough to get around any message integrity you > > might have. > > > > > > Also, I'd reword the charter bullet regarding the secure transport. > > You want a bullet claiming that you will write a document=20 > describing a > > secure transport. Actually requiring the secure transport be > > implemented happens in the protocol document. As a result,=20 > you cannot > > submit syslog-protocol to the IESG until this transport document is > > written. It might be possible for the protocol document not to > > discuss mandatory transports at all and for there to be a later > > applicability statement for syslog requiring protocol, the secure > > transport and UDP. RFC 2026 does allow that structure but I don't > > know of any WG who has actually done things that way. > > > > --Sam > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 05:31:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwdGi-0006wN-Rs; Wed, 11 Jan 2006 05:31:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwdGh-0006vx-Mo for syslog@megatron.ietf.org; Wed, 11 Jan 2006 05:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00405 for ; Wed, 11 Jan 2006 05:30:31 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwdN3-00064Z-S5 for syslog@ietf.org; Wed, 11 Jan 2006 05:38:58 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6980C27C05A; Wed, 11 Jan 2006 11:25:11 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20430-04; Wed, 11 Jan 2006 11:25:11 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id EC3B027C059; Wed, 11 Jan 2006 11:25:10 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 11:30:56 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Sec 6.1: Truncation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 11:30:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4210@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYS8k5MFvQCqVz3RJqX9nFzDRup+wACkoPgAH4rzAAADy9LcAAAdK/gAFl9htA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" X-OriginalArrivalTime: 11 Jan 2006 10:30:56.0379 (UTC) FILETIME=[1B33C4B0:01C6169A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton and all, I have now changed section 6.1 to: ### 6.1. Message Length Syslog message size limits are dictated by the syslog transport mapping in use. There is no upper limit per se. Each transport mapping MUST define the minimum required message length support. Any syslog transport mapping MUST support messages of up to and including 480 octets in length. Any syslog receiver MUST be able to accept messages of up to and including 480 octets in length. All receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Receivers MAY receive messages larger than 2048 octets in length. If a receiver receives a message with a length larger than it supports, the receiver MAY discard the message or truncate the payload. If a receiver truncates messages, the truncation MUST occur at the end of the message. UTF-8 encoding and STRUCTURED-DATA MUST be kept valid during truncation. SD-ELEMENTs MUST NOT partly be truncated. If an SD-ELEMENT is to be truncated, the whole SD-ELEMENT MUST be deleted. If the last SD-ELEMENT of a message is deleted, the STRUCTURED-DATA field MUST be changed to NILVALUE. ### I have explicitly stated that there is no intrinsic upper size limit. I did this, because we had so much confusion/misunderstanding on that fact in the past. I've also added some details on truncation. The rest is as suggested by Anton :) Please review and comment. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, January 09, 2006 4:49 PM > To: Anton Okmianski (aokmians) > Cc: syslog@ietf.org > Subject: RE: [Syslog] Sec 6.1: Truncation >=20 > > Rainer: > >=20 > > I agree - this is better than a convoluted rule.=20 > >=20 > > I think we only have any business in defining truncation for=20 > > relays. For collectors, we have tried to stay away from=20 > > describing how messages are stored. =20 > >=20 > > For relays, I think it would be useful to state that relay=20 > > can't just drop arbitrary message parts. Your statements=20 > > about "some parts ... are lost" may be interpreted that way.=20 >=20 > Actually, this was what I meant ;) [I saw a number of use=20 > cases where it > would make sense to strip some known-not-so-relavant SD-IDs to be > strippedd], but ... > >=20 > > I would recommend that we state that any truncation must=20 > > happen at the end of the message, which I think is what=20 > > truncation means to a lot of people anyway. This would=20 > > prevent an implementation which prefers to throw out=20 > > STRUCTURED-DATA before the MSG content. A consistent=20 > > behavior is useful for interop and, in particular, may help=20 > > in dealing with security issues. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ... this is more important. I now agree with your point. >=20 > As a side-note, we had the idea that relay operations may become a > separate document, so I would prefer not to dig too deep into relay > behaviour. To specify what you recommend, this is not=20 > necessary, so this > is not really a discussion topic here. >=20 > Rainer=20 > >=20 > > Thanks, > > Anton.=20 > >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > > Sent: Monday, January 09, 2006 3:21 AM > > > To: Anton Okmianski (aokmians) > > > Subject: RE: [Syslog] Sec 6.1: Truncation > > >=20 > > > Anton, Darren, > > >=20 > > > I agree that the truncation rule is probably not really=20 > > > useful, even confusing. I think it is hard to predict for any=20 > > > potential message if the more interesting content is in=20 > > > STRUCTURED-DATA or in the MSG part. > > > For example, with our current SD-IDs, I'd prefer to trunctate=20 > > > them instead of MSG. Obviously, the case is different for=20 > > > your LINKDOWN sample. I also agree with Darren that=20 > > > truncation probably happens on the transport layer, the=20 > > > application may not even see the full message. > > >=20 > > > My conclusion, however, is slightly different: I recommend=20 > > > now that we remove truncation rules from -protocol. We should=20 > > > just say that truncation might happen and that in this case=20 > > > some parts of the message are lost - what is at the=20 > > > discretion of the receiver. > > >=20 > > > Rainer > > >=20 > > > > -----Original Message----- > > > > From: syslog-bounces@lists.ietf.org > > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton=20 > > Okmianski=20 > > > > (aokmians) > > > > Sent: Friday, January 06, 2006 9:48 PM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] Sec 6.1: Truncation > > > >=20 > > > > Rainer and all: > > > >=20 > > > > I started reading draft #16. Since we are revisiting=20 > > > everything... I=20 > > > > am not very comfortable with the current truncation rules. > > > >=20 > > > > "Receivers SHOULD follow this order of preference when it=20 > > comes to=20 > > > > truncation: > > > >=20 > > > > 1) No truncation > > > > 2) Truncation by dropping SD-ELEMENTs > > > > 3) If 2) not sufficient, truncate MSG" > > > >=20 > > > > I don't think that this is a good recommendation. I would=20 > > > assume that=20 > > > > in many cases people would try to tokenize more important=20 > > data into=20 > > > > structured data and use message text as a secondary=20 > user-friendly=20 > > > > description. For example, for LINK_DOWN message, I=20 > would probably=20 > > > > encode link ID in the structured elements as this is=20 > > something that=20 > > > > should be readily available for receivers. The MSGID could be=20 > > > > "LINK_DOWN" and the MSG text may simply be "Link down". If you=20 > > > > truncate the structured data, it makes it harder. > > > >=20 > > > > I also think, in general it is useful to put more=20 > important data=20 > > > > first, which is another reason for putting more valuable=20 > > data into=20 > > > > structured data in a more compact way. > > > >=20 > > > > Additionally, structured data can be used to provide=20 > > > message length or=20 > > > > digest, which can help receiver to determine if message was=20 > > > truncated. > > > >=20 > > > > Also, I think this statement is very convoluted: > > > >=20 > > > > "Please note that it is possible that the MSG field is=20 > truncated=20 > > > > without dropping any SD-PARAMS. This is the case if a=20 > > > message with an=20 > > > > empty STRUCTURED-DATA field must be truncated." > > > >=20 > > > > I think I understand what you are driving at, but I don't=20 > > see it as=20 > > > > adding any requirements or clarification. > > > >=20 > > > > This sentence is not clear although I know what you are=20 > > > trying to say: > > > >=20 > > > > "The limits below are minimum maximum lengths, not=20 > > maximum length." > > > >=20 > > > > I propose replacing the entire section 6.1 with this text: > > > >=20 > > > > "Syslog message limits are dictated by the syslog transport=20 > > > mapping in=20 > > > > use. Each transport mapping MUST define the minimum=20 > > > required message=20 > > > > length support. Any syslog transport mapping MUST support=20 > > > messages of=20 > > > > up to and including 480 octets in length. > > > >=20 > > > > Any syslog receiver MUST be able to accept messages of=20 > up to and=20 > > > > including 480 octets in length. All receiver=20 > > > implementations SHOULD=20 > > > > be able to accept messages of up to and including 2048=20 > octets in=20 > > > > length. Receivers MAY receive messages larger than 2048=20 > octets in=20 > > > > length. If a receiver receives a message with a length=20 > > > larger than it=20 > > > > supports, the receiver MAY discard the message or truncate the=20 > > > > payload. > > > >=20 > > > > If truncation is performed by the receiver, it MUST first=20 > > > truncate the=20 > > > > MSG field as necessary to meet the supported length limit. If=20 > > > > truncation of the entire MSG field is not sufficient, then=20 > > > > additionally, the STRUCTURED-DATA field MUST be truncated=20 > > > by removing=20 > > > > one or more SD-ELEMENT fields. A minimum number of=20 > > > SD-ELEMENT fields=20 > > > > MUST be truncated starting from the end as necessary to=20 > meet the=20 > > > > supported length limit. SD-ELEMENT field can't be truncated=20 > > > partially. > > > > If all SD-ELEMENT fields are removed, NILVALUE MUST be=20 > > > specified for=20 > > > > STRUCTURED-DATA field. Truncation of HEADER > > > > field MUST NOT be performed." =20 > > > >=20 > > > > BTW, in your text or mine, what happens if message is=20 > > malformed? A=20 > > > > proxy won't be able to truncate it properly then. We=20 > > don't want to=20 > > > > prevent it from truncating it in some way and sending=20 > the message=20 > > > > further, I would think. At least you will see something at=20 > > > the final=20 > > > > destination, which maybe more useful than nothing. If we=20 > > just made=20 > > > > truncation a simple take the first X octets out of Y=20 > > > octets, it would=20 > > > > not be an issue, but then proxy would be allowed to turn a=20 > > > well-formed > > > > message into malformed message upon truncation. =20 > > > >=20 > > > > What do you think? > > > >=20 > > > > Thanks, > > > > Anton.=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 06:39:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweKG-0001An-Sw; Wed, 11 Jan 2006 06:39:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweKF-0001Ae-TT for syslog@megatron.ietf.org; Wed, 11 Jan 2006 06:39:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04269 for ; Wed, 11 Jan 2006 06:38:14 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EweR6-0007pG-RX for syslog@ietf.org; Wed, 11 Jan 2006 06:46:42 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k0BBcfOv028610; Wed, 11 Jan 2006 22:38:41 +1100 (EST) From: Darren Reed Message-Id: <200601111138.k0BBcGqY004890@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Sec 6.1: Truncation In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E4210@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 11 Jan 2006 22:38:16 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Anton and all, > > I have now changed section 6.1 to: > > ### > 6.1. Message Length > .. Well written and very sensible. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 07:04:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweiH-0008Io-6F; Wed, 11 Jan 2006 07:04:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EweiF-0008Ig-V5 for syslog@megatron.ietf.org; Wed, 11 Jan 2006 07:04:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06019 for ; Wed, 11 Jan 2006 07:03:03 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewep8-00009K-G8 for syslog@ietf.org; Wed, 11 Jan 2006 07:11:32 -0500 Subject: RE: [Syslog] Re: Threat model and charter From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Wed, 11 Jan 2006 13:04:04 +0100 Message-Id: <1136981044.5320.17.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: > Chris, > > However, it *is* possible to authenticate the peers via X.509 > certificates. Any TLS implementation can do client and server > certificate verification as part of the session setup process. To the > best of my knowledge, some folks use this feature with stunnel. So the > server accepts messages only from clients which are authenticated via > their certificate (their certificate-based names are configured at the > server side). I basically agree with you, one minor addition that this X.509 certificate based authentication is a hop-by-hop authentication and provided the operator trusts all devices on the message path and requires authentication on each hop, then message authenticity can be ensured. There's no per-message signature, thus it is not proovable that a message was generated by a given device after it has been received and stored. A parallel example: It is in a sense similar to client authentication in HTTPS: if you upload a file using HTTPS where client certificate was required and validated, then the file on the server can be trusted to a certain extent (as much as the HTTPS server can be trusted), however there's no means to prove that the file has not been tampered with after it has been received. There was no signature _stored_ along the file and no such signature exists in the HTTPS protocol itself, to do this the HTTPS client would need to generate a signature before transmission and upload the signature along with the file itself. Back to syslog: TLS and X.509 certificate authentication is hop-by-hop and authenticates the infrastructure and network transmission (like HTTPS itself), syslog-sign is a per-message authentication similar to the client-side-sign-and-upload-along-with-file example in HTTPS as described above. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 07:05:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwejH-0008Sl-TM; Wed, 11 Jan 2006 07:05:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwejG-0008ST-PX for syslog@megatron.ietf.org; Wed, 11 Jan 2006 07:05:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06085 for ; Wed, 11 Jan 2006 07:04:06 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EweqA-0000C2-Rr for syslog@ietf.org; Wed, 11 Jan 2006 07:12:35 -0500 Subject: Re: [Syslog] Sec 6.1: Truncation From: Balazs Scheidler To: Darren Reed In-Reply-To: <200601111138.k0BBcGqY004890@firewall.reed.wattle.id.au> References: <200601111138.k0BBcGqY004890@firewall.reed.wattle.id.au> Content-Type: text/plain Date: Wed, 11 Jan 2006 13:05:25 +0100 Message-Id: <1136981125.5320.19.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-11 at 22:38 +1100, Darren Reed wrote: > > Anton and all, > > > > I have now changed section 6.1 to: > > > > ### > > 6.1. Message Length > > > .. > > Well written and very sensible. I like it too :) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 08:07:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfhA-0002fk-Jx; Wed, 11 Jan 2006 08:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewfh8-0002eq-3l for syslog@megatron.ietf.org; Wed, 11 Jan 2006 08:07:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10432 for ; Wed, 11 Jan 2006 08:05:57 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwfnU-00029a-Jy for syslog@ietf.org; Wed, 11 Jan 2006 08:14:27 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B84A927C05A; Wed, 11 Jan 2006 14:00:40 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21640-07; Wed, 11 Jan 2006 14:00:40 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6A5D727C059; Wed, 11 Jan 2006 14:00:40 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 14:06:32 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 14:06:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4214@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYWpyIENOIwwS2vRwq4gXJ+X+dcmQACAlFA From: "Rainer Gerhards" To: "Balazs Scheidler" , X-OriginalArrivalTime: 11 Jan 2006 13:06:32.0821 (UTC) FILETIME=[D827C250:01C616AF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Bazsi, I agree with you, thanks for the great clarification. I think this is also an excellent explanation why syslog-sign is necessary - and that a secure transport and -sign have some different applications. When it comes to priorities, I am still in favour of mandating a TLS transport. The good in that is that you can actually guarantee authenticy, even in a relay chain, as long as you (can) trust all relays. In a typical corporate environment, I think this can be ensured. -sign, on the other hand, does not solve the "message observation" issue, which to the best of my knowledge is the driving force behind most of todays syslog/ssl implementations. The security considerations section for -transport-tls should list the hop-by-hop restriction and provide information on mitigating it. Rainer > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Wednesday, January 11, 2006 1:04 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] Re: Threat model and charter >=20 > On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: > > Chris, > >=20 > > However, it *is* possible to authenticate the peers via X.509 > > certificates. Any TLS implementation can do client and server > > certificate verification as part of the session setup=20 > process. To the > > best of my knowledge, some folks use this feature with=20 > stunnel. So the > > server accepts messages only from clients which are=20 > authenticated via > > their certificate (their certificate-based names are=20 > configured at the > > server side). >=20 > I basically agree with you, one minor addition that this X.509 > certificate based authentication is a hop-by-hop authentication and > provided the operator trusts all devices on the message path and > requires authentication on each hop, then message authenticity can be > ensured. There's no per-message signature, thus it is not=20 > proovable that > a message was generated by a given device after it has been=20 > received and > stored.=20 >=20 > A parallel example: It is in a sense similar to client=20 > authentication in > HTTPS: if you upload a file using HTTPS where client certificate was > required and validated, then the file on the server can be=20 > trusted to a > certain extent (as much as the HTTPS server can be trusted), however > there's no means to prove that the file has not been tampered=20 > with after > it has been received. There was no signature _stored_ along=20 > the file and > no such signature exists in the HTTPS protocol itself, to do this the > HTTPS client would need to generate a signature before=20 > transmission and > upload the signature along with the file itself. >=20 > Back to syslog: TLS and X.509 certificate authentication is hop-by-hop > and authenticates the infrastructure and network transmission (like > HTTPS itself), syslog-sign is a per-message authentication similar to > the client-side-sign-and-upload-along-with-file example in HTTPS as > described above. >=20 > --=20 > Bazsi >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 09:19:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewgoi-00084E-6W; Wed, 11 Jan 2006 09:19:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewgog-000846-LX for syslog@megatron.ietf.org; Wed, 11 Jan 2006 09:19:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15542 for ; Wed, 11 Jan 2006 09:17:49 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewgvb-0004Iy-QX for syslog@ietf.org; Wed, 11 Jan 2006 09:26:20 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2006 06:19:02 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0BEJ0ju010902; Wed, 11 Jan 2006 06:19:00 -0800 (PST) Date: Wed, 11 Jan 2006 06:19:00 -0800 (PST) From: Chris Lonvick To: Balazs Scheidler Subject: RE: [Syslog] Re: Threat model and charter In-Reply-To: <1136981044.5320.17.camel@bzorp.balabit> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> <1136981044.5320.17.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I was thinking that if we have to do authentication then we could try to get consensus on a simple authentication mechanism - a shared secret. Essentially, each sender would have to be configured with a shared secret before it could use TLS. The receivers and relays would also have that information. When a sender prepares a message, it would hash the shared secret with the formed message. That hash could be placed in an SD element ( [tlsAuthChk="12345678..."] ). The recipient could extract the value, and then re-run the hash. If the received hash is the same as the calculated hash then both the sender and the receiver must be using the same shared secret. The caveat to this is in choosing the right hash algorithm. This mechanism and shared secret authentication has been well defined in many prior RFCs. A lot of those RFCs used MD5 which is now going out of favor. Check out RFC 1305 (NTP - appendix D) and RFC 2385 (authentication for BGP). This suggestion tries to keep the ease-of-use of syslog. Using credentials stored in an X.505 certificate (of the recipient) would provide a higher degree of authentication - shared secrets can be much more easily compromised (found, guessed, brute-forced, etc.) than the validated credentials contained in a certificate. If we can get consensus that an in-packet authentication mechanism like this is sufficient to meet our threat model, then we can decide if the shared secret is sufficient (the REQUIRED mechanism), and/or if we want to RECOMMEND a similar X.509 mechanism. That would require having each syslog sender to have an X.509 certificate, and have those signed and available. That just seems to me to be getting a bit far away from the ease-of-use that makes syslog so easy to deploy. Thoughts? Thanks, Chris On Wed, 11 Jan 2006, Balazs Scheidler wrote: > On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: >> Chris, >> >> However, it *is* possible to authenticate the peers via X.509 >> certificates. Any TLS implementation can do client and server >> certificate verification as part of the session setup process. To the >> best of my knowledge, some folks use this feature with stunnel. So the >> server accepts messages only from clients which are authenticated via >> their certificate (their certificate-based names are configured at the >> server side). > > I basically agree with you, one minor addition that this X.509 > certificate based authentication is a hop-by-hop authentication and > provided the operator trusts all devices on the message path and > requires authentication on each hop, then message authenticity can be > ensured. There's no per-message signature, thus it is not proovable that > a message was generated by a given device after it has been received and > stored. > > A parallel example: It is in a sense similar to client authentication in > HTTPS: if you upload a file using HTTPS where client certificate was > required and validated, then the file on the server can be trusted to a > certain extent (as much as the HTTPS server can be trusted), however > there's no means to prove that the file has not been tampered with after > it has been received. There was no signature _stored_ along the file and > no such signature exists in the HTTPS protocol itself, to do this the > HTTPS client would need to generate a signature before transmission and > upload the signature along with the file itself. > > Back to syslog: TLS and X.509 certificate authentication is hop-by-hop > and authenticates the infrastructure and network transmission (like > HTTPS itself), syslog-sign is a per-message authentication similar to > the client-side-sign-and-upload-along-with-file example in HTTPS as > described above. > > -- > Bazsi > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 09:28:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwgxX-00026z-CG; Wed, 11 Jan 2006 09:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwgxW-00026u-2T for syslog@megatron.ietf.org; Wed, 11 Jan 2006 09:28:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16265 for ; Wed, 11 Jan 2006 09:26:57 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewh4P-0004c9-07 for syslog@ietf.org; Wed, 11 Jan 2006 09:35:27 -0500 Subject: RE: [Syslog] Re: Threat model and charter From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> <1136981044.5320.17.camel@bzorp.balabit> Content-Type: text/plain Date: Wed, 11 Jan 2006 15:28:02 +0100 Message-Id: <1136989682.5320.52.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-11 at 06:19 -0800, Chris Lonvick wrote: > Hi, > If we can get consensus that an in-packet authentication mechanism like > this is sufficient to meet our threat model, then we can decide if the > shared secret is sufficient (the REQUIRED mechanism), and/or if we want to > RECOMMEND a similar X.509 mechanism. That would require having each > syslog sender to have an X.509 certificate, and have those signed and > available. That just seems to me to be getting a bit far away from the > ease-of-use that makes syslog so easy to deploy. I don't like this approach as this check does not prove authenticity as each device in the chain can regenerate the same checksum. So I fail to see how this adds to security compared to using hop-by-hop TLS with x.509 certificate checking as it requires the same trust in the involved devices. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 09:29:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewgyz-0003NL-Ur; Wed, 11 Jan 2006 09:29:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewgyy-0003NG-8M for syslog@megatron.ietf.org; Wed, 11 Jan 2006 09:29:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16374 for ; Wed, 11 Jan 2006 09:28:27 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewh5s-0004fV-Kb for syslog@ietf.org; Wed, 11 Jan 2006 09:36:57 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2006 06:29:39 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0BETbju019359; Wed, 11 Jan 2006 06:29:37 -0800 (PST) Date: Wed, 11 Jan 2006 06:29:37 -0800 (PST) From: Chris Lonvick To: Balazs Scheidler Subject: SSH - RE: [Syslog] Re: Threat model and charter In-Reply-To: <1136981044.5320.17.camel@bzorp.balabit> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> <1136981044.5320.17.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I forgot to address the use of SSH for authentication. The isms WG is trying to use SSH to provide security for SNMPv3. This can be done by having the devices authenticate by having a username and credential (password, public key, etc.). Again, this sounds to me like it's getting further away from the ease of deployment for syslog than we'd like. However, Rainer mentioned that he thought some people were already using SSH to transport syslog. I need to ask: How many people have implementations that use SSH, and how many are planning this? Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 09:40:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewh97-0006GX-Tx; Wed, 11 Jan 2006 09:40:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewh97-0006Fn-2m for syslog@megatron.ietf.org; Wed, 11 Jan 2006 09:40:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17033 for ; Wed, 11 Jan 2006 09:38:55 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwhG0-0004yk-5P for syslog@ietf.org; Wed, 11 Jan 2006 09:47:26 -0500 Subject: Re: SSH - RE: [Syslog] Re: Threat model and charter From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> <1136981044.5320.17.camel@bzorp.balabit> Content-Type: text/plain Date: Wed, 11 Jan 2006 15:40:06 +0100 Message-Id: <1136990407.5320.63.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-11 at 06:29 -0800, Chris Lonvick wrote: > Hi, > > I forgot to address the use of SSH for authentication. The isms WG is > trying to use SSH to provide security for SNMPv3. This can be done by > having the devices authenticate by having a username and credential > (password, public key, etc.). Again, this sounds to me like it's getting > further away from the ease of deployment for syslog than we'd like. > However, Rainer mentioned that he thought some people were already using > SSH to transport syslog. I need to ask: How many people have > implementations that use SSH, and how many are planning this? I for one (syslog-ng) don't plan to add native support to SSH, although SSH can be integrated into syslog-ng by using the program destination, something like this: program("ssh -i /etc/syslog-ng/ssh.key syslog@remote.host /usr/bin/logger -f"); However I don't see this as a very good solution. On the other hand I'm planning on adding TLS natively (instead of using stunnel style hacks). -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 09:51:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhKG-0001bJ-2k; Wed, 11 Jan 2006 09:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhKE-0001Yj-Ce for syslog@megatron.ietf.org; Wed, 11 Jan 2006 09:51:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17645 for ; Wed, 11 Jan 2006 09:50:24 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwhQd-0005ER-CK for syslog@ietf.org; Wed, 11 Jan 2006 09:58:55 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 0D07927C05A; Wed, 11 Jan 2006 15:45:11 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23178-03; Wed, 11 Jan 2006 15:45:10 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id BCC0B27C059; Wed, 11 Jan 2006 15:45:10 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 15:51:03 +0100 Content-class: urn:content-classes:message Subject: RE: SSH - RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 15:51:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4219@grfint2.intern.adiscon.com> Thread-Topic: SSH - RE: [Syslog] Re: Threat model and charter Thread-Index: AcYWvPFXC2rJ6Ax7Tzmzza+6d31tDQAATwXg From: "Rainer Gerhards" To: "Balazs Scheidler" , "Chris Lonvick" X-OriginalArrivalTime: 11 Jan 2006 14:51:03.0336 (UTC) FILETIME=[71AC6A80:01C616BE] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Just for the records, we (Adiscon - WinSyslog, MonitorWare, rsyslog) do not plan to support SSH either. We plan native TLS first in rsyslog and later in the Windows product. I guess we'll try to make it compatible to syslog-ng no matter if this will be an IETF or industry standard. I expect this to be fairly easy (AFIK our products interoperate via the stunnel hack over SSL). Rainer > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Wednesday, January 11, 2006 3:40 PM > To: Chris Lonvick > Cc: Rainer Gerhards; syslog@ietf.org > Subject: Re: SSH - RE: [Syslog] Re: Threat model and charter >=20 > On Wed, 2006-01-11 at 06:29 -0800, Chris Lonvick wrote: > > Hi, > >=20 > > I forgot to address the use of SSH for authentication. The=20 > isms WG is=20 > > trying to use SSH to provide security for SNMPv3. This can=20 > be done by=20 > > having the devices authenticate by having a username and credential=20 > > (password, public key, etc.). Again, this sounds to me=20 > like it's getting=20 > > further away from the ease of deployment for syslog than we'd like.=20 > > However, Rainer mentioned that he thought some people were=20 > already using=20 > > SSH to transport syslog. I need to ask: How many people have=20 > > implementations that use SSH, and how many are planning this? >=20 > I for one (syslog-ng) don't plan to add native support to=20 > SSH, although > SSH can be integrated into syslog-ng by using the program destination, > something like this: >=20 > program("ssh -i /etc/syslog-ng/ssh.key syslog@remote.host=20 > /usr/bin/logger -f"); >=20 > However I don't see this as a very good solution. On the=20 > other hand I'm=20 > planning on adding TLS natively (instead of using stunnel=20 > style hacks). >=20 > --=20 > Bazsi >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 10:00:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhSY-00042c-6M; Wed, 11 Jan 2006 10:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhSX-00042X-1R for syslog@megatron.ietf.org; Wed, 11 Jan 2006 10:00:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18154 for ; Wed, 11 Jan 2006 09:58:59 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwhZR-0005Tc-MF for syslog@ietf.org; Wed, 11 Jan 2006 10:07:30 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id DB0DEE0053; Wed, 11 Jan 2006 10:00:12 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] Re: Threat model and charter References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> From: Sam Hartman Date: Wed, 11 Jan 2006 10:00:12 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Wed, 11 Jan 2006 10:37:54 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I'm concerned that your analysis seems to be based on what is easy to implement. We also need to do the analysis of what security is actually required by syslog deployments. If the ansers are different, we'll have to deal with that. But e are in a different situation if we decide to do something because we don't know how to do better than if we meet what we believe the security requirements are. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 10:16:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhiG-00012k-Qk; Wed, 11 Jan 2006 10:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhiE-00012K-47 for syslog@megatron.ietf.org; Wed, 11 Jan 2006 10:16:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19400 for ; Wed, 11 Jan 2006 10:15:12 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewhod-0005zT-Gh for syslog@ietf.org; Wed, 11 Jan 2006 10:23:43 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6526A27C05A; Wed, 11 Jan 2006 16:09:58 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23495-05; Wed, 11 Jan 2006 16:09:58 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2582E27C059; Wed, 11 Jan 2006 16:09:58 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 16:15:38 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 16:15:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E421A@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYWv8NGJsFJdMa+RWCl3WqWZvkVvwAACCyg From: "Rainer Gerhards" To: "Sam Hartman" X-OriginalArrivalTime: 11 Jan 2006 15:15:38.0617 (UTC) FILETIME=[E1026E90:01C616C1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > I'm concerned that your analysis seems to be based on what is easy to > implement. Well, I have to admit that in the world of syslog people vote with their feet. If it is not easy to implement (better said: deploy), the majority will not deploy it. Maybe I have a false impression, but I think I am not totally wrong. Security is only as secure as people actually use it. Just think about the nice yellow "post it" notes below the keyboards where all these strong passwords that nobody can remember are being kept. Is it really a good thing to have a multitude of strong passwords that leads to people resort to easily accessible, totally insecure paper notes? Wouldn't it be better to have fewer and not so totally strong passwords, but ones that are actually used as designed? I know there can be a lot said in this regard - I do not want to go into the specifics here. My point is that security is only as good as it is being accepted by the typical user. Stronger security might actually turn out to be weaker when you look at how it is actually *used*. > We also need to do the analysis of what security is actually required > by syslog deployments. > If the ansers are different, we'll have to deal with that. I thought we are doing this by refering to the sections in RFC 3164 and syslog-protocol-16. Do you think we need to elaborate more on the potential threats? If so, we definitely would need to reconsider that part of the work (also in -protocol, because it should mention at least all transport-independant threats). >=20 > But e are in a different situation if we decide to do something > because we don't know how to do better than if we meet what we believe > the security requirements are. I think with TLS and certificates we can address the security threads I mentioned. Making the use of certificates optional for operators is in the spirit of what I said above. I don't see any unnecessary evil in that. After all, even seat belts are somewhat optional. So far, cars don't force their drivers to wear them (all attempts to actually force the driver have been circumvented by the user). Please advise. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 10:51:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiGL-0003Vs-2t; Wed, 11 Jan 2006 10:51:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiGK-0003Vn-61 for syslog@megatron.ietf.org; Wed, 11 Jan 2006 10:51:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21560 for ; Wed, 11 Jan 2006 10:50:28 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwiNF-0006z9-PN for syslog@ietf.org; Wed, 11 Jan 2006 10:58:58 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 48020E0053; Wed, 11 Jan 2006 10:51:39 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] Re: Threat model and charter References: <577465F99B41C842AAFBE9ED71E70ABA0E421A@grfint2.intern.adiscon.com> From: Sam Hartman Date: Wed, 11 Jan 2006 10:51:39 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E421A@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Wed, 11 Jan 2006 16:15:46 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Rainer" == Rainer Gerhards writes: >> I'm concerned that your analysis seems to be based on what is >> easy to implement. Rainer> Well, I have to admit that in the world of syslog people Rainer> vote with their feet. If it is not easy to implement Rainer> (better said: deploy), the majority will not deploy Rainer> it. Maybe I have a false impression, but I think I am not Rainer> totally wrong. I completely agree with you here. It is however important for us to understand the gap between what we can implement and what we believe people need. If that gap exists, we'll need to consider what to do about it. "Document it," may well be what we decide. >> We also need to do the analysis of what security is actually >> required by syslog deployments. If the ansers are different, >> we'll have to deal with that. Rainer> I thought we are doing this by refering to the sections in Rainer> RFC 3164 and syslog-protocol-16. Do you think we need to Rainer> elaborate more on the potential threats? If so, we Rainer> definitely would need to reconsider that part of the work Rainer> (also in -protocol, because it should mention at least all Rainer> transport-independant threats). no, that documents all the threats. It doesn't actually make a call as to wether a particular threat is important to solve. As an example, if integrity is not important to the way people use syslog, we might not consider it important to provide integrity. On the other hand if integrity is important to how syslog is used but we cannot find a way to deliver integrity in a manner that is useful to people, we have to carefully consider what to do. >> But e are in a different situation if we decide to do >> something because we don't know how to do better than if we >> meet what we believe the security requirements are. Rainer> I think with TLS and certificates we can address the Rainer> security threads I mentioned. Making the use of Rainer> certificates optional for operators is in the spirit of Rainer> what I said above. I don't see any unnecessary evil in Rainer> that. After all, even seat belts are somewhat optional. So Rainer> far, cars don't force their drivers to wear them (all Rainer> attempts to actually force the driver have been Rainer> circumvented by the user). Security is completely optional. We understand that many people will deploy syslog-udp without security. That's fine. The IESG has charged us with delivering a solution that has a mandatory to implement mode meeting the following two criteria: 1) Meets the security requirements implied by how people use syslog. 2) Is sufficiently easy to use that it does not in practice provide weaker security than some other option. For example, TLS with mandatory certificate authentication on both sides is more secure than anonymous TLS. However it's sufficiently hard to use that many people will choose insecure UDP over certificates and TLS. Some of those same people would have chosen anonymous TLS over secure UDP. So, you and Chris have made an argument that we cannot provide integrity without decreasing the utility of our security solution. we now need to answer the question of whether integrity should be a security requirement. If it should, then we need to go back to the IESG and say we can't do what they want in an ideal world. This is all part of the standard closed loop between requirements analysis and design. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 11:01:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiPu-0006Ey-JK; Wed, 11 Jan 2006 11:01:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiPr-0006En-JZ for syslog@megatron.ietf.org; Wed, 11 Jan 2006 11:01:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22121 for ; Wed, 11 Jan 2006 11:00:20 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwiWH-0007Ek-2S for syslog@ietf.org; Wed, 11 Jan 2006 11:08:49 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3ACDF27C05A; Wed, 11 Jan 2006 16:55:04 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24083-05; Wed, 11 Jan 2006 16:55:04 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id A576427C059; Wed, 11 Jan 2006 16:55:03 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 17:00:56 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 17:01:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E421B@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYWugEVvnJqBo5WTu+x28yBH2uEbgABSfOw From: "Rainer Gerhards" To: "Chris Lonvick" , "Balazs Scheidler" X-OriginalArrivalTime: 11 Jan 2006 16:00:56.0908 (UTC) FILETIME=[353CB8C0:01C616C8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I think a shared secret is not actually much less management overhead then certificates. You need to distribute the shared secret anyway, much the same as you distribute the certificates.=20 >From the implementor's standpoint, I assume most implementors will use openssl or a similar library. These libraries all support certificate processing. In fact, it should be done as part of the session setup process. So, in short, the implementor will already have almost everything implemented that is necessary. The only thing missing are some configuration file entries (or whereever the config is kept) that allow the operator to specify which sending systems to accept (something necessary for shared secrets, too). I tend to assume that shared secrets are a bigger effort to implement than certificate based authentication. >From the security perspective, there is the hop-by-hop problem Bazsi mentioned. With TLS, you can only secure/authenticate from hop to hop, leaving a gap. With TLS, you also do not get anything that you can persist to the log file (at least not easily). The hash you propose offers this. However, isn't that hash not just a signature? If so (and I think so), we are back at syslog-protocol. I do not fully agree with Baszi that it does not offer additional benefits. Relays do not necessarily need to rewrite the signature, so it can provide a genuine "stamp" of the orginal sender. It even can be persisted to a log file and such. I think we should address this need in the context of syslog-sign, which already put a lot of effort into it.=20 In my point of view, the ideal solution is transmitting signed messages via certificate-authenticated TLS. I haven't look at -sign lately, but I think the signature could be based on the same cert that is used for TLS authentication. A receiver could even be configured to check that the signature matches the sender (obviously not an option when relaying, but in other cases it might be useful). So we could use the same technology for multiple purposes - plus the technology is close to what is already being deploed (signing shouldn't be too hard for an implementor if openssl is already used for TLS...). Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Wednesday, January 11, 2006 3:19 PM > To: Balazs Scheidler > Cc: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Re: Threat model and charter >=20 > Hi, >=20 > I was thinking that if we have to do authentication then we=20 > could try to=20 > get consensus on a simple authentication mechanism - a shared secret.=20 > Essentially, each sender would have to be configured with a=20 > shared secret=20 > before it could use TLS. The receivers and relays would also=20 > have that=20 > information. When a sender prepares a message, it would hash=20 > the shared=20 > secret with the formed message. That hash could be placed in an SD=20 > element ( [tlsAuthChk=3D"12345678..."] ). The recipient could=20 > extract the=20 > value, and then re-run the hash. If the received hash is the=20 > same as the=20 > calculated hash then both the sender and the receiver must be=20 > using the=20 > same shared secret. The caveat to this is in choosing the right hash=20 > algorithm. This mechanism and shared secret authentication=20 > has been well=20 > defined in many prior RFCs. A lot of those RFCs used MD5=20 > which is now=20 > going out of favor. Check out RFC 1305 (NTP - appendix D)=20 > and RFC 2385=20 > (authentication for BGP). >=20 > This suggestion tries to keep the ease-of-use of syslog. Using=20 > credentials stored in an X.505 certificate (of the recipient) would=20 > provide a higher degree of authentication - shared secrets=20 > can be much=20 > more easily compromised (found, guessed, brute-forced, etc.) than the=20 > validated credentials contained in a certificate. >=20 > If we can get consensus that an in-packet authentication=20 > mechanism like=20 > this is sufficient to meet our threat model, then we can=20 > decide if the=20 > shared secret is sufficient (the REQUIRED mechanism), and/or=20 > if we want to=20 > RECOMMEND a similar X.509 mechanism. That would require having each=20 > syslog sender to have an X.509 certificate, and have those signed and=20 > available. That just seems to me to be getting a bit far=20 > away from the=20 > ease-of-use that makes syslog so easy to deploy. >=20 > Thoughts? >=20 > Thanks, > Chris >=20 > On Wed, 11 Jan 2006, Balazs Scheidler wrote: >=20 > > On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: > >> Chris, > >> > >> However, it *is* possible to authenticate the peers via X.509 > >> certificates. Any TLS implementation can do client and server > >> certificate verification as part of the session setup=20 > process. To the > >> best of my knowledge, some folks use this feature with=20 > stunnel. So the > >> server accepts messages only from clients which are=20 > authenticated via > >> their certificate (their certificate-based names are=20 > configured at the > >> server side). > > > > I basically agree with you, one minor addition that this X.509 > > certificate based authentication is a hop-by-hop authentication and > > provided the operator trusts all devices on the message path and > > requires authentication on each hop, then message=20 > authenticity can be > > ensured. There's no per-message signature, thus it is not=20 > proovable that > > a message was generated by a given device after it has been=20 > received and > > stored. > > > > A parallel example: It is in a sense similar to client=20 > authentication in > > HTTPS: if you upload a file using HTTPS where client certificate was > > required and validated, then the file on the server can be=20 > trusted to a > > certain extent (as much as the HTTPS server can be trusted), however > > there's no means to prove that the file has not been=20 > tampered with after > > it has been received. There was no signature _stored_ along=20 > the file and > > no such signature exists in the HTTPS protocol itself, to=20 > do this the > > HTTPS client would need to generate a signature before=20 > transmission and > > upload the signature along with the file itself. > > > > Back to syslog: TLS and X.509 certificate authentication is=20 > hop-by-hop > > and authenticates the infrastructure and network transmission (like > > HTTPS itself), syslog-sign is a per-message authentication=20 > similar to > > the client-side-sign-and-upload-along-with-file example in HTTPS as > > described above. > > > > --=20 > > Bazsi > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 11:15:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewict-00006x-S9; Wed, 11 Jan 2006 11:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewics-00006j-FU for syslog@megatron.ietf.org; Wed, 11 Jan 2006 11:15:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23226 for ; Wed, 11 Jan 2006 11:13:46 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwijH-0007ft-G1 for syslog@ietf.org; Wed, 11 Jan 2006 11:22:16 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1B99A27C05A; Wed, 11 Jan 2006 17:08:30 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23967-10; Wed, 11 Jan 2006 17:08:30 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B5E1127C059; Wed, 11 Jan 2006 17:08:29 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 17:14:20 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 17:14:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E421C@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYWxvEEysOgs3L4TL2BgBacdMPiAwAAZQjQ From: "Rainer Gerhards" To: "Sam Hartman" X-OriginalArrivalTime: 11 Jan 2006 16:14:20.0549 (UTC) FILETIME=[143E9B50:01C616CA] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam, thanks for your reply, I think I am getting closer (and many thanks for bearing with me)...=20 >=20 > >> We also need to do the analysis of what security is actually > >> required by syslog deployments. If the ansers are different, > >> we'll have to deal with that. >=20 > Rainer> I thought we are doing this by refering to the sections in > Rainer> RFC 3164 and syslog-protocol-16. Do you think we need to > Rainer> elaborate more on the potential threats? If so, we > Rainer> definitely would need to reconsider that part of the work > Rainer> (also in -protocol, because it should mention at least all > Rainer> transport-independant threats). >=20 > no, that documents all the threats. It doesn't actually make a call > as to wether a particular threat is important to solve. >=20 > As an example, if integrity is not important to the way people use > syslog, we might not consider it important to provide integrity. On > the other hand if integrity is important to how syslog is used but we > cannot find a way to deliver integrity in a manner that is useful to > people, we have to carefully consider what to do. I now understand. But wouldn't it then make sense to create a separate document for it? I have the feeling that would focus us better than when the discussion is split among different places/documents. And if I understood Eric Hibbard right, we may even have a volunteer to put it together. Or would it be better to put all of this into -protocol's security considerations section? > So, you and Chris have made an argument that we cannot provide > integrity without decreasing the utility of our security solution. Actually not. I wrote ### On the other hand, it might make sense to mandate that a -transport-tls (let me call it so for now) compliant implementation MUST support #2, but MUST be configurable to not use it. That way, we would require that each implementation supports full security but do not force the operator to use it. However, I am not sure if such wording is within the scope of the IETF. ### (#2 was authenticated TLS) Look at the last sentence. I was not sure if we could specify a configuration option inside a RFC. My intension is to mandate in -transport-tls that the implementation MUST support anonymous and authenticated TLS (its even easy to do), but that it must be possible that that the operator decides which to use. Now that I have written this sentence, it probably is already the solution. -transport-tls mandates both as two separate modes. So either mode could be configured by the operator. Then, it's security considerations section could document the implications of mode selection.=20 Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 12:18:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewjbx-0004Wo-Ug; Wed, 11 Jan 2006 12:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewjbx-0004WZ-4J for syslog@megatron.ietf.org; Wed, 11 Jan 2006 12:18:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27923 for ; Wed, 11 Jan 2006 12:16:52 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewjis-0001MC-7n for syslog@ietf.org; Wed, 11 Jan 2006 12:25:23 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2006 09:18:02 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0BHI0Qk003961; Wed, 11 Jan 2006 09:18:01 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 12:18:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Sec 6.1: Truncation Date: Wed, 11 Jan 2006 12:18:00 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122EF2DA9@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYS8k5MFvQCqVz3RJqX9nFzDRup+wACkoPgAH4rzAAADy9LcAAAdK/gAFl9htAADRiHYA== From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 11 Jan 2006 17:18:01.0182 (UTC) FILETIME=[F984EFE0:01C616D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer:=20 Thanks for the update. Comments below.=20 > I have now changed section 6.1 to: >=20 > ### > 6.1. Message Length >=20 > Syslog message size limits are dictated by the syslog transport > mapping in use. There is no upper limit per se. =20 These two sentences are contradictory. I'd remove the last one. The = maximum limit can be dictated by a transport mapping, like in the case = of UDP.=20 > Each transport > mapping MUST define the minimum required message length=20 > support. Any > syslog transport mapping MUST support messages of up to=20 > and including > 480 octets in length. >=20 > Any syslog receiver MUST be able to accept messages of up to and > including 480 octets in length. All receiver=20 > implementations SHOULD > be able to accept messages of up to and including 2048 octets in > length. Receivers MAY receive messages larger than 2048 octets in > length. If a receiver receives a message with a length larger than > it supports, the receiver MAY discard the message or truncate the > payload. >=20 > If a receiver truncates messages, the truncation MUST occur at the > end of the message. UTF-8 encoding and STRUCTURED-DATA=20 > MUST be kept > valid during truncation. =20 You need to be clear what you mean by keeping the UTF-8 encoding. Do you = mean that octets should not be truncated in a way which corrupts the = last character (which may have multiple octets)? It is probably possible to detect such corruption by looking at the = first bit of the last character and making sure it is not 1, if I recall = UTF-8 encoding correctly. If it is 1, drop the last octet. Check the = new last one and do the same until you find one with first bit set to 0. = It seems that to ensure that the receiver would need to be pretty smart. = I wonder if it is a problem. Another question is whether or not = validation like this is more appropriate at the higher layer, where = every UTF character may be validated anyway.=20 > SD-ELEMENTs MUST NOT partly be truncated. > If an SD-ELEMENT is to be truncated, the whole SD-ELEMENT MUST be > deleted. If the last SD-ELEMENT of a message is deleted, the > STRUCTURED-DATA field MUST be changed to NILVALUE. > ### I thought the last train of thought was to do a dumb cutover of octets = at the end. Darren mentioned this is what you will likely get at the = application layer. Proposed rules (although simpler than before) would = still demand quite a bit of handling for messages that exceed the max = size supported by receiver. I now wonder if implementors would really = bother to implement all that logic for the case of messages of sizes = they are not configured to handle. =20 After all the trouble of validating and fixing the message which exceeds = normative size for receiver, all you'd get is a truncated message, which = will be well-formed syslog message after truncation, but may not be = well-formed as far as consuming application is concerned. =20 What do you guys think? Thanks, Anton.=20 >=20 > I have explicitly stated that there is no intrinsic upper=20 > size limit. I did this, because we had so much=20 > confusion/misunderstanding on that fact in the past. I've=20 > also added some details on truncation. The rest is as=20 > suggested by Anton :) >=20 > Please review and comment. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Monday, January 09, 2006 4:49 PM > > To: Anton Okmianski (aokmians) > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] Sec 6.1: Truncation > >=20 > > > Rainer: > > >=20 > > > I agree - this is better than a convoluted rule.=20 > > >=20 > > > I think we only have any business in defining truncation=20 > for relays. =20 > > > For collectors, we have tried to stay away from describing how=20 > > > messages are stored. > > >=20 > > > For relays, I think it would be useful to state that relay can't=20 > > > just drop arbitrary message parts. Your statements about=20 > "some parts=20 > > > ... are lost" may be interpreted that way. > >=20 > > Actually, this was what I meant ;) [I saw a number of use=20 > cases where=20 > > it would make sense to strip some known-not-so-relavant=20 > SD-IDs to be=20 > > strippedd], but ... > > >=20 > > > I would recommend that we state that any truncation must=20 > happen at=20 > > > the end of the message, which I think is what truncation=20 > means to a=20 > > > lot of people anyway. This would prevent an implementation which=20 > > > prefers to throw out STRUCTURED-DATA before the MSG content. A=20 > > > consistent behavior is useful for interop and, in particular, may=20 > > > help in dealing with security issues. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ... this is more important. I now agree with your point. > >=20 > > As a side-note, we had the idea that relay operations may become a=20 > > separate document, so I would prefer not to dig too deep into relay=20 > > behaviour. To specify what you recommend, this is not necessary, so=20 > > this is not really a discussion topic here. > >=20 > > Rainer > > >=20 > > > Thanks, > > > Anton.=20 > > >=20 > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > Sent: Monday, January 09, 2006 3:21 AM > > > > To: Anton Okmianski (aokmians) > > > > Subject: RE: [Syslog] Sec 6.1: Truncation > > > >=20 > > > > Anton, Darren, > > > >=20 > > > > I agree that the truncation rule is probably not really useful,=20 > > > > even confusing. I think it is hard to predict for any potential=20 > > > > message if the more interesting content is in=20 > STRUCTURED-DATA or=20 > > > > in the MSG part. > > > > For example, with our current SD-IDs, I'd prefer to=20 > trunctate them=20 > > > > instead of MSG. Obviously, the case is different for=20 > your LINKDOWN=20 > > > > sample. I also agree with Darren that truncation=20 > probably happens=20 > > > > on the transport layer, the application may not even=20 > see the full=20 > > > > message. > > > >=20 > > > > My conclusion, however, is slightly different: I recommend now=20 > > > > that we remove truncation rules from -protocol. We=20 > should just say=20 > > > > that truncation might happen and that in this case some=20 > parts of=20 > > > > the message are lost - what is at the discretion of the=20 > receiver. > > > >=20 > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: syslog-bounces@lists.ietf.org=20 > > > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton > > > Okmianski > > > > > (aokmians) > > > > > Sent: Friday, January 06, 2006 9:48 PM > > > > > To: syslog@ietf.org > > > > > Subject: [Syslog] Sec 6.1: Truncation > > > > >=20 > > > > > Rainer and all: > > > > >=20 > > > > > I started reading draft #16. Since we are revisiting > > > > everything... I > > > > > am not very comfortable with the current truncation rules. > > > > >=20 > > > > > "Receivers SHOULD follow this order of preference when it > > > comes to > > > > > truncation: > > > > >=20 > > > > > 1) No truncation > > > > > 2) Truncation by dropping SD-ELEMENTs > > > > > 3) If 2) not sufficient, truncate MSG" > > > > >=20 > > > > > I don't think that this is a good recommendation. I would > > > > assume that > > > > > in many cases people would try to tokenize more important > > > data into > > > > > structured data and use message text as a secondary > > user-friendly > > > > > description. For example, for LINK_DOWN message, I > > would probably > > > > > encode link ID in the structured elements as this is > > > something that > > > > > should be readily available for receivers. The MSGID could be=20 > > > > > "LINK_DOWN" and the MSG text may simply be "Link=20 > down". If you=20 > > > > > truncate the structured data, it makes it harder. > > > > >=20 > > > > > I also think, in general it is useful to put more > > important data > > > > > first, which is another reason for putting more valuable > > > data into > > > > > structured data in a more compact way. > > > > >=20 > > > > > Additionally, structured data can be used to provide > > > > message length or > > > > > digest, which can help receiver to determine if message was > > > > truncated. > > > > >=20 > > > > > Also, I think this statement is very convoluted: > > > > >=20 > > > > > "Please note that it is possible that the MSG field is > > truncated > > > > > without dropping any SD-PARAMS. This is the case if a > > > > message with an > > > > > empty STRUCTURED-DATA field must be truncated." > > > > >=20 > > > > > I think I understand what you are driving at, but I don't > > > see it as > > > > > adding any requirements or clarification. > > > > >=20 > > > > > This sentence is not clear although I know what you are > > > > trying to say: > > > > >=20 > > > > > "The limits below are minimum maximum lengths, not > > > maximum length." > > > > >=20 > > > > > I propose replacing the entire section 6.1 with this text: > > > > >=20 > > > > > "Syslog message limits are dictated by the syslog transport > > > > mapping in > > > > > use. Each transport mapping MUST define the minimum > > > > required message > > > > > length support. Any syslog transport mapping MUST support > > > > messages of > > > > > up to and including 480 octets in length. > > > > >=20 > > > > > Any syslog receiver MUST be able to accept messages of > > up to and > > > > > including 480 octets in length. All receiver > > > > implementations SHOULD > > > > > be able to accept messages of up to and including 2048 > > octets in > > > > > length. Receivers MAY receive messages larger than 2048 > > octets in > > > > > length. If a receiver receives a message with a length > > > > larger than it > > > > > supports, the receiver MAY discard the message or=20 > truncate the=20 > > > > > payload. > > > > >=20 > > > > > If truncation is performed by the receiver, it MUST first > > > > truncate the > > > > > MSG field as necessary to meet the supported length limit. If=20 > > > > > truncation of the entire MSG field is not sufficient, then=20 > > > > > additionally, the STRUCTURED-DATA field MUST be truncated > > > > by removing > > > > > one or more SD-ELEMENT fields. A minimum number of > > > > SD-ELEMENT fields > > > > > MUST be truncated starting from the end as necessary to > > meet the > > > > > supported length limit. SD-ELEMENT field can't be truncated > > > > partially. > > > > > If all SD-ELEMENT fields are removed, NILVALUE MUST be > > > > specified for > > > > > STRUCTURED-DATA field. Truncation of HEADER > > > > > field MUST NOT be performed." =20 > > > > >=20 > > > > > BTW, in your text or mine, what happens if message is > > > malformed? A > > > > > proxy won't be able to truncate it properly then. We > > > don't want to > > > > > prevent it from truncating it in some way and sending > > the message > > > > > further, I would think. At least you will see something at > > > > the final > > > > > destination, which maybe more useful than nothing. If we > > > just made > > > > > truncation a simple take the first X octets out of Y > > > > octets, it would > > > > > not be an issue, but then proxy would be allowed to turn a > > > > well-formed > > > > > message into malformed message upon truncation. =20 > > > > >=20 > > > > > What do you think? > > > > >=20 > > > > > Thanks, > > > > > Anton.=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > >=20 > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 13:09:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkPF-0000Cb-Pt; Wed, 11 Jan 2006 13:09:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkPE-00009m-5Y for syslog@megatron.ietf.org; Wed, 11 Jan 2006 13:09:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01165 for ; Wed, 11 Jan 2006 13:07:47 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwkWB-0002pY-D4 for syslog@ietf.org; Wed, 11 Jan 2006 13:16:19 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 87BF4E0053; Wed, 11 Jan 2006 13:09:03 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] Re: Threat model and charter References: <577465F99B41C842AAFBE9ED71E70ABA0E421C@grfint2.intern.adiscon.com> From: Sam Hartman Date: Wed, 11 Jan 2006 13:09:03 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E421C@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Wed, 11 Jan 2006 17:14:44 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Rainer" == Rainer Gerhards writes: Rainer> I now understand. But wouldn't it then make sense to Rainer> create a separate document for it? I have the feeling that Rainer> would focus us better than when the discussion is split Rainer> among different places/documents. And if I understood Eric Rainer> Hibbard right, we may even have a volunteer to put it Rainer> together. I'm not sure this needs to be in a document although documenting it is certainly not harmful. It does need to be decided by the WG and the WG does need to justify that decision. The protocol document will naturally describe all the threats (possibly by referring to 3164 for some of them) and will describe which threats are handled by the mandatory to implement transport. This can be split across documents as desired provided there is a reference. Rainer> Or would it be better to put all of this into -protocol's Rainer> inside a RFC. My intension is to mandate in -transport-tls Rainer> that the implementation MUST support anonymous and Rainer> authenticated TLS (its even easy to do), but that it must Rainer> be possible that that the operator decides which to Rainer> use. Now that I have written this sentence, it probably is Rainer> already the solution. -transport-tls mandates both as two Rainer> separate modes. So either mode could be configured by the Rainer> operator. Then, it's security considerations section could Rainer> document the implications of mode selection. You can certainly do this. It's even a reasonable solution if: 1) The people who need integrity are willing to deploy some sort of credential to the senders. (This is more or less given; without it, I think you can prove no solution exists). 2) That credential is a valid TLS credential. In particular note that TLS would not be useful in a Kerberos environment,an environment where people had ssh public keys, etc. So, from a theoretical standpoint, your proposed solution works. The WG needs to consider whether it meets the needs of operators in practice. If so, then that's a fine direction. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 14:50:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwlzO-0001RC-LV; Wed, 11 Jan 2006 14:50:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwlzN-0001R7-ET for syslog@megatron.ietf.org; Wed, 11 Jan 2006 14:50:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07074 for ; Wed, 11 Jan 2006 14:49:12 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewm6L-0005Tq-4V for syslog@ietf.org; Wed, 11 Jan 2006 14:57:45 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Jan 2006 11:50:22 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,356,1131350400"; d="scan'208"; a="19520605:sNHT25488008" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0BJnsK5006422; Wed, 11 Jan 2006 14:50:19 -0500 (EST) 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.211); Wed, 11 Jan 2006 14:50:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: Threat model and charter Date: Wed, 11 Jan 2006 14:50:16 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122EF2E8E@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYWujT8U5OOrDdRQbKbMkxuhj5YZgAJ5dZg From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , "Balazs Scheidler" X-OriginalArrivalTime: 11 Jan 2006 19:50:57.0737 (UTC) FILETIME=[572C1B90:01C616E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi! I am not sure how re-emerging "TLS vs. SSH" discussion pertains to the = Threat Model for charter. They provide identical security except TLS = requires PKI, while SSH can do PKI or shared-secrets. TLS is well = established. SSH as a transport is not an RFC yet, as far as I = understand, but been around in similar incarnation.=20 So, the relevant issues for the charter in this discussions are: (a) Do we have to provide PKI support for auth? (b) Do we have to provide an auth option that does not require PKI? These requirements would likely drive choice between TLS and SSH.=20 Another relevant issues: (c) Do we have to provide a light-weight non-encrypted security option = which MUST work with any transport? Syslog-sign is such. It covers all = of security except for encryption (message integrity). You get = authentication of original message producer by virtue of shared secret. = You get message integrity. If you include timestamp in integrity check, = it can also provide replay protection. (d) Do we have to address message observation threat? If not. Then we = don't need neither TLS/SSH - syslog-sign would do. This does not prevent = new transport to be used. Some can be used by just underlying tunnels = anyway.=20 Thanks, Anton.=20 =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris=20 > Lonvick (clonvick) > Sent: Wednesday, January 11, 2006 9:19 AM > To: Balazs Scheidler > Cc: syslog@ietf.org > Subject: RE: [Syslog] Re: Threat model and charter >=20 > Hi, >=20 > I was thinking that if we have to do authentication then we=20 > could try to get consensus on a simple authentication=20 > mechanism - a shared secret.=20 > Essentially, each sender would have to be configured with a=20 > shared secret before it could use TLS. The receivers and=20 > relays would also have that information. When a sender=20 > prepares a message, it would hash the shared secret with the=20 > formed message. That hash could be placed in an SD element (=20 > [tlsAuthChk=3D"12345678..."] ). The recipient could extract=20 > the value, and then re-run the hash. If the received hash is=20 > the same as the calculated hash then both the sender and the=20 > receiver must be using the same shared secret. The caveat to=20 > this is in choosing the right hash algorithm. This mechanism=20 > and shared secret authentication has been well defined in=20 > many prior RFCs. A lot of those RFCs used MD5 which is now=20 > going out of favor. Check out RFC 1305 (NTP - appendix D)=20 > and RFC 2385 (authentication for BGP). >=20 > This suggestion tries to keep the ease-of-use of syslog. =20 > Using credentials stored in an X.505 certificate (of the=20 > recipient) would provide a higher degree of authentication -=20 > shared secrets can be much more easily compromised (found,=20 > guessed, brute-forced, etc.) than the validated credentials=20 > contained in a certificate. >=20 > If we can get consensus that an in-packet authentication=20 > mechanism like this is sufficient to meet our threat model,=20 > then we can decide if the shared secret is sufficient (the=20 > REQUIRED mechanism), and/or if we want to RECOMMEND a similar=20 > X.509 mechanism. That would require having each syslog=20 > sender to have an X.509 certificate, and have those signed=20 > and available. That just seems to me to be getting a bit far=20 > away from the ease-of-use that makes syslog so easy to deploy. >=20 > Thoughts? >=20 > Thanks, > Chris >=20 > On Wed, 11 Jan 2006, Balazs Scheidler wrote: >=20 > > On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: > >> Chris, > >> > >> However, it *is* possible to authenticate the peers via X.509=20 > >> certificates. Any TLS implementation can do client and server=20 > >> certificate verification as part of the session setup=20 > process. To the=20 > >> best of my knowledge, some folks use this feature with stunnel. So=20 > >> the server accepts messages only from clients which are=20 > authenticated=20 > >> via their certificate (their certificate-based names are=20 > configured=20 > >> at the server side). > > > > I basically agree with you, one minor addition that this X.509=20 > > certificate based authentication is a hop-by-hop authentication and=20 > > provided the operator trusts all devices on the message path and=20 > > requires authentication on each hop, then message=20 > authenticity can be=20 > > ensured. There's no per-message signature, thus it is not proovable=20 > > that a message was generated by a given device after it has been=20 > > received and stored. > > > > A parallel example: It is in a sense similar to client=20 > authentication=20 > > in > > HTTPS: if you upload a file using HTTPS where client=20 > certificate was=20 > > required and validated, then the file on the server can be=20 > trusted to=20 > > a certain extent (as much as the HTTPS server can be=20 > trusted), however=20 > > there's no means to prove that the file has not been tampered with=20 > > after it has been received. There was no signature _stored_=20 > along the=20 > > file and no such signature exists in the HTTPS protocol=20 > itself, to do=20 > > this the HTTPS client would need to generate a signature before=20 > > transmission and upload the signature along with the file itself. > > > > Back to syslog: TLS and X.509 certificate authentication is=20 > hop-by-hop=20 > > and authenticates the infrastructure and network transmission (like=20 > > HTTPS itself), syslog-sign is a per-message authentication=20 > similar to=20 > > the client-side-sign-and-upload-along-with-file example in HTTPS as=20 > > described above. > > > > -- > > Bazsi > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 14:51:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm0E-0001bo-97; Wed, 11 Jan 2006 14:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm0D-0001bh-1o for syslog@megatron.ietf.org; Wed, 11 Jan 2006 14:51:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07174 for ; Wed, 11 Jan 2006 14:50:04 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewm7A-0005Uy-1u for syslog@ietf.org; Wed, 11 Jan 2006 14:58:37 -0500 Subject: Re: [Syslog] Re: Threat model and charter From: Balazs Scheidler To: Sam Hartman In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA0E421C@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Wed, 11 Jan 2006 20:51:07 +0100 Message-Id: <1137009067.6335.6.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-11 at 13:09 -0500, Sam Hartman wrote: > >>>>> "Rainer" == Rainer Gerhards writes: > You can certainly do this. > It's even a reasonable solution if: > > 1) The people who need integrity are willing to deploy some sort of > credential to the senders. (This is more or less given; without > it, I think you can prove no solution exists). > > 2) That credential is a valid TLS credential. > > In particular note that TLS would not be useful in a Kerberos > environment,an environment where people had ssh public keys, etc. Although not strictly related to this discussion, but TLS does support kerberos based authentication, see RFC 2712 > > So, from a theoretical standpoint, your proposed solution works. The > WG needs to consider whether it meets the needs of operators in > practice. If so, then that's a fine direction. How to decide? Are there operators on this mailing list who we could poll, or is it enough that at least three implementors are on the list were involved in the discussions and seem to agree? -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 15:01:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm9c-0005dc-Fb; Wed, 11 Jan 2006 15:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm9a-0005cr-FA for syslog@megatron.ietf.org; Wed, 11 Jan 2006 15:01:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08452 for ; Wed, 11 Jan 2006 14:59:45 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmGX-0005pM-Hj for syslog@ietf.org; Wed, 11 Jan 2006 15:08:18 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 85472E0053; Wed, 11 Jan 2006 15:01:00 -0500 (EST) To: Balazs Scheidler Subject: Re: [Syslog] Re: Threat model and charter References: <577465F99B41C842AAFBE9ED71E70ABA0E421C@grfint2.intern.adiscon.com> <1137009067.6335.6.camel@bzorp.balabit> From: Sam Hartman Date: Wed, 11 Jan 2006 15:01:00 -0500 In-Reply-To: <1137009067.6335.6.camel@bzorp.balabit> (Balazs Scheidler's message of "Wed, 11 Jan 2006 20:51:07 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Balazs" == Balazs Scheidler writes: Balazs> Although not strictly related to this discussion, but TLS Balazs> does support kerberos based authentication, see RFC 2712 I just knew someone was going to bring that up. I really need to right draft-hartmans-tls-2712-historic. Briefly, the major Kerberos implementations do not provide APIs necessary to implement RFC 2712, the spec provides insufficient detail to be implemented, the Kerberos vendors believe that providing the APIs would be a bad idea from an abstraction standpoint, RFC 2712 only supports DES, and RFC 2712 fails to use Kerberos in a manner that is compatible with ongoing work in the Kerberos working group. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 15:25:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmWx-000416-K0; Wed, 11 Jan 2006 15:25:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmWw-00040N-O1 for syslog@megatron.ietf.org; Wed, 11 Jan 2006 15:25:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10196 for ; Wed, 11 Jan 2006 15:23:53 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmdO-0006Pf-8K for syslog@ietf.org; Wed, 11 Jan 2006 15:32:27 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id A42F227C05A; Wed, 11 Jan 2006 21:18:37 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27382-08; Wed, 11 Jan 2006 21:18:37 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6C6E327C059; Wed, 11 Jan 2006 21:18:37 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 21:24:31 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 21:24:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4222@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYWujT8U5OOrDdRQbKbMkxuhj5YZgAJ5dZgAALDIbA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Chris Lonvick (clonvick)" , "Balazs Scheidler" X-OriginalArrivalTime: 11 Jan 2006 20:24:31.0685 (UTC) FILETIME=[07942F50:01C616ED] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton, > (d) Do we have to address message observation threat? If not.=20 > Then we don't need neither TLS/SSH - syslog-sign would do.=20 > This does not prevent new transport to be used. Some can be=20 > used by just underlying tunnels anyway.=20 Based on my (obviously limited) experience, this is the primary objective that leads to SSL deployments today. So it seems to be something that operators care about (which I can very well understand). Rainer=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 16:34:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwncQ-00015N-6J; Wed, 11 Jan 2006 16:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwncO-00015H-8M for syslog@megatron.ietf.org; Wed, 11 Jan 2006 16:34:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15791 for ; Wed, 11 Jan 2006 16:33:34 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwnjL-0000bO-LX for syslog@ietf.org; Wed, 11 Jan 2006 16:42:09 -0500 Subject: Re: [Syslog] Re: Threat model and charter From: Balazs Scheidler To: Sam Hartman In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA0E421C@grfint2.intern.adiscon.com> <1137009067.6335.6.camel@bzorp.balabit> Content-Type: text/plain Date: Wed, 11 Jan 2006 22:34:44 +0100 Message-Id: <1137015284.8647.7.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-11 at 15:01 -0500, Sam Hartman wrote: > >>>>> "Balazs" == Balazs Scheidler writes: > > Balazs> Although not strictly related to this discussion, but TLS > Balazs> does support kerberos based authentication, see RFC 2712 > > > I just knew someone was going to bring that up. > > I really need to right draft-hartmans-tls-2712-historic. Briefly, the > major Kerberos implementations do not provide APIs necessary to > implement RFC 2712, the spec provides insufficient detail to be > implemented, the Kerberos vendors believe that providing the APIs > would be a bad idea from an abstraction standpoint, RFC 2712 only > supports DES, and RFC 2712 fails to use Kerberos in a manner that is > compatible with ongoing work in the Kerberos working group. While it is true that I only used kerberos5 and TLS separately, but openssl 0.9.7e (the version I have on my notebook in source format) has a file named ssl/kssl.c which seems to be an implementation of RFC2712. But again this is probably not relevant. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 11 17:35:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwoZ1-0005Py-7R; Wed, 11 Jan 2006 17:35:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwoYw-0005Pm-2N for syslog@megatron.ietf.org; Wed, 11 Jan 2006 17:35:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20375 for ; Wed, 11 Jan 2006 17:34:06 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewofu-0002dY-HV for syslog@ietf.org; Wed, 11 Jan 2006 17:42:39 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc12) with SMTP id <2006011122351401400dkijre>; Wed, 11 Jan 2006 22:35:14 +0000 From: "David B Harrington" To: "'Chris Lonvick'" , "'Balazs Scheidler'" Subject: RE: SSH - RE: [Syslog] Re: Threat model and charter Date: Wed, 11 Jan 2006 17:35:08 -0500 Message-ID: <004701c616ff$47dc9db0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYWvDZ1m4ghB09qRvytBH2hkPfKqAAQtwiQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Note that ISMS has a user-authenticatioin requirement for mapping to data access controls, while I do not believe that to be a requirement of syslog. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Wednesday, January 11, 2006 9:30 AM > To: Balazs Scheidler > Cc: syslog@ietf.org > Subject: SSH - RE: [Syslog] Re: Threat model and charter > > Hi, > > I forgot to address the use of SSH for authentication. The > isms WG is > trying to use SSH to provide security for SNMPv3. This can > be done by > having the devices authenticate by having a username and credential > (password, public key, etc.). Again, this sounds to me like > it's getting > further away from the ease of deployment for syslog than we'd like. > However, Rainer mentioned that he thought some people were > already using > SSH to transport syslog. I need to ask: How many people have > implementations that use SSH, and how many are planning this? > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 12 04:46:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewz2h-0008II-6D; Thu, 12 Jan 2006 04:46:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewz2f-0008E2-DU for syslog@megatron.ietf.org; Thu, 12 Jan 2006 04:46:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05275 for ; Thu, 12 Jan 2006 04:45:27 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewz9D-0006Ok-Re for syslog@ietf.org; Thu, 12 Jan 2006 04:54:08 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4899E27C02D; Thu, 12 Jan 2006 10:40:10 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04674-06; Thu, 12 Jan 2006 10:40:10 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C15C327C02C; Thu, 12 Jan 2006 10:40:09 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jan 2006 10:46:04 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Sec 6.1: Truncation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2006 10:45:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E422B@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYS8k5MFvQCqVz3RJqX9nFzDRup+wACkoPgAH4rzAAADy9LcAAAdK/gAFl9htAADRiHYAAjqiOQ From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" X-OriginalArrivalTime: 12 Jan 2006 09:46:04.0699 (UTC) FILETIME=[013FBEB0:01C6175D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton & all, You have good points and I have to admit I am still thinking what is the best way. I would appreciate if some other WG members could express their thoughts... Thanks, Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Wednesday, January 11, 2006 6:18 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] Sec 6.1: Truncation >=20 > Rainer:=20 >=20 > Thanks for the update. Comments below.=20 >=20 > > I have now changed section 6.1 to: > >=20 > > ### > > 6.1. Message Length > >=20 > > Syslog message size limits are dictated by the syslog transport > > mapping in use. There is no upper limit per se. =20 >=20 > These two sentences are contradictory. I'd remove the last=20 > one. The maximum limit can be dictated by a transport=20 > mapping, like in the case of UDP.=20 >=20 > > Each transport > > mapping MUST define the minimum required message length=20 > > support. Any > > syslog transport mapping MUST support messages of up to=20 > > and including > > 480 octets in length. > >=20 > > Any syslog receiver MUST be able to accept messages of up to and > > including 480 octets in length. All receiver=20 > > implementations SHOULD > > be able to accept messages of up to and including 2048 octets in > > length. Receivers MAY receive messages larger than 2048=20 > octets in > > length. If a receiver receives a message with a length=20 > larger than > > it supports, the receiver MAY discard the message or truncate the > > payload. > >=20 > > If a receiver truncates messages, the truncation MUST=20 > occur at the > > end of the message. UTF-8 encoding and STRUCTURED-DATA=20 > > MUST be kept > > valid during truncation. =20 >=20 > You need to be clear what you mean by keeping the UTF-8=20 > encoding. Do you mean that octets should not be truncated in=20 > a way which corrupts the last character (which may have=20 > multiple octets)? >=20 > It is probably possible to detect such corruption by looking=20 > at the first bit of the last character and making sure it is=20 > not 1, if I recall UTF-8 encoding correctly. If it is 1, drop=20 > the last octet. Check the new last one and do the same until=20 > you find one with first bit set to 0.=20 >=20 > It seems that to ensure that the receiver would need to be=20 > pretty smart. I wonder if it is a problem. Another question=20 > is whether or not validation like this is more appropriate at=20 > the higher layer, where every UTF character may be validated anyway.=20 >=20 > > SD-ELEMENTs MUST NOT partly be truncated. > > If an SD-ELEMENT is to be truncated, the whole SD-ELEMENT MUST be > > deleted. If the last SD-ELEMENT of a message is deleted, the > > STRUCTURED-DATA field MUST be changed to NILVALUE. > > ### >=20 > I thought the last train of thought was to do a dumb cutover=20 > of octets at the end. Darren mentioned this is what you will=20 > likely get at the application layer. Proposed rules (although=20 > simpler than before) would still demand quite a bit of=20 > handling for messages that exceed the max size supported by=20 > receiver. I now wonder if implementors would really bother=20 > to implement all that logic for the case of messages of sizes=20 > they are not configured to handle. =20 >=20 > After all the trouble of validating and fixing the message=20 > which exceeds normative size for receiver, all you'd get is a=20 > truncated message, which will be well-formed syslog message=20 > after truncation, but may not be well-formed as far as=20 > consuming application is concerned. =20 >=20 > What do you guys think? >=20 > Thanks, > Anton.=20 >=20 > >=20 > > I have explicitly stated that there is no intrinsic upper=20 > > size limit. I did this, because we had so much=20 > > confusion/misunderstanding on that fact in the past. I've=20 > > also added some details on truncation. The rest is as=20 > > suggested by Anton :) > >=20 > > Please review and comment. > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of=20 > Rainer Gerhards > > > Sent: Monday, January 09, 2006 4:49 PM > > > To: Anton Okmianski (aokmians) > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] Sec 6.1: Truncation > > >=20 > > > > Rainer: > > > >=20 > > > > I agree - this is better than a convoluted rule.=20 > > > >=20 > > > > I think we only have any business in defining truncation=20 > > for relays. =20 > > > > For collectors, we have tried to stay away from describing how=20 > > > > messages are stored. > > > >=20 > > > > For relays, I think it would be useful to state that=20 > relay can't=20 > > > > just drop arbitrary message parts. Your statements about=20 > > "some parts=20 > > > > ... are lost" may be interpreted that way. > > >=20 > > > Actually, this was what I meant ;) [I saw a number of use=20 > > cases where=20 > > > it would make sense to strip some known-not-so-relavant=20 > > SD-IDs to be=20 > > > strippedd], but ... > > > >=20 > > > > I would recommend that we state that any truncation must=20 > > happen at=20 > > > > the end of the message, which I think is what truncation=20 > > means to a=20 > > > > lot of people anyway. This would prevent an=20 > implementation which=20 > > > > prefers to throw out STRUCTURED-DATA before the MSG content. A=20 > > > > consistent behavior is useful for interop and, in=20 > particular, may=20 > > > > help in dealing with security issues. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > ... this is more important. I now agree with your point. > > >=20 > > > As a side-note, we had the idea that relay operations may=20 > become a=20 > > > separate document, so I would prefer not to dig too deep=20 > into relay=20 > > > behaviour. To specify what you recommend, this is not=20 > necessary, so=20 > > > this is not really a discussion topic here. > > >=20 > > > Rainer > > > >=20 > > > > Thanks, > > > > Anton.=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > > Sent: Monday, January 09, 2006 3:21 AM > > > > > To: Anton Okmianski (aokmians) > > > > > Subject: RE: [Syslog] Sec 6.1: Truncation > > > > >=20 > > > > > Anton, Darren, > > > > >=20 > > > > > I agree that the truncation rule is probably not=20 > really useful,=20 > > > > > even confusing. I think it is hard to predict for any=20 > potential=20 > > > > > message if the more interesting content is in=20 > > STRUCTURED-DATA or=20 > > > > > in the MSG part. > > > > > For example, with our current SD-IDs, I'd prefer to=20 > > trunctate them=20 > > > > > instead of MSG. Obviously, the case is different for=20 > > your LINKDOWN=20 > > > > > sample. I also agree with Darren that truncation=20 > > probably happens=20 > > > > > on the transport layer, the application may not even=20 > > see the full=20 > > > > > message. > > > > >=20 > > > > > My conclusion, however, is slightly different: I=20 > recommend now=20 > > > > > that we remove truncation rules from -protocol. We=20 > > should just say=20 > > > > > that truncation might happen and that in this case some=20 > > parts of=20 > > > > > the message are lost - what is at the discretion of the=20 > > receiver. > > > > >=20 > > > > > Rainer > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: syslog-bounces@lists.ietf.org=20 > > > > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton > > > > Okmianski > > > > > > (aokmians) > > > > > > Sent: Friday, January 06, 2006 9:48 PM > > > > > > To: syslog@ietf.org > > > > > > Subject: [Syslog] Sec 6.1: Truncation > > > > > >=20 > > > > > > Rainer and all: > > > > > >=20 > > > > > > I started reading draft #16. Since we are revisiting > > > > > everything... I > > > > > > am not very comfortable with the current truncation rules. > > > > > >=20 > > > > > > "Receivers SHOULD follow this order of preference when it > > > > comes to > > > > > > truncation: > > > > > >=20 > > > > > > 1) No truncation > > > > > > 2) Truncation by dropping SD-ELEMENTs > > > > > > 3) If 2) not sufficient, truncate MSG" > > > > > >=20 > > > > > > I don't think that this is a good recommendation. I would > > > > > assume that > > > > > > in many cases people would try to tokenize more important > > > > data into > > > > > > structured data and use message text as a secondary > > > user-friendly > > > > > > description. For example, for LINK_DOWN message, I > > > would probably > > > > > > encode link ID in the structured elements as this is > > > > something that > > > > > > should be readily available for receivers. The=20 > MSGID could be=20 > > > > > > "LINK_DOWN" and the MSG text may simply be "Link=20 > > down". If you=20 > > > > > > truncate the structured data, it makes it harder. > > > > > >=20 > > > > > > I also think, in general it is useful to put more > > > important data > > > > > > first, which is another reason for putting more valuable > > > > data into > > > > > > structured data in a more compact way. > > > > > >=20 > > > > > > Additionally, structured data can be used to provide > > > > > message length or > > > > > > digest, which can help receiver to determine if message was > > > > > truncated. > > > > > >=20 > > > > > > Also, I think this statement is very convoluted: > > > > > >=20 > > > > > > "Please note that it is possible that the MSG field is > > > truncated > > > > > > without dropping any SD-PARAMS. This is the case if a > > > > > message with an > > > > > > empty STRUCTURED-DATA field must be truncated." > > > > > >=20 > > > > > > I think I understand what you are driving at, but I don't > > > > see it as > > > > > > adding any requirements or clarification. > > > > > >=20 > > > > > > This sentence is not clear although I know what you are > > > > > trying to say: > > > > > >=20 > > > > > > "The limits below are minimum maximum lengths, not > > > > maximum length." > > > > > >=20 > > > > > > I propose replacing the entire section 6.1 with this text: > > > > > >=20 > > > > > > "Syslog message limits are dictated by the syslog transport > > > > > mapping in > > > > > > use. Each transport mapping MUST define the minimum > > > > > required message > > > > > > length support. Any syslog transport mapping MUST support > > > > > messages of > > > > > > up to and including 480 octets in length. > > > > > >=20 > > > > > > Any syslog receiver MUST be able to accept messages of > > > up to and > > > > > > including 480 octets in length. All receiver > > > > > implementations SHOULD > > > > > > be able to accept messages of up to and including 2048 > > > octets in > > > > > > length. Receivers MAY receive messages larger than 2048 > > > octets in > > > > > > length. If a receiver receives a message with a length > > > > > larger than it > > > > > > supports, the receiver MAY discard the message or=20 > > truncate the=20 > > > > > > payload. > > > > > >=20 > > > > > > If truncation is performed by the receiver, it MUST first > > > > > truncate the > > > > > > MSG field as necessary to meet the supported length=20 > limit. If=20 > > > > > > truncation of the entire MSG field is not sufficient, then=20 > > > > > > additionally, the STRUCTURED-DATA field MUST be truncated > > > > > by removing > > > > > > one or more SD-ELEMENT fields. A minimum number of > > > > > SD-ELEMENT fields > > > > > > MUST be truncated starting from the end as necessary to > > > meet the > > > > > > supported length limit. SD-ELEMENT field can't be truncated > > > > > partially. > > > > > > If all SD-ELEMENT fields are removed, NILVALUE MUST be > > > > > specified for > > > > > > STRUCTURED-DATA field. Truncation of HEADER > > > > > > field MUST NOT be performed." =20 > > > > > >=20 > > > > > > BTW, in your text or mine, what happens if message is > > > > malformed? A > > > > > > proxy won't be able to truncate it properly then. We > > > > don't want to > > > > > > prevent it from truncating it in some way and sending > > > the message > > > > > > further, I would think. At least you will see something at > > > > > the final > > > > > > destination, which maybe more useful than nothing. If we > > > > just made > > > > > > truncation a simple take the first X octets out of Y > > > > > octets, it would > > > > > > not be an issue, but then proxy would be allowed to turn a > > > > > well-formed > > > > > > message into malformed message upon truncation. =20 > > > > > >=20 > > > > > > What do you think? > > > > > >=20 > > > > > > Thanks, > > > > > > Anton.=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Syslog mailing list > > > > > > Syslog@lists.ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 12 05:07:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwzMi-00067J-8v; Thu, 12 Jan 2006 05:07:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwzMh-00067E-RZ for syslog@megatron.ietf.org; Thu, 12 Jan 2006 05:07:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06761 for ; Thu, 12 Jan 2006 05:06:09 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwzTl-00074y-Co for syslog@ietf.org; Thu, 12 Jan 2006 05:14:50 -0500 Subject: RE: [Syslog] Sec 6.1: Truncation From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E422B@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E422B@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Thu, 12 Jan 2006 11:07:18 +0100 Message-Id: <1137060438.5769.19.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-01-12 at 10:45 +0100, Rainer Gerhards wrote: > Anton & all, > > You have good points and I have to admit I am still thinking what is the > best way. I would appreciate if some other WG members could express > their thoughts... My pragmatic view is that overly long messages should be split instead of truncated. Of course splitting rules are similar to truncating rules in a sense, but the question of generating the syslog header also comes up, e.g. <16>Jun 12 13:45:54 host app[12345]: This is a too long message should become: <16>Jun 12 13:45:54 host app[12345]: This is a too... <16>Jun 12 13:45:54 host app[12345]: long message This way we don't lose information while still limiting the message size. Of course this will still confuse log analysis applications but it can be solved simply by lifting the message size limit if that is configurable in the syslog application. Maybe we should indicate in an SD-ID that message truncation happened so there would be no ambiguity. Another question whether we allow relays to modify the SD-ID part of the message or it must be done by the sender alone? -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 12 10:48:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4gh-0008W9-66; Thu, 12 Jan 2006 10:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4gd-0008Vz-2M for syslog@megatron.ietf.org; Thu, 12 Jan 2006 10:48:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26276 for ; Thu, 12 Jan 2006 10:47:05 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex4nk-00089A-79 for syslog@ietf.org; Thu, 12 Jan 2006 10:55:49 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2006 07:48:15 -0800 X-IronPort-AV: i="3.99,360,1131350400"; d="scan'208"; a="1766059833:sNHT31511692" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0CFmEQj011427; Thu, 12 Jan 2006 07:48:14 -0800 (PST) Date: Thu, 12 Jan 2006 07:48:14 -0800 (PST) From: Chris Lonvick To: Sam Hartman Subject: Re: [Syslog] Re: Threat model and charter In-Reply-To: Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Sam, I also have a concern that we may try to craft an answer that provides good security but that won't actually be deployed. As an analogy, snmp has similar characteristics to syslog. usm has good security properties but has not been widely deployed. isms is trying to redress that and is also getting bogged down in transport issues. RFC 3562 (Key Management Considerations for the TCP MD5 Signature Option) indicates that shared secrets don't get deployed unless there is a real threat. Even then, it takes a lot of effort to maintain those credentials across a very large network. Utilizing X.509 credentials has much better security properties but are the operations groups of large networks going to be willing to implement that? I would like to hear more discussion from developers, operators and network managers before we draw conclusions. Thanks, Chris On Wed, 11 Jan 2006, Sam Hartman wrote: > > I'm concerned that your analysis seems to be based on what is easy to > implement. > > > We also need to do the analysis of what security is actually required > by syslog deployments. > If the ansers are different, we'll have to deal with that. > > But e are in a different situation if we decide to do something > because we don't know how to do better than if we meet what we believe > the security requirements are. > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 12 12:25:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex6CO-0005gY-Hs; Thu, 12 Jan 2006 12:25:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex6CM-0005gG-MD for syslog@megatron.ietf.org; Thu, 12 Jan 2006 12:25:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02298 for ; Thu, 12 Jan 2006 12:23:58 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex6JV-0002X3-70 for syslog@ietf.org; Thu, 12 Jan 2006 12:32:42 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jan 2006 12:25:09 -0500 X-IronPort-AV: i="3.99,360,1131339600"; d="scan'208"; a="80129959:sNHT36978958" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0CHP36J016004; Thu, 12 Jan 2006 12:25:06 -0500 (EST) 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.211); Thu, 12 Jan 2006 12:25:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Sec 6.1: Truncation Date: Thu, 12 Jan 2006 12:24:58 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122EF322F@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYXYFNTYoZhvdBCQumTXbxdyLIcLwAOfRYw From: "Anton Okmianski \(aokmians\)" To: "Balazs Scheidler" , "Rainer Gerhards" X-OriginalArrivalTime: 12 Jan 2006 17:25:08.0827 (UTC) FILETIME=[22D422B0:01C6179D] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Banzsi: I agree truncation does not solve the issue - that's why I don't want to = over-design it. =20 Splitting is an option I'd leave to application-layer running above = syslog. It is not precluded. Just a matter of another RFC with extra = sd-elements.=20 If we do fragmentation in syslog transport/protocol, we are re-inventing = IP & TCP. We went down the path of defining special sd-elements for this = once, but decided that in most cases increasing max acceptable message = size on receivers and using appropriate transport is a better solution = for many deployments. =20 I'd propose we do truncation as raw octet cut-over, but define an = optional sd-element for msg-length (in octets?), which people can use to = know if there was truncation. However, this would mean we would allow a = proxy to legitimately send malformed messages. Well, a receiver has to = handle those somehow coming from the original sender anyway. It is not = ideal, whichever way you slice it.=20 Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Balazs Scheidler > Sent: Thursday, January 12, 2006 5:07 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] Sec 6.1: Truncation >=20 > On Thu, 2006-01-12 at 10:45 +0100, Rainer Gerhards wrote: > > Anton & all, > >=20 > > You have good points and I have to admit I am still=20 > thinking what is=20 > > the best way. I would appreciate if some other WG members could=20 > > express their thoughts... >=20 > My pragmatic view is that overly long messages should be=20 > split instead of truncated. Of course splitting rules are=20 > similar to truncating rules in a sense, but the question of=20 > generating the syslog header also comes up, e.g. >=20 > <16>Jun 12 13:45:54 host app[12345]: This is a too long message >=20 > should become: >=20 > <16>Jun 12 13:45:54 host app[12345]: This is a too... > <16>Jun 12 13:45:54 host app[12345]: long message >=20 > This way we don't lose information while still limiting the=20 > message size. Of course this will still confuse log analysis=20 > applications but it can be solved simply by lifting the=20 > message size limit if that is configurable in the syslog application. >=20 > Maybe we should indicate in an SD-ID that message truncation=20 > happened so there would be no ambiguity. >=20 > Another question whether we allow relays to modify the SD-ID=20 > part of the message or it must be done by the sender alone? >=20 > -- > Bazsi >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 12 13:27:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7AC-0004FP-FU; Thu, 12 Jan 2006 13:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7AA-0004E8-9h for syslog@megatron.ietf.org; Thu, 12 Jan 2006 13:27:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05778 for ; Thu, 12 Jan 2006 13:25:44 -0500 (EST) From: robert.horn@agfa.com Received: from smtp6.agfa.be ([134.54.1.27] helo=smtp5.agfa.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex7HI-0004Dx-BC for syslog@ietf.org; Thu, 12 Jan 2006 13:34:29 -0500 Received: from morswa037.be.local (morswa037.agfa.be [10.232.220.21] (may be forged)) by smtp5.agfa.be (8.13.5/8.13.5) with ESMTP id k0CIQJgv016312; Thu, 12 Jan 2006 19:26:19 +0100 (MET) Subject: RE: [Syslog] Re: Threat model and charter To: rgerhards@hq.adiscon.com Message-ID: Date: Thu, 12 Jan 2006 13:25:57 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.54 on 10.232.180.82 X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: syslog@ietf.org, syslog-bounces@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think that you are leaping too soon into implementation space. That is why the threat model is requested first. Off the top of my head here are some components of the threat model. I organize these in terms of "Asset, Threat, Mitigation". There are certainly more threats because I know I have left off all the environmental threats like fire, earthquake, backhoe, etc. There are probably more assets to consider. And each of these descriptions is very incomplete. Asset: Secrecy of message contents Threat: Network eavesdropping Mitigation: Encrypted transport or encrypted message Asset: Operational Characteristics of the network Threat: Traffic Analysis Mitigations: a) Encryption of identifying header contents (e.g., source identification) b) Encryption of transport c) "blinding" with random meaningless traffic between genuine end-points d) "blinding" with random meaningless traffic between falsified end-points Asset: Proper functioning of syslog receivers (data sinks) Threat: DoS attack (there are actually many) Mitigation: need to be enumerated. Asset: Messages reaching desired receivers Threat: Bogus masquerading receivers Mitigation: Transport with node identification. Note that message encryption prevents the receiver from reading the message, but it does not mitigate the issue that the message is lost because it goes to the wrong destination. Asset: Message integrity Threat: Message modification Mitigation: Digital checksums/ hash codes; digital signatures. and so forth. R Horn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 12 15:43:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9IW-000473-7C; Thu, 12 Jan 2006 15:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9IV-00046y-HI for syslog@megatron.ietf.org; Thu, 12 Jan 2006 15:43:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16374 for ; Thu, 12 Jan 2006 15:42:29 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex9Pf-0000Kx-QI for syslog@ietf.org; Thu, 12 Jan 2006 15:51:17 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2006 12:41:21 -0800 X-IronPort-AV: i="3.99,360,1131350400"; d="scan'208"; a="248767652:sNHT6695406262" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0CKf7Qj009492; Thu, 12 Jan 2006 12:41:21 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 15:40:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2006 15:40:34 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122EF33AF@xmb-rtp-20d.amer.cisco.com> Thread-Topic: SD-ELEMENT names Thread-Index: AcYXYFNTYoZhvdBCQumTXbxdyLIcLwAPMtwQ From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 12 Jan 2006 20:40:36.0059 (UTC) FILETIME=[70CDBAB0:01C617B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] SD-ELEMENT names X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer and all: I'd like to propose a slight terminology change for syslog protocol for = structured data. I think there is confusion even in this group about = current terminology. For example, we (me included) keep referring to = "structured data element", when we mean "structured data parameter". It = is hard to remember the difference. =20 I think easier vocabulary can help a standard - inside and outside this = group. Here is my proposal: Structured Data =3D> Tags Structured Data Element =3D> Tag Group Structured Data ID =3D> Tag Group ID Structured Data Parameter =3D> Tag Structured Data Parameter Name =3D> Tag Name Structured Data Parameter Value =3D> Tag Value This is much less verbose and easier IMO.=20 Thanks, Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 12 15:53:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9Rd-0006di-T1; Thu, 12 Jan 2006 15:53:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9Rc-0006Xm-7B for syslog@megatron.ietf.org; Thu, 12 Jan 2006 15:53:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17693 for ; Thu, 12 Jan 2006 15:51:54 -0500 (EST) Received: from stratton-two-twenty-three.mit.edu ([18.187.5.223] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex9Ym-0000tN-0B for syslog@ietf.org; Thu, 12 Jan 2006 16:00:41 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 66639E0053; Thu, 12 Jan 2006 15:53:07 -0500 (EST) To: Chris Lonvick Subject: Re: [Syslog] Re: Threat model and charter References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> From: Sam Hartman Date: Thu, 12 Jan 2006 15:53:07 -0500 In-Reply-To: (Chris Lonvick's message of "Thu, 12 Jan 2006 07:48:14 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I agree with your concerns. I believe the only real issue you need to solve before you are done with the chartering discussion is whether you are going to have a transport or whether you are going to use something like syslog-sign. I *think* that you'll need to know what security threats you consider important in order to answer that question. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 13 03:02:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExJtQ-0002x4-PR; Fri, 13 Jan 2006 03:02:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExJtP-0002ww-CW for syslog@megatron.ietf.org; Fri, 13 Jan 2006 03:02:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10841 for ; Fri, 13 Jan 2006 03:01:15 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExK08-0008O4-7N for syslog@ietf.org; Fri, 13 Jan 2006 03:10:08 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6EE8727C02C; Fri, 13 Jan 2006 08:55:47 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19736-09; Fri, 13 Jan 2006 08:55:47 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 3484927C02B; Fri, 13 Jan 2006 08:55:47 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 09:01:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2006 09:01:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E423D@grfint2.intern.adiscon.com> Thread-Topic: SD-ELEMENT names Thread-Index: AcYXYFNTYoZhvdBCQumTXbxdyLIcLwAPMtwQAB6COKA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" X-OriginalArrivalTime: 13 Jan 2006 08:01:44.0057 (UTC) FILETIME=[98075690:01C61817] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] RE: SD-ELEMENT names X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton, I see your point, but I am not yet convinced the proposed terminology is actually better. I have some concerns on "Tag Group" vs. "Tag". If I think about tags, I typically think about something that has a name and a value (good description for param-name and param-value). However, I associate a tag-group with something loosely coupled. In STRUCTURED-DATA, however, each name/value pair is strongly associated with the ID. It is the ID that describes what the whole thing is about, the name/value pairs "just" convey some specifics. Any more comments? Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Thursday, January 12, 2006 9:41 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: SD-ELEMENT names >=20 > Rainer and all: >=20 > I'd like to propose a slight terminology change for syslog=20 > protocol for structured data. I think there is confusion even=20 > in this group about current terminology. For example, we (me=20 > included) keep referring to "structured data element", when=20 > we mean "structured data parameter". It is hard to remember=20 > the difference. =20 >=20 > I think easier vocabulary can help a standard - inside and=20 > outside this group. Here is my proposal: >=20 > Structured Data =3D> Tags > Structured Data Element =3D> Tag Group > Structured Data ID =3D> Tag Group ID > Structured Data Parameter =3D> Tag > Structured Data Parameter Name =3D> Tag Name > Structured Data Parameter Value =3D> Tag Value >=20 > This is much less verbose and easier IMO.=20 >=20 > Thanks, > Anton.=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 13 09:06:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPZQ-0000Dt-Tg; Fri, 13 Jan 2006 09:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPZP-0000Cm-J7 for syslog@megatron.ietf.org; Fri, 13 Jan 2006 09:06:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07999 for ; Fri, 13 Jan 2006 09:05:01 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExPgj-0004ee-8p for syslog@ietf.org; Fri, 13 Jan 2006 09:13:57 -0500 Received: from pc6 (1Cust43.tnt30.lnd3.gbr.da.uu.net [62.188.122.43]) by ranger.systems.pipex.net (Postfix) with SMTP id 1DEE1E0003EA; Fri, 13 Jan 2006 14:06:07 +0000 (GMT) Message-ID: <025001c61841$b1e5b500$0601a8c0@pc6> From: "Tom Petch" To: "Anton Okmianski (aokmians)" References: <98AE08B66FAD1742BED6CB9522B73122EF2E8E@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Syslog] Re: Threat model and charter Date: Fri, 13 Jan 2006 14:02:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton SSH is now a set of RFC, RFC425? Tom Petch ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Chris Lonvick (clonvick)" ; "Balazs Scheidler" Cc: Sent: Wednesday, January 11, 2006 8:50 PM Subject: RE: [Syslog] Re: Threat model and charter Hi! I am not sure how re-emerging "TLS vs. SSH" discussion pertains to the Threat Model for charter. They provide identical security except TLS requires PKI, while SSH can do PKI or shared-secrets. TLS is well established. SSH as a transport is not an RFC yet, as far as I understand, but been around in similar incarnation. So, the relevant issues for the charter in this discussions are: (a) Do we have to provide PKI support for auth? (b) Do we have to provide an auth option that does not require PKI? These requirements would likely drive choice between TLS and SSH. Another relevant issues: (c) Do we have to provide a light-weight non-encrypted security option which MUST work with any transport? Syslog-sign is such. It covers all of security except for encryption (message integrity). You get authentication of original message producer by virtue of shared secret. You get message integrity. If you include timestamp in integrity check, it can also provide replay protection. (d) Do we have to address message observation threat? If not. Then we don't need neither TLS/SSH - syslog-sign would do. This does not prevent new transport to be used. Some can be used by just underlying tunnels anyway. Thanks, Anton. > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris > Lonvick (clonvick) > Sent: Wednesday, January 11, 2006 9:19 AM > To: Balazs Scheidler > Cc: syslog@ietf.org > Subject: RE: [Syslog] Re: Threat model and charter > > Hi, > > I was thinking that if we have to do authentication then we > could try to get consensus on a simple authentication > mechanism - a shared secret. > Essentially, each sender would have to be configured with a > shared secret before it could use TLS. The receivers and > relays would also have that information. When a sender > prepares a message, it would hash the shared secret with the > formed message. That hash could be placed in an SD element ( > [tlsAuthChk="12345678..."] ). The recipient could extract > the value, and then re-run the hash. If the received hash is > the same as the calculated hash then both the sender and the > receiver must be using the same shared secret. The caveat to > this is in choosing the right hash algorithm. This mechanism > and shared secret authentication has been well defined in > many prior RFCs. A lot of those RFCs used MD5 which is now > going out of favor. Check out RFC 1305 (NTP - appendix D) > and RFC 2385 (authentication for BGP). > > This suggestion tries to keep the ease-of-use of syslog. > Using credentials stored in an X.505 certificate (of the > recipient) would provide a higher degree of authentication - > shared secrets can be much more easily compromised (found, > guessed, brute-forced, etc.) than the validated credentials > contained in a certificate. > > If we can get consensus that an in-packet authentication > mechanism like this is sufficient to meet our threat model, > then we can decide if the shared secret is sufficient (the > REQUIRED mechanism), and/or if we want to RECOMMEND a similar > X.509 mechanism. That would require having each syslog > sender to have an X.509 certificate, and have those signed > and available. That just seems to me to be getting a bit far > away from the ease-of-use that makes syslog so easy to deploy. > > Thoughts? > > Thanks, > Chris > > On Wed, 11 Jan 2006, Balazs Scheidler wrote: > > > On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: > >> Chris, > >> > >> However, it *is* possible to authenticate the peers via X.509 > >> certificates. Any TLS implementation can do client and server > >> certificate verification as part of the session setup > process. To the > >> best of my knowledge, some folks use this feature with stunnel. So > >> the server accepts messages only from clients which are > authenticated > >> via their certificate (their certificate-based names are > configured > >> at the server side). > > > > I basically agree with you, one minor addition that this X.509 > > certificate based authentication is a hop-by-hop authentication and > > provided the operator trusts all devices on the message path and > > requires authentication on each hop, then message > authenticity can be > > ensured. There's no per-message signature, thus it is not proovable > > that a message was generated by a given device after it has been > > received and stored. > > > > A parallel example: It is in a sense similar to client > authentication > > in > > HTTPS: if you upload a file using HTTPS where client > certificate was > > required and validated, then the file on the server can be > trusted to > > a certain extent (as much as the HTTPS server can be > trusted), however > > there's no means to prove that the file has not been tampered with > > after it has been received. There was no signature _stored_ > along the > > file and no such signature exists in the HTTPS protocol > itself, to do > > this the HTTPS client would need to generate a signature before > > transmission and upload the signature along with the file itself. > > > > Back to syslog: TLS and X.509 certificate authentication is > hop-by-hop > > and authenticates the infrastructure and network transmission (like > > HTTPS itself), syslog-sign is a per-message authentication > similar to > > the client-side-sign-and-upload-along-with-file example in HTTPS as > > described above. > > > > -- > > Bazsi > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 13 09:06:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPZU-0000EZ-5K; Fri, 13 Jan 2006 09:06:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPZP-0000Cx-Jg for syslog@megatron.ietf.org; Fri, 13 Jan 2006 09:06:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07996 for ; Fri, 13 Jan 2006 09:05:01 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExPgi-0004ea-Eb for syslog@ietf.org; Fri, 13 Jan 2006 09:13:57 -0500 Received: from pc6 (1Cust43.tnt30.lnd3.gbr.da.uu.net [62.188.122.43]) by ranger.systems.pipex.net (Postfix) with SMTP id CE72DE0003F8; Fri, 13 Jan 2006 14:06:02 +0000 (GMT) Message-ID: <024f01c61841$b1257240$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , "Sam Hartman" References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Re: Threat model and charter Date: Fri, 13 Jan 2006 14:00:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Replying to no-one specifically, I think one significant consideration is being missed. Basing security on a secure transport may already exist as an implementation but not as an I-D. I expect it to take at least 6 months, more like 12, to produce an IESG ready I-D. By that time, our long-suffering editor of syslog-protocol says he will have had to stand down. I believe that means we will never produce the two I-Ds needed for advancement and that the WG will shut down with nothing done. More hopefully, I do believe that the threats can be met by syslog-sign. Almost every user I talk to about security wants encryption. I have to work very hard to do so, but mostly succeed, in demonstrating to them that what they need is message origin authentication and integrity and it just so happens that that is what most IPS protocols offer, and, even better, it is much cheaper than encryption. I believe syslog falls into this category for most users, and that the aims of syslog-sign will meet most requirements. I hear it criticised for having the wrong algorithms. Fine, we must change that since every security system nowadays should be algorithm agnostic. MD5 got busted, fine we switch to SHA-1. SHA-1 under threat, no problem, roll on SHA-256. This process will go on for ever so we must incorporate it in anything we produce - like syslog-sign. And, given the state of syslog-sign, current editors still willing, I believe we can get those two I-Ds ready inside four monhts. The only realistic alternative would be to incorporate signature blocks in the style of syslog-sign in the structured data of the message being authenticated. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 13 09:31:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPxv-00073R-Q9; Fri, 13 Jan 2006 09:31:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPxu-00073M-Ag for syslog@megatron.ietf.org; Fri, 13 Jan 2006 09:31:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09569 for ; Fri, 13 Jan 2006 09:30:20 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExQ5D-0005cA-UT for syslog@ietf.org; Fri, 13 Jan 2006 09:39:17 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5760FE0053; Fri, 13 Jan 2006 09:31:38 -0500 (EST) To: "Tom Petch" Subject: Re: [Syslog] Re: Threat model and charter References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> <024f01c61841$b1257240$0601a8c0@pc6> From: Sam Hartman Date: Fri, 13 Jan 2006 09:31:38 -0500 In-Reply-To: <024f01c61841$b1257240$0601a8c0@pc6> (Tom Petch's message of "Fri, 13 Jan 2006 14:00:13 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Tom" == Tom Petch writes: Tom> More hopefully, I do believe that the threats can be met by Tom> syslog-sign. Almost every user I talk to about security Tom> wants encryption. I have to work very hard to do so, but Tom> mostly succeed, in demonstrating to them that what they need Tom> is message origin authentication and integrity and it just so Tom> happens that that is what most IPS protocols offer, and, even Tom> better, it is much cheaper than encryption. I'm not sure it is true that message origin authentication and integrity is much cheaper than encryption with either symmetric or asymmetric cryptography. This may be true when comparing a traditional symmetric block cipher to a hash implemented in software. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 13 11:15:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRaP-0003w4-2i; Fri, 13 Jan 2006 11:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRaN-0003vv-7d for syslog@megatron.ietf.org; Fri, 13 Jan 2006 11:15:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18997 for ; Fri, 13 Jan 2006 11:14:08 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExRhi-0001qg-PK for syslog@ietf.org; Fri, 13 Jan 2006 11:23:07 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2006 08:15:22 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,366,1131350400"; d="scan'208"; a="19682027:sNHT79816394" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0DGFFJj029842; Fri, 13 Jan 2006 11:15:20 -0500 (EST) 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.211); Fri, 13 Jan 2006 11:15:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2006 11:15:16 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122EF3658@xmb-rtp-20d.amer.cisco.com> Thread-Topic: SD-ELEMENT names Thread-Index: AcYXYFNTYoZhvdBCQumTXbxdyLIcLwAPMtwQAB6COKAAESPyMA== From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 13 Jan 2006 16:15:37.0798 (UTC) FILETIME=[971D5E60:01C6185C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] RE: SD-ELEMENT names X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Well, that's why the Tag Group has a Tag Group ID. It is not called a = Tag Set or Tag Array. Maybe there is a better word than Group here. = Cluster? I agree it is not ideal, but I don't believe "Structured Data = Element" is any more intuitive. It sounds like one element, while in = fact it contains multiple parameters and the ID.=20 At least, we agree that Tag is better than Structured Data Parameter. = This is the one I am really after.=20 Thanks, Anton.=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Friday, January 13, 2006 3:02 AM > To: Anton Okmianski (aokmians) > Cc: syslog@ietf.org > Subject: RE: SD-ELEMENT names >=20 > Anton, >=20 > I see your point, but I am not yet convinced the proposed=20 > terminology is actually better. I have some concerns on "Tag=20 > Group" vs. "Tag". If I think about tags, I typically think=20 > about something that has a name and a value (good description=20 > for param-name and param-value). However, I associate a=20 > tag-group with something loosely coupled. In STRUCTURED-DATA,=20 > however, each name/value pair is strongly associated with the=20 > ID. It is the ID that describes what the whole thing is=20 > about, the name/value pairs "just" convey some specifics. >=20 > Any more comments? >=20 > Rainer >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > > Sent: Thursday, January 12, 2006 9:41 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: SD-ELEMENT names > >=20 > > Rainer and all: > >=20 > > I'd like to propose a slight terminology change for syslog protocol=20 > > for structured data. I think there is confusion even in this group=20 > > about current terminology. For example, we (me > > included) keep referring to "structured data element", when we mean=20 > > "structured data parameter". It is hard to remember the difference. > >=20 > > I think easier vocabulary can help a standard - inside and outside=20 > > this group. Here is my proposal: > >=20 > > Structured Data =3D> Tags > > Structured Data Element =3D> Tag Group > > Structured Data ID =3D> Tag Group ID > > Structured Data Parameter =3D> Tag > > Structured Data Parameter Name =3D> Tag Name Structured Data=20 > Parameter=20 > > Value =3D> Tag Value > >=20 > > This is much less verbose and easier IMO.=20 > >=20 > > Thanks, > > Anton.=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 13 12:04:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSLY-00071U-He; Fri, 13 Jan 2006 12:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSLX-00071M-EN for syslog@megatron.ietf.org; Fri, 13 Jan 2006 12:04:15 -0500 Received: from usscmail7.hds.com (usscmail7.hds.com [63.74.235.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21982 for ; Fri, 13 Jan 2006 12:02:51 -0500 (EST) Received: from mail.hds.com (usscmail8 [10.1.6.229]) by usscmail7.hds.com (8.11.7p1+Sun/8.11.5) with ESMTP id k0DH3gG08572 for ; Fri, 13 Jan 2006 09:03:42 -0800 (PST) Received: from usscceb102.corp.hds.com (USSCCNETSLB08-VLAN4.hds.com [10.1.6.68]) by mail.hds.com (8.11.5-p0-rfc19719/8.11.5) with ESMTP id k0DH3fu08501 for ; Fri, 13 Jan 2006 09:03:41 -0800 (PST) Received: from USSCCEVS102.corp.hds.com ([10.1.52.225]) by usscceb102.corp.hds.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 09:03:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jan 2006 09:03:41 -0800 Message-ID: <45D4D9EBC6EF8D418F584D3D3F6AFC1C92923F@USSCCEVS102.corp.hds.com> Thread-Topic: Possible Threats for Syslog Thread-Index: AcYYY03r6Or8hfs5QY27QgaaePOjwA== From: "Eric Hibbard" To: X-OriginalArrivalTime: 13 Jan 2006 17:03:41.0814 (UTC) FILETIME=[4E1F4960:01C61863] Cc: Subject: [Syslog] Possible Threats for Syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1240031842==" Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1240031842== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61863.4DC7741F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61863.4DC7741F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another possible threat to consider for a Syslog environment is: =20 Traffic Pattern Analysis - It is sometimes used as a form of reconnaissance to further hone an attack. The focus of attention is on how the network is being used as opposed to the data content being moved. An analysis of this kind of information can identify details about clients, reveal "hidden" log servers, give clues as to the performance capabilities of certain systems (e.g., excessive retransmits), identify specific chokepoints (ideal for denial of service attacks), quiescent or active periods, etc.=20 =20 Like denial of service attacks, this threat is difficult to prevent. =20 =20 Eric A. Hibbard, CISSP, ISSAP, ISSMP, ISSEP Senior Director, Data Networking Technology Chair, SNIA Security Technical Work Group =20 Office of the CTO HITACHI DATA SYSTEMS 750 Central Expressway, MS 3407 Santa Clara, CA 95050-2627 P 408.970.7979/ F 408.562.5477 eric.hibbard@hds.com =20 =20 ------_=_NextPart_001_01C61863.4DC7741F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Another possible=20 threat to consider for a Syslog=20 environment is:
 
Traffic Pattern=20 Analysis - It is sometimes used as a form of reconnaissance to further = hone an=20 attack. The focus of attention is on how the network is being used as = opposed to=20 the data content being moved. An analysis of this kind of information = can=20 identify details about clients, reveal "hidden" log servers, give clues as = to the=20 performance capabilities of certain systems (e.g., excessive=20 retransmits), identify specific chokepoints (ideal for = denial of=20 service attacks), quiescent or active periods, etc.
 
Like = denial of=20 service attacks, this threat is difficult to = prevent.
 
 
Eric A. Hibbard, CISSP, ISSAP, ISSMP,=20 ISSEP
Senior = Director,=20 Data Networking Technology
Chair, SNIA Security Technical = Work=20 Group
 
Office of the = CTO
HITACHI DATA=20 SYSTEMS
750 Central = Expressway, MS=20 3407
Santa=20 Clara, CA 95050-2627
P 408.970.7979/ F = 408.562.5477
eric.hibbard@hds.com
 
------_=_NextPart_001_01C61863.4DC7741F-- --===============1240031842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --===============1240031842==-- From syslog-bounces@lists.ietf.org Fri Jan 13 12:09:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSQM-0007gH-87; Fri, 13 Jan 2006 12:09:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSQK-0007g4-Ol for syslog@megatron.ietf.org; Fri, 13 Jan 2006 12:09:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22280 for ; Fri, 13 Jan 2006 12:07:49 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExSXd-0003ac-So for syslog@ietf.org; Fri, 13 Jan 2006 12:16:48 -0500 Received: from pc6 (1Cust90.tnt104.lnd4.gbr.da.uu.net [213.116.56.90]) by ranger.systems.pipex.net (Postfix) with SMTP id 8A64AE000398; Fri, 13 Jan 2006 17:08:53 +0000 (GMT) Message-ID: <037a01c6185b$3a649a40$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" References: <577465F99B41C842AAFBE9ED71E70ABA0E4210@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Sec 6.1: Truncation Date: Fri, 13 Jan 2006 17:04:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Truncation of UTF-8 is actually slightly worse than has been described. It is possible to determine from the UTF-8 octets where one coded character ends and another begins. But because Unicode contains combining characters, with no limit on how many of these there can be, and these modify the meaning of previous or later coded characters, it is not possible to determine where one 'symbol' ends. So truncation at a UTF-8 boundary could subtlety change the meaning of a message, even breach security. Not something we can guard against but should mention. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" Cc: Sent: Wednesday, January 11, 2006 11:30 AM Subject: RE: [Syslog] Sec 6.1: Truncation Anton and all, I have now changed section 6.1 to: ### 6.1. Message Length Syslog message size limits are dictated by the syslog transport mapping in use. There is no upper limit per se. Each transport mapping MUST define the minimum required message length support. Any syslog transport mapping MUST support messages of up to and including 480 octets in length. Any syslog receiver MUST be able to accept messages of up to and including 480 octets in length. All receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Receivers MAY receive messages larger than 2048 octets in length. If a receiver receives a message with a length larger than it supports, the receiver MAY discard the message or truncate the payload. If a receiver truncates messages, the truncation MUST occur at the end of the message. UTF-8 encoding and STRUCTURED-DATA MUST be kept valid during truncation. SD-ELEMENTs MUST NOT partly be truncated. If an SD-ELEMENT is to be truncated, the whole SD-ELEMENT MUST be deleted. If the last SD-ELEMENT of a message is deleted, the STRUCTURED-DATA field MUST be changed to NILVALUE. ### I have explicitly stated that there is no intrinsic upper size limit. I did this, because we had so much confusion/misunderstanding on that fact in the past. I've also added some details on truncation. The rest is as suggested by Anton :) Please review and comment. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, January 09, 2006 4:49 PM > To: Anton Okmianski (aokmians) > Cc: syslog@ietf.org > Subject: RE: [Syslog] Sec 6.1: Truncation > > > Rainer: > > > > I agree - this is better than a convoluted rule. > > > > I think we only have any business in defining truncation for > > relays. For collectors, we have tried to stay away from > > describing how messages are stored. > > > > For relays, I think it would be useful to state that relay > > can't just drop arbitrary message parts. Your statements > > about "some parts ... are lost" may be interpreted that way. > > Actually, this was what I meant ;) [I saw a number of use > cases where it > would make sense to strip some known-not-so-relavant SD-IDs to be > strippedd], but ... > > > > I would recommend that we state that any truncation must > > happen at the end of the message, which I think is what > > truncation means to a lot of people anyway. This would > > prevent an implementation which prefers to throw out > > STRUCTURED-DATA before the MSG content. A consistent > > behavior is useful for interop and, in particular, may help > > in dealing with security issues. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ... this is more important. I now agree with your point. > > As a side-note, we had the idea that relay operations may become a > separate document, so I would prefer not to dig too deep into relay > behaviour. To specify what you recommend, this is not > necessary, so this > is not really a discussion topic here. > > Rainer > > > > Thanks, > > Anton. > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Monday, January 09, 2006 3:21 AM > > > To: Anton Okmianski (aokmians) > > > Subject: RE: [Syslog] Sec 6.1: Truncation > > > > > > Anton, Darren, > > > > > > I agree that the truncation rule is probably not really > > > useful, even confusing. I think it is hard to predict for any > > > potential message if the more interesting content is in > > > STRUCTURED-DATA or in the MSG part. > > > For example, with our current SD-IDs, I'd prefer to trunctate > > > them instead of MSG. Obviously, the case is different for > > > your LINKDOWN sample. I also agree with Darren that > > > truncation probably happens on the transport layer, the > > > application may not even see the full message. > > > > > > My conclusion, however, is slightly different: I recommend > > > now that we remove truncation rules from -protocol. We should > > > just say that truncation might happen and that in this case > > > some parts of the message are lost - what is at the > > > discretion of the receiver. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: syslog-bounces@lists.ietf.org > > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton > > Okmianski > > > > (aokmians) > > > > Sent: Friday, January 06, 2006 9:48 PM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] Sec 6.1: Truncation > > > > > > > > Rainer and all: > > > > > > > > I started reading draft #16. Since we are revisiting > > > everything... I > > > > am not very comfortable with the current truncation rules. > > > > > > > > "Receivers SHOULD follow this order of preference when it > > comes to > > > > truncation: > > > > > > > > 1) No truncation > > > > 2) Truncation by dropping SD-ELEMENTs > > > > 3) If 2) not sufficient, truncate MSG" > > > > > > > > I don't think that this is a good recommendation. I would > > > assume that > > > > in many cases people would try to tokenize more important > > data into > > > > structured data and use message text as a secondary > user-friendly > > > > description. For example, for LINK_DOWN message, I > would probably > > > > encode link ID in the structured elements as this is > > something that > > > > should be readily available for receivers. The MSGID could be > > > > "LINK_DOWN" and the MSG text may simply be "Link down". If you > > > > truncate the structured data, it makes it harder. > > > > > > > > I also think, in general it is useful to put more > important data > > > > first, which is another reason for putting more valuable > > data into > > > > structured data in a more compact way. > > > > > > > > Additionally, structured data can be used to provide > > > message length or > > > > digest, which can help receiver to determine if message was > > > truncated. > > > > > > > > Also, I think this statement is very convoluted: > > > > > > > > "Please note that it is possible that the MSG field is > truncated > > > > without dropping any SD-PARAMS. This is the case if a > > > message with an > > > > empty STRUCTURED-DATA field must be truncated." > > > > > > > > I think I understand what you are driving at, but I don't > > see it as > > > > adding any requirements or clarification. > > > > > > > > This sentence is not clear although I know what you are > > > trying to say: > > > > > > > > "The limits below are minimum maximum lengths, not > > maximum length." > > > > > > > > I propose replacing the entire section 6.1 with this text: > > > > > > > > "Syslog message limits are dictated by the syslog transport > > > mapping in > > > > use. Each transport mapping MUST define the minimum > > > required message > > > > length support. Any syslog transport mapping MUST support > > > messages of > > > > up to and including 480 octets in length. > > > > > > > > Any syslog receiver MUST be able to accept messages of > up to and > > > > including 480 octets in length. All receiver > > > implementations SHOULD > > > > be able to accept messages of up to and including 2048 > octets in > > > > length. Receivers MAY receive messages larger than 2048 > octets in > > > > length. If a receiver receives a message with a length > > > larger than it > > > > supports, the receiver MAY discard the message or truncate the > > > > payload. > > > > > > > > If truncation is performed by the receiver, it MUST first > > > truncate the > > > > MSG field as necessary to meet the supported length limit. If > > > > truncation of the entire MSG field is not sufficient, then > > > > additionally, the STRUCTURED-DATA field MUST be truncated > > > by removing > > > > one or more SD-ELEMENT fields. A minimum number of > > > SD-ELEMENT fields > > > > MUST be truncated starting from the end as necessary to > meet the > > > > supported length limit. SD-ELEMENT field can't be truncated > > > partially. > > > > If all SD-ELEMENT fields are removed, NILVALUE MUST be > > > specified for > > > > STRUCTURED-DATA field. Truncation of HEADER > > > > field MUST NOT be performed." > > > > > > > > BTW, in your text or mine, what happens if message is > > malformed? A > > > > proxy won't be able to truncate it properly then. We > > don't want to > > > > prevent it from truncating it in some way and sending > the message > > > > further, I would think. At least you will see something at > > > the final > > > > destination, which maybe more useful than nothing. If we > > just made > > > > truncation a simple take the first X octets out of Y > > > octets, it would > > > > not be an issue, but then proxy would be allowed to turn a > > > well-formed > > > > message into malformed message upon truncation. > > > > > > > > What do you think? > > > > > > > > Thanks, > > > > Anton. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 16 16:52:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EycHT-0007rT-U5; Mon, 16 Jan 2006 16:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EycHS-0007rI-9r for syslog@megatron.ietf.org; Mon, 16 Jan 2006 16:52:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18675 for ; Mon, 16 Jan 2006 16:51:24 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EycPP-0004jG-8v for syslog@ietf.org; Mon, 16 Jan 2006 17:01:05 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k0GLqEtb007923; Tue, 17 Jan 2006 08:52:14 +1100 (EST) From: Darren Reed Message-Id: <200601162151.k0GLpn6L027231@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Sec 6.1: Truncation In-Reply-To: <037a01c6185b$3a649a40$0601a8c0@pc6> To: Tom Petch Date: Tue, 17 Jan 2006 08:51:49 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > Truncation of UTF-8 is actually slightly worse than has been described. > > It is possible to determine from the UTF-8 octets where one coded > character ends and another begins. But because Unicode contains > combining characters, with no limit on how many of these there can > be, and these modify the meaning of previous or later coded characters, > it is not possible to determine where one 'symbol' ends. So truncation > at a UTF-8 boundary could subtlety change the meaning of a message, > even breach security. Not something we can guard against > but should mention. The above seems a little confused to me. How can there be a problem if a message is truncated on the boundary of complex character ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 17 10:35:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyssB-0001bA-4f; Tue, 17 Jan 2006 10:35:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyss9-0001aW-Dv for syslog@megatron.ietf.org; Tue, 17 Jan 2006 10:35:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24689 for ; Tue, 17 Jan 2006 10:34:23 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyt0F-0004is-UZ for syslog@ietf.org; Tue, 17 Jan 2006 10:44:15 -0500 Received: from pc6 (1Cust101.tnt103.lnd4.gbr.da.uu.net [213.116.54.101]) by blaster.systems.pipex.net (Postfix) with SMTP id AA9F4E000059; Tue, 17 Jan 2006 15:35:12 +0000 (GMT) Message-ID: <023601c61b72$d320c640$0601a8c0@pc6> From: "Tom Petch" To: "Darren Reed" References: <200601162151.k0GLpn6L027231@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Sec 6.1: Truncation Date: Tue, 17 Jan 2006 14:39:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Darren Reed" To: "Tom Petch" Cc: Sent: Monday, January 16, 2006 10:51 PM Subject: Re: [Syslog] Sec 6.1: Truncation > [ Charset ISO-8859-1 unsupported, converting... ] > > Truncation of UTF-8 is actually slightly worse than has been described. > > > > It is possible to determine from the UTF-8 octets where one coded > > character ends and another begins. But because Unicode contains > > combining characters, with no limit on how many of these there can > > be, and these modify the meaning of previous or later coded characters, > > it is not possible to determine where one 'symbol' ends. So truncation > > at a UTF-8 boundary could subtlety change the meaning of a message, > > even breach security. Not something we can guard against > > but should mention. > > The above seems a little confused to me. How can there be a problem > if a message is truncated on the boundary of complex character ? > > Darren I lack the precise terminology. Unicode includes base characters and modifying characters, such as diacritic marks, as well as characters that combine the two. Where the combination exists as a single code point, no problem. Where it does not, then what the user would see as a single character is actually sent as several code points, each separately encoded in UTF-8. It is fairly easy for a truncating relay to work out the boundary of the UTF-8 and so ensure that a complete UTF-8 encoding is truncated (or not). It is much harder, probably impossible, to work out where any modifying characters belong, whether they should be removed or left in. And the character 'o' with a diacritic mark is not the same as that character without that diacritic mark, so removing trailing modifying characters changes the meaning, which could be a security exposure. . Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 17 15:21:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxK8-0005Ah-PJ; Tue, 17 Jan 2006 15:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxK6-0005Ac-Vj for syslog@megatron.ietf.org; Tue, 17 Jan 2006 15:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14927 for ; Tue, 17 Jan 2006 15:19:33 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyxSH-0005JM-Tr for syslog@ietf.org; Tue, 17 Jan 2006 15:29:27 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 17 Jan 2006 12:20:47 -0800 X-IronPort-AV: i="3.99,377,1131350400"; d="scan'208"; a="392758035:sNHT31770204" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0HKKkju006585; Tue, 17 Jan 2006 12:20:47 -0800 (PST) Date: Tue, 17 Jan 2006 12:20:45 -0800 (PST) From: Chris Lonvick To: Tom Petch Subject: Re: [Syslog] Re: Threat model and charter In-Reply-To: <024f01c61841$b1257240$0601a8c0@pc6> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E420D@grfint2.intern.adiscon.com> <024f01c61841$b1257240$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 2.2 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Tom, On Fri, 13 Jan 2006, Tom Petch wrote: > Replying to no-one specifically, I think one significant consideration is being > missed. > > Basing security on a secure transport may already exist as an implementation but > not as an I-D. I expect it to take at least 6 months, more like 12, to produce > an IESG ready I-D. By that time, our long-suffering editor of syslog-protocol > says he will have had to stand down. I believe that means we will never produce > the two I-Ds needed for advancement and that the WG will shut down with nothing > done. > > More hopefully, I do believe that the threats can be met by syslog-sign. Almost > every user I talk to about security wants encryption. I have to work very hard > to do so, but mostly succeed, in demonstrating to them that what they need is > message origin authentication and integrity and it just so happens that that is > what most IPS protocols offer, and, even better, it is much cheaper than > encryption. > > I believe syslog falls into this category for most users, and that the aims of > syslog-sign will meet most requirements. I hear it criticised for having the > wrong algorithms. Fine, we must change that since every security system > nowadays should be algorithm agnostic. MD5 got busted, fine we switch to SHA-1. > SHA-1 under threat, no problem, roll on SHA-256. This process will go on for > ever so we must incorporate it in anything we produce - like syslog-sign. > > And, given the state of syslog-sign, current editors still willing, I believe we > can get those two I-Ds ready inside four monhts. > > The only realistic alternative would be to incorporate signature blocks in the > style of syslog-sign in the structured data of the message being authenticated. Your suggestion has good reasoning behind it. I have not heard back from anyone about how SSL is currently being implemented for syslog. From that, I might conclude that message confidentiality is not a priority for the community. (Responses to that would be welcome.) If origin authentication, and loss detection are important then syslog-sign is a fit. Can we get some discussion on this? Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 17 16:01:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxxE-0004pi-Ig; Tue, 17 Jan 2006 16:01:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxxB-0004pS-HE for syslog@megatron.ietf.org; Tue, 17 Jan 2006 16:01:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18550 for ; Tue, 17 Jan 2006 15:59:55 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyy5L-0006yx-Sn for syslog@ietf.org; Tue, 17 Jan 2006 16:09:50 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2006 13:01:11 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,377,1131350400"; d="scan'208"; a="19907974:sNHT24368452" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0HL0MKH024258; Tue, 17 Jan 2006 16:01:08 -0500 (EST) 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.211); Tue, 17 Jan 2006 16:01:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: Threat model and charter Date: Tue, 17 Jan 2006 16:01:00 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122F3BC71@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYbpAx7AXtA55S+QVmyYaettDeohgAA8C5g From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , "Tom Petch" X-OriginalArrivalTime: 17 Jan 2006 21:01:01.0625 (UTC) FILETIME=[1F5D0290:01C61BA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think having a "lightweight" secure transport option without requiring = PKI is good. If one were to use PKI, no doubt TLS beats SSH as an = established standard. But using PKI is not trivial and should not be a = requirement IMO.=20 Based my experience with SSL/TLS on an unrelated product, private key = configuration is a very frequent support issue. Of course, some of it = could be streamlined with better tools and documentation, but whatever = you do it is not as easy as a setting shared secrets. =20 So, I'd prefer to have a basic secure transport option that allows for = using a shared secret. If that transport does not provide for privacy, I = am fine with that. The added benefit thought is that it is = transport-agnostic and adds no overhead on proxies. The validation on = receiver end can also be delayed until message is actually used (if at = all).=20 Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris=20 > Lonvick (clonvick) > Sent: Tuesday, January 17, 2006 3:21 PM > To: Tom Petch > Cc: syslog@ietf.org; Sam Hartman > Subject: Re: [Syslog] Re: Threat model and charter >=20 > Hi Tom, >=20 > On Fri, 13 Jan 2006, Tom Petch wrote: >=20 > > Replying to no-one specifically, I think one significant=20 > consideration=20 > > is being missed. > > > > Basing security on a secure transport may already exist as an=20 > > implementation but not as an I-D. I expect it to take at least 6=20 > > months, more like 12, to produce an IESG ready I-D. By=20 > that time, our=20 > > long-suffering editor of syslog-protocol says he will have had to=20 > > stand down. I believe that means we will never produce the=20 > two I-Ds=20 > > needed for advancement and that the WG will shut down with=20 > nothing done. > > > > More hopefully, I do believe that the threats can be met by=20 > > syslog-sign. Almost every user I talk to about security wants=20 > > encryption. I have to work very hard to do so, but mostly=20 > succeed, in=20 > > demonstrating to them that what they need is message origin=20 > > authentication and integrity and it just so happens that=20 > that is what=20 > > most IPS protocols offer, and, even better, it is much=20 > cheaper than encryption. > > > > I believe syslog falls into this category for most users,=20 > and that the=20 > > aims of syslog-sign will meet most requirements. I hear it=20 > criticised=20 > > for having the wrong algorithms. Fine, we must change that since=20 > > every security system nowadays should be algorithm=20 > agnostic. MD5 got busted, fine we switch to SHA-1. > > SHA-1 under threat, no problem, roll on SHA-256. This=20 > process will go=20 > > on for ever so we must incorporate it in anything we=20 > produce - like syslog-sign. > > > > And, given the state of syslog-sign, current editors still=20 > willing, I=20 > > believe we can get those two I-Ds ready inside four monhts. > > > > The only realistic alternative would be to incorporate signature=20 > > blocks in the style of syslog-sign in the structured data=20 > of the message being authenticated. >=20 > Your suggestion has good reasoning behind it. >=20 > I have not heard back from anyone about how SSL is currently=20 > being implemented for syslog. From that, I might conclude=20 > that message confidentiality is not a priority for the=20 > community. (Responses to that would be welcome.) >=20 > If origin authentication, and loss detection are important=20 > then syslog-sign is a fit. Can we get some discussion on this? >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 17 16:26:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyyLz-0000u2-BS; Tue, 17 Jan 2006 16:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyyFO-0005cy-Bm for syslog@megatron.ietf.org; Tue, 17 Jan 2006 16:20:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24181 for ; Tue, 17 Jan 2006 16:18:44 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyyNZ-0000iD-V9 for syslog@ietf.org; Tue, 17 Jan 2006 16:28:39 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9EF30E006A; Tue, 17 Jan 2006 16:17:44 -0500 (EST) To: "Anton Okmianski (aokmians)" Subject: Re: [Syslog] Re: Threat model and charter References: <98AE08B66FAD1742BED6CB9522B73122F3BC71@xmb-rtp-20d.amer.cisco.com> From: Sam Hartman Date: Tue, 17 Jan 2006 16:17:44 -0500 In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122F3BC71@xmb-rtp-20d.amer.cisco.com> (Anton Okmianski's message of "Tue, 17 Jan 2006 16:01:00 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Tue, 17 Jan 2006 16:26:58 -0500 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org May I recommend TLS PSK or TLS in anonymous DH mode in preference to inventing your own transport that does not use PKI? Also, before doing something based on shared secrets carefully consider the requirements of RFC 4107. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 17 16:55:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyynX-00047A-Ik; Tue, 17 Jan 2006 16:55:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyynW-000475-K3 for syslog@megatron.ietf.org; Tue, 17 Jan 2006 16:55:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28231 for ; Tue, 17 Jan 2006 16:54:00 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyyvi-0002MO-H6 for syslog@ietf.org; Tue, 17 Jan 2006 17:03:55 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2006 13:55:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,377,1131350400"; d="scan'208"; a="19913143:sNHT24141580" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0HLt2Jp004616; Tue, 17 Jan 2006 16:55:14 -0500 (EST) 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.211); Tue, 17 Jan 2006 16:55:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: Threat model and charter Date: Tue, 17 Jan 2006 16:54:59 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122F3BCC5@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYbq9KHuxKat1yrS6iakrbjnqIbsgAAqbCQ From: "Anton Okmianski \(aokmians\)" To: "Sam Hartman" X-OriginalArrivalTime: 17 Jan 2006 21:55:00.0787 (UTC) FILETIME=[AA0DE830:01C61BB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam: > May I recommend TLS PSK=20 Interesting option. Probably not as mature as just using HMAC message = digests.=20 Is there some document which compares and contrasts TLS and SSH? It = seems recent RFCs surrounding both have put them on a redundancy path. = I'd really like to learn why IETF is pursuing both of those at the same = time.=20 > or TLS in anonymous DH mode in=20 > preference to inventing your own transport that does not use PKI? This, I think, does not accomplish an objective of authentication or = frankly any non-trivial security, unless I am missing something. It does = not really do privacy either since it is susceptible to = man-in-the-middle.=20 > Also, before doing something based on shared secrets=20 > carefully consider the requirements of RFC 4107. Good read. Thanks!=20 It bring up a question as to what kind of environment syslog really = addresses: private-only network or private and public. It is one thing = to manage alerts from web server farm and another thing to manage = millions of consumer CPEs such as internet modems, VoIP ATA, etc. A lot = of CPE protocols nowadays go towards having a built-in certificate or = even multiple of them. In the case of alerts from something like VoIP = ATA which would go over public network, I would think privacy would be = more important too.=20 I have also never been clear on the scope of syslog vs SNMP. There is a = large overlap. It would be great if this was clear in the charter. I = hope I am not opening up a deep rat hole here. =20 Thanks, Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 03:12:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8Qv-0005Db-Ds; Wed, 18 Jan 2006 03:12:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8Qt-0005DW-3d for syslog@megatron.ietf.org; Wed, 18 Jan 2006 03:12:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15929 for ; Wed, 18 Jan 2006 03:11:17 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez8Yc-00072T-81 for syslog@ietf.org; Wed, 18 Jan 2006 03:21:17 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1479B27C029; Wed, 18 Jan 2006 09:05:26 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08920-02; Wed, 18 Jan 2006 09:05:26 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id CCF5127C006; Wed, 18 Jan 2006 09:05:25 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 09:11:38 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 09:11:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E426E@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYbo9Hh6r2iQ7wJTWyspTuVDQjR8AAYmeiw From: "Rainer Gerhards" To: "Chris Lonvick" , "Tom Petch" X-OriginalArrivalTime: 18 Jan 2006 08:11:38.0666 (UTC) FILETIME=[CE8238A0:01C61C06] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris,=20 > I have not heard back from anyone about how SSL is currently being=20 > implemented for syslog. From that, I might conclude that message=20 > confidentiality is not a priority for the community. =20 > (Responses to that=20 > would be welcome.) I thought that these postings pointed out what is done: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html You might also want to review some of these documents: http://www.stunnel.org/examples/syslog-ng.html http://freshmeat.net/articles/view/1781/ Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 03:32:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8kU-0001Tv-TC; Wed, 18 Jan 2006 03:32:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8kS-0001Tj-W5 for syslog@megatron.ietf.org; Wed, 18 Jan 2006 03:32:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17625 for ; Wed, 18 Jan 2006 03:31:30 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez8sF-0007lq-7N for syslog@ietf.org; Wed, 18 Jan 2006 03:41:31 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4171227C029; Wed, 18 Jan 2006 09:26:01 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08526-07; Wed, 18 Jan 2006 09:26:01 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E11E927C006; Wed, 18 Jan 2006 09:26:00 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 09:32:14 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Sec 6.1: Truncation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 09:32:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E426F@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYbe/aXGyUzTFOHQG6M9sXD2652IgAjUj2A From: "Rainer Gerhards" To: "Tom Petch" , "Darren Reed" X-OriginalArrivalTime: 18 Jan 2006 08:32:14.0198 (UTC) FILETIME=[AEF17160:01C61C09] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, I agree there are some issues with truncation, but I think they are inherent. We have specified that the message should be truncated at the end of the message. In the text I proposed, I wanted to make sure that the message ends with a technically-complete UTF-8 sequence. Based on Anton's comment, I have to admit I am unsure if there is really benefit in this. Anyhow, even if it is, I think we should not try to preserve the proper meaning. If the message is truncated, the end of it is in doubt. This might also mean a few characters at the end might be wrongly interpreted due to truncated control characters. I think we should document it and live with it (but it was important to bring this issue up so that it can be documented). Any comments? Thanks, Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Tuesday, January 17, 2006 2:40 PM > To: Darren Reed > Cc: syslog@ietf.org > Subject: Re: [Syslog] Sec 6.1: Truncation >=20 > ----- Original Message ----- > From: "Darren Reed" > To: "Tom Petch" > Cc: > Sent: Monday, January 16, 2006 10:51 PM > Subject: Re: [Syslog] Sec 6.1: Truncation >=20 >=20 > > [ Charset ISO-8859-1 unsupported, converting... ] > > > Truncation of UTF-8 is actually slightly worse than has=20 > been described. > > > > > > It is possible to determine from the UTF-8 octets where one coded > > > character ends and another begins. But because Unicode contains > > > combining characters, with no limit on how many of these there can > > > be, and these modify the meaning of previous or later=20 > coded characters, > > > it is not possible to determine where one 'symbol' ends. =20 > So truncation > > > at a UTF-8 boundary could subtlety change the meaning of=20 > a message, > > > even breach security. Not something we can guard against > > > but should mention. > > > > The above seems a little confused to me. How can there be a problem > > if a message is truncated on the boundary of complex character ? > > > > Darren >=20 > I lack the precise terminology. Unicode includes base=20 > characters and modifying > characters, such as diacritic marks, as well as characters=20 > that combine the two. > Where the combination exists as a single code point, no=20 > problem. Where it does > not, then what the user would see as a single character is=20 > actually sent as > several code points, each separately encoded in UTF-8. It is=20 > fairly easy for a > truncating relay to work out the boundary of the UTF-8 and so=20 > ensure that a > complete UTF-8 encoding is truncated (or not). It is much=20 > harder, probably > impossible, to work out where any modifying characters=20 > belong, whether they > should be removed or left in. And the character 'o' with a=20 > diacritic mark is > not the same as that character without that diacritic mark,=20 > so removing trailing > modifying characters changes the meaning, which could be a=20 > security exposure. > . > Tom Petch >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 09:25:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzEFa-000259-L7; Wed, 18 Jan 2006 09:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzEFY-00023U-P4 for syslog@megatron.ietf.org; Wed, 18 Jan 2006 09:25:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17379 for ; Wed, 18 Jan 2006 09:23:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzENt-0003bb-B0 for syslog@ietf.org; Wed, 18 Jan 2006 09:34:02 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2006 06:24:57 -0800 X-IronPort-AV: i="3.99,381,1131350400"; d="scan'208"; a="393139545:sNHT2790770434" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0IEOuju009611; Wed, 18 Jan 2006 06:24:56 -0800 (PST) Date: Wed, 18 Jan 2006 06:24:56 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] Re: Threat model and charter In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E426E@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E426E@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, I'm still not seeing too many responses about how TLS is authenticated. Only Baszi has said that full X.509 certificates should be used - similar to how they are used in stunnel. Is this acceptable to the WG? Should the WG also consider using PSKs as proposed in RFC 4279? Having authenticated TLS will address many of the threats described in RFC 3164. Is this how the Working Group wants to proceed? I'd like to hear from more people on this. Thanks, Chris On Wed, 18 Jan 2006, Rainer Gerhards wrote: > Chris, > >> I have not heard back from anyone about how SSL is currently being >> implemented for syslog. From that, I might conclude that message >> confidentiality is not a priority for the community. >> (Responses to that >> would be welcome.) > > I thought that these postings pointed out what is done: > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html > > You might also want to review some of these documents: > http://www.stunnel.org/examples/syslog-ng.html > http://freshmeat.net/articles/view/1781/ > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 09:34:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzEOJ-0003Zk-H4; Wed, 18 Jan 2006 09:34:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzEOI-0003Ze-L3 for syslog@megatron.ietf.org; Wed, 18 Jan 2006 09:34:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18083 for ; Wed, 18 Jan 2006 09:33:00 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzEW7-0003rb-Sc for syslog@ietf.org; Wed, 18 Jan 2006 09:43:04 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 208C427C029; Wed, 18 Jan 2006 15:27:29 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13914-05; Wed, 18 Jan 2006 15:27:29 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9CB4027C006; Wed, 18 Jan 2006 15:27:28 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 15:33:36 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 15:33:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E427B@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYcOwioxuxafb1cQs2/paB8p7ZqSwAAIkfg From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 18 Jan 2006 14:33:36.0027 (UTC) FILETIME=[2A51FEB0:01C61C3C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi Rainer, >=20 > I'm still not seeing too many responses about how TLS is=20 > authenticated.=20 I guess you do not see them because most often it is used anonymous... As of my experience, people are concerend about message observation. Authentication is not their prime concern (my previous post detailled why it isn't - hint: Intranet, "authentication" via sender IP address). > Only Baszi has said that full X.509 certificates should be=20 > used - similar=20 > to how they are used in stunnel. Is this acceptable to the=20 > WG? =20 Anyhow, TLS authentication is pretty easy. If you do it as in stunnel (and that's always an option), you do not necessarily need to set up a full PKI. Files with the private keys do well. Distributing them to the senders should not be more hassle than distributing shared secrets. > Should=20 > the WG also consider using PSKs as proposed in RFC 4279? >=20 > Having authenticated TLS will address many of the threats=20 > described in RFC=20 > 3164. Is this how the Working Group wants to proceed? I'd=20 > like to hear=20 > from more people on this. I recommend -transport-tls with two modes: - unauthenticated TLS - authenticatated TLS both are mandatory to implement but the user can choose which one he needs (that means that nobody is forced to distribute certs or PKI if only message observation shall be mitigated). Rainer >=20 > Thanks, > Chris >=20 > On Wed, 18 Jan 2006, Rainer Gerhards wrote: >=20 > > Chris, > > > >> I have not heard back from anyone about how SSL is currently being > >> implemented for syslog. From that, I might conclude that message > >> confidentiality is not a priority for the community. > >> (Responses to that > >> would be welcome.) > > > > I thought that these postings pointed out what is done: > > > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html > > > > You might also want to review some of these documents: > > http://www.stunnel.org/examples/syslog-ng.html > > http://freshmeat.net/articles/view/1781/ > > > > Rainer > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 11:16:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFzK-0008Mj-FX; Wed, 18 Jan 2006 11:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFzI-0008Mc-NM for syslog@megatron.ietf.org; Wed, 18 Jan 2006 11:16:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00253 for ; Wed, 18 Jan 2006 11:15:17 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzG7Z-0008Fi-Oi for syslog@ietf.org; Wed, 18 Jan 2006 11:25:20 -0500 Subject: RE: [Syslog] Re: Threat model and charter From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA0E426E@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Wed, 18 Jan 2006 17:16:28 +0100 Message-Id: <1137600988.5083.40.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-18 at 06:24 -0800, Chris Lonvick wrote: > Hi Rainer, > > I'm still not seeing too many responses about how TLS is authenticated. > Only Baszi has said that full X.509 certificates should be used - similar > to how they are used in stunnel. Is this acceptable to the WG? Should > the WG also consider using PSKs as proposed in RFC 4279? > > Having authenticated TLS will address many of the threats described in RFC > 3164. Is this how the Working Group wants to proceed? I'd like to hear > from more people on this. Maybe I was not completely clear. I think we should go the TLS route and let the operator decide whether he wants authenticated or unauthenticated TLS (or asymmetric authentication, e.g. the server is authenticated but the client is not just like in HTTPS) So I fully agree with Rainer on this one. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 12:51:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHSX-0003J2-H1; Wed, 18 Jan 2006 12:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHSW-0003IV-Iv for syslog@megatron.ietf.org; Wed, 18 Jan 2006 12:51:00 -0500 Received: from usscmail7.hds.com (usscmail7.hds.com [63.74.235.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08489 for ; Wed, 18 Jan 2006 12:49:34 -0500 (EST) Received: from mail.hds.com (usscmail9 [10.1.6.230]) by usscmail7.hds.com (8.11.7p1+Sun/8.11.5) with ESMTP id k0IHoSG23956 for ; Wed, 18 Jan 2006 09:50:28 -0800 (PST) Received: from usscceb102.corp.hds.com (USSCCNETSLB08-VLAN4.hds.com [10.1.6.68]) by mail.hds.com (8.11.5-p0-rfc19719/8.11.5) with ESMTP id k0IHoxb16055 for ; Wed, 18 Jan 2006 09:50:59 -0800 (PST) Received: from USSCCEVS102.corp.hds.com ([10.1.52.225]) by usscceb102.corp.hds.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 09:50:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 09:50:27 -0800 Message-ID: <45D4D9EBC6EF8D418F584D3D3F6AFC1C929268@USSCCEVS102.corp.hds.com> Thread-Topic: RE: Re: Threat model and charter Thread-Index: AcYcV6pw4puMAuZoThSUdUZAOFOCrw== From: "Eric Hibbard" To: X-OriginalArrivalTime: 18 Jan 2006 17:50:28.0134 (UTC) FILETIME=[AAE27C60:01C61C57] Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] RE: Re: Threat model and charter X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Maybe I was not completely clear. I think we should go the TLS route and=20 > let the operator decide whether he wants authenticated or > unauthenticated TLS (or asymmetric authentication, e.g. the server is > authenticated but the client is not just like in HTTPS) So I fully agree > with Rainer on this one. >=20 > --=20 > Bazsi This is a way to go, but it is important to note that the absence of client-side certificates (authentication) potentially exposes you to hostile clients attempting to masquerade as a legitimate client. It also makes it more difficult to guard against man-in-the-middle attacks. I like the idea of using TLS because it is much lighter weight than IPsec and it is better understood by a broader group of IT professionals. In a scenario where all the clients and servers are using certificates from the same issuing CA, one could also make the argument that this is the basis of trust, starting at the device, flowing through relays, and arriving at collectors. -Eric =20 Eric A. Hibbard, CISSP, ISSAP, ISSMP, ISSEP Senior Director, Data Networking Technology Chair, SNIA Security Technical Work Group =20 Office of the CTO HITACHI DATA SYSTEMS 750 Central Expressway, MS 3407 Santa Clara, CA 95050-2627 P 408.970.7979/ F 408.562.5477 eric.hibbard@hds.com _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 16:12:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKby-0002Nn-Sz; Wed, 18 Jan 2006 16:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKbx-0002LG-Hh for syslog@megatron.ietf.org; Wed, 18 Jan 2006 16:12:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27432 for ; Wed, 18 Jan 2006 16:11:30 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzKkL-00030c-5F for syslog@ietf.org; Wed, 18 Jan 2006 16:21:38 -0500 Received: from pc6 (1Cust69.tnt30.lnd3.gbr.da.uu.net [62.188.122.69]) by ranger.systems.pipex.net (Postfix) with SMTP id 75ECCE000438; Wed, 18 Jan 2006 21:12:31 +0000 (GMT) Message-ID: <02c101c61c6b$14824d40$0601a8c0@pc6> From: "Tom Petch" To: "Anton Okmianski (aokmians)" References: <98AE08B66FAD1742BED6CB9522B73122F3BCC5@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Syslog] Re: Threat model and charter Date: Wed, 18 Jan 2006 21:08:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Sam Hartman" Cc: "Chris Lonvick (clonvick)" ; "Tom Petch" ; Sent: Tuesday, January 17, 2006 10:54 PM Subject: RE: [Syslog] Re: Threat model and charter Sam: > May I recommend TLS PSK Interesting option. Probably not as mature as just using HMAC message digests. Is there some document which compares and contrasts TLS and SSH? It seems recent RFCs surrounding both have put them on a redundancy path. I'd really like to learn why IETF is pursuing both of those at the same time. > [tp] As I said previously, I think that transport level security is a topic for 2007 and not 2006, but if and when we do go down that route, then I think the choice of which needs careful consideration. SSL, and to some extent TLS, is stated to be the most widely used security system on the Internet but then it is used with that most widely used protocol HTTP, to access (Enterprise) web servers. Look at network operators and a different picture emerges. The survey that was required before isms came into being showed that ssh was the most widely used system; TLS did not figure, appearing less often than Windows Active Directory, while local accounts scored higher than RADIUS/.TACACS+ (this is also the picture I get from looking at network products on websites). This set the direction for isms. Whatever the issues are of distributing security credentials, they have been accommodated, else these systems would not be in use (although I suspect the quality of key management might not meet the standards wanted by the IETF).. So for me the choice should is one of the marketplace. Enterprise web servers and SSL(TLS) is in place and should give good leverage. Network Operators and the answer is SSH. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 16:37:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKzQ-0006j7-Tq; Wed, 18 Jan 2006 16:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKzO-0006in-QY for syslog@megatron.ietf.org; Wed, 18 Jan 2006 16:37:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06198 for ; Wed, 18 Jan 2006 16:35:43 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzL7k-0006NF-6t for syslog@ietf.org; Wed, 18 Jan 2006 16:45:51 -0500 Subject: Re: [Syslog] RE: Re: Threat model and charter From: Balazs Scheidler To: Eric Hibbard In-Reply-To: <45D4D9EBC6EF8D418F584D3D3F6AFC1C929268@USSCCEVS102.corp.hds.com> References: <45D4D9EBC6EF8D418F584D3D3F6AFC1C929268@USSCCEVS102.corp.hds.com> Content-Type: text/plain Date: Wed, 18 Jan 2006 22:36:55 +0100 Message-Id: <1137620215.10286.9.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-01-18 at 09:50 -0800, Eric Hibbard wrote: > > Maybe I was not completely clear. I think we should go the TLS route > and > > let the operator decide whether he wants authenticated or > > unauthenticated TLS (or asymmetric authentication, e.g. the server is > > authenticated but the client is not just like in HTTPS) So I fully > agree > > with Rainer on this one. > > This is a way to go, but it is important to note that the absence of > client-side certificates (authentication) potentially exposes you to > hostile clients attempting to masquerade as a legitimate client. _I_ know this, and I would not recommend doing this in any way :) And of course should be documented in the RFC as well. > It also makes it more difficult to guard against man-in-the-middle attacks. If the server is authenticated then MiTM does not apply, does it? -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 18 21:37:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzPfZ-0002OY-Oe; Wed, 18 Jan 2006 21:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzPfY-0002L5-2V for syslog@megatron.ietf.org; Wed, 18 Jan 2006 21:37:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09066 for ; Wed, 18 Jan 2006 21:35:33 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzPnz-0003NX-HI for syslog@ietf.org; Wed, 18 Jan 2006 21:45:44 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k0J2aiXj029235; Thu, 19 Jan 2006 11:36:44 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k0J2ag5x016036; Thu, 19 Jan 2006 11:36:44 +0900 (JST) Message-ID: <43CEFB3A.4000806@cysols.com> Date: Thu, 19 Jan 2006 11:36:42 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt References: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> <001601c61234$f7e335e0$0601a8c0@pc6> In-Reply-To: <001601c61234$f7e335e0$0601a8c0@pc6> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, Apologies for the delay in responding. > I have had a look at the syslog MIB, and am confused, at a fairly fundamental > level, about the relationship of the MIB to the other documents, RFC3164 and > syslog-protocol. The last two have a common framework/architecture, spelt out > at the beginning of each, with a common terminology of device, relay, collector, > server. The MIB is different. > > Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group of > syslog devices' and 'One or more syslog devices which may be on the same host'. > '"facilities" generate messages indicating their own status or the occurance of > events. These messages are handled by what has come to be known as the syslog > process or device' I agree with you that the definition of "syslog device" is NOT consistent with RFC3164 and syslog-protocol-17. I will fix this in the next draft. Thanks for pointing that out. As far as management is concerned the syslog daemon [receiver/relay] is an application ( doing a specific task viz. receiving and forwarding syslog messages). There may be several syslog daemons on a host. That has been provisioned for in the MIB. > Which leaves me with the impression of a loosely-coupled system of hosts > communicating via proprietary protocols with multiple instances of a syslog > daemon per host forwarding messages onward. Really? There is nothing that prohibits one from using multiple syslog daemons. > could be but I think I am> lost here and that the introduction should be recast > in the language of RFC3164/syslog-protocol (even if it is intending to convey the > above). Right. I will find a better name for the entity that we intend to manage using the MIB and of course must not conflict with the terms used in 3164/syslog-protocol. In the absence of a better name I may use the term "entity" itself. It receives, stores and forwards syslog messages. Let me know if I have missed out something. Cheers Glenn > > Tom Petch > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog -- +----------------------------------------------------------+ Cyber Solutions Inc. Phone 022-303-4012 6-6-3, Minami Yoshinari Fax 022-303-4015 Aoba-ku, Sendai, Japan 989-3204 e-mail cyber@cysols.com +----------------------------------------------------------+ _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 19 16:37:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhSq-0001a5-T4; Thu, 19 Jan 2006 16:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhSq-0001a0-39 for syslog@megatron.ietf.org; Thu, 19 Jan 2006 16:37:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28884 for ; Thu, 19 Jan 2006 16:35:36 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzhbO-0006Ox-Lw for syslog@ietf.org; Thu, 19 Jan 2006 16:45:58 -0500 Received: from pc6 (1Cust171.tnt30.lnd3.gbr.da.uu.net [62.188.122.171]) by galaxy.systems.pipex.net (Postfix) with SMTP id 626D7E00047F; Thu, 19 Jan 2006 21:36:41 +0000 (GMT) Message-ID: <026e01c61d37$9dccf6a0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" References: <577465F99B41C842AAFBE9ED71E70ABA0E426F@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Sec 6.1: Truncation Date: Thu, 19 Jan 2006 20:04:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Rainer Gerhards" To: "Tom Petch" ; "Darren Reed" Cc: Sent: Wednesday, January 18, 2006 9:32 AM Subject: RE: [Syslog] Sec 6.1: Truncation Tom, I agree there are some issues with truncation, but I think they are inherent. We have specified that the message should be truncated at the end of the message. In the text I proposed, I wanted to make sure that the message ends with a technically-complete UTF-8 sequence. Based on Anton's comment, I have to admit I am unsure if there is really benefit in this. Anyhow, even if it is, I think we should not try to preserve the proper meaning. If the message is truncated, the end of it is in doubt. This might also mean a few characters at the end might be wrongly interpreted due to truncated control characters. I think we should document it and live with it (but it was important to bring this issue up so that it can be documented). Any comments? Thanks, Rainer Rainer Yes, I had in mind only to add a sentence which, assuming we end up with truncation in mid text, points out the two issues, that truncating on a octet boundary may result in incomplete UTF-8 encodings, and that truncating on the boundary of a UTF-8 encoding may result in an incomplete composite character (a brief foray into the UCS website suggests that that is the appropriate term) Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 20 04:45:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezspc-00051J-Nb; Fri, 20 Jan 2006 04:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezspa-000518-Iy for syslog@megatron.ietf.org; Fri, 20 Jan 2006 04:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25817 for ; Fri, 20 Jan 2006 04:43:50 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzsyF-0005LB-7l for syslog@ietf.org; Fri, 20 Jan 2006 04:54:18 -0500 Received: from pc6 (1Cust143.tnt4.lnd4.gbr.da.uu.net [62.188.133.143]) by astro.systems.pipex.net (Postfix) with SMTP id 74074E00037F; Fri, 20 Jan 2006 09:44:53 +0000 (GMT) Message-ID: <001001c61d9d$5a360b00$0601a8c0@pc6> From: "Tom Petch" To: "Glenn Mansfield Keeni" References: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> <001601c61234$f7e335e0$0601a8c0@pc6> <43CEFB3A.4000806@cysols.com> Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt Date: Fri, 20 Jan 2006 09:34:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Although these comments are a response to Glenn, I would appreciate others on the list reading and commenting on pp3-4 of the syslog-mib which describes syslog (nothing MIBby, honest) in terms I am struggling with, if only to say 'yes, that is exactly how I see syslog being used'. Recall that IESG tends to require a MIB to allow protocols to advance so unless we agree on a MIB, we may not have a syslog-protocol:-( Glenn Ok so far but ...:-) you talk of 'receiving and forwarding syslog messages', that is of relay and collector in syslog-protocol terms; what about sender? Do you envisage any use of this MIB for an entity that is only involved in sending packets conforming to syslog-protocol? And when the document talks of receiving messages, are these messages ones that conform to syslog-protocol or does it include messages in a proprietary format that may or may not be emitted as syslog-protocol messages? And when this document talks of this being used to manage a group of syslog devices, what makes this a group? Are they all running under the same instance of an operating system (allowing sysplex as a single operating system)? If not, what makes it a group? Tom Petch ----- Original Message ----- From: "Glenn Mansfield Keeni" To: "Tom Petch" Cc: Sent: Thursday, January 19, 2006 3:36 AM Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt > Tom, > Apologies for the delay in responding. > > I have had a look at the syslog MIB, and am confused, at a fairly fundamental > > level, about the relationship of the MIB to the other documents, RFC3164 and > > syslog-protocol. The last two have a common framework/architecture, spelt out > > at the beginning of each, with a common terminology of device, relay, collector, > > server. The MIB is different. > > > > Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group of > > syslog devices' and 'One or more syslog devices which may be on the same host'. > > '"facilities" generate messages indicating their own status or the occurance of > > events. These messages are handled by what has come to be known as the syslog > > process or device' > I agree with you that the definition of "syslog device" is NOT consistent with > RFC3164 and syslog-protocol-17. I will fix this in the next draft. Thanks for > pointing that out. > As far as management is concerned the syslog daemon [receiver/relay] is an > application ( doing a specific task viz. receiving and forwarding syslog messages). > There may be several syslog daemons on a host. That has been provisioned for in the > MIB. > > Which leaves me with the impression of a loosely-coupled system of hosts > > communicating via proprietary protocols with multiple instances of a syslog > > daemon per host forwarding messages onward. Really? > There is nothing that prohibits one from using multiple syslog daemons. > > could be but I think I am> lost here and that the introduction should be recast > > in the language of RFC3164/syslog-protocol (even if it is intending to convey the > > above). > Right. I will find a better name for the entity that we intend to manage using the > MIB and of course must not conflict with the terms used in 3164/syslog-protocol. In > the absence of a better name I may use the term "entity" itself. It receives, stores > and forwards syslog messages. Let me know if I have missed out something. > > Cheers > > Glenn > > > > > Tom Petch > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > -- > +----------------------------------------------------------+ > Cyber Solutions Inc. Phone 022-303-4012 > 6-6-3, Minami Yoshinari Fax 022-303-4015 > Aoba-ku, Sendai, Japan 989-3204 e-mail cyber@cysols.com > +----------------------------------------------------------+ > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 20 08:58:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezwme-0004WH-D0; Fri, 20 Jan 2006 08:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezwmc-0004W8-Cl for syslog@megatron.ietf.org; Fri, 20 Jan 2006 08:58:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14704 for ; Fri, 20 Jan 2006 08:57:00 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzwvH-00058y-OK for syslog@ietf.org; Fri, 20 Jan 2006 09:07:29 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k0KDvnER024313; Sat, 21 Jan 2006 00:57:49 +1100 (EST) From: Darren Reed Message-Id: <200601201357.k0KDvOp2007493@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Sec 6.1: Truncation In-Reply-To: <026e01c61d37$9dccf6a0$0601a8c0@pc6> To: Tom Petch Date: Sat, 21 Jan 2006 00:57:24 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Is the truncation of a message on a UTF-8 boundary rather than within an extended character something that syslog daemons SHOULD do rather than MUST do ? (To use the RFC words.) Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 20 09:07:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzwvZ-0006Rt-Hd; Fri, 20 Jan 2006 09:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzwvX-0006Pa-OS for syslog@megatron.ietf.org; Fri, 20 Jan 2006 09:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15353 for ; Fri, 20 Jan 2006 09:06:16 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezx4G-0005Ou-Fv for syslog@ietf.org; Fri, 20 Jan 2006 09:16:46 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k0KE7ZcD020460; Sat, 21 Jan 2006 01:07:35 +1100 (EST) From: Darren Reed Message-Id: <200601201407.k0KE7A9r007228@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Re: Threat model and charter In-Reply-To: To: Chris Lonvick Date: Sat, 21 Jan 2006 01:07:10 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, > I'm still not seeing too many responses about how TLS is authenticated. > Only Baszi has said that full X.509 certificates should be used - similar > to how they are used in stunnel. Is this acceptable to the WG? Should > the WG also consider using PSKs as proposed in RFC 4279? > > Having authenticated TLS will address many of the threats described in RFC > 3164. Is this how the Working Group wants to proceed? I'd like to hear > from more people on this. I think supporting TLS and all of its authentication options is what we should do in our documentation. Or to put it another way, we shouldn't worry ourselves with restricting use of TLS to a particular authentication model, be it PSK or X.509 or something else. What we should be doing is letting systems people use whatever they feel comfortable with and are already deploying...which makes me think, we need to be saying "authentiation style(s) X must be included", to set a minimum level of interoperability between all implementations. I believe that minimum level should be PSK as anything certificate orientated can quickly become complicated, not just for management but initial use. So to express this in RFC terms, TLS PSK MUST be supported, TLS .... SHOULD be supported, TLS ...... Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 20 10:39:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyMK-0004dz-Ci; Fri, 20 Jan 2006 10:39:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyMI-0004dI-B6 for syslog@megatron.ietf.org; Fri, 20 Jan 2006 10:39:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23137 for ; Fri, 20 Jan 2006 10:37:58 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyV0-0000Dk-5t for syslog@ietf.org; Fri, 20 Jan 2006 10:48:29 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2006 07:39:04 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="250314980:sNHT32539168" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0KFcwQR021872; Fri, 20 Jan 2006 07:39:04 -0800 (PST) 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.211); Fri, 20 Jan 2006 10:39:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Sec 6.1: Truncation Date: Fri, 20 Jan 2006 10:39:01 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122F9C1E1@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Sec 6.1: Truncation Thread-Index: AcYdye1Bmwnrde1xRwi2fC7IaAqwOQADTaaA From: "Anton Okmianski \(aokmians\)" To: "Darren Reed" , "Tom Petch" X-OriginalArrivalTime: 20 Jan 2006 15:39:02.0680 (UTC) FILETIME=[A39D3180:01C61DD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think the suggestion from me and Tom (if I interpret his email = correctly) is to state that messages can be truncated at the end at an = arbitrary point. We also make a note that this may result in invalid = UTF character encoding, or a change in UTF character. =20 I don't think it even warrants a SHOULD for truncation to preserve UTF = character in full. Valid characters when you only get some of them after = truncation may result in a wrong language word, anyway.=20 Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Friday, January 20, 2006 8:57 AM > To: Tom Petch > Cc: syslog@ietf.org > Subject: Re: [Syslog] Sec 6.1: Truncation >=20 >=20 > Is the truncation of a message on a UTF-8 boundary rather=20 > than within an extended character something that syslog=20 > daemons SHOULD do rather than MUST do ? (To use the RFC words.) >=20 > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 20 16:04:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03R6-00079K-8L; Fri, 20 Jan 2006 16:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03R3-00078y-SF for syslog@megatron.ietf.org; Fri, 20 Jan 2006 16:04:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20665 for ; Fri, 20 Jan 2006 16:03:13 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03Zo-0003Qx-1V for syslog@ietf.org; Fri, 20 Jan 2006 16:13:47 -0500 Received: from pc6 (1Cust253.tnt109.lnd4.gbr.da.uu.net [62.188.172.253]) by astro.systems.pipex.net (Postfix) with SMTP id 9A210E000041; Fri, 20 Jan 2006 21:04:06 +0000 (GMT) Message-ID: <039a01c61dfc$a415e420$0601a8c0@pc6> From: "Tom Petch" To: "Anton Okmianski \(aokmians\)" , "Darren Reed" References: <98AE08B66FAD1742BED6CB9522B73122F9C1E1@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Syslog] Sec 6.1: Truncation Date: Fri, 20 Jan 2006 20:59:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I don't have a strong view on SHOULD v MUST v neither, happy with any of them. My point was that this is UTF-8 which I see as an unfamiliar technology for some, perhaps for many, so while the idea that truncating a message can change its meaning I would expect to be obvious to all, the idea of truncation leading to a change within a character (from base + diacritic mark to base) or to an illegal string (UTF-8 says three octets follow and there are none) to be less familiar and so worth pointing out. So, if we truncate any UTF-8 string, then I would like to see a warning of what the consequences might be. I think it unrealistic to ask for truncation at the boundary of a composite character, I suspect it unrealistic to ask for more than a SHOULD to truncate at an UTF-8 boundary and perhaps even a SHOULD is too much, but as I said, I don't have a strong view on that aspect on truncation. Tom Petch ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Darren Reed" ; "Tom Petch" Cc: Sent: Friday, January 20, 2006 4:39 PM Subject: RE: [Syslog] Sec 6.1: Truncation I think the suggestion from me and Tom (if I interpret his email correctly) is to state that messages can be truncated at the end at an arbitrary point. We also make a note that this may result in invalid UTF character encoding, or a change in UTF character. I don't think it even warrants a SHOULD for truncation to preserve UTF character in full. Valid characters when you only get some of them after truncation may result in a wrong language word, anyway. Anton. > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Friday, January 20, 2006 8:57 AM > To: Tom Petch > Cc: syslog@ietf.org > Subject: Re: [Syslog] Sec 6.1: Truncation > > > Is the truncation of a message on a UTF-8 boundary rather > than within an extended character something that syslog > daemons SHOULD do rather than MUST do ? (To use the RFC words.) > > Darren > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 23 00:42:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0uTe-00045D-Qd; Mon, 23 Jan 2006 00:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0uTc-00044a-LE for syslog@megatron.ietf.org; Mon, 23 Jan 2006 00:42:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17776 for ; Mon, 23 Jan 2006 00:41:22 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0ucs-0000lK-5g for syslog@ietf.org; Mon, 23 Jan 2006 00:52:27 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k0N5g6Xj008602; Mon, 23 Jan 2006 14:42:06 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k0N5g25x008219; Mon, 23 Jan 2006 14:42:06 +0900 (JST) Message-ID: <43D46CAA.8080403@cysols.com> Date: Mon, 23 Jan 2006 14:42:02 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt References: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> <001601c61234$f7e335e0$0601a8c0@pc6> <43CEFB3A.4000806@cysols.com> <001001c61d9d$5a360b00$0601a8c0@pc6> In-Reply-To: <001001c61d9d$5a360b00$0601a8c0@pc6> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, Tom Petch wrote: > Although these comments are a response to Glenn, I would appreciate others on > the list reading and commenting on pp3-4 of the syslog-mib which describes > syslog (nothing MIBby, honest) in terms I am struggling with, if only to say > 'yes, that is exactly how I see syslog being used'. > > Recall that IESG tends to require a MIB to allow protocols to advance so unless > we agree on a MIB, we may not have a syslog-protocol:-( > > Glenn > > Ok so far but ...:-) > you talk of 'receiving and forwarding syslog messages', that is of relay and > collector in syslog-protocol terms; what about sender? Do you envisage any use > of this MIB for an entity that is only involved in sending packets conforming to > syslog-protocol? Hmm. I do not envisage the MIB being used for a pure sender. The Syslog daemon is the target. > > And when the document talks of receiving messages, are these messages ones that > conform to syslog-protocol or does it include messages in a proprietary format > that may or may not be emitted as syslog-protocol messages? In the text "message" denotes "Syslog Message". I will add a sentence clarifying that. > > And when this document talks of this being used to manage a group of syslog > devices, what makes this a group? Are they all running under the same instance > of an operating system (allowing sysplex as a single operating system)? If not, > what makes it a group? It means that there may be more than one Syslog daemons running on different ports /network addresses. The grouping is a feature not a necessaity. I think that it is providing flexibility that will be needed. Am I missing something here ? > > Tom Petch Glenn > > ----- Original Message ----- > From: "Glenn Mansfield Keeni" > To: "Tom Petch" > Cc: > Sent: Thursday, January 19, 2006 3:36 AM > Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt > > > >>Tom, >> Apologies for the delay in responding. >> >>>I have had a look at the syslog MIB, and am confused, at a fairly > > fundamental > >>>level, about the relationship of the MIB to the other documents, RFC3164 and >>>syslog-protocol. The last two have a common framework/architecture, spelt > > out > >>>at the beginning of each, with a common terminology of device, relay, > > collector, > >>>server. The MIB is different. >>> >>>Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group > > of > >>>syslog devices' and 'One or more syslog devices which may be on the same > > host'. > >>>'"facilities" generate messages indicating their own status or the occurance > > of > >>>events. These messages are handled by what has come to be known as the > > syslog > >>>process or device' >> >>I agree with you that the definition of "syslog device" is NOT consistent with >>RFC3164 and syslog-protocol-17. I will fix this in the next draft. Thanks for >>pointing that out. >> As far as management is concerned the syslog daemon [receiver/relay] is an >>application ( doing a specific task viz. receiving and forwarding syslog > > messages). > >>There may be several syslog daemons on a host. That has been provisioned for > > in the > >>MIB. >> >>>Which leaves me with the impression of a loosely-coupled system of hosts >>>communicating via proprietary protocols with multiple instances of a syslog >>>daemon per host forwarding messages onward. Really? >> >>There is nothing that prohibits one from using multiple syslog daemons. >> >>>could be but I think I am> lost here and that the introduction should be > > recast > >>>in the language of RFC3164/syslog-protocol (even if it is intending to > > convey the > >>>above). >> >>Right. I will find a better name for the entity that we intend to manage using > > the > >>MIB and of course must not conflict with the terms used in > > 3164/syslog-protocol. In > >>the absence of a better name I may use the term "entity" itself. It receives, > > stores > >>and forwards syslog messages. Let me know if I have missed out something. >> >>Cheers >> >>Glenn >> >> >>>Tom Petch >>> >>> >>>_______________________________________________ >>>Syslog mailing list >>>Syslog@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/syslog >> >> >>-- >>+----------------------------------------------------------+ >> Cyber Solutions Inc. Phone 022-303-4012 >> 6-6-3, Minami Yoshinari Fax 022-303-4015 >> Aoba-ku, Sendai, Japan 989-3204 e-mail cyber@cysols.com >>+----------------------------------------------------------+ >> >> > > -- +----------------------------------------------------------+ Cyber Solutions Inc. Phone 022-303-4012 6-6-3, Minami Yoshinari Fax 022-303-4015 Aoba-ku, Sendai, Japan 989-3204 e-mail cyber@cysols.com +----------------------------------------------------------+ _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 23 02:20:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0w0N-0003yi-Eo; Mon, 23 Jan 2006 02:20:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0w0L-0003yC-9L for syslog@megatron.ietf.org; Mon, 23 Jan 2006 02:20:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23761 for ; Mon, 23 Jan 2006 02:19:15 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0w96-0003Rc-Uh for syslog@ietf.org; Mon, 23 Jan 2006 02:30:22 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 84E4027C02C; Mon, 23 Jan 2006 08:13:19 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03933-06; Mon, 23 Jan 2006 08:13:19 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 419C527C02B; Mon, 23 Jan 2006 08:13:19 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 08:19:48 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Threat model and charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jan 2006 08:19:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E42A8@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Re: Threat model and charter Thread-Index: AcYdyxrO3Bi1TP8ZRLKnwcmuxaCuugCIkQGw From: "Rainer Gerhards" To: "Darren Reed" , "Chris Lonvick" X-OriginalArrivalTime: 23 Jan 2006 07:19:48.0436 (UTC) FILETIME=[64BB8940:01C61FED] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I agree with Darren. Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Friday, January 20, 2006 3:07 PM > To: Chris Lonvick > Cc: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: Re: [Syslog] Re: Threat model and charter >=20 > Chris, >=20 > > I'm still not seeing too many responses about how TLS is=20 > authenticated.=20 > > Only Baszi has said that full X.509 certificates should be=20 > used - similar=20 > > to how they are used in stunnel. Is this acceptable to the=20 > WG? Should=20 > > the WG also consider using PSKs as proposed in RFC 4279? > >=20 > > Having authenticated TLS will address many of the threats=20 > described in RFC=20 > > 3164. Is this how the Working Group wants to proceed? I'd=20 > like to hear=20 > > from more people on this. >=20 > I think supporting TLS and all of its authentication options is what > we should do in our documentation. Or to put it another way, we > shouldn't worry ourselves with restricting use of TLS to a particular > authentication model, be it PSK or X.509 or something else. >=20 > What we should be doing is letting systems people use whatever they > feel comfortable with and are already deploying...which makes me > think, we need to be saying "authentiation style(s) X must be=20 > included", > to set a minimum level of interoperability between all=20 > implementations. >=20 > I believe that minimum level should be PSK as anything certificate > orientated can quickly become complicated, not just for management > but initial use. >=20 > So to express this in RFC terms, TLS PSK MUST be supported, > TLS .... SHOULD be supported, TLS ...... >=20 > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 24 07:48:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Nab-000129-JZ; Tue, 24 Jan 2006 07:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NaZ-00011y-PZ for syslog@megatron.ietf.org; Tue, 24 Jan 2006 07:48:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08553 for ; Tue, 24 Jan 2006 07:46:29 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Nk5-0000Q6-V5 for syslog@ietf.org; Tue, 24 Jan 2006 07:57:52 -0500 Received: from pc6 (1Cust227.tnt2.lnd4.gbr.da.uu.net [62.188.131.227]) by ranger.systems.pipex.net (Postfix) with SMTP id C1D63E000150; Tue, 24 Jan 2006 12:47:36 +0000 (GMT) Message-ID: <000801c620db$e8e842a0$0601a8c0@pc6> From: "Tom Petch" To: "Glenn Mansfield Keeni" References: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> <001601c61234$f7e335e0$0601a8c0@pc6> <43CEFB3A.4000806@cysols.com> <001001c61d9d$5a360b00$0601a8c0@pc6> <43D46CAA.8080403@cysols.com> Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt Date: Tue, 24 Jan 2006 12:46:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Glenn Mansfield Keeni" To: "Tom Petch" Cc: Sent: Monday, January 23, 2006 6:42 AM Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt > Tom, > Tom Petch wrote: > > Although these comments are a response to Glenn, I would appreciate others on > > the list reading and commenting on pp3-4 of the syslog-mib which describes > > syslog (nothing MIBby, honest) in terms I am struggling with, if only to say > > 'yes, that is exactly how I see syslog being used'. > > > > Recall that IESG tends to require a MIB to allow protocols to advance so unless > > we agree on a MIB, we may not have a syslog-protocol:-( > > > > Glenn > > > > Ok so far but ...:-) > > you talk of 'receiving and forwarding syslog messages', that is of relay and > > collector in syslog-protocol terms; what about sender? Do you envisage any use > > of this MIB for an entity that is only involved in sending packets conforming to > > syslog-protocol? > Hmm. I do not envisage the MIB being used for a pure sender. The Syslog daemon is > the target. > > > > And when the document talks of receiving messages, are these messages ones that > > conform to syslog-protocol or does it include messages in a proprietary format > > that may or may not be emitted as syslog-protocol messages? > In the text "message" denotes "Syslog Message". I will add a sentence clarifying > that. > > > > And when this document talks of this being used to manage a group of syslog > > devices, what makes this a group? Are they all running under the same instance > > of an operating system (allowing sysplex as a single operating system)? If not, > > what makes it a group? > It means that there may be more than one Syslog daemons running on different ports > /network addresses. The grouping is a feature not a necessaity. I think that it is > providing flexibility that will be needed. Am I missing something here ? > > > > Tom Petch > > Glenn Getting there; recall that my initial problem is one of understanding what it is the MIB caters for. I had expected the MIB to cater for a pure Sender, in order to configure it with where to send what, and I am slightly suprised at that omission. As ever, it is a question of reaching rough consensus on questions like this. Likewise, grouping is not something I am familiar with, seeing rather a single Collector with proprietary features behind it to filter, disseminate etc. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 25 15:25:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1rCa-0005Su-BG; Wed, 25 Jan 2006 15:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1rCZ-0005SE-38 for syslog@megatron.ietf.org; Wed, 25 Jan 2006 15:25:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20656 for ; Wed, 25 Jan 2006 15:23:39 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1rMJ-0000Mt-Vs for syslog@ietf.org; Wed, 25 Jan 2006 15:35:20 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2006 12:24:57 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0PKOvWG012830; Wed, 25 Jan 2006 12:24:57 -0800 (PST) Date: Wed, 25 Jan 2006 12:24:57 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: hartmans-ietf@mit.edu Subject: [Syslog] Threat model requirements discussion X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Folks, We need to back up a moment and formalize our thoughts on the threats that we are going to address to "secure" syslog messages. We need to have this discussion to ensure that any mechanism we decide to provide will address the threats. The summary of our discussion will likely be included in syslog-transport-(secure) to show our objective and how the mechanism meets it. >From the prior discussions, it looks like the primary threats to current syslog messages are: - message observation - message tampering, injection, replay - message loss If these are the threats (please respond to the list if you don't agree), then we can deploy the following mechanisms to thwart them: - message encryption at the transport layer will prevent observation - transport layer encryption with a sufficient message authentication check (mac) mechanism will allow a receiver to detect attemps of tampering, injection and replay - transport layer encryption will provide seqenced delivery of messages in transit Is this sufficient for our needs? Does the possibility of message loss due to network unavailability need to be addressed at this time? This will be addressed in syslog-sign, but do we need an additional mechanism (such as the required use of the eventID SD-ID) to ensure that messages generated but not delivered are detected by the receiver? If we can agree that these are the threats, and mechanisms that will thwart them, then we can finalize our discussion on a transport layer service and add that to our charter. Please respond to the list with your thoughts. We need responses to this to make sure that we're on the right track with this discussion. Please keep Sam cc'd on this thread. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 26 00:44:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1zvv-0003Xj-4P; Thu, 26 Jan 2006 00:44:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1zvt-0003Xb-1J for syslog@megatron.ietf.org; Thu, 26 Jan 2006 00:44:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12606 for ; Thu, 26 Jan 2006 00:43:01 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F205i-00068f-8W for syslog@ietf.org; Thu, 26 Jan 2006 00:54:46 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k0Q5hwXj011131; Thu, 26 Jan 2006 14:43:58 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k0Q5hu5x001927; Thu, 26 Jan 2006 14:43:58 +0900 (JST) Message-ID: <43D8619C.5090302@cysols.com> Date: Thu, 26 Jan 2006 14:43:56 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt References: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> <001601c61234$f7e335e0$0601a8c0@pc6> <43CEFB3A.4000806@cysols.com> <001001c61d9d$5a360b00$0601a8c0@pc6> <43D46CAA.8080403@cysols.com> <000801c620db$e8e842a0$0601a8c0@pc6> In-Reply-To: <000801c620db$e8e842a0$0601a8c0@pc6> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, > > > Getting there; recall that my initial problem is one of understanding what it is > the MIB caters for. I had expected the MIB to cater for a pure Sender, in order > to configure it with where to send what, and I am slightly suprised at that > omission. As ever, it is a question of reaching rough consensus on questions > like this. Right. I will reword the answer. The MIB serves to monitor entities that receive and/or forward syslog messages e.g. the unix syslog daemon. Note that the MIB allows us to monitor all the syslog messages even if we do not monitor senders. [There is nothing in the MIB that prohibits one from monitoring the senders for syslog messages, but it is better done by monitoring the entity that receives syslog messages (from multiple entities) and forwards some of those messages]. > > Likewise, grouping is not something I am familiar with, seeing rather a single > Collector with proprietary features behind it to filter, disseminate etc. We are focussing on the simple and primary task of monitoring syslog messages from syslog entities. The MIB will support several syslog daemons which are probably using various transports (UDP{4|6}, TCP{4|6}, on standard and non-standard ports.). This situation does arise in practice. I think that the MIB does take care of that nicely using the concept of grouping. One good way to look at the MIB is as a collection of knobs and dials. Then we can ask a. Do we need another knob or another dial b. Do we need this knob or that dial > > Tom Petch > Cheers Glenn -- +----------------------------------------------------------+ Cyber Solutions Inc. Phone 022-303-4012 6-6-3, Minami Yoshinari Fax 022-303-4015 Aoba-ku, Sendai, Japan 989-3204 e-mail cyber@cysols.com +----------------------------------------------------------+ _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 26 08:36:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27IK-0004N7-M2; Thu, 26 Jan 2006 08:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27IJ-0004M3-25 for syslog@megatron.ietf.org; Thu, 26 Jan 2006 08:36:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14269 for ; Thu, 26 Jan 2006 08:34:39 -0500 (EST) Received: from bay115-dav18.bay115.hotmail.com ([65.54.250.90] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F27SF-0003x3-Ft for syslog@ietf.org; Thu, 26 Jan 2006 08:46:28 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Jan 2006 05:35:59 -0800 Message-ID: Received: from 24.99.144.45 by BAY115-DAV18.phx.gbl with DAV; Thu, 26 Jan 2006 13:35:59 +0000 X-Originating-IP: [24.99.144.45] X-Originating-Email: [whiz100@hotmail.com] X-Sender: whiz100@hotmail.com User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Thu, 26 Jan 2006 08:35:58 -0500 From: Peter Hall To: Chris Lonvick Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jan 2006 13:35:59.0493 (UTC) FILETIME=[715EC350:01C6227D] X-Spam-Score: 1.7 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: [Syslog] Reliable syslog - rfc 3195 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hello Chris I keep hearing that rfc3195 is being depreciated or has been already, apparently because of some problems with the standard ( Which I haven't seen ). Can you or anyone else here please tell me what is correct. I'm have been developing a rfc3195 compliant server and client tools and I really don't want to waste my time if it's going to disappear. Thanks Peter _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 26 09:52:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F28US-0006if-TF; Thu, 26 Jan 2006 09:52:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F28NV-0004y1-45 for syslog@megatron.ietf.org; Thu, 26 Jan 2006 09:45:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21537 for ; Thu, 26 Jan 2006 09:44:05 -0500 (EST) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F28XT-0006wl-GJ for syslog@ietf.org; Thu, 26 Jan 2006 09:55:55 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITP00MHXFHXCP@usaga01-in.huawei.com> for syslog@ietf.org; Thu, 26 Jan 2006 06:41:57 -0800 (PST) Received: from huawei.com (usams01-in [172.18.4.10]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITP005IWFHW4F@usaga01-in.huawei.com> for syslog@ietf.org; Thu, 26 Jan 2006 06:41:57 -0800 (PST) Received: from [172.24.1.6] (Forwarded-For: [219.234.180.253]) by usams01-in.huawei.com (mshttpd); Thu, 26 Jan 2006 09:46:29 -0500 Date: Thu, 26 Jan 2006 09:46:29 -0500 From: HarringtonDavid 73653 Subject: [Syslog] Threat model requirements discussion To: syslog@ietf.org Message-id: <9251b98bd8.98bd89251b@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 26 Jan 2006 09:52:47 -0500 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Since syslog and snmp are both IETF standards for network management, I think it would be beneficial to consider the same set of security requirements. The set of requirements in RFC3411 have undergone signficant review within the IETF, and especially within the security community of the IETF. Therefore I recommend that the syslog WG consider the threats described in RFC3411, section 1.4. It is possible the requirements will be different for syslog than for snmp, but it would be good to discuss the requirements in similar terms so operators can understand how to balance the security properties, and mitigate the security threats, of the two protocols when used within the same system. >From RFC3411: 1.4. Security Requirements of this Architecture Several of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to any Security Model used in an SNMP Management Framework. Other threats are not applicable to the management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which any Security Model used within this architecture SHOULD provide protection are: Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object. Masquerade The masquerade threat is the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal that has the appropriate authorizations. Secondary threats against which any Security Model used within this architecture SHOULD provide protection are: Message Stream Modification The SNMP protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations. Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines. Protecting against this threat may be required as a matter of local policy. There are at least two threats against which a Security Model within this architecture need not protect, since they are deemed to be of lesser importance in this context: Denial of Service A Security Model need not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable management protocol must cope as a matter of course. Traffic Analysis A Security Model need not attempt to address traffic analysis attacks. Many traffic patterns are predictable - entities may be managed on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis. David Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 26 13:26:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BpA-0004HT-BN; Thu, 26 Jan 2006 13:26:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bp6-0004H6-M5 for syslog@megatron.ietf.org; Thu, 26 Jan 2006 13:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12384 for ; Thu, 26 Jan 2006 13:24:48 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Bz6-0000QO-9w for syslog@ietf.org; Thu, 26 Jan 2006 13:36:40 -0500 Received: from pc6 (1Cust119.tnt29.lnd3.gbr.da.uu.net [62.188.120.119]) by ranger.systems.pipex.net (Postfix) with SMTP id 4013EE0002A9; Thu, 26 Jan 2006 18:25:54 +0000 (GMT) Message-ID: <025201c6229d$7d2319a0$0601a8c0@pc6> From: "Tom Petch" To: "Glenn Mansfield Keeni" References: <577465F99B41C842AAFBE9ED71E70ABA0E416E@grfint2.intern.adiscon.com> <001601c61234$f7e335e0$0601a8c0@pc6> <43CEFB3A.4000806@cysols.com> <001001c61d9d$5a360b00$0601a8c0@pc6> <43D46CAA.8080403@cysols.com> <000801c620db$e8e842a0$0601a8c0@pc6> <43D8619C.5090302@cysols.com> Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt Date: Thu, 26 Jan 2006 18:17:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Understand; the knob and dial I was expecting to see and do not was for the Sender. I was expecting to be able to configure the Sender with where to send what, what severity levels and such like. Also, I was expecting to see statistics from the Sender's point of view. This is an insecure, unreliable transport (UDP) so knowing what made it to the Collector is only half the story; what left the Sender would tell us what did not make it or what got spoofed. I will shut up for the time being and see if any one else chips in. I do have some comments on the SMI but that can wait until this is resolved. Tom Petch ----- Original Message ----- From: "Glenn Mansfield Keeni" To: "Tom Petch" Cc: Sent: Thursday, January 26, 2006 6:43 AM Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt > Tom, > > > > > > Getting there; recall that my initial problem is one of understanding what it is > > the MIB caters for. I had expected the MIB to cater for a pure Sender, in order > > to configure it with where to send what, and I am slightly suprised at that > > omission. As ever, it is a question of reaching rough consensus on questions > > like this. > > Right. I will reword the answer. > The MIB serves to monitor entities that receive and/or forward syslog messages > e.g. the unix syslog daemon. > Note that the MIB allows us to monitor all the syslog messages even if we do not > monitor senders. [There is nothing in the MIB that prohibits one from monitoring > the senders for syslog messages, but it is better done by monitoring the entity > that receives syslog messages (from multiple entities) and forwards some of those > messages]. > > > > Likewise, grouping is not something I am familiar with, seeing rather a single > > Collector with proprietary features behind it to filter, disseminate etc. > > We are focussing on the simple and primary task of monitoring syslog messages from > syslog entities. The MIB will support several syslog daemons which are probably using > various transports (UDP{4|6}, TCP{4|6}, on standard and non-standard ports.). This > situation does arise in practice. I think that the MIB does take care of that nicely > using the concept of grouping. > > One good way to look at the MIB is as a collection of knobs and dials. Then we can > ask > a. Do we need another knob or another dial > b. Do we need this knob or that dial > > > > Tom Petch > > > > Cheers > > Glenn > > > -- > +----------------------------------------------------------+ > Cyber Solutions Inc. Phone 022-303-4012 > 6-6-3, Minami Yoshinari Fax 022-303-4015 > Aoba-ku, Sendai, Japan 989-3204 e-mail cyber@cysols.com > +----------------------------------------------------------+ > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 26 13:26:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BpB-0004Hz-4g; Thu, 26 Jan 2006 13:26:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bp6-0004H7-M5 for syslog@megatron.ietf.org; Thu, 26 Jan 2006 13:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12385 for ; Thu, 26 Jan 2006 13:24:48 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Bz6-0000Q9-A0 for syslog@ietf.org; Thu, 26 Jan 2006 13:36:40 -0500 Received: from pc6 (1Cust119.tnt29.lnd3.gbr.da.uu.net [62.188.120.119]) by ranger.systems.pipex.net (Postfix) with SMTP id 326D9E0002BB; Thu, 26 Jan 2006 18:25:50 +0000 (GMT) Message-ID: <025101c6229d$7a8cde60$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Threat model requirements discussion Date: Thu, 26 Jan 2006 18:10:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Chris Lonvick" To: Cc: Sent: Wednesday, January 25, 2006 9:24 PM Subject: [Syslog] Threat model requirements discussion > Hi Folks, > > We need to back up a moment and formalize our thoughts on the threats that we > are going to address to "secure" syslog messages. We need to have this > discussion to ensure that any mechanism we decide to provide will address the > threats. The summary of our discussion will likely be included in > syslog-transport-(secure) to show our objective and how the mechanism > meets it. > > >From the prior discussions, it looks like the primary threats to current syslog > messages are: > > - message observation > - message tampering, injection, replay > - message loss > > If these are the threats (please respond to the list if you don't agree), > then we can deploy the following mechanisms to thwart them: > - message encryption at the transport layer will prevent observation > - transport layer encryption with a sufficient message authentication > check (mac) mechanism will allow a receiver to detect attemps of > tampering, injection and replay > - transport layer encryption will provide seqenced delivery of messages > in transit > > Is this sufficient for our needs? > I disagree. I think this list of threats is excessive. As I have said before, I regard integrity and message origin authentication as the needs, with modification and spoofing as the threats. I do not see observation as a problem and although others have said it is, noone has given an example of a syslog message that is so significant that it must be kept secret. Doubtless someone will produce some but I doubt I will ever be convinced that it is as important as the first two threats I mention. The logical conclusion of your approach is that what we need is encryption, encryption and encryption, and oh, we could throw in a little MAC here and there. I think this makes it too complex, too costly with the result that the security that is needed, and could be provided more simply, will not happen. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 26 13:40:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2C2Q-0003Y3-BB; Thu, 26 Jan 2006 13:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2C2N-0003XE-U9 for syslog@megatron.ietf.org; Thu, 26 Jan 2006 13:40:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13780 for ; Thu, 26 Jan 2006 13:38:32 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2CCM-00012C-8a for syslog@ietf.org; Thu, 26 Jan 2006 13:50:24 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2006 10:39:52 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0QIdhjt005845; Thu, 26 Jan 2006 10:39:47 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Jan 2006 13:39:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Threat model requirements discussion Date: Thu, 26 Jan 2006 13:39:42 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122FF50F1@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Threat model requirements discussion Thread-Index: AcYipll1QE+Bu+13QEGGFov5EJmoWAAAPkoA From: "Anton Okmianski \(aokmians\)" To: "Tom Petch" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 26 Jan 2006 18:39:43.0732 (UTC) FILETIME=[DFDCF340:01C622A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I second Tom's opinion. I think we should not preclude the use of transport that supports = encryption, but I don't think it is as high a priority as integrity and = authentication of origin. Certainly, there should be an option of not = incurring encryption overhead when all you need is integrity and = authentication.=20 Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Thursday, January 26, 2006 12:11 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Cc: hartmans-ietf@mit.edu > Subject: Re: [Syslog] Threat model requirements discussion >=20 > ----- Original Message ----- > From: "Chris Lonvick" > To: > Cc: > Sent: Wednesday, January 25, 2006 9:24 PM > Subject: [Syslog] Threat model requirements discussion >=20 >=20 > > Hi Folks, > > > > We need to back up a moment and formalize our thoughts on=20 > the threats=20 > > that we are going to address to "secure" syslog messages. =20 > We need to=20 > > have this discussion to ensure that any mechanism we decide=20 > to provide=20 > > will address the threats. The summary of our discussion=20 > will likely=20 > > be included in > > syslog-transport-(secure) to show our objective and how the=20 > mechanism=20 > > meets it. > > > > >From the prior discussions, it looks like the primary threats to=20 > > >current > syslog > > messages are: > > > > - message observation > > - message tampering, injection, replay > > - message loss > > > > If these are the threats (please respond to the list if you don't=20 > > agree), then we can deploy the following mechanisms to thwart them: > > - message encryption at the transport layer will prevent=20 > observation > > - transport layer encryption with a sufficient message=20 > authentication > > check (mac) mechanism will allow a receiver to detect=20 > attemps of > > tampering, injection and replay > > - transport layer encryption will provide seqenced=20 > delivery of messages > > in transit > > > > Is this sufficient for our needs? > > >=20 > I disagree. I think this list of threats is excessive. >=20 > As I have said before, I regard integrity and message origin=20 > authentication as the needs, with modification and spoofing=20 > as the threats. I do not see observation as a problem and=20 > although others have said it is, noone has given an example=20 > of a syslog message that is so significant that it must be=20 > kept secret. > Doubtless someone will produce some but I doubt I will ever=20 > be convinced that it is as important as the first two threats=20 > I mention. >=20 > The logical conclusion of your approach is that what we need=20 > is encryption, encryption and encryption, and oh, we could=20 > throw in a little MAC here and there. I think this makes it=20 > too complex, too costly with the result that the security=20 > that is needed, and could be provided more simply, will not happen. >=20 > Tom Petch >=20 > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 26 15:08:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DQM-0003tG-RF; Thu, 26 Jan 2006 15:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DQJ-0003s1-RS for syslog@megatron.ietf.org; Thu, 26 Jan 2006 15:08:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21175 for ; Thu, 26 Jan 2006 15:07:19 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2DaI-0004Cd-6i for syslog@ietf.org; Thu, 26 Jan 2006 15:19:13 -0500 Subject: Re: [Syslog] Threat model requirements discussion From: Balazs Scheidler To: Tom Petch In-Reply-To: <025101c6229d$7a8cde60$0601a8c0@pc6> References: <025101c6229d$7a8cde60$0601a8c0@pc6> Content-Type: text/plain Date: Thu, 26 Jan 2006 21:08:28 +0100 Message-Id: <1138306108.9863.27.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-01-26 at 18:10 +0100, Tom Petch wrote: > I disagree. I think this list of threats is excessive. > > As I have said before, I regard integrity and message origin authentication as > the needs, with modification and spoofing as the threats. I do not see > observation as a problem and although others have said it is, noone has given an > example of a syslog message that is so significant that it must be kept secret. > Doubtless someone will produce some but I doubt I will ever be convinced that it > is as important as the first two threats I mention. Application Layer firewall logs may contain sensitive information such as passwords, especially when running at a high log level. Lots of people are using syslog-ng with stunnel for similar reasons now. So maybe we should consider both schemes: authenticating the origin of each message _AND_ standardizing encrypted transport. I vote for encrypted transport but there might be enough support for the first one as well. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 29 21:11:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OWD-0004Bb-7k; Sun, 29 Jan 2006 21:11:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OVy-0004AT-Ca for syslog@megatron.ietf.org; Sun, 29 Jan 2006 21:11:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17597 for ; Sun, 29 Jan 2006 21:09:50 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3OgV-0003EI-KR for syslog@ietf.org; Sun, 29 Jan 2006 21:22:28 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 29 Jan 2006 18:11:17 -0800 X-IronPort-AV: i="4.01,231,1136188800"; d="scan'208"; a="1771355813:sNHT29021368" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0U2BEju008162; Sun, 29 Jan 2006 18:11:15 -0800 (PST) Date: Sun, 29 Jan 2006 18:11:14 -0800 (PST) From: Chris Lonvick To: Balazs Scheidler Subject: Re: [Syslog] Threat model requirements discussion In-Reply-To: <1138306108.9863.27.camel@bzorp.balabit> Message-ID: References: <025101c6229d$7a8cde60$0601a8c0@pc6> <1138306108.9863.27.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: hartmans-ietf@mit.edu, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Bazsi, Would you look at the section of RFC3411 that David Harrington forwarded and put those sections in a priority order as you see they would apply to syslog? Thanks, Chris On Thu, 26 Jan 2006, Balazs Scheidler wrote: > On Thu, 2006-01-26 at 18:10 +0100, Tom Petch wrote: > >> I disagree. I think this list of threats is excessive. >> >> As I have said before, I regard integrity and message origin authentication as >> the needs, with modification and spoofing as the threats. I do not see >> observation as a problem and although others have said it is, noone has given an >> example of a syslog message that is so significant that it must be kept secret. >> Doubtless someone will produce some but I doubt I will ever be convinced that it >> is as important as the first two threats I mention. > > Application Layer firewall logs may contain sensitive information such > as passwords, especially when running at a high log level. > > Lots of people are using syslog-ng with stunnel for similar reasons now. > > So maybe we should consider both schemes: authenticating the origin of > each message _AND_ standardizing encrypted transport. I vote for > encrypted transport but there might be enough support for the first one > as well. > > -- > Bazsi > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 29 21:12:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OWX-0004GU-HG; Sun, 29 Jan 2006 21:12:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OWW-0004Fu-UT for syslog@megatron.ietf.org; Sun, 29 Jan 2006 21:12:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17627 for ; Sun, 29 Jan 2006 21:10:33 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3OhB-0003Fa-Ou for syslog@ietf.org; Sun, 29 Jan 2006 21:23:11 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Jan 2006 18:11:58 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0U2BvKU029782; Sun, 29 Jan 2006 18:11:57 -0800 (PST) Date: Sun, 29 Jan 2006 18:11:57 -0800 (PST) From: Chris Lonvick To: Peter Hall In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: syslog@ietf.org Subject: [Syslog] Re: Reliable syslog - rfc 3195 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Peter, On Thu, 26 Jan 2006, Peter Hall wrote: > > > Hello Chris > > I keep hearing that rfc3195 is being depreciated or has been already, > apparently because of some problems with the standard ( Which I haven't seen > ). Can you or anyone else here please tell me what is correct. I'm have been > developing a rfc3195 compliant server and client tools and I really don't > want to waste my time if it's going to disappear. RFC 3195 has not been deprecated. It is currently a Proposed Standard. First we need to get syslog-protocol out and implementations should incorporate that. Once we have some interoperable implementations of that we can advance it to a Draft Standard by generating an implementation report and a revision. Implementaters such as yourself should start tracking a list of things that need to be addressed in a revision (length has been noted). I have spoken to a person who has a very good working knowledge of BEEP. He is willing to undertake a revision of RFC 3195 if he can find a co-author who is implementing. Again, let's get syslog-protocol out the door first. :) Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 29 21:33:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OrG-0007jP-L0; Sun, 29 Jan 2006 21:33:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OrF-0007jG-G7 for syslog@megatron.ietf.org; Sun, 29 Jan 2006 21:33:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18876 for ; Sun, 29 Jan 2006 21:31:57 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3P1v-0003ny-Fb for syslog@ietf.org; Sun, 29 Jan 2006 21:44:35 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 29 Jan 2006 18:33:19 -0800 X-IronPort-AV: i="4.01,231,1136188800"; d="scan'208"; a="398084157:sNHT29778592" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0U2XIKU007921; Sun, 29 Jan 2006 18:33:18 -0800 (PST) Date: Sun, 29 Jan 2006 18:33:17 -0800 (PST) From: Chris Lonvick To: Tom Petch Subject: Re: [Syslog] Threat model requirements discussion In-Reply-To: <025101c6229d$7a8cde60$0601a8c0@pc6> Message-ID: References: <025101c6229d$7a8cde60$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Tom, I see your points. It appears that the section of RFC3411 that David Harrington sent around agrees with your analysis for SNMP. However, as Baszi says, devices are using encryption for syslog for what is considered to be sensitive information when high levels of debugging are enabled. How would you address that? Thanks, Chris On Thu, 26 Jan 2006, Tom Petch wrote: > ----- Original Message ----- > From: "Chris Lonvick" > To: > Cc: > Sent: Wednesday, January 25, 2006 9:24 PM > Subject: [Syslog] Threat model requirements discussion > > >> Hi Folks, >> >> We need to back up a moment and formalize our thoughts on the threats that we >> are going to address to "secure" syslog messages. We need to have this >> discussion to ensure that any mechanism we decide to provide will address the >> threats. The summary of our discussion will likely be included in >> syslog-transport-(secure) to show our objective and how the mechanism >> meets it. >> >>> From the prior discussions, it looks like the primary threats to current > syslog >> messages are: >> >> - message observation >> - message tampering, injection, replay >> - message loss >> >> If these are the threats (please respond to the list if you don't agree), >> then we can deploy the following mechanisms to thwart them: >> - message encryption at the transport layer will prevent observation >> - transport layer encryption with a sufficient message authentication >> check (mac) mechanism will allow a receiver to detect attemps of >> tampering, injection and replay >> - transport layer encryption will provide seqenced delivery of messages >> in transit >> >> Is this sufficient for our needs? >> > > I disagree. I think this list of threats is excessive. > > As I have said before, I regard integrity and message origin authentication as > the needs, with modification and spoofing as the threats. I do not see > observation as a problem and although others have said it is, noone has given an > example of a syslog message that is so significant that it must be kept secret. > Doubtless someone will produce some but I doubt I will ever be convinced that it > is as important as the first two threats I mention. > > The logical conclusion of your approach is that what we need is encryption, > encryption and encryption, and oh, we could throw in a little MAC here and > there. I think this makes it too complex, too costly with the result that the > security that is needed, and could be provided more simply, will not happen. > > Tom Petch > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 30 06:15:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3X0E-0002JG-MW; Mon, 30 Jan 2006 06:15:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3X0C-0002I5-GE for syslog@megatron.ietf.org; Mon, 30 Jan 2006 06:15:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14625 for ; Mon, 30 Jan 2006 06:13:39 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3XAq-0008OS-A9 for syslog@ietf.org; Mon, 30 Jan 2006 06:26:21 -0500 Subject: Re: [Syslog] Threat model requirements discussion From: Balazs Scheidler To: HarringtonDavid 73653 In-Reply-To: <9251b98bd8.98bd89251b@huawei.com> References: <9251b98bd8.98bd89251b@huawei.com> Content-Type: text/plain Date: Mon, 30 Jan 2006 12:14:54 +0100 Message-Id: <1138619694.6570.26.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I tried to create a prioritized list of threats, however as I see we have separate threats that affect the hop-by-hop nature of syslog (which is not present in SNMP, AFAIK) and the messages itself. So the list of threats is doubled: a threat can be affecting a single sender and each message of that sender (per-message threats), and a threat can affect the hop-by-hop link between two relays where the information sent by multiple senders are "merged". Primary threats: ---------------- * modification of information while transported from one relay to the next (integrity checking, hop-by-hop) * disclosure of information while transported from one relay to the next (encryption, hop-by-hop) * masquerading as an information sender while transported from one relay to the next (authenticity checking, hop-by-hop) Secondary threats: ------------------ * modification of information while it traverses multiple relays (integrity checking, per-message) * masquerading as an information sender while the message traverses multiple relays (authenticity checking, per-message) * message stream modification for an individual sender (reordering and replay, per-message) * message stream modification while messages are being transported from one relay to the next (reordering and replay, hop-by-hop) Less important threats: ----------------------- * DoS * Traffic Analysis My rationale of giving more importance to hop-by-hop threats is that it is easier to build a syslog infrastructure which does hop-by-hop encryption/integrity/authenticity than one which expects _ALL_ sending devices to sign messages. And additionally a dedicated syslog infrastructure can already be trusted enough not to modify in-transit messages which makes per-message authenticity less important. My vision is as follows: legacy syslog device -> encryption capable relay -> log center where the encryption capable relay is close to the syslog source, so that the link between them can be trusted (e.g. possibly dedicated local LAN), and the encryption capable relay can use all nifty crypto stuff to make sure that the center receives what it originally received. And one last note: I've put message stream modification to the secondary group, even though I know that any decent crypto transport layer is capable of eliminating this threat. On Thu, 2006-01-26 at 09:46 -0500, HarringtonDavid 73653 wrote: > Hi, > > Since syslog and snmp are both IETF standards for network management, I think it would be beneficial to consider the same set of security requirements. The set of requirements in RFC3411 have undergone signficant review within the IETF, and especially within the security community of the IETF. Therefore I recommend that the syslog WG consider the threats described in RFC3411, section 1.4. > > It is possible the requirements will be different for syslog than for snmp, but it would be good to discuss the requirements in similar terms so operators can understand how to balance the security properties, and mitigate the security threats, of the two protocols when used within the same system. > > >From RFC3411: > 1.4. Security Requirements of this Architecture > > Several of the classical threats to network protocols are applicable > to the management problem and therefore would be applicable to any > Security Model used in an SNMP Management Framework. Other threats > are not applicable to the management problem. This section discusses > principal threats, secondary threats, and threats which are of lesser > importance. > > The principal threats against which any Security Model used within > this architecture SHOULD provide protection are: > > Modification of Information > The modification threat is the danger that some unauthorized > entity may alter in-transit SNMP messages generated on behalf > of an authorized principal in such a way as to effect > unauthorized management operations, including falsifying the > value of an object. > Masquerade > The masquerade threat is the danger that management operations > not authorized for some principal may be attempted by assuming > the identity of another principal that has the appropriate > authorizations. > > Secondary threats against which any Security Model used within this > architecture SHOULD provide protection are: > > Message Stream Modification > The SNMP protocol is typically based upon a connectionless > transport service which may operate over any subnetwork > service. The re-ordering, delay or replay of messages can and > does occur through the natural operation of many such > subnetwork services. The message stream modification threat is > the danger that messages may be maliciously re-ordered, delayed > or replayed to an extent which is greater than can occur > through the natural operation of a subnetwork service, in order > to effect unauthorized management operations. > > Disclosure > The disclosure threat is the danger of eavesdropping on the > exchanges between SNMP engines. Protecting against this threat > may be required as a matter of local policy. > > There are at least two threats against which a Security Model within > this architecture need not protect, since they are deemed to be of > lesser importance in this context: > > Denial of Service > A Security Model need not attempt to address the broad range of > attacks by which service on behalf of authorized users is > denied. Indeed, such denial-of-service attacks are in many > cases indistinguishable from the type of network failures with > which any viable management protocol must cope as a matter of > course. > > Traffic Analysis > A Security Model need not attempt to address traffic analysis > attacks. Many traffic patterns are predictable - entities may > be managed on a regular basis by a relatively small number of > management stations - and therefore there is no significant > advantage afforded by protecting against traffic analysis. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 30 09:40:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3aCr-0004TP-Qr; Mon, 30 Jan 2006 09:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3aCq-0004TA-VE for syslog@megatron.ietf.org; Mon, 30 Jan 2006 09:40:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27542 for ; Mon, 30 Jan 2006 09:39:01 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3aNc-0005s3-Io for syslog@ietf.org; Mon, 30 Jan 2006 09:51:46 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2006013014402301400gbnsre>; Mon, 30 Jan 2006 14:40:23 +0000 From: "David B Harrington" To: "'Balazs Scheidler'" Subject: RE: [Syslog] Threat model requirements discussion Date: Mon, 30 Jan 2006 09:40:16 -0500 Message-ID: <007301c625ab$171a6940$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYljwAqnsaA53XBTlOTeFg9lkiyiwAFgZvw In-Reply-To: <1138619694.6570.26.camel@bzorp.balabit> X-Spam-Score: 0.1 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Comments inline David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Balazs Scheidler > Sent: Monday, January 30, 2006 6:15 AM > To: HarringtonDavid 73653 > Cc: syslog@ietf.org > Subject: Re: [Syslog] Threat model requirements discussion > > Hi, > > I tried to create a prioritized list of threats, however as I see we > have separate threats that affect the hop-by-hop nature of > syslog (which > is not present in SNMP, AFAIK) and the messages itself. First, let me try to clarify some terminology, since I find Balazs's terminology a little murky. In SNMP we make a distinction between the message and the PDU. The message is the complete message including the header and the content. The PDU is the content of the message. All SNMP messages have a hop-by-hop nature. Authentication and integrity-checking of the complete message is done on a hop-by-hop basis. A PDU can be passed on through a proxy - the PDU typically receives no processing at the proxy but is just forwarded between engines of the same SNMP version. There are "translating proxies" that do alter the PDU, when the message is being translated between versions of SNMP. When a proxy forwards a message, the message header for the incoming message is different than the message header for the outgoing message. For a message passing from A to B to C, the message header from A to B contains the necessary information to authenticate the security trust relationship between A and B. The message header from B to C contains the necessary information to authenticate the security trust relationship between B and C. Integrity checking is done using a digest created from the whole message, so the integrity-checking data also differs between A and B and between B and C. There is an assumption that A trusts B to not alter the PDU in undesirable ways. If A didn't trust B, then A wouldn't have a security trust relationship with B and send B the PDU in the first place. The same is true for B to A, B to C, and C to B, and so on. So every step between engines is a hop that gets authentication and integrity checking, whether the step is from the originator of the PDU to a proxy, between two intermediate proxies, or between a proxy and the final receiver of the PDU. (or between the originator of the PDU and the final receiver of the PDU, with no proxies in between). In SNMP, an engine that originates a message and an engine that receives a message is simply an engine. A proxy forwarder is an engine that is configured to both receive a message and originate a message for the purpose of forwarding the PDU. I assume this is roughly equivalent to the security relationships between syslog engines as well. > > So the list of threats is doubled: a threat can be affecting a single > sender and each message of that sender (per-message threats), and a > threat can affect the hop-by-hop link between two relays where the > information sent by multiple senders are "merged". > > Primary threats: > ---------------- > * modification of information while transported from one > relay to the next (integrity checking, hop-by-hop) > * disclosure of information while transported from one > relay to the next (encryption, hop-by-hop) > * masquerading as an information sender while transported > from one relay to the next (authenticity checking, hop-by-hop) > > > Secondary threats: > ------------------ > * modification of information while it traverses multiple > relays (integrity checking, per-message) > * masquerading as an information sender while the message > traverses multiple relays (authenticity checking, per-message) > * message stream modification for an individual sender > (reordering and replay, per-message) If the hop-by-hop transport of information checks integrity of the whole message, then it shouldn't be necessary to check the integrity of the message contents independently, should it? If a relay cannot be trusted to not alter the message contents in undesirable ways, why would an administrator utilize that relay in their system of relays for message transport? Can you give me an example of when such an untrustworthy relay would be used? > * message stream modification while messages are being transported > from one relay to the next (reordering and replay, hop-by-hop) > > Less important threats: > ----------------------- > * DoS > * Traffic Analysis > > My rationale of giving more importance to hop-by-hop threats is > that it is easier to build a syslog infrastructure which does > hop-by-hop encryption/integrity/authenticity than one which > expects _ALL_ sending devices to sign messages. And additionally > a dedicated syslog infrastructure can already be trusted enough > not to modify in-transit messages which makes per-message > authenticity less important. > > My vision is as follows: > > legacy syslog device -> encryption capable relay -> log center > > where the encryption capable relay is close to the syslog source, > so that the link between them can be trusted (e.g. possibly > dedicated local LAN), and the encryption capable relay can use > all nifty crypto stuff to make sure that the center receives > what it originally received. Let me observe that during the development of SNMPv3, the idea of having non-secure SNMPv1 engines in the system at all was anathema to some IAB members, even in the type of migratory scenario you describe. I personally think such a migratory approach for legacy devices is critical in the real world. > > And one last note: I've put message stream modification to the > secondary group, even though I know that any decent crypto > transport layer is capable of eliminating this threat. > > On Thu, 2006-01-26 at 09:46 -0500, HarringtonDavid 73653 wrote: > > Hi, > > > > Since syslog and snmp are both IETF standards for network > management, I think it would be beneficial to consider the > same set of security requirements. The set of requirements in > RFC3411 have undergone signficant review within the IETF, and > especially within the security community of the IETF. > Therefore I recommend that the syslog WG consider the threats > described in RFC3411, section 1.4. > > > > It is possible the requirements will be different for > syslog than for snmp, but it would be good to discuss the > requirements in similar terms so operators can understand how > to balance the security properties, and mitigate the security > threats, of the two protocols when used within the same system. > > > > >From RFC3411: > > 1.4. Security Requirements of this Architecture > > > > Several of the classical threats to network protocols > are applicable > > to the management problem and therefore would be > applicable to any > > Security Model used in an SNMP Management Framework. > Other threats > > are not applicable to the management problem. This > section discusses > > principal threats, secondary threats, and threats which > are of lesser > > importance. > > > > The principal threats against which any Security Model > used within > > this architecture SHOULD provide protection are: > > > > Modification of Information > > The modification threat is the danger that some > unauthorized > > entity may alter in-transit SNMP messages > generated on behalf > > of an authorized principal in such a way as to effect > > unauthorized management operations, including > falsifying the > > value of an object. > > Masquerade > > The masquerade threat is the danger that > management operations > > not authorized for some principal may be attempted > by assuming > > the identity of another principal that has the appropriate > > authorizations. > > > > Secondary threats against which any Security Model used > within this > > architecture SHOULD provide protection are: > > > > Message Stream Modification > > The SNMP protocol is typically based upon a connectionless > > transport service which may operate over any subnetwork > > service. The re-ordering, delay or replay of > messages can and > > does occur through the natural operation of many such > > subnetwork services. The message stream > modification threat is > > the danger that messages may be maliciously > re-ordered, delayed > > or replayed to an extent which is greater than can occur > > through the natural operation of a subnetwork > service, in order > > to effect unauthorized management operations. > > > > Disclosure > > The disclosure threat is the danger of eavesdropping on the > > exchanges between SNMP engines. Protecting > against this threat > > may be required as a matter of local policy. > > > > There are at least two threats against which a Security > Model within > > this architecture need not protect, since they are > deemed to be of > > lesser importance in this context: > > > > Denial of Service > > A Security Model need not attempt to address the > broad range of > > attacks by which service on behalf of authorized users is > > denied. Indeed, such denial-of-service attacks are in many > > cases indistinguishable from the type of network > failures with > > which any viable management protocol must cope as > a matter of > > course. > > > > Traffic Analysis > > A Security Model need not attempt to address > traffic analysis > > attacks. Many traffic patterns are predictable - > entities may > > be managed on a regular basis by a relatively > small number of > > management stations - and therefore there is no significant > > advantage afforded by protecting against traffic analysis. > > -- > Bazsi > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 30 19:56:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3jpD-0006Aw-EN; Mon, 30 Jan 2006 19:56:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3jpC-0006AQ-4M for syslog@megatron.ietf.org; Mon, 30 Jan 2006 19:56:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28332 for ; Mon, 30 Jan 2006 19:55:02 -0500 (EST) Received: from dsl254-102-222.nyc1.dsl.speakeasy.net ([216.254.102.222] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3jzr-0006KG-9T for syslog@ietf.org; Mon, 30 Jan 2006 20:07:52 -0500 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 4022921CC0 for ; Mon, 30 Jan 2006 19:56:25 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on gandalf.taltos.org X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.1.2] (unknown [192.168.1.2]) by gandalf.taltos.org (Postfix) with ESMTP id 327C621B73 for ; Mon, 30 Jan 2006 19:56:25 -0500 (EST) Date: Mon, 30 Jan 2006 19:56:22 -0500 From: Carson Gaspar To: syslog@ietf.org Subject: RE: [Syslog] Threat model requirements discussion Message-ID: <46AC2625F0F1980CA6D8743B@[192.168.1.2]> In-Reply-To: <007301c625ab$171a6940$0400a8c0@DJYXPY41> References: <007301c625ab$171a6940$0400a8c0@DJYXPY41> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --On Monday, January 30, 2006 9:40 AM -0500 David B Harrington wrote: > If the hop-by-hop transport of information checks integrity of the > whole message, then it shouldn't be necessary to check the integrity > of the message contents independently, should it? > > If a relay cannot be trusted to not alter the message contents in > undesirable ways, why would an administrator utilize that relay in > their system of relays for message transport? Can you give me an > example of when such an untrustworthy relay would be used? Simple - a formerly trusted relay becomes compromised. In a perfect world, this wouldn't happen. But in the real world, it does. Having the data authenticated by the origin reduces the threat to only the origin server. -- Carson _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 03:49:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rC9-0007Z5-Rh; Tue, 31 Jan 2006 03:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rC2-0007Ve-RS for syslog@megatron.ietf.org; Tue, 31 Jan 2006 03:49:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25734 for ; Tue, 31 Jan 2006 03:47:05 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3rMZ-0002F2-8A for syslog@ietf.org; Tue, 31 Jan 2006 04:00:00 -0500 Subject: RE: [Syslog] Threat model requirements discussion From: Balazs Scheidler To: Carson Gaspar In-Reply-To: <46AC2625F0F1980CA6D8743B@[192.168.1.2]> References: <007301c625ab$171a6940$0400a8c0@DJYXPY41> <46AC2625F0F1980CA6D8743B@[192.168.1.2]> Content-Type: text/plain Date: Tue, 31 Jan 2006 09:47:53 +0100 Message-Id: <1138697273.5005.7.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Mon, 2006-01-30 at 19:56 -0500, Carson Gaspar wrote: > > --On Monday, January 30, 2006 9:40 AM -0500 David B Harrington > wrote: > > > If the hop-by-hop transport of information checks integrity of the > > whole message, then it shouldn't be necessary to check the integrity > > of the message contents independently, should it? > > > > If a relay cannot be trusted to not alter the message contents in > > undesirable ways, why would an administrator utilize that relay in > > their system of relays for message transport? Can you give me an > > example of when such an untrustworthy relay would be used? > > Simple - a formerly trusted relay becomes compromised. In a perfect world, > this wouldn't happen. But in the real world, it does. Having the data > authenticated by the origin reduces the threat to only the origin server. And additionally, the syslog infrastructure can be a shared infrastructure that is managed by a different group in the organization. So the IT managers of end systems _might_ be interested in having their own security measures while still using the shared infrastructure. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 06:31:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tjd-0006Cz-Rc; Tue, 31 Jan 2006 06:31:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3tjb-0006Bc-EG for syslog@megatron.ietf.org; Tue, 31 Jan 2006 06:31:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07359 for ; Tue, 31 Jan 2006 06:29:58 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3tuN-0007eZ-Rz for syslog@ietf.org; Tue, 31 Jan 2006 06:42:53 -0500 Received: from pc6 (1Cust202.tnt103.lnd4.gbr.da.uu.net [213.116.54.202]) by astro.systems.pipex.net (Postfix) with SMTP id 8D0F4E0003BA; Tue, 31 Jan 2006 11:31:12 +0000 (GMT) Message-ID: <00ea01c62651$5e9a1300$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" References: <025101c6229d$7a8cde60$0601a8c0@pc6> Subject: Re: [Syslog] Threat model requirements discussion Date: Tue, 31 Jan 2006 11:28:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Chris Lonvick" To: "Tom Petch" Cc: ; Sent: Monday, January 30, 2006 3:33 AM Subject: Re: [Syslog] Threat model requirements discussion > Hi Tom, > > I see your points. It appears that the section of RFC3411 that David > Harrington sent around agrees with your analysis for SNMP. However, as > Baszi says, devices are using encryption for syslog for what is considered > to be sensitive information when high levels of debugging are enabled. > How would you address that? > > Thanks, > Chris > Chris I would not exclude encryption as a defence against message observation but would give it a lower priority, my experience suggests a much lower priority, than message origin authentication and integrity. My concern is that we end up with a solution whose complexity or cost makes it unsuitable for users whose needs would be satisfied by a simpler one, namely authentication and integrity without encryption - in technical terms, I see adding a keyed hash as more attractive than deploying SSH or TLS etc Any solution has some of the same issues - key distribution and maintenance - but what I am mindful of is that this is an event/notification system (and one-way at that) which reverses client and server roles compared to much of the rest of systems management. SNMPv3 solved this problem but in a way that users found unacceptable to implement; isms and netconf have yet to solve it, we have not yet begun to think about it. So I want to see a simpler solution - eg keyed hash - first and a more complex one which includes encryption as phase two (2007?). And yes, my views are coloured by SNMP which I have worked with for many years, where, as I have said before, users tell me they must have encryption but it usually turns out they have not yet learnt about the concept of differing threats. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 08:35:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3vf9-0006Ju-VK; Tue, 31 Jan 2006 08:35:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3vf4-0006Hj-96 for syslog@megatron.ietf.org; Tue, 31 Jan 2006 08:35:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16161 for ; Tue, 31 Jan 2006 08:33:21 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3vpm-0003Bs-RG for syslog@ietf.org; Tue, 31 Jan 2006 08:46:18 -0500 Subject: Re: [Syslog] Threat model requirements discussion From: Balazs Scheidler To: Tom Petch In-Reply-To: <00ea01c62651$5e9a1300$0601a8c0@pc6> References: <025101c6229d$7a8cde60$0601a8c0@pc6> <00ea01c62651$5e9a1300$0601a8c0@pc6> Content-Type: text/plain Date: Tue, 31 Jan 2006 14:34:43 +0100 Message-Id: <1138714483.5005.28.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-01-31 at 11:28 +0100, Tom Petch wrote: > So I want to see a simpler solution - eg keyed hash - first and a more complex > one which includes encryption as phase two (2007?). > > And yes, my views are coloured by SNMP which I have worked with for many years, > where, as I have said before, users tell me they must have encryption but it > usually turns out they have not yet learnt about the concept of differing > threats. My points: * syslog is way different than SNMP traps, it really does contain sensitive information (not just link up/down). * adding TLS is very simple from the implementation point of view: adding a new transport layer to the software stack does not really change the software (can be done without changing the software at all via a wrapper like stunnel), message signatures is a big change in _all_ senders * adding TLS is very simple from the protocol specification point of view: define a way to wrap messages to an "envelope" (e.g. NL termination, or byte counter) and wrap messages into TLS * adding message signatures is difficult both implementation and specification wise, syslog-sign is far from being simple I'd say that the specification and implementation something like syslog-sign is at least 3-5 times as big work as doing the same with a drop-in package like TLS. But I guess this is a yes/no argument so we have to come up with a decision. I would propose an agenda like: 1) syslog-protocol 2) syslog-protocol over TLS 3) message integrity/authenticity checking in syslog-protocol Or maybe even start work on 2) and 3) in parallel. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 08:44:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3voI-00007P-O0; Tue, 31 Jan 2006 08:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3voH-00006M-7m for syslog@megatron.ietf.org; Tue, 31 Jan 2006 08:44:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17032 for ; Tue, 31 Jan 2006 08:42:54 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3vyY-0003SW-Mx for syslog@ietf.org; Tue, 31 Jan 2006 08:55:52 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3454027C007 for ; Tue, 31 Jan 2006 14:36:41 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22472-02 for ; Tue, 31 Jan 2006 14:36:41 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E22EB27C006 for ; Tue, 31 Jan 2006 14:36:40 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 14:43:35 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Threat model requirements discussion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 31 Jan 2006 14:43:34 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E434D@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Threat model requirements discussion Thread-Index: AcYmbBDzmA+uFvmVTUuaA3TlPwn5FwAAC3ag From: "Rainer Gerhards" To: X-OriginalArrivalTime: 31 Jan 2006 13:43:35.0460 (UTC) FILETIME=[55368E40:01C6266C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org FWIW: I agree with Baszi in all points. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Balazs Scheidler > Sent: Tuesday, January 31, 2006 2:35 PM > To: Tom Petch > Cc: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: Re: [Syslog] Threat model requirements discussion >=20 > On Tue, 2006-01-31 at 11:28 +0100, Tom Petch wrote: >=20 > > So I want to see a simpler solution - eg keyed hash - first=20 > and a more complex > > one which includes encryption as phase two (2007?). > >=20 > > And yes, my views are coloured by SNMP which I have worked=20 > with for many years, > > where, as I have said before, users tell me they must have=20 > encryption but it > > usually turns out they have not yet learnt about the=20 > concept of differing > > threats. >=20 > My points: > * syslog is way different than SNMP traps, it really does contain > sensitive information (not just link up/down).=20 > * adding TLS is very simple from the implementation point of view: > adding a new transport layer to the software stack does not really > change the software (can be done without changing the software at all > via a wrapper like stunnel), message signatures is a big=20 > change in _all_ > senders > * adding TLS is very simple from the protocol specification point of > view: define a way to wrap messages to an "envelope" (e.g. NL > termination, or byte counter) and wrap messages into TLS > * adding message signatures is difficult both implementation and > specification wise, syslog-sign is far from being simple >=20 > I'd say that the specification and implementation something like > syslog-sign is at least 3-5 times as big work as doing the same with a > drop-in package like TLS. >=20 > But I guess this is a yes/no argument so we have to come up with a > decision. I would propose an agenda like: >=20 > 1) syslog-protocol > 2) syslog-protocol over TLS > 3) message integrity/authenticity checking in syslog-protocol >=20 > Or maybe even start work on 2) and 3) in parallel. >=20 > --=20 > Bazsi >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 12:51:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zfC-0003F2-8f; Tue, 31 Jan 2006 12:51:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zf6-0003Bl-C8 for syslog@megatron.ietf.org; Tue, 31 Jan 2006 12:51:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12649 for ; Tue, 31 Jan 2006 12:49:47 -0500 (EST) Received: from [66.114.247.47] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3zpz-0005dT-Nk for syslog@ietf.org; Tue, 31 Jan 2006 13:02:45 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E4B21E006A; Tue, 31 Jan 2006 12:51:08 -0500 (EST) To: "Tom Petch" Subject: Re: [Syslog] Threat model requirements discussion References: <025101c6229d$7a8cde60$0601a8c0@pc6> From: Sam Hartman Date: Tue, 31 Jan 2006 12:51:08 -0500 In-Reply-To: <025101c6229d$7a8cde60$0601a8c0@pc6> (Tom Petch's message of "Thu, 26 Jan 2006 18:10:35 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Tom" == Tom Petch writes: Tom> The logical conclusion of your approach is that what we need Tom> is encryption, encryption and encryption, and oh, we could Tom> throw in a little MAC here and there. I think this makes it Tom> too complex, too costly with the result that the security Tom> that is needed, and could be provided more simply, will not Tom> happen. I will say that encryption and macs are very easy to do and I think you'd need to show a strong argument that they will not perform well before performance concerns can be taken seriously. The question I really need answers to is: * Does the WG believe that Authentication of the origin of the message is a requirement for the mandatory to implement approach? * Does the WG believe that integrity protection independent of transport is a requirement for the mandatory to implement? I want these questions answered independent of particular choices about implementation complexity. Ultimately this comes down to Chris judging the consensus of the WG based on the discussion here. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 13:05:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zt4-0006zL-3a; Tue, 31 Jan 2006 13:05:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zt3-0006xo-4F for syslog@megatron.ietf.org; Tue, 31 Jan 2006 13:05:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13818 for ; Tue, 31 Jan 2006 13:04:17 -0500 (EST) Received: from [66.114.247.47] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4043-0006BL-08 for syslog@ietf.org; Tue, 31 Jan 2006 13:17:16 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2D7EDE006A; Tue, 31 Jan 2006 13:05:45 -0500 (EST) To: "Tom Petch" Subject: Re: [Syslog] Threat model requirements discussion References: <025101c6229d$7a8cde60$0601a8c0@pc6> <00ea01c62651$5e9a1300$0601a8c0@pc6> From: Sam Hartman Date: Tue, 31 Jan 2006 13:05:45 -0500 In-Reply-To: <00ea01c62651$5e9a1300$0601a8c0@pc6> (Tom Petch's message of "Tue, 31 Jan 2006 11:28:47 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, I'd like to ask you to give your requirements independent of any particular implementation biases. I'm trying to determine if the requirements match what the WG is able to implement. It doesn't help me do that when people keep mixing the two issues. I do completely understand that if we get impossible to implement requirements for our security solution then we'll have to go back and revisit something. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 13:32:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40Iw-0004ye-B9; Tue, 31 Jan 2006 13:32:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40In-0004wA-BO for syslog@megatron.ietf.org; Tue, 31 Jan 2006 13:32:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16034 for ; Tue, 31 Jan 2006 13:30:45 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F40Tf-00076g-LW for syslog@ietf.org; Tue, 31 Jan 2006 13:43:44 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2006 10:32:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,240,1136188800"; d="scan'208"; a="20885133:sNHT22575396" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0VIVd6V017839; Tue, 31 Jan 2006 13:32:04 -0500 (EST) 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.211); Tue, 31 Jan 2006 13:31:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Threat model requirements discussion Date: Tue, 31 Jan 2006 13:31:46 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201043A64@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Threat model requirements discussion Thread-Index: AcYmj+dcZ+WDqwO6TIGAUcaMfKEH/AAA3u2g From: "Anton Okmianski \(aokmians\)" To: "Sam Hartman" , "Tom Petch" X-OriginalArrivalTime: 31 Jan 2006 18:31:46.0827 (UTC) FILETIME=[97ABC5B0:01C62694] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org My personal opinion below. Not speaking for WG, of course.=20 > * Does the WG believe that Authentication of the origin of=20 > the message is a requirement for the mandatory to implement approach? Yes. =20 > * Does the WG believe that integrity protection independent=20 > of transport is a requirement for the mandatory to implement? I would guess this is where opinions may differ.=20 I think - yes, it is a requirement. Both integrity support in general = and its independence from transport. The latter extends protection = beyond transport (to storage for example) and allows to defer validation = till message is actually used if this is desired. =20 Thanks, Anton. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 13:36:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40Me-00065h-A6; Tue, 31 Jan 2006 13:36:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40Ma-00064b-Km for syslog@megatron.ietf.org; Tue, 31 Jan 2006 13:36:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16548 for ; Tue, 31 Jan 2006 13:34:40 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F40XS-0007JI-Es for syslog@ietf.org; Tue, 31 Jan 2006 13:47:40 -0500 Received: from pc6 (1Cust233.tnt109.lnd4.gbr.da.uu.net [62.188.172.233]) by astro.systems.pipex.net (Postfix) with SMTP id 8722DE000179; Tue, 31 Jan 2006 18:35:53 +0000 (GMT) Message-ID: <045201c6268c$b2053340$0601a8c0@pc6> From: "Tom Petch" To: "Balazs Scheidler" References: <025101c6229d$7a8cde60$0601a8c0@pc6> <00ea01c62651$5e9a1300$0601a8c0@pc6> <1138714483.5005.28.camel@bzorp.balabit> Subject: Re: [Syslog] Threat model requirements discussion Date: Tue, 31 Jan 2006 18:34:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Balazs Scheidler" To: "Tom Petch" Cc: "Chris Lonvick" ; ; Sent: Tuesday, January 31, 2006 2:34 PM Subject: Re: [Syslog] Threat model requirements discussion > On Tue, 2006-01-31 at 11:28 +0100, Tom Petch wrote: > > > So I want to see a simpler solution - eg keyed hash - first and a more complex > > one which includes encryption as phase two (2007?). > > > > And yes, my views are coloured by SNMP which I have worked with for many years, > > where, as I have said before, users tell me they must have encryption but it > > usually turns out they have not yet learnt about the concept of differing > > threats. > > My points: > * syslog is way different than SNMP traps, it really does contain > sensitive information (not just link up/down). > * adding TLS is very simple from the implementation point of view: > adding a new transport layer to the software stack does not really > change the software (can be done without changing the software at all > via a wrapper like stunnel), message signatures is a big change in _all_ > senders > * adding TLS is very simple from the protocol specification point of > view: define a way to wrap messages to an "envelope" (e.g. NL > termination, or byte counter) and wrap messages into TLS > * adding message signatures is difficult both implementation and > specification wise, syslog-sign is far from being simple > > I'd say that the specification and implementation something like > syslog-sign is at least 3-5 times as big work as doing the same with a > drop-in package like TLS. > Note that I did not say syslog-sign, just keyed hash, so it is misleading to estimate the implementation effort when we are debating requirements (even if a possible design which may or may not match the requirements already exists). The kind of issues that need solving with SSH and/or TLS - reliable transport needed, eg TCP; when is the connection established, when is it taken down? - what port is used? if SSH/TLS, how is syslog traffic differentiated? if not, will IANA grant yet another port (or ports as allowed by syslog MIB)? - with multiple flows, are they multiplexed over a single connection? - which end is SSH/TLS client, which server? client and server in security protocols have significant impact on what security credentials are stored where, what customisation is needed before the system can be used (do you allow an unattended hub to perform a leap of faith?) - what is the user to which these security credentials relate, particularly for authentication, how is the user identified? - is authorisation to use secure syslog required? - is another system needed to keep security credentials up to date, eg RADIUS? and so on and so forth. Keyed hash? many of these issues disappear (and it could be end-to-end security were that a requirement, none of those concerns about relays). syslog is precisely like SNMP traps when you look at the wish that some users express for encyption, namely both are a one way flow over a datagram transport with some application client out there somewhere:-) And as I said, these issues have been mulled over by isms and netconf and, a year or so on, there are no obvious solutions. TLS may allow you to use off the shelf modules to achieve a quick code package but, and SNMPv3 is the case study here, the code package is not enough, the system must be sufficiently easy to implement if we are going to see it used. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 31 14:48:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Ui-0002P7-EP; Tue, 31 Jan 2006 14:48:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41Uh-0002OP-Bl for syslog@megatron.ietf.org; Tue, 31 Jan 2006 14:48:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22557 for ; Tue, 31 Jan 2006 14:47:12 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F41fg-000206-0B for syslog@ietf.org; Tue, 31 Jan 2006 15:00:13 -0500 Received: from pc6 (1Cust213.tnt14.lnd4.gbr.da.uu.net [62.188.143.213]) by astro.systems.pipex.net (Postfix) with SMTP id 053C1E000087; Tue, 31 Jan 2006 19:48:34 +0000 (GMT) Message-ID: <052301c62696$d9a8b520$0601a8c0@pc6> From: "Tom Petch" To: "Sam Hartman" References: <025101c6229d$7a8cde60$0601a8c0@pc6> Subject: Re: [Syslog] Threat model requirements discussion Date: Tue, 31 Jan 2006 19:46:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > The question I really need answers to is: > > * Does the WG believe that Authentication of the origin of the message is a requirement for the mandatory to implement approach? > Yes, this is top of my list > > * Does the WG believe that integrity protection independent of transport is a requirement for the mandatory to implement? > No; integrity per se yes (comes second on my list), but integrity independent of transport, no (just nice to have) Tom Petch > > --Sam > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog