From syslog-bounces@lists.ietf.org Thu Apr 06 16:30:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRb7O-0007dG-JU; Thu, 06 Apr 2006 16:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRb7M-0007cw-Fr for syslog@ietf.org; Thu, 06 Apr 2006 16:30:12 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRb7L-0006gn-7x for syslog@ietf.org; Thu, 06 Apr 2006 16:30:12 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 06 Apr 2006 13:30:11 -0700 X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="1792556473:sNHT66835826" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k36KUAGw017217; Thu, 6 Apr 2006 13:30:10 -0700 (PDT) Date: Thu, 6 Apr 2006 13:30:10 -0700 (PDT) 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: 1.8 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: hartmans-ietf@mit.edu Subject: [Syslog] Welcome David Harrington as the new syslog WG Co-Chair X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, We have a lot of work to do in a short time. Since I've gotten busy with many things and can't dedicate as much time to this as I'd like, I've asked David Harrington to Co-Chair this Working Group with me. David has offered very good advice to this Working Group in the past and he knows the importance and significance of this work. He brings a lot of IETF experience with him, is well known in the Operations and Management Area and is very active in several other Working Groups. Please join me in welcoming David to this position. Many thanks, Chris syslog WG Co-Chair _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Apr 14 03:40:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIup-0003jU-1Y; Fri, 14 Apr 2006 03:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIum-0003jP-Tu for syslog@ietf.org; Fri, 14 Apr 2006 03:40:24 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUIuh-0007dR-6n for syslog@ietf.org; Fri, 14 Apr 2006 03:40:24 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP008H8BXPLY@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 14 Apr 2006 15:39:25 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXP00A91BXPTV@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 14 Apr 2006 15:39:25 +0800 (CST) Received: from m19684 ([10.110.114.80]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXP00639CKDYU@szxml02-in.huawei.com> for syslog@ietf.org; Fri, 14 Apr 2006 15:53:10 +0800 (CST) Date: Fri, 14 Apr 2006 15:39:10 +0800 From: Miao Fuyou To: syslog@ietf.org Message-id: <000001c65f96$87ce86b0$50726e0a@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: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Syslog] Summary of the syslog/tls issues resolving X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I summarized the issues resolving, soon I will update the document and get it posted. The resolutions are tentative, if you have different idea to resolutions, please comment on mailing list! [Issue 0]: Do we need a Syslog TCP port for TLS transport? The security community had debates about whether using special ports is desirable. Tentative resolution: Yes, we need a port < 1024 for syslog/tls (refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00910.html) [Issue 1]: Is it possible to use "generic certificate for different host? The generic certificate is for specific application type. AND [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- NAME(generic certificate)? APP-NAME binding makes authentication/ access control happens both in TLS handshake and Syslog message processing, is efficiency a problem? Tentative resolution: 1, Generic certificate may not be possible (refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00918.html). So bind app-name is not required and possible. 2, We need cerficate binding to host name, operator to decide whether to check the binding. Receiver may consult DNS to get host name for a sender, while sender may just query local configuration to get host name. [Issue 3] The problem of CR LF is it can not process binary data well. How to process Syslog signature/certificate message? Tentative resolution: We need byte counter, the byte counter is in a text based format(refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00902.html). [Issue 4]: Shall we mandate the sender MUST be authenticated? Most of the Syslogd accepts messages only from configured address. Tentative resolution: It should be optional to operator, use SHOULD or MAY instead of MUST and explain security implication. I tend to use SHOULD. (Refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html) Miao _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Apr 14 10:56:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPiq-00075U-Du; Fri, 14 Apr 2006 10:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPip-00075P-JZ for syslog@ietf.org; Fri, 14 Apr 2006 10:56:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPip-0004Ij-7B for syslog@ietf.org; Fri, 14 Apr 2006 10:56:31 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Apr 2006 10:56:31 -0400 X-IronPort-AV: i="4.04,120,1144036800"; d="scan'208"; a="86458296:sNHT32981092" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3EEuUTL003218; Fri, 14 Apr 2006 10:56:30 -0400 (EDT) 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, 14 Apr 2006 10:56:30 -0400 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] Summary of the syslog/tls issues resolving Date: Fri, 14 Apr 2006 10:56:37 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201510D05@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Summary of the syslog/tls issues resolving Thread-Index: AcZflsLSK4rKOWTxSuCO3uX5Ia2r8gANwPnw From: "Anton Okmianski \(aokmians\)" To: "Miao Fuyou" , X-OriginalArrivalTime: 14 Apr 2006 14:56:30.0225 (UTC) FILETIME=[9CEE7810:01C65FD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Miao: > [Issue 1]: Is it possible to use "generic certificate for different > host? The generic certificate is for specific application type. > AND > [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- > NAME(generic certificate)? APP-NAME binding makes authentication/ > access control happens both in TLS handshake and Syslog message > processing, is efficiency a problem? >=20 > Tentative resolution: 1, Generic certificate may not be=20 > possible (refer to > http://www1.ietf.org/mail-archive/web/syslog/current/msg00918. > html).=20 I can't support this conclusion. Of course, it is possible - used all = the time.=20 > So bind > app-name is not required and possible.=20 Generic certificate does not need to be bound to anything, although it = can carry some certified pieces of information. Having a format for = putting known fields into certificate CN field would be nice, but not = mandatory. =20 I work on a product which manages million of consumer devices (modems, = gateways, settop boxes, etc)remotely for service providers (SPs). These = SPs are starting to use SSL/TLS for many CPE to back-end interactions. = Some SPs use unique certificates on each device, in which case it is a = device ID such as serial number or MAC address embedded in certificate = CN field - not hostname. Case study, DSL Forum defines use of device ID = in certificate CN field in their CWMP standard defined in TR-069 / = WT-121. The same standard also allows for use of generic certificates. =20 Some SP want to use the same cert on all devices. That generic cert = identifies either manufacturer or service provider. It does not = authenticate a specific CPE, but rather as a way to establish that CPE = is the right kind to connect to backend systems. Similar vendor = certificates, I believe, are used in Cable industry's PacketCable VoIP = standards (although they have unique ones too). In this environment, = having a unique certificate on millions of devices is generally = considered a serious cost factor - adds cost to CPE. Sometimes a = combination of generic cert + HTTP digest authentication is used. In = syslog case, syslog payload signing could be the option that could = replace HTTP digest authentication. =20 The point of above is that generic certificates are used today, part of = standards and seem to make sense to large organizations which demand = their use. So, it is certainly possible to use those and would be a = good idea for syslog to support it too.=20 > 2, We need cerficate=20 > binding to host > name, operator to decide whether to check the binding.=20 Certificate with hostname (FQDN, right?) in the CN is a decent option, = but as I mentioned above, this is not what say DSL SPs use to identify = devices. Hostname for unique certificate can't be a requirement IMO. =20 I agree that it should be operator decision whether or not to check the = certificate binding.=20 > Receiver may consult > DNS to get host name for a sender, while sender may just query local > configuration to get host name. Not sure what you mean here. Certificates have to be generated by CA = (certificate Authority) which has the private key, then installed on the = host. The sender can't just generate one by looking up the hostname. Or = are you talking about hostname inserted in syslog message field? =20 Also, why does receiver need to consult DNS? =20 > [Issue 4]: Shall we mandate the sender MUST be authenticated? Most > of the Syslogd accepts messages only from configured address. In TCP, restricting by source IP buys you more than in UDP where it is = easy to spoof, but even in TCP it is hardly an authentication mechanism = or we would not be talking about TLS auth. In case of my application = with millions of devices, you would have to allow huge subnets anyway = and addresses are allocated dynamically using DHCP. =20 > Tentative resolution: It should be optional to operator, use=20 > SHOULD or MAY > instead of MUST and explain security implication. I tend to=20 > use SHOULD. Sounds good. Please state clearly what it means to authenticate the = sender though. Is it a sender presenting a legitimate signed certificate = (be it generic or unique)? Or does it include checking certificate = binding by comparing CN field to some field in syslog message (like = FQDN)? In case of latter, the syslog would need to carry FQDN (not = hostname or IP which are allowed substitutes) as well.=20 Thanks, Anton.=20 > (Refer to > http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html) >=20 > Miao >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Apr 17 05:16:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVPq6-0000XZ-DM; Mon, 17 Apr 2006 05:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVPq5-0000XT-8A for syslog@ietf.org; Mon, 17 Apr 2006 05:16:09 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVPq2-0002Eu-NH for syslog@ietf.org; Mon, 17 Apr 2006 05:16:09 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXV006G805359@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 17 Apr 2006 17:10:15 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXV006M30521J@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 17 Apr 2006 17:10:15 +0800 (CST) Received: from m19684 ([10.110.114.80]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXV004R60XZLB@szxml01-in.huawei.com>; Mon, 17 Apr 2006 17:27:43 +0800 (CST) Date: Mon, 17 Apr 2006 17:09:57 +0800 From: Miao Fuyou Subject: RE: [Syslog] Summary of the syslog/tls issues resolving In-reply-to: <98AE08B66FAD1742BED6CB9522B7312201510D05@xmb-rtp-20d.amer.cisco.com> To: "'Anton Okmianski (aokmians)'" , syslog@ietf.org Message-id: <001d01c661fe$b5bbf7a0$50726e0a@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: 25eb6223a37c19d53ede858176b14339 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 The confusion comes from the relationship of binding and authentication. In TLS/SSL, authentciation is to check whether a CA trusted by the checker in the certificate chain is available. If there is trusted CA, checker may check the binding of common name of certificate to something available locally, such as host name. But, binding check is not a step for authentcation by certificate's nature. If we consider authentication only, it will be much simple. A receiver just check the trustship of sender's certificate without checking binding, regardless what entity(a host, an application, a class of device or application described in Anton's scenario) the certificate is issued to. In such case, generic certificate is possible. When we discuss certificate/CN binding, it becomes tricky. It is not practical to check the binding of APP-NAME or anything from syslog message, such as FQDN, to certificate when authentciating a sender. Such binding check will breach the layership and modularity of tls/syslog, and may impact efficiency badly. This point was discussed by Balazs and me on the mailing list( http://www1.ietf.org/mail-archive/web/syslog/current/msg00918). We MUST rely on the information available to TLS layer to check the binding of common name. One such information is hostname, so we are able to check the binding of hostname to certificate when it is issued to host(host certificate, or unique certificate). When common name of a host certificate is device ID or MAC etc, it is not practical to check the binding because of inavailablity of such information to TLS. If a certificate is issued to anything else(such as applicaiton, a class of device or application), the similiar things may happen. So, for a lot of scenarios, binding check is not practical! Now the question are: Do we really need binding check? Does binding check provides any benefit/security? If we need binding check, we may only be able to use it with host certificate. Miao > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Friday, April 14, 2006 10:57 PM > To: Miao Fuyou; syslog@ietf.org > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > > > Miao: > > > [Issue 1]: Is it possible to use "generic certificate > for different > > host? The generic certificate is for specific application type. > > AND > > [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- > > NAME(generic certificate)? APP-NAME binding makes > authentication/ > > access control happens both in TLS handshake and Syslog message > > processing, is efficiency a problem? > > > > Tentative resolution: 1, Generic certificate may not be > > possible (refer to > > http://www1.ietf.org/mail-archive/web/syslog/current/msg00918. > > html). > > I can't support this conclusion. Of course, it is possible - > used all the time. > > > So bind > > app-name is not required and possible. > > Generic certificate does not need to be bound to anything, > although it can carry some certified pieces of information. > Having a format for putting known fields into certificate CN > field would be nice, but not mandatory. > > I work on a product which manages million of consumer devices > (modems, gateways, settop boxes, etc)remotely for service > providers (SPs). These SPs are starting to use SSL/TLS for > many CPE to back-end interactions. Some SPs use unique > certificates on each device, in which case it is a device ID > such as serial number or MAC address embedded in certificate > CN field - not hostname. Case study, DSL Forum defines use of > device ID in certificate CN field in their CWMP standard > defined in TR-069 / WT-121. The same standard also allows for > use of generic certificates. > > Some SP want to use the same cert on all devices. That > generic cert identifies either manufacturer or service > provider. It does not authenticate a specific CPE, but rather > as a way to establish that CPE is the right kind to connect > to backend systems. Similar vendor certificates, I believe, > are used in Cable industry's PacketCable VoIP standards > (although they have unique ones too). In this environment, > having a unique certificate on millions of devices is > generally considered a serious cost factor - adds cost to > CPE. Sometimes a combination of generic cert + HTTP digest > authentication is used. In syslog case, syslog payload > signing could be the option that could replace HTTP digest > authentication. > > The point of above is that generic certificates are used > today, part of standards and seem to make sense to large > organizations which demand their use. So, it is certainly > possible to use those and would be a good idea for syslog to > support it too. > > > 2, We need cerficate > > binding to host > > name, operator to decide whether to check the binding. > > Certificate with hostname (FQDN, right?) in the CN is a > decent option, but as I mentioned above, this is not what say > DSL SPs use to identify devices. Hostname for unique > certificate can't be a requirement IMO. > > I agree that it should be operator decision whether or not to > check the certificate binding. > > > Receiver may consult > > DNS to get host name for a sender, while sender may just > query local > > configuration to get host name. > > Not sure what you mean here. Certificates have to be > generated by CA (certificate Authority) which has the private > key, then installed on the host. The sender can't just > generate one by looking up the hostname. Or are you talking > about hostname inserted in syslog message field? > > Also, why does receiver need to consult DNS? > > > [Issue 4]: Shall we mandate the sender MUST be > authenticated? Most > > of the Syslogd accepts messages only from configured address. > > In TCP, restricting by source IP buys you more than in UDP > where it is easy to spoof, but even in TCP it is hardly an > authentication mechanism or we would not be talking about TLS > auth. In case of my application with millions of devices, you > would have to allow huge subnets anyway and addresses are > allocated dynamically using DHCP. > > > Tentative resolution: It should be optional to operator, use > > SHOULD or MAY > > instead of MUST and explain security implication. I tend to > > use SHOULD. > > Sounds good. Please state clearly what it means to > authenticate the sender though. Is it a sender presenting a > legitimate signed certificate (be it generic or unique)? Or > does it include checking certificate binding by comparing CN > field to some field in syslog message (like FQDN)? In case of > latter, the syslog would need to carry FQDN (not hostname or > IP which are allowed substitutes) as well. > > Thanks, > Anton. > > > (Refer to > > http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html) > > > > Miao > > > > > > > > _______________________________________________ > > 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 Apr 17 11:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVNY-0005b9-Bu; Mon, 17 Apr 2006 11:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVNW-0005Z5-K4 for syslog@ietf.org; Mon, 17 Apr 2006 11:11:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVNW-0002rj-HP for syslog@ietf.org; Mon, 17 Apr 2006 11:11:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FVV4J-0006uN-3C for syslog@ietf.org; Mon, 17 Apr 2006 10:51:14 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2006 10:51:11 -0400 X-IronPort-AV: i="4.04,125,1144036800"; d="scan'208"; a="86571427:sNHT35328300" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3HEpATL011168; Mon, 17 Apr 2006 10:51:10 -0400 (EDT) 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); Mon, 17 Apr 2006 10:51:10 -0400 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] Summary of the syslog/tls issues resolving Date: Mon, 17 Apr 2006 10:51:08 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201511050@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Summary of the syslog/tls issues resolving Thread-Index: AcZh/5BOzJKHBPvoSDm1EMAwrlt4cAAKTtNQ From: "Anton Okmianski \(aokmians\)" To: "Miao Fuyou" , X-OriginalArrivalTime: 17 Apr 2006 14:51:10.0010 (UTC) FILETIME=[5D4EC9A0:01C6622E] X-Spam-Score: -2.6 (--) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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 Miao: The layering is not a problem. The TLS stack will expose the validated = client certificate to the upper layer. That layer (syslog server app) = can do whatever it wants with the certificate data. =20 However, I don't think binding check should be required. For one, this = would preclude the most generic certificates. There may be too many = options about how one may want to validate/use the client identity in = the certificate. For example, one could configure syslog server to = allow clients which have one of the defined strings in the CN fields = (could be hostnames or whatever) or it could consult a database of = clients. Alternatively (or in addition), one can check the CN content = against some field in the syslog message itself.=20 I think having a standard way to identify individual syslog clients = using syslog-over-TLS would be very useful. This means that client = identity could be extracted our of certificate. =20 Possibly, all we need to do here is: (a) say that certificate CN MAY carry syslog client identity = information (b) REQUIRE insertion of CN data into syslog message (relay or not) (c) define structured element for insertion of CN data (d) RECOMMEND that syslog servers provide a function to restrict access = based on CN content Thoughts? Thanks, Anton. =20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Monday, April 17, 2006 5:10 AM > To: Anton Okmianski (aokmians); syslog@ietf.org > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving >=20 >=20 > The confusion comes from the relationship of binding and=20 > authentication.=20 >=20 > In TLS/SSL, authentciation is to check whether a CA trusted=20 > by the checker > in the certificate chain is available. If there is trusted=20 > CA, checker may > check the binding of common name of certificate to something available > locally, such as host name. But, binding check is not a step for > authentcation by certificate's nature.=20 >=20 > If we consider authentication only, it will be much simple. A=20 > receiver just > check the trustship of sender's certificate without checking binding, > regardless what entity(a host, an application, a class of device or > application described in Anton's scenario) the certificate is=20 > issued to. In > such case, generic certificate is possible.=20 >=20 > When we discuss certificate/CN binding, it becomes tricky. It is not > practical to check the binding of APP-NAME or anything from=20 > syslog message, > such as FQDN, to certificate when authentciating a sender.=20 > Such binding > check will breach the layership and modularity of tls/syslog,=20 > and may impact > efficiency badly. This point was discussed by Balazs and me=20 > on the mailing > list(=20 > http://www1.ietf.org/mail-archive/web/syslog/current/msg00918). We > MUST rely on the information available to TLS layer to check=20 > the binding of > common name. One such information is hostname, so we are able=20 > to check the > binding of hostname to certificate when it is issued to host(host > certificate, or unique certificate). When common name of a=20 > host certificate > is device ID or MAC etc, it is not practical to check the=20 > binding because of > inavailablity of such information to TLS. If a certificate is=20 > issued to > anything else(such as applicaiton, a class of device or=20 > application), the > similiar things may happen. So, for a lot of scenarios,=20 > binding check is not > practical! >=20 > Now the question are: Do we really need binding check? Does=20 > binding check > provides any benefit/security? If we need binding check, we=20 > may only be able > to use it with host certificate. >=20 > Miao >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > > Sent: Friday, April 14, 2006 10:57 PM > > To: Miao Fuyou; syslog@ietf.org > > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > >=20 > >=20 > > Miao: > >=20 > > > [Issue 1]: Is it possible to use "generic certificate=20 > > for different > > > host? The generic certificate is for specific=20 > application type.=20 > > > AND > > > [Issue 2]: What to bind to a certificate? Hostname,=20 > Syslog APP- > > > NAME(generic certificate)? APP-NAME binding makes=20 > > authentication/ > > > access control happens both in TLS handshake and Syslog message > > > processing, is efficiency a problem? > > >=20 > > > Tentative resolution: 1, Generic certificate may not be > > > possible (refer to > > > http://www1.ietf.org/mail-archive/web/syslog/current/msg00918. > > > html).=20 > >=20 > > I can't support this conclusion. Of course, it is possible -=20 > > used all the time.=20 > >=20 > > > So bind > > > app-name is not required and possible. > >=20 > > Generic certificate does not need to be bound to anything,=20 > > although it can carry some certified pieces of information.=20 > > Having a format for putting known fields into certificate CN=20 > > field would be nice, but not mandatory. =20 > >=20 > > I work on a product which manages million of consumer devices=20 > > (modems, gateways, settop boxes, etc)remotely for service=20 > > providers (SPs). These SPs are starting to use SSL/TLS for=20 > > many CPE to back-end interactions. Some SPs use unique=20 > > certificates on each device, in which case it is a device ID=20 > > such as serial number or MAC address embedded in certificate=20 > > CN field - not hostname. Case study, DSL Forum defines use of=20 > > device ID in certificate CN field in their CWMP standard=20 > > defined in TR-069 / WT-121. The same standard also allows for=20 > > use of generic certificates. =20 > >=20 > > Some SP want to use the same cert on all devices. That=20 > > generic cert identifies either manufacturer or service=20 > > provider. It does not authenticate a specific CPE, but rather=20 > > as a way to establish that CPE is the right kind to connect=20 > > to backend systems. Similar vendor certificates, I believe,=20 > > are used in Cable industry's PacketCable VoIP standards=20 > > (although they have unique ones too). In this environment,=20 > > having a unique certificate on millions of devices is=20 > > generally considered a serious cost factor - adds cost to=20 > > CPE. Sometimes a combination of generic cert + HTTP digest=20 > > authentication is used. In syslog case, syslog payload=20 > > signing could be the option that could replace HTTP digest=20 > > authentication. =20 > >=20 > > The point of above is that generic certificates are used=20 > > today, part of standards and seem to make sense to large=20 > > organizations which demand their use. So, it is certainly=20 > > possible to use those and would be a good idea for syslog to=20 > > support it too.=20 > >=20 > > > 2, We need cerficate > > > binding to host > > > name, operator to decide whether to check the binding.=20 > >=20 > > Certificate with hostname (FQDN, right?) in the CN is a=20 > > decent option, but as I mentioned above, this is not what say=20 > > DSL SPs use to identify devices. Hostname for unique=20 > > certificate can't be a requirement IMO. =20 > >=20 > > I agree that it should be operator decision whether or not to=20 > > check the certificate binding.=20 > >=20 > > > Receiver may consult > > > DNS to get host name for a sender, while sender may just=20 > > query local=20 > > > configuration to get host name. > >=20 > > Not sure what you mean here. Certificates have to be=20 > > generated by CA (certificate Authority) which has the private=20 > > key, then installed on the host. The sender can't just=20 > > generate one by looking up the hostname. Or are you talking=20 > > about hostname inserted in syslog message field? =20 > >=20 > > Also, why does receiver need to consult DNS? =20 > >=20 > > > [Issue 4]: Shall we mandate the sender MUST be=20 > > authenticated? Most =20 > > > of the Syslogd accepts messages only from configured address. > >=20 > > In TCP, restricting by source IP buys you more than in UDP=20 > > where it is easy to spoof, but even in TCP it is hardly an=20 > > authentication mechanism or we would not be talking about TLS=20 > > auth. In case of my application with millions of devices, you=20 > > would have to allow huge subnets anyway and addresses are=20 > > allocated dynamically using DHCP. =20 > >=20 > > > Tentative resolution: It should be optional to operator, use > > > SHOULD or MAY > > > instead of MUST and explain security implication. I tend to=20 > > > use SHOULD. > >=20 > > Sounds good. Please state clearly what it means to=20 > > authenticate the sender though. Is it a sender presenting a=20 > > legitimate signed certificate (be it generic or unique)? Or=20 > > does it include checking certificate binding by comparing CN=20 > > field to some field in syslog message (like FQDN)? In case of=20 > > latter, the syslog would need to carry FQDN (not hostname or=20 > > IP which are allowed substitutes) as well.=20 > >=20 > > Thanks, > > Anton.=20 > >=20 > > > (Refer to > > >=20 > http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html) > > >=20 > > > Miao > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org=20 > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Apr 17 12:34:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWgJ-0007dy-EA; Mon, 17 Apr 2006 12:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWgH-0007ds-Ps for syslog@ietf.org; Mon, 17 Apr 2006 12:34:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVWgH-0007OR-5a for syslog@ietf.org; Mon, 17 Apr 2006 12:34:29 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 17 Apr 2006 09:34:27 -0700 X-IronPort-AV: i="4.04,126,1144047600"; d="scan'208"; a="269119911:sNHT34873016" 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 k3HGYQw2027249; Mon, 17 Apr 2006 09:34:26 -0700 (PDT) Date: Mon, 17 Apr 2006 09:34:26 -0700 (PDT) From: Chris Lonvick To: "Anton Okmianski (aokmians)" Subject: RE: [Syslog] Summary of the syslog/tls issues resolving In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201511050@xmb-rtp-20d.amer.cisco.com> Message-ID: References: <98AE08B66FAD1742BED6CB9522B7312201511050@xmb-rtp-20d.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: dperkins@dsperkins.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Anton, Your proposal seems to be overlapping syslog-sign. I think that what the community would like (this is open for debate) is for a standard that will allow an existing implementation of syslog to use syslog/tls in a standard way right now. The next step would be to convert to syslog-protocol, and the step beyond that would be to include syslog-sign. On the subject of binding checks, perhaps it would be good to keep in mind that some syslog senders are things like printers or other devices that will have a certificate issued at the time it was manufactured. Is it going to be worth the effort for the operations staff to install localized certificates, or would they be willing to accept those and just use access control lists? (David Perkins mentioned this to me and said that it was OK for me to include him in this discussion - which is why I'm cc'ing him on this.) Thanks, Chris On Mon, 17 Apr 2006, Anton Okmianski (aokmians) wrote: > Miao: > > The layering is not a problem. The TLS stack will expose the validated client certificate to the upper layer. That layer (syslog server app) can do whatever it wants with the certificate data. > > However, I don't think binding check should be required. For one, this would preclude the most generic certificates. There may be too many options about how one may want to validate/use the client identity in the certificate. For example, one could configure syslog server to allow clients which have one of the defined strings in the CN fields (could be hostnames or whatever) or it could consult a database of clients. Alternatively (or in addition), one can check the CN content against some field in the syslog message itself. > > I think having a standard way to identify individual syslog clients using syslog-over-TLS would be very useful. This means that client identity could be extracted our of certificate. > > Possibly, all we need to do here is: > > (a) say that certificate CN MAY carry syslog client identity information > (b) REQUIRE insertion of CN data into syslog message (relay or not) > (c) define structured element for insertion of CN data > (d) RECOMMEND that syslog servers provide a function to restrict access based on CN content > > Thoughts? > > Thanks, > Anton. > >> -----Original Message----- >> From: Miao Fuyou [mailto:miaofy@huawei.com] >> Sent: Monday, April 17, 2006 5:10 AM >> To: Anton Okmianski (aokmians); syslog@ietf.org >> Subject: RE: [Syslog] Summary of the syslog/tls issues resolving >> >> >> The confusion comes from the relationship of binding and >> authentication. >> >> In TLS/SSL, authentciation is to check whether a CA trusted >> by the checker >> in the certificate chain is available. If there is trusted >> CA, checker may >> check the binding of common name of certificate to something available >> locally, such as host name. But, binding check is not a step for >> authentcation by certificate's nature. >> >> If we consider authentication only, it will be much simple. A >> receiver just >> check the trustship of sender's certificate without checking binding, >> regardless what entity(a host, an application, a class of device or >> application described in Anton's scenario) the certificate is >> issued to. In >> such case, generic certificate is possible. >> >> When we discuss certificate/CN binding, it becomes tricky. It is not >> practical to check the binding of APP-NAME or anything from >> syslog message, >> such as FQDN, to certificate when authentciating a sender. >> Such binding >> check will breach the layership and modularity of tls/syslog, >> and may impact >> efficiency badly. This point was discussed by Balazs and me >> on the mailing >> list( >> http://www1.ietf.org/mail-archive/web/syslog/current/msg00918). We >> MUST rely on the information available to TLS layer to check >> the binding of >> common name. One such information is hostname, so we are able >> to check the >> binding of hostname to certificate when it is issued to host(host >> certificate, or unique certificate). When common name of a >> host certificate >> is device ID or MAC etc, it is not practical to check the >> binding because of >> inavailablity of such information to TLS. If a certificate is >> issued to >> anything else(such as applicaiton, a class of device or >> application), the >> similiar things may happen. So, for a lot of scenarios, >> binding check is not >> practical! >> >> Now the question are: Do we really need binding check? Does >> binding check >> provides any benefit/security? If we need binding check, we >> may only be able >> to use it with host certificate. >> >> Miao >> >>> -----Original Message----- >>> From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] >>> Sent: Friday, April 14, 2006 10:57 PM >>> To: Miao Fuyou; syslog@ietf.org >>> Subject: RE: [Syslog] Summary of the syslog/tls issues resolving >>> >>> >>> Miao: >>> >>>> [Issue 1]: Is it possible to use "generic certificate >>> for different >>>> host? The generic certificate is for specific >> application type. >>>> AND >>>> [Issue 2]: What to bind to a certificate? Hostname, >> Syslog APP- >>>> NAME(generic certificate)? APP-NAME binding makes >>> authentication/ >>>> access control happens both in TLS handshake and Syslog message >>>> processing, is efficiency a problem? >>>> >>>> Tentative resolution: 1, Generic certificate may not be >>>> possible (refer to >>>> http://www1.ietf.org/mail-archive/web/syslog/current/msg00918. >>>> html). >>> >>> I can't support this conclusion. Of course, it is possible - >>> used all the time. >>> >>>> So bind >>>> app-name is not required and possible. >>> >>> Generic certificate does not need to be bound to anything, >>> although it can carry some certified pieces of information. >>> Having a format for putting known fields into certificate CN >>> field would be nice, but not mandatory. >>> >>> I work on a product which manages million of consumer devices >>> (modems, gateways, settop boxes, etc)remotely for service >>> providers (SPs). These SPs are starting to use SSL/TLS for >>> many CPE to back-end interactions. Some SPs use unique >>> certificates on each device, in which case it is a device ID >>> such as serial number or MAC address embedded in certificate >>> CN field - not hostname. Case study, DSL Forum defines use of >>> device ID in certificate CN field in their CWMP standard >>> defined in TR-069 / WT-121. The same standard also allows for >>> use of generic certificates. >>> >>> Some SP want to use the same cert on all devices. That >>> generic cert identifies either manufacturer or service >>> provider. It does not authenticate a specific CPE, but rather >>> as a way to establish that CPE is the right kind to connect >>> to backend systems. Similar vendor certificates, I believe, >>> are used in Cable industry's PacketCable VoIP standards >>> (although they have unique ones too). In this environment, >>> having a unique certificate on millions of devices is >>> generally considered a serious cost factor - adds cost to >>> CPE. Sometimes a combination of generic cert + HTTP digest >>> authentication is used. In syslog case, syslog payload >>> signing could be the option that could replace HTTP digest >>> authentication. >>> >>> The point of above is that generic certificates are used >>> today, part of standards and seem to make sense to large >>> organizations which demand their use. So, it is certainly >>> possible to use those and would be a good idea for syslog to >>> support it too. >>> >>>> 2, We need cerficate >>>> binding to host >>>> name, operator to decide whether to check the binding. >>> >>> Certificate with hostname (FQDN, right?) in the CN is a >>> decent option, but as I mentioned above, this is not what say >>> DSL SPs use to identify devices. Hostname for unique >>> certificate can't be a requirement IMO. >>> >>> I agree that it should be operator decision whether or not to >>> check the certificate binding. >>> >>>> Receiver may consult >>>> DNS to get host name for a sender, while sender may just >>> query local >>>> configuration to get host name. >>> >>> Not sure what you mean here. Certificates have to be >>> generated by CA (certificate Authority) which has the private >>> key, then installed on the host. The sender can't just >>> generate one by looking up the hostname. Or are you talking >>> about hostname inserted in syslog message field? >>> >>> Also, why does receiver need to consult DNS? >>> >>>> [Issue 4]: Shall we mandate the sender MUST be >>> authenticated? Most >>>> of the Syslogd accepts messages only from configured address. >>> >>> In TCP, restricting by source IP buys you more than in UDP >>> where it is easy to spoof, but even in TCP it is hardly an >>> authentication mechanism or we would not be talking about TLS >>> auth. In case of my application with millions of devices, you >>> would have to allow huge subnets anyway and addresses are >>> allocated dynamically using DHCP. >>> >>>> Tentative resolution: It should be optional to operator, use >>>> SHOULD or MAY >>>> instead of MUST and explain security implication. I tend to >>>> use SHOULD. >>> >>> Sounds good. Please state clearly what it means to >>> authenticate the sender though. Is it a sender presenting a >>> legitimate signed certificate (be it generic or unique)? Or >>> does it include checking certificate binding by comparing CN >>> field to some field in syslog message (like FQDN)? In case of >>> latter, the syslog would need to carry FQDN (not hostname or >>> IP which are allowed substitutes) as well. >>> >>> Thanks, >>> Anton. >>> >>>> (Refer to >>>> >> http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html) >>>> >>>> Miao >>>> >>>> >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>> >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Apr 17 21:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVeit-0005aV-Fm; Mon, 17 Apr 2006 21:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVeis-0005aQ-7G for syslog@ietf.org; Mon, 17 Apr 2006 21:09:42 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVeiq-0001iY-QC for syslog@ietf.org; Mon, 17 Apr 2006 21:09:42 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXW00CU78JJ0U@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 18 Apr 2006 09:09:19 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXW00G3J8JI6B@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 18 Apr 2006 09:09:19 +0800 (CST) Received: from m19684 ([10.110.114.80]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXW00KHA966IM@szxml02-in.huawei.com>; Tue, 18 Apr 2006 09:23:04 +0800 (CST) Date: Tue, 18 Apr 2006 09:08:57 +0800 From: Miao Fuyou Subject: RE: [Syslog] Summary of the syslog/tls issues resolving In-reply-to: To: 'Chris Lonvick' , "'Anton Okmianski (aokmians)'" Message-id: <009601c66284$aec10bd0$50726e0a@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: 918f4bd8440e8de4700bcf6d658bc801 Cc: dperkins@dsperkins.com, 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 believe now the best thing we can do is: we do not exclude certificate in any form, generic or unique, to maximize syslog/tls deployment. We can talk what CN is possible to be for a certificate, but we don't specify how to process CN for sender/receiver. > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Tuesday, April 18, 2006 12:34 AM > To: Anton Okmianski (aokmians) > Cc: Miao Fuyou; dperkins@dsperkins.com; syslog@ietf.org > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > > > Hi Anton, > > Your proposal seems to be overlapping syslog-sign. > > I think that what the community would like (this is open for > debate) is > for a standard that will allow an existing implementation of > syslog to use > syslog/tls in a standard way right now. The next step would > be to convert > to syslog-protocol, and the step beyond that would be to include > syslog-sign. > > On the subject of binding checks, perhaps it would be good to > keep in mind > that some syslog senders are things like printers or other > devices that > will have a certificate issued at the time it was > manufactured. Is it > going to be worth the effort for the operations staff to > install localized > certificates, or would they be willing to accept those and > just use access > control lists? (David Perkins mentioned this to me and said > that it was > OK for me to include him in this discussion - which is why > I'm cc'ing him > on this.) > > Thanks, > Chris > > > On Mon, 17 Apr 2006, Anton Okmianski (aokmians) wrote: > > > Miao: > > > > The layering is not a problem. The TLS stack will expose > the validated > > client certificate to the upper layer. That layer (syslog > server app) > > can do whatever it wants with the certificate data. > > > > However, I don't think binding check should be required. For one, > > this would preclude the most generic certificates. There may be too > > many options about how one may want to validate/use the client > > identity in the certificate. For example, one could > configure syslog > > server to allow clients which have one of the defined > strings in the > > CN fields (could be hostnames or whatever) or it could consult a > > database of clients. Alternatively (or in addition), one can check > > the CN content against some field in the syslog message itself. > > > > I think having a standard way to identify individual syslog clients > > using syslog-over-TLS would be very useful. This means that client > > identity could be extracted our of certificate. > > > > Possibly, all we need to do here is: > > > > (a) say that certificate CN MAY carry syslog client identity > > information > > (b) REQUIRE insertion of CN data into syslog message (relay or not) > > (c) define structured element for insertion of CN data > > (d) RECOMMEND that syslog servers provide a function to > restrict access based on CN content > > > > Thoughts? > > > > Thanks, > > Anton. > > > >> -----Original Message----- > >> From: Miao Fuyou [mailto:miaofy@huawei.com] > >> Sent: Monday, April 17, 2006 5:10 AM > >> To: Anton Okmianski (aokmians); syslog@ietf.org > >> Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > >> > >> > >> The confusion comes from the relationship of binding and > >> authentication. > >> > >> In TLS/SSL, authentciation is to check whether a CA trusted by the > >> checker in the certificate chain is available. If there is trusted > >> CA, checker may > >> check the binding of common name of certificate to > something available > >> locally, such as host name. But, binding check is not a step for > >> authentcation by certificate's nature. > >> > >> If we consider authentication only, it will be much simple. A > >> receiver just check the trustship of sender's certificate without > >> checking binding, regardless what entity(a host, an application, a > >> class of device or application described in Anton's scenario) the > >> certificate is issued to. In > >> such case, generic certificate is possible. > >> > >> When we discuss certificate/CN binding, it becomes tricky. > It is not > >> practical to check the binding of APP-NAME or anything from syslog > >> message, such as FQDN, to certificate when authentciating a sender. > >> Such binding > >> check will breach the layership and modularity of tls/syslog, > >> and may impact > >> efficiency badly. This point was discussed by Balazs and me > >> on the mailing > >> list( > >> http://www1.ietf.org/mail-archive/web/syslog/current/msg00918). We > >> MUST rely on the information available to TLS layer to check > >> the binding of > >> common name. One such information is hostname, so we are able > >> to check the > >> binding of hostname to certificate when it is issued to host(host > >> certificate, or unique certificate). When common name of a > >> host certificate > >> is device ID or MAC etc, it is not practical to check the > >> binding because of > >> inavailablity of such information to TLS. If a certificate is > >> issued to > >> anything else(such as applicaiton, a class of device or > >> application), the > >> similiar things may happen. So, for a lot of scenarios, > >> binding check is not > >> practical! > >> > >> Now the question are: Do we really need binding check? > Does binding > >> check provides any benefit/security? If we need binding check, we > >> may only be able > >> to use it with host certificate. > >> > >> Miao > >> > >>> -----Original Message----- > >>> From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > >>> Sent: Friday, April 14, 2006 10:57 PM > >>> To: Miao Fuyou; syslog@ietf.org > >>> Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > >>> > >>> > >>> Miao: > >>> > >>>> [Issue 1]: Is it possible to use "generic certificate > >>> for different > >>>> host? The generic certificate is for specific > >> application type. > >>>> AND > >>>> [Issue 2]: What to bind to a certificate? Hostname, > >> Syslog APP- > >>>> NAME(generic certificate)? APP-NAME binding makes > >>> authentication/ > >>>> access control happens both in TLS handshake and > Syslog message > >>>> processing, is efficiency a problem? > >>>> > >>>> Tentative resolution: 1, Generic certificate may not be possible > >>>> (refer to > >>>> http://www1.ietf.org/mail-archive/web/syslog/current/msg00918. > >>>> html). > >>> > >>> I can't support this conclusion. Of course, it is possible - used > >>> all the time. > >>> > >>>> So bind > >>>> app-name is not required and possible. > >>> > >>> Generic certificate does not need to be bound to > anything, although > >>> it can carry some certified pieces of information. Having > a format > >>> for putting known fields into certificate CN field would be nice, > >>> but not mandatory. > >>> > >>> I work on a product which manages million of consumer devices > >>> (modems, gateways, settop boxes, etc)remotely for service > providers > >>> (SPs). These SPs are starting to use SSL/TLS for many CPE to > >>> back-end interactions. Some SPs use unique certificates on each > >>> device, in which case it is a device ID such as serial > number or MAC > >>> address embedded in certificate CN field - not hostname. > Case study, > >>> DSL Forum defines use of device ID in certificate CN > field in their > >>> CWMP standard defined in TR-069 / WT-121. The same standard also > >>> allows for use of generic certificates. > >>> > >>> Some SP want to use the same cert on all devices. That > generic cert > >>> identifies either manufacturer or service provider. It does not > >>> authenticate a specific CPE, but rather as a way to > establish that > >>> CPE is the right kind to connect to backend systems. > Similar vendor > >>> certificates, I believe, are used in Cable industry's PacketCable > >>> VoIP standards (although they have unique ones too). In this > >>> environment, having a unique certificate on millions of devices is > >>> generally considered a serious cost factor - adds cost to > >>> CPE. Sometimes a combination of generic cert + HTTP digest > >>> authentication is used. In syslog case, syslog payload > >>> signing could be the option that could replace HTTP digest > >>> authentication. > >>> > >>> The point of above is that generic certificates are used > today, part > >>> of standards and seem to make sense to large organizations which > >>> demand their use. So, it is certainly possible to use those and > >>> would be a good idea for syslog to support it too. > >>> > >>>> 2, We need cerficate > >>>> binding to host > >>>> name, operator to decide whether to check the binding. > >>> > >>> Certificate with hostname (FQDN, right?) in the CN is a decent > >>> option, but as I mentioned above, this is not what say > DSL SPs use > >>> to identify devices. Hostname for unique certificate can't be a > >>> requirement IMO. > >>> > >>> I agree that it should be operator decision whether or > not to check > >>> the certificate binding. > >>> > >>>> Receiver may consult > >>>> DNS to get host name for a sender, while sender may just > >>> query local > >>>> configuration to get host name. > >>> > >>> Not sure what you mean here. Certificates have to be > generated by CA > >>> (certificate Authority) which has the private key, then > installed on > >>> the host. The sender can't just generate one by looking up the > >>> hostname. Or are you talking about hostname inserted in syslog > >>> message field? > >>> > >>> Also, why does receiver need to consult DNS? > >>> > >>>> [Issue 4]: Shall we mandate the sender MUST be > >>> authenticated? Most > >>>> of the Syslogd accepts messages only from configured address. > >>> > >>> In TCP, restricting by source IP buys you more than in > UDP where it > >>> is easy to spoof, but even in TCP it is hardly an authentication > >>> mechanism or we would not be talking about TLS auth. In > case of my > >>> application with millions of devices, you would have to > allow huge > >>> subnets anyway and addresses are allocated dynamically using DHCP. > >>> > >>>> Tentative resolution: It should be optional to operator, > use SHOULD > >>>> or MAY instead of MUST and explain security implication. > I tend to > >>>> use SHOULD. > >>> > >>> Sounds good. Please state clearly what it means to > authenticate the > >>> sender though. Is it a sender presenting a legitimate signed > >>> certificate (be it generic or unique)? Or does it > include checking > >>> certificate binding by comparing CN field to some field in syslog > >>> message (like FQDN)? In case of latter, the syslog would need to > >>> carry FQDN (not hostname or IP which are allowed substitutes) as > >>> well. > >>> > >>> Thanks, > >>> Anton. > >>> > >>>> (Refer to > >>>> > >> http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html) > >>>> > >>>> Miao > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > >>>> > >>> > >> > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Apr 19 14:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHNe-0005Ot-0M; Wed, 19 Apr 2006 14:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHNc-0005ON-9L for syslog@ietf.org; Wed, 19 Apr 2006 14:26:20 -0400 Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWHNZ-0000A0-5p for syslog@ietf.org; Wed, 19 Apr 2006 14:26:20 -0400 Subject: RE: [Syslog] Summary of the syslog/tls issues resolving From: Balazs Scheidler To: "Anton Okmianski (aokmians)" In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201510D05@xmb-rtp-20d.amer.cisco.com> References: <98AE08B66FAD1742BED6CB9522B7312201510D05@xmb-rtp-20d.amer.cisco.com> Content-Type: text/plain Date: Wed, 19 Apr 2006 20:26:06 +0200 Message-Id: <1145471166.7520.58.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 On Fri, 2006-04-14 at 10:56 -0400, Anton Okmianski (aokmians) wrote: > Miao: > > > [Issue 1]: Is it possible to use "generic certificate for different > > host? The generic certificate is for specific application type. > > AND > > [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- > > NAME(generic certificate)? APP-NAME binding makes authentication/ > > access control happens both in TLS handshake and Syslog message > > processing, is efficiency a problem? > > > > Tentative resolution: 1, Generic certificate may not be > > possible (refer to > > http://www1.ietf.org/mail-archive/web/syslog/current/msg00918. > > html). > > I can't support this conclusion. Of course, it is possible - used all the time. Although the email above was written by me, there must have been some kind of misunderstanding, probably on my side. My understanding is: 1) we should define some kind of certificate binding scheme (like subjectAltName is for HTTP) 2) we probably should allow the operator to override this mechanism and avoid having to check this. > > > So bind > > app-name is not required and possible. > > Generic certificate does not need to be bound to anything, although it can carry some > certified pieces of information. Having a format for putting known fields into > certificate CN field would be nice, but not mandatory. > > I work on a product which manages million of consumer devices (modems, gateways, > settop boxes, etc)remotely for service providers (SPs). These SPs are starting to > use SSL/TLS for many CPE to back-end interactions. Some SPs use unique certificates > on each device, in which case it is a device ID such as serial number or MAC address > embedded in certificate CN field - not hostname. Case study, DSL Forum defines use > of device ID in certificate CN field in their CWMP standard defined in TR-069 / WT-121. > The same standard also allows for use of generic certificates. > > Some SP want to use the same cert on all devices. That generic cert identifies either > manufacturer or service provider. It does not authenticate a specific CPE, but rather > as a way to establish that CPE is the right kind to connect to backend systems. Similar > vendor certificates, I believe, are used in Cable industry's PacketCable VoIP standards > (although they have unique ones too). In this environment, having a unique certificate > on millions of devices is generally considered a serious cost factor - adds cost to CPE. > Sometimes a combination of generic cert + HTTP digest authentication is used. In syslog > case, syslog payload signing could be the option that could replace HTTP digest authentication. > > The point of above is that generic certificates are used today, part of standards and > seem to make sense to large organizations which demand their use. So, it is certainly > possible to use those and would be a good idea for syslog to support it too. I think these are the exact situations when certificate binding should be turned off, or tweaked. > > > 2, We need cerficate > > binding to host > > name, operator to decide whether to check the binding. > > Certificate with hostname (FQDN, right?) in the CN is a decent option, but as I mentioned above, > this is not what say DSL SPs use to identify devices. Hostname for unique certificate can't > be a requirement IMO. > > I agree that it should be operator decision whether or not to check the certificate binding. > > > Receiver may consult > > DNS to get host name for a sender, while sender may just query local > > configuration to get host name. > > Not sure what you mean here. Certificates have to be generated by CA (certificate > Authority) which has the private key, then installed on the host. The sender can't > just generate one by looking up the hostname. Or are you talking about hostname > inserted in syslog message field? > > Also, why does receiver need to consult DNS? The problem is with syslog that you get a connection from an IP address without any hostname information. If we are to define a certificate binding scheme that involves the name of the client's host, then we need to map the IP address to a hostname somehow. The sender is in an easy situation, we configure it to forward all logs to a specified syslog receiver, with the also specified hostname (like the hostname in the HTTPS URL). Certificate binding can be done, no problem. On the receiver side, things are a bit more difficult: it is listening for any number of clients, and these clients are not usually listed in their configuration (e.g. it is an open server like HTTPS) The problem in this case is that there is no hostname information apart from the IP. Our solution might be somewhat similar to what HTTPS has: * define a certificate binding scheme for syslog receivers (in which case it can easily be validated by the sender as it has the necessary information) * and leave it to implementations/operators for definition in the case of senders, just like client certificates in HTTPS, this way no DNS is required. > > > [Issue 4]: Shall we mandate the sender MUST be authenticated? Most > > of the Syslogd accepts messages only from configured address. > > In TCP, restricting by source IP buys you more than in UDP where it is > easy to spoof, but even in TCP it is hardly an authentication mechanism > or we would not be talking about TLS auth. In case of my application with > millions of devices, you would have to allow huge subnets anyway and > addresses are allocated dynamically using DHCP. Sometimes it is enough to validate the syslog server for secrecy and client authentication is not required. > > > Tentative resolution: It should be optional to operator, use > > SHOULD or MAY > > instead of MUST and explain security implication. I tend to > > use SHOULD. > > Sounds good. Please state clearly what it means to authenticate the sender > though. Is it a sender presenting a legitimate signed certificate (be it > generic or unique)? Or does it include checking certificate binding by > comparing CN field to some field in syslog message (like FQDN)? In case > of latter, the syslog would need to carry FQDN (not hostname or IP which > are allowed substitutes) as well. The problem with validating the host field in the message, that a single sender may produce several different, but still valid names: relays which receive messages from its close neighbours and send messages to a syslog center for processing. In this case the relay has a single certificate. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Apr 19 18:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKkQ-0004Dd-KV; Wed, 19 Apr 2006 18:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKkO-0004DX-TC for syslog@ietf.org; Wed, 19 Apr 2006 18:02:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWKkO-0002EG-7t for syslog@ietf.org; Wed, 19 Apr 2006 18:02:04 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2006 15:02:03 -0700 X-IronPort-AV: i="4.04,137,1144047600"; d="scan'208"; a="269876706:sNHT101073790" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3JM1tVM009755; Wed, 19 Apr 2006 15:01:59 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 18:01:58 -0400 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] Summary of the syslog/tls issues resolving Date: Wed, 19 Apr 2006 18:01:57 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122015650F6@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Summary of the syslog/tls issues resolving Thread-Index: AcZj3sFKykN/q9TMSjOTEJRBX9+31QADEPfA From: "Anton Okmianski \(aokmians\)" To: "Balazs Scheidler" X-OriginalArrivalTime: 19 Apr 2006 22:01:58.0724 (UTC) FILETIME=[E12B0840:01C663FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 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 Balazs: I don't think DNS lookup for validating clients will work in all cases. = If syslog clients are NAT'ed (and many CPEs are), it does not make sense = for them to have a hostname. You will not see the real source IP on = syslog server. So, if we recommend it as basic standard binding its use = will be limited. =20 I agree that server validation is different. In this case you have the = ultimate source IP and hostname lookup helps. You are validating that = the certificate the server presented is not just signed by right CA, but = also authenticates the server you intended to connect to. =20 In case of authenticating clients, I see two uses for it: (a) restricting access to server to a subset of clients; this can be = accomplished by CPE presenting a generic certificate signed by a given = CA (say my organization CA); if further granularity of access control = is needed, some data from certificate needs to be compared against a = list or a database - this is where "binding check" comes in, if you want = to call it that; this should be allowed; (b) establishing the real identity of the sender, so you can trust its = messages; here you don't necessarily care to limit access to the server, = but rather care to have an indication about client identity that = generated a given message; this is where insertion of CN data into = message helps - it helps you understand who really sent the message; in = case of generic certificate you may decide to trust what the client says = in syslog message as long as it presented a valid generic certificate. I can't think of a good standard binding check for clients (I don't mind = us recommending it if we can come up with one), but I can see the value = of standard way to identify the authenticated source in the message by = inserting CN/CA field. =20 Thanks, Anton.=20 =20 > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Wednesday, April 19, 2006 2:26 PM > To: Anton Okmianski (aokmians) > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving >=20 > On Fri, 2006-04-14 at 10:56 -0400, Anton Okmianski (aokmians) wrote: > > Miao: > >=20 > > > [Issue 1]: Is it possible to use "generic certificate=20 > for different > > > host? The generic certificate is for specific=20 > application type. > > > AND > > > [Issue 2]: What to bind to a certificate? Hostname,=20 > Syslog APP- > > > NAME(generic certificate)? APP-NAME binding makes=20 > authentication/ > > > access control happens both in TLS handshake and Syslog message > > > processing, is efficiency a problem? > > >=20 > > > Tentative resolution: 1, Generic certificate may not be=20 > > > possible (refer to > > > http://www1.ietf.org/mail-archive/web/syslog/current/msg00918. > > > html).=20 > >=20 > > I can't support this conclusion. Of course, it is possible=20 > - used all the time.=20 >=20 > Although the email above was written by me, there must have been some > kind of misunderstanding, probably on my side. >=20 > My understanding is: > 1) we should define some kind of certificate binding scheme (like > subjectAltName is for HTTP) > 2) we probably should allow the operator to override this=20 > mechanism and > avoid having to check this. >=20 > >=20 > > > So bind > > > app-name is not required and possible.=20 > >=20 > > Generic certificate does not need to be bound to anything,=20 > although it can carry some=20 > > certified pieces of information. Having a format for=20 > putting known fields into=20 > > certificate CN field would be nice, but not mandatory. =20 > >=20 > > I work on a product which manages million of consumer=20 > devices (modems, gateways,=20 > > settop boxes, etc)remotely for service providers (SPs).=20 > These SPs are starting to=20 > > use SSL/TLS for many CPE to back-end interactions. Some SPs=20 > use unique certificates=20 > > on each device, in which case it is a device ID such as=20 > serial number or MAC address=20 > > embedded in certificate CN field - not hostname. Case=20 > study, DSL Forum defines use=20 > > of device ID in certificate CN field in their CWMP standard=20 > defined in TR-069 / WT-121.=20 > > The same standard also allows for use of generic certificates. =20 > >=20 > > Some SP want to use the same cert on all devices. That=20 > generic cert identifies either > > manufacturer or service provider. It does not authenticate=20 > a specific CPE, but rather=20 > > as a way to establish that CPE is the right kind to connect=20 > to backend systems. Similar=20 > > vendor certificates, I believe, are used in Cable=20 > industry's PacketCable VoIP standards=20 > > (although they have unique ones too). In this environment,=20 > having a unique certificate=20 > > on millions of devices is generally considered a serious=20 > cost factor - adds cost to CPE.=20 > > Sometimes a combination of generic cert + HTTP digest=20 > authentication is used. In syslog=20 > > case, syslog payload signing could be the option that could=20 > replace HTTP digest authentication. =20 > >=20 > > The point of above is that generic certificates are used=20 > today, part of standards and=20 > > seem to make sense to large organizations which demand=20 > their use. So, it is certainly=20 > > possible to use those and would be a good idea for syslog=20 > to support it too.=20 >=20 > I think these are the exact situations when certificate binding should > be turned off, or tweaked. >=20 > >=20 > > > 2, We need cerficate=20 > > > binding to host > > > name, operator to decide whether to check the binding.=20 > >=20 > > Certificate with hostname (FQDN, right?) in the CN is a=20 > decent option, but as I mentioned above,=20 > > this is not what say DSL SPs use to identify devices.=20 > Hostname for unique certificate can't=20 > > be a requirement IMO. =20 > >=20 > > I agree that it should be operator decision whether or not=20 > to check the certificate binding.=20 > >=20 > > > Receiver may consult > > > DNS to get host name for a sender, while sender may just=20 > query local > > > configuration to get host name. > >=20 > > Not sure what you mean here. Certificates have to be=20 > generated by CA (certificate=20 > > Authority) which has the private key, then installed on the=20 > host. The sender can't=20 > > just generate one by looking up the hostname. Or are you=20 > talking about hostname=20 > > inserted in syslog message field? =20 > >=20 > > Also, why does receiver need to consult DNS? =20 >=20 > The problem is with syslog that you get a connection from an=20 > IP address > without any hostname information. If we are to define a certificate > binding scheme that involves the name of the client's host,=20 > then we need > to map the IP address to a hostname somehow. >=20 > The sender is in an easy situation, we configure it to=20 > forward all logs > to a specified syslog receiver, with the also specified hostname (like > the hostname in the HTTPS URL). Certificate binding can be done, no > problem. >=20 > On the receiver side, things are a bit more difficult: it is listening > for any number of clients, and these clients are not usually listed in > their configuration (e.g. it is an open server like HTTPS) The problem > in this case is that there is no hostname information apart=20 > from the IP. >=20 > Our solution might be somewhat similar to what HTTPS has: > * define a certificate binding scheme for syslog receivers (in which > case it can easily be validated by the sender as it has the necessary > information) > * and leave it to implementations/operators for definition in the case > of senders, just like client certificates in HTTPS, this way no DNS is > required. >=20 > >=20 > > > [Issue 4]: Shall we mandate the sender MUST be=20 > authenticated? Most > > > of the Syslogd accepts messages only from configured address. > >=20 > > In TCP, restricting by source IP buys you more than in UDP=20 > where it is=20 > > easy to spoof, but even in TCP it is hardly an=20 > authentication mechanism=20 > > or we would not be talking about TLS auth. In case of my=20 > application with=20 > > millions of devices, you would have to allow huge subnets=20 > anyway and=20 > > addresses are allocated dynamically using DHCP. =20 >=20 > Sometimes it is enough to validate the syslog server for secrecy and > client authentication is not required. >=20 > >=20 > > > Tentative resolution: It should be optional to operator, use=20 > > > SHOULD or MAY > > > instead of MUST and explain security implication. I tend to=20 > > > use SHOULD. > >=20 > > Sounds good. Please state clearly what it means to=20 > authenticate the sender=20 > > though. Is it a sender presenting a legitimate signed=20 > certificate (be it=20 > > generic or unique)? Or does it include checking=20 > certificate binding by=20 > > comparing CN field to some field in syslog message (like=20 > FQDN)? In case=20 > > of latter, the syslog would need to carry FQDN (not=20 > hostname or IP which=20 > > are allowed substitutes) as well.=20 >=20 > The problem with validating the host field in the message,=20 > that a single > sender may produce several different, but still valid names: >=20 > relays which receive messages from its close neighbours and send > messages to a syslog center for processing. In this case the=20 > relay has a > single certificate. >=20 > --=20 > Bazsi >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Apr 20 03:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTmb-0003Ej-RY; Thu, 20 Apr 2006 03:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTma-0003E8-WF for syslog@ietf.org; Thu, 20 Apr 2006 03:40:57 -0400 Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWTmW-0006RK-2G for syslog@ietf.org; Thu, 20 Apr 2006 03:40:56 -0400 Subject: RE: [Syslog] Summary of the syslog/tls issues resolving From: Balazs Scheidler To: "Anton Okmianski (aokmians)" In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122015650F6@xmb-rtp-20d.amer.cisco.com> References: <98AE08B66FAD1742BED6CB9522B73122015650F6@xmb-rtp-20d.amer.cisco.com> Content-Type: text/plain Date: Thu, 20 Apr 2006 09:40:47 +0200 Message-Id: <1145518847.6877.2.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 On Wed, 2006-04-19 at 18:01 -0400, Anton Okmianski (aokmians) wrote: > Balazs: > > I don't think DNS lookup for validating clients will work in all cases. If > syslog clients are NAT'ed (and many CPEs are), it does not make sense for > them to have a hostname. You will not see the real source IP on syslog > server. So, if we recommend it as basic standard binding its use will be > limited. Yes, I did not like the approach either, I just could not come up with anything else. > > I agree that server validation is different. In this case you have the > ultimate source IP and hostname lookup helps. You are validating that the > certificate the server presented is not just signed by right CA, but also > authenticates the server you intended to connect to. I think we should not rely on DNS in this case either, but rather require the operator to supply a hostname. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Apr 20 11:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbBJ-00012t-Gq; Thu, 20 Apr 2006 11:34:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbBI-00012a-LR for syslog@ietf.org; Thu, 20 Apr 2006 11:34:56 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbBH-00066q-Bw for syslog@ietf.org; Thu, 20 Apr 2006 11:34:56 -0400 Received: from harrington73653 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70]) by comcast.net (rwcrmhc11) with SMTP id <20060420153453m1100miqshe>; Thu, 20 Apr 2006 15:34:54 +0000 From: "David B Harrington" To: "'Balazs Scheidler'" , "'Anton Okmianski \(aokmians\)'" Subject: RE: [Syslog] Summary of the syslog/tls issues resolving Date: Thu, 20 Apr 2006 11:34:19 -0400 Message-ID: <0ab201c6648f$e4b388f0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-reply-to: <1145518847.6877.2.camel@bzorp.balabit> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I also have concerns about depending on DNS. I want to be sure I understand what you are suggesting as an alternative. Is the mapping from IP to hostname operator-defined in a static way? What happens, network-management-wise, when an IP address changes for a given host, or more importantly, is reissued to a different host? David Harrington FutureWei Technologies, a Huawei company dharrington@huawei.com=20 dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Thursday, April 20, 2006 3:41 AM > To: Anton Okmianski (aokmians) > Cc: syslog@ietf.org > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving >=20 >=20 > On Wed, 2006-04-19 at 18:01 -0400, Anton Okmianski (aokmians) wrote: > > Balazs: > >=20 > > I don't think DNS lookup for validating clients will work=20 > in all cases. If=20 > > syslog clients are NAT'ed (and many CPEs are), it does not=20 > make sense for=20 > > them to have a hostname. You will not see the real source=20 > IP on syslog=20 > > server. So, if we recommend it as basic standard binding=20 > its use will be=20 > > limited. =20 >=20 > Yes, I did not like the approach either, I just could not come up with > anything else. >=20 > >=20 > > I agree that server validation is different. In this case=20 > you have the=20 > > ultimate source IP and hostname lookup helps. You are=20 > validating that the=20 > > certificate the server presented is not just signed by=20 > right CA, but also=20 > > authenticates the server you intended to connect to. =20 >=20 > I think we should not rely on DNS in this case either, but rather > require the operator to supply a hostname. >=20 > --=20 > Bazsi >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Apr 20 11:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbGO-0001EI-NT; Thu, 20 Apr 2006 11:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbGN-0001ED-7k for syslog@ietf.org; Thu, 20 Apr 2006 11:40:11 -0400 Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbGL-0006Rz-So for syslog@ietf.org; Thu, 20 Apr 2006 11:40:11 -0400 Subject: RE: [Syslog] Summary of the syslog/tls issues resolving From: Balazs Scheidler To: David B Harrington In-Reply-To: <0ab201c6648f$e4b388f0$0400a8c0@china.huawei.com> References: <0ab201c6648f$e4b388f0$0400a8c0@china.huawei.com> Content-Type: text/plain Date: Thu, 20 Apr 2006 17:40:07 +0200 Message-Id: <1145547607.6877.35.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: , Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-04-20 at 11:34 -0400, David B Harrington wrote: > Hi, > > I also have concerns about depending on DNS. > > I want to be sure I understand what you are suggesting as an > alternative. > Is the mapping from IP to hostname operator-defined in a static way? > > What happens, network-management-wise, when an IP address changes for > a given host, or more importantly, is reissued to a different host? I would say that the client should be configured to log to log://loghost.domain/ instead of logging to an IP address. (maybe we can also define an URL format, but not necessarily) In this case the name of the host is in the URL, and this is what the certificate should be compared against. This way we only rely on the DNS to forward-resolve hostnames which should work. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Apr 30 05:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa8Gx-0006kO-1l; Sun, 30 Apr 2006 05:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa8Gw-0006kJ-7U for syslog@ietf.org; Sun, 30 Apr 2006 05:31:22 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fa8Gu-0002lj-Il for syslog@ietf.org; Sun, 30 Apr 2006 05:31:22 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYJ00CQ43RJ6A@szxga01-in.huawei.com> for syslog@ietf.org; Sun, 30 Apr 2006 17:30:55 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYJ001EE3RI3S@szxga01-in.huawei.com> for syslog@ietf.org; Sun, 30 Apr 2006 17:30:55 +0800 (CST) Received: from m19684 ([10.110.114.80]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYJ00HW74EG8E@szxml02-in.huawei.com>; Sun, 30 Apr 2006 17:44:44 +0800 (CST) Date: Sun, 30 Apr 2006 17:30:23 +0800 From: Miao Fuyou Subject: RE: [Syslog] Summary of the syslog/tls issues resolving In-reply-to: <1145547607.6877.35.camel@bzorp.balabit> To: 'Balazs Scheidler' , 'David B Harrington' Message-id: <000301c66c38$b571a490$50726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZsOLT4xFOphjUBQ/GFZevw86vkdw== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Another problem of using DNS is: name resolution itself is not secure if DNSSEC is not used (true im most cases). Dependency on DNS may introduce new security vulnerable to Syslog/TLS. Client should use knowledge a priori to check server's certificate, such as URL, if it is available. > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu] > Sent: Thursday, April 20, 2006 11:40 PM > To: David B Harrington > Cc: syslog@ietf.org > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > > On Thu, 2006-04-20 at 11:34 -0400, David B Harrington wrote: > > Hi, > > > > I also have concerns about depending on DNS. > > > > I want to be sure I understand what you are suggesting as an > > alternative. > > Is the mapping from IP to hostname operator-defined in a static way? > > > > What happens, network-management-wise, when an IP address > changes for > > a given host, or more importantly, is reissued to a different host? > > I would say that the client should be configured to log to > log://loghost.domain/ instead of logging to an IP address. > (maybe we can also define an URL format, but not necessarily) > > In this case the name of the host is in the URL, and this is > what the certificate should be compared against. This way we > only rely on the DNS to forward-resolve hostnames which should work. > > -- > Bazsi > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Apr 30 09:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaBl8-00005R-EI; Sun, 30 Apr 2006 09:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaBl6-00005M-TG for syslog@ietf.org; Sun, 30 Apr 2006 09:14:44 -0400 Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaBl5-00023q-Iq for syslog@ietf.org; Sun, 30 Apr 2006 09:14:44 -0400 Subject: RE: [Syslog] Summary of the syslog/tls issues resolving From: Balazs Scheidler To: Miao Fuyou In-Reply-To: <000301c66c38$b571a490$50726e0a@china.huawei.com> References: <000301c66c38$b571a490$50726e0a@china.huawei.com> Content-Type: text/plain Date: Sun, 30 Apr 2006 15:14:56 +0200 Message-Id: <1146402896.8357.10.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'David B Harrington' , 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 On Sun, 2006-04-30 at 17:30 +0800, Miao Fuyou wrote: > Another problem of using DNS is: name resolution itself is not secure if > DNSSEC is not used (true im most cases). Dependency on DNS may introduce new > security vulnerable to Syslog/TLS. > > Client should use knowledge a priori to check server's certificate, such as > URL, if it is available. Yes, you need forward DNS resolution in this case too. (e.g. hostname in URL -> IP address) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog