From syslog-bounces@lists.ietf.org Wed Feb 01 07:24:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4H22-0001LV-Qt; Wed, 01 Feb 2006 07:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4H20-0001K4-97 for syslog@megatron.ietf.org; Wed, 01 Feb 2006 07:24:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12311 for ; Wed, 1 Feb 2006 07:22:27 -0500 (EST) Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4HCy-0002fL-6f for syslog@ietf.org; Wed, 01 Feb 2006 07:35:36 -0500 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 80D764C0DC for ; Wed, 1 Feb 2006 13:23:39 +0100 (CET) Subject: Re: [Syslog] Threat model requirements discussion From: Balazs Scheidler To: Tom Petch In-Reply-To: <045201c6268c$b2053340$0601a8c0@pc6> References: <025101c6229d$7a8cde60$0601a8c0@pc6> <00ea01c62651$5e9a1300$0601a8c0@pc6> <1138714483.5005.28.camel@bzorp.balabit> <045201c6268c$b2053340$0601a8c0@pc6> Content-Type: text/plain Date: Wed, 01 Feb 2006 13:24:36 +0100 Message-Id: <1138796676.19234.28.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-01-31 at 18:34 +0100, Tom Petch wrote: > ----- Original Message ----- > From: "Balazs Scheidler" > To: "Tom Petch" > Cc: "Chris Lonvick" ; ; > > Sent: Tuesday, January 31, 2006 2:34 PM > Subject: Re: [Syslog] Threat model requirements discussion > > > > On Tue, 2006-01-31 at 11:28 +0100, Tom Petch wrote: > > > > > So I want to see a simpler solution - eg keyed hash - first and a more > complex > > > one which includes encryption as phase two (2007?). > > > > > > And yes, my views are coloured by SNMP which I have worked with for many > years, > > > where, as I have said before, users tell me they must have encryption but it > > > usually turns out they have not yet learnt about the concept of differing > > > threats. > > > > My points: > > * syslog is way different than SNMP traps, it really does contain > > sensitive information (not just link up/down). > > * adding TLS is very simple from the implementation point of view: > > adding a new transport layer to the software stack does not really > > change the software (can be done without changing the software at all > > via a wrapper like stunnel), message signatures is a big change in _all_ > > senders > > * adding TLS is very simple from the protocol specification point of > > view: define a way to wrap messages to an "envelope" (e.g. NL > > termination, or byte counter) and wrap messages into TLS > > * adding message signatures is difficult both implementation and > > specification wise, syslog-sign is far from being simple > > > > I'd say that the specification and implementation something like > > syslog-sign is at least 3-5 times as big work as doing the same with a > > drop-in package like TLS. > > > > Note that I did not say syslog-sign, just keyed hash, so it is misleading to > estimate the implementation effort when we are debating requirements (even if a > possible design which may or may not match the requirements already exists). > > The kind of issues that need solving with SSH and/or TLS > - reliable transport needed, eg TCP; when is the connection established, when is > it taken down? As I said the communication model is the same as current syslog to make the implementation possible with no real program changes. Thus the connection is established from the sender to the receiver, right before messages are sent. The connection might be kept opened for a period of time with a sane timeout value. > > - what port is used? if SSH/TLS, how is syslog traffic differentiated? if not, > will IANA grant yet another port (or ports as allowed by syslog MIB)? A separate port number would probably be necessary. > > - with multiple flows, are they multiplexed over a single connection? yes, just like they are now. > > - which end is SSH/TLS client, which server? client and server in security > protocols have significant impact on what security credentials are stored where, > what customisation is needed before the system can be used (do you allow an > unattended hub to perform a leap of faith?) the one initiating the connection is client, the other presumably the server :) authentication has already been discussed, authentication should be warmly recommended (maybe even required). how the credentials are stored and distributed are an implementation issue, the credentials are X.509 certificates, they could be stored in secure storage or as files in PEM format. > > - what is the user to which these security credentials relate, particularly for > authentication, how is the user identified? no user is identified, the credentials identify the "hop", thus the infrastructure element. > > - is authorisation to use secure syslog required? do you mean authentication here? authorization is again an imlpementation issue, it could be implemented as a list of trusted DNs, a single trusted CA which is required to sign all keys. Again authentication would be performed for _devices_ and not individual messages, e.g. it is not possible to verify the authenticity of separate messages, but it is an independent goal. > > - is another system needed to keep security credentials up to date, eg RADIUS? no, RADIUS is password based, TLS is RSA keypair based. Keys need to be distributed to all end-nodes. (to be more precise a certificate, the matching private key, the CA certificate(s) and a revocation list (or access to an online revocation service) But again, it is again an implementation issue how keys are distributed. > > Keyed hash? many of these issues disappear (and it could be end-to-end security > were that a requirement, none of those concerns about relays). and not only the keys need to be distributed but the software running in _each_ device. we have customers who still use AIX 4.3 and Solaris 7, not to mention the necessity for firmware upgrades in various embedded devices. I think we already achieved something if we focus securing the syslog infrastructure (relay and center) first and then go on to other issues like message based authentication. Keyed hash also have a list of questions what you asked about TLS above: * how to get the shared key to the box? * what about replay detection? you need a sequence number, then what about losing messages? * if you want reliable transport then the same questions with connection establishment come up, if you stick with UDP, then what happens with lost messages, and how does this affect your sequence numbering? > > syslog is precisely like SNMP traps No, it isn't, but it probably depends on how you use it. syslog contains debugging information generated by applications which might not exactly know what they are dumping: it might contain sensitive information like passwords, mail bodies and instant messages. If you enable debugging on a router, it does not send that information as SNMP traps but it does send it in syslog. > when you look at the wish that some users > express for encyption, namely both are a one way flow over a datagram transport > with some application client out there somewhere:-) And as I said, these issues > have been mulled over by isms and netconf and, a year or so on, there are no > obvious solutions. TLS may allow you to use off the shelf modules to achieve a > quick code package but, and SNMPv3 is the case study here, the code package is > not enough, the system must be sufficiently easy to implement if we are going to > see it used. _It is_ being used. Just google around searching for "syslog-ng stunnel" I've just tried and found 133000 hits. You can even read step-by-step articles how to set this up on sun.com: http://www.sun.com/bigadmin/features/articles/syslog_ng.html (Stunnel + syslog-ng is a hack, I know that myself.) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 01 07:47:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4HO8-000732-OC; Wed, 01 Feb 2006 07:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4HO1-000706-9v for syslog@megatron.ietf.org; Wed, 01 Feb 2006 07:47:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16241 for ; Wed, 1 Feb 2006 07:45:15 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4HYV-0003S7-9y for syslog@ietf.org; Wed, 01 Feb 2006 07:58:24 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 36BA727C02F; Wed, 1 Feb 2006 13:39:09 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07862-06; Wed, 1 Feb 2006 13:39:09 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id EF46027C02E; Wed, 1 Feb 2006 13:39:08 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 13:46:07 +0100 Subject: RE: [Syslog] Threat model requirements discussion Date: Wed, 1 Feb 2006 13:46:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4364@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Syslog] Threat model requirements discussion thread-index: AcYnLA5fgMUyPlyTSLaIhVktpueDOwAAT4FQ From: "Rainer Gerhards" To: "Balazs Scheidler" , "Tom Petch" X-OriginalArrivalTime: 01 Feb 2006 12:46:07.0310 (UTC) FILETIME=[785E5EE0:01C6272D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > when you look at the wish that some users > > express for encyption, namely both are a one way flow over=20 > a datagram transport > > with some application client out there somewhere:-) And as=20 > I said, these issues > > have been mulled over by isms and netconf and, a year or so=20 > on, there are no > > obvious solutions. TLS may allow you to use off the shelf=20 > modules to achieve a > > quick code package but, and SNMPv3 is the case study here,=20 > the code package is > > not enough, the system must be sufficiently easy to=20 > implement if we are going to > > see it used. >=20 > _It is_ being used. Just google around searching for=20 > "syslog-ng stunnel" > I've just tried and found 133000 hits. You can even read step-by-step > articles how to set this up on sun.com: >=20 > http://www.sun.com/bigadmin/features/articles/syslog_ng.html >=20 > (Stunnel + syslog-ng is a hack, I know that myself.) If you google for just syslog + stunnel=20 http://www.google.com/search?q=3Dsyslog+stunnel&hl=3Den&lr=3D&safe=3Doff&= start=3D0 &sa=3DN you'll find 212,000 results - and many of them seem to be quite related to what we discuss. tls protected syslog is something that is widely used. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 07 09:09:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TXa-0007zl-4I; Tue, 07 Feb 2006 09:09:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TXX-0007ut-9o for syslog@megatron.ietf.org; Tue, 07 Feb 2006 09:09:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28262 for ; Tue, 7 Feb 2006 09:08:02 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Tjk-0001Ct-VC for syslog@ietf.org; Tue, 07 Feb 2006 09:22:33 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2006 06:09:34 -0800 X-IronPort-AV: i="4.02,94,1139212800"; d="scan'208"; a="1774144242:sNHT30147180" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k17E9Xc2013664 for ; Tue, 7 Feb 2006 06:09:33 -0800 (PST) Date: Tue, 7 Feb 2006 06:09:32 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: [Syslog] Coming to consensus on syslog threats X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, In reviewing the messages around the threats to the syslog protocol, it appears that the priority of threats is as follows: Primary: Modification Disclosure Masquerading Secondary: Message stream modification Not highly considered: DoS Traffic Analysis Disclosure has been controversial in the discussions. It has been noted that syslog messages are freeform text and the possibility of sending sensitive information will always exist. This is all the more true if high levels of debugging are enabled. Also from the list, it appears that the use of TLS is supported and will address these threats. I will ask for volunteers to write syslog-protocol-tls and get it through the process. It looks like syslog-protocol and syslog-transport-udp are very close to being finished. I'd like to wrap those up and fully concentrate on syslog-transport-tls, syslog-sign, and syslog-device-mib. syslog-transport-tls will have to go through the process at the same time as syslog-protocol and syslog-transport-udp. I'll ask Rainer and Anton to please be patient while we complete this final document. With that, I'll propose the following Charter revision and Milestones. ---vvv--- Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in the INFORMATIONAL RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the at the start. Additional testing has shown that as long as the is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the at the start of the message and will introduce protocol versioning. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. The primary attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. The secondary threat of message stream modification can be addressed by a mechanism that will verify the end-to-end integrity and sequence of messages. The Working Group feels that these aspects may be addressed by a dissociated signature upon sent messages. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that requires a secure transport for the delivery of syslog messages. - A document will be produced to describe the MIB for syslog entities. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. Milestones: Nov 2006 Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit a document that defines a message signing and ordering mechanism to the IESG for consideration as a PROPOSED STANDARD ---^^^--- Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 08 04:26:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6laV-0001cs-0m; Wed, 08 Feb 2006 04:26:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6laT-0001ai-AC for syslog@megatron.ietf.org; Wed, 08 Feb 2006 04:26:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03265 for ; Wed, 8 Feb 2006 04:24:27 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6lmy-0004OI-29 for syslog@ietf.org; Wed, 08 Feb 2006 04:39:09 -0500 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 <0IUD00AKB3YIFB@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 08 Feb 2006 17:35:06 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUD00GRI3QV9T@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 08 Feb 2006 17:35:06 +0800 (CST) Received: from m19684 ([10.111.12.90]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUD00JNH3UI4V@szxml02-in.huawei.com>; Wed, 08 Feb 2006 17:32:43 +0800 (CST) Date: Wed, 08 Feb 2006 17:20:40 +0800 From: Miao Fuyou Subject: RE: [Syslog] Coming to consensus on syslog threats In-reply-to: To: "'Chris Lonvick'" Message-id: <00e301c62c90$ee391930$5a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7BIT Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I and Yuzhi would like to edit a draft on syslog tls transport. We will get the draft posted ASAP. Miao miaofy@huawei.com -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick Sent: Tuesday, February 07, 2006 10:10 PM To: syslog@ietf.org Subject: [Syslog] Coming to consensus on syslog threats Hi, In reviewing the messages around the threats to the syslog protocol, it appears that the priority of threats is as follows: Primary: Modification Disclosure Masquerading Secondary: Message stream modification Not highly considered: DoS Traffic Analysis Disclosure has been controversial in the discussions. It has been noted that syslog messages are freeform text and the possibility of sending sensitive information will always exist. This is all the more true if high levels of debugging are enabled. Also from the list, it appears that the use of TLS is supported and will address these threats. I will ask for volunteers to write syslog-protocol-tls and get it through the process. It looks like syslog-protocol and syslog-transport-udp are very close to being finished. I'd like to wrap those up and fully concentrate on syslog-transport-tls, syslog-sign, and syslog-device-mib. syslog-transport-tls will have to go through the process at the same time as syslog-protocol and syslog-transport-udp. I'll ask Rainer and Anton to please be patient while we complete this final document. With that, I'll propose the following Charter revision and Milestones. ---vvv--- Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in the INFORMATIONAL RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the at the start. Additional testing has shown that as long as the is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the at the start of the message and will introduce protocol versioning. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. The primary attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. The secondary threat of message stream modification can be addressed by a mechanism that will verify the end-to-end integrity and sequence of messages. The Working Group feels that these aspects may be addressed by a dissociated signature upon sent messages. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that requires a secure transport for the delivery of syslog messages. - A document will be produced to describe the MIB for syslog entities. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. Milestones: Nov 2006 Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD. Nov 2006 Submit a document that defines a message signing and ordering mechanism to the IESG for consideration as a PROPOSED STANDARD ---^^^--- Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 09 12:08:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FHF-0002cP-5C; Thu, 09 Feb 2006 12:08:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FHC-0002bE-R5 for syslog@megatron.ietf.org; Thu, 09 Feb 2006 12:08:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09122 for ; Thu, 9 Feb 2006 12:06:21 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7FTs-0007N4-Hg for syslog@ietf.org; Thu, 09 Feb 2006 12:21:21 -0500 Received: from pc6 (1Cust57.tnt28.lnd4.gbr.da.uu.net [62.188.156.57]) by astro.systems.pipex.net (Postfix) with SMTP id 82E4FE0005AF; Thu, 9 Feb 2006 17:06:09 +0000 (GMT) Message-ID: <04c501c62d92$9ff8ddc0$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Coming to consensus on syslog threats Date: Thu, 9 Feb 2006 13:21:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.8 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris I notice that the body of the proposal takes a neutral stance towards which secure transport but then specifies TLS in the milestones. I suggest that you keep the milestones neutral as well, not because I expect any different but because I think it more acceptable to those that will review it. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Tuesday, February 07, 2006 3:09 PM Subject: [Syslog] Coming to consensus on syslog threats > Hi, > > In reviewing the messages around the threats to the syslog protocol, it > appears that the priority of threats is as follows: > > Primary: > Modification > Disclosure > Masquerading > > Secondary: > Message stream modification > > Not highly considered: > DoS > Traffic Analysis > > > Disclosure has been controversial in the discussions. It has been noted > that syslog messages are freeform text and the possibility of sending > sensitive information will always exist. This is all the more true if > high levels of debugging are enabled. > > Also from the list, it appears that the use of TLS is supported and will > address these threats. I will ask for volunteers to write > syslog-protocol-tls and get it through the process. > > It looks like syslog-protocol and syslog-transport-udp are very close to > being finished. I'd like to wrap those up and fully concentrate on > syslog-transport-tls, syslog-sign, and syslog-device-mib. > syslog-transport-tls will have to go through the process at the same time > as syslog-protocol and syslog-transport-udp. I'll ask Rainer and Anton to > please be patient while we complete this final document. > > > With that, I'll propose the following Charter revision and Milestones. > > ---vvv--- > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it has > some known security problems which were documented in the INFORMATIONAL > RFC 3164. > > The goal of this working group is to address the security and integrity > problems, and to standardize the syslog protocol, transport, and a select > set of mechanisms in a manner that considers the ease of migration between > and the co-existence of existing versions and the standard. > > Reviews have shown that there are very few similarities between the > message formats generated by heterogeneous systems. In fact, the only > consistent commonality between messages is that all of them contain the > at the start. Additional testing has shown that as long as the > is present in a syslog message, all tested receivers will accept any > generated message as a valid syslog message. In designing a standard > syslog message format, this Working Group will retain the at the > start of the message and will introduce protocol versioning. Along these > same lines, many different charsets have been used in syslog messages > observed in the wild but no indication of the charset has been given in > any message. The Working Group also feels that multiple charsets will not > be beneficial to the community; much code would be needed to distinguish > and interpret different charsets. For compatibility with existing > implementations, the Working Group will allow that messages may still be > sent that do not indicate the charset used. However, the Working Group > will recommend that messages contain a way to identify the charset used > for the message, and will also recommend a single default charset. > > syslog has traditionally been transported over UDP and this WG has already > defined RFC 3195 for the reliable transport for the syslog messages. The > WG will separate the UDP transport from the protocol so that others may > define additional transports in the future. > > The threats that this WG will primarily address are modification, > disclosure, and masquerading. A secondary threat is message stream > modification. Threats that will not be addressed by this WG are DoS and > traffic analysis. The primary attacks may be thwarted by a secure > transport. However, it must be remembered that a great deal of the > success of syslog has been attributed to its ease of implementation and > relatively low maintenance level. The Working Group will consider those > factors, as well as current implementations, when deciding upon a secure > transport. The secondary threat of message stream modification can be > addressed by a mechanism that will verify the end-to-end integrity and > sequence of messages. The Working Group feels that these aspects may be > addressed by a dissociated signature upon sent messages. > > > > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document > that will provide a means to convey structured data. > > - A document will be produced that describes a standardized UDP > transport for syslog. > > - A document will be produced that requires a secure transport for the > delivery of syslog messages. > > - A document will be produced to describe the MIB for syslog entities. > > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication. > > > Milestones: > > Nov 2006 Submit Syslog Protocol to the IESG for consideration as a > PROPOSED STANDARD. > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for > consideration as a PROPOSED STANDARD. > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for > consideration as a PROPOSED STANDARD. > Nov 2006 Submit Syslog Device MIB to IESG for consideration as a > PROPOSED STANDARD. > Nov 2006 Submit a document that defines a message signing and > ordering mechanism to the IESG for consideration as a > PROPOSED STANDARD > > > ---^^^--- > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 09 12:45:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Fr8-0003It-26; Thu, 09 Feb 2006 12:45:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Fqd-0003Co-3y for syslog@megatron.ietf.org; Thu, 09 Feb 2006 12:44:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12669 for ; Thu, 9 Feb 2006 12:42:54 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7G3F-0000RO-Q5 for syslog@ietf.org; Thu, 09 Feb 2006 12:57:55 -0500 Subject: Re: [Syslog] Coming to consensus on syslog threats From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: Content-Type: text/plain Date: Thu, 09 Feb 2006 18:44:20 +0100 Message-Id: <1139507060.6415.6.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-02-07 at 06:09 -0800, Chris Lonvick wrote: > Hi, > > In reviewing the messages around the threats to the syslog protocol, it > appears that the priority of threats is as follows: > Cool. :) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Feb 11 16:13:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F823r-00066Z-1a; Sat, 11 Feb 2006 16:13:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F823q-00066U-A7 for syslog@megatron.ietf.org; Sat, 11 Feb 2006 16:13:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29552 for ; Sat, 11 Feb 2006 16:11:58 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F82H7-0000M4-EJ for syslog@ietf.org; Sat, 11 Feb 2006 16:27:26 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2006 13:13:33 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1BLDWKU009706; Sat, 11 Feb 2006 13:13:32 -0800 (PST) Date: Sat, 11 Feb 2006 13:13:32 -0800 (PST) From: Chris Lonvick To: Miao Fuyou Subject: RE: [Syslog] Coming to consensus on syslog threats In-Reply-To: <00e301c62c90$ee391930$5a0c6f0a@china.huawei.com> Message-ID: References: <00e301c62c90$ee391930$5a0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Miao and Yuzhi, As Tom Petch pointed out we do need to establish that a TLS transport will address the threats we have described. Would you briefly outline how you propose to utilize TLS to address Modification, Disclosure, Masquerading? (Others can jump in here with more comments and concerns so the document can get a good start.) Once we establish that I believe we can accept your offer to write the document. Many thanks, Chris On Wed, 8 Feb 2006, Miao Fuyou wrote: > > I and Yuzhi would like to edit a draft on syslog tls transport. We will get > the draft posted ASAP. > > Miao > miaofy@huawei.com > > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Chris Lonvick > Sent: Tuesday, February 07, 2006 10:10 PM > To: syslog@ietf.org > Subject: [Syslog] Coming to consensus on syslog threats > > > Hi, > > In reviewing the messages around the threats to the syslog protocol, it > appears that the priority of threats is as follows: > > Primary: > Modification > Disclosure > Masquerading > > Secondary: > Message stream modification > > Not highly considered: > DoS > Traffic Analysis > > > Disclosure has been controversial in the discussions. It has been noted > that syslog messages are freeform text and the possibility of sending > sensitive information will always exist. This is all the more true if > high levels of debugging are enabled. > > Also from the list, it appears that the use of TLS is supported and will > address these threats. I will ask for volunteers to write > syslog-protocol-tls and get it through the process. > > It looks like syslog-protocol and syslog-transport-udp are very close to > being finished. I'd like to wrap those up and fully concentrate on > syslog-transport-tls, syslog-sign, and syslog-device-mib. > syslog-transport-tls will have to go through the process at the same time > as syslog-protocol and syslog-transport-udp. I'll ask Rainer and Anton to > please be patient while we complete this final document. > > > With that, I'll propose the following Charter revision and Milestones. > > ---vvv--- > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it has > some known security problems which were documented in the INFORMATIONAL RFC > 3164. > > The goal of this working group is to address the security and integrity > problems, and to standardize the syslog protocol, transport, and a select > set of mechanisms in a manner that considers the ease of migration between > and the co-existence of existing versions and the standard. > > Reviews have shown that there are very few similarities between the message > formats generated by heterogeneous systems. In fact, the only consistent > commonality between messages is that all of them contain the at the > start. Additional testing has shown that as long as the is present in > a syslog message, all tested receivers will accept any generated message as > a valid syslog message. In designing a standard syslog message format, this > Working Group will retain the at the start of the message and will > introduce protocol versioning. Along these same lines, many different > charsets have been used in syslog messages observed in the wild but no > indication of the charset has been given in any message. The Working Group > also feels that multiple charsets will not be beneficial to the community; > much code would be needed to distinguish and interpret different charsets. > For compatibility with existing implementations, the Working Group will > allow that messages may still be sent that do not indicate the charset used. > However, the Working Group will recommend that messages contain a way to > identify the charset used for the message, and will also recommend a single > default charset. > > syslog has traditionally been transported over UDP and this WG has already > defined RFC 3195 for the reliable transport for the syslog messages. The WG > will separate the UDP transport from the protocol so that others may define > additional transports in the future. > > The threats that this WG will primarily address are modification, > disclosure, and masquerading. A secondary threat is message stream > modification. Threats that will not be addressed by this WG are DoS and > traffic analysis. The primary attacks may be thwarted by a secure > transport. However, it must be remembered that a great deal of the > success of syslog has been attributed to its ease of implementation and > relatively low maintenance level. The Working Group will consider those > factors, as well as current implementations, when deciding upon a secure > transport. The secondary threat of message stream modification can be > addressed by a mechanism that will verify the end-to-end integrity and > sequence of messages. The Working Group feels that these aspects may be > addressed by a dissociated signature upon sent messages. > > > > - A document will be produced that describes a standardized syslog protocol. > A mechanism will also be defined in this document that will provide a means > to convey structured data. > > - A document will be produced that describes a standardized UDP transport > for syslog. > > - A document will be produced that requires a secure transport for the > delivery of syslog messages. > > - A document will be produced to describe the MIB for syslog entities. > > - A document will be produced that describes a standardized mechanism to > sign syslog messages to provide integrity checking and source > authentication. > > > Milestones: > > Nov 2006 Submit Syslog Protocol to the IESG for consideration as a > PROPOSED STANDARD. > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for > consideration as a PROPOSED STANDARD. > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for > consideration as a PROPOSED STANDARD. > Nov 2006 Submit Syslog Device MIB to IESG for consideration as a > PROPOSED STANDARD. > Nov 2006 Submit a document that defines a message signing and > ordering mechanism to the IESG for consideration as a > PROPOSED STANDARD > > > ---^^^--- > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Feb 11 16:12:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F822K-0005Rp-D1; Sat, 11 Feb 2006 16:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F822I-0005Rg-Lq for syslog@megatron.ietf.org; Sat, 11 Feb 2006 16:12:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29484 for ; Sat, 11 Feb 2006 16:10:22 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F82FZ-0000KD-3j for syslog@ietf.org; Sat, 11 Feb 2006 16:25:50 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2006 13:11:57 -0800 X-IronPort-AV: i="4.02,105,1139212800"; d="scan'208"; a="403844386:sNHT27553444" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1BLBtKU009304; Sat, 11 Feb 2006 13:11:56 -0800 (PST) Date: Sat, 11 Feb 2006 13:11:55 -0800 (PST) From: Chris Lonvick To: Tom Petch Subject: Re: [Syslog] Coming to consensus on syslog threats In-Reply-To: <04c501c62d92$9ff8ddc0$0601a8c0@pc6> Message-ID: References: <04c501c62d92$9ff8ddc0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Tom, You are correct. I'll change that to: Nov 2006 Submit a secure syslog transport mapping document to the IESG for consideration as a PROPOSED STANDARD. Thanks, Chris On Thu, 9 Feb 2006, Tom Petch wrote: > Chris > > I notice that the body of the proposal takes a neutral stance towards which > secure transport but then specifies TLS in the milestones. I suggest that you > keep the milestones neutral as well, not because I expect any different but > because I think it more acceptable to those that will review it. > > Tom Petch ---remainder deleted for brevity--- _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 13 02:46:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8YQC-00079L-3h; Mon, 13 Feb 2006 02:46:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8YQA-00079D-IW for syslog@megatron.ietf.org; Mon, 13 Feb 2006 02:46:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22125 for ; Mon, 13 Feb 2006 02:45:08 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8Yd9-0005xI-S4 for syslog@ietf.org; Mon, 13 Feb 2006 03:00:56 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 0F31027C055 for ; Mon, 13 Feb 2006 08:38:32 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04593-04 for ; Mon, 13 Feb 2006 08:38:31 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C118927C03B for ; Mon, 13 Feb 2006 08:38:31 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 08:46:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Feb 2006 08:46:10 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E443B@grfint2.intern.adiscon.com> Thread-Topic: implementing -protocol and -transport-udp thread-index: AcYwcY6Mb48sroTHTPSrRuSR4gkfoA== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 13 Feb 2006 07:46:07.0236 (UTC) FILETIME=[8C720C40:01C63071] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] implementing -protocol and -transport-udp X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi all, it is nice to see us making progress. However, as we need to finish (and start) a secure transport before we can submit -protocol and -transport-udp, I have a question to the implementors here on the list. -transport-udp is basically finished and -protocol just needs a brush up (aka "hopefully soon finished"). I wonder if some folks would like to implement these drafts, even before they are submitted (aka "soon" ;)). I see several advantages in doing so: - we get real-world experience about what is practical and what not - this enables us to create a better standard - we can do interop-testing between different implementations, again clarifying how good the text is - we prepare for rapid deployment once the draft has been submitted - we (and our users) can enjoy the benefits of the standardized format earlier - we have implementation reports at hand when the IESG asks about vendor and user acceptance Remember that both drafts are essentially ready for publication - what is missing is "just" a secure transport, which does not interfere with what we currently have. Of course, implementations could lead to new discussions and eventual changes to the draft. I think is is better to have this now then when it is released.=20 I already did a test implementation in rsyslog. It prooved to be quite easy and quickly doable. If others agreee to implement it too, I would go ahead and also see that we implement it in our commercial packages. I hope that my proposal is a good one and that other implementors would like to participate. Please reply on list if you think this would be a good idea or not. Many thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 13 08:12:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8dVD-0003CK-BY; Mon, 13 Feb 2006 08:12:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8dVB-0003AE-Kj for syslog@megatron.ietf.org; Mon, 13 Feb 2006 08:12:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18447 for ; Mon, 13 Feb 2006 08:10:39 -0500 (EST) Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8din-00083r-Ug for syslog@ietf.org; Mon, 13 Feb 2006 08:26:30 -0500 Received: from globalsuite.gtcorp.com (host09.bosrc.hyatthsiagx.com [206.165.43.9]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id CC3EDE8; Mon, 13 Feb 2006 06:12:15 -0700 (MST) Received: from DJYXPY41 (globalsuite.gtcorp.com [127.0.0.1]) by globalsuite.gtcorp.com (Postfix) with ESMTP id AEF4B19E43; Mon, 13 Feb 2006 06:12:14 -0700 (MST) From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] implementing -protocol and -transport-udp Date: Mon, 13 Feb 2006 08:12:02 -0500 Message-ID: <026001c6309f$16e99d20$0600a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYwcY6Mb48sroTHTPSrRuSR4gkfoAALPouQ In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E443B@grfint2.intern.adiscon.com> X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Just a point. -transport-udp and -transport-tls should be independent of each other, since one is based on udp and the other on tcp. I just want to be sure that is understood. -transport-udp and transport-tls should have a comparable interface to the rest of the syslog documents. Do we agree on that point? David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, February 13, 2006 2:46 AM > To: syslog@ietf.org > Subject: [Syslog] implementing -protocol and -transport-udp > > Hi all, > > it is nice to see us making progress. However, as we need to > finish (and > start) a secure transport before we can submit -protocol and > -transport-udp, I have a question to the implementors here on > the list. > -transport-udp is basically finished and -protocol just needs > a brush up > (aka "hopefully soon finished"). I wonder if some folks would like to > implement these drafts, even before they are submitted (aka > "soon" ;)). > I see several advantages in doing so: > > - we get real-world experience about what is practical and > what not - this enables us to create a better standard > - we can do interop-testing between different implementations, > again clarifying how good the text is > - we prepare for rapid deployment once the draft has been > submitted > - we (and our users) can enjoy the benefits of the standardized > format earlier > - we have implementation reports at hand when the IESG asks about > vendor and user acceptance > > Remember that both drafts are essentially ready for publication - what > is missing is "just" a secure transport, which does not interfere with > what we currently have. Of course, implementations could lead to new > discussions and eventual changes to the draft. I think is is better to > have this now then when it is released. > > I already did a test implementation in rsyslog. It prooved to be quite > easy and quickly doable. If others agreee to implement it too, I would > go ahead and also see that we implement it in our commercial packages. > > I hope that my proposal is a good one and that other > implementors would > like to participate. Please reply on list if you think this would be a > good idea or not. > > Many thanks, > Rainer > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 13 10:54:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8g1c-00065X-8q; Mon, 13 Feb 2006 10:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8g1a-00065O-DG for syslog@megatron.ietf.org; Mon, 13 Feb 2006 10:54:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02608 for ; Mon, 13 Feb 2006 10:52:17 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8gEi-00051K-2e for syslog@ietf.org; Mon, 13 Feb 2006 11:08:08 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id F221827C055; Mon, 13 Feb 2006 16:45:39 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15051-01; Mon, 13 Feb 2006 16:45:39 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 92ACD27C053; Mon, 13 Feb 2006 16:45:39 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 16:53:16 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] implementing -protocol and -transport-udp Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Feb 2006 16:53:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4459@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] implementing -protocol and -transport-udp thread-index: AcYwcY6Mb48sroTHTPSrRuSR4gkfoAALPouQAAW01hA= From: "Rainer Gerhards" To: X-OriginalArrivalTime: 13 Feb 2006 15:53:16.0746 (UTC) FILETIME=[9A9752A0:01C630B5] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org David, I agree on this point. But -transport-udp cross-references -protocol and -protocol must cross-reference -transport-tls (or whatever it will be named), so they must be sumbitted together even though there is no direct relationship between -transport-udp and -transport-tls. Rainer=20 > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, February 13, 2006 2:12 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] implementing -protocol and -transport-udp >=20 > Hi, >=20 > Just a point. -transport-udp and -transport-tls should be independent > of each other, since one is based on udp and the other on tcp. I just > want to be sure that is understood.=20 >=20 > -transport-udp and transport-tls should have a comparable interface to > the rest of the syslog documents. Do we agree on that point? >=20 > David Harrington > dbharrington@comcast.net >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Monday, February 13, 2006 2:46 AM > > To: syslog@ietf.org > > Subject: [Syslog] implementing -protocol and -transport-udp > >=20 > > Hi all, > >=20 > > it is nice to see us making progress. However, as we need to=20 > > finish (and > > start) a secure transport before we can submit -protocol and > > -transport-udp, I have a question to the implementors here on=20 > > the list. > > -transport-udp is basically finished and -protocol just needs=20 > > a brush up > > (aka "hopefully soon finished"). I wonder if some folks would like > to > > implement these drafts, even before they are submitted (aka=20 > > "soon" ;)). > > I see several advantages in doing so: > >=20 > > - we get real-world experience about what is practical and > > what not - this enables us to create a better standard > > - we can do interop-testing between different implementations, > > again clarifying how good the text is > > - we prepare for rapid deployment once the draft has been > > submitted > > - we (and our users) can enjoy the benefits of the standardized > > format earlier > > - we have implementation reports at hand when the IESG asks about > > vendor and user acceptance > >=20 > > Remember that both drafts are essentially ready for publication - > what > > is missing is "just" a secure transport, which does not interfere > with > > what we currently have. Of course, implementations could lead to new > > discussions and eventual changes to the draft. I think is is better > to > > have this now then when it is released.=20 > >=20 > > I already did a test implementation in rsyslog. It prooved to be > quite > > easy and quickly doable. If others agreee to implement it too, I > would > > go ahead and also see that we implement it in our commercial > packages. > >=20 > > I hope that my proposal is a good one and that other=20 > > implementors would > > like to participate. Please reply on list if you think this would be > a > > good idea or not. > >=20 > > Many thanks, > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 16 10:02:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9kds-000341-Hs; Thu, 16 Feb 2006 10:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9kdr-00033n-1F for syslog@megatron.ietf.org; Thu, 16 Feb 2006 10:01:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00224 for ; Thu, 16 Feb 2006 10:00:10 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ks3-0000Bw-Rz for syslog@ietf.org; Thu, 16 Feb 2006 10:16:42 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc11) with SMTP id <20060216150145m1100pmrv1e>; Thu, 16 Feb 2006 15:01:46 +0000 From: "David B Harrington" To: "'Miao Fuyou'" , "'Chris Lonvick'" , Subject: RE: [Syslog] Coming to consensus on syslog threats Date: Thu, 16 Feb 2006 10:01:39 -0500 Message-ID: <004701c63309$e48743b0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <01e101c632d6$aa7d5b10$5a0c6f0a@china.huawei.com> Thread-Index: AcYy1vpHQ+m5OrmeTyu1HVojl5xZIQAI41wA X-Spam-Score: 0.1 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Miao and Yuhzi, It would be easier if you used a consistent numbering/lettering scheme in your outline, so a reviewer can refer to your #2, and be unambiguous. I recommend adding the following as you expand the outline: 1) The Problem Description - what security threats need to be addressed for syslog environments (free of any discussion of TLS as the soution) Describe the relationships between the architectural syslog entities (sender vs receiver vs relay), and the threats to each entity and the connections between them (the discussion that has been happening recently on the list). 2) Introduction to TLS 2a) Include an introduction to how TLS works, free of any discussion of syslog, described in a high-level manner, for all those syslog users who do not have a background in TLS. A simple high-level description of the basic steps would be helpful. 2b) The threats that different features of TLS are designed to mitigate (your current #2). 3) How TLS addresses the syslog threats The threats to syslog (from #1 above) and how TLS threat mitigation (#2b above) applies to those threats in a syslog environment, possibly described in an architectural way: the connection fron sender to relay has the threat of disclosure, so the encryption features of TLS should be applied to that connection, etc. And I have these comments: 4) The WG has had a problem staying focused on security. I would avoid the discussion of the upgrade from syslog/TCP to syslog/tcp/tls in the document if possible. It is not currently in scope for this WG to discuss or standardize syslog/TCP, and mentioning syslog/tcp in the syslog/tls document could open a big rathole for those who want to discuss syslog/tcp before discussing syslog/tls. It can also lead to references between this document and a yet-to-be-written document, and that can get messy in the publication process. The best approach might be to have the charter state that there are two scenarios, but that this document only addresses syslog/tls, not syslog/tcp/tls, so you can totally ignore it in the syslog/tls document. 5) there has been some IETF work done on using TCP-based transport for NM protocols. If you haven't already looked at them, there might be some useful information about session management in the netconf -transport- drafts and in the snmp/tcp RFC. The ISMS WG will also need to address these issues, so don't be afraid to touch base with ISMS participants (but please don't cross-post). To my knowledge, none of the NM/secure-stream protocols have done a good job discussing TCP and session issues. You might also consult with Margaret Wasserman (netconf/ssh) and Juergen Shoenwaelder (snmp/tcp) to make sure the likely issues are identified. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com] > Sent: Thursday, February 16, 2006 3:55 AM > To: 'Chris Lonvick' > Cc: myz@huawei.com; ietfdbh@comcast.net > Subject: RE: [Syslog] Coming to consensus on syslog threats > > Chris, > > > Outline of Syslog TLS Transport > > 1, Security threats of syslog and security properties of TLS > 1) Syslog threats: modification, eavesdropping and masquerading > 2) TLS security properties: Integrity verification(Hash MAC with > MD5 and SHA1) to counter modification, Data origin authentication > (Certificate/signature along with hash MAC) to counter masquerading, > Confidentiality/Privacy(encryption/decryption with DES, AES, RC2 > etc) to counter disclosure. The security property of TLS counters > the threats to SYSLOG well. So the primary problem is how to > make SYSLOG work along with TLS. > > 2, Framework > SYSLOG sender works as TLS client and receiver as TLS server. > Note: It is possible to reverse the role, i.e. sender is TLS server. > But it looks odd and there is no obvious benefit observed right now. > > 3, Protocol Port > Two modes: SYSLOG over TLS and Upgrading TCP to TLS within SYSLOG > SYSLOG over TLS: SYSLOG communication happens after TLS Shakehand. > A port number should be allocated for the mode. UpgradingTCP to > TLS within SYSLOG: SYSLOG communication already happens over TCP > , server/client send a message to peer to ask the other party to > use TLS over the same TCP connection. This mode reuses SYSLOG > TCP transporting port number allocated (probably not available > right now). The draft only deals with the first scenarios. > > 4, Protocol Elements > 1) Initiation > The Sender should initiate a connection to the Receiver on the > appropriate port and then send the TLS ClientHello to begin the > TLS handshake. When the TLS handshake has finished the Sender > may then initiate the first SYSLOG message. > Note: We need to discuss what authentication we need: client > authenticated to server, server authenticated to client, or > both (mutual authentication) > > 2) Sending data > All SYSLOG message MUST be sent as TLS "application data". > We need to discuss: > a, Multiple SYSLOG messages in one TLS message or one SYSLOG > message in one TLS message? How to parse TLS message into several > SYSLOG messages in the multiplexing mode? > b, Does SYSLOG message truncation will affect the transport? > > 3) Closure > Sender MUST send a closure alert before closing the connection. > Sender which are unprepared to receive any more data MAY choose > not to wait for the Receiver 's closure alert and simply close > the connection, thus generating an incomplete close on the > Receiver side. Receiver MUST attempt to initiate an exchange > of closure alerts with the Sender before closing the connection. > Receiver MAY close the connection after sending the closure > alert, thus generating an incomplete close on the Sender side. > > 4) Relay > a, It seems expensive to a SYSLOG Relay to become TLS client > or server. Is it possible to relay SYSLOG message without > TLS processing? > b, There are hostname or IP in SYSLOG message header. A > implementation should not check the hostname/IP against TLS > certificate because of relay. > > 5, Security Consideration > 1, Coexist of TLS and SYSLOG-SIGN > TLS and SYSLOG-SIGN address quite different security requirements. > Data origin authentication of TLS authenticates whether the > data is received from the SENDER (device or relay), but the > SYSLOG-SIGN check whether the data originates from a specific > DEVICE. 2, Mutual Authentication? > > > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Sunday, February 12, 2006 5:14 AM > To: Miao Fuyou > Cc: syslog@ietf.org; ietfdbh@comcast.net; myz@huawei.com > Subject: RE: [Syslog] Coming to consensus on syslog threats > > > Hi Miao and Yuzhi, > > As Tom Petch pointed out we do need to establish that a TLS > transport will > address the threats we have described. Would you briefly > outline how you > propose to utilize TLS to address Modification, Disclosure, > Masquerading? > (Others can jump in here with more comments and concerns so > the document > can get a good start.) Once we establish that I believe we > can accept > your offer to write the document. > > Many thanks, > Chris > > > On Wed, 8 Feb 2006, Miao Fuyou wrote: > > > > > I and Yuzhi would like to edit a draft on syslog tls transport. We > > will get the draft posted ASAP. > > > > Miao > > miaofy@huawei.com > > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] > > On Behalf Of Chris Lonvick > > Sent: Tuesday, February 07, 2006 10:10 PM > > To: syslog@ietf.org > > Subject: [Syslog] Coming to consensus on syslog threats > > > > > > Hi, > > > > In reviewing the messages around the threats to the syslog > protocol, > > it appears that the priority of threats is as follows: > > > > Primary: > > Modification > > Disclosure > > Masquerading > > > > Secondary: > > Message stream modification > > > > Not highly considered: > > DoS > > Traffic Analysis > > > > > > Disclosure has been controversial in the discussions. It has been > > noted that syslog messages are freeform text and the possibility of > > sending sensitive information will always exist. This is > all the more > > true if high levels of debugging are enabled. > > > > Also from the list, it appears that the use of TLS is supported and > > will address these threats. I will ask for volunteers to write > > syslog-protocol-tls and get it through the process. > > > > It looks like syslog-protocol and syslog-transport-udp are > very close > > to being finished. I'd like to wrap those up and fully > concentrate on > > syslog-transport-tls, syslog-sign, and syslog-device-mib. > > syslog-transport-tls will have to go through the process at > the same > > time as syslog-protocol and syslog-transport-udp. I'll ask > Rainer and > > Anton to please be patient while we complete this final document. > > > > > > With that, I'll propose the following Charter revision and > Milestones. > > > > ---vvv--- > > > > Syslog is a de-facto standard for logging system events. > However, the > > protocol component of this event logging system has not > been formally > > documented. While the protocol has been very useful and > scalable, it > > has some known security problems which were documented in the > > INFORMATIONAL RFC 3164. > > > > The goal of this working group is to address the security and > > integrity problems, and to standardize the syslog protocol, > transport, > > and a select set of mechanisms in a manner that considers > the ease of > > migration between and the co-existence of existing versions and the > > standard. > > > > Reviews have shown that there are very few similarities between the > > message formats generated by heterogeneous systems. In > fact, the only > > consistent commonality between messages is that all of them contain > > the at the start. Additional testing has shown that > as long as > > the is present in a syslog message, all tested receivers will > > accept any generated message as a valid syslog message. In > designing > > a standard syslog message format, this Working Group will > retain the > > at the start of the message and will introduce protocol > > versioning. Along these same lines, many different > charsets have been > > used in syslog messages observed in the wild but no > indication of the > > charset has been given in any message. The Working Group > also feels > > that multiple charsets will not be beneficial to the > community; much > > code would be needed to distinguish and interpret different > charsets. > > For compatibility with existing implementations, the Working Group > > will allow that messages may still be sent that do not indicate the > > charset used. However, the Working Group will recommend > that messages > > contain a way to identify the charset used for the message, > and will > > also recommend a single default charset. > > > > syslog has traditionally been transported over UDP and this WG has > > already defined RFC 3195 for the reliable transport for the syslog > > messages. The WG will separate the UDP transport from the > protocol so > > that others may define additional transports in the future. > > > > The threats that this WG will primarily address are modification, > > > disclosure, and masquerading. A secondary threat is message stream > > modification. Threats that will not be addressed by this > WG are DoS > > and traffic analysis. The primary attacks may be thwarted > by a secure > > transport. However, it must be remembered that a great deal of the > > success of syslog has been attributed to its ease of implementation > > and relatively low maintenance level. The Working Group > will consider > > those factors, as well as current implementations, when > deciding upon > > a secure transport. The secondary threat of message stream > > modification can be addressed by a mechanism that will verify the > > end-to-end integrity and sequence of messages. The Working Group > > feels that these aspects may be addressed by a dissociated > signature > > upon sent messages. > > > > > > > > - A document will be produced that describes a standardized syslog > > protocol. A mechanism will also be defined in this document > that will > > provide a means to convey structured data. > > > > - A document will be produced that describes a standardized UDP > > transport for syslog. > > > > - A document will be produced that requires a secure > transport for the > > delivery of syslog messages. > > > > - A document will be produced to describe the MIB for > syslog entities. > > > > - A document will be produced that describes a standardized > mechanism > > to sign syslog messages to provide integrity checking and source > > authentication. > > > > > > Milestones: > > > > Nov 2006 Submit Syslog Protocol to the IESG for consideration as a > > PROPOSED STANDARD. > > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for > > consideration as a PROPOSED STANDARD. > > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for > > consideration as a PROPOSED STANDARD. > > Nov 2006 Submit Syslog Device MIB to IESG for consideration as a > > PROPOSED STANDARD. > > Nov 2006 Submit a document that defines a message signing and > > ordering mechanism to the IESG for consideration as a > > PROPOSED STANDARD > > > > > > ---^^^--- > > > > Thanks, > > Chris > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 17 10:06:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA77y-0007wE-OL; Fri, 17 Feb 2006 10:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA71i-0001Gk-OW for syslog@megatron.ietf.org; Fri, 17 Feb 2006 09:56:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07215 for ; Fri, 17 Feb 2006 09:14:18 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9wAT-0002DO-Sn for syslog@ietf.org; Thu, 16 Feb 2006 22:20:30 -0500 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 <0IUT00HIFA8BNN@szxga03-in.huawei.com> for syslog@ietf.org; Fri, 17 Feb 2006 11:12:11 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT00KNPA89V1@szxga03-in.huawei.com> for syslog@ietf.org; Fri, 17 Feb 2006 11:12:11 +0800 (CST) Received: from m19684 ([10.111.12.90]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUT00HWGAN480@szxml01-in.huawei.com>; Fri, 17 Feb 2006 11:21:04 +0800 (CST) Date: Fri, 17 Feb 2006 11:05:14 +0800 From: Miao Fuyou Subject: RE: [Syslog] Coming to consensus on syslog threats In-reply-to: To: "'Chris Lonvick'" Message-id: <000c01c6336e$f97d5ec0$5a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: 7BIT Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Chris, ---------------------OUTLINE---------------------------------- 1, Problem statement In reviewing the messages around the threats to the syslog protocol, it appears that the priority of threats is as follows: Primary: Modification Disclosure Masquerading Secondary: Message stream modification Not highly considered: DoS Traffic Analysis Disclosure has been controversial in the discussions. It has been noted that syslog messages are freeform text and the possibility of sending sensitive information will always exist. This is all the more true if high levels of debugging are enabled. Note: This section will summary the security threats to SYSLOG discussed on mailing list. 2, Introduction to TLS 2.1 How TLS works TLS establishes a private end-to-end connection, optionally including strong mutual authentication, using a variety of cryptosystems. Initially, a handshake phase uses three subprotocols to set up a record layer, authenticate endpoints, set parameters, as well as report errors. Then, there is an ongoing layered record protocol that handles encryption, compression, and reassembly for the remainder of the connection. Application data protocol, such as SYSLOG, works as a client of record protocol. 2.2 Security Property TLS security properties: Integrity verification (by Hash MAC with MD5 and SHA1), Data origin authentication (by Certificate/signature along with hash MAC), Confidentiality/Privacy (by encryption/decryption with DES, AES, RC2 etc), Anti-replay (by sequence number with integrity verification). 3, TLS to mitigate SYSLOG security threats Integrity verification to counter modification Data origin authentication to counter masquerading Confidentiality/Privacy to counter disclosure Anti-replay to counter message stream modification 4, Framework 4.1 Roles SYSLOG sender works as TLS client and receiver as TLS server. Note: It is possible to reverse the role, i.e. sender is TLS server. But it looks odd and there is no obvious benefit observed right now. Syslog relay can be either TLS client or server. 4.2 Protocol Port A port number should be allocated. 5, Protocol Elements 5.1 Initiation The Sender should initiate a connection to the Receiver on the appropriate port and then send the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished the Sender may then initiate the first SYSLOG message. Note: We need to define how syslog interpret the authentication certificates exchanged by handshake protocol. Note: We need to discuss what authentication we need: client authenticated to server, server authenticated to client, or both (mutual authentication) 5.2 Sending data All SYSLOG message MUST be sent as TLS "application data". We need to discuss: 5.2.1, Multiple SYSLOG messages in one TLS message or one SYSLOG message in one TLS message? How to parse TLS message into several SYSLOG messages in the multiplexing mode? 5.2.2, Does SYSLOG message truncation will affect the transport? 5.3 Closure Sender MUST send a closure alert before closing the connection. Sender which are unprepared to receive any more data MAY choose not to wait for the Receiver 's closure alert and simply close the connection, thus generating an incomplete close on the Receiver side. Receiver MUST attempt to initiate an exchange of closure alerts with the Sender before closing the connection. Receiver MAY close the connection after sending the closure alert, thus generating an incomplete close on the Sender side. 5.4 Relay 5.4.1 It seems expensive to a SYSLOG Relay to become TLS client or server. Is it possible to relay SYSLOG message without TLS processing? 5.4.2 There are hostname or IP in SYSLOG message header. A implementation should not check the hostname/IP against TLS certificate because of relay. 6 Security Consideration 6.1 Coexist of TLS and SYSLOG-SIGN TLS and SYSLOG-SIGN address quite different security requirements. Data origin authentication of TLS checks whether the data is received from the SENDER (device or relay), but the SYSLOG-SIGN check whether the data originates from a specific DEVICE. The syslog-sign certificate and tls client certificate are not exchangeable because a sender may be a relay. Another reason is sender may have several certificates for different purpose. 6.2 Mutual Authentication? -----Original Message----- From: Chris Lonvick [mailto:clonvick@cisco.com] Sent: Sunday, February 12, 2006 5:14 AM To: Miao Fuyou Cc: syslog@ietf.org; ietfdbh@comcast.net; myz@huawei.com Subject: RE: [Syslog] Coming to consensus on syslog threats Hi Miao and Yuzhi, As Tom Petch pointed out we do need to establish that a TLS transport will address the threats we have described. Would you briefly outline how you propose to utilize TLS to address Modification, Disclosure, Masquerading? (Others can jump in here with more comments and concerns so the document can get a good start.) Once we establish that I believe we can accept your offer to write the document. Many thanks, Chris On Wed, 8 Feb 2006, Miao Fuyou wrote: > > I and Yuzhi would like to edit a draft on syslog tls transport. We > will get the draft posted ASAP. > > Miao > miaofy@huawei.com > > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Chris Lonvick > Sent: Tuesday, February 07, 2006 10:10 PM > To: syslog@ietf.org > Subject: [Syslog] Coming to consensus on syslog threats > > > Hi, > > In reviewing the messages around the threats to the syslog protocol, > it appears that the priority of threats is as follows: > > Primary: > Modification > Disclosure > Masquerading > > Secondary: > Message stream modification > > Not highly considered: > DoS > Traffic Analysis > > > Disclosure has been controversial in the discussions. It has been > noted that syslog messages are freeform text and the possibility of > sending sensitive information will always exist. This is all the more > true if high levels of debugging are enabled. > > Also from the list, it appears that the use of TLS is supported and > will address these threats. I will ask for volunteers to write > syslog-protocol-tls and get it through the process. > > It looks like syslog-protocol and syslog-transport-udp are very close > to being finished. I'd like to wrap those up and fully concentrate on > syslog-transport-tls, syslog-sign, and syslog-device-mib. > syslog-transport-tls will have to go through the process at the same > time as syslog-protocol and syslog-transport-udp. I'll ask Rainer and > Anton to please be patient while we complete this final document. > > > With that, I'll propose the following Charter revision and Milestones. > > ---vvv--- > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in the > INFORMATIONAL RFC 3164. > > The goal of this working group is to address the security and > integrity problems, and to standardize the syslog protocol, transport, > and a select set of mechanisms in a manner that considers the ease of > migration between and the co-existence of existing versions and the > standard. > > Reviews have shown that there are very few similarities between the > message formats generated by heterogeneous systems. In fact, the only > consistent commonality between messages is that all of them contain > the at the start. Additional testing has shown that as long as > the is present in a syslog message, all tested receivers will > accept any generated message as a valid syslog message. In designing > a standard syslog message format, this Working Group will retain the > at the start of the message and will introduce protocol > versioning. Along these same lines, many different charsets have been > used in syslog messages observed in the wild but no indication of the > charset has been given in any message. The Working Group also feels > that multiple charsets will not be beneficial to the community; much > code would be needed to distinguish and interpret different charsets. > For compatibility with existing implementations, the Working Group > will allow that messages may still be sent that do not indicate the > charset used. However, the Working Group will recommend that messages > contain a way to identify the charset used for the message, and will > also recommend a single default charset. > > syslog has traditionally been transported over UDP and this WG has > already defined RFC 3195 for the reliable transport for the syslog > messages. The WG will separate the UDP transport from the protocol so > that others may define additional transports in the future. > > The threats that this WG will primarily address are modification, > disclosure, and masquerading. A secondary threat is message stream > modification. Threats that will not be addressed by this WG are DoS > and traffic analysis. The primary attacks may be thwarted by a secure > transport. However, it must be remembered that a great deal of the > success of syslog has been attributed to its ease of implementation > and relatively low maintenance level. The Working Group will consider > those factors, as well as current implementations, when deciding upon > a secure transport. The secondary threat of message stream > modification can be addressed by a mechanism that will verify the > end-to-end integrity and sequence of messages. The Working Group > feels that these aspects may be addressed by a dissociated signature > upon sent messages. > > > > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document that will > provide a means to convey structured data. > > - A document will be produced that describes a standardized UDP > transport for syslog. > > - A document will be produced that requires a secure transport for the > delivery of syslog messages. > > - A document will be produced to describe the MIB for syslog entities. > > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication. > > > Milestones: > > Nov 2006 Submit Syslog Protocol to the IESG for consideration as a > PROPOSED STANDARD. > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for > consideration as a PROPOSED STANDARD. > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for > consideration as a PROPOSED STANDARD. > Nov 2006 Submit Syslog Device MIB to IESG for consideration as a > PROPOSED STANDARD. > Nov 2006 Submit a document that defines a message signing and > ordering mechanism to the IESG for consideration as a > PROPOSED STANDARD > > > ---^^^--- > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 20 08:56:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBWG-0001tu-I0; Mon, 20 Feb 2006 08:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBWF-0001tp-Bk for syslog@ietf.org; Mon, 20 Feb 2006 08:56:03 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBBWE-0007vw-Qt for syslog@ietf.org; Mon, 20 Feb 2006 08:56:03 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2006 05:56:02 -0800 X-IronPort-AV: i="4.02,130,1139212800"; d="scan'208"; a="407610885:sNHT34014384" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1KDu0gf000324; Mon, 20 Feb 2006 05:56:00 -0800 (PST) Date: Mon, 20 Feb 2006 05:56:00 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Subject: RE: [Syslog] Coming to consensus on syslog threats In-Reply-To: <000c01c6336e$f97d5ec0$5a0c6f0a@china.huawei.com> Message-ID: References: <000c01c6336e$f97d5ec0$5a0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 All, I am willing to accept this as a WG document. There are some items that Miao has noted below. Let's get some discussion going now so Miao and Yuzhi can deliver a clean -00 ID. We're not going to have this ID available for the Dallas IETF meeting. As such, I'm not planning on calling a meeting there. Please let me know if you think otherwise. Some comments in-line. On Fri, 17 Feb 2006, Miao Fuyou wrote: > Hi Chris, > > ---------------------OUTLINE---------------------------------- > > > 1, Problem statement > In reviewing the messages around the threats to the syslog protocol, it > appears that the priority of threats is as follows: > Primary: > Modification > Disclosure > Masquerading > Secondary: > Message stream modification > Not highly considered: > DoS > Traffic Analysis > Disclosure has been controversial in the discussions. It has been noted > that syslog messages are freeform text and the possibility of sending > sensitive information will always exist. This is all the more true if high > levels of debugging are enabled. > Note: This section will summary the security threats to SYSLOG discussed on > mailing list. This needs to include the definitions of "sender", "reviever", etc. as they are defined in Section 3 of syslog-protocol-16. The TLS devices of "client" and "server" should be defined in the next section, or in Section 4, or perhaps in the "Conventions Used in this Document" section. I suspect that the syslog message "sender" will always be the TLC "client". Anyone disagree with that? > > 2, Introduction to TLS > 2.1 How TLS works > TLS establishes a private end-to-end connection, optionally including strong > mutual authentication, using a variety of cryptosystems. Initially, a > handshake phase uses three subprotocols to set up a record layer, > authenticate endpoints, set parameters, as well as report errors. Then, > there is an ongoing layered record protocol that handles encryption, > compression, and reassembly for the remainder of the connection. Application > data protocol, such as SYSLOG, works as a client of record protocol. > > 2.2 Security Property > TLS security properties: Integrity verification (by Hash MAC with MD5 and > SHA1), Data origin authentication (by Certificate/signature along with hash > MAC), Confidentiality/Privacy (by encryption/decryption with DES, AES, RC2 > etc), Anti-replay (by sequence number with integrity verification). > > 3, TLS to mitigate SYSLOG security threats > Integrity verification to counter modification > Data origin authentication to counter masquerading > Confidentiality/Privacy to counter disclosure > Anti-replay to counter message stream modification > > 4, Framework > 4.1 Roles > SYSLOG sender works as TLS client and receiver as TLS server. > Note: It is possible to reverse the role, i.e. sender is TLS server. But it > looks odd and there is no obvious benefit observed right now. > Syslog relay can be either TLS client or server. A relay will be both TLS client and server. > > 4.2 Protocol Port > A port number should be allocated. > > 5, Protocol Elements > 5.1 Initiation > The Sender should initiate a connection to the Receiver on the appropriate > port and then send the TLS ClientHello to begin the TLS handshake. When the > TLS handshake has finished the Sender may then initiate the first SYSLOG > message. > Note: We need to define how syslog interpret the authentication certificates > exchanged by handshake protocol. > Note: We need to discuss what authentication we need: client authenticated > to server, server authenticated to client, or both (mutual authentication) This needs to be discussed by the Working Group. All: Please comment. > > 5.2 Sending data > All SYSLOG message MUST be sent as TLS "application data". > We need to discuss: > 5.2.1, Multiple SYSLOG messages in one TLS message or one SYSLOG message in > one TLS message? How to parse TLS message into several SYSLOG messages in > the multiplexing mode? I'll open a separate thread about this. > > 5.2.2, Does SYSLOG message truncation will affect the transport? > > 5.3 Closure > Sender MUST send a closure alert before closing the connection. Sender which > are unprepared to receive any more data MAY choose not to wait for the > Receiver 's closure alert and simply close the connection, thus generating > an incomplete close on the Receiver side. Receiver MUST attempt to initiate > an exchange of closure alerts with the Sender before closing the connection. > Receiver MAY close the connection after sending the closure alert, thus > generating an incomplete close on the Sender side. > > 5.4 Relay > 5.4.1 It seems expensive to a SYSLOG Relay to become TLS client or server. > Is it possible to relay SYSLOG message without TLS processing? No; the relay will need to view the or other information in the message to decide if it needs to be relayed, and if so to where. > 5.4.2 There are hostname or IP in SYSLOG message header. A implementation > should not check the hostname/IP against TLS certificate because of relay. This falls under the threat of message stream modification. A brief note about this in the Security Considerations section should take care of this. It will be fully addressed in syslog-sign. > > 6 Security Consideration > 6.1 Coexist of TLS and SYSLOG-SIGN > TLS and SYSLOG-SIGN address quite different security requirements. Data > origin authentication of TLS checks whether the data is received from the > SENDER (device or relay), but the SYSLOG-SIGN check whether the data > originates from a specific DEVICE. Do not reference syslog-sign in this document. We do not want to create any additional dependencies. This document, syslog-protocol and syslog-transport-udp will go to the IESG together. syslog-sign can come after these. > The syslog-sign certificate and tls client certificate are not exchangeable > because a sender may be a relay. Another reason is sender may have several > certificates for different purpose. > 6.2 Mutual Authentication? Let's see what the WG has to say about this. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 20 10:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBCaW-0004Q8-M4; Mon, 20 Feb 2006 10:04:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBCaU-0004Q1-Vy for syslog@ietf.org; Mon, 20 Feb 2006 10:04:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBCaT-0001LF-Kh for syslog@ietf.org; Mon, 20 Feb 2006 10:04:30 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Feb 2006 07:04:30 -0800 X-IronPort-AV: i="4.02,130,1139212800"; d="scan'208"; a="1777881922:sNHT31615040" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1KF47Sj004002 for ; Mon, 20 Feb 2006 07:04:26 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 10:03:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Coming to consensus on syslog threats Date: Mon, 20 Feb 2006 10:03:47 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B731220114085F@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Coming to consensus on syslog threats Thread-Index: AcY2JZbS+iwKQmBNQqme4zJ6SuAw5wABvTNg From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 20 Feb 2006 15:03:48.0113 (UTC) FILETIME=[DA0A2010:01C6362E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 ... > > 5, Protocol Elements > > 5.1 Initiation > > The Sender should initiate a connection to the Receiver on the=20 > > appropriate port and then send the TLS ClientHello to begin the TLS=20 > > handshake. When the TLS handshake has finished the Sender may then=20 > > initiate the first SYSLOG message. > > Note: We need to define how syslog interpret the authentication=20 > > certificates exchanged by handshake protocol. Very good point. I think we should specify that Common Name (CN) field = of the server certificate must be matched to what's configured on the = client. Any other ideas? =20 > > Note: We need to discuss what authentication we need: client=20 > > authenticated to server, server authenticated to client, or both=20 > > (mutual authentication) I think both options should be supported. If we support client = authentication, there are two possibilities with certificates: generic = vs. unique. With a generic cert I can have all clients have the same = cert. In this case, I would authenticate that they all are clients from = my organization, for example, but won't ascertain the client identity. =20 With unique certificates, the certificate has to include the identity of = the client which must be logged/used by the receiver - otherwise you = won't know which client you received the message from. For unique client = certificates, I think we should state that the identity of the client = must be represented in the certificate CN field, but we can leave the = format and content undefined. =20 > 5.3 Closure > Sender MUST send a closure alert before closing the connection. Sender = > which are unprepared to receive any more data MAY choose not to wait=20 > for the Receiver 's closure alert and simply close the connection,=20 > thus generating an incomplete close on the Receiver side. Receiver=20 > MUST attempt to initiate an exchange of closure alerts with the Sender = before closing the connection. > Receiver MAY close the connection after sending the closure alert,=20 > thus generating an incomplete close on the Sender side. So, the sender can keep the persistent connection for as long as it = wants unless receiver closes it. I think we need to recommend that = client SHOULD close the connection if it is not using it. If server = always initiates connection closing, can it end up with a bunch of = sockets in the TIME_WAIT state, which may hinder scalability? =20 Should we specify client behavior in case of connection reset by the = server? It probably SHOULD retry the un-acknowledged message. Should we = recommend incremental back-off?=20 Do we need an RPC style message delivery as well, where the server can = acknowledge messages after they have been processed by application layer = as opposed to ack'ed by the TCP stack? Thanks, Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 23 13:13:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKyJ-0003Mr-RX; Thu, 23 Feb 2006 13:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKy2-0003Gv-EJ for syslog@ietf.org; Thu, 23 Feb 2006 13:13:30 -0500 Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKy1-0007Tq-4k for syslog@ietf.org; Thu, 23 Feb 2006 13:13:30 -0500 Received: from [65.213.193.135] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FCKxz-00027c-JW for syslog@ietf.org; Thu, 23 Feb 2006 13:13:27 -0500 From: "Robert Holliday" To: Date: Thu, 23 Feb 2006 13:13:28 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcY4pNic70dVwDlFSoCkD9dI0gJIow== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.8 (+) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Subject: [Syslog] Registration for Network Security 2006 Now Open 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="===============1417305967==" Errors-To: syslog-bounces@lists.ietf.org Message-Id: This is a multi-part message in MIME format. --===============1417305967== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C6387A.EFE2EDB0" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C6387A.EFE2EDB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit International Conference on Network Security 2006 Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday@isocore.com. www.networksecurity2006.com ------=_NextPart_000_0010_01C6387A.EFE2EDB0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

International Conference on Network Security 2006

 

Registration = Open!!!

 

Reston Virginia, April = 17-19

Early Registration Benefits = Now Available

 

The conference offers cutting edge discussion and presentations on the contemporary issues in network security and = critical information infrastructure. 

 

Technical = Program: http://www.isocore.com/netwo= rksecurity2006/program.htm

 

Discounts still available for early = registration.

 

Registration: http://www.isocore.com/netwo= rksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made on-line.

 

Hotel = Reservations: http://www.isocore.com/netwo= rksecurity2006/hotel.htm

 

To obtain special rates for student or group please = contact Robert Holliday at rholliday@isocore.com.

 

www.networksecurity2006.com<= /span>

 

------=_NextPart_000_0010_01C6387A.EFE2EDB0-- --===============1417305967== 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 --===============1417305967==-- From syslog-bounces@lists.ietf.org Thu Feb 23 21:51:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCT3c-0005F1-4b; Thu, 23 Feb 2006 21:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCT3b-0005Et-KH for syslog@ietf.org; Thu, 23 Feb 2006 21:51:47 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCT3b-0000lC-8t for syslog@ietf.org; Thu, 23 Feb 2006 21:51:47 -0500 Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600KOY78KCH@lhrga01-in.huawei.com> for syslog@ietf.org; Fri, 24 Feb 2006 02:36:21 +0000 (GMT) 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 <0IV600D2F8F6LP@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 24 Feb 2006 11:01:55 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600FKQ8F6CY@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 24 Feb 2006 11:01:54 +0800 (CST) Received: from m19684 ([10.111.12.90]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV600CBT8OS2S@szxml01-in.huawei.com>; Fri, 24 Feb 2006 11:07:41 +0800 (CST) Date: Fri, 24 Feb 2006 10:51:35 +0800 From: Miao Fuyou Subject: RE: [Syslog] Coming to consensus on syslog threats In-reply-to: <98AE08B66FAD1742BED6CB9522B731220114085F@xmb-rtp-20d.amer.cisco.com> To: "'Anton Okmianski (aokmians)'" Message-id: <000001c638ed$3a14e3d0$5a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 inline > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Monday, February 20, 2006 11:04 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Coming to consensus on syslog threats > > > ... > > > > 5, Protocol Elements > > > 5.1 Initiation > > > The Sender should initiate a connection to the Receiver on the > > > appropriate port and then send the TLS ClientHello to > begin the TLS > > > handshake. When the TLS handshake has finished the Sender > may then > > > initiate the first SYSLOG message. > > > Note: We need to define how syslog interpret the authentication > > > certificates exchanged by handshake protocol. > > Very good point. I think we should specify that Common Name > (CN) field of the server certificate must be matched to > what's configured on the client. Any other ideas? > > > > Note: We need to discuss what authentication we need: client > > > authenticated to server, server authenticated to client, or both > > > (mutual authentication) > > I think both options should be supported. If we support I agree upon that both options should be supported. It is up to the application to decide what authentication is required in specific scenarios. One of my consideration is server authentication is indispensible for confidentiality. If a server is spoofed, syslog messages are disclosed to the spoofed server even if encryption is enabled. > client authentication, there are two possibilities with > certificates: generic vs. unique. With a generic cert I can > have all clients have the same cert. In this case, I would I thinks it is good that all TCP/TLS clients in the same host (device, relay or collector) share same client cert. My further suggestion is to resuse tls session for all clients in same host. But, I don't think the certs can be generic to different hosts, it will weaken the security of TLS. > authenticate that they all are clients from my organization, > for example, but won't ascertain the client identity. > > With unique certificates, the certificate has to include the > identity of the client which must be logged/used by the > receiver - otherwise you won't know which client you received > the message from. For unique client certificates, I think we > should state that the identity of the client must be > represented in the certificate CN field, but we can leave the > format and content undefined. > > 5.3 Closure > > Sender MUST send a closure alert before closing the > connection. Sender > > which are unprepared to receive any more data MAY choose > not to wait > > for the Receiver 's closure alert and simply close the connection, > > thus generating an incomplete close on the Receiver side. Receiver > > MUST attempt to initiate an exchange of closure alerts with > the Sender before closing the connection. > > Receiver MAY close the connection after sending the closure alert, > > thus generating an incomplete close on the Sender side. > > So, the sender can keep the persistent connection for as long > as it wants unless receiver closes it. I think we need to > recommend that client SHOULD close the connection if it is > not using it. If server always initiates connection closing, > can it end up with a bunch of sockets in the TIME_WAIT state, > which may hinder scalability? > > Should we specify client behavior in case of connection reset > by the server? It probably SHOULD retry the un-acknowledged > message. Should we recommend incremental back-off? > > Do we need an RPC style message delivery as well, where the > server can acknowledge messages after they have been > processed by application layer as opposed to ack'ed by the TCP stack? > > Thanks, > Anton. > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 24 00:19:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCVMx-0006kS-Ux; Fri, 24 Feb 2006 00:19:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCVMx-0006kN-92 for syslog@ietf.org; Fri, 24 Feb 2006 00:19:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCVMv-0005Kb-WF for syslog@ietf.org; Fri, 24 Feb 2006 00:19:55 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2006 21:19:53 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,142,1139212800"; d="scan'208"; a="22517460:sNHT23230740" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1O5JrjJ011446; Fri, 24 Feb 2006 00:19:53 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 00:19:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Coming to consensus on syslog threats Date: Fri, 24 Feb 2006 00:19:51 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122011BC136@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Coming to consensus on syslog threats Thread-Index: AcY47UfGbw1K9AhoTxuLm2hczIGGCQAE65iw From: "Anton Okmianski \(aokmians\)" To: "Miao Fuyou" X-OriginalArrivalTime: 24 Feb 2006 05:19:52.0962 (UTC) FILETIME=[F11D5620:01C63901] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao:=20 > I thinks it is good that all TCP/TLS clients in the same host > (device, relay or collector) share same client cert.=20 It depends on what you want to authenticate. I would mandate a tie of = client identity to identity of the host. =20 > My=20 > further suggestion > is to resuse > tls session for all clients in same host. =20 While a valid use-case, we cannot mandate a central syslog agent on host = which all clients must use. Each application should be allowed to = function as independent an syslog client IMO.=20 > But, I don't think=20 > the certs can be generic to different hosts, it will weaken=20 > the security of > TLS.=20 There are legitimate use-case for that. It depends on what you want to = authenticate. For example, if I want to allow access to my server to = all applications of type X which all share the same certificate even = thought they are on different hosts. In this case, I am authenticating = the application type, not specific client or host.=20 Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 24 01:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCWBw-0000LS-Af; Fri, 24 Feb 2006 01:12:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCWBv-0000Ia-H0 for syslog@ietf.org; Fri, 24 Feb 2006 01:12:35 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCWBu-0006UX-8K for syslog@ietf.org; Fri, 24 Feb 2006 01:12:35 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600MM9GT3JW@usaga01-in.huawei.com> for syslog@ietf.org; Thu, 23 Feb 2006 22:03:03 -0800 (PST) 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 <0IV6003FJHJFRY@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 24 Feb 2006 14:18:51 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600DIYHJF1B@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 24 Feb 2006 14:18:51 +0800 (CST) Received: from m19684 ([10.111.12.90]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV600GZ8HP5JY@szxml01-in.huawei.com>; Fri, 24 Feb 2006 14:22:17 +0800 (CST) Date: Fri, 24 Feb 2006 14:06:13 +0800 From: Miao Fuyou Subject: RE: [Syslog] Coming to consensus on syslog threats In-reply-to: <98AE08B66FAD1742BED6CB9522B73122011BC136@xmb-rtp-20d.amer.cisco.com> To: "'Anton Okmianski (aokmians)'" Message-id: <000001c63908$6acd9f60$5a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 inline > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Friday, February 24, 2006 1:20 PM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: RE: [Syslog] Coming to consensus on syslog threats > > > Miao: > > > I thinks it is good that all TCP/TLS clients in the same > host (device, > > relay or collector) share same client cert. > > It depends on what you want to authenticate. I would mandate > a tie of client identity to identity of the host. > > > My > > further suggestion > > is to resuse > > tls session for all clients in same host. > > While a valid use-case, we cannot mandate a central syslog > agent on host which all clients must use. Each application > should be allowed to function as independent an syslog client IMO. > Actually the exact meaning is to reuse the security parameters of a earlier session or current active session. > > But, I don't think > > the certs can be generic to different hosts, it will weaken > > the security of > > TLS. > > There are legitimate use-case for that. It depends on what > you want to authenticate. For example, if I want to allow > access to my server to all applications of type X which all > share the same certificate even thought they are on different > hosts. In this case, I am authenticating the application > type, not specific client or host. > > Anton. > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 24 02:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCX7g-0000MN-EU; Fri, 24 Feb 2006 02:12:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCX7f-0000MF-1y for syslog@ietf.org; Fri, 24 Feb 2006 02:12:15 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCX7d-0008PW-JX for syslog@ietf.org; Fri, 24 Feb 2006 02:12:15 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 77CE727C061; Fri, 24 Feb 2006 07:19:03 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01930-04; Fri, 24 Feb 2006 07:19:03 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2E5D327C05D; Fri, 24 Feb 2006 07:19:03 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 08:12:10 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Coming to consensus on syslog threats MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2006 08:12:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174091@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Coming to consensus on syslog threats Thread-Index: AcY47UfGbw1K9AhoTxuLm2hczIGGCQAE65iwAAQez7A= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Miao Fuyou" X-OriginalArrivalTime: 24 Feb 2006 07:12:10.0578 (UTC) FILETIME=[A10BF320:01C63911] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 I agree with Anton. I would *expect*, however, that on the same client the same cert is used. I would expect that multiple clients also use the same cert (with less likelyhood). I would not outrule any of the "unexpected" cases. If you look at the current deployments using stunnel, you can find this in practice. Rainer=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Friday, February 24, 2006 6:20 AM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: RE: [Syslog] Coming to consensus on syslog threats >=20 > Miao:=20 >=20 > > I thinks it is good that all TCP/TLS clients in the same host > > (device, relay or collector) share same client cert.=20 >=20 > It depends on what you want to authenticate. I would mandate=20 > a tie of client identity to identity of the host. =20 >=20 > > My=20 > > further suggestion > > is to resuse > > tls session for all clients in same host. =20 >=20 > While a valid use-case, we cannot mandate a central syslog=20 > agent on host which all clients must use. Each application=20 > should be allowed to function as independent an syslog client IMO.=20 >=20 > > But, I don't think=20 > > the certs can be generic to different hosts, it will weaken=20 > > the security of > > TLS.=20 >=20 > There are legitimate use-case for that. It depends on what=20 > you want to authenticate. For example, if I want to allow=20 > access to my server to all applications of type X which all=20 > share the same certificate even thought they are on different=20 > hosts. In this case, I am authenticating the application=20 > type, not specific client or host.=20 >=20 > Anton.=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog