From syslog-bounces@lists.ietf.org Mon Apr 02 15:51:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSXr-0001Ww-Ky; Mon, 02 Apr 2007 15:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSXh-0001VI-NY; Mon, 02 Apr 2007 15:50:17 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSXS-0008Vz-P1; Mon, 02 Apr 2007 15:50:17 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B5F8132A17; Mon, 2 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYSXS-0000YT-Jz; Mon, 02 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 02 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-07.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: , 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 : TLS Transport Mapping for Syslog Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-07.txt Pages : 11 Date : 2007-4-2 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-07.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-transport-tls-07.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-transport-tls-07.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: <2007-4-2143715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-2143715.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 Tue Apr 03 10:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjcs-00038Y-2X; Tue, 03 Apr 2007 10:04:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjcp-00031k-CE for syslog@ietf.org; Tue, 03 Apr 2007 10:04:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYjYm-0000F2-E0 for syslog@ietf.org; Tue, 03 Apr 2007 10:00:34 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 03 Apr 2007 07:00:33 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l33E0VKt010999 for ; Tue, 3 Apr 2007 07:00:31 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l33E0VA9025241 for ; Tue, 3 Apr 2007 14:00:31 GMT Date: Tue, 3 Apr 2007 07:00:31 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1700; t=1175608831; x=1176472831; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20New=20-transport-tls=20ID=20-=20Need=20Reviews=20NOW |Sender:=20; bh=spFSh+atvUc/CqjvRKdhGZim801xxaztp/LKboo4eF4=; b=j9RkAD0W6zfxzvN1AIPXMm3cBht+a4ZHGcVsCXR19vw8AzkhekEVKjBDCfl25xkogaqKCz+k TScCV7f2Sn851jcYamY3I/jZliw+KvnJWa/DszglMIkW8Du7da4fKdMN; Authentication-Results: sj-dkim-8; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Syslog] New -transport-tls ID - Need Reviews NOW 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: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, New ID: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-07.txt Miao has submitted a revised -transport-tls document. This came about after Sam performed a review and found some items that needed to be addressed. >From Sam: ===vvv=== First, I think the idea of generic certificates will not meet with consensus of the security community. It may be OK to use the same Subject name for all cable modems from a given vendor, but reuse of private keys is not something we should recommend in an IETF standard. In general, preferring dnsname subjectAlternativeName to CN in the subject field seems preferable. Why does this specification use cn rather than either always using dnsname or using a procedure similar to that in RFC 2818. The text seems confused about what authentication is required when. Section 5.1 implies that authentication of receivers is optional but the text requires it. Are senders and relays required to have a certificate and to use that certificate? ===^^^=== There is a lengthy discussion which can be found in the archives. David and I feel that there are enough significant changes to this document that we'd like a WG review before we pass it back to Sam. Please read this document and send a note back the the mail list - even to say that you have no problems with the document. I'll ask that everyone overlook typo's and small grammar problems at this time. We need to make sure that the document: - addresses Sam's concerns, - meets the stated goals of our charter, - is technically sound, implementable, and deployable, - is a good thing to do for syslog. Many thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Apr 03 10:49:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkJs-0006CU-F6; Tue, 03 Apr 2007 10:49:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkJq-000696-LM for syslog@ietf.org; Tue, 03 Apr 2007 10:49:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYkJi-0003Dw-5Q for syslog@ietf.org; Tue, 03 Apr 2007 10:49:10 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2007 16:48:57 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l33EmvvQ022064; Tue, 3 Apr 2007 16:48:57 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp362.cisco.com [10.61.65.106]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33EmulZ014587; Tue, 3 Apr 2007 14:48:56 GMT Message-ID: <46126957.1060505@cisco.com> Date: Tue, 03 Apr 2007 16:48:55 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: [Syslog] New -transport-tls ID - Need Reviews NOW References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=902; t=1175611737; x=1176475737; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20New=20-transport-tls=20ID=20-=20Need=20Rev iews=20NOW |Sender:=20; bh=tdN330jurH4BEupwBr8UuihiBg1SOXoiu7HCJavyIMA=; b=lM1mzhRyeQnfS+pcGcggqRv5Qfa1M9m8v2x4zkZVbcXlimSo/jQmF4uWJsQWrEWNfvybmYup F73AYgon7wslM3/AKnCwmfAAOb1WzoLbJGh4/4Yyo3DobPKwjFwyVU7D; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: syslog-bounces@lists.ietf.org Hi Chris, I've taken a look at this document, and I have just two comments. In section 4.2.2: > A client's certificate must be associated with a unique private key . > Private keys MUST NOT be shared between clients. This is not part of the protocol, often beyond the control of the syslog implementor, and hence should be stricken. If you want to have a discussion about the shared use of private keys, please move it into Security Considerations with non-normative text. Similarly, Section 4.2.3 overreaches: > Syslog applications MUST be implemented in a manner that permits > administrators, as a matter of local policy, to select the > cryptographic level and authentication options they desire. > While I understand the desire for algorithm agility, this may not be possible in embedded applications. I would state this as a SHOULD. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Apr 04 09:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ55R-0004l0-5B; Wed, 04 Apr 2007 08:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ55Q-0004kv-H4 for syslog@ietf.org; Wed, 04 Apr 2007 08:59:40 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ55P-00007r-3k for syslog@ietf.org; Wed, 04 Apr 2007 08:59:40 -0400 Received: from pc6 (1Cust148.tnt13.lnd4.gbr.da.uu.net [62.188.142.148]) by blaster.systems.pipex.net (Postfix) with SMTP id 9D21BE0005D3; Wed, 4 Apr 2007 13:59:24 +0100 (BST) Message-ID: <037f01c776b0$4fb91600$0601a8c0@pc6> From: "tom.petch" To: "syslog" References: <019a01c75042$5211a460$0601a8c0@pc6> <0cc101c761c8$7a96b8c0$0600a8c0@china.huawei.com> Date: Wed, 4 Apr 2007 13:52:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: David Harrington Subject: [Syslog] draft-ietf-syslog-device-mib-15 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: , Errors-To: syslog-bounces@lists.ietf.org A few more suggestions on this thorny matter:-( I like the change to [references] in the object descriptions - but I would suggest moving the paragraph which tells the RFC Editor what to do up the document to the first time that RFCPROT occurs. And label it as a Note to the RFC Ed. because that is what it is (unless we wait on the publication of the other RFC before submitting this one which could delay it for nine months) In the statistics entries, I suggest that 'should have a zero value' is more accurate than 'will have a zero value' (really it is 'SHOULD be zero' but I do not think that that is allowed in a MIB module). s2 'A relay forwards /some/ ... ' suggest /some or all/ s3 statistics now include received, sent, relayed and discarded so I would mention all those options here. SyslogRoles confuses me; I read the earlier text in s2 as sender/receiver being the lower layer and collector/relay/originator as being the application; in which case, I expect the Roles to be collector/relay/originator ie relay includes both sender and receiver in the lower layer sense in which they are used elsewhere. SyslogEncapsulation - what did we decide about Syslog-Sign; I have lost track. suggest removing --syslogControlTable -- -- --syslogOperationsTable -- syslogControlBindPort - might there be a default of 514? syslogOperationsMsgsTransmitted - I would prefer syslogOperationsMsgsSent since we talk elsewhere of Sender and not Transmitter. The two terms are near synonyms but could confuse a non-native speaker syslogOperationsMsgsDropped "The number of messages that could not be queued for transmission by the syslog sender. I am unclear what this means; it sounds to me like an implementation detail. In general, I would expect there to be other reasons, other resource shortages, why messages could not be sent and would prefer a more generic description with 'could not be queued' as an eg rather than the sole cause syslogOperationsCounterDiscontinuityTime OBJECT-TYPE counters, viz., counters with OID prefix I would suggest Object Descriptor rather than OID prefix syslogOperationsMsgsMalFormed - the reference to s6.3 is a reference to structured data whereas the text in this I-D only talks of header; I know of no reference for malformed headers, although it has surfaced on the list, without, as I recall, any conclusion. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Apr 10 02:37:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb9xG-0003wU-Vr; Tue, 10 Apr 2007 02:35:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb9xG-0003wP-0i for syslog@ietf.org; Tue, 10 Apr 2007 02:35:50 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb9xB-0000B3-Gq for syslog@ietf.org; Tue, 10 Apr 2007 02:35:50 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 95C7027C06F; Tue, 10 Apr 2007 08:32:20 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08379-01; Tue, 10 Apr 2007 08:32:20 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 35A9D27C06E; Tue, 10 Apr 2007 08:32:20 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Apr 2007 08:35:27 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] draft-ietf-syslog-device-mib-15 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2007 08:35:25 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA277EFB@grfint2.intern.adiscon.com> In-Reply-To: <037f01c776b0$4fb91600$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-syslog-device-mib-15 Thread-Index: Acd2uXJ2O91rsWwGSNSz/5xoGw4BuwEgLXOg References: <019a01c75042$5211a460$0601a8c0@pc6><0cc101c761c8$7a96b8c0$0600a8c0@china.huawei.com> <037f01c776b0$4fb91600$0601a8c0@pc6> From: "Rainer Gerhards" To: "tom.petch" , "syslog" X-OriginalArrivalTime: 10 Apr 2007 06:35:27.0891 (UTC) FILETIME=[6D821630:01C77B3A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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: , Errors-To: syslog-bounces@lists.ietf.org Tom, I have documented the generic design of almost (all?) syslog implementations I know. Of course, there are some slight differences if you look at the code, but the logical functions are present. Find it here: http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph tml Rainer > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, April 04, 2007 1:52 PM > To: syslog > Cc: David Harrington > Subject: [Syslog] draft-ietf-syslog-device-mib-15 >=20 > A few more suggestions on this thorny matter:-( >=20 > I like the change to [references] in the object descriptions - but I > would > suggest moving the paragraph which tells the RFC Editor what to do up > the > document to the first time that RFCPROT occurs. And label it as a Note > to the > RFC Ed. because that is what it is (unless we wait on the publication > of the > other RFC before submitting this one which could delay it for nine > months) >=20 > In the statistics entries, I suggest that 'should have a zero value' is > more > accurate than 'will have a zero value' (really it is 'SHOULD be zero' > but I do > not think that that is allowed in a MIB module). >=20 > s2 'A relay forwards /some/ ... ' suggest /some or all/ >=20 > s3 statistics now include received, sent, relayed and discarded so I > would > mention all those options here. >=20 > SyslogRoles confuses me; I read the earlier text in s2 as > sender/receiver being > the lower layer and collector/relay/originator as being the > application; in > which case, I expect the Roles to be collector/relay/originator ie > relay > includes both sender and receiver in the lower layer sense in which > they are > used elsewhere. >=20 > SyslogEncapsulation - what did we decide about Syslog-Sign; I have lost > track. >=20 > suggest removing > --syslogControlTable > -- > -- > --syslogOperationsTable > -- >=20 > syslogControlBindPort - might there be a default of 514? >=20 > syslogOperationsMsgsTransmitted - I would prefer > syslogOperationsMsgsSent since > we talk elsewhere of Sender and not Transmitter. The two terms are > near > synonyms but could confuse a non-native speaker >=20 > syslogOperationsMsgsDropped > "The number of messages that could not be queued > for transmission by the syslog sender. > I am unclear what this means; it sounds to me like an implementation > detail. In > general, I would expect there to be other reasons, other resource > shortages, why > messages could not be sent and would prefer a more generic description > with > 'could not be queued' as an eg rather than the sole cause >=20 > syslogOperationsCounterDiscontinuityTime > OBJECT-TYPE > counters, viz., counters with OID prefix >=20 > I would suggest Object Descriptor rather than OID prefix >=20 > syslogOperationsMsgsMalFormed - the reference to s6.3 is a reference > to > structured data whereas the text in this I-D only talks of header; I > know of no > reference for malformed headers, although it has surfaced on the list, > without, > as I recall, any conclusion. >=20 > Tom Petch >=20 >=20 > _______________________________________________ > 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 Apr 17 07:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdlsm-0003VU-MH; Tue, 17 Apr 2007 07:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdlsm-0003VP-8f for syslog@ietf.org; Tue, 17 Apr 2007 07:30:00 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdlsk-0007OH-VM for syslog@ietf.org; Tue, 17 Apr 2007 07:30:00 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3HBTuO21601 for ; Tue, 17 Apr 2007 11:29:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C780E3.B9BA7F18" Date: Tue, 17 Apr 2007 07:29:55 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E8033F5@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-gerhards-chisholm-syslog-alarm-00.txt Thread-Index: AceAecMDXoZDiAvsSgGeV6orKTuDXAAaeCPQ From: "Sharon Chisholm" To: "syslog" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Subject: [Syslog] FW: I-D ACTION:draft-gerhards-chisholm-syslog-alarm-00.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: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C780E3.B9BA7F18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, April 16, 2007 6:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-gerhards-chisholm-syslog-alarm-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Alarms in SYSLOG Author(s) : R. Gerhards, S. Chisholm Filename : draft-gerhards-chisholm-syslog-alarm-00.txt Pages : 7 Date : 2007-4-16 =09 This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gerhards-chisholm-syslog-alarm -00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-gerhards-chisholm-syslog-alarm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-gerhards-chisholm-syslog-alarm-00.txt". =09 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_001_01C780E3.B9BA7F18 Content-Type: application/octet-stream; name="ATT4492830.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT4492830.TXT Content-Disposition: attachment; filename="ATT4492830.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy00LTE2MTUxMjMyLkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdlcmhhcmRzLWNoaXNob2xt LXN5c2xvZy1hbGFybS0wMC50eHQNCg== ------_=_NextPart_001_01C780E3.B9BA7F18 Content-Type: application/octet-stream; name="draft-gerhards-chisholm-syslog-alarm-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-gerhards-chisholm-syslog-alarm-00.URL Content-Disposition: attachment; filename="draft-gerhards-chisholm-syslog-alarm-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1nZXJoYXJkcy1jaGlzaG9sbS1zeXNsb2ctYWxhcm0tMDAudHh0DQo= ------_=_NextPart_001_01C780E3.B9BA7F18 Content-Type: text/plain; name="ATT4492831.txt" Content-Transfer-Encoding: base64 Content-Description: ATT4492831.txt Content-Disposition: attachment; filename="ATT4492831.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C780E3.B9BA7F18 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_001_01C780E3.B9BA7F18-- From syslog-bounces@lists.ietf.org Fri Apr 20 13:33:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hewyx-00039X-Ig; Fri, 20 Apr 2007 13:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hewyw-00039S-Sg for syslog@ietf.org; Fri, 20 Apr 2007 13:33:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hewyu-0002Y7-IT for syslog@ietf.org; Fri, 20 Apr 2007 13:33:14 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 20 Apr 2007 10:33:12 -0700 X-IronPort-AV: i="4.14,433,1170662400"; d="scan'208"; a="55216575:sNHT42263892" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3KHXBEh019429 for ; Fri, 20 Apr 2007 10:33:11 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3KHXBwo006381 for ; Fri, 20 Apr 2007 17:33:11 GMT Date: Fri, 20 Apr 2007 10:33:11 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1405; t=1177090391; x=1177954391; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Status=20Update |Sender:=20; bh=qac2HahfTcXq6ZFD0ojrV9qVD+K+pZsXjXGI9QLa43s=; b=MTFrU63dGhWfbKAe1e5bWlnvFLCH+B234LVbGgz4WNJmgQa2D/XhQu/3W93fZTSHiwFGTZTr mcTDWK+2sfBhdYigP9CEpwFLtv3taLoQJxoDPlo7nbZTeU1PwVHqnSfo; Authentication-Results: sj-dkim-8; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Syslog] Status Update 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: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, I know that the mailing list has been quiet for a while. This doesn't mean that we're not working. :-) We have taken the IETF Last Call comments and asked Rainer to integrate them into -protocol. As we've discussed, the definitions in -protocol needed to be slightly reworked so that the counters in -mib have specific meaning. We can't have any ambiguity in how things are counted in -mib so we need to be very specific in -protocol. We think we have a clear set of definitions now and Rainer is integrating those items into -protocol. We should see the revision soon. We've also asked Glenn to make some revisions to -mib to be consistent with -protocol and so that the accounting of packets will work out. Miao and Yuzhi are integrating the IETF Last Call comments into -transport-tls. They submitted that to the ID Editor a day or so ago but David noticed an error that needs to be rectified before we ask the WG for final review. Anton worked-in the IETF Last Call comments and we're satisfied that it is ready to go. Alex is preparing a new ID to address many of the comments received about -sign. We'll be asking for a review of that when it is updated. Somehow the -3195bis ID got dropped from our list of IDs. We've asked Eliot to resubmit that. Once we get that in the repository we can review it. Thanks, Chris & David _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Apr 20 15:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez7r-0006VL-CS; Fri, 20 Apr 2007 15:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez7M-0005Vy-Cy; Fri, 20 Apr 2007 15:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hez7K-0007Fj-0X; Fri, 20 Apr 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F29FC32CA6; Fri, 20 Apr 2007 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hez7J-0001wt-Sq; Fri, 20 Apr 2007 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Apr 2007 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-08.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: , 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 : TLS Transport Mapping for Syslog Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-08.txt Pages : 11 Date : 2007-4-20 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-08.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-transport-tls-08.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-transport-tls-08.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: <2007-4-20100406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-20100406.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 Mon Apr 23 03:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfslI-0004k9-0e; Mon, 23 Apr 2007 03:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfslG-0004jn-AF for syslog@ietf.org; Mon, 23 Apr 2007 03:14:58 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfslF-0007Sr-Kf for syslog@ietf.org; Mon, 23 Apr 2007 03:14:58 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGX00MWFW3GMD@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 23 Apr 2007 15:14:04 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JGX00535W3FOH@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 23 Apr 2007 15:14:04 +0800 (CST) Received: from m19684 ([10.111.12.159]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGX00LZTW3BNP@szxml03-in.huawei.com> for syslog@ietf.org; Mon, 23 Apr 2007 15:14:03 +0800 (CST) Date: Mon, 23 Apr 2007 15:13:58 +0800 From: Miao Fuyou Subject: RE: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-08.txt In-reply-to: To: syslog@ietf.org Message-id: <001c01c78576$f6973bd0$9f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceDhS6o6tCQ+RLhRpSXD8YnAgt5rgB8UPFg X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: syslog-bounces@lists.ietf.org Hi, As Chris pointted out, a new draft will be published in one or two days to replace this one because of rectification of an error. Sorry for your inconvenience! Thanks, Miao > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Saturday, April 21, 2007 3:50 AM > To: i-d-announce@ietf.org > Cc: syslog@ietf.org > Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-08.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Security Issues in Network > Event Logging Working Group of the IETF. > > Title : TLS Transport Mapping for Syslog > Author(s) : F. Miao, M. Yuzhi > Filename : draft-ietf-syslog-transport-tls-08.txt > Pages : 11 > Date : 2007-4-20 > > This document describes the use of Transport Layer Security (TLS) to > provide a secure connection for the transport of Syslog messages. > This document describes the security threats to Syslog and how TLS > can be used to counter such threats. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpor > t-tls-08.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-transport-tls-08.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-transport-tls-08.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 Mon Apr 23 15:50:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Y3-0003G7-Tg; Mon, 23 Apr 2007 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Xz-0003CI-2a; Mon, 23 Apr 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4Xy-0005qu-QI; Mon, 23 Apr 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C0DD332AF6; Mon, 23 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hg4Xy-0004Cv-Jt; Mon, 23 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-09.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: , 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 : TLS Transport Mapping for Syslog Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-09.txt Pages : 11 Date : 2007-4-23 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-09.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-transport-tls-09.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-transport-tls-09.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: <2007-4-23121153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-23121153.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 Mon Apr 23 16:46:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5R1-0000Yr-MO; Mon, 23 Apr 2007 16:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5R0-0000Yh-B6 for syslog@ietf.org; Mon, 23 Apr 2007 16:46:54 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5Qy-0000YB-SY for syslog@ietf.org; Mon, 23 Apr 2007 16:46:54 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <20070423204652013003euiqe>; Mon, 23 Apr 2007 20:46:52 +0000 From: "David B Harrington" To: Date: Mon, 23 Apr 2007 16:46:50 -0400 Message-ID: <012301c785e8$84a4d3d0$0600a8c0@china.huawei.com> 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.3028 Thread-Index: AceFeGZlxcvjTXBvQserSE5TWbdsRAAFgkWQABZWgzA= X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Syslog] Syslog-tls-09 draft - suggested change 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: , Errors-To: syslog-bounces@lists.ietf.org Hi, The -09- revision copied text directly from rfc2818 without modifying it to match the simplex operating environment of syslog, as compared to the duplex operating environment of HTTP. I think this makes the text confusing since it is unclear what a "user-oriented" syslog would be. HTTP is often used in a "user-oriented" environment, such as with a web browser, so the following makes sense: If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. The syslog-tls text was changed from rfc2818 because the "user oriented" text of rfc2818 does not seem to make protocol sense for the simplex syslog, where you cannot "notify the user", so most of the first sentence was eliminated from the syslog draft. If the hostname (or IP address) does not match the identity in the certificate, the clients MUST terminate the connection with a bad certificate error. Clients MAY log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). The "user-oriented" and "automated client" conditionals were removed, and the user-oriented action was changed from "MUST notify or terminate" to simply "MUST terminate". The removal of the conditionals makes the actions unconditional. But the unconditional "MUST terminate" in the first sentence conflicts with the unconditional "SHOULD terminate" in the second sentence. I recommend the following text which is consistent with the automated client case in rfc2818: If the hostname (or IP address) does not match the identity in the certificate, the client MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). (Note that changing "MAY log the error" (syslog-tls-08) , to "MUST log the error" (rfc2818), makes little difference since there is an "if available" clause.) David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Apr 23 22:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgAsd-0001mC-5u; Mon, 23 Apr 2007 22:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgAsc-0001gd-DW for syslog@ietf.org; Mon, 23 Apr 2007 22:35:46 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgAsb-00014f-1s for syslog@ietf.org; Mon, 23 Apr 2007 22:35:46 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGZ00GP9DU1JB@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 24 Apr 2007 10:34:50 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGZ000EHDU1ZD@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 24 Apr 2007 10:34:49 +0800 (CST) Received: from m19684 ([10.111.12.159]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGZ000MFDTXEL@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 24 Apr 2007 10:34:48 +0800 (CST) Date: Tue, 24 Apr 2007 10:34:45 +0800 From: Miao Fuyou Subject: RE: [Syslog] Syslog-tls-09 draft - suggested change In-reply-to: <012301c785e8$84a4d3d0$0600a8c0@china.huawei.com> To: 'David Harrington' Message-id: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceFeGZlxcvjTXBvQserSE5TWbdsRAAFgkWQABZWgzAACpiCcA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: , Errors-To: syslog-bounces@lists.ietf.org Hi, TLS is still duplex even if syslog is simplex. In the same time, authenticaiton happens in the handshaking phase of TLS when syslog message transfering does not begin . So, simplex or duplex does not matter for authentication. I had persuaded myself that syslog sender is always hosted on automated application/appliance, such as web daemon or printer, this make it impossible for an user to check interactively whether umatched hostname/IP address is acceptable. However, I am suspecting the perception is wrong. It is possible to host syslog sender on a interactive application, such as database administration tool. One may argue that why we need to log events when we could read event description on a popup dialog or from prompt. Probably one of the motivations is that currently syslog are widely used to collect events for audit, so IDS tools could check the audit trail for further analysis. This is not only valuable for automated application but also for interactive (or user-oriented) application. So, my suggestion is the specification should not exclude user-oriented apllication of syslog, just like RFC2818 does not exclude automated application. My 0.02 bucks. Thanks, Miao > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Tuesday, April 24, 2007 4:47 AM > To: syslog@ietf.org > Subject: [Syslog] Syslog-tls-09 draft - suggested change > > Hi, > > The -09- revision copied text directly from rfc2818 without > modifying it to match the simplex operating environment of > syslog, as compared to the duplex operating environment of HTTP. > > I think this makes the text confusing since it is unclear > what a "user-oriented" syslog would be. > > HTTP is often used in a "user-oriented" environment, such as > with a web browser, so the following makes sense: > If the hostname does not match the identity in the > certificate, user > oriented clients MUST either notify the user (clients MAY give the > user the opportunity to continue with the connection in > any case) or > terminate the connection with a bad certificate error. Automated > clients MUST log the error to an appropriate audit log (if > available) > and SHOULD terminate the connection (with a bad certificate error). > Automated clients MAY provide a configuration setting that disables > this check, but MUST provide a setting which enables it. > > The syslog-tls text was changed from rfc2818 because the > "user oriented" text of rfc2818 does not seem to make > protocol sense for the simplex syslog, where you cannot > "notify the user", so most of the first sentence was > eliminated from the syslog draft. > > If the hostname (or IP address) does not match the identity in the > certificate, the clients MUST terminate the connection with a bad > certificate error. Clients MAY log the error to an > appropriate audit > log (if available) and SHOULD terminate the connection (with a bad > certificate error). > > The "user-oriented" and "automated client" conditionals were > removed, and the user-oriented action was changed from "MUST > notify or terminate" to simply "MUST terminate". The removal > of the conditionals makes the actions unconditional. But the > unconditional "MUST terminate" in the first sentence > conflicts with the unconditional "SHOULD terminate" in the > second sentence. > > I recommend the following text which is consistent with the > automated client case in rfc2818: > > If the hostname (or IP address) does not match the identity in the > certificate, the client MUST log the error to an appropriate audit > log (if available) and SHOULD terminate the connection (with a bad > certificate error). > > (Note that changing "MAY log the error" (syslog-tls-08) , to > "MUST log the error" (rfc2818), makes little difference since > there is an "if available" clause.) > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > _______________________________________________ > 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 Apr 24 03:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFfb-0001OR-0I; Tue, 24 Apr 2007 03:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFfZ-0001OG-8Y for syslog@ietf.org; Tue, 24 Apr 2007 03:42:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFfX-0007sF-Tm for syslog@ietf.org; Tue, 24 Apr 2007 03:42:37 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2007 09:42:35 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3O7gZ9B004410; Tue, 24 Apr 2007 09:42:35 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp4271.cisco.com [10.61.80.174]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3O7gYlZ026634; Tue, 24 Apr 2007 07:42:34 GMT Message-ID: <462DB4EA.1000605@cisco.com> Date: Tue, 24 Apr 2007 09:42:34 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Miao Fuyou Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change References: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> In-Reply-To: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3376; t=1177400555; x=1178264555; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Syslog-tls-09=20draft=20-=20suggested=20ch ange |Sender:=20; bh=TGNNhi+lXb/yFstUY3PKovmWIxn8Evzunj6GIale7W8=; b=DyXdVCkXze3c8QMSXkJb3LijlNTy0wUxa9FmsGCvzz/RtcgrtzimSPA3eLHCSzbnflGGDhIB 0mEI0VOl68Gjx4uDenbgq5//dCEawHLjW1B8VDewB5H4hjgH0s5k6RjE; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: syslog@ietf.org, 'David Harrington' 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: , Errors-To: syslog-bounces@lists.ietf.org Miao, > TLS is still duplex even if syslog is simplex. In the same time, > authenticaiton happens in the handshaking phase of TLS when syslog message > transfering does not begin . So, simplex or duplex does not matter for > authentication. I personally haven't liked those terms since 300 baud modems and 3270s went out of style ;-) > I had persuaded myself that syslog sender is always hosted on automated > application/appliance, such as web daemon or printer, this make it > impossible for an user to check interactively whether umatched hostname/IP > address is acceptable. However, I am suspecting the perception is wrong. It > is possible to host syslog sender on a interactive application, such as > database administration tool. This is not as simple a decision as may first appear. On the one hand, while you can come up with examples such as the above, and they really do exist (another good one is when you have some sort of Windows Watcher(*) that you want to log back to a central source), the two problems with reporting to the user are (a) the cases where there is no user and (b) the fact that operational experience has shown that the user really doesn't know what to do when there is a problem. On the other hand, we have another little problem in this specific case. What do we normally say when something goes wrong in one of our protocols? "Log an error." Here that poses a little bit of a problem ;-) I would suggest text along the lines of the following: The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. In the case of a receiving relay or a receiver, the connection SHOULD be closed and an error logged, indicating the problem. In the case of a syslog sender or a transmitting relay, the situation requires more care. Here the application SHOULD also close the connection and also use whatever other means are available to it to inform the administrator of the problem. This may include producing a message on a console, returning an error to the user, or writing a file to disk, if possible. There is also a matter of what an application is supposed to do when logging fails. Some applications should proceed uninterrupted. Others may need to block. I don't know whether text is appropriate. It's not part of the protocol, but it does fall under common modes of failure. The reason this would be an issue with TLS (or BEEP for that matter) and not with UDP is that one doesn't block with UDP. In addition, you have another problem in the text: > If the client is configured with IP address > of the server, the hostname should be got first through a trusted > mechanism such as a preconfigured hosts table or DNSSEC [8]. It is often the case that a reverse map does not match a forward map. For example, often times a service provider might allocate IP address space and route that space to a customer but not delegate the reverse mapping. This is particularly true in consumer environments. I would suggest that if the client is configured with an IP address, that it is what should be present in the certificate, as the name has no meaning at all to the client. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Apr 24 10:29:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgM0v-00058Z-Ks; Tue, 24 Apr 2007 10:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgM0u-00058R-Jp for syslog@ietf.org; Tue, 24 Apr 2007 10:29:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgM0s-0007ys-NL for syslog@ietf.org; Tue, 24 Apr 2007 10:29:04 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 07:29:02 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="415005738:sNHT55836164" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3OET2Oq002162; Tue, 24 Apr 2007 07:29:02 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3OET1wo013715; Tue, 24 Apr 2007 14:29:01 GMT Date: Tue, 24 Apr 2007 07:29:01 -0700 (PDT) From: Chris Lonvick To: Eliot Lear Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change In-Reply-To: <462DB4EA.1000605@cisco.com> Message-ID: References: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> <462DB4EA.1000605@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5086; t=1177424942; x=1178288942; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Syslog-tls-09=20draft=20-=20suggested=20ch ange |Sender:=20; bh=axJT6xkPXGiFZSk6NuN9+q6j2vUqeV+Y095g8ExBmNE=; b=A5ummOkuXZgkfri1al5jgmAylgKmrQwpYUhaQhJjnGE0YzGIV0K853J2pwktQmfVDKlaLmnX B3lbyc3RIACHk1ynI5RVagvK3OXrNXPrjCI2xqe8oZUWrHU/89wWSY4v; Authentication-Results: sj-dkim-6; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: syslog@ietf.org, 'David Harrington' 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: , Errors-To: syslog-bounces@lists.ietf.org Hi, On Tue, 24 Apr 2007, Eliot Lear wrote: > Miao, >> TLS is still duplex even if syslog is simplex. In the same time, >> authenticaiton happens in the handshaking phase of TLS when syslog message >> transfering does not begin . So, simplex or duplex does not matter for >> authentication. > > I personally haven't liked those terms since 300 baud modems and 3270s went > out of style ;-) > >> I had persuaded myself that syslog sender is always hosted on automated >> application/appliance, such as web daemon or printer, this make it >> impossible for an user to check interactively whether umatched hostname/IP >> address is acceptable. However, I am suspecting the perception is wrong. >> It >> is possible to host syslog sender on a interactive application, such as >> database administration tool. > > > This is not as simple a decision as may first appear. On the one hand, while > you can come up with examples such as the above, and they really do exist > (another good one is when you have some sort of Windows Watcher(*) that you > want to log back to a central source), the two problems with reporting to the > user are (a) the cases where there is no user and (b) the fact that > operational experience has shown that the user really doesn't know what to do > when there is a problem. > > On the other hand, we have another little problem in this specific case. > What do we normally say when something goes wrong in one of our protocols? > "Log an error." Here that poses a little bit of a problem ;-) I would > suggest text along the lines of the following: > > The application developer must take some care to consider the case > when, for whatever reason, there is a problem with authenticating > the other end of the connection. In the case of a receiving relay > or a receiver, the connection SHOULD be closed and an error logged, > indicating the problem. In the case of a syslog sender or a > transmitting relay, the situation requires more care. Here the > application SHOULD also close the connection and also use whatever > other means are available to it to inform the administrator of the > problem. This may include producing a message on a console, > returning an error to the user, or writing a file to disk, if possible. > > There is also a matter of what an application is supposed to do when logging > fails. Some applications should proceed uninterrupted. Others may need to > block. I don't know whether text is appropriate. It's not part of the > protocol, but it does fall under common modes of failure. The reason this > would be an issue with TLS (or BEEP for that matter) and not with UDP is that > one doesn't block with UDP. I think Eliot is on the right track. However, I wouldn't differentiate between the actions that a sender or receiver is to take when authentication fails - both cases should have a recommendation that the device log the failure _and_ attempt to inform the administrator of the problem. This might be pop-ups to the unsuspecting user who won't know what to do about it, it might be messages printed on the console, it might be a blinky light on the printer, etc. (Most networked printers that I'm seeing these days have nice displays that are starting to give informative messages.) Perhaps this text: The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. The connection SHOULD be closed and an error logged indicating the problem. Since this problem will prevent log messages from being transmitted, each device having this problem should use whatever means are available to inform the administrator of the problem. This may include producing a message on a console, returning an error to a user (if there is one), or writing a file to disk, if possible. > > In addition, you have another problem in the text: > >> If the client is configured with IP address >> of the server, the hostname should be got first through a trusted >> mechanism such as a preconfigured hosts table or DNSSEC [8]. > > It is often the case that a reverse map does not match a forward map. For > example, often times a service provider might allocate IP address space and > route that space to a customer but not delegate the reverse mapping. This is > particularly true in consumer environments. I would suggest that if the > client is configured with an IP address, that it is what should be present in > the certificate, as the name has no meaning at all to the client. I think that's an operational issue that we're not going to deal with. We're talking about a domain of administration here. We're not going to be able to write enough text into this document to cover the case where the administrators cannot line up dNSName with an IP address within their own purview. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Apr 24 11:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNAP-0001Br-02; Tue, 24 Apr 2007 11:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNAN-0000xz-73 for syslog@ietf.org; Tue, 24 Apr 2007 11:42:55 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNAK-0000c8-Rp for syslog@ietf.org; Tue, 24 Apr 2007 11:42:55 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH000CMXEA30H@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 24 Apr 2007 23:42:03 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH000DJBEA2A3@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 24 Apr 2007 23:42:03 +0800 (CST) Received: from Harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net [24.128.104.207]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JH0004T9E9Q9Y@szxml01-in.huawei.com>; Tue, 24 Apr 2007 23:42:02 +0800 (CST) Date: Tue, 24 Apr 2007 11:41:50 -0400 From: David Harrington Subject: RE: [Syslog] Syslog-tls-09 draft - suggested change In-reply-to: <462DB4EA.1000605@cisco.com> To: 'Eliot Lear' , 'Miao Fuyou' , 'Chris Lonvick' Message-id: <016501c78687$171aae80$0600a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceGRCRnPgZK7S0LT6m+mC473V2QWgALMmTw References: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> <462DB4EA.1000605@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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: , Errors-To: syslog-bounces@lists.ietf.org Hi, I am a bit concerned that most people will look at syslog as being an automated client and not a user-oriented client, and the paragraph from rfc2818 can be confusing if one does not consider the few exceptions. I recognized that my suggested text did exclude consideration of the few user-oriented cases, so I do not have a problem with my text being rejected on that point. But leaving the text from rfc2818 as is still has the same problem. I would be much more accepting of the text from rfc2818 if the "automated client" was discussed before the user-oriented client discussion: If the hostname does not match the identity in the certificate, automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. User oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. The connection SHOULD be closed and an error logged indicating the problem. Since this problem will prevent log messages from being transmitted, each device having this problem should use whatever means are available to inform the administrator of the problem. This may include producing a message on a console, returning an error to a user (if there is one), or writing a file to disk, if possible. Does the third paragraph eliminate the need for the first two paragraphs? dbh > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Tuesday, April 24, 2007 3:43 AM > To: Miao Fuyou > Cc: 'David Harrington'; syslog@ietf.org > Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change > > Miao, > > TLS is still duplex even if syslog is simplex. In the same time, > > authenticaiton happens in the handshaking phase of TLS when > syslog message > > transfering does not begin . So, simplex or duplex does not > matter for > > authentication. > > I personally haven't liked those terms since 300 baud modems > and 3270s > went out of style ;-) > > > I had persuaded myself that syslog sender is always hosted > on automated > > application/appliance, such as web daemon or printer, this make it > > impossible for an user to check interactively whether > umatched hostname/IP > > address is acceptable. However, I am suspecting the > perception is wrong. It > > is possible to host syslog sender on a interactive > application, such as > > database administration tool. > > > This is not as simple a decision as may first appear. On the > one hand, > while you can come up with examples such as the above, and > they really > do exist (another good one is when you have some sort of Windows > Watcher(*) that you want to log back to a central source), the two > problems with reporting to the user are (a) the cases where > there is no > user and (b) the fact that operational experience has shown that the > user really doesn't know what to do when there is a problem. > > On the other hand, we have another little problem in this specific > case. What do we normally say when something goes wrong in > one of our > protocols? "Log an error." Here that poses a little bit of > a problem > ;-) I would suggest text along the lines of the following: > > The application developer must take some care to consider the case > when, for whatever reason, there is a problem with authenticating > the other end of the connection. In the case of a receiving relay > or a receiver, the connection SHOULD be closed and an > error logged, > indicating the problem. In the case of a syslog sender or a > transmitting relay, the situation requires more care. Here the > application SHOULD also close the connection and also use whatever > other means are available to it to inform the administrator of the > problem. This may include producing a message on a console, > returning an error to the user, or writing a file to > disk, if possible. > > There is also a matter of what an application is supposed to do when > logging fails. Some applications should proceed > uninterrupted. Others > may need to block. I don't know whether text is appropriate. > It's not > part of the protocol, but it does fall under common modes of > failure. > The reason this would be an issue with TLS (or BEEP for that > matter) and > not with UDP is that one doesn't block with UDP. > > In addition, you have another problem in the text: > > > If the client is configured with IP address > > of the server, the hostname should be got first through a trusted > > mechanism such as a preconfigured hosts table or DNSSEC [8]. > > It is often the case that a reverse map does not match a > forward map. > For example, often times a service provider might allocate IP address > space and route that space to a customer but not delegate the reverse > mapping. This is particularly true in consumer environments. > I would > suggest that if the client is configured with an IP address, > that it is > what should be present in the certificate, as the name has no > meaning at > all to the client. > > Eliot > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Apr 24 13:21:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOgl-0004re-99; Tue, 24 Apr 2007 13:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOgk-0004rY-Fu for syslog@ietf.org; Tue, 24 Apr 2007 13:20:26 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgOgj-0001yQ-Cv for syslog@ietf.org; Tue, 24 Apr 2007 13:20:26 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2007 19:20:26 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3OHKO0Y027075; Tue, 24 Apr 2007 19:20:24 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp34.cisco.com [10.61.64.34]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OHKNlZ000325; Tue, 24 Apr 2007 17:20:24 GMT Message-ID: <462E3C57.8020504@cisco.com> Date: Tue, 24 Apr 2007 19:20:23 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: David Harrington Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change References: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> <462DB4EA.1000605@cisco.com> <016501c78687$171aae80$0600a8c0@china.huawei.com> In-Reply-To: <016501c78687$171aae80$0600a8c0@china.huawei.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18465; t=1177435224; x=1178299224; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Syslog-tls-09=20draft=20-=20suggested=20ch ange |Sender:=20; bh=Pb7w1clKzkmLxpMLE5nIfq4djHc04I+PzpNH+HJU1T0=; b=YS/SqMeotZtdMDt5dXAJ2eNWn2t+ZKcdgdRbtzruxwu/BfIic46WXR8U++gC/dlozjHPTbAo VmHElG+8ug+K1B4gnVUyvRLBPsUCZU9L7TPBbq9Y7+ECM/biyo5aN/YN; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd 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: , Content-Type: multipart/mixed; boundary="===============1516273390==" Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1516273390== Content-Type: multipart/alternative; boundary="------------090403080803010701020509" This is a multi-part message in MIME format. --------------090403080803010701020509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, > Does the third paragraph eliminate the need for the first two > paragraphs? > > I think they need to be merged. Key parts are these: * SHOULD close the connection on failed authentication, and attempt to log an error * A discussion of the challenges of logging in such an environment. I think that boils down to this: vv If the hostname does not match the identity in the certificate, clients SHOULD log the error in some form or another (see below), and SHOULD terminate the connection (with a bad certificate error). Clients MAY provide a configuration setting that disables this check but MUST enable it by default. The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. Since this problem will prevent log messages from being transmitted, each device having this program should use whatever means are available to inform the administrator of the problem. This may include producing an error code on a console, returning an error to a user (if there is one), or writing a file to disk, being mindful that such writes should be rate limited in the case of attacks. ^^ So the above eliminates the distinction, and allows the necessary versatility that applications writers will need, given circumstances. I could envision a printer flashing the occasional "E184" or some such. Please also note that I changed the setting text, the reason for that being that if there is a configuration knob to disable a check it only follows that there will be something enabled already ;-) You might disagree. Eliot David Harrington wrote: > Hi, > > I am a bit concerned that most people will look at syslog as being an > automated client and not a user-oriented client, and the paragraph > from rfc2818 can be confusing if one does not consider the few > exceptions. > > I recognized that my suggested text did exclude consideration of the > few user-oriented cases, so I do not have a problem with my text being > rejected on that point. But leaving the text from rfc2818 as is still > has the same problem. > > I would be much more accepting of the text from rfc2818 if the > "automated client" was discussed before the user-oriented client > discussion: > > If the hostname does not match the identity in the certificate, > automated > clients MUST log the error to an appropriate audit log (if > available) > and SHOULD terminate the connection (with a bad certificate error). > Automated clients MAY provide a configuration setting that disables > this check, but MUST provide a setting which enables it. > > User oriented clients MUST either notify the user (clients MAY give > the > user the opportunity to continue with the connection in any case) > or > terminate the connection with a bad certificate error. > > The application developer must take some care to consider the case > when, for whatever reason, there is a problem with authenticating > the other end of the connection. The connection SHOULD be closed > and > an error logged indicating the problem. Since this problem will > prevent log messages from being transmitted, each device having > this > problem should use whatever means are available to inform the > administrator of the problem. This may include producing a message > on a > console, returning an error to a user (if there is one), or > writing a > file to disk, if possible. > > Does the third paragraph eliminate the need for the first two > paragraphs? > > dbh > > >> -----Original Message----- >> From: Eliot Lear [mailto:lear@cisco.com] >> Sent: Tuesday, April 24, 2007 3:43 AM >> To: Miao Fuyou >> Cc: 'David Harrington'; syslog@ietf.org >> Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change >> >> Miao, >> >>> TLS is still duplex even if syslog is simplex. In the same time, >>> authenticaiton happens in the handshaking phase of TLS when >>> >> syslog message >> >>> transfering does not begin . So, simplex or duplex does not >>> >> matter for >> >>> authentication. >>> >> I personally haven't liked those terms since 300 baud modems >> and 3270s >> went out of style ;-) >> >> >>> I had persuaded myself that syslog sender is always hosted >>> >> on automated >> >>> application/appliance, such as web daemon or printer, this make it >>> impossible for an user to check interactively whether >>> >> umatched hostname/IP >> >>> address is acceptable. However, I am suspecting the >>> >> perception is wrong. It >> >>> is possible to host syslog sender on a interactive >>> >> application, such as >> >>> database administration tool. >>> >> This is not as simple a decision as may first appear. On the >> one hand, >> while you can come up with examples such as the above, and >> they really >> do exist (another good one is when you have some sort of Windows >> Watcher(*) that you want to log back to a central source), the two >> problems with reporting to the user are (a) the cases where >> there is no >> user and (b) the fact that operational experience has shown that the >> > > >> user really doesn't know what to do when there is a problem. >> >> On the other hand, we have another little problem in this specific >> case. What do we normally say when something goes wrong in >> one of our >> protocols? "Log an error." Here that poses a little bit of >> a problem >> ;-) I would suggest text along the lines of the following: >> >> The application developer must take some care to consider the >> > case > >> when, for whatever reason, there is a problem with >> > authenticating > >> the other end of the connection. In the case of a receiving >> > relay > >> or a receiver, the connection SHOULD be closed and an >> error logged, >> indicating the problem. In the case of a syslog sender or a >> transmitting relay, the situation requires more care. Here the >> application SHOULD also close the connection and also use >> > whatever > >> other means are available to it to inform the administrator of >> > the > >> problem. This may include producing a message on a console, >> returning an error to the user, or writing a file to >> disk, if possible. >> >> There is also a matter of what an application is supposed to do when >> > > >> logging fails. Some applications should proceed >> uninterrupted. Others >> may need to block. I don't know whether text is appropriate. >> It's not >> part of the protocol, but it does fall under common modes of >> failure. >> The reason this would be an issue with TLS (or BEEP for that >> matter) and >> not with UDP is that one doesn't block with UDP. >> >> In addition, you have another problem in the text: >> >> >>> If the client is configured with IP address >>> of the server, the hostname should be got first through a >>> > trusted > >>> mechanism such as a preconfigured hosts table or DNSSEC [8]. >>> >> It is often the case that a reverse map does not match a >> forward map. >> For example, often times a service provider might allocate IP >> > address > >> space and route that space to a customer but not delegate the >> > reverse > >> mapping. This is particularly true in consumer environments. >> I would >> suggest that if the client is configured with an IP address, >> that it is >> what should be present in the certificate, as the name has no >> meaning at >> all to the client. >> >> Eliot >> >> > > --------------090403080803010701020509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dave,

Does the third paragraph eliminate the need for the first two
paragraphs?

I think they need to be merged.  Key parts are these:
  • SHOULD close the connection on failed authentication, and attempt to log an error
  • A discussion of the challenges of logging in such an environment.
I think that boils down to this:

vv

If the hostname does not match the identity in the certificate,
clients SHOULD log the error in some form or another (see below),
and SHOULD terminate the connection (with a bad certificate error).
Clients MAY provide a configuration setting that disables this check
but MUST enable it by default.

The application developer must take some care to consider the case
when, for whatever reason, there is a problem with authenticating
the other end of the connection.  Since this problem will
prevent log messages from being transmitted, each device having this
program should use whatever means are available to inform the
administrator of the problem. This may include producing an error code
on a console, returning an error to a user (if there is one), or
writing a file to disk, being mindful that such writes should be
rate limited in the case of attacks.


^^

So the above eliminates the distinction, and allows the necessary versatility that applications writers will need, given circumstances.   I could envision a printer flashing the occasional "E184" or some such.  Please also note that I changed the setting text, the reason for that being that if there is a configuration knob to disable a check it only follows that there will be something enabled already ;-)  You might disagree.

Eliot



David Harrington wrote: 
Hi,

I am a bit concerned that most people will look at syslog as being an
automated client and not a user-oriented client, and the paragraph
from rfc2818 can be confusing if one does not consider the few
exceptions.

I recognized that my suggested text did exclude consideration of the
few user-oriented cases, so I do not have a problem with my text being
rejected on that point. But leaving the text from rfc2818 as is still
has the same problem.

I would be much more accepting of the text from rfc2818 if the
"automated client" was discussed before the user-oriented client
discussion:

   If the hostname does not match the identity in the certificate,
automated
   clients MUST log the error to an appropriate audit log (if
available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it. 

   User oriented clients MUST either notify the user (clients MAY give
the
   user the opportunity to continue with the connection in any case)
or
   terminate the connection with a bad certificate error.

    The application developer must take some care to consider the case
    when, for whatever reason, there is a problem with authenticating
    the other end of the connection.  The connection SHOULD be closed
and
    an error logged indicating the problem.  Since this problem will
    prevent log messages from being transmitted, each device having
this
    problem should use whatever means are available to inform the
    administrator of the problem. This may include producing a message
on a
    console, returning an error to a user (if there is one), or
writing a
    file to disk, if possible.

Does the third paragraph eliminate the need for the first two
paragraphs?

dbh

  
-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com] 
Sent: Tuesday, April 24, 2007 3:43 AM
To: Miao Fuyou
Cc: 'David Harrington'; syslog@ietf.org
Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change

Miao,
    
TLS is still duplex even if syslog is simplex. In the same time,
authenticaiton happens in the handshaking phase of TLS when 
      
syslog message
    
transfering does not begin . So, simplex or duplex does not 
      
matter for
    
authentication.
      
I personally haven't liked those terms since 300 baud modems 
and 3270s 
went out of style  ;-)

    
I had persuaded myself that syslog sender is always hosted 
      
on automated
    
application/appliance, such as web daemon or printer, this make it
impossible for an user to check interactively whether 
      
umatched hostname/IP
    
address is acceptable. However, I am suspecting the 
      
perception is wrong. It
    
is possible to host syslog sender on a interactive 
      
application, such as
    
database administration tool.
      
This is not as simple a decision as may first appear.  On the 
one hand, 
while you can come up with examples such as the above, and 
they really 
do exist (another good one is when you have some sort of Windows 
Watcher(*) that you want to log back to a central source), the two 
problems with reporting to the user are (a) the cases where 
there is no 
user and (b) the fact that operational experience has shown that the
    

  
user really doesn't know what to do when there is a problem.

On the other hand, we have another little problem in this specific 
case.  What do we normally say when something goes wrong in 
one of our 
protocols?  "Log an error."  Here that poses a little bit of 
a problem 
;-)  I would suggest text along the lines of the following:

    The application developer must take some care to consider the
    
case
  
    when, for whatever reason, there is a problem with
    
authenticating
  
    the other end of the connection.  In the case of a receiving
    
relay
  
    or a receiver, the connection SHOULD be closed and an 
error logged,
    indicating the problem.  In the case of a syslog sender or a
    transmitting relay, the situation requires more care.  Here the
    application SHOULD also close the connection and also use
    
whatever
  
    other means are available to it to inform the administrator of
    
the
  
    problem.  This may include producing a message on a console,
    returning an error to the user, or writing a file to 
disk, if possible.

There is also a matter of what an application is supposed to do when
    

  
logging fails.  Some applications should proceed 
uninterrupted.  Others 
may need to block.  I don't know whether text is appropriate. 
 It's not 
part of the protocol, but it does fall under common modes of 
failure.  
The reason this would be an issue with TLS (or BEEP for that 
matter) and 
not with UDP is that one doesn't block with UDP.

In addition, you have another problem in the text:

    
   If the client is configured with IP address
   of the server, the hostname should be got first through a
      
trusted
  
   mechanism such as a preconfigured hosts table or DNSSEC [8].
      
It is often the case that a reverse map does not match a 
forward map.  
For example, often times a service provider might allocate IP
    
address 
  
space and route that space to a customer but not delegate the
    
reverse 
  
mapping.  This is particularly true in consumer environments. 
  I would 
suggest that if the client is configured with an IP address, 
that it is 
what should be present in the certificate, as the name has no 
meaning at 
all to the client.

Eliot

--------------090403080803010701020509-- --===============1516273390== 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 --===============1516273390==-- From syslog-bounces@lists.ietf.org Tue Apr 24 22:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgX1q-0008QA-Ik; Tue, 24 Apr 2007 22:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgX1p-0008Px-6L for syslog@ietf.org; Tue, 24 Apr 2007 22:14:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgX1n-0007R0-TY for syslog@ietf.org; Tue, 24 Apr 2007 22:14:45 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 19:14:43 -0700 X-IronPort-AV: i="4.14,449,1170662400"; d="scan'208"; a="415287711:sNHT43582432" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3P2EhZc016499; Tue, 24 Apr 2007 19:14:43 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3P2EgA9014529; Wed, 25 Apr 2007 02:14:42 GMT Date: Tue, 24 Apr 2007 19:14:42 -0700 (PDT) From: Chris Lonvick To: Eliot Lear Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change In-Reply-To: <462E3C57.8020504@cisco.com> Message-ID: References: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> <462DB4EA.1000605@cisco.com> <016501c78687$171aae80$0600a8c0@china.huawei.com> <462E3C57.8020504@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1155; t=1177467283; x=1178331283; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Syslog-tls-09=20draft=20-=20suggested=20ch ange |Sender:=20; bh=44UwpgYpquPYSbInn1X6YKxAHl1DIzLRAX1JYqXWf1A=; b=A3nkAiATpNtqZmpOBzmk9GJE0fkcl+FhdEjJ2ZP0D4WVrd0LyShayYTm7jYonYs8TMnX1Kht p2701l8am/LL7QZMvjq21QxFadQrNpbeef45/VSI9+SBr56Ofm+09i/n; Authentication-Results: sj-dkim-6; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: syslog@ietf.org, David Harrington 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: , Errors-To: syslog-bounces@lists.ietf.org Hi, I'm OK with this proposal with two minor changes. - rather than "(see below)" it should have "(see next paragraph)" - remove parenthasis from "(with a bad certificate error)" as that text is normative. > vv > > If the hostname does not match the identity in the certificate, > clients SHOULD log the error in some form or another (see below), > and SHOULD terminate the connection (with a bad certificate error). > Clients MAY provide a configuration setting that disables this check > but MUST enable it by default. > > The application developer must take some care to consider the case > when, for whatever reason, there is a problem with authenticating > the other end of the connection. Since this problem will > prevent log messages from being transmitted, each device having this > program should use whatever means are available to inform the > administrator of the problem. This may include producing an error code > on a console, returning an error to a user (if there is one), or > writing a file to disk, being mindful that such writes should be > rate limited in the case of attacks. > > ^^ Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Apr 25 03:34:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgc13-0002KD-Rr; Wed, 25 Apr 2007 03:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgc12-0002K7-5W for syslog@ietf.org; Wed, 25 Apr 2007 03:34:16 -0400 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgc10-0005vN-Sk for syslog@ietf.org; Wed, 25 Apr 2007 03:34:16 -0400 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 583DF294011 for ; Wed, 25 Apr 2007 09:34:13 +0200 (CEST) Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change From: Balazs Scheidler To: Eliot Lear In-Reply-To: <462DB4EA.1000605@cisco.com> References: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> <462DB4EA.1000605@cisco.com> Content-Type: text/plain Date: Wed, 25 Apr 2007 09:34:13 +0200 Message-Id: <1177486453.6283.3.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: syslog@ietf.org, 'David Harrington' 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: , Errors-To: syslog-bounces@lists.ietf.org On Tue, 2007-04-24 at 09:42 +0200, Eliot Lear wrote: > Miao, > In addition, you have another problem in the text: > > > If the client is configured with IP address > > of the server, the hostname should be got first through a trusted > > mechanism such as a preconfigured hosts table or DNSSEC [8]. > > It is often the case that a reverse map does not match a forward map. > For example, often times a service provider might allocate IP address > space and route that space to a customer but not delegate the reverse > mapping. This is particularly true in consumer environments. I would > suggest that if the client is configured with an IP address, that it is > what should be present in the certificate, as the name has no meaning at > all to the client. And the IP address can also be added to the X.509 certificate in the subjectAltName extension. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Apr 25 03:47:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcDw-00054O-5j; Wed, 25 Apr 2007 03:47:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcDu-0004wt-Fr for syslog@ietf.org; Wed, 25 Apr 2007 03:47:34 -0400 Received: from dsl081-242-052.sfo1.dsl.speakeasy.net ([64.81.242.52] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgcDt-0001xA-6q for syslog@ietf.org; Wed, 25 Apr 2007 03:47:34 -0400 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id BDE9938A92 for ; Wed, 25 Apr 2007 00:47:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gandalf.taltos.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from [10.0.231.231] (72-255-23-223.client.stsn.net [72.255.23.223]) by gandalf.taltos.org (Postfix) with ESMTP id 7D00E38019 for ; Wed, 25 Apr 2007 00:47:24 -0700 (PDT) Date: Wed, 25 Apr 2007 03:47:11 -0400 From: Carson Gaspar To: syslog@ietf.org Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change Message-ID: In-Reply-To: <1177486453.6283.3.camel@bzorp.balabit> References: <011501c78619$1f147fd0$9f0c6f0a@china.huawei.com> <462DB4EA.1000605@cisco.com> <1177486453.6283.3.camel@bzorp.balabit> 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.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: syslog-bounces@lists.ietf.org [ re: DNS reverse mapping ] DNS is not secure, and isn't likely to be any time soon. Using DNS as any sort of security measure is just plain stupid. Either the other party possesses the private key material that matches their public key or they don't. If they don't, SSL will fail. If they do, then they're exactly who they say they are (or the private key material has leaked, at which point it's game over anyway). DNS should have nothing whatsoever to do with it. Any modern RFC that makes references to doing reverse lookups in a security context should be laughed out of the IETF. -- Carson _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Apr 25 04:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgcui-0000v4-3p; Wed, 25 Apr 2007 04:31:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgcug-0000rS-CP for syslog@ietf.org; Wed, 25 Apr 2007 04:31:46 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgcud-0000xY-7K for syslog@ietf.org; Wed, 25 Apr 2007 04:31:46 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH10007VOZIT9@szxga03-in.huawei.com> for syslog@ietf.org; Wed, 25 Apr 2007 16:30:54 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH1003MTOZH26@szxga03-in.huawei.com> for syslog@ietf.org; Wed, 25 Apr 2007 16:30:54 +0800 (CST) Received: from m19684 ([10.111.12.159]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH100CA6OZE1Q@szxml03-in.huawei.com> for syslog@ietf.org; Wed, 25 Apr 2007 16:30:53 +0800 (CST) Date: Wed, 25 Apr 2007 16:30:49 +0800 From: Miao Fuyou Subject: RE: [Syslog] Syslog-tls-09 draft - suggested change In-reply-to: To: 'Carson Gaspar' , syslog@ietf.org Message-id: <00a201c78714$07c03080$9f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceHDgBwas0Hc1mjSNubANl1MhK+lgABZlsQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: syslog-bounces@lists.ietf.org I think the working group had discussed the issue and actually the draft is written with: "trusted mechanism such as a preconfigured hosts table or DNSSEC" Regards, Miao > -----Original Message----- > From: Carson Gaspar [mailto:carson@taltos.org] > Sent: Wednesday, April 25, 2007 3:47 PM > To: syslog@ietf.org > Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change > > [ re: DNS reverse mapping ] > > DNS is not secure, and isn't likely to be any time soon. > Using DNS as any sort of security measure is just plain stupid. > > Either the other party possesses the private key material > that matches their public key or they don't. If they don't, > SSL will fail. If they do, then they're exactly who they say > they are (or the private key material has leaked, at which > point it's game over anyway). DNS should have nothing > whatsoever to do with it. Any modern RFC that makes > references to doing reverse lookups in a security context > should be laughed out of the IETF. > > -- > Carson > > _______________________________________________ > 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 Apr 25 04:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcwI-0002t7-Bf; Wed, 25 Apr 2007 04:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcwH-0002sk-P8 for syslog@ietf.org; Wed, 25 Apr 2007 04:33:25 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgcwG-0001NS-76 for syslog@ietf.org; Wed, 25 Apr 2007 04:33:25 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH1007FWP262L@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 25 Apr 2007 16:32:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JH100056P252K@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 25 Apr 2007 16:32:30 +0800 (CST) Received: from m19684 ([10.111.12.159]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH100IR2P225A@szxml04-in.huawei.com> for syslog@ietf.org; Wed, 25 Apr 2007 16:32:29 +0800 (CST) Date: Wed, 25 Apr 2007 16:32:25 +0800 From: Miao Fuyou Subject: RE: [Syslog] Syslog-tls-09 draft - suggested change In-reply-to: To: 'Chris Lonvick' , 'Eliot Lear' Message-id: <00a301c78714$40fa4e30$9f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceGfOnNOgwZB1R4SFiYcjTqfB1Z/wAj6XcA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: syslog@ietf.org, 'David Harrington' 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: , Errors-To: syslog-bounces@lists.ietf.org > > There is also a matter of what an application is supposed > to do when > > logging fails. Some applications should proceed uninterrupted. > > Others may need to block. I don't know whether text is > appropriate. > > It's not part of the protocol, but it does fall under > common modes of > > failure. The reason this would be an issue with TLS (or > BEEP for that > > matter) and not with UDP is that one doesn't block with UDP. > > I think Eliot is on the right track. However, I wouldn't > differentiate between the actions that a sender or receiver > is to take when authentication fails - both cases should have > a recommendation that the device log the failure _and_ > attempt to inform the administrator of the problem. This > might be pop-ups to the unsuspecting user who won't know what > to do about it, it might be messages printed on the console, > it might be a blinky light on the printer, etc. (Most > networked printers that I'm seeing these days have nice > displays that are starting to give informative > messages.) My perception is logging does not necesarily mean send events over network to syslog server,. Webopedia says log is "to record an action". If there is no syslog connection available, it is still possible to log the message in local storage. I just checked the printer in my office, it does log events locally. It is reckoned the buffer for log is very small because there are only 50 records, acutally the printer fails from time to time:-( Thanks, Miao _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Apr 25 05:40:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgdyd-00015k-Rs; Wed, 25 Apr 2007 05:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgdyd-00013u-GM for syslog@ietf.org; Wed, 25 Apr 2007 05:39:55 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgdyc-0004yF-5v for syslog@ietf.org; Wed, 25 Apr 2007 05:39:55 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2007 11:39:53 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3P9drYE022606; Wed, 25 Apr 2007 11:39:53 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp513.cisco.com [10.61.66.1]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3P9dqlZ012624; Wed, 25 Apr 2007 09:39:52 GMT Message-ID: <462F21E8.2070900@cisco.com> Date: Wed, 25 Apr 2007 11:39:52 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Miao Fuyou Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change References: <00a301c78714$40fa4e30$9f0c6f0a@china.huawei.com> In-Reply-To: <00a301c78714$40fa4e30$9f0c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=485; t=1177493993; x=1178357993; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Syslog-tls-09=20draft=20-=20suggested=20ch ange |Sender:=20; bh=JUwjewpv3IASX96lzWg+emJf0sC2V8DQWf0f4Yibwno=; b=i7lC1e1F3UtshA8fSB1K0th5ouwq0ZG1VcL61yOfd3P3YPu05+fSeCHK8a0VEVm8F/NhIJ2X vlQTgr2a89YshEHxTd7xaxagvMPzdft2QzjtQEPLUsglS3el1UAOnnrV; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: syslog@ietf.org, 'David Harrington' 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: , Errors-To: syslog-bounces@lists.ietf.org Miao Fuyou wrote: > My perception is logging does not necesarily mean send events over network > to syslog server,. Webopedia says log is "to record an action". If there is > no syslog connection available, it is still possible to log the message in > local storage. > Right. The issue here, however, is that you've configured an application or a system to use the network and that has failed. What you do next requires a bit of care. That's all I'm saying. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog