From syslog-bounces@lists.ietf.org Sun Oct 09 23:17:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOoAA-0002WO-52; Sun, 09 Oct 2005 23:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOoA9-0002WG-3w for syslog@megatron.ietf.org; Sun, 09 Oct 2005 23:17:17 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27138 for ; Sun, 9 Oct 2005 23:17:10 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2005 20:16:41 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9A3GZVu029892 for ; Sun, 9 Oct 2005 20:16:35 -0700 (PDT) Date: Sun, 9 Oct 2005 20:16:39 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1903590565-1128912764=:19278" Content-ID: Cc: Subject: [Syslog] 64th IETF - DRAFT Agenda (fwd) X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1903590565-1128912764=:19278 Content-Type: TEXT/PLAIN; format=flowed; charset=X-UNKNOWN Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Folks, It looks like we're scheduled for Monday evening from 1850 to 1950.=20 Please look this over and let me know if there are any major conflicts=20 with the other groups meeting at that time. Please keep in mind that=20 these meeting slots are subject to change. If I don't hear any objections= =20 to this then I'll push to keep this time slot. Just a reminder: we're using syslog@lists.ietf.org from now on. Thanks, Chris ---------- Forwarded message ---------- Date: Sat, 08 Oct 2005 00:09:26 -0400 From: IETF Agenda To: IETF Announcement list Subject: 64th IETF - DRAFT Agenda IETF Meetings start Monday morning and run through Friday lunchtime, with l= ate scheduling changes. Newcomers' training and technical tutorials take place = the previous Sunday afternoon. Participants should plan their travel accordingl= y. This is the first draft of the agenda, the final agenda will be published October 17, 2005 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D DRAFT Agenda of the Sixty-fourth IETF November 6-11, 2005 As of 10/7/2005 SUNDAY, November 6, 2005 1200-1900 Registration - 1300-1430 Newcomer=E2=80=99s Training - 1300-1500 Security Tutorial - 1500-1700 Introduction to WG Leadership: Chairs & Editors - 1500-1700 DNS for Programmers - 1700-1900 Welcome Reception - MONDAY, November 7, 2005 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP apparea Applications and Transportation Joint Area Meeting INT dnsext DNS Extensions WG INT eap Extensible Authentication Protocol WG OPS grow Global Routing Operations WG RTG ccamp Common Control and Measurement Plane WG 1130-1300 Break 1300-1500 Afternoon Session I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG INT ipdvb IP over Digital Video Broadcast WG INT l2vpn Layer 2 Virtual Private Networks WG OPS capwap Control and Provisioning of Wireless Access Points WG OPS v6ops IPv6 Operations WG SEC dkim Domain Keys Identified Mail BOF TSV ecrit Emergency Context Resolution with Internet Technologies WG TSV ippm IP Performance Metrics WG 1510-1710 Afternoon Session II INT softwire Softwire BOF OPS bmwg Benchmarking Methodology WG RTG rtgarea Routing Area Meeting SEC krb-wg Kerberos WG TSV rmt Reliable Multicast Transport WG TSV sipping Session Initiation Protocol Investigation WG 1710-1740 Afternoon Refreshment Break - 1740-1840 Afternoon Session III APP calsify Calendaring and Scheduling Standards Simplification WG INT mipshop MIPv6 Signaling and Handoff Optimization WG INT ntp Network Time Protocol WG OPS opsarea Operations & Management Open Area RTG rpsec Routing Protocols Security Requirements WG SEC smime S/MIME Mail Security WG TSV fecframe FEC over Transport Framework BOF 1850-1950 Afternoon Session IV APP xmlpatch XML-Patch-Ops BOF INT netlmm Network-based Localized Mobility Management BOF INT ntp Network Time Protocol WG OPS opsarea Operations & Management Open Area RTG bfd Bidirectional Forwarding Detection WG SEC ltans Long-Term Archive and Notary Services WG SEC syslog Security Issues in Network Event Logging WG TSV pmtud Path MTU Discovery WG TUESDAY, November 8, 2005 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP rui Remote UI BOF INT ipv6 IP Version 6 WG INT monami6 Mobile Nodes and Multiple Interfaces in IPv6 BOF OPS radext Radius Extensions WG RTG mpls MultiProtocol Label Switching WG SEC sasl Simple Authentication and Security Layer WG TSV nfsv4 Network File System Version 4 WG TSV xcon Centralized Conferencing WG 1130-1300 Break 1300-1500 Afternoon Session I APP imapext Internet Message Access Protocol Extension WG INT 16ng IPv6 over IEEE 802.6(e) Network BOF RTG forces Forwarding and Control Element Separation WG RTG idr Inter-Domain Routing WG SEC isms Integrated Security Model for SNMP WG SEC pkix Public-Key Infrastructure (X.509) WG TSV rserpool Reliable Server Pooling WG TSV sip Session Initiation Protocol WG 1510-1710 Afternoon Session II GEN edu EduTeam General Meeting INT mip4 Mobility for IPv4 WG OPS dnsop Domain Name System Operations WG RTG gels GMPLS Controlled Ethernet Label Switching BOF RTG ospf Open Shortest Path First IGP WG SEC tls Transport Layer Security WG TSV behave Behavior Engineering for Hindrance Avoidance WG TSV dccp Datagram Congestion Control Protocol WG 1710-1740 Afternoon Refreshment Break - 1740-1840 Afternoon Session III APP crisp Cross Registry Information Service Protocol WG INT dhc Dynamic Host Configuration WG INT pana Protocol for Carrying Authenticaion for Network Access WG IRTF mobopts IP Mobility Optimizations RG OPS imss Internet and Management Support for Storage WG RTG rtgwg Routing Area WG SEC pki4ipsec Profiling Use of PKI in IPSEC WG TSV enum Telephone Number Mapping WG 1850-1950 Afternoon Session IV APP opes Open Pluggable Edge Services WG GEN ipr Intellectual Property Rights WG INT dhc Dynamic Host Configuration WG INT ipoib IP over InfiniBand WG IRTF mobopts IP Mobility Optimizations RG OPS opsec Operational Security Capabilities for IP Network Infrastruc= ture WG SEC msec Multicast Security WG TSV enum Telephone Number Mapping WG WEDNESDAY, November 9, 2005 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG INT dna Detecting Network Attachment WG INT pwe3 Pseudo Wire Emulation Edge to Edge WG OPS mboned MBONE Deployment WG RTG sidr Secure Inter-Domain Routing BOF SEC kitten Kitten (GSS-API Next Generation) WG TSV mmusic Multiparty Multimedia Session Control WG TSV nsis Next Steps in Signaling WG 1130-1300 Break 1300-1500 Afternoon Session I APP geopriv Geographic Location/Privacy WG APP sieve Sieve Mail Filtering Language WG INT nemo Network Mobility WG INT trill Transparent Interconnection of Lots of Links WG RTG l1vpn Layer 1 Virtual Private Networks WG SEC inch Extended Incident Handling WG SEC mobike IKEv2 Mobility and Multihoming WG TSV sipping Session Initiation Protocol Investigation WG 1510-1610 Afternoon Session II GEN pesci Process Evolution Consideration for the IETF BOF INT autoconf Ad-Hoc Network Autoconfiguration BOF RTG isis IS-IS for IP Internets WG SEC mobike IKEv2 Mobility and Multihoming WG TSV xcon Centralized Conferencing WG 1610-1700 Afternoon Refreshment Break - 1700-1930 IETF Operations and Administration Plenary - =09Session Chair: Brian Carpenter 2200 Late Night Session PGP Key Signing THURSDAY, November 10, 2005 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP iee Internationalized Email and Extensions BOF GEN techspec Requirements for IETF Technical Specification Publication B= OF INT mip6 Mobility for IPv6 WG IRTF rrg Routing Research Group RTG pce Path Computation Element WG SEC emu EAP Method Update BOF TSV tcpm TCP Maintenance and Minor Extensions WG TSV voipeer VoIP Peering and Interconnect BOF 1130-1300 Break 1300-1500 Afternoon Session I APP geopriv Geographic Location/Privacy WG INT hip Host Identity Protocol WG INT l3vpn Layer 3 Virtual Private Networks WG OPS psamp Packet Sampling WG RTG manet Mobile Ad hoc Networks WG SEC saag Open Security Area Directorate TSV sip Session Initiation Protocol WG 1510-1610 Afternoon Session II APP ldapbis LDAP (v3) Revision WG INT 6lowpan IPv6 over Low Power WPAN WG OPS ipcdn IP over Cable Data Network WG RTG pim Protocol Independent Multicast WG SEC btns Better Than Nothing Security WG TSV nsis Next Steps in Signaling WG TSV speechsc Speech Services Control WG 1610-1700 Afternoon Refreshment Break - 1700-1930 Technical Plenary - =09Session Chair: Leslie Daigle FRIDAY, November 11, 2005 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP simple SIP for Instant Messaging and Presence Leveraging Extension= s WG INT shim6 Site Multihoming by IPv6 Intermediation WG TSV avt Audio/Visual Transport WG 1230-1500Afternoon Session I IRTF hiprg Host Identity Protocol RG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ---559023410-1903590565-1128912764=:19278 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ---559023410-1903590565-1128912764=:19278-- From syslog-bounces@lists.ietf.org Mon Oct 10 11:17:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzPG-0002dq-8G; Mon, 10 Oct 2005 11:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzPE-0002dM-V5 for syslog@megatron.ietf.org; Mon, 10 Oct 2005 11:17:36 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23928 for ; Mon, 10 Oct 2005 11:17:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DACD927C027 for ; Mon, 10 Oct 2005 17:16:01 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32707-06 for ; Mon, 10 Oct 2005 17:16:01 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 8431627C018 for ; Mon, 10 Oct 2005 17:16:01 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2005 17:17:03 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 10 Oct 2005 17:17:03 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3B93@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcXJEUtAnbDgiHKCR+CHzUBPZjfdcwABMb5wASVZP8A= From: "Rainer Gerhards" To: X-OriginalArrivalTime: 10 Oct 2005 15:17:03.0988 (UTC) FILETIME=[AB7A4340:01C5CDAD] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi list, I have talked offline to some collagues. Most of them share Alex (and my) concerns on the name space designator size. However, all share the concerns about just using x- as a prefix, thus providing no solution for namespace collisions. Given the problems we often face with namespace collisions, I think that we should actually require strict rules. So while space is an issue, it is worth to sacrify some space (octets) to solve the namespace issue. So we are in for namespace identifiers. On the issue of what exactly to use, we talked about something like ssh, but with shorter identifiers. Definitely, that would introduce a syntax not yet used in other protocols, be it looks more intuitive that the - prefix. The suggestion is to use @. So instead of #1 mySDID@example.example.com or #2 19406-mySDID we could use mySDID@19406 (19406 is the Adiscon-assigend enterprise ID - is there an example ID like the example.com domain?) This is brief, close to SNMP and looks familiar. Feedback is appreciated. If there are no objections to this approach, I will create some text. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Alexander Clemm (alex) > Sent: Tuesday, October 04, 2005 9:10 PM > To: Chris Lonvick (clonvick); David B Harrington > Cc: syslog-sec@employees.org > Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 >=20 > In general, the "@example.company.com" name space is a nice idea. > However, I am concerned about the length that this=20 > introduces. I would > much prefer to have a more compact encoding, resembling what=20 > parameters > would look like in SDP more than what they would look like=20 > XML (in terms > of compactness). This is one reason why I actually like the=20 > proposal to > use the company identifier (typically 3 digits) as prefix (followed by > some delimiter) as was suggested to denote a private name space. >=20 > Just my 2 cents. > --- Alex >=20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chris > Lonvick (clonvick) > Sent: Monday, October 03, 2005 6:25 PM > To: David B Harrington > Cc: syslog-sec@employees.org > Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 >=20 > Hi David, >=20 > On Fri, 30 Sep 2005, David B Harrington wrote: >=20 > > Hi, > > > > Because I believe we should be working to integrate our network=20 > > management standards, at least to the point they can secure and=20 > > correlate data easily across NM interfaces, I would like to see the=20 > > approach adopted by syslog to be similar to the approaches used by=20 > > other IETF protocols, especially network management protocols. >=20 > I'd like that as well. >=20 > > > > SNMP uses the vendor ID approach, managed by IANA. > > Netconf has no data model, so we don't know what they will use for=20 > > vendor extensions. > > I'm not sure what ipfix is using. > > > > Who will manage the @cisco.com registrations? IANA or=20 > another external >=20 > > agency? Will the assignments be as stable as IANA assignments? >=20 > The "...@example.com" namespace for SSH is for private use=20 > and will not > be registered with anyone. It's been working well enough for the SSH > community with the warning of, "It is up to each domain how it manages > its local namespace." I will say that this practice in SSH is not as > widespread as SNMP but it has been done and it seems to be working. >=20 > It would be good to have discussion of this on the mailing list and we > can hopefully finalize what we want in Vancouver. Your input would be > appreciated. >=20 > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 10 14:12:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP28Z-0007Qn-2V; Mon, 10 Oct 2005 14:12:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP28X-0007QV-Oi for syslog@megatron.ietf.org; Mon, 10 Oct 2005 14:12:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10158 for ; Mon, 10 Oct 2005 14:12:31 -0400 (EDT) Message-Id: <200510101812.OAA10158@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP2IT-0003rn-Eg for syslog@ietf.org; Mon, 10 Oct 2005 14:22:50 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101018121601500bcv9ue>; Mon, 10 Oct 2005 18:12:16 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] RE: [Syslog-sec] AD Review fordraft-ietf-syslog-protocol-14 Date: Mon, 10 Oct 2005 14:12:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3B93@grfint2.intern.adiscon.com> Thread-Index: AcXJEUtAnbDgiHKCR+CHzUBPZjfdcwABMb5wASVZP8AABkq9wA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Just for clarity, 19406 is the IANA-assigned enterprise ID for Adiscon, not an Adiscon-assigned enterprise ID. I see the space-saving difference between #1 and the alternatives, and prefer the shorter format. I also prefer the IANA-assigned identifier since we are guaranteed that will not change, or will change in very specific ways, whereas I am less convinced of the stability of domain names. I don't really see any effective difference between #2 and your proposal, so either is fine with me. Unless, of course "-" is already a reserved character, and using "@" means we're reserving yet another character for no particular benefit. And if companies are already likely to use "@" in their messages for other purposes, then making this an additional reserved character would not be backwards compatible. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, October 10, 2005 11:17 AM > To: syslog@ietf.org > Subject: [Syslog] RE: [Syslog-sec] AD Review > fordraft-ietf-syslog-protocol-14 > > Hi list, > > I have talked offline to some collagues. Most of them share Alex (and > my) concerns on the name space designator size. However, all share the > concerns about just using x- as a prefix, thus providing no > solution for > namespace collisions. Given the problems we often face with namespace > collisions, I think that we should actually require strict rules. So > while space is an issue, it is worth to sacrify some space (octets) to > solve the namespace issue. So we are in for namespace identifiers. > > On the issue of what exactly to use, we talked about > something like ssh, > but with shorter identifiers. Definitely, that would > introduce a syntax > not yet used in other protocols, be it looks more intuitive that the > - prefix. > > The suggestion is to use @. So instead of > > #1 mySDID@example.example.com > > or > > #2 19406-mySDID > > we could use > > mySDID@19406 > > (19406 is the Adiscon-assigend enterprise ID - is there an example ID > like the example.com domain?) > > This is brief, close to SNMP and looks familiar. > > Feedback is appreciated. If there are no objections to this > approach, I > will create some text. > > Rainer > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Alexander Clemm (alex) > > Sent: Tuesday, October 04, 2005 9:10 PM > > To: Chris Lonvick (clonvick); David B Harrington > > Cc: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > > > > In general, the "@example.company.com" name space is a nice idea. > > However, I am concerned about the length that this > > introduces. I would > > much prefer to have a more compact encoding, resembling what > > parameters > > would look like in SDP more than what they would look like > > XML (in terms > > of compactness). This is one reason why I actually like the > > proposal to > > use the company identifier (typically 3 digits) as prefix > (followed by > > some delimiter) as was suggested to denote a private name space. > > > > Just my 2 cents. > > --- Alex > > > > -----Original Message----- > > From: syslog-sec-bounces@willers.employees.org > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chris > > Lonvick (clonvick) > > Sent: Monday, October 03, 2005 6:25 PM > > To: David B Harrington > > Cc: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > > > > Hi David, > > > > On Fri, 30 Sep 2005, David B Harrington wrote: > > > > > Hi, > > > > > > Because I believe we should be working to integrate our network > > > management standards, at least to the point they can secure and > > > correlate data easily across NM interfaces, I would like > to see the > > > approach adopted by syslog to be similar to the > approaches used by > > > other IETF protocols, especially network management protocols. > > > > I'd like that as well. > > > > > > > > SNMP uses the vendor ID approach, managed by IANA. > > > Netconf has no data model, so we don't know what they > will use for > > > vendor extensions. > > > I'm not sure what ipfix is using. > > > > > > Who will manage the @cisco.com registrations? IANA or > > another external > > > > > agency? Will the assignments be as stable as IANA assignments? > > > > The "...@example.com" namespace for SSH is for private use > > and will not > > be registered with anyone. It's been working well enough > for the SSH > > community with the warning of, "It is up to each domain how > it manages > > its local namespace." I will say that this practice in SSH > is not as > > widespread as SNMP but it has been done and it seems to be working. > > > > It would be good to have discussion of this on the mailing > list and we > > can hopefully finalize what we want in Vancouver. Your > input would be > > appreciated. > > > > Thanks, > > Chris > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > _______________________________________________ > 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 Oct 10 14:39:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2Ys-0004lC-Lr; Mon, 10 Oct 2005 14:39:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2Yq-0004kz-F0 for syslog@megatron.ietf.org; Mon, 10 Oct 2005 14:39:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11731 for ; Mon, 10 Oct 2005 14:39:42 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP2il-0004bz-KA for syslog@ietf.org; Mon, 10 Oct 2005 14:50:02 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2005 11:39:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9AIdQ4X013399; Mon, 10 Oct 2005 11:39:28 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 11:39:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RE: [Syslog-sec] AD Reviewfordraft-ietf-syslog-protocol-14 Date: Mon, 10 Oct 2005 11:39:20 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBB98D80@xmb-sjc-236.amer.cisco.com> Thread-Topic: [Syslog] RE: [Syslog-sec] AD Reviewfordraft-ietf-syslog-protocol-14 Thread-Index: AcXJEUtAnbDgiHKCR+CHzUBPZjfdcwABMb5wASVZP8AABkq9wAABO0Jg From: "Alexander Clemm \(alex\)" To: , "Rainer Gerhards" , X-OriginalArrivalTime: 10 Oct 2005 18:39:19.0218 (UTC) FILETIME=[ECA36920:01C5CDC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I agree with David's sentiment - from my perspective, both "19406-mySDid" and "mySDid@19406" look fine.=20 Cheers --- Alex=20 -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Monday, October 10, 2005 11:12 AM To: 'Rainer Gerhards'; syslog@ietf.org Subject: RE: [Syslog] RE: [Syslog-sec] AD Reviewfordraft-ietf-syslog-protocol-14 Hi, Just for clarity, 19406 is the IANA-assigned enterprise ID for Adiscon, not an Adiscon-assigned enterprise ID. I see the space-saving difference between #1 and the alternatives, and prefer the shorter format. I also prefer the IANA-assigned identifier since we are guaranteed that will not change, or will change in very specific ways, whereas I am less convinced of the stability of domain names. I don't really see any effective difference between #2 and your proposal, so either is fine with me.=20 Unless, of course "-" is already a reserved character, and using "@" means we're reserving yet another character for no particular benefit. And if companies are already likely to use "@" in their messages for other purposes, then making this an additional reserved character would not be backwards compatible. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, October 10, 2005 11:17 AM > To: syslog@ietf.org > Subject: [Syslog] RE: [Syslog-sec] AD Review > fordraft-ietf-syslog-protocol-14 >=20 > Hi list, >=20 > I have talked offline to some collagues. Most of them share Alex (and > my) concerns on the name space designator size. However, all share the > concerns about just using x- as a prefix, thus providing no solution=20 > for namespace collisions. Given the problems we often face with namespace > collisions, I think that we should actually require strict rules. So=20 > while space is an issue, it is worth to sacrify some space (octets) to > solve the namespace issue. So we are in for namespace identifiers. >=20 > On the issue of what exactly to use, we talked about something like=20 > ssh, but with shorter identifiers. Definitely, that would introduce a=20 > syntax not yet used in other protocols, be it looks more intuitive=20 > that the > - prefix. >=20 > The suggestion is to use @. So instead of >=20 > #1 mySDID@example.example.com >=20 > or >=20 > #2 19406-mySDID >=20 > we could use >=20 > mySDID@19406 >=20 > (19406 is the Adiscon-assigend enterprise ID - is there an example ID > like the example.com domain?) >=20 > This is brief, close to SNMP and looks familiar. >=20 > Feedback is appreciated. If there are no objections to this approach,=20 > I will create some text. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Alexander > > Clemm (alex) > > Sent: Tuesday, October 04, 2005 9:10 PM > > To: Chris Lonvick (clonvick); David B Harrington > > Cc: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > >=20 > > In general, the "@example.company.com" name space is a nice idea. > > However, I am concerned about the length that this introduces. I=20 > > would much prefer to have a more compact encoding, resembling what=20 > > parameters would look like in SDP more than what they would look=20 > > like XML (in terms of compactness). This is one reason why I=20 > > actually like the proposal to use the company identifier (typically=20 > > 3 digits) as prefix > (followed by > > some delimiter) as was suggested to denote a private name space. > >=20 > > Just my 2 cents. > > --- Alex > >=20 > > -----Original Message----- > > From: syslog-sec-bounces@willers.employees.org > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chris > > Lonvick (clonvick) > > Sent: Monday, October 03, 2005 6:25 PM > > To: David B Harrington > > Cc: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > >=20 > > Hi David, > >=20 > > On Fri, 30 Sep 2005, David B Harrington wrote: > >=20 > > > Hi, > > > > > > Because I believe we should be working to integrate our network=20 > > > management standards, at least to the point they can secure and=20 > > > correlate data easily across NM interfaces, I would like > to see the > > > approach adopted by syslog to be similar to the > approaches used by > > > other IETF protocols, especially network management protocols. > >=20 > > I'd like that as well. > >=20 > > > > > > SNMP uses the vendor ID approach, managed by IANA. > > > Netconf has no data model, so we don't know what they > will use for > > > vendor extensions. > > > I'm not sure what ipfix is using. > > > > > > Who will manage the @cisco.com registrations? IANA or > > another external > >=20 > > > agency? Will the assignments be as stable as IANA assignments? > >=20 > > The "...@example.com" namespace for SSH is for private use and will=20 > > not be registered with anyone. It's been working well enough > for the SSH > > community with the warning of, "It is up to each domain how > it manages > > its local namespace." I will say that this practice in SSH > is not as > > widespread as SNMP but it has been done and it seems to be working. > >=20 > > It would be good to have discussion of this on the mailing > list and we > > can hopefully finalize what we want in Vancouver. Your > input would be > > appreciated. > >=20 > > Thanks, > > Chris > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > >=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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 10 17:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP52V-0000O8-PA; Mon, 10 Oct 2005 17:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP4vy-0007Og-BE for syslog@megatron.ietf.org; Mon, 10 Oct 2005 17:11:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25083 for ; Mon, 10 Oct 2005 17:11:43 -0400 (EDT) Received: from relay00.pair.com ([209.68.5.9] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EP55v-0001qt-Ox for syslog@ietf.org; Mon, 10 Oct 2005 17:22:05 -0400 Received: (qmail 86742 invoked from network); 10 Oct 2005 21:11:32 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 10 Oct 2005 21:11:32 -0000 X-pair-Authenticated: 222.153.94.208 From: "Andrew Ross" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] RE: [Syslog-sec] AD Review fordraft-ietf-syslog-protocol-14 Date: Tue, 11 Oct 2005 10:11:28 +1300 Organization: Kiwi Enterprises Message-ID: <001501c5cddf$2f6e0e30$d9a8a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3B93@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Oct 2005 17:18:30 -0400 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org The idea of using "mySDID@19406" sounds like a good solution to me. Regards Andrew Kiwi Enterprises -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards Sent: Tuesday, 11 October 2005 4:17 a.m. To: syslog@ietf.org Subject: [Syslog] RE: [Syslog-sec] AD Review fordraft-ietf-syslog-protocol-14 Hi list, I have talked offline to some collagues. Most of them share Alex (and my) concerns on the name space designator size. However, all share the concerns about just using x- as a prefix, thus providing no solution for namespace collisions. Given the problems we often face with namespace collisions, I think that we should actually require strict rules. So while space is an issue, it is worth to sacrify some space (octets) to solve the namespace issue. So we are in for namespace identifiers. On the issue of what exactly to use, we talked about something like ssh, but with shorter identifiers. Definitely, that would introduce a syntax not yet used in other protocols, be it looks more intuitive that the - prefix. The suggestion is to use @. So instead of #1 mySDID@example.example.com or #2 19406-mySDID we could use mySDID@19406 (19406 is the Adiscon-assigend enterprise ID - is there an example ID like the example.com domain?) This is brief, close to SNMP and looks familiar. Feedback is appreciated. If there are no objections to this approach, I will create some text. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Alexander Clemm (alex) > Sent: Tuesday, October 04, 2005 9:10 PM > To: Chris Lonvick (clonvick); David B Harrington > Cc: syslog-sec@employees.org > Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 > > In general, the "@example.company.com" name space is a nice idea. > However, I am concerned about the length that this > introduces. I would > much prefer to have a more compact encoding, resembling what > parameters > would look like in SDP more than what they would look like > XML (in terms > of compactness). This is one reason why I actually like the > proposal to > use the company identifier (typically 3 digits) as prefix (followed by > some delimiter) as was suggested to denote a private name space. > > Just my 2 cents. > --- Alex > > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chris > Lonvick (clonvick) > Sent: Monday, October 03, 2005 6:25 PM > To: David B Harrington > Cc: syslog-sec@employees.org > Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 > > Hi David, > > On Fri, 30 Sep 2005, David B Harrington wrote: > > > Hi, > > > > Because I believe we should be working to integrate our network > > management standards, at least to the point they can secure and > > correlate data easily across NM interfaces, I would like to see the > > approach adopted by syslog to be similar to the approaches used by > > other IETF protocols, especially network management protocols. > > I'd like that as well. > > > > > SNMP uses the vendor ID approach, managed by IANA. > > Netconf has no data model, so we don't know what they will use for > > vendor extensions. > > I'm not sure what ipfix is using. > > > > Who will manage the @cisco.com registrations? IANA or > another external > > > agency? Will the assignments be as stable as IANA assignments? > > The "...@example.com" namespace for SSH is for private use > and will not > be registered with anyone. It's been working well enough for the SSH > community with the warning of, "It is up to each domain how it manages > its local namespace." I will say that this practice in SSH is not as > widespread as SNMP but it has been done and it seems to be working. > > It would be good to have discussion of this on the mailing list and we > can hopefully finalize what we want in Vancouver. Your input would be > appreciated. > > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ 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 Oct 12 08:12:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPfT5-0004sv-S8; Wed, 12 Oct 2005 08:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPfT4-0004sE-Gs for syslog@megatron.ietf.org; Wed, 12 Oct 2005 08:12:22 -0400 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17371 for ; Wed, 12 Oct 2005 08:12:18 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2005 05:11:52 -0700 X-IronPort-AV: i="3.97,206,1125903600"; d="scan'208"; a="665434835:sNHT25087038" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9CCBo95024142 for ; Wed, 12 Oct 2005 05:11:50 -0700 (PDT) Date: Wed, 12 Oct 2005 05:11:50 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: [Syslog] Agenda posted X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Folks, I've posted the first proposal of an agenda. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 Are there other items of interest? ========================================================================== Security Issures in Network Event Logging WG (syslog) MONDAY, November 7, 2005 ============================ CHAIR: Chris Lonvick Scribe: Jabber-er AGENDA: I. Review of Scope and Charter (Chris) 5 min. Presentation: (rsn) II. Update of "syslog Protocol" ID (Rainer or proxy) 10 min. Presentation: (?) Document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-14.txt III. Update of "syslog-sign" ID (Jon or Alex) 15 min. Presentation: (?) Document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-16.txt IV. Discussion of "authenticity, integrity and 15 min. confidentiality of Syslog messages" RFC 3195 has been out there for a while with few implementations. isms and netconf are choosing ssh. Should this WG go along with that? V. Wrap-up and review of decisions made (Chris) 10 min. ========================================================================== Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 14 09:50:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPx8-0005gA-MQ; Fri, 14 Oct 2005 09:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPx7-0005fw-2l for syslog@megatron.ietf.org; Fri, 14 Oct 2005 09:50:29 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11067 for ; Fri, 14 Oct 2005 09:50:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 0FF8A27C02B for ; Fri, 14 Oct 2005 15:48:33 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07143-02 for ; Fri, 14 Oct 2005 15:48:32 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 72A7927C02A for ; Fri, 14 Oct 2005 15:48:32 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 15:49:46 +0200 Content-class: urn:content-classes:message Date: Fri, 14 Oct 2005 15:49:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3C21@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Unicode - was: AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcg From: "Rainer Gerhards" To: X-OriginalArrivalTime: 14 Oct 2005 13:49:46.0250 (UTC) FILETIME=[2331DEA0:01C5D0C6] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, I address the following issue Sam mentioned: > 2) You do not discuss Unicode security at all. I suggest that people > in the working group read Unicode TR 36 and also consider the > implications of the Unicode security presentation given at the > last SAAG presentation. particularly consider comments from > operators concerned about Unicode characters interacting with > existing scripts. Then write up a security considerations > section. You need to at least explain the security risks > associated with your choice to support all Unicode characters. It > would be a good idea to discuss other alternatives that were > considered and to explain why this choice was made. I have gone through the material Sam mentions. For those not already done so, the following links might be helpful. The first link is to the presentation, which very quickly provides an overview of the magnitude of the issues. http://www3.ietf.org/proceedings/05aug/slides/saag-4.pdf http://www3.ietf.org/proceedings/05aug/saag.html#cmr http://www.unicode.org/reports/tr36/ (the UTR36) In a brief (and not 100% correct) summary, there are two issues with Unicode: one is the technical aspect of using non-common encoding forms that may lead to trick an application's security check code. This is addressed in section 3.1 of UTR 36. This issue is relatively straightforward to solve in requiring applications to use the shortest possible encoding only. I have already done some text change in syslog-protocol to cover this. The second issue is more subtle: that of visual security issues (outlined in section 2 of UTR36). In short, there are visually easily confusable characters - just like l (lower case letter L) and 1 (digit 1) in many fonts. This issue is of major concern if used in identifying information. UTR36 also gives some insights into the international DNS decisions and issues with visual confusability. The bottom line is that whenever we use something as identifying information, targeted somewhere down the road towards humans, we have an issue. UTR36 defines some mechanisms to at least partly solve the confusabilty. However, in the context of syslog I consider none of them to be straightforward. If we require them in syslog-protocol, that will probably be a thing that costs us much acceptance at the implementor side. So it might be useful to think about where we have an issue at all. The MSG field, I think, does not count as identifying information. It is meant as a human-readable message. Even though it obviously carries information, I think it is not subject to an easy visual spoofing attack. Ok, one can think about scenarios where visual spoofing might cause confusion, but the severity level of this should be fairly low. I think it has the same implications as hoax mails, where misinformation in the textual part is a simple fact of life and not avoidable without stopping to use that service. So I conclude that supporting the full set of Unicode characters inside MSG is fine. The STRUCTURED-DATA is another story. Here, it includes information that might primarily be used as identifying information. Reviewing the current defined SD-IDs, I hardly see any need for using Unicode encoding. As far as I recall, we have selected Unicode instead of US-ASCII because we thought it might be benefitial for further extensions. However, given the fact of visual confusability and the need to deal with it, I am questioning if it acually is a good idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be better to use US-ASCII, which relievs us of all of these issues? So far, I do not see a compelling reason for full Unicode support in SD-IDs. Of course, we could just go ahead and document these issues in security considerations. I think, however, that we should try to solve them before resorting to that. I think we have a good chance of finding a workable solution. My suggestion to the WG is that we drop Unicode encoding for STRUCTURED-DATA and use printable US-ASCII instead. I would appreciate feedback on the following: #1 Is it OK the support Unicode - without restriction - in MSG? #2 Is there support in the WG for changing STRUCTURED-DATA encoding from Unicode to US-ASCII? If the answer to #2 is "no", please provide reasoning as that will help speed up the process. -- Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 14 11:56:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRuz-0004Yc-QE; Fri, 14 Oct 2005 11:56:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRuw-0004Xm-Uo for syslog@megatron.ietf.org; Fri, 14 Oct 2005 11:56:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25713 for ; Fri, 14 Oct 2005 11:56:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQS5h-0001kj-AK for syslog@ietf.org; Fri, 14 Oct 2005 12:07:29 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 08:56:14 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9EFu694025407; Fri, 14 Oct 2005 08:56:11 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 11:56:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Unicode - was: AD Review for draft-ietf-syslog-protocol-14 Date: Fri, 14 Oct 2005 11:56:04 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731229F2B97@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcgAAjPxeA= From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 14 Oct 2005 15:56:04.0986 (UTC) FILETIME=[C87935A0:01C5D0D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: > So it might be useful to think about where we have an issue=20 > at all. The MSG field, I think, does not count as identifying=20 > information. It is meant as a human-readable message. Even=20 > though it obviously carries information, I think it is not=20 > subject to an easy visual spoofing attack. Ok, one can think=20 > about scenarios where visual spoofing might cause confusion,=20 > but the severity level of this should be fairly low. I think=20 > it has the same implications as hoax mails, where=20 > misinformation in the textual part is a simple fact of life=20 > and not avoidable without stopping to use that service. So I=20 > conclude that supporting the full set of Unicode characters=20 > inside MSG is fine. Agree.=20 > The STRUCTURED-DATA is another story. Here, it includes=20 > information that might primarily be used as identifying=20 > information.=20 Identifying, but mostly used by software that can filter messages, which = is not susceptible to visual character confusion.=20 > Reviewing the current defined SD-IDs, I hardly=20 > see any need for using Unicode encoding. As far as I recall,=20 > we have selected Unicode instead of US-ASCII because we=20 > thought it might be benefitial for further extensions.=20 > However, given the fact of visual confusability and the need=20 > to deal with it, I am questioning if it acually is a good=20 > idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be=20 > better to use US-ASCII, which relievs us of all of these=20 > issues? So far, I do not see a compelling reason for full=20 > Unicode support in SD-IDs. With all due respect, I strongly disagree. Structured data may include = anything. It is just structured. It can contain same pieces of = information that may be found in the message. =20 We have a very specific use-case where a structured element is a = username. And that username can be in Japanese. I can see many other = use-cases like this. Being from Germany, I am sure you can easily come = with some too. :) How about any company name in a foreign language? = Address? English is not an exclusive language of system administration = anymore. =20 > Of course, we could just go ahead and document these issues=20 > in security considerations. I think, however, that we should=20 > try to solve them before resorting to that. I think we have a=20 > good chance of finding a workable solution. >=20 > My suggestion to the WG is that we drop Unicode encoding for=20 > STRUCTURED-DATA and use printable US-ASCII instead. >=20 > I would appreciate feedback on the following: >=20 > #1 Is it OK the support Unicode - without restriction - in MSG? Well, the restriction is that we require use of the most compact = encoding as you mentioned.=20 > #2 Is there support in the WG for changing STRUCTURED-DATA encoding > from Unicode to US-ASCII? Not from me. :) In fact, I think it is very critical to support = non-ASCII in structured data.=20 Thanks, Anton.=20 >=20 > If the answer to #2 is "no", please provide reasoning as that=20 > will help speed up the process. >=20 > -- > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 14 12:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSH1-0000X9-In; Fri, 14 Oct 2005 12:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSH0-0000WZ-32 for syslog@megatron.ietf.org; Fri, 14 Oct 2005 12:19:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27588 for ; Fri, 14 Oct 2005 12:19:05 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSRk-0002bT-EM for syslog@ietf.org; Fri, 14 Oct 2005 12:30:16 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2005 09:19:01 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="666243678:sNHT50576014" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9EGInJp012636; Fri, 14 Oct 2005 09:18:58 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:18:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Date: Fri, 14 Oct 2005 09:18:43 -0700 Message-ID: Thread-Topic: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcgAAjPxeAAAMUhwA== From: "Steve Chang \(schang99\)" To: "Anton Okmianski \(aokmians\)" , "Rainer Gerhards" , X-OriginalArrivalTime: 14 Oct 2005 16:18:45.0498 (UTC) FILETIME=[F366DDA0:01C5D0DA] X-Spam-Score: 0.9 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Just a thought. For this argument, to keep most people happy, it seems logical to expand the HEADER section with 2 more fields which are still US-ASCII. One is SD-encoding-type (1 byte) followed by anther one=20 MSG-encoding-type (1 byte). With these 2 1-DIGIT fields, everyone can have their own way. The receiving end should have not problem decoding it. It saves arguments and it allows code reuse in practice. Steve > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Anton Okmianski (aokmians) > Sent: Friday, October 14, 2005 8:56 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog- > protocol-14 >=20 > Rainer: >=20 > > So it might be useful to think about where we have an issue > > at all. The MSG field, I think, does not count as identifying > > information. It is meant as a human-readable message. Even > > though it obviously carries information, I think it is not > > subject to an easy visual spoofing attack. Ok, one can think > > about scenarios where visual spoofing might cause confusion, > > but the severity level of this should be fairly low. I think > > it has the same implications as hoax mails, where > > misinformation in the textual part is a simple fact of life > > and not avoidable without stopping to use that service. So I > > conclude that supporting the full set of Unicode characters > > inside MSG is fine. >=20 > Agree. >=20 > > The STRUCTURED-DATA is another story. Here, it includes > > information that might primarily be used as identifying > > information. >=20 > Identifying, but mostly used by software that can filter messages, which > is not susceptible to visual character confusion. >=20 > > Reviewing the current defined SD-IDs, I hardly > > see any need for using Unicode encoding. As far as I recall, > > we have selected Unicode instead of US-ASCII because we > > thought it might be benefitial for further extensions. > > However, given the fact of visual confusability and the need > > to deal with it, I am questioning if it acually is a good > > idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be > > better to use US-ASCII, which relievs us of all of these > > issues? So far, I do not see a compelling reason for full > > Unicode support in SD-IDs. >=20 > With all due respect, I strongly disagree. Structured data may include > anything. It is just structured. It can contain same pieces of information > that may be found in the message. >=20 > We have a very specific use-case where a structured element is a username. > And that username can be in Japanese. I can see many other use-cases like > this. Being from Germany, I am sure you can easily come with some too. :) > How about any company name in a foreign language? Address? English is > not an exclusive language of system administration anymore. >=20 > > Of course, we could just go ahead and document these issues > > in security considerations. I think, however, that we should > > try to solve them before resorting to that. I think we have a > > good chance of finding a workable solution. > > > > My suggestion to the WG is that we drop Unicode encoding for > > STRUCTURED-DATA and use printable US-ASCII instead. > > > > I would appreciate feedback on the following: > > > > #1 Is it OK the support Unicode - without restriction - in MSG? >=20 > Well, the restriction is that we require use of the most compact encoding > as you mentioned. >=20 > > #2 Is there support in the WG for changing STRUCTURED-DATA encoding > > from Unicode to US-ASCII? >=20 > Not from me. :) In fact, I think it is very critical to support non-ASCII > in structured data. >=20 > Thanks, > Anton. >=20 > > > > If the answer to #2 is "no", please provide reasoning as that > > will help speed up the process. > > > > -- > > Rainer > > > > _______________________________________________ > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 14 12:24:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSMC-0001yG-J3; Fri, 14 Oct 2005 12:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSMA-0001y6-V1 for syslog@megatron.ietf.org; Fri, 14 Oct 2005 12:24:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27971 for ; Fri, 14 Oct 2005 12:24:26 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSWv-0002lu-As for syslog@ietf.org; Fri, 14 Oct 2005 12:35:37 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2005 09:24:21 -0700 X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="666246509:sNHT28104560" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9EGNVvB012517; Fri, 14 Oct 2005 09:24:19 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 12:24:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Date: Fri, 14 Oct 2005 12:24:07 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731229F2BCA@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcgAAjPxeAAAMUhwAAAhBlg From: "Anton Okmianski \(aokmians\)" To: "Steve Chang \(schang99\)" , "Rainer Gerhards" , X-OriginalArrivalTime: 14 Oct 2005 16:24:08.0465 (UTC) FILETIME=[B3E7B810:01C5D0DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org And the receiver has to support both? A MUST? Generally, the more options, the harder is the interop.=20 Anton. =20 > -----Original Message----- > From: Steve Chang (schang99)=20 > Sent: Friday, October 14, 2005 12:19 PM > To: Anton Okmianski (aokmians); Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Unicode - was: AD Review=20 > fordraft-ietf-syslog-protocol-14 >=20 > Hi, >=20 > Just a thought. >=20 > For this argument, to keep most people happy, it seems=20 > logical to expand the HEADER section with 2 more fields which=20 > are still US-ASCII. >=20 > One is SD-encoding-type (1 byte) followed by anther one=20 > MSG-encoding-type (1 byte). >=20 > With these 2 1-DIGIT fields, everyone can have their own way. > The receiving end should have not problem decoding it. > It saves arguments and it allows code reuse in practice. >=20 >=20 > Steve >=20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] > > On Behalf Of Anton Okmianski (aokmians) > > Sent: Friday, October 14, 2005 8:56 AM > > To: Rainer Gerhards; syslog@ietf.org > > Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog- > > protocol-14 > >=20 > > Rainer: > >=20 > > > So it might be useful to think about where we have an=20 > issue at all.=20 > > > The MSG field, I think, does not count as identifying=20 > information.=20 > > > It is meant as a human-readable message. Even though it obviously=20 > > > carries information, I think it is not subject to an easy visual=20 > > > spoofing attack. Ok, one can think about scenarios where visual=20 > > > spoofing might cause confusion, but the severity level of this=20 > > > should be fairly low. I think it has the same=20 > implications as hoax=20 > > > mails, where misinformation in the textual part is a=20 > simple fact of=20 > > > life and not avoidable without stopping to use that service. So I=20 > > > conclude that supporting the full set of Unicode=20 > characters inside=20 > > > MSG is fine. > >=20 > > Agree. > >=20 > > > The STRUCTURED-DATA is another story. Here, it includes=20 > information=20 > > > that might primarily be used as identifying information. > >=20 > > Identifying, but mostly used by software that can filter messages,=20 > > which is not susceptible to visual character confusion. > >=20 > > > Reviewing the current defined SD-IDs, I hardly see any need for=20 > > > using Unicode encoding. As far as I recall, we have=20 > selected Unicode=20 > > > instead of US-ASCII because we thought it might be benefitial for=20 > > > further extensions. > > > However, given the fact of visual confusability and the=20 > need to deal=20 > > > with it, I am questioning if it acually is a good idea to encode=20 > > > STRUCTURED-DATA in Unicode. Wouldn't it be better to use=20 > US-ASCII,=20 > > > which relievs us of all of these issues? So far, I do not see a=20 > > > compelling reason for full Unicode support in SD-IDs. > >=20 > > With all due respect, I strongly disagree. Structured data=20 > may include=20 > > anything. It is just structured. It can contain same pieces of=20 > > information that may be found in the message. > >=20 > > We have a very specific use-case where a structured element=20 > is a username. > > And that username can be in Japanese. I can see many other=20 > use-cases=20 > > like this. Being from Germany, I am sure you can easily come with=20 > > some too. :) How about any company name in a foreign language? =20 > > Address? English is not an exclusive language of system=20 > administration anymore. > >=20 > > > Of course, we could just go ahead and document these issues in=20 > > > security considerations. I think, however, that we should try to=20 > > > solve them before resorting to that. I think we have a=20 > good chance=20 > > > of finding a workable solution. > > > > > > My suggestion to the WG is that we drop Unicode encoding for=20 > > > STRUCTURED-DATA and use printable US-ASCII instead. > > > > > > I would appreciate feedback on the following: > > > > > > #1 Is it OK the support Unicode - without restriction - in MSG? > >=20 > > Well, the restriction is that we require use of the most compact=20 > > encoding as you mentioned. > >=20 > > > #2 Is there support in the WG for changing=20 > STRUCTURED-DATA encoding > > > from Unicode to US-ASCII? > >=20 > > Not from me. :) In fact, I think it is very critical to support=20 > > non-ASCII in structured data. > >=20 > > Thanks, > > Anton. > >=20 > > > > > > If the answer to #2 is "no", please provide reasoning as=20 > that will=20 > > > help speed up the process. > > > > > > -- > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 14 12:37:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSYW-0007UT-Vj; Fri, 14 Oct 2005 12:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSYV-0007UO-Sb for syslog@megatron.ietf.org; Fri, 14 Oct 2005 12:37:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28623 for ; Fri, 14 Oct 2005 12:37:11 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSjG-000369-D1 for syslog@ietf.org; Fri, 14 Oct 2005 12:48:23 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Oct 2005 09:37:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9EGanVC021793; Fri, 14 Oct 2005 09:37:04 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:37:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Date: Fri, 14 Oct 2005 09:37:01 -0700 Message-ID: Thread-Topic: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcgAAjPxeAAAMUhwAAAhBlgAAAYYkA= From: "Steve Chang \(schang99\)" To: "Anton Okmianski \(aokmians\)" , "Rainer Gerhards" , X-OriginalArrivalTime: 14 Oct 2005 16:37:02.0968 (UTC) FILETIME=[818B7F80:01C5D0DD] X-Spam-Score: 0.9 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Yes. I would think these 2 new fields have to be MUST fields. In reality, the receiver is already required by this new protocol=20 to be bilingual to handle both US-ASCII and UNICODE. =20 As a developer, I do not see difficulty in decoding the 2 encoding=20 types up front and then apply the indicated decoding scheme to=20 SD and MSG part of message. It's a small price to pay as compared to hardcode this new protocol with only one encoding type (you lose flexibility this way.) Facing no win-win situation, I naturally choose the least cost option. Steve > -----Original Message----- > From: Anton Okmianski (aokmians) > Sent: Friday, October 14, 2005 9:24 AM > To: Steve Chang (schang99); 'Rainer Gerhards'; 'syslog@ietf.org' > Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog- > protocol-14 >=20 > And the receiver has to support both? A MUST? >=20 > Generally, the more options, the harder is the interop. >=20 > Anton. >=20 > > -----Original Message----- > > From: Steve Chang (schang99) > > Sent: Friday, October 14, 2005 12:19 PM > > To: Anton Okmianski (aokmians); Rainer Gerhards; syslog@ietf.org > > Subject: RE: [Syslog] Unicode - was: AD Review > > fordraft-ietf-syslog-protocol-14 > > > > Hi, > > > > Just a thought. > > > > For this argument, to keep most people happy, it seems > > logical to expand the HEADER section with 2 more fields which > > are still US-ASCII. > > > > One is SD-encoding-type (1 byte) followed by anther one > > MSG-encoding-type (1 byte). > > > > With these 2 1-DIGIT fields, everyone can have their own way. > > The receiving end should have not problem decoding it. > > It saves arguments and it allows code reuse in practice. > > > > > > Steve > > > > > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] > > > On Behalf Of Anton Okmianski (aokmians) > > > Sent: Friday, October 14, 2005 8:56 AM > > > To: Rainer Gerhards; syslog@ietf.org > > > Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog- > > > protocol-14 > > > > > > Rainer: > > > > > > > So it might be useful to think about where we have an > > issue at all. > > > > The MSG field, I think, does not count as identifying > > information. > > > > It is meant as a human-readable message. Even though it obviously > > > > carries information, I think it is not subject to an easy visual > > > > spoofing attack. Ok, one can think about scenarios where visual > > > > spoofing might cause confusion, but the severity level of this > > > > should be fairly low. I think it has the same > > implications as hoax > > > > mails, where misinformation in the textual part is a > > simple fact of > > > > life and not avoidable without stopping to use that service. So I > > > > conclude that supporting the full set of Unicode > > characters inside > > > > MSG is fine. > > > > > > Agree. > > > > > > > The STRUCTURED-DATA is another story. Here, it includes > > information > > > > that might primarily be used as identifying information. > > > > > > Identifying, but mostly used by software that can filter messages, > > > which is not susceptible to visual character confusion. > > > > > > > Reviewing the current defined SD-IDs, I hardly see any need for > > > > using Unicode encoding. As far as I recall, we have > > selected Unicode > > > > instead of US-ASCII because we thought it might be benefitial for > > > > further extensions. > > > > However, given the fact of visual confusability and the > > need to deal > > > > with it, I am questioning if it acually is a good idea to encode > > > > STRUCTURED-DATA in Unicode. Wouldn't it be better to use > > US-ASCII, > > > > which relievs us of all of these issues? So far, I do not see a > > > > compelling reason for full Unicode support in SD-IDs. > > > > > > With all due respect, I strongly disagree. Structured data > > may include > > > anything. It is just structured. It can contain same pieces of > > > information that may be found in the message. > > > > > > We have a very specific use-case where a structured element > > is a username. > > > And that username can be in Japanese. I can see many other > > use-cases > > > like this. Being from Germany, I am sure you can easily come with > > > some too. :) How about any company name in a foreign language? > > > Address? English is not an exclusive language of system > > administration anymore. > > > > > > > Of course, we could just go ahead and document these issues in > > > > security considerations. I think, however, that we should try to > > > > solve them before resorting to that. I think we have a > > good chance > > > > of finding a workable solution. > > > > > > > > My suggestion to the WG is that we drop Unicode encoding for > > > > STRUCTURED-DATA and use printable US-ASCII instead. > > > > > > > > I would appreciate feedback on the following: > > > > > > > > #1 Is it OK the support Unicode - without restriction - in MSG? > > > > > > Well, the restriction is that we require use of the most compact > > > encoding as you mentioned. > > > > > > > #2 Is there support in the WG for changing > > STRUCTURED-DATA encoding > > > > from Unicode to US-ASCII? > > > > > > Not from me. :) In fact, I think it is very critical to support > > > non-ASCII in structured data. > > > > > > Thanks, > > > Anton. > > > > > > > > > > > If the answer to #2 is "no", please provide reasoning as > > that will > > > > help speed up the process. > > > > > > > > -- > > > > Rainer > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 14 12:51:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSmH-00030c-FW; Fri, 14 Oct 2005 12:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSmB-00030E-MZ for syslog@megatron.ietf.org; Fri, 14 Oct 2005 12:51:27 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00110 for ; Fri, 14 Oct 2005 12:51:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id ED04A27C02B for ; Fri, 14 Oct 2005 18:49:36 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10671-09 for ; Fri, 14 Oct 2005 18:49:36 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 714B127C02A for ; Fri, 14 Oct 2005 18:49:36 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 18:50:46 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 MIME-Version: 1.0 Date: Fri, 14 Oct 2005 18:50:46 +0200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3C27@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcgAAjPxeAAAMUhwAAAhBlgAAAYYkAAAMAhIA== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 14 Oct 2005 16:50:46.0918 (UTC) FILETIME=[6CA84A60:01C5D0DF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Steve, here, I agree with Anton. The reason is that this calls for both encodings, but that will not save us the hassles with Unicode. Please keep in mind > In reality, the receiver is already required by this new protocol=20 > to be bilingual to handle both US-ASCII and UNICODE. =20 That is not fully true. US-ASCII is a subset of UNICODE, so there is no need to detect US-ASCII at all - it inherently is there with UNICODE. > As a developer, I do not see difficulty in decoding the 2 encoding=20 > types up front and then apply the indicated decoding scheme to=20 > SD and MSG part of message. That does not solve the issues with Unicode visual spoofing. Rainer PS: I need to leave now, will reply to Anton's initial comment later... >=20 > It's a small price to pay as compared to hardcode this new protocol > with only one encoding type (you lose flexibility this way.) > Facing no win-win situation, I naturally choose the least cost option. >=20 >=20 > Steve >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) > > Sent: Friday, October 14, 2005 9:24 AM > > To: Steve Chang (schang99); 'Rainer Gerhards'; 'syslog@ietf.org' > > Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog- > > protocol-14 > >=20 > > And the receiver has to support both? A MUST? > >=20 > > Generally, the more options, the harder is the interop. > >=20 > > Anton. > >=20 > > > -----Original Message----- > > > From: Steve Chang (schang99) > > > Sent: Friday, October 14, 2005 12:19 PM > > > To: Anton Okmianski (aokmians); Rainer Gerhards; syslog@ietf.org > > > Subject: RE: [Syslog] Unicode - was: AD Review > > > fordraft-ietf-syslog-protocol-14 > > > > > > Hi, > > > > > > Just a thought. > > > > > > For this argument, to keep most people happy, it seems > > > logical to expand the HEADER section with 2 more fields which > > > are still US-ASCII. > > > > > > One is SD-encoding-type (1 byte) followed by anther one > > > MSG-encoding-type (1 byte). > > > > > > With these 2 1-DIGIT fields, everyone can have their own way. > > > The receiving end should have not problem decoding it. > > > It saves arguments and it allows code reuse in practice. > > > > > > > > > Steve > > > > > > > > > > -----Original Message----- > > > > From: syslog-bounces@lists.ietf.org > > > > [mailto:syslog-bounces@lists.ietf.org] > > > > On Behalf Of Anton Okmianski (aokmians) > > > > Sent: Friday, October 14, 2005 8:56 AM > > > > To: Rainer Gerhards; syslog@ietf.org > > > > Subject: RE: [Syslog] Unicode - was: AD Review > fordraft-ietf-syslog- > > > > protocol-14 > > > > > > > > Rainer: > > > > > > > > > So it might be useful to think about where we have an > > > issue at all. > > > > > The MSG field, I think, does not count as identifying > > > information. > > > > > It is meant as a human-readable message. Even though it > obviously > > > > > carries information, I think it is not subject to an=20 > easy visual > > > > > spoofing attack. Ok, one can think about scenarios=20 > where visual > > > > > spoofing might cause confusion, but the severity level of this > > > > > should be fairly low. I think it has the same > > > implications as hoax > > > > > mails, where misinformation in the textual part is a > > > simple fact of > > > > > life and not avoidable without stopping to use that=20 > service. So > I > > > > > conclude that supporting the full set of Unicode > > > characters inside > > > > > MSG is fine. > > > > > > > > Agree. > > > > > > > > > The STRUCTURED-DATA is another story. Here, it includes > > > information > > > > > that might primarily be used as identifying information. > > > > > > > > Identifying, but mostly used by software that can=20 > filter messages, > > > > which is not susceptible to visual character confusion. > > > > > > > > > Reviewing the current defined SD-IDs, I hardly see=20 > any need for > > > > > using Unicode encoding. As far as I recall, we have > > > selected Unicode > > > > > instead of US-ASCII because we thought it might be benefitial > for > > > > > further extensions. > > > > > However, given the fact of visual confusability and the > > > need to deal > > > > > with it, I am questioning if it acually is a good=20 > idea to encode > > > > > STRUCTURED-DATA in Unicode. Wouldn't it be better to use > > > US-ASCII, > > > > > which relievs us of all of these issues? So far, I do=20 > not see a > > > > > compelling reason for full Unicode support in SD-IDs. > > > > > > > > With all due respect, I strongly disagree. Structured data > > > may include > > > > anything. It is just structured. It can contain same pieces of > > > > information that may be found in the message. > > > > > > > > We have a very specific use-case where a structured element > > > is a username. > > > > And that username can be in Japanese. I can see many other > > > use-cases > > > > like this. Being from Germany, I am sure you can=20 > easily come with > > > > some too. :) How about any company name in a foreign language? > > > > Address? English is not an exclusive language of system > > > administration anymore. > > > > > > > > > Of course, we could just go ahead and document these issues in > > > > > security considerations. I think, however, that we=20 > should try to > > > > > solve them before resorting to that. I think we have a > > > good chance > > > > > of finding a workable solution. > > > > > > > > > > My suggestion to the WG is that we drop Unicode encoding for > > > > > STRUCTURED-DATA and use printable US-ASCII instead. > > > > > > > > > > I would appreciate feedback on the following: > > > > > > > > > > #1 Is it OK the support Unicode - without restriction=20 > - in MSG? > > > > > > > > Well, the restriction is that we require use of the most compact > > > > encoding as you mentioned. > > > > > > > > > #2 Is there support in the WG for changing > > > STRUCTURED-DATA encoding > > > > > from Unicode to US-ASCII? > > > > > > > > Not from me. :) In fact, I think it is very critical to support > > > > non-ASCII in structured data. > > > > > > > > Thanks, > > > > Anton. > > > > > > > > > > > > > > If the answer to #2 is "no", please provide reasoning as > > > that will > > > > > help speed up the process. > > > > > > > > > > -- > > > > > Rainer > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 14 12:59:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSto-0008Pl-B6; Fri, 14 Oct 2005 12:59:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQStl-0008Of-Pm for syslog@megatron.ietf.org; Fri, 14 Oct 2005 12:59:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00522 for ; Fri, 14 Oct 2005 12:59:09 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQT4U-0003wT-Fm for syslog@ietf.org; Fri, 14 Oct 2005 13:10:21 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 09:59:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9EGwnul004299; Fri, 14 Oct 2005 09:59:00 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:58:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Date: Fri, 14 Oct 2005 09:58:57 -0700 Message-ID: Thread-Topic: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcgAAjPxeAAAMUhwAAAhBlgAAAYYkAAAMAhIAAAYQYw From: "Steve Chang \(schang99\)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 14 Oct 2005 16:58:59.0686 (UTC) FILETIME=[925EB860:01C5D0E0] X-Spam-Score: 0.9 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Thanks for the clarifications. I agree with your view now. Steve > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Friday, October 14, 2005 9:51 AM > To: syslog@ietf.org > Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog- > protocol-14 >=20 > Steve, >=20 > here, I agree with Anton. The reason is that this calls for both > encodings, but that will not save us the hassles with Unicode. >=20 > Please keep in mind >=20 > > In reality, the receiver is already required by this new protocol > > to be bilingual to handle both US-ASCII and UNICODE. >=20 > That is not fully true. US-ASCII is a subset of UNICODE, so there is no > need to detect US-ASCII at all - it inherently is there with UNICODE. >=20 > > As a developer, I do not see difficulty in decoding the 2 encoding > > types up front and then apply the indicated decoding scheme to > > SD and MSG part of message. >=20 > That does not solve the issues with Unicode visual spoofing. >=20 > Rainer > PS: I need to leave now, will reply to Anton's initial comment later... >=20 > > > > It's a small price to pay as compared to hardcode this new protocol > > with only one encoding type (you lose flexibility this way.) > > Facing no win-win situation, I naturally choose the least cost option. > > > > > > Steve > > > > > -----Original Message----- > > > From: Anton Okmianski (aokmians) > > > Sent: Friday, October 14, 2005 9:24 AM > > > To: Steve Chang (schang99); 'Rainer Gerhards'; 'syslog@ietf.org' > > > Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog- > > > protocol-14 > > > > > > And the receiver has to support both? A MUST? > > > > > > Generally, the more options, the harder is the interop. > > > > > > Anton. > > > > > > > -----Original Message----- > > > > From: Steve Chang (schang99) > > > > Sent: Friday, October 14, 2005 12:19 PM > > > > To: Anton Okmianski (aokmians); Rainer Gerhards; syslog@ietf.org > > > > Subject: RE: [Syslog] Unicode - was: AD Review > > > > fordraft-ietf-syslog-protocol-14 > > > > > > > > Hi, > > > > > > > > Just a thought. > > > > > > > > For this argument, to keep most people happy, it seems > > > > logical to expand the HEADER section with 2 more fields which > > > > are still US-ASCII. > > > > > > > > One is SD-encoding-type (1 byte) followed by anther one > > > > MSG-encoding-type (1 byte). > > > > > > > > With these 2 1-DIGIT fields, everyone can have their own way. > > > > The receiving end should have not problem decoding it. > > > > It saves arguments and it allows code reuse in practice. > > > > > > > > > > > > Steve > > > > > > > > > > > > > -----Original Message----- > > > > > From: syslog-bounces@lists.ietf.org > > > > > [mailto:syslog-bounces@lists.ietf.org] > > > > > On Behalf Of Anton Okmianski (aokmians) > > > > > Sent: Friday, October 14, 2005 8:56 AM > > > > > To: Rainer Gerhards; syslog@ietf.org > > > > > Subject: RE: [Syslog] Unicode - was: AD Review > > fordraft-ietf-syslog- > > > > > protocol-14 > > > > > > > > > > Rainer: > > > > > > > > > > > So it might be useful to think about where we have an > > > > issue at all. > > > > > > The MSG field, I think, does not count as identifying > > > > information. > > > > > > It is meant as a human-readable message. Even though it > > obviously > > > > > > carries information, I think it is not subject to an > > easy visual > > > > > > spoofing attack. Ok, one can think about scenarios > > where visual > > > > > > spoofing might cause confusion, but the severity level of this > > > > > > should be fairly low. I think it has the same > > > > implications as hoax > > > > > > mails, where misinformation in the textual part is a > > > > simple fact of > > > > > > life and not avoidable without stopping to use that > > service. So > > I > > > > > > conclude that supporting the full set of Unicode > > > > characters inside > > > > > > MSG is fine. > > > > > > > > > > Agree. > > > > > > > > > > > The STRUCTURED-DATA is another story. Here, it includes > > > > information > > > > > > that might primarily be used as identifying information. > > > > > > > > > > Identifying, but mostly used by software that can > > filter messages, > > > > > which is not susceptible to visual character confusion. > > > > > > > > > > > Reviewing the current defined SD-IDs, I hardly see > > any need for > > > > > > using Unicode encoding. As far as I recall, we have > > > > selected Unicode > > > > > > instead of US-ASCII because we thought it might be benefitial > > for > > > > > > further extensions. > > > > > > However, given the fact of visual confusability and the > > > > need to deal > > > > > > with it, I am questioning if it acually is a good > > idea to encode > > > > > > STRUCTURED-DATA in Unicode. Wouldn't it be better to use > > > > US-ASCII, > > > > > > which relievs us of all of these issues? So far, I do > > not see a > > > > > > compelling reason for full Unicode support in SD-IDs. > > > > > > > > > > With all due respect, I strongly disagree. Structured data > > > > may include > > > > > anything. It is just structured. It can contain same pieces of > > > > > information that may be found in the message. > > > > > > > > > > We have a very specific use-case where a structured element > > > > is a username. > > > > > And that username can be in Japanese. I can see many other > > > > use-cases > > > > > like this. Being from Germany, I am sure you can > > easily come with > > > > > some too. :) How about any company name in a foreign language? > > > > > Address? English is not an exclusive language of system > > > > administration anymore. > > > > > > > > > > > Of course, we could just go ahead and document these issues in > > > > > > security considerations. I think, however, that we > > should try to > > > > > > solve them before resorting to that. I think we have a > > > > good chance > > > > > > of finding a workable solution. > > > > > > > > > > > > My suggestion to the WG is that we drop Unicode encoding for > > > > > > STRUCTURED-DATA and use printable US-ASCII instead. > > > > > > > > > > > > I would appreciate feedback on the following: > > > > > > > > > > > > #1 Is it OK the support Unicode - without restriction > > - in MSG? > > > > > > > > > > Well, the restriction is that we require use of the most compact > > > > > encoding as you mentioned. > > > > > > > > > > > #2 Is there support in the WG for changing > > > > STRUCTURED-DATA encoding > > > > > > from Unicode to US-ASCII? > > > > > > > > > > Not from me. :) In fact, I think it is very critical to support > > > > > non-ASCII in structured data. > > > > > > > > > > Thanks, > > > > > Anton. > > > > > > > > > > > > > > > > > If the answer to #2 is "no", please provide reasoning as > > > > that will > > > > > > help speed up the process. > > > > > > > > > > > > -- > > > > > > Rainer > > > > > > > > > > > > _______________________________________________ > > > > > > Syslog mailing list > > > > > > Syslog@lists.ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 17 06:20:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERS6Z-00024M-K6; Mon, 17 Oct 2005 06:20:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERS6W-00024H-88 for syslog@megatron.ietf.org; Mon, 17 Oct 2005 06:20:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01729 for ; Mon, 17 Oct 2005 06:20:20 -0400 (EDT) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERSHI-0000RA-Ie for syslog@ietf.org; Mon, 17 Oct 2005 06:32:09 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id CE74927C02C; Mon, 17 Oct 2005 12:18:00 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05827-06; Mon, 17 Oct 2005 12:18:00 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id A470C27C02A; Mon, 17 Oct 2005 12:17:59 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 12:19:22 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2005 12:19:17 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3C34@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQTmaGcgAAjPxeAAimmNYA== From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , X-OriginalArrivalTime: 17 Oct 2005 10:19:22.0679 (UTC) FILETIME=[3E330C70:01C5D304] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton: thanks for your reply. I agree that structured data can contain (and = probably does in a real use case) data that is also present in the MSG = part. As of this, there is need to support Unicode there, too. As you = outline, STRUCTURED-DATA is mostly machine-processed. I do not fully = agree that it won't be interpreted by a human, so there eventually is = some hit by visual spoofing. This is acceptable as the security concerns = are outweighted by the required functionality. However, there might still be one thing that we could consider to do: = STRUCTURED-DATA consists of SD-IDs, PARAM-NAMEs and PARAM-VALUEs. Your = argument definitely shows that PARAM-VALUEs must support Unicode. But is = it true for the other two entities, too? Will we loose required = functionality for the international community if we restrict either = SD-ID, PARAM-NAME or both to US-ASCII? If the answer is "no", then we = can probably restrict some entities. I know that local characters in = these identifiers might be helpful. But is it really something we MUST = have? Let me use an example. In Germany, "M=FCller" (containing u with Umlaut = - =FC) is a common name. As such, a user name "M=FCller" is something we = can have. Now, if I encode this in (hypothetical) STRUCTRED-DATA, I may = end up with something like USER=3D"M=FCller" [PARAM-NAME =3D PARAM-VALUE] The "USER=3D" part should be locale- and language-ignorant - at least in = my point of view. So it is probably not a good idea that a German = implementation would encode it as BENUTZER=3D"M=FCller" ["Benutzer" is German for "User"] While the extension-mechanism for vendor- and experimental extensions = does not specify any details, it probably is a good idea to use English = language tags in order to facilitate interpretation of the tags (and = universal) adoption. The extension mechanism should not be used as a = translation tool. (Maybe this is also something we should point out in = syslog-protocol). But if we intend to facilitate universal adoption of = tags, we can probably require them to be English names. And in such a = case, US-ASCII would be sufficient. Please do not misunderstand me. I am not suggesting that using local = language is a bad thing per se. I also do not think of the use of = English in this context as the use of the local language of e.g. the US = and the British. I am thinking about the use of English as the language = of IT, the language that - at least currently - lays the foundation for = international collaboration (and as such conceptually should not be tied = to some nations). The fact that I am from a non-native English speaking = country might proove my point a little. My concern is that if we encourage implementors to create = language-specific tag names, interoperability might become a much bigger = problem than when we stick with a single, universal (in this context!) = language. I currently do not see any samples where local-language tag = names will actually be required. Maybe I am overlooking the obvious. = Maybe English is not sufficiently enough considered to be the "univesal = language of IT", so that local policies might require tag names to be in = local language. But at the same time, would this not also mean that we = would need to support not a single, universal, timestamp but rather a = wealth of different local formats? Any feedback is deeply appreciated. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Friday, October 14, 2005 5:56 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Unicode - was: AD Review for=20 > draft-ietf-syslog-protocol-14 >=20 > Rainer: >=20 > > So it might be useful to think about where we have an issue=20 > > at all. The MSG field, I think, does not count as identifying=20 > > information. It is meant as a human-readable message. Even=20 > > though it obviously carries information, I think it is not=20 > > subject to an easy visual spoofing attack. Ok, one can think=20 > > about scenarios where visual spoofing might cause confusion,=20 > > but the severity level of this should be fairly low. I think=20 > > it has the same implications as hoax mails, where=20 > > misinformation in the textual part is a simple fact of life=20 > > and not avoidable without stopping to use that service. So I=20 > > conclude that supporting the full set of Unicode characters=20 > > inside MSG is fine. >=20 > Agree.=20 >=20 > > The STRUCTURED-DATA is another story. Here, it includes=20 > > information that might primarily be used as identifying=20 > > information.=20 >=20 > Identifying, but mostly used by software that can filter=20 > messages, which is not susceptible to visual character confusion.=20 >=20 > > Reviewing the current defined SD-IDs, I hardly=20 > > see any need for using Unicode encoding. As far as I recall,=20 > > we have selected Unicode instead of US-ASCII because we=20 > > thought it might be benefitial for further extensions.=20 > > However, given the fact of visual confusability and the need=20 > > to deal with it, I am questioning if it acually is a good=20 > > idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be=20 > > better to use US-ASCII, which relievs us of all of these=20 > > issues? So far, I do not see a compelling reason for full=20 > > Unicode support in SD-IDs. >=20 > With all due respect, I strongly disagree. Structured data=20 > may include anything. It is just structured. It can contain=20 > same pieces of information that may be found in the message. =20 >=20 > We have a very specific use-case where a structured element=20 > is a username. And that username can be in Japanese. I can=20 > see many other use-cases like this. Being from Germany, I am=20 > sure you can easily come with some too. :) How about any=20 > company name in a foreign language? Address? English is not=20 > an exclusive language of system administration anymore. =20 >=20 > > Of course, we could just go ahead and document these issues=20 > > in security considerations. I think, however, that we should=20 > > try to solve them before resorting to that. I think we have a=20 > > good chance of finding a workable solution. > >=20 > > My suggestion to the WG is that we drop Unicode encoding for=20 > > STRUCTURED-DATA and use printable US-ASCII instead. > >=20 > > I would appreciate feedback on the following: > >=20 > > #1 Is it OK the support Unicode - without restriction - in MSG? >=20 > Well, the restriction is that we require use of the most=20 > compact encoding as you mentioned.=20 >=20 > > #2 Is there support in the WG for changing STRUCTURED-DATA encoding > > from Unicode to US-ASCII? >=20 > Not from me. :) In fact, I think it is very critical to=20 > support non-ASCII in structured data.=20 >=20 > Thanks, > Anton.=20 >=20 > >=20 > > If the answer to #2 is "no", please provide reasoning as that=20 > > will help speed up the process. > >=20 > > -- > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 17 07:35:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERTGw-0005dL-30; Mon, 17 Oct 2005 07:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERTGu-0005cl-7B for syslog@megatron.ietf.org; Mon, 17 Oct 2005 07:35:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05336 for ; Mon, 17 Oct 2005 07:35:07 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERTSD-0002QX-RF for syslog@ietf.org; Mon, 17 Oct 2005 07:46:58 -0400 Received: from pc6 (1Cust127.tnt2.lnd4.gbr.da.uu.net [62.188.131.127]) by ranger.systems.pipex.net (Postfix) with SMTP id D6BB5E000281; Mon, 17 Oct 2005 12:34:51 +0100 (BST) Message-ID: <031801c5d306$47f796c0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA0E3C21@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14 Date: Mon, 17 Oct 2005 11:27:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think Unicode is a must, even if it then means we have other problems to solve. US-ASCII is fine for the northern part of that small island that sits between the Pacific and Atlantic oceans but not for the most of the world:-). This is more political than technical but I do take the actions of UN/WSIS/ITU seriously and do not want to give them ammunition to take control of technology away from the engineers of the IETF and into the bureaucracy of some other body (think OSI). So we must cater for the majority of the world (even if there is little sign of calls for i18n on this particular list) and take Unicode on board. Ambiguity? Yes I have lived with the confusion of 0/O 1/I/| 2/Z 5/S for decades and see it as primarily the choice of the 'name space authority' not to choose symbols, 'names', that are ambiguous. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Friday, October 14, 2005 3:49 PM Subject: [Syslog] Unicode - was: AD Review for draft-ietf-syslog-protocol-14 Hi WG, I address the following issue Sam mentioned: > 2) You do not discuss Unicode security at all. I suggest that people > in the working group read Unicode TR 36 and also consider the > implications of the Unicode security presentation given at the > last SAAG presentation. particularly consider comments from > operators concerned about Unicode characters interacting with > existing scripts. Then write up a security considerations > section. You need to at least explain the security risks > associated with your choice to support all Unicode characters. It > would be a good idea to discuss other alternatives that were > considered and to explain why this choice was made. I have gone through the material Sam mentions. For those not already done so, the following links might be helpful. The first link is to the presentation, which very quickly provides an overview of the magnitude of the issues. http://www3.ietf.org/proceedings/05aug/slides/saag-4.pdf http://www3.ietf.org/proceedings/05aug/saag.html#cmr http://www.unicode.org/reports/tr36/ (the UTR36) In a brief (and not 100% correct) summary, there are two issues with Unicode: one is the technical aspect of using non-common encoding forms that may lead to trick an application's security check code. This is addressed in section 3.1 of UTR 36. This issue is relatively straightforward to solve in requiring applications to use the shortest possible encoding only. I have already done some text change in syslog-protocol to cover this. The second issue is more subtle: that of visual security issues (outlined in section 2 of UTR36). In short, there are visually easily confusable characters - just like l (lower case letter L) and 1 (digit 1) in many fonts. This issue is of major concern if used in identifying information. UTR36 also gives some insights into the international DNS decisions and issues with visual confusability. The bottom line is that whenever we use something as identifying information, targeted somewhere down the road towards humans, we have an issue. UTR36 defines some mechanisms to at least partly solve the confusabilty. However, in the context of syslog I consider none of them to be straightforward. If we require them in syslog-protocol, that will probably be a thing that costs us much acceptance at the implementor side. So it might be useful to think about where we have an issue at all. The MSG field, I think, does not count as identifying information. It is meant as a human-readable message. Even though it obviously carries information, I think it is not subject to an easy visual spoofing attack. Ok, one can think about scenarios where visual spoofing might cause confusion, but the severity level of this should be fairly low. I think it has the same implications as hoax mails, where misinformation in the textual part is a simple fact of life and not avoidable without stopping to use that service. So I conclude that supporting the full set of Unicode characters inside MSG is fine. The STRUCTURED-DATA is another story. Here, it includes information that might primarily be used as identifying information. Reviewing the current defined SD-IDs, I hardly see any need for using Unicode encoding. As far as I recall, we have selected Unicode instead of US-ASCII because we thought it might be benefitial for further extensions. However, given the fact of visual confusability and the need to deal with it, I am questioning if it acually is a good idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be better to use US-ASCII, which relievs us of all of these issues? So far, I do not see a compelling reason for full Unicode support in SD-IDs. Of course, we could just go ahead and document these issues in security considerations. I think, however, that we should try to solve them before resorting to that. I think we have a good chance of finding a workable solution. My suggestion to the WG is that we drop Unicode encoding for STRUCTURED-DATA and use printable US-ASCII instead. I would appreciate feedback on the following: #1 Is it OK the support Unicode - without restriction - in MSG? #2 Is there support in the WG for changing STRUCTURED-DATA encoding from Unicode to US-ASCII? If the answer to #2 is "no", please provide reasoning as that will help speed up the process. -- Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 17 08:50:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERURE-0006UC-5v; Mon, 17 Oct 2005 08:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERURC-0006TC-J4 for syslog@megatron.ietf.org; Mon, 17 Oct 2005 08:49:58 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09989 for ; Mon, 17 Oct 2005 08:49:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 9E44527C02C for ; Mon, 17 Oct 2005 14:48:00 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12041-01 for ; Mon, 17 Oct 2005 14:48:00 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 3E38627C02A for ; Mon, 17 Oct 2005 14:48:00 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 14:49:14 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2005 14:49:11 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3C39@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: plain tcp syslog Thread-Index: AcXTGSwb0EbXIY+ASqy8l45goVVG2Q== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 17 Oct 2005 12:49:14.0981 (UTC) FILETIME=[2E077150:01C5D319] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] plain tcp syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, Chris has put some questions about RFC 3195 usage on the agenda for the next IETF. In preparation for this, I am going to ask a question that I know is very unpopular in the WG. We have discussed the issue of a very-simple, non-BEEP based plain tcp syslog several times on this list. The idea always has violently been rejected. However, the current status is that RFC 3195 is nicely standardized but seldomly implemented and even less often deployed. Plain tcp syslog, on the other hand, is not standardized but widely deployed. It is implemented at least in: - syslog-ng - rsyslog - Kiwi syslog daemon - WinSyslog/MonitorWare Agent/EventReporter - Cisco PIX As of my experience, many syslog-ng installations use plain tcp syslog. All of the implementations listed are interoperable. The list is most probably not complete, these were just the products that came immediately to my mind. The end user-base is also continously asking about such a simple transport - this is probably why it is implemented so often. Given the obvious importance of this protocol, wouldn't it make sense to at least document its observed behaviour, much as RFC 3164 documents UDP based syslog observed behaviour? Such a document could also be useful to document the security and (un)reliability issues coming along with the "plain tcp" syslog. Eventually, this could even increase demand for more reliable solutions like RFC 3195. Feedback is appreciated. Rainer Gerhards _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 17 19:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReCK-0004bv-2K; Mon, 17 Oct 2005 19:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERd4m-0002NZ-L6 for syslog@megatron.ietf.org; Mon, 17 Oct 2005 18:03:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09689 for ; Mon, 17 Oct 2005 18:03:16 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERdGA-0005Uy-3w for syslog@ietf.org; Mon, 17 Oct 2005 18:15:12 -0400 Received: (qmail 73533 invoked from network); 17 Oct 2005 22:03:10 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 17 Oct 2005 22:03:10 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] plain tcp syslog Date: Tue, 18 Oct 2005 11:03:06 +1300 Organization: Kiwi Enterprises Message-ID: <001801c5d366$90763cc0$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3C39@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Oct 2005 19:15:15 -0400 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, A document describing syslog over TCP would be very handy. Two things that need to be identified are: the delimiting character - usually a LF (ASCII &H0A) and how long the maximum message length should be (4096 chrs seems to cover most implementations I've seen in the wild). NetScreen firewalls can also send syslog via TCP. Regards Andrew Kiwi Enterprises -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards Sent: Tuesday, 18 October 2005 1:49 a.m. To: syslog@ietf.org Subject: [Syslog] plain tcp syslog Hi WG, Chris has put some questions about RFC 3195 usage on the agenda for the next IETF. In preparation for this, I am going to ask a question that I know is very unpopular in the WG. We have discussed the issue of a very-simple, non-BEEP based plain tcp syslog several times on this list. The idea always has violently been rejected. However, the current status is that RFC 3195 is nicely standardized but seldomly implemented and even less often deployed. Plain tcp syslog, on the other hand, is not standardized but widely deployed. It is implemented at least in: - syslog-ng - rsyslog - Kiwi syslog daemon - WinSyslog/MonitorWare Agent/EventReporter - Cisco PIX As of my experience, many syslog-ng installations use plain tcp syslog. All of the implementations listed are interoperable. The list is most probably not complete, these were just the products that came immediately to my mind. The end user-base is also continously asking about such a simple transport - this is probably why it is implemented so often. Given the obvious importance of this protocol, wouldn't it make sense to at least document its observed behaviour, much as RFC 3164 documents UDP based syslog observed behaviour? Such a document could also be useful to document the security and (un)reliability issues coming along with the "plain tcp" syslog. Eventually, this could even increase demand for more reliable solutions like RFC 3195. Feedback is appreciated. Rainer Gerhards _______________________________________________ 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 Oct 17 23:32:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERiCp-0002PS-2x; Mon, 17 Oct 2005 23:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERiCn-0002PK-GI for syslog@megatron.ietf.org; Mon, 17 Oct 2005 23:32:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28883 for ; Mon, 17 Oct 2005 23:31:53 -0400 (EDT) Received: from mail.shs.siemens.com ([64.46.248.224] helo=mlvv9m2x.shs.siemens.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERiOF-0006KH-Kn for syslog@ietf.org; Mon, 17 Oct 2005 23:43:51 -0400 Received: from mlvv9m1x.shs.siemens.com (mlvv9m1x.shs.siemens.com [165.226.204.11]) by mlvv9m2x.shs.siemens.com (Postfix) with ESMTP id 68C7A383B4 for ; Mon, 17 Oct 2005 23:31:49 -0400 (EDT) Received: from usmlvv1imsso1.ww005.siemens.net (usmlvv1imsso1.ww005.siemens.net [165.226.169.170]) by mlvv9m1x.shs.siemens.com (8.12.11/8.12.11) with ESMTP id j9I3Vn9O027700 for ; Mon, 17 Oct 2005 23:31:49 -0400 Received: from MLVV099a.ww005.siemens.net ([165.226.248.184]) by usmlvv1imsso1.ww005.siemens.net with InterScan Messaging Security Suite; Mon, 17 Oct 2005 23:31:47 -0400 Received: by mlvv099a.ww005.siemens.net with Internet Mail Service (5.5.2657.72) id <4LZWPX4T>; Mon, 17 Oct 2005 23:31:47 -0400 Message-ID: From: Marshall Glen To: andrew@kiwisyslog.com, "'Rainer Gerhards'" , syslog@ietf.org Subject: RE: [Syslog] plain tcp syslog Date: Mon, 17 Oct 2005 23:31:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I'd like to see that too, although I think the length needs to be 32K for healthcare audit records (see RFC 3881). Glen Marshall -----Original Message----- From: Andrew Ross [mailto:andrew@kiwisyslog.com] Sent: Monday, October 17, 2005 18:03 To: 'Rainer Gerhards'; syslog@ietf.org Subject: RE: [Syslog] plain tcp syslog Hi Rainer, A document describing syslog over TCP would be very handy. Two things that need to be identified are: the delimiting character - usually a LF (ASCII &H0A) and how long the maximum message length should be (4096 chrs seems to cover most implementations I've seen in the wild). NetScreen firewalls can also send syslog via TCP. Regards Andrew Kiwi Enterprises -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards Sent: Tuesday, 18 October 2005 1:49 a.m. To: syslog@ietf.org Subject: [Syslog] plain tcp syslog Hi WG, Chris has put some questions about RFC 3195 usage on the agenda for the next IETF. In preparation for this, I am going to ask a question that I know is very unpopular in the WG. We have discussed the issue of a very-simple, non-BEEP based plain tcp syslog several times on this list. The idea always has violently been rejected. However, the current status is that RFC 3195 is nicely standardized but seldomly implemented and even less often deployed. Plain tcp syslog, on the other hand, is not standardized but widely deployed. It is implemented at least in: - syslog-ng - rsyslog - Kiwi syslog daemon - WinSyslog/MonitorWare Agent/EventReporter - Cisco PIX As of my experience, many syslog-ng installations use plain tcp syslog. All of the implementations listed are interoperable. The list is most probably not complete, these were just the products that came immediately to my mind. The end user-base is also continously asking about such a simple transport - this is probably why it is implemented so often. Given the obvious importance of this protocol, wouldn't it make sense to at least document its observed behaviour, much as RFC 3164 documents UDP based syslog observed behaviour? Such a document could also be useful to document the security and (un)reliability issues coming along with the "plain tcp" syslog. Eventually, this could even increase demand for more reliable solutions like RFC 3195. Feedback is appreciated. Rainer Gerhards _______________________________________________ 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 ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to Central.SecurityOffice@shs.siemens.com Thank you _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 00:40:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERjGm-0006as-GV; Tue, 18 Oct 2005 00:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERjGk-0006am-Nl for syslog@megatron.ietf.org; Tue, 18 Oct 2005 00:40:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01981 for ; Tue, 18 Oct 2005 00:40:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERjSC-00081E-NF for syslog@ietf.org; Tue, 18 Oct 2005 00:52:02 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 21:40:01 -0700 X-IronPort-AV: i="3.97,226,1125903600"; d="scan'208"; a="353413732:sNHT26354360" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9I4dh9C002179; Mon, 17 Oct 2005 21:39:58 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 00:39:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] plain tcp syslog Date: Tue, 18 Oct 2005 00:39:55 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731229F32BD@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] plain tcp syslog Thread-Index: AcXTGSwb0EbXIY+ASqy8l45goVVG2QAggv+w From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 18 Oct 2005 04:39:56.0050 (UTC) FILETIME=[FD27D720:01C5D39D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: Just my 2 cents... I am not in favor of informational RFC describing some behavior "as seen = in the wild". If you want to create a standard - that's a different = matter. But an informational RFC just clouds the water because it makes = an appearance of describing a standard, while not really making any = standard. =20 This has been a point of major confusion around syslog RFC 3164, for = example. I have personally had to explain over and over to a lot of = engineers/managers that it is not a standard and "compliant" = implementation can send petty much anything yet claim consistency with = that RFC. That's what you end up with when you don't have strict = requirements in the RFC. =20 Thanks, Anton.=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, October 17, 2005 8:49 AM > To: syslog@ietf.org > Subject: [Syslog] plain tcp syslog >=20 > Hi WG, >=20 > Chris has put some questions about RFC 3195 usage on the=20 > agenda for the next IETF. In preparation for this, I am going=20 > to ask a question that I know is very unpopular in the WG. >=20 > We have discussed the issue of a very-simple, non-BEEP based=20 > plain tcp syslog several times on this list. The idea always=20 > has violently been rejected. >=20 > However, the current status is that RFC 3195 is nicely=20 > standardized but seldomly implemented and even less often=20 > deployed. Plain tcp syslog, on the other hand, is not=20 > standardized but widely deployed. It is implemented at least in: >=20 > - syslog-ng > - rsyslog > - Kiwi syslog daemon > - WinSyslog/MonitorWare Agent/EventReporter > - Cisco PIX >=20 > As of my experience, many syslog-ng installations use plain=20 > tcp syslog. > All of the implementations listed are interoperable. The list=20 > is most probably not complete, these were just the products=20 > that came immediately to my mind. The end user-base is also=20 > continously asking about such a simple transport - this is=20 > probably why it is implemented so often. >=20 > Given the obvious importance of this protocol, wouldn't it=20 > make sense to at least document its observed behaviour, much=20 > as RFC 3164 documents UDP based syslog observed behaviour?=20 > Such a document could also be useful to document the security=20 > and (un)reliability issues coming along with the "plain tcp"=20 > syslog. Eventually, this could even increase demand for more=20 > reliable solutions like RFC 3195. >=20 > Feedback is appreciated. > Rainer Gerhards >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 06:16:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERoWE-0004fX-AE; Tue, 18 Oct 2005 06:16:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERoWD-0004fK-69 for syslog@megatron.ietf.org; Tue, 18 Oct 2005 06:16:29 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19228 for ; Tue, 18 Oct 2005 06:16:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 178F727C027 for ; Tue, 18 Oct 2005 12:14:25 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30893-07 for ; Tue, 18 Oct 2005 12:14:24 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id A4FFC27C026 for ; Tue, 18 Oct 2005 12:14:24 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Oct 2005 12:15:50 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] plain tcp syslog MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Oct 2005 12:15:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3C4E@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] plain tcp syslog Thread-Index: AcXTGSwb0EbXIY+ASqy8l45goVVG2QAggv+wAAwvepA= From: "Rainer Gerhards" To: X-OriginalArrivalTime: 18 Oct 2005 10:15:50.0996 (UTC) FILETIME=[EA708940:01C5D3CC] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton: I agree that an actual standard would be much better. However, I've seen very violent objection on this list against it. So it might be a compromise to create an informational document that at least describes what currently *is* done. It's being implemented and deployed anyway, so documenting it does not hurt. Not documenting it will not stop it from being implemented and deployed, there is simply too much demand in the market and it is working far to well to dump it "just" because it is no-standard (in fact, I think it is already "industry-standard" with the large number of supporters it has). But let's try again: I suggest that we create a standard-track document on a very simple and not fully reliable tcp based transport in the spirit of what syslog-ng and many others do today. Most probably, it would make sense to create it in the form of a transport mapping, just like Anton's UDP transport mapping. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Tuesday, October 18, 2005 6:40 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] plain tcp syslog >=20 > Rainer: >=20 > Just my 2 cents... >=20 > I am not in favor of informational RFC describing some=20 > behavior "as seen in the wild". If you want to create a=20 > standard - that's a different matter. But an informational=20 > RFC just clouds the water because it makes an appearance of=20 > describing a standard, while not really making any standard. =20 >=20 > This has been a point of major confusion around syslog RFC=20 > 3164, for example. I have personally had to explain over and=20 > over to a lot of engineers/managers that it is not a standard=20 > and "compliant" implementation can send petty much anything=20 > yet claim consistency with that RFC. That's what you end up=20 > with when you don't have strict requirements in the RFC. =20 >=20 > Thanks, > Anton.=20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Monday, October 17, 2005 8:49 AM > > To: syslog@ietf.org > > Subject: [Syslog] plain tcp syslog > >=20 > > Hi WG, > >=20 > > Chris has put some questions about RFC 3195 usage on the=20 > > agenda for the next IETF. In preparation for this, I am going=20 > > to ask a question that I know is very unpopular in the WG. > >=20 > > We have discussed the issue of a very-simple, non-BEEP based=20 > > plain tcp syslog several times on this list. The idea always=20 > > has violently been rejected. > >=20 > > However, the current status is that RFC 3195 is nicely=20 > > standardized but seldomly implemented and even less often=20 > > deployed. Plain tcp syslog, on the other hand, is not=20 > > standardized but widely deployed. It is implemented at least in: > >=20 > > - syslog-ng > > - rsyslog > > - Kiwi syslog daemon > > - WinSyslog/MonitorWare Agent/EventReporter > > - Cisco PIX > >=20 > > As of my experience, many syslog-ng installations use plain=20 > > tcp syslog. > > All of the implementations listed are interoperable. The list=20 > > is most probably not complete, these were just the products=20 > > that came immediately to my mind. The end user-base is also=20 > > continously asking about such a simple transport - this is=20 > > probably why it is implemented so often. > >=20 > > Given the obvious importance of this protocol, wouldn't it=20 > > make sense to at least document its observed behaviour, much=20 > > as RFC 3164 documents UDP based syslog observed behaviour?=20 > > Such a document could also be useful to document the security=20 > > and (un)reliability issues coming along with the "plain tcp"=20 > > syslog. Eventually, this could even increase demand for more=20 > > reliable solutions like RFC 3195. > >=20 > > Feedback is appreciated. > > Rainer Gerhards > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 07:50:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERpz5-0002aa-Hh; Tue, 18 Oct 2005 07:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERpz3-0002aO-On for syslog@megatron.ietf.org; Tue, 18 Oct 2005 07:50:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23956 for ; Tue, 18 Oct 2005 07:50:10 -0400 (EDT) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERqAV-0002YE-2h for syslog@ietf.org; Tue, 18 Oct 2005 08:02:14 -0400 Subject: RE: [Syslog] plain tcp syslog From: Balazs Scheidler To: Marshall Glen In-Reply-To: References: Content-Type: text/plain Date: Tue, 18 Oct 2005 13:50:04 +0200 Message-Id: <1129636204.28386.3.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Mon, 2005-10-17 at 23:31 -0400, Marshall Glen wrote: > I'd like to see that too, although I think the length needs to be 32K for > healthcare audit records (see RFC 3881). I think a required limit and a SHOULD clause stating that implementations should support longer message lengths via some configuration mechanism would be ok. (for the record syslog-ng supports specifying the maximum message length using a configuration parameter, and it defaults to 8k) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 08:41:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqmG-0002AB-Il; Tue, 18 Oct 2005 08:41:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqmF-0002A3-1E for syslog@megatron.ietf.org; Tue, 18 Oct 2005 08:41:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27012 for ; Tue, 18 Oct 2005 08:41:02 -0400 (EDT) Received: from adsl.mietus.nl ([80.126.244.90] helo=morpork.ons-huis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERqxk-0003rW-5R for syslog@ietf.org; Tue, 18 Oct 2005 08:53:06 -0400 Received: by morpork.ons-huis.net (Postfix, from userid 103) id 6A0A3102; Tue, 18 Oct 2005 14:40:34 +0200 (CEST) Received: from [10.0.0.175] (BOOK [10.0.0.175]) by morpork.ons-huis.net (Postfix) with ESMTP id EC79E5C; Tue, 18 Oct 2005 14:40:31 +0200 (CEST) In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3C39@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E3C39@grfint2.intern.adiscon.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A6D76B2-9D69-4DEE-B0CA-C172AE253D8B@ons-huis.net> Content-Transfer-Encoding: 7bit From: Albert Mietus Subject: Re: [Syslog] plain tcp syslog Date: Tue, 18 Oct 2005 14:40:30 +0200 To: Rainer Gerhards X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on morpork.ons-huis.net X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.62 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > We have discussed the issue of a very-simple, non-BEEP based plain tcp > syslog several times on this list. The idea always has violently been > rejected. Iff (if and only if) there will be a standard for syslog-over-tcp, I think it should do more then replace UDP by TCP. Some years ago, we have studied this. And found that in environments where UDP 'will not do' a simple replacement will not suffice to. E.g. We needed to be able to transfer log from a hostile, "unsafe" environment (e.g. the systems just before the firewall), to a safe place (behind the FW). UDP isn't an option; nobody will accept such a DOS-hole. But for the same reasons, any TCP session from a possible hijacked host through the FW is not a good idea. So, we implemented a 'reverse, buffered' TCP syslog. The idea: a (controlled, safe) host will start an (outward) TCP session, fetching log from the 'unsafe' area. When there is no connections the host in the hostile environment will buffer log (for some time) in memory. The latter will give stat-up log. But also make sure the "log during an attack" (when possible some systems/ the FW are down/closed) can be saved (and studied later). The reverse-flow will make sure never a 'hijacked' host can send data through the FW. Sure, some loglines that can be faked. But the control of that session is full: only a secure host can start a session. Note: For political reasons, the code is never put in production. (I have it laying somewhere, it is open ...). But it works. I mention this example; to show replacing UDP by TCP is simple and will suffice. I think, there is need for a TCP version. Personally, I don't like BEEP, nor the syslog-over-BEEP option. But a don't like a simple TCP syslog nether. Note: It just me. But I'm not actively involved in syslog anymore. And will be offline for some time. So I can't discuses a follow up --Groetjes ALbert Mietus Send prive mail to: ALbert at ons-huis dot net Send business mail to: Albert dot Mietus at PTS dot nl Don't send spam mail! http://albert.mietus.nl http://albert.mietus.nl/read.IT _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 10:29:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsSe-0008N8-3H; Tue, 18 Oct 2005 10:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsSc-0008N3-H7 for syslog@megatron.ietf.org; Tue, 18 Oct 2005 10:29:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03909 for ; Tue, 18 Oct 2005 10:28:54 -0400 (EDT) Message-Id: <200510181428.KAA03909@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERseA-0007Ag-LZ for syslog@ietf.org; Tue, 18 Oct 2005 10:40:59 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc14) with SMTP id <20051018142852014004k7fle>; Tue, 18 Oct 2005 14:28:52 +0000 From: "David B Harrington" To: "'Albert Mietus'" , "'Rainer Gerhards'" Subject: RE: [Syslog] plain tcp syslog Date: Tue, 18 Oct 2005 10:28:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2A6D76B2-9D69-4DEE-B0CA-C172AE253D8B@ons-huis.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXT4Xq54V7vaWj8Sn+rBvhBrQH6XgACsV1Q X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, There will be much discussion of "call-home" functionality, something akin to the reverese buffered approach described here, at the upcoming Vancouver meeting. It may be a BOF, or it may be a discussion in the O&M open area meeting. See https://www1.ietf.org/mailman/listinfo/call-home for information about the call-home mailing list. The proponents are looking for operators who think this is really needed for network management protocols, and should be addressed as part of the ISMS WG work or in a separate WG. This discussion is largely targeted at SNMP and NETCONF over TCP-based transports, such as SSH. It sounds like the syslog WG should be involved in this discussion as well, even if the WG chooses to just do a TCP transport mapping. The security and transport needs for SNMP, Netconf, and syslog are converging. Note that a TCP transport mapping was developed for SNMP (RFC3430), and the demand was for more than just TCP; the demand was for a secured TCP transport. Currently the ISMS WG is working on an SSH-secured transport for SNMP to parallel Netconf's use of SSH, although the ISMS version has more to it than Netconf's because we are also tying into RADIUS centralized authentication through SSH, and tying the centralized RADIUS authorization into SNMP access control. For the record, I believe standardizing a TCP-based transport mapping for syslog, preferably using SSH, would be a good supplement to the UDP transport mapping. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Albert Mietus > Sent: Tuesday, October 18, 2005 8:41 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] plain tcp syslog > > > We have discussed the issue of a very-simple, non-BEEP > based plain tcp > > syslog several times on this list. The idea always has > violently been > > rejected. > > Iff (if and only if) there will be a standard for syslog-over-tcp, I > think it should do more then replace UDP by TCP. > > Some years ago, we have studied this. And found that in environments > where UDP 'will not do' a simple replacement will not suffice to. > E.g. We needed to be able to transfer log from a hostile, "unsafe" > environment (e.g. the systems just before the firewall), to a safe > place (behind the FW). UDP isn't an option; nobody will accept such > a DOS-hole. But for the same reasons, any TCP session from a > possible > hijacked host through the FW is not a good idea. > So, we implemented a 'reverse, buffered' TCP syslog. > > The idea: a (controlled, safe) host will start an (outward) TCP > session, fetching log from the 'unsafe' area. When there is no > connections the host in the hostile environment will buffer log (for > some time) in memory. The latter will give stat-up log. But > also make > sure the "log during an attack" (when possible some systems/ the FW > are down/closed) can be saved (and studied later). The reverse-flow > will make sure never a 'hijacked' host can send data through the FW. > Sure, some loglines that can be faked. But the control of that > session is full: only a secure host can start a session. > > Note: For political reasons, the code is never put in production. (I > have it laying somewhere, it is open ...). But it works. > > I mention this example; to show replacing UDP by TCP is simple and > will suffice. I think, there is need for a TCP version. > Personally, I > don't like BEEP, nor the syslog-over-BEEP option. But a don't like a > simple TCP syslog nether. > > Note: It just me. But I'm not actively involved in syslog anymore. > And will be offline for some time. So I can't discuses a follow up > > > > > --Groetjes > ALbert Mietus > Send prive mail to: ALbert at ons-huis dot net > Send business mail to: Albert dot Mietus at PTS dot nl > Don't send spam mail! > http://albert.mietus.nl http://albert.mietus.nl/read.IT > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 10:34:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsYC-0001GX-70; Tue, 18 Oct 2005 10:34:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsYA-0001GM-IV for syslog@megatron.ietf.org; Tue, 18 Oct 2005 10:34:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04251 for ; Tue, 18 Oct 2005 10:34:38 -0400 (EDT) Received: from mail.shs.siemens.com ([64.46.248.224] helo=mlvv9m2x.shs.siemens.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsjh-0007Ka-PE for syslog@ietf.org; Tue, 18 Oct 2005 10:46:43 -0400 Received: from mlvv9m1x.shs.siemens.com (mlvv9m1x.shs.siemens.com [165.226.204.11]) by mlvv9m2x.shs.siemens.com (Postfix) with ESMTP id 654FF3898B for ; Tue, 18 Oct 2005 10:34:28 -0400 (EDT) Received: from usmlvv1imsso1.ww005.siemens.net (usmlvv1imsso1.ww005.siemens.net [165.226.169.170]) by mlvv9m1x.shs.siemens.com (8.12.11/8.12.11) with ESMTP id j9IEYSrU009889 for ; Tue, 18 Oct 2005 10:34:28 -0400 Received: from MLVV099a.ww005.siemens.net ([165.226.248.184]) by usmlvv1imsso1.ww005.siemens.net with InterScan Messaging Security Suite; Tue, 18 Oct 2005 10:34:27 -0400 Received: by mlvv099a.ww005.siemens.net with Internet Mail Service (5.5.2657.72) id <4LZWRD4K>; Tue, 18 Oct 2005 10:34:27 -0400 Message-ID: From: Marshall Glen To: "'Darren Reed'" Subject: RE: [Syslog] plain tcp syslog Date: Tue, 18 Oct 2005 10:34:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org RFC 3881 is transport agnostic. However, DICOM Supplement 99 and the IHE technical framework that specify its implementations currently require Reliable Syslog COOKED. The issue is the maximum supported length. RFC 3195 does not specify a limit. So the issue is what that limit should be. Many of the medical devices that implement an audit capability are not general-purpose computers, e.g., radiological modalities. A simple protocol stack like BEEP is preferable, for a variety of good reasons, for those cases. Glen Marshall -----Original Message----- From: Darren Reed [mailto:darrenr@reed.wattle.id.au] Sent: Tuesday, October 18, 2005 10:23 AM To: Marshall Glen Cc: andrew@kiwisyslog.com; 'Rainer Gerhards'; syslog@ietf.org Subject: Re: [Syslog] plain tcp syslog > > I'd like to see that too, although I think the length needs to be 32K for > healthcare audit records (see RFC 3881). Why ? RFC 3881 doesn't specify that syslog needs to be anywhere. If you've got long records that need to be saved for audit purposes then perhaps a protocol other than syslog should be used for this ? Just because you have a hammer doesn't make everything you want to fix a nail. (or however it goes :) Darren ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to Central.SecurityOffice@shs.siemens.com Thank you _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 11:36:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtVV-0002YR-V5; Tue, 18 Oct 2005 11:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsE6-0001G1-Ew for syslog@megatron.ietf.org; Tue, 18 Oct 2005 10:14:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03226 for ; Tue, 18 Oct 2005 10:13:53 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsPa-0006li-36 for syslog@ietf.org; Tue, 18 Oct 2005 10:25:57 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9IEDE6l024147; Wed, 19 Oct 2005 00:13:14 +1000 (EST) From: Darren Reed Message-Id: <200510181412.j9IECqMq021681@firewall.reed.wattle.id.au> Subject: Re: [Syslog] plain tcp syslog In-Reply-To: <98AE08B66FAD1742BED6CB9522B731229F32BD@xmb-rtp-20d.amer.cisco.com> To: "Anton Okmianski (aokmians)" Date: Wed, 19 Oct 2005 00:12:52 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Oct 2005 11:36:04 -0400 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > Rainer: > > Just my 2 cents... > > I am not in favor of informational RFC describing some behavior "as > seen in the wild". If you want to create a standard - that's a different > matter. But an informational RFC just clouds the water because it makes > an appearance of describing a standard, while not really making any > standard. Good, so you don't have any technical problems with doing it. > This has been a point of major confusion around syslog RFC 3164, for > example. I have personally had to explain over and over to a lot of > engineers/managers that it is not a standard and "compliant" > implementation can send petty much anything yet claim consistency with > that RFC. That's what you end up with when you don't have strict > requirements in the RFC. Have you also mentioned to your engineers/managers that all of the Cisco devices, for years and years, were RFC 3164 compliant ? Or that this RFC documents an otherwise undocumented protocol that they have been implementing for years ? What you're describing are organisation problems and not the domain of this working group to solve. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 11:36:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtVW-0002Yq-7i; Tue, 18 Oct 2005 11:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsJY-0003qc-3m for syslog@megatron.ietf.org; Tue, 18 Oct 2005 10:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03466 for ; Tue, 18 Oct 2005 10:19:32 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsV4-0006vb-AQ for syslog@ietf.org; Tue, 18 Oct 2005 10:31:36 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9IEJM1a020430; Wed, 19 Oct 2005 00:19:22 +1000 (EST) From: Darren Reed Message-Id: <200510181419.j9IEJ32o021749@firewall.reed.wattle.id.au> Subject: Re: [Syslog] plain tcp syslog In-Reply-To: <2A6D76B2-9D69-4DEE-B0CA-C172AE253D8B@ons-huis.net> To: Albert Mietus Date: Wed, 19 Oct 2005 00:19:03 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Oct 2005 11:36:04 -0400 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > We have discussed the issue of a very-simple, non-BEEP based plain tcp > > syslog several times on this list. The idea always has violently been > > rejected. > > Iff (if and only if) there will be a standard for syslog-over-tcp, I > think it should do more then replace UDP by TCP. Eventually, yes. But we don't have to get there in one big jump, especially if there is evidence that the proposed result will be widely rejected. > I mention this example; to show replacing UDP by TCP is simple and > will suffice. I think, there is need for a TCP version. Personally, I > don't like BEEP, nor the syslog-over-BEEP option. But a don't like a > simple TCP syslog nether. I think starting off with a simple TCP syslog and adding to it with a reliable version (matching the UDP progress) is the right way to start. I think there is much more chance of getting progress and useful RFCs and internet drafts published that way than trying to solve the entire solution space in one hit. i.e. BEEP has been proposed as "the solution", nobody likes it, lets back off, do what we know people like and along the way maybe we will learn about how to deliver the ultimate solution that people do want. btw, I'm willing to add my voice to this in Vancouver, if it matters to anyone. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 11:36:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtVW-0002ZF-H1; Tue, 18 Oct 2005 11:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsMt-0004yQ-2T for syslog@megatron.ietf.org; Tue, 18 Oct 2005 10:23:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03656 for ; Tue, 18 Oct 2005 10:22:59 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsYQ-000727-FM for syslog@ietf.org; Tue, 18 Oct 2005 10:35:03 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9IEN0ma023016; Wed, 19 Oct 2005 00:23:00 +1000 (EST) From: Darren Reed Message-Id: <200510181422.j9IEMWlo020973@firewall.reed.wattle.id.au> Subject: Re: [Syslog] plain tcp syslog In-Reply-To: To: Marshall Glen Date: Wed, 19 Oct 2005 00:22:31 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Oct 2005 11:36:04 -0400 Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > I'd like to see that too, although I think the length needs to be 32K for > healthcare audit records (see RFC 3881). Why ? RFC 3881 doesn't specify that syslog needs to be anywhere. If you've got long records that need to be saved for audit purposes then perhaps a protocol other than syslog should be used for this ? Just because you have a hammer doesn't make everything you want to fix a nail. (or however it goes :) Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 11:36:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtVW-0002Ze-QJ; Tue, 18 Oct 2005 11:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERssu-0007iK-5h for syslog@megatron.ietf.org; Tue, 18 Oct 2005 10:56:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06033 for ; Tue, 18 Oct 2005 10:56:04 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERt4Q-00086q-D1 for syslog@ietf.org; Tue, 18 Oct 2005 11:08:08 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9IEtx7b021333; Wed, 19 Oct 2005 00:55:59 +1000 (EST) From: Darren Reed Message-Id: <200510181455.j9IEtcVw020944@firewall.reed.wattle.id.au> Subject: Re: [Syslog] plain tcp syslog In-Reply-To: To: Marshall Glen Date: Wed, 19 Oct 2005 00:55:38 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Oct 2005 11:36:04 -0400 Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > RFC 3881 is transport agnostic. However, DICOM Supplement 99 and the IHE > technical framework that specify its implementations currently require > Reliable Syslog COOKED. The issue is the maximum supported length. RFC > 3195 does not specify a limit. So the issue is what that limit should be. Well whoever wrote DICOM Supplement 99 and the IHE technical framework should be told they screwed up in deciding that this was the way to go and implementors should use something else that makes sense. > Many of the medical devices that implement an audit capability are not > general-purpose computers, e.g., radiological modalities. A simple protocol > stack like BEEP is preferable, for a variety of good reasons, for those > cases. BEEP is NOT simple. BEEP is extraordinarily complex solution for what is a very simple problem. If it was simple syslog over TCP, today, would use it. In open source, people vote with their feet (or their code) and the result of that poll is that BEEP for syslog over TCP is a failure. BEEP and syslog is like an orphan looking for someone or something to make it feel loved. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 11:36:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtVX-0002a3-3j; Tue, 18 Oct 2005 11:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsyO-0000yL-Tq for syslog@megatron.ietf.org; Tue, 18 Oct 2005 11:01:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07187 for ; Tue, 18 Oct 2005 11:01:44 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERt9v-00006J-Cv for syslog@ietf.org; Tue, 18 Oct 2005 11:13:49 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9IF1b4a024795; Wed, 19 Oct 2005 01:01:37 +1000 (EST) From: Darren Reed Message-Id: <200510181501.j9IF17RP021080@firewall.reed.wattle.id.au> Subject: Re: [Syslog] plain tcp syslog In-Reply-To: <200510181428.KAA03909@ietf.org> To: ietfdbh@comcast.net Date: Wed, 19 Oct 2005 01:01:07 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Oct 2005 11:36:04 -0400 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org .. > This discussion is largely targeted at SNMP and NETCONF over TCP-based > transports, such as SSH. It sounds like the syslog WG should be > involved in this discussion as well, even if the WG chooses to just do > a TCP transport mapping. The security and transport needs for SNMP, > Netconf, and syslog are converging. So what you're saying is that the others are tunelling via ssh to deliver data back via secure means as well as have that connection properly authenticated ? (for some value of "proper") > Note that a TCP transport mapping was developed for SNMP (RFC3430), > and the demand was for more than just TCP; the demand was for a > secured TCP transport. Why was SSL/TLS rejected ? > For the record, I believe standardizing a TCP-based transport mapping > for syslog, preferably using SSH, would be a good supplement to the > UDP transport mapping. How do you propose (or imagine) that this would work for an arbitrary device connected to your network (say printer) that wants to use this mechanism to deliver syslog messages ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 11:46:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtfw-00044q-5H; Tue, 18 Oct 2005 11:46:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtfu-00043V-0q for syslog@megatron.ietf.org; Tue, 18 Oct 2005 11:46:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11077 for ; Tue, 18 Oct 2005 11:46:41 -0400 (EDT) Message-Id: <200510181546.LAA11077@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtrN-0001i0-Rg for syslog@ietf.org; Tue, 18 Oct 2005 11:58:44 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc11) with SMTP id <2005101815463201300cg105e>; Tue, 18 Oct 2005 15:46:33 +0000 From: "David B Harrington" To: "'Darren Reed'" Subject: RE: [Syslog] plain tcp syslog Date: Tue, 18 Oct 2005 11:46:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200510181501.j9IF17RP021080@firewall.reed.wattle.id.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXT9NgK0nW4spbTQ76kJKu5E1TeSAAAoZFg X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Comments inline > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > Sent: Tuesday, October 18, 2005 11:01 AM > To: ietfdbh@comcast.net > Cc: 'Albert Mietus'; 'Rainer Gerhards'; syslog@ietf.org > Subject: Re: [Syslog] plain tcp syslog > > .. > > This discussion is largely targeted at SNMP and NETCONF > over TCP-based > > transports, such as SSH. It sounds like the syslog WG should be > > involved in this discussion as well, even if the WG chooses > to just do > > a TCP transport mapping. The security and transport needs for SNMP, > > Netconf, and syslog are converging. > > So what you're saying is that the others are tunelling via ssh to > deliver data back via secure means as well as have that connection > properly authenticated ? (for some value of "proper") Other WGs are using user authenticated sessions over a secure connection for request-response types of network management data, and plan to use similar tunnels for notification types of traffic. The ISMS and Netconf WGs are considering using a call-back approach. > > > Note that a TCP transport mapping was developed for SNMP (RFC3430), > > and the demand was for more than just TCP; the demand was for a > > secured TCP transport. > > Why was SSL/TLS rejected ? SSL/TLS was not rejected. SSH was identified by the Netconf WG as the "transport" of preference for operators performing configuration tasks using CLI scripting, and Netconf is an effort to provide a machine-parseable alternative to CLI scripting. SSH was identified by the ISMS WG as one of the secure "transport" protocols that operators would like to see utilized for SNMP. TLS was another. The ISMS WG chose to design an SSH security model for SNMP because it had a slight edge over other protocols in a survey of NANOG operators, and it had already been chosen by Netconf as the mandatory-to-implement protocol. > > > For the record, I believe standardizing a TCP-based > transport mapping > > for syslog, preferably using SSH, would be a good supplement to the > > UDP transport mapping. > > How do you propose (or imagine) that this would work for an arbitrary > device connected to your network (say printer) that wants to use this > mechanism to deliver syslog messages ? About the same as it would work for an arbitrary device that wants to use this mechanism to deliver SNMP or Netconf notifications. See draft-ietf-isms-secshell-00.txt for more information (in the I-D queue at this point, but not yet available). An earlier version can be found in ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-ism s-secshell-01.txt. > > Darren > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 13:07:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuvf-0007lK-20; Tue, 18 Oct 2005 13:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuvd-0007hv-0J for syslog@megatron.ietf.org; Tue, 18 Oct 2005 13:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16065 for ; Tue, 18 Oct 2005 13:07:00 -0400 (EDT) From: rjhorn@panix.com Received: from mail1.panix.com ([166.84.1.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERv7C-000456-CJ for syslog@ietf.org; Tue, 18 Oct 2005 13:19:06 -0400 Received: from mailspool3.panix.com (mailspool3.panix.com [166.84.1.78]) by mail1.panix.com (Postfix) with ESMTP id 4A9F95A43D; Tue, 18 Oct 2005 13:06:53 -0400 (EDT) Received: from panix.com (panix1.panix.com [166.84.1.1]) by mailspool3.panix.com (Postfix) with ESMTP id 11172392987; Tue, 18 Oct 2005 13:06:47 -0400 (EDT) Date: Tue, 18 Oct 2005 13:06:43 -0400 (EDT) Subject: Re: [Syslog] plain tcp syslog To: darrenr@reed.wattle.id.au In-Reply-To: <200510181455.j9IEtcVw020944@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20051018170647.11172392987@mailspool3.panix.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: glen.f.marshall@siemens.com, syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rjhorn@alum.mit.edu List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On 19 Oct, Darren Reed wrote: >> >> RFC 3881 is transport agnostic. However, DICOM Supplement 99 and the IHE >> technical framework that specify its implementations currently require >> Reliable Syslog COOKED. The issue is the maximum supported length. RFC >> 3195 does not specify a limit. So the issue is what that limit should be. > > Well whoever wrote DICOM Supplement 99 and the IHE technical > framework should be told they screwed up in deciding that this > was the way to go and implementors should use something else > that makes sense. > Look in a (virtual) mirror. Supplement 99 was issued for public comment before RFC 3195 was approved, and we did inform the syslog group, and there was no comment. But, at the time the syslog group was still pushing the used of BEEP through the approval process in the IETF and I'm not surprised that they thought that DICOM's use of BEEP was appropriate. They were still pushing BEEP themselves. DICOM was just trying to avoid re-inventing the wheel and following their lead. In fact, Supplement 99 is still in frozen draft for trial implementation stage. We recognized the novelty and uncertainty in all this. So it is not yet issued as part of the standard. It is gathering public feedback. Yours is appreciated. The issue of message size is very important in healthcare. For other reasons we must use XML encoding. This has the practical impact of increasing message size by a factor of 5-10. So a message that sensible people would put into 2-3KB expands to 20+KB when XML encoded. That's life. We have to deal with big messages. > If it was simple syslog over TCP, today, would use it. Unfortunately TCP alone is not going to address the reliability concern. On that front we are looking for a reliable application level datagram service. The problem scenario for TCP is primarily driven by mobile equipment, although some kinds of network problems and equipment problems can trigger it. It's the mobile equipment that worries me. The others are low enough probability that I don't worry. On all of the interesting OS systems, the TCP stack will return "success" for transmission of a small message (where small means it fits in the unused portion of a TCP window). The message need not have left the system yet. In fact, the network may be down or disconnected. The OS still returns "success", so the application thinks that the message has been sent, takes it off the queue, proceeds to the next message, etc. If the problem is something like a loose cable or router glitch, the messages flow through and get delivered when the problem is fixed. But, if the sending machine is power cycled, applications restarted, or even just attached to a different network, all the messages in that buffer are lost. This is highly likely in the case of mobile equipment, and this kind of failure would be commonplace. It is not practical to expect people to follow a rigid procedure before unplugging mobile equipment from the network. The solution (used by DICOM, BEEP, HL7, etc.) is to demand an application level ACK before considering the message delivered. Any simple datagram framing on top of TCP delivers that. BEEP is overkill for what we need. but at the time BEEP was what the syslog group was using. Maybe I should propose a simple protocol like DICOM :-). (It really is a very simple protocol to implement. And there are about 20 open source implementations already. It's much simpler to implement than a web server.) A reliable datagram service needs: 1) Datagram framing (start/stop). 2) Datagram identification, e.g. sequence number. 3) Datagram acknowledgement/reject/retransmit. 4) Asynchronous operation (for reasonable performance) You need the identification and asynchronous operation so that the sender can stream datagrams out at full speed and keep the network pipeline full. We've seen too many problems in the DICOM world where failure to support asynchronous operation leads to unanticipated performance problems. You need to deal with out of order acknowledgement and recovery up front to avoid nasty compatibility issues later. So define asynchronous operation from the beginning. As long as the underlying error rate is low a very simplistic ack/nak system will work just fine. TCP and TLS deliver that low error rate. I would be happy with a reliable datagram framing service that could then be planted on top of UDP, TCP, or TLS. That lets me make the rest of the implementation tradeoffs separately. I can use TLS when I need authentication or encryption. I can use TCP when I'm traversing a network where message size or network characteristics make UDP unacceptable. I can use UDP when I have a suitable network environment. The discussions so far have ignored the mobile environment. In the mobile environment the use of TCP can lead to data loss with equipment relocations. That would be a problem. R Horn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 18 14:31:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwFL-0005V5-EP; Tue, 18 Oct 2005 14:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERwFJ-0005V0-KR for syslog@megatron.ietf.org; Tue, 18 Oct 2005 14:31:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21048 for ; Tue, 18 Oct 2005 14:31:24 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERwQq-0006g1-Qh for syslog@ietf.org; Tue, 18 Oct 2005 14:43:32 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2005 11:31:21 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9IIUpK3001067; Tue, 18 Oct 2005 11:31:18 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 14:30:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] plain tcp syslog Date: Tue, 18 Oct 2005 14:30:44 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122A44B88@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] plain tcp syslog Thread-Index: AcXT7iH3vrgQj/7WQ3mxPmk+jKjRNgAH6BhA From: "Anton Okmianski \(aokmians\)" To: "Darren Reed" X-OriginalArrivalTime: 18 Oct 2005 18:30:44.0953 (UTC) FILETIME=[0D6ACC90:01C5D412] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren: > > This has been a point of major confusion around syslog RFC=20 > 3164, for=20 > > example. I have personally had to explain over and over to=20 > a lot of=20 > > engineers/managers that it is not a standard and "compliant" > > implementation can send petty much anything yet claim=20 > consistency with=20 > > that RFC. That's what you end up with when you don't have strict=20 > > requirements in the RFC. >=20 > Have you also mentioned to your engineers/managers that all=20 > of the Cisco devices, for years and years, were RFC 3164 compliant ? >=20 > Or that this RFC documents an otherwise undocumented protocol=20 > that they have been implementing for years ? >=20 > What you're describing are organisation problems and not the=20 > domain of this working group to solve. Well... You say all of Cisco devices "were RFC 3164 compliant". This = illustrates my point. What exactly does this compliance mean? =20 My point is that any product can legitimately claim compliance with RFC = 3164 and this claim has zero practical usefulness! I don't know what = that compliance means, if RFC 3164 says in Sec 4.2: "There are no set requirements on the contents of the syslog packet as = it is originally sent from a device. It should be reiterated here that = the payload of any IP packet destined to UDP port 514 MUST be considered = to be a valid syslog message." So, I can send any UDP message and legitimately claim I am complaint = with RFC 3164. In fact, I can show you plenty of examples of very = different formats of syslog messages found in the wild in pretty popular = implementations.=20 This was one of the reasons, I thought, we initiated the whole = syslog-protocol work -- to make a real standard that could serve as = authoritative reference for interop. So, when I hear we want another = document similar to RFC 3164 in nature, I am a bit concerned if we are = repeating the same mistakes. Documenting does not make a standard IMO.=20 Now, one may argue that we could make a more strict informational RFC = than RFC 3164. But if we can do an RFC with strict requirements - then = make it a standard. I think it is a better investment of WG resources. = But obviously consensus opinion rules.=20 Thanks, Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 19 14:52:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJ3b-0001p9-DG; Wed, 19 Oct 2005 14:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJ3a-0001p2-0e for syslog@megatron.ietf.org; Wed, 19 Oct 2005 14:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06492 for ; Wed, 19 Oct 2005 14:52:47 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESJFL-00053H-0G for syslog@ietf.org; Wed, 19 Oct 2005 15:05:08 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9JIqY504607 for ; Wed, 19 Oct 2005 14:52:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2005 14:52:33 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40556E50B@zcarhxm2.corp.nortel.com> Thread-Topic: syslog conflicting with opsarea?! Thread-Index: AcXU3kN+4YSYGMDuQ3iNMcjlE+R/sw== From: "Sharon Chisholm" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: "Wijnen, Bert \(Bert\)" Subject: [Syslog] syslog conflicting with opsarea?! X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org hi I just noticed that the syslog session is set opposite the ops area meeting. This is bad. You will only get the security people there (lots of guys named Steve from what I understand). Can we fix this so we can get both the management *and* security folks? http://www.ietf.org/meetings/agenda_64.txt Sharon Chisholm Nortel=20 Ottawa, Ontario Canada _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Oct 20 09:51:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESapU-0005TW-4g; Thu, 20 Oct 2005 09:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESapS-0005SG-SS for syslog@megatron.ietf.org; Thu, 20 Oct 2005 09:51:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12795 for ; Thu, 20 Oct 2005 09:51:24 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESb1O-0000tM-VY for syslog@ietf.org; Thu, 20 Oct 2005 10:03:56 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2005 06:51:29 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="667862156:sNHT22443928" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KDpR95014074 for ; Thu, 20 Oct 2005 06:51:28 -0700 (PDT) Date: Thu, 20 Oct 2005 06:51:27 -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: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Syslog] TCP and SSH Discussion X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Our charter says: At a minimum this group will address providing authenticity, integrity and confidentiality of Syslog messages as they traverse the network. If the WG feels that an SSH transport will accomplish this goal, and it will be used, then I'm open to having that discussion. I don't feel that documenting current tcp transports works towards that goal. I've heard a few voices say that they would support an SSH transport on the mailing list. Does anyone object or have a differing view? (We will have this as a topic in Vancouver as well.) If we agree to move forward with this then we will need someone to write the document. Volunteers? We do have BEEP as a transport and I've received some email from a few people saying that they are using both the RAW and COOKED modes. Can I get someone who has implemented it to update RFC 3195? Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Oct 20 10:08:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESb5i-0003tq-AD; Thu, 20 Oct 2005 10:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESb5g-0003td-RF for syslog@megatron.ietf.org; Thu, 20 Oct 2005 10:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14559 for ; Thu, 20 Oct 2005 10:08:10 -0400 (EDT) Message-Id: <200510201408.KAA14559@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESbHc-0001gA-Rx for syslog@ietf.org; Thu, 20 Oct 2005 10:20:42 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <20051020140804013003gavme>; Thu, 20 Oct 2005 14:08:04 +0000 From: "David B Harrington" To: "'Chris Lonvick'" , Subject: RE: [Syslog] TCP and SSH Discussion Date: Thu, 20 Oct 2005 10:07:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXVfgxdI6bBGjeXS6Sk7KALVVBbSAAAKeMQ In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, For a discussion of syslog over SSH, I recommend people read the documents for other IETF network management protocols that plan to run over SSH: http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt and http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-00.txt http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-00.txt also deals with some issues related to moving a management protocol from UDP to TCP and sessions (but mostly is about backwards compatibility with the SNMPv3 architecture and access control). David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Thursday, October 20, 2005 9:51 AM > To: syslog@ietf.org > Subject: [Syslog] TCP and SSH Discussion > > Hi, > > Our charter says: > > At a minimum this group will address providing > authenticity, integrity > and confidentiality of Syslog messages as they traverse > the network. > > If the WG feels that an SSH transport will accomplish this > goal, and it > will be used, then I'm open to having that discussion. I > don't feel that > documenting current tcp transports works towards that goal. > I've heard a > few voices say that they would support an SSH transport on > the mailing > list. Does anyone object or have a differing view? (We will > have this as > a topic in Vancouver as well.) If we agree to move forward > with this then > we will need someone to write the document. Volunteers? > > We do have BEEP as a transport and I've received some email > from a few > people saying that they are using both the RAW and COOKED > modes. Can I > get someone who has implemented it to update RFC 3195? > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 04:56:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESsh1-0002ck-97; Fri, 21 Oct 2005 04:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESsgz-0002aK-FM for syslog@megatron.ietf.org; Fri, 21 Oct 2005 04:56:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07243 for ; Fri, 21 Oct 2005 04:55:48 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESst2-0008HM-9L for syslog@ietf.org; Fri, 21 Oct 2005 05:08:31 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9L8tck2024125; Fri, 21 Oct 2005 18:55:38 +1000 (EST) From: Darren Reed Message-Id: <200510210855.j9L8t4wj013464@firewall.reed.wattle.id.au> Subject: Re: [Syslog] TCP and SSH Discussion In-Reply-To: To: Chris Lonvick Date: Fri, 21 Oct 2005 18:55:03 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi, > > Our charter says: > > At a minimum this group will address providing authenticity, integrity > and confidentiality of Syslog messages as they traverse the network. > > If the WG feels that an SSH transport will accomplish this goal, and it > will be used, then I'm open to having that discussion. I don't feel that > documenting current tcp transports works towards that goal. The only concern I'd have would be syslog being _only_ UDP over ssh. But then if SNMP is operating in this manner, I'm much less concerned about it being a problem of any kind. If there are 4 different TCP transports for syslog out there, it might be worth trying to get them to converge and be interoperable. If the number can be reduced to 1 or 2, and this represents a sizable portion of the syslog over TCP install base, I think it behooves us have that protocol published. This might be something to push back on the implementors of said protocol(s). > I've heard a > few voices say that they would support an SSH transport on the mailing > list. Does anyone object or have a differing view? I'd add that we should look at supporting both TCP and UDP transports to the ssh endpoint but also, see the above. Using ssh is clearly a winning proposition at this piont in time. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 08:39:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwB8-0001nh-3T; Fri, 21 Oct 2005 08:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwB5-0001YO-QI for syslog@megatron.ietf.org; Fri, 21 Oct 2005 08:39:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18965 for ; Fri, 21 Oct 2005 08:39:06 -0400 (EDT) Message-Id: <200510211239.IAA18965@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwN9-0007gd-TL for syslog@ietf.org; Fri, 21 Oct 2005 08:51:50 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2005102112390201200fktjqe>; Fri, 21 Oct 2005 12:39:03 +0000 From: "David B Harrington" To: "'Darren Reed'" , "'Chris Lonvick'" Subject: RE: [Syslog] TCP and SSH Discussion Date: Fri, 21 Oct 2005 08:38:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXWHUuPGH5lzZbUQ3KCcdbDo9SIpAAHXryA In-Reply-To: <200510210855.j9L8t4wj013464@firewall.reed.wattle.id.au> X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Comments inline > > If the WG feels that an SSH transport will accomplish this > goal, and it > > will be used, then I'm open to having that discussion. I > don't feel that > > documenting current tcp transports works towards that goal. > > The only concern I'd have would be syslog being _only_ UDP over ssh. > But then if SNMP is operating in this manner, I'm much less concerned > about it being a problem of any kind. If there are 4 different TCP > transports for syslog out there, it might be worth trying to get them > to converge and be interoperable. If the number can be reduced to 1 > or 2, and this represents a sizable portion of the syslog over TCP > install base, I think it behooves us have that protocol published. > This might be something to push back on the implementors of said > protocol(s). I am not aware of an SSH-over-UDP standard; an SSH transport runs over TCP. Establishing the TCP connection is part of the SSH standard. http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-24.txt: "This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression." When SNMP runs over SSH, it is over an SSH/TCP transport. It is not running over UDP: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-00.txt > > > I've heard a > > few voices say that they would support an SSH transport on > the mailing > > list. Does anyone object or have a differing view? > > I'd add that we should look at supporting both TCP and UDP transports > to the ssh endpoint but also, see the above. Using ssh is clearly a > winning proposition at this piont in time. I don't think the SecSH WG has any plans to run SSH over UDP at this time. David Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 08:44:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwFe-0004UD-AL; Fri, 21 Oct 2005 08:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwFa-0004U5-PQ for syslog@megatron.ietf.org; Fri, 21 Oct 2005 08:44:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19199 for ; Fri, 21 Oct 2005 08:43:48 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwRj-0007pY-TD for syslog@ietf.org; Fri, 21 Oct 2005 08:56:32 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2005 05:43:50 -0700 X-IronPort-AV: i="3.97,239,1125903600"; d="scan'208"; a="222435811:sNHT23598812" 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 j9LChlJi020862; Fri, 21 Oct 2005 05:43:48 -0700 (PDT) Date: Fri, 21 Oct 2005 05:43:47 -0700 (PDT) From: Chris Lonvick To: Darren Reed Subject: Re: [Syslog] TCP and SSH Discussion In-Reply-To: <200510210855.j9L8t4wj013464@firewall.reed.wattle.id.au> Message-ID: References: <200510210855.j9L8t4wj013464@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Darren, It's not "syslog/udp/ssh" nor "syslog/tcp/ssh", it's going to be "syslog/ssh/tcp/ip". syslog will be a defined subsystem for SSH much like sftp and netconf. SSH subsystems are described here: http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/draft-ietf-secsh-connect-26.txt SFTP is here: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-10.txt netconf/ssh is here http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt Are you volunteering to write? :) Thanks, Chris On Fri, 21 Oct 2005, Darren Reed wrote: >> Hi, >> >> Our charter says: >> >> At a minimum this group will address providing authenticity, integrity >> and confidentiality of Syslog messages as they traverse the network. >> >> If the WG feels that an SSH transport will accomplish this goal, and it >> will be used, then I'm open to having that discussion. I don't feel that >> documenting current tcp transports works towards that goal. > > The only concern I'd have would be syslog being _only_ UDP over ssh. > But then if SNMP is operating in this manner, I'm much less concerned > about it being a problem of any kind. If there are 4 different TCP > transports for syslog out there, it might be worth trying to get them > to converge and be interoperable. If the number can be reduced to 1 > or 2, and this represents a sizable portion of the syslog over TCP > install base, I think it behooves us have that protocol published. > This might be something to push back on the implementors of said > protocol(s). > >> I've heard a >> few voices say that they would support an SSH transport on the mailing >> list. Does anyone object or have a differing view? > > I'd add that we should look at supporting both TCP and UDP transports > to the ssh endpoint but also, see the above. Using ssh is clearly a > winning proposition at this piont in time. > > Darren > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 08:48:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwJu-0007mQ-Bn; Fri, 21 Oct 2005 08:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwJs-0007mL-J4 for syslog@megatron.ietf.org; Fri, 21 Oct 2005 08:48:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19426 for ; Fri, 21 Oct 2005 08:48:14 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwW0-0007zY-Ni for syslog@ietf.org; Fri, 21 Oct 2005 09:00:58 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2005 05:48:14 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9LCmC95002408; Fri, 21 Oct 2005 05:48:13 -0700 (PDT) Date: Fri, 21 Oct 2005 05:48:12 -0700 (PDT) From: Chris Lonvick To: David B Harrington Subject: RE: [Syslog] TCP and SSH Discussion In-Reply-To: <4dg6tg$3qflpv@sj-inbound-e.cisco.com> Message-ID: References: <4dg6tg$3qflpv@sj-inbound-e.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi David, I'd also recommend that people look at the current thoughts on "call home". http://www.ietf.org/internet-drafts/draft-lear-callhome-description-03.txt Thanks, Chris On Thu, 20 Oct 2005, David B Harrington wrote: > Hi, > > For a discussion of syslog over SSH, I recommend people read the > documents for other IETF network management protocols that plan to run > over SSH: > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt and > http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-00.txt > > http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-00.txt also > deals with some issues related to moving a management protocol from > UDP to TCP and sessions (but mostly is about backwards compatibility > with the SNMPv3 architecture and access control). > > David Harrington > dbharrington@comcast.net > >> -----Original Message----- >> From: syslog-bounces@lists.ietf.org >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick >> Sent: Thursday, October 20, 2005 9:51 AM >> To: syslog@ietf.org >> Subject: [Syslog] TCP and SSH Discussion >> >> Hi, >> >> Our charter says: >> >> At a minimum this group will address providing >> authenticity, integrity >> and confidentiality of Syslog messages as they traverse >> the network. >> >> If the WG feels that an SSH transport will accomplish this >> goal, and it >> will be used, then I'm open to having that discussion. I >> don't feel that >> documenting current tcp transports works towards that goal. >> I've heard a >> few voices say that they would support an SSH transport on >> the mailing >> list. Does anyone object or have a differing view? (We will >> have this as >> a topic in Vancouver as well.) If we agree to move forward >> with this then >> we will need someone to write the document. Volunteers? >> >> We do have BEEP as a transport and I've received some email >> from a few >> people saying that they are using both the RAW and COOKED >> modes. Can I >> get someone who has implemented it to update RFC 3195? >> >> Thanks, >> Chris >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 09:04:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwZu-0007xs-Gz; Fri, 21 Oct 2005 09:04:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESwZs-0007xk-7g for syslog@megatron.ietf.org; Fri, 21 Oct 2005 09:04:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20334 for ; Fri, 21 Oct 2005 09:04:45 -0400 (EDT) Message-Id: <200510211304.JAA20334@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESwm0-00006Q-9f for syslog@ietf.org; Fri, 21 Oct 2005 09:17:29 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2005102113044401400sf3kde>; Fri, 21 Oct 2005 13:04:44 +0000 From: "David B Harrington" To: "'Chris Lonvick'" Subject: RE: [Syslog] TCP and SSH Discussion Date: Fri, 21 Oct 2005 09:04:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXWPbPuAYgnmutoS+ihjCjB3hsdJAAAaJtA In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Chris, Do you think "callhome" should be done in the SecSH WG, or should it be done as part of the syslog WG transport mapping? It seems to me it is a type of SSH transport negotiation, not part of syslog or snmp or netconf (although they might be affected by a reversed asymmetry of authentication). David Harrington dbharrington@comcast.net > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, October 21, 2005 8:48 AM > To: David B Harrington > Cc: syslog@ietf.org > Subject: RE: [Syslog] TCP and SSH Discussion > > Hi David, > > I'd also recommend that people look at the current thoughts on "call > home". > > http://www.ietf.org/internet-drafts/draft-lear-callhome-descri > ption-03.txt > > Thanks, > Chris > > On Thu, 20 Oct 2005, David B Harrington wrote: > > > Hi, > > > > For a discussion of syslog over SSH, I recommend people read the > > documents for other IETF network management protocols that > plan to run > > over SSH: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt and > > http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-00.txt > > > > http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-00.txt also > > deals with some issues related to moving a management protocol from > > UDP to TCP and sessions (but mostly is about backwards compatibility > > with the SNMPv3 architecture and access control). > > > > David Harrington > > dbharrington@comcast.net > > > >> -----Original Message----- > >> From: syslog-bounces@lists.ietf.org > >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > >> Sent: Thursday, October 20, 2005 9:51 AM > >> To: syslog@ietf.org > >> Subject: [Syslog] TCP and SSH Discussion > >> > >> Hi, > >> > >> Our charter says: > >> > >> At a minimum this group will address providing > >> authenticity, integrity > >> and confidentiality of Syslog messages as they traverse > >> the network. > >> > >> If the WG feels that an SSH transport will accomplish this > >> goal, and it > >> will be used, then I'm open to having that discussion. I > >> don't feel that > >> documenting current tcp transports works towards that goal. > >> I've heard a > >> few voices say that they would support an SSH transport on > >> the mailing > >> list. Does anyone object or have a differing view? (We will > >> have this as > >> a topic in Vancouver as well.) If we agree to move forward > >> with this then > >> we will need someone to write the document. Volunteers? > >> > >> We do have BEEP as a transport and I've received some email > >> from a few > >> people saying that they are using both the RAW and COOKED > >> modes. Can I > >> get someone who has implemented it to update RFC 3195? > >> > >> Thanks, > >> Chris > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 10:54:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyHp-0003Ns-R9; Fri, 21 Oct 2005 10:54:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyHo-0003N7-8o for syslog@megatron.ietf.org; Fri, 21 Oct 2005 10:54:24 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26340 for ; Fri, 21 Oct 2005 10:54:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 848FB27C029 for ; Fri, 21 Oct 2005 16:52:12 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04206-10 for ; Fri, 21 Oct 2005 16:52:12 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2348F27C018 for ; Fri, 21 Oct 2005 16:52:12 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 16:53:28 +0200 Subject: RE: [Syslog] TCP and SSH Discussion - where are we heading to? Date: Fri, 21 Oct 2005 16:53:14 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3C8D@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Thread-Topic: [Syslog] TCP and SSH Discussion - where are we heading to? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcXWPUuqj9TT8bGLT6ehIcfJiG0uawAD+2/Q From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Oct 2005 14:53:28.0438 (UTC) FILETIME=[3249B960:01C5D64F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris,=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Are you volunteering to write? :) I think we are not yet in a position we have something to write. I know that you probably did not mean to start anything right now, but let me use this message as a tool to voice my concerns. Over the past months (years), we've done some good work in evolving syslog. However, RFC 3195 is having a very hard time among implementors and our last efforts on protocol have received very limited feedback from the operator/end user camp. On the other hand, I know that there *is* vital interest in syslog. It's easy to judge this by the interest new implementations receive from the user base and also by the number of deployments of syslog tools. Obviously, end-users tend to be interested more in the actual software tools than in protocols. But the low implementor participation and end-user adoption rate is raising a very important question to me: are we still heading into the right direction? What does it help if we create better and better standards (assumed they are, which is obviously arguable) but nobody cares? In practice, mostly non-official-standard solutions are being asked form, developed and deployed. For example, I will begin to implement plain tcp syslog with ssl encryption shortly. Not because it is so secure or reliable - simply because there is so much demand for it. Current approaches typically use plain tcp syslog together with stunnel (which, by the way, is valid solution for many needs). May be it is just me feeling some asynchronicity between what the field is asking for and what we are doing. If so, I would suggest that we try to obtain some broader feedback from operators and implementors before going any further with new standards. If there is a sufficiently large group of operators (maybe "just" in terms of purchasing power) asking for some new protocol (or protocol versions), we can probably make the implementors implement them. Currently, I honestly feel it very hard to provide business reasoning for creating something new... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 12:07:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzQb-0005pH-DA; Fri, 21 Oct 2005 12:07:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzQZ-0005pC-TS for syslog@megatron.ietf.org; Fri, 21 Oct 2005 12:07:32 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15612 for ; Fri, 21 Oct 2005 12:07:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6606827C029 for ; Fri, 21 Oct 2005 18:05:23 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06558-01 for ; Fri, 21 Oct 2005 18:05:23 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 22FDD27C018 for ; Fri, 21 Oct 2005 18:05:23 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 18:06:35 +0200 Date: Fri, 21 Oct 2005 18:06:06 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3C97@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Thread-Topic: slightly off-topic: new rfc3195 implementation list X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcXWWVgTLdX28JNwTtSh6JFzaQS0Lw== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Oct 2005 16:06:35.0643 (UTC) FILETIME=[694414B0:01C5D659] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] slightly off-topic: new rfc3195 implementation list X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, I know this is slightly off-topic, but hopefully tolerable. Based on the many discussions I had recently about RFC 3195, I have decided to set up a mailing list specifically for implemtnatations. The list charter is as follows: ### The rfc3195 list is targeted towards people interested in RFC 3195-based solutions. It is primarily aimed at implementors, protocol-designers and operators who would like to have insight into the protocol and the various implementations. It carries deeply technical content about protocol interpretations, interoperability of different RFC 3195-based solutions, and discussion about the future of RFC 3195. It also covers news and annoucement about RFC 3195-related projects and products. These items should not be marketingish but rather help inform the community of new arrivals and other important events. ### Please note that the list is actually targeted at getting rfc3195 up in running *in practice*. It is not a place to design the next evolution of it (obviously, this is the syslog-sec IETF list). Subscription information is available at http://lists.adiscon.net/mailman/listinfo/rfc3195 I hope this is a useful tool for this WG, too. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 15:54:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2y7-0006A1-JK; Fri, 21 Oct 2005 15:54:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2uC-0003xa-Ig; Fri, 21 Oct 2005 15:50:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00173; Fri, 21 Oct 2005 15:50:09 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET36B-0004ZD-EF; Fri, 21 Oct 2005 16:02:47 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tv-0001Ip-G3; Fri, 21 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-15.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-15.txt Pages : 48 Date : 2005-10-21 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. The layered architecture also provides a solid basis that allows code to be written once instead of multiple times, once for each syslog feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-21153332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21153332.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Fri Oct 21 22:49:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET9Rs-00066r-T4; Fri, 21 Oct 2005 22:49:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET9Rr-00066S-4J for syslog@megatron.ietf.org; Fri, 21 Oct 2005 22:49:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13321 for ; Fri, 21 Oct 2005 22:49:18 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET9e5-0003i1-3D for syslog@ietf.org; Fri, 21 Oct 2005 23:02:10 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9M2n9oB024193; Sat, 22 Oct 2005 12:49:09 +1000 (EST) From: Darren Reed Message-Id: <200510220248.j9M2mk4U022298@firewall.reed.wattle.id.au> Subject: Re: [Syslog] TCP and SSH Discussion In-Reply-To: To: Chris Lonvick Date: Sat, 22 Oct 2005 12:48:46 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi Darren, > > It's not "syslog/udp/ssh" nor "syslog/tcp/ssh", it's going to be > "syslog/ssh/tcp/ip". syslog will be a defined subsystem for SSH much like > sftp and netconf. Oh! Hmmm. Do you have any links to critiques about sftp ? I've spoken to at least one person recently (but I can't recall *who*) that wasn't too impressed with sftp, so I'm curious if there is anything substantial that discusses its drawbacks and what lessons (if any) need to be learnt from it. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 23:10:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET9lu-0003Kd-63; Fri, 21 Oct 2005 23:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET9ls-0003KY-S3 for syslog@megatron.ietf.org; Fri, 21 Oct 2005 23:10:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14045 for ; Fri, 21 Oct 2005 23:10:01 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET9y7-0004IM-Md for syslog@ietf.org; Fri, 21 Oct 2005 23:22:53 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9M39tG9027069; Sat, 22 Oct 2005 13:09:55 +1000 (EST) From: Darren Reed Message-Id: <200510220309.j9M39ofN022718@firewall.reed.wattle.id.au> Subject: Re: [Syslog] TCP and SSH Discussion - where are we heading to? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3C8D@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Sat, 22 Oct 2005 13:09:50 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org .. > But the low implementor participation and end-user adoption rate is > raising a very important question to me: are we still heading into the > right direction? What does it help if we create better and better > standards (assumed they are, which is obviously arguable) but nobody > cares? In practice, mostly non-official-standard solutions are being > asked form, developed and deployed. For example, I will begin to > implement plain tcp syslog with ssl encryption shortly. Not because it > is so secure or reliable - simply because there is so much demand for > it. Current approaches typically use plain tcp syslog together with > stunnel (which, by the way, is valid solution for many needs). Right. This is close to the approach I took, over 5 years ago now, that started this off. I wasn't happy with the unbounded record problem you have with TCP and so added a small header to mark the start of messages. This was more just for the sake of doing it than any market driver(s). > May be it is just me feeling some asynchronicity between what the field > is asking for and what we are doing. I think there has been too little feedback to this group and research done by this group about how syslog is evolving "out there". If someone is deploying a syslog using TCP solution, what are they likely to do? My bet is pick one software bundle and use it everywhere they can. For the most part, this is going to be of most signifance to Linux people. If you're using AIX, HP-UX or Solaris, chances are you don't have the freedom to upgrade/replace syslogd so you're stuck using UDP. If you're using various pieces of network equipment, I'm willing to bet people use syslog/udp because that is what everyone does & understands, removing problem of interoperable syslog/tcp implementations. If you were a commercial Un*x vendor, what would it take you to want to spend $$ on replacing your in-house syslogd? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 21 23:17:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET9t8-00019O-1t; Fri, 21 Oct 2005 23:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET9t5-00016L-SA for syslog@megatron.ietf.org; Fri, 21 Oct 2005 23:17:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14405 for ; Fri, 21 Oct 2005 23:17:28 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETA5L-0004Xz-Ro for syslog@ietf.org; Fri, 21 Oct 2005 23:30:20 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9M3HYsM026427; Sat, 22 Oct 2005 13:17:34 +1000 (EST) From: Darren Reed Message-Id: <200510220317.j9M3HNui022224@firewall.reed.wattle.id.au> Subject: Re: [Syslog] plain tcp syslog In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122A44B88@xmb-rtp-20d.amer.cisco.com> To: "Anton Okmianski (aokmians)" Date: Sat, 22 Oct 2005 13:17:23 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Darren: > > Well... You say all of Cisco devices "were RFC 3164 compliant". > This illustrates my point. What exactly does this compliance mean? That the device delivers an ASCII text message that can be easily read and understood, without any translation tools, by someone familiar with the product. > My point is that any product can legitimately claim compliance with > RFC 3164 and this claim has zero practical usefulness! I don't know > what that compliance means, if RFC 3164 says in Sec 4.2: > > "There are no set requirements on the contents of the syslog packet as > it is originally sent from a device. It should be reiterated here that > the payload of any IP packet destined to UDP port 514 MUST be considered > to be a valid syslog message." Right, so that's way too loose, but is it like that because some devices do not implement the header with the priority, etc ? > Now, one may argue that we could make a more strict informational RFC > than RFC 3164. But if we can do an RFC with strict requirements - then > make it a standard. I think it is a better investment of WG resources. > But obviously consensus opinion rules. Maybe we need to say "RFC 3164 documents the past but this new RFC is the document that defines syslog/udp for the future" ? If we did that, just rewrote section 4.2 so that it required the header, rather than left it open, it would be minimal effort for establishing a new RFC to define a proposed BSD syslog/UDp standard. Is there any reason why we wouldn't want to do that? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Oct 22 03:36:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETDvC-0002sk-8f; Sat, 22 Oct 2005 03:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETDvA-0002sc-2d for syslog@megatron.ietf.org; Sat, 22 Oct 2005 03:36:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24199 for ; Sat, 22 Oct 2005 03:35:52 -0400 (EDT) Received: from rot13.romab.com ([194.52.231.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETE7R-0003y5-GK for syslog@ietf.org; Sat, 22 Oct 2005 03:48:47 -0400 Received: by rot13.romab.com (Postfix, from userid 30002) id CF40F29D62E; Sat, 22 Oct 2005 09:35:38 +0200 (CEST) Received: from [127.0.0.1] (rot13.romab.com [194.52.231.20]) by rot13.romab.com (Postfix) with ESMTP id 5D1C329D3B6 for ; Sat, 22 Oct 2005 09:35:34 +0200 (CEST) Message-ID: <4359EBF1.8070505@romab.com> Date: Sat, 22 Oct 2005 09:36:17 +0200 From: Robert Malmgren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] TCP and SSH Discussion - where are we heading to? References: <200510220309.j9M39ofN022718@firewall.reed.wattle.id.au> In-Reply-To: <200510220309.j9M39ofN022718@firewall.reed.wattle.id.au> X-Enigmail-Version: 0.93.0.0 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on rot13.romab.com X-Spam-Status: No, score=-5.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: , Content-Type: multipart/mixed; boundary="===============0336932833==" Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0336932833== Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig16AF529110D3F8AECC9FD0AC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16AF529110D3F8AECC9FD0AC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Darren Reed wrote: > .. > [snip] > I think there has been too little feedback to this group and research done > by this group about how syslog is evolving "out there". > > If someone is deploying a syslog using TCP solution, what are they likely > to do? My bet is pick one software bundle and use it everywhere they can. > For the most part, this is going to be of most signifance to Linux people. > If you're using AIX, HP-UX or Solaris, chances are you don't have the > freedom to upgrade/replace syslogd so you're stuck using UDP. > If you're using various pieces of network equipment, I'm willing to bet > people use syslog/udp because that is what everyone does & understands, > removing problem of interoperable syslog/tcp implementations. > In general, I think that you're right. > If you were a commercial Un*x vendor, what would it take you to want to > spend $$ on replacing your in-house syslogd? > Customer preasure? A couple of ways of creating this customer preasure could be * Writing some best practise documents on the topic. * Writing an attack tree description on the different versions of the syslog protocols. Tina Bird's material, http://www.seclib.com/seclib/ids.general/syslog-attack-sigs.pdf, could be a good starting point for a best practise material? Another thing I think we must have in mind is the possibility that the "market" for network logging might become proprietary, since it is rumored that Microsoft is cooking some solution for enterprise logging. > Darren > --Robert > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog --------------enig16AF529110D3F8AECC9FD0AC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDWev3BDL0PDfjxw0RA6i5AJ9EH5gaBxmlMEurjLMKTLgJdDrf9wCffN/E R/mGgHTrIYRlmudv3Mh6dNU= =/eHf -----END PGP SIGNATURE----- --------------enig16AF529110D3F8AECC9FD0AC-- --===============0336932833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --===============0336932833==-- From syslog-bounces@lists.ietf.org Sun Oct 23 21:02:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqjb-0002jy-0j; Sun, 23 Oct 2005 21:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqjZ-0002jZ-Ta for syslog@megatron.ietf.org; Sun, 23 Oct 2005 21:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04379 for ; Sun, 23 Oct 2005 21:02:28 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETqwE-0005Dk-O9 for syslog@ietf.org; Sun, 23 Oct 2005 21:15:47 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 23 Oct 2005 18:02:31 -0700 X-IronPort-AV: i="3.97,243,1125903600"; d="scan'208"; a="223039816:sNHT25675276" 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 j9O12Tuc022072; Sun, 23 Oct 2005 18:02:30 -0700 (PDT) Date: Sun, 23 Oct 2005 18:02:29 -0700 (PDT) From: Chris Lonvick To: David B Harrington Subject: RE: [Syslog] TCP and SSH Discussion In-Reply-To: <4c9fgf$3ljfe2@sj-inbound-d.cisco.com> Message-ID: References: <4c9fgf$3ljfe2@sj-inbound-d.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi David, Check with Eliot and Bill Sommerfeld. Perhaps opsra should take it on themselves as it crosses so many boundaries. Later, Chris On Fri, 21 Oct 2005, David B Harrington wrote: > Hi Chris, > > Do you think "callhome" should be done in the SecSH WG, or should it > be done as part of the syslog WG transport mapping? > > It seems to me it is a type of SSH transport negotiation, not part of > syslog or snmp or netconf (although they might be affected by a > reversed asymmetry of authentication). > > David Harrington > dbharrington@comcast.net > >> -----Original Message----- >> From: Chris Lonvick [mailto:clonvick@cisco.com] >> Sent: Friday, October 21, 2005 8:48 AM >> To: David B Harrington >> Cc: syslog@ietf.org >> Subject: RE: [Syslog] TCP and SSH Discussion >> >> Hi David, >> >> I'd also recommend that people look at the current thoughts on "call > >> home". >> >> http://www.ietf.org/internet-drafts/draft-lear-callhome-descri >> ption-03.txt >> >> Thanks, >> Chris >> >> On Thu, 20 Oct 2005, David B Harrington wrote: >> >>> Hi, >>> >>> For a discussion of syslog over SSH, I recommend people read the >>> documents for other IETF network management protocols that >> plan to run >>> over SSH: >>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-05.txt > and >>> > http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-00.txt >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-00.txt > also >>> deals with some issues related to moving a management protocol > from >>> UDP to TCP and sessions (but mostly is about backwards > compatibility >>> with the SNMPv3 architecture and access control). >>> >>> David Harrington >>> dbharrington@comcast.net >>> >>>> -----Original Message----- >>>> From: syslog-bounces@lists.ietf.org >>>> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick >>>> Sent: Thursday, October 20, 2005 9:51 AM >>>> To: syslog@ietf.org >>>> Subject: [Syslog] TCP and SSH Discussion >>>> >>>> Hi, >>>> >>>> Our charter says: >>>> >>>> At a minimum this group will address providing >>>> authenticity, integrity >>>> and confidentiality of Syslog messages as they traverse >>>> the network. >>>> >>>> If the WG feels that an SSH transport will accomplish this >>>> goal, and it >>>> will be used, then I'm open to having that discussion. I >>>> don't feel that >>>> documenting current tcp transports works towards that goal. >>>> I've heard a >>>> few voices say that they would support an SSH transport on >>>> the mailing >>>> list. Does anyone object or have a differing view? (We will >>>> have this as >>>> a topic in Vancouver as well.) If we agree to move forward >>>> with this then >>>> we will need someone to write the document. Volunteers? >>>> >>>> We do have BEEP as a transport and I've received some email >>>> from a few >>>> people saying that they are using both the RAW and COOKED >>>> modes. Can I >>>> get someone who has implemented it to update RFC 3195? >>>> >>>> Thanks, >>>> Chris >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>> >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Oct 23 21:02:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqjr-0002qs-9r; Sun, 23 Oct 2005 21:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqjp-0002pY-OE for syslog@megatron.ietf.org; Sun, 23 Oct 2005 21:02:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04388 for ; Sun, 23 Oct 2005 21:02:44 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETqwT-0005E8-Cv for syslog@ietf.org; Sun, 23 Oct 2005 21:16:02 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 23 Oct 2005 18:02:48 -0700 X-IronPort-AV: i="3.97,243,1125903600"; d="scan'208"; a="668497082:sNHT22754596" 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 j9O12iJi017043; Sun, 23 Oct 2005 18:02:45 -0700 (PDT) Date: Sun, 23 Oct 2005 18:02:44 -0700 (PDT) From: Chris Lonvick To: Darren Reed Subject: Re: [Syslog] TCP and SSH Discussion In-Reply-To: <200510220248.j9M2mk4U022298@firewall.reed.wattle.id.au> Message-ID: References: <200510220248.j9M2mk4U022298@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Darren, On Sat, 22 Oct 2005, Darren Reed wrote: >> Hi Darren, >> >> It's not "syslog/udp/ssh" nor "syslog/tcp/ssh", it's going to be >> "syslog/ssh/tcp/ip". syslog will be a defined subsystem for SSH much like >> sftp and netconf. > > Oh! Hmmm. > > Do you have any links to critiques about sftp ? The secsh wg mailing list. ;) ftp://ftp.ietf.org/ietf-mail-archive/secsh/ > > I've spoken to at least one person recently (but I can't recall *who*) > that wasn't too impressed with sftp, so I'm curious if there is anything > substantial that discusses its drawbacks and what lessons (if any) need > to be learnt from it. Joseph Galbriath has offered to have a bar-bof to discuss sftp. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Oct 23 21:03:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqkR-0002vs-Iu; Sun, 23 Oct 2005 21:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETqkQ-0002vn-Go for syslog@megatron.ietf.org; Sun, 23 Oct 2005 21:03:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04398 for ; Sun, 23 Oct 2005 21:03:20 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETqx4-0005Eh-5h for syslog@ietf.org; Sun, 23 Oct 2005 21:16:39 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Oct 2005 18:03:24 -0700 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 j9O13GJi017155; Sun, 23 Oct 2005 18:03:22 -0700 (PDT) Date: Sun, 23 Oct 2005 18:03:16 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] TCP and SSH Discussion - where are we heading to? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3C8D@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3C8D@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, On Fri, 21 Oct 2005, Rainer Gerhards wrote: > Chris, > >> -----Original Message----- >> From: syslog-bounces@lists.ietf.org >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > >> Are you volunteering to write? :) > > I think we are not yet in a position we have something to write. I know > that you probably did not mean to start anything right now, but let me > use this message as a tool to voice my concerns. > > Over the past months (years), we've done some good work in evolving > syslog. However, RFC 3195 is having a very hard time among implementors > and our last efforts on protocol have received very limited feedback > from the operator/end user camp. On the other hand, I know that there > *is* vital interest in syslog. It's easy to judge this by the interest > new implementations receive from the user base and also by the number of > deployments of syslog tools. Obviously, end-users tend to be interested > more in the actual software tools than in protocols. > > But the low implementor participation and end-user adoption rate is > raising a very important question to me: are we still heading into the > right direction? What does it help if we create better and better > standards (assumed they are, which is obviously arguable) but nobody > cares? In practice, mostly non-official-standard solutions are being > asked form, developed and deployed. For example, I will begin to > implement plain tcp syslog with ssl encryption shortly. Not because it > is so secure or reliable - simply because there is so much demand for > it. Current approaches typically use plain tcp syslog together with > stunnel (which, by the way, is valid solution for many needs). > > May be it is just me feeling some asynchronicity between what the field > is asking for and what we are doing. > > If so, I would suggest that we try to obtain some broader feedback from > operators and implementors before going any further with new standards. > If there is a sufficiently large group of operators (maybe "just" in > terms of purchasing power) asking for some new protocol (or protocol > versions), we can probably make the implementors implement them. > Currently, I honestly feel it very hard to provide business reasoning > for creating something new... Very good points. I've gotten a few separate emails asking if this is the right direction. I'll raise this discussion in a new thread on the mailing list. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 24 09:04:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU204-00035V-Vc; Mon, 24 Oct 2005 09:04:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU204-00035K-2D for syslog@megatron.ietf.org; Mon, 24 Oct 2005 09:04:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08335 for ; Mon, 24 Oct 2005 09:04:13 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU2Cn-0002oX-Rd for syslog@ietf.org; Mon, 24 Oct 2005 09:17:39 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2005 06:04:15 -0700 X-IronPort-AV: i="3.97,244,1125903600"; d="scan'208"; a="355889267:sNHT22506948" 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 j9OD4Duc025261 for ; Mon, 24 Oct 2005 06:04:14 -0700 (PDT) Date: Mon, 24 Oct 2005 06:04:13 -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: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Syslog] Secure substrate - need your input X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Folks, I'll be asking this in Vancouver but would like to get some input from the mailing list. Our charter says that we will develop a secure method to transport syslog messages. We have BEEP (RFC 3195) but it has a low implementation record. Other groups have specified BEEP as well but are also moving along towards using SSH or SSL. 1) What secure substrate should the WG look towards: __ ssl __ ssh __ dtls http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt __ other 2) Why? Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 24 09:05:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU213-0003MA-9v; Mon, 24 Oct 2005 09:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU211-0003Ly-PC for syslog@megatron.ietf.org; Mon, 24 Oct 2005 09:05:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08473 for ; Mon, 24 Oct 2005 09:05:13 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU2Dl-0002tx-Kz for syslog@ietf.org; Mon, 24 Oct 2005 09:18:38 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2005 06:05:17 -0700 X-IronPort-AV: i="3.97,244,1125903600"; d="scan'208"; a="355889453:sNHT23670480" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9OD5F95021066 for ; Mon, 24 Oct 2005 06:05:16 -0700 (PDT) Date: Mon, 24 Oct 2005 06:05:15 -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: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Syslog] syslog-protocol - is it going to be used? X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Folks, >From the notes I've been getting and the recent discussion on the mailing list, I'd like to ask for a sanity check. 1) Will you (or your organization) be transmitting or receiving syslog messages using syslog-protocol as described in the most recent ID? I got few positive responses the last time I asked this so I'm going to ask some questions that I hope will be more directed towards the people who are either not going to implement, or who are sitting on the fence. 2) If you are not going to implement, would you consider doing something that would have less of an impact on current transmitters and receivers? (Such as keeping the start of the syslog message as "..." rather than "1 888 4 00 ..." .) 3) Do you like the TIMESTAMP as defined in the current syslog-protocol ID? 4) Do you like the idea of using "structured data" as is currently described in syslog-protocol? Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 24 12:43:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5Q5-000530-P7; Mon, 24 Oct 2005 12:43:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5Q3-000506-SS for syslog@megatron.ietf.org; Mon, 24 Oct 2005 12:43:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19716 for ; Mon, 24 Oct 2005 12:43:16 -0400 (EDT) Received: from yancy.pkiclue.com ([209.172.115.117] helo=yancy.b70.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU5cl-0001dC-BH for syslog@ietf.org; Mon, 24 Oct 2005 12:56:42 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by yancy.b70.net (8.9.3/8.9.3) with ESMTP id JAA24189 for ; Mon, 24 Oct 2005 09:46:26 -0700 Message-ID: <435D0F16.3020501@canola-jones.com> Date: Mon, 24 Oct 2005 09:43:02 -0700 From: Rodney Thayer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Secure substrate - need your input References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris Lonvick wrote: > Hi Folks, > > I'll be asking this in Vancouver but would like to get some input from > the mailing list. > > Our charter says that we will develop a secure method to transport > syslog messages. We have BEEP (RFC 3195) but it has a low > implementation record. Other groups have specified BEEP as well but are > also moving along towards using SSH or SSL. > > > 1) What secure substrate should the WG look towards: you should never add a new substrate. The IETF re-invents things way too often. Any proposal should be required to justify not using some pre-existing scheme (TLS, SSH, IPSec, whatever) > > 2) Why? Because it's hard enough to get vendors to implement this stuff and if they already have one or more security mechanisms implemented it's architecturally irresponsible to ask them to add another one without a significant amount of justification. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 08:41:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUO7q-0006Vh-QE; Tue, 25 Oct 2005 08:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUO7o-0006Vc-Q2 for syslog@megatron.ietf.org; Tue, 25 Oct 2005 08:41:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14026 for ; Tue, 25 Oct 2005 08:41:42 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUOKk-0001IZ-Uk for syslog@ietf.org; Tue, 25 Oct 2005 08:55:20 -0400 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by mx2.foretec.com with esmtp (Exim 4.24) id 1EUNCR-0003H0-C7 for syslog@ietf.org; Tue, 25 Oct 2005 07:42:39 -0400 Received: from pc6 (1Cust252.tnt30.lnd3.gbr.da.uu.net [62.188.122.252]) by blaster.systems.pipex.net (Postfix) with SMTP id 08D87E0004AF; Tue, 25 Oct 2005 12:38:46 +0100 (BST) Message-ID: <094e01c5d950$2678f700$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Secure substrate - need your input Date: Tue, 25 Oct 2005 12:31:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ---- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, October 24, 2005 3:04 PM Subject: [Syslog] Secure substrate - need your input > I'll be asking this in Vancouver but would like to get some input from the > mailing list. > > Our charter says that we will develop a secure method to transport syslog > messages. We have BEEP (RFC 3195) but it has a low implementation record. > Other groups have specified BEEP as well but are also moving along towards > using SSH or SSL. > > 1) What secure substrate should the WG look towards: > __ ssl > __ ssh > __ dtls http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > __ other > > 2) Why? > SSH; before the isms WG came into existence, there was a survey of operators to find why SNMPv3 security was unacceptable and that showed that the most used security was ssh; tls did not figure. This makes sense to me as SSH is widely used with telnet to control remote network devices - I do not see much (d)tls in this area. And, after due deliberation, netconf chose SSH. Having it in use by three working groups in the operations area seems the right thing. Downside is the use of a reliable transport, in practice TCP, which then brings a load of unnecessary baggage (mmm I think the IETF is missing a few transport protocol options). dtls sounds fine, and if it is in widespread use in five years time in this environment, then it would have been the right choice but at present, it is a gamble which I do not want to take. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 11:11:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQSI-00069A-Qi; Tue, 25 Oct 2005 11:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQSG-00066x-DT for syslog@megatron.ietf.org; Tue, 25 Oct 2005 11:11:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28076 for ; Tue, 25 Oct 2005 11:10:57 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUQf8-0007PL-VS for syslog@ietf.org; Tue, 25 Oct 2005 11:24:33 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2005 11:10:55 -0400 X-IronPort-AV: i="3.97,250,1125892800"; d="scan'208"; a="74371409:sNHT24415708" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9PF9MEq015305 for ; Tue, 25 Oct 2005 11:10:53 -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); Tue, 25 Oct 2005 11:10:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Secure substrate - need your input Date: Tue, 25 Oct 2005 11:10:48 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122A9ED50@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Secure substrate - need your input Thread-Index: AcXYm6PlIJcQihn6QSyHoslTKsOFaAA16vDg From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 25 Oct 2005 15:10:48.0960 (UTC) FILETIME=[4823C800:01C5D976] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi Folks, >=20 > I'll be asking this in Vancouver but would like to get some=20 > input from the mailing list. >=20 > Our charter says that we will develop a secure method to=20 > transport syslog messages. We have BEEP (RFC 3195) but it=20 > has a low implementation record.=20 > Other groups have specified BEEP as well but are also moving=20 > along towards using SSH or SSL. >=20 >=20 > 1) What secure substrate should the WG look towards: >=20 > __ ssl >=20 > __ ssh >=20 > __ dtls =20 > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt >=20 > __ other I believe it should be SSL 3.0 / TLS 1.0. At least in web-server farm = environments, you got SSL everywhere with a bunch of SSL accelerator = hardware already in place. =20 I also think several mappings can be defined. I am not a fan of options = when it comes to standards, but allowing syslog over any kind of secure = transport is a good thing. This was the whole idea of separating = syslog-protocol from syslog-transport. Frankly, I don't think it will = be a lot of work to define those transport mappings. =20 > 2) Why? SSL/TLS is the most widely deployed network security protocol today. All = e-commerce happens over it. Dozens of companies provide all shapes and = forms of SSL accelerators. Many routers now have SSL accelartor modules. = =20 If I need to manage a large environment of servers where distributed = logging really makes sense, being able to re-use existing infrastructure = for scaling really helps. A search for "SSH accelerator" on google does = not reveal anything interesting, but "SSL accelarator" shows up with a = bunch of listings, several of which claim thousands of new SSL sessions = per second. This confirms my experience. BTW, with SSL session caching, = accelerators (ie. load balancers) can do 100,000 connections per second = and more. So, to scale syslog over SSH would I have to wait for SSH = accelerators to come to market? I see that there is a lot of work around SSH connection protocol and its = potential use in new protocols. I have not followed these developments. = There must have been a good reason for it. I would like to understand = why people object to SSL, which is a well established technology. Any = pointers? Thanks, Anton. >=20 >=20 >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 11:39:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQtL-0005Xh-4Y; Tue, 25 Oct 2005 11:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQtJ-0005XV-4s for syslog@megatron.ietf.org; Tue, 25 Oct 2005 11:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00199 for ; Tue, 25 Oct 2005 11:38:52 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUR6D-0008Ow-9g for syslog@ietf.org; Tue, 25 Oct 2005 11:52:33 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9PFcKq5017637; Wed, 26 Oct 2005 01:38:20 +1000 (EST) From: Darren Reed Message-Id: <200510251538.j9PFcELZ019409@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Secure substrate - need your input In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122A9ED50@xmb-rtp-20d.amer.cisco.com> To: "Anton Okmianski (aokmians)" Date: Wed, 26 Oct 2005 01:38:14 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > > 1) What secure substrate should the WG look towards: > > > > __ ssl > > > > __ ssh > > > > __ dtls > > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > > > __ other > > I believe it should be SSL 3.0 / TLS 1.0. I agree and for all the reasons you said. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 13:36:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSjD-0003E8-5W; Tue, 25 Oct 2005 13:36:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSj8-0003Ds-JM for syslog@megatron.ietf.org; Tue, 25 Oct 2005 13:36:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07726 for ; Tue, 25 Oct 2005 13:36:32 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSw7-0003hE-Nc for syslog@ietf.org; Tue, 25 Oct 2005 13:50:13 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2005102517363301400sh953e>; Tue, 25 Oct 2005 17:36:33 +0000 From: "David B Harrington" To: "'Anton Okmianski \(aokmians\)'" , "'Chris Lonvick \(clonvick\)'" , Subject: RE: [Syslog] Secure substrate - need your input Date: Tue, 25 Oct 2005 13:36:25 -0400 Message-ID: <004401c5d98a$a1fe29b0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXYm6PlIJcQihn6QSyHoslTKsOFaAA16vDgAAVq6mA= In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122A9ED50@xmb-rtp-20d.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > I see that there is a lot of work around SSH connection > protocol and its potential use in new protocols. I have not > followed these developments. There must have been a good > reason for it. I would like to understand why people object > to SSL, which is a well established technology. Any pointers? I agree that SSL is widely deployed, especially for e-commerce. Nobody has objected to SSL. In many ways, the ISMS decision was 6-of-one, half-dozen of the other - so ISMS picked the one that Netconf had chosen. ISMS chose SSH to work on first; there is nothing that precludes also developing a transport mapping security model for SSL, except the desire to limit standards options to improve interoperability, and volunteer manpower. The ISMS and Netconf WGs chose SSH because it is widely used by operators to perform management tasks, there was a Netconf draft that could be adapted for ISMS usage, and having "balanced" security across management inetrfaces makes sense. If CLI, Netconf, and SNMP run over SSH, and syslog runs over SSL, that may make it harder to ensure that the security characteristics of the four management interfaces are equivalent. Netconf wants to add notifications, and I believe they are considering trying to use syslog as their notification approach. That might be easier if syslog worked over the same secure transport as Netconf. David Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 13:48:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSur-0007gN-Fh; Tue, 25 Oct 2005 13:48:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSup-0007fZ-TG for syslog@megatron.ietf.org; Tue, 25 Oct 2005 13:48:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08584 for ; Tue, 25 Oct 2005 13:48:37 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUT7p-00046w-Rm for syslog@ietf.org; Tue, 25 Oct 2005 14:02:18 -0400 Received: from pc6 (1Cust251.tnt5.lnd4.gbr.da.uu.net [62.188.134.251]) by blaster.systems.pipex.net (Postfix) with SMTP id 230BCE0000C5; Tue, 25 Oct 2005 18:48:32 +0100 (BST) Message-ID: <0e5801c5d983$c717dc20$0601a8c0@pc6> From: "Tom Petch" To: "Anton Okmianski (aokmians)" , "Chris Lonvick (clonvick)" , References: <98AE08B66FAD1742BED6CB9522B73122A9ED50@xmb-rtp-20d.amer.cisco.com> Subject: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Tue, 25 Oct 2005 18:39:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org In the context of isms, ie SNMP, the choice was SSH v TLS + SASL; TLS provides the security but not the authentication while SSH does both. And SSH is a well-established protocol. I agree that TLS/SSL is the most widely used but that is because more people access websites (securely) than access network devices. If you limit yourself to network operations of network devices, then it appears to be SSH a significant number TLS so small as to be invisible Tom Petch ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Chris Lonvick (clonvick)" ; Sent: Tuesday, October 25, 2005 5:10 PM Subject: RE: [Syslog] Secure substrate - need your input > Hi Folks, > > I'll be asking this in Vancouver but would like to get some > input from the mailing list. > > Our charter says that we will develop a secure method to > transport syslog messages. We have BEEP (RFC 3195) but it > has a low implementation record. > Other groups have specified BEEP as well but are also moving > along towards using SSH or SSL. > > > 1) What secure substrate should the WG look towards: > > __ ssl > > __ ssh > > __ dtls > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > __ other I believe it should be SSL 3.0 / TLS 1.0. At least in web-server farm environments, you got SSL everywhere with a bunch of SSL accelerator hardware already in place. I also think several mappings can be defined. I am not a fan of options when it comes to standards, but allowing syslog over any kind of secure transport is a good thing. This was the whole idea of separating syslog-protocol from syslog-transport. Frankly, I don't think it will be a lot of work to define those transport mappings. > 2) Why? SSL/TLS is the most widely deployed network security protocol today. All e-commerce happens over it. Dozens of companies provide all shapes and forms of SSL accelerators. Many routers now have SSL accelartor modules. If I need to manage a large environment of servers where distributed logging really makes sense, being able to re-use existing infrastructure for scaling really helps. A search for "SSH accelerator" on google does not reveal anything interesting, but "SSL accelarator" shows up with a bunch of listings, several of which claim thousands of new SSL sessions per second. This confirms my experience. BTW, with SSL session caching, accelerators (ie. load balancers) can do 100,000 connections per second and more. So, to scale syslog over SSH would I have to wait for SSH accelerators to come to market? I see that there is a lot of work around SSH connection protocol and its potential use in new protocols. I have not followed these developments. There must have been a good reason for it. I would like to understand why people object to SSL, which is a well established technology. Any pointers? Thanks, Anton. > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 17:04:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVyE-0006sc-DP; Tue, 25 Oct 2005 17:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVyD-0006rH-Dv for syslog@megatron.ietf.org; Tue, 25 Oct 2005 17:04:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14218 for ; Tue, 25 Oct 2005 17:04:18 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWBE-0001tb-Sd for syslog@ietf.org; Tue, 25 Oct 2005 17:18:01 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2005 14:04:22 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="223766795:sNHT26810616" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9PL4AV6027432; Tue, 25 Oct 2005 14:04:20 -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); Tue, 25 Oct 2005 17:04:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Tue, 25 Oct 2005 17:04:18 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122A9EF33@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Why not TLS was Re: [Syslog] Secure substrate - need your input Thread-Index: AcXZjGbh+ZwA8zXOSb6Vcyk4W/IN5gAEN4Fg From: "Anton Okmianski \(aokmians\)" To: "Tom Petch" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 25 Oct 2005 21:04:19.0110 (UTC) FILETIME=[AA5FD460:01C5D9A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom: TLS provides for asymmetric authentication. RFC 2264 Section 1: "The peer's identity can be authenticated using asymmetric, or public = key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This = authentication can be made optional, but is generally required for at = least one of the peers." SSL/TLS with server-side certs is pretty much a norm for all HTTPS = deployments. SSL/TLS with client-side certs are used less frequently, = but some organizations use those in mail clients. SMTP, IMAP, POP3 and = ACAP all have mappings to TLS transport (RFC2487, RFC 2595) with = commercial deployments. =20 I think the reason SASL comes into the picture with certain protocols = (like RFC 2595) is that TLS provides asymmetric authentication, and SASL = symmetric (based on passwords), which is preferred in some protocol like = mail for legacy reasons. =20 Not sure if SSH provides for symmetric auth for server (vs. user) = authentication. As far as I can tell from quick scan only asymmetric key = support is required in SSH draft (sec 4.1): http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/draft-ietf-secsh-a= rchitecture-23.txt I am not sure if support for symmetric keys (passwords) should be a = requirement, anyway. Maintaining a database of passwords instead of = public keys (in form of certs or other way) sounds like a security = threat, not to mention a choir when one could just maintain single root = CA (plus revocation lists if needed). Thoughts? Finally, I suspect mapping to SSH will take longer to develop and longer = to deploy because it will be dependent on SSH drafts (see above). =20 Thanks, Anton. =20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Tuesday, October 25, 2005 12:39 PM > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick);=20 > syslog@ietf.org > Subject: Why not TLS was Re: [Syslog] Secure substrate - need=20 > your input >=20 > In the context of isms, ie SNMP, the choice was SSH v TLS +=20 > SASL; TLS provides the security but not the authentication=20 > while SSH does both. And SSH is a well-established protocol. >=20 > I agree that TLS/SSL is the most widely used but that is=20 > because more people access websites (securely) than access=20 > network devices. If you limit yourself to network operations=20 > of network devices, then it appears to be SSH a significant=20 > number TLS so small as to be invisible >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Anton Okmianski (aokmians)" > To: "Chris Lonvick (clonvick)" ; > Sent: Tuesday, October 25, 2005 5:10 PM > Subject: RE: [Syslog] Secure substrate - need your input >=20 >=20 > > Hi Folks, > > > > I'll be asking this in Vancouver but would like to get some=20 > input from=20 > > the mailing list. > > > > Our charter says that we will develop a secure method to transport=20 > > syslog messages. We have BEEP (RFC 3195) but it has a low=20 > > implementation record. > > Other groups have specified BEEP as well but are also moving along=20 > > towards using SSH or SSL. > > > > > > 1) What secure substrate should the WG look towards: > > > > __ ssl > > > > __ ssh > > > > __ dtls > > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > > > __ other >=20 > I believe it should be SSL 3.0 / TLS 1.0. At least in=20 > web-server farm environments, you got SSL everywhere with a=20 > bunch of SSL accelerator hardware already in place. >=20 > I also think several mappings can be defined. I am not a fan=20 > of options when it comes to standards, but allowing syslog=20 > over any kind of secure transport is a good thing. This was=20 > the whole idea of separating syslog-protocol from=20 > syslog-transport. Frankly, I don't think it will be a lot of=20 > work to define those transport mappings. >=20 > > 2) Why? >=20 > SSL/TLS is the most widely deployed network security protocol=20 > today. All e-commerce happens over it. Dozens of companies=20 > provide all shapes and forms of SSL accelerators. Many=20 > routers now have SSL accelartor modules. >=20 > If I need to manage a large environment of servers where=20 > distributed logging really makes sense, being able to re-use=20 > existing infrastructure for scaling really helps. A search=20 > for "SSH accelerator" on google does not reveal anything=20 > interesting, but "SSL accelarator" shows up with a bunch of=20 > listings, several of which claim thousands of new SSL=20 > sessions per second. This confirms my experience. BTW, with=20 > SSL session caching, accelerators (ie. load balancers) can do=20 > 100,000 connections per second and more. So, to scale syslog=20 > over SSH would I have to wait for SSH accelerators to come to market? >=20 > I see that there is a lot of work around SSH connection=20 > protocol and its potential use in new protocols. I have not=20 > followed these developments. There must have been a good=20 > reason for it. I would like to understand why people object=20 > to SSL, which is a well established technology. Any pointers? >=20 > Thanks, > Anton. >=20 > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 17:47:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWdQ-00040t-8n; Tue, 25 Oct 2005 17:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWdO-0003zC-Fq for syslog@megatron.ietf.org; Tue, 25 Oct 2005 17:47:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16803 for ; Tue, 25 Oct 2005 17:46:51 -0400 (EDT) Received: from yancy.pkiclue.com ([209.172.115.117] helo=yancy.b70.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWqP-0003F4-OH for syslog@ietf.org; Tue, 25 Oct 2005 18:00:35 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by yancy.b70.net (8.9.3/8.9.3) with ESMTP id OAA01404 for ; Tue, 25 Oct 2005 14:50:07 -0700 Message-ID: <435EA7BF.2090308@canola-jones.com> Date: Tue, 25 Oct 2005 14:46:39 -0700 From: Rodney Thayer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input References: <98AE08B66FAD1742BED6CB9522B73122A9ED50@xmb-rtp-20d.amer.cisco.com> <0e5801c5d983$c717dc20$0601a8c0@pc6> In-Reply-To: <0e5801c5d983$c717dc20$0601a8c0@pc6> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom Petch wrote: > In the context of isms, ie SNMP, the choice was SSH v TLS + SASL; TLS provides > the security but not the authentication while SSH does both. And SSH is a > well-established protocol. > > I agree that TLS/SSL is the most widely used but that is because more people > access websites (securely) than access network devices. If you limit yourself > to network operations of network devices, then it appears to be > SSH a significant number > TLS so small as to be invisible A couple of comments - I disagree that TLS is rare. TLS is common, in my experience, because many devices have web-based management interfaces and those are secured with TLS. Also, if your logic were correct, then all those SASL folks who hassled us TLS people into going with STARTLS/SASL/etc must have been wrong - this is one of those "the IETF can't declare both 1 and 0 to be truth, depending on which RFC you read" problems. OTOH you are using SOME standard protocol so I'm fine with SSH... _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 17:57:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWnj-0008Dx-PD; Tue, 25 Oct 2005 17:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUWQH-0004DM-Cv for syslog@megatron.ietf.org; Tue, 25 Oct 2005 17:33:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16060 for ; Tue, 25 Oct 2005 17:33:17 -0400 (EDT) Received: from relay00.pair.com ([209.68.5.9] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUWdJ-0002pn-3M for syslog@ietf.org; Tue, 25 Oct 2005 17:47:01 -0400 Received: (qmail 40602 invoked from network); 25 Oct 2005 21:33:24 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 25 Oct 2005 21:33:24 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Anton Okmianski \(aokmians\)'" , "'Chris Lonvick \(clonvick\)'" , Subject: RE: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 10:33:17 +1300 Organization: Kiwi Enterprises Message-ID: <000801c5d9ab$b919adb0$d901a8c0@KiwiAndrew> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122A9ED50@xmb-rtp-20d.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 25 Oct 2005 17:57:47 -0400 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Good points Anton, My preference is also for using SSL/TLS. From an implementers point of = view, there is a good supply of SSL/TLS components and source code available = (both commercial and open source). This would make it easy for customers to = add secured syslog support to their apps. We currently use SSH in our secure syslog tunnel app, but could replace = it with SSL very easily. I heard that Rainer is going to add SSL support = soon as well. Please, no one suggest we try and run the secure protocol over UDP :-) = Let's keep to TCP as the transport for the secure/reliable protocol and keep = using UDP for the simple send and forget system. The idea is to make it as simple as possible for a programmer to make = his application/appliance send syslog messages. Grab an SSL library, choose = a socket stack and Bob's your mother's brother. I believe that one of the reasons that 3195 is so slow to take off is = that it is not easy to create an implementation from scratch. It is a lot = easier to just grab a UDP socket library and put at the start of each message. Simple is as simple does. Cheers Andrew -----Original Message----- From: syslog-bounces@lists.ietf.org = [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton Okmianski (aokmians) Sent: Wednesday, 26 October 2005 4:11 a.m. To: Chris Lonvick (clonvick); syslog@ietf.org Subject: RE: [Syslog] Secure substrate - need your input > Hi Folks, >=20 > I'll be asking this in Vancouver but would like to get some=20 > input from the mailing list. >=20 > Our charter says that we will develop a secure method to=20 > transport syslog messages. We have BEEP (RFC 3195) but it=20 > has a low implementation record.=20 > Other groups have specified BEEP as well but are also moving=20 > along towards using SSH or SSL. >=20 >=20 > 1) What secure substrate should the WG look towards: >=20 > __ ssl >=20 > __ ssh >=20 > __ dtls =20 > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt >=20 > __ other I believe it should be SSL 3.0 / TLS 1.0. At least in web-server farm environments, you got SSL everywhere with a bunch of SSL accelerator hardware already in place. =20 I also think several mappings can be defined. I am not a fan of options = when it comes to standards, but allowing syslog over any kind of secure = transport is a good thing. This was the whole idea of separating syslog-protocol = from syslog-transport. Frankly, I don't think it will be a lot of work to = define those transport mappings. =20 > 2) Why? SSL/TLS is the most widely deployed network security protocol today. All e-commerce happens over it. Dozens of companies provide all shapes and = forms of SSL accelerators. Many routers now have SSL accelartor modules. =20 If I need to manage a large environment of servers where distributed = logging really makes sense, being able to re-use existing infrastructure for = scaling really helps. A search for "SSH accelerator" on google does not reveal anything interesting, but "SSL accelarator" shows up with a bunch of listings, several of which claim thousands of new SSL sessions per = second. This confirms my experience. BTW, with SSL session caching, accelerators (ie. load balancers) can do 100,000 connections per second and more. So, = to scale syslog over SSH would I have to wait for SSH accelerators to come = to market? I see that there is a lot of work around SSH connection protocol and its potential use in new protocols. I have not followed these developments. There must have been a good reason for it. I would like to understand = why people object to SSL, which is a well established technology. Any = pointers? Thanks, Anton. >=20 >=20 >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 25 18:11:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUX1F-0001Y0-QL; Tue, 25 Oct 2005 18:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUX1E-0001Xv-Lz for syslog@megatron.ietf.org; Tue, 25 Oct 2005 18:11:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18433 for ; Tue, 25 Oct 2005 18:11:29 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUXEG-00044e-6l for syslog@ietf.org; Tue, 25 Oct 2005 18:25:13 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 25 Oct 2005 15:11:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9PMBJ98009489 for ; Tue, 25 Oct 2005 15:11:32 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 18:11:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] syslog-protocol - is it going to be used? Date: Tue, 25 Oct 2005 18:11:26 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122A9EF60@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] syslog-protocol - is it going to be used? Thread-Index: AcXYm93VxUxIPkbBQPy6MUg6Z3S0XABEplWA From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 25 Oct 2005 22:11:26.0539 (UTC) FILETIME=[0AE8B9B0:01C5D9B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > >From the notes I've been getting and the recent discussion on the=20 > >mailing > list, I'd like to ask for a sanity check. >=20 >=20 > 1) Will you (or your organization) be transmitting or=20 > receiving syslog messages using syslog-protocol as described=20 > in the most recent ID? I can't speak to any product road maps or any specifics, but let's just = say I have a suspicion that a certain large networking device = manufacturer will support syslog-protocol (sending) in majority of its = devices by 2006. :) You may not be hearing lots of feedback on who is implementing this = because not all companies like to issue press releases for things that = are in development and may get de-committed if project priorities = change. 3) Do you like the TIMESTAMP as defined in the current syslog-protocol=20 ID? Yes. 4) Do you like the idea of using "structured data" as is currently=20 described in syslog-protocol? Yes. A bit bulky names, but this concept is what's going to make this = protocol shine down the road IMO. Now, people would be able to write = *standard* log filters/viewers that can do meaningful things. Once = people pick up on using this to produce useful structured data in their = messages, I think it may change the whole logging landscape for the = better. Imagine being able to zero-in on specific flow, device, = transaction, component, message name, combination of them, etc. =20 Overall, I think this protocol is a great step forward. From no = standard at all to a great standard. Rainer has done a great job on = this! I am optimistic about this RFC.=20 Thanks, Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 05:06:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhET-0002zl-3X; Wed, 26 Oct 2005 05:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUhEO-0002zG-RI for syslog@megatron.ietf.org; Wed, 26 Oct 2005 05:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05477 for ; Wed, 26 Oct 2005 05:05:45 -0400 (EDT) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUhQV-0001vs-AK for syslog@ietf.org; Wed, 26 Oct 2005 05:19:35 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B025F27C02A for ; Wed, 26 Oct 2005 11:02:38 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19506-10 for ; Wed, 26 Oct 2005 11:02:38 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2AE5327C018 for ; Wed, 26 Oct 2005 11:02:38 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 11:04:28 +0200 Received: from adisconone ([172.19.2.14]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 11:04:27 +0200 Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input From: Rainer Gerhards To: syslog@ietf.org In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122A9EF33@xmb-rtp-20d.amer.cisco.com> References: <98AE08B66FAD1742BED6CB9522B73122A9EF33@xmb-rtp-20d.amer.cisco.com> Content-Type: text/plain Organization: Adiscon Message-Id: <1130317466.2195.41.camel@rh9lt.intern.adiscon.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 26 Oct 2005 11:04:27 +0200 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2005 09:04:27.0460 (UTC) FILETIME=[448ED040:01C5DA0C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I agree with Anton (both his initial comment and this one) and the others talking in favor of SSL/TLS. In addition, I would like to mention that in current practice, ssl/tls protected syslog solutions are *already* being deployed. This is possible thanks to the non-IETF-standard plain tcp syslog mode that is supported by so many of the major implementations. On top of that run either vendor-specific ssl/tls implementations or - most often - generic tunneling via stunnel. It is also not uncommon to authenticate the sender and client via certificates in ssl/tls (not only in theory, but in practice). So, I would also like to see a ssl/tls based approach - simply because we already see massive acceptance for it. I also agree on Anton's idea that creating a transport mapping for it is easy. HOWEVER, that brings us back to the issue of a "really stupid simple" tcp transmission mode. In my point of view, that would need to be defined first and then a ssl/tls mapping on top of it. Of course, it can be done in a single document, but I would prefer to have two small ones. My reasoning is that I think that would receive easier acceptance in the implementor community. Obviously, putting syslog in sync with netconf by using SSH is also desirable. I just doubt that this will become quickly implemented. If there is demand, we could add just another transport mapping. Sure, this means multiple choices and multiple effort required. But if we talk about effort, we must face reality: rfc 3195 is not being implemented that often because it is much more effort than plain tcp syslog - which provides nearly as good reliability. Current non-standard tcp syslog is nearly no effort to implement yet still provides close to100% of the benefits. Let me talk as an implementor: I like to implement things that customers (paying or not) ask for. Being a lazy person, I prefer things that are easy to do (which means there are libraries available and some reference implementations). I also like to implement things in areas where others are also implementing, so I can ask questions on interpretations and such. I like things that work reasonable well. From that perspective, a simple tcp transport protected by ssl/tls is *very* attractive. Granted, it does not provide the 100% reliability that rfc 3195 provides. But it provides 99,9% of that - at a much lower cost. And if we go for a simple app-level ACK mechanism, we would end up very close to what rfc 3195 offers in terms of reliability. If we add ssl/tls (easily done), we end up very close to what rfc 3195 offers in terms of authenticy and encryption (side note: rfc 3195 uses TLS, it just uses a complicated way of configuring it...). Given that we try to build on existing technology, this approach could also be very quickly implemented. That, together with the known customer demand, would probably give a standard in that area a jump start. I prefer to sacrify being in sync with the other network management protocols. Just for the records: I am saying this *after* I have implemented rfc 3195. So if we would stick with 3195, only, I would already be set for most things. Rainer On Tue, 2005-10-25 at 23:04, Anton Okmianski (aokmians) wrote: > Tom: > > TLS provides for asymmetric authentication. RFC 2264 Section 1: > > "The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers." > > SSL/TLS with server-side certs is pretty much a norm for all HTTPS deployments. SSL/TLS with client-side certs are used less frequently, but some organizations use those in mail clients. SMTP, IMAP, POP3 and ACAP all have mappings to TLS transport (RFC2487, RFC 2595) with commercial deployments. > > I think the reason SASL comes into the picture with certain protocols (like RFC 2595) is that TLS provides asymmetric authentication, and SASL symmetric (based on passwords), which is preferred in some protocol like mail for legacy reasons. > > Not sure if SSH provides for symmetric auth for server (vs. user) authentication. As far as I can tell from quick scan only asymmetric key support is required in SSH draft (sec 4.1): > http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/draft-ietf-secsh-architecture-23.txt > > I am not sure if support for symmetric keys (passwords) should be a requirement, anyway. Maintaining a database of passwords instead of public keys (in form of certs or other way) sounds like a security threat, not to mention a choir when one could just maintain single root CA (plus revocation lists if needed). Thoughts? > > Finally, I suspect mapping to SSH will take longer to develop and longer to deploy because it will be dependent on SSH drafts (see above). > > Thanks, > Anton. > > > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Tuesday, October 25, 2005 12:39 PM > > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick); > > syslog@ietf.org > > Subject: Why not TLS was Re: [Syslog] Secure substrate - need > > your input > > > > In the context of isms, ie SNMP, the choice was SSH v TLS + > > SASL; TLS provides the security but not the authentication > > while SSH does both. And SSH is a well-established protocol. > > > > I agree that TLS/SSL is the most widely used but that is > > because more people access websites (securely) than access > > network devices. If you limit yourself to network operations > > of network devices, then it appears to be SSH a significant > > number TLS so small as to be invisible > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Anton Okmianski (aokmians)" > > To: "Chris Lonvick (clonvick)" ; > > Sent: Tuesday, October 25, 2005 5:10 PM > > Subject: RE: [Syslog] Secure substrate - need your input > > > > > > > Hi Folks, > > > > > > I'll be asking this in Vancouver but would like to get some > > input from > > > the mailing list. > > > > > > Our charter says that we will develop a secure method to transport > > > syslog messages. We have BEEP (RFC 3195) but it has a low > > > implementation record. > > > Other groups have specified BEEP as well but are also moving along > > > towards using SSH or SSL. > > > > > > > > > 1) What secure substrate should the WG look towards: > > > > > > __ ssl > > > > > > __ ssh > > > > > > __ dtls > > > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > > > > > __ other > > > > I believe it should be SSL 3.0 / TLS 1.0. At least in > > web-server farm environments, you got SSL everywhere with a > > bunch of SSL accelerator hardware already in place. > > > > I also think several mappings can be defined. I am not a fan > > of options when it comes to standards, but allowing syslog > > over any kind of secure transport is a good thing. This was > > the whole idea of separating syslog-protocol from > > syslog-transport. Frankly, I don't think it will be a lot of > > work to define those transport mappings. > > > > > 2) Why? > > > > SSL/TLS is the most widely deployed network security protocol > > today. All e-commerce happens over it. Dozens of companies > > provide all shapes and forms of SSL accelerators. Many > > routers now have SSL accelartor modules. > > > > If I need to manage a large environment of servers where > > distributed logging really makes sense, being able to re-use > > existing infrastructure for scaling really helps. A search > > for "SSH accelerator" on google does not reveal anything > > interesting, but "SSL accelarator" shows up with a bunch of > > listings, several of which claim thousands of new SSL > > sessions per second. This confirms my experience. BTW, with > > SSL session caching, accelerators (ie. load balancers) can do > > 100,000 connections per second and more. So, to scale syslog > > over SSH would I have to wait for SSH accelerators to come to market? > > > > I see that there is a lot of work around SSH connection > > protocol and its potential use in new protocols. I have not > > followed these developments. There must have been a good > > reason for it. I would like to understand why people object > > to SSL, which is a well established technology. Any pointers? > > > > Thanks, > > Anton. > > > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 06:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiMZ-0006iT-Cr; Wed, 26 Oct 2005 06:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiMX-0006gU-Ll for syslog@megatron.ietf.org; Wed, 26 Oct 2005 06:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09327 for ; Wed, 26 Oct 2005 06:18:13 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiZg-0004Dg-3G for syslog@ietf.org; Wed, 26 Oct 2005 06:32:04 -0400 Received: from pc6 (1Cust93.tnt29.lnd3.gbr.da.uu.net [62.188.120.93]) by ranger.systems.pipex.net (Postfix) with SMTP id CFB75E0003D4; Wed, 26 Oct 2005 11:18:05 +0100 (BST) Message-ID: <03fd01c5da0e$03084c80$0601a8c0@pc6> From: "Tom Petch" To: "Anton Okmianski (aokmians)" , References: <98AE08B66FAD1742BED6CB9522B73122A9EF33@xmb-rtp-20d.amer.cisco.com> Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 11:15:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org It is not a question of asymmetric or symmetric authentication but of user(client) authentication; SSH has got it, TLS has not, hence the need for SASL. To quote the Security AD, from an e-mail he sent to the isms list detailing options to consider, "1) TLS/SASL. The combination of TLS and SASL go well together. You typically use one or both. In one common mode, TLS is used to authenticate the server (responder) to the client. The server has a cert and the client does not. You then use SASL to authenticate the client to the server. TLS is used to protect the session. Another common mode supported by the TLS+SASL option only involves SASL. You use a SASL security layer that provides mutual authentication to provide both data confidentiality and integrity to the session and to authenticate both parties. This SASL-only mode is used by Kerberos. A third mode involves only TLS. Both the client and server have certificates. This actually often looks like the first mode because the SASL external mechanism is used to signal that TLS has provided the client authentication." So for technical reasons, TLS alone was insufficient. For syslog, which is simplex not half-duplex, more change is needed to set up any form of a secure channel and I am not clear about the technical ramifications of that, whether TLS alone is sufficient. For syslog, I think it really comes down to a) the user marketplace; Web servers (TLS) or network operations (SSH) b) coherence within the IETF; SMTP/HTTP(TLS) v Telnet/Netconf/isms (SSH) In both cases, I am in the latter camp. Whichever way we go, distributing security credentials to remote, network devices is a pain as SNMPv3 has demonstrated; for network operators, as the isms survey showed, this is a soluble problem for SSH. I think that the issue of I-Ds is a red herring. TLS is a string of I-Ds, reflecting recent work on a protocol that many have not heard of, knowing only of SSL. SSH is a string of I-Ds, reflecting recent work on a protocol that many are familiar with. In both cases, there are problems of conformance, of there being different, not quite standard flavours, and the work of the IETF is to bring conformity to two well established protocols (bit like syslog:-). Tom Petch ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Tom Petch" ; "Chris Lonvick (clonvick)" ; Sent: Tuesday, October 25, 2005 11:04 PM Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input Tom: TLS provides for asymmetric authentication. RFC 2264 Section 1: "The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers." SSL/TLS with server-side certs is pretty much a norm for all HTTPS deployments. SSL/TLS with client-side certs are used less frequently, but some organizations use those in mail clients. SMTP, IMAP, POP3 and ACAP all have mappings to TLS transport (RFC2487, RFC 2595) with commercial deployments. I think the reason SASL comes into the picture with certain protocols (like RFC 2595) is that TLS provides asymmetric authentication, and SASL symmetric (based on passwords), which is preferred in some protocol like mail for legacy reasons. Not sure if SSH provides for symmetric auth for server (vs. user) authentication. As far as I can tell from quick scan only asymmetric key support is required in SSH draft (sec 4.1): http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/draft-ietf-secsh-architec ture-23.txt I am not sure if support for symmetric keys (passwords) should be a requirement, anyway. Maintaining a database of passwords instead of public keys (in form of certs or other way) sounds like a security threat, not to mention a choir when one could just maintain single root CA (plus revocation lists if needed). Thoughts? Finally, I suspect mapping to SSH will take longer to develop and longer to deploy because it will be dependent on SSH drafts (see above). Thanks, Anton. > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Tuesday, October 25, 2005 12:39 PM > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick); > syslog@ietf.org > Subject: Why not TLS was Re: [Syslog] Secure substrate - need > your input > > In the context of isms, ie SNMP, the choice was SSH v TLS + > SASL; TLS provides the security but not the authentication > while SSH does both. And SSH is a well-established protocol. > > I agree that TLS/SSL is the most widely used but that is > because more people access websites (securely) than access > network devices. If you limit yourself to network operations > of network devices, then it appears to be SSH a significant > number TLS so small as to be invisible > > Tom Petch > > ----- Original Message ----- > From: "Anton Okmianski (aokmians)" > To: "Chris Lonvick (clonvick)" ; > Sent: Tuesday, October 25, 2005 5:10 PM > Subject: RE: [Syslog] Secure substrate - need your input > > > > Hi Folks, > > > > I'll be asking this in Vancouver but would like to get some > input from > > the mailing list. > > > > Our charter says that we will develop a secure method to transport > > syslog messages. We have BEEP (RFC 3195) but it has a low > > implementation record. > > Other groups have specified BEEP as well but are also moving along > > towards using SSH or SSL. > > > > > > 1) What secure substrate should the WG look towards: > > > > __ ssl > > > > __ ssh > > > > __ dtls > > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > > > __ other > > I believe it should be SSL 3.0 / TLS 1.0. At least in > web-server farm environments, you got SSL everywhere with a > bunch of SSL accelerator hardware already in place. > > I also think several mappings can be defined. I am not a fan > of options when it comes to standards, but allowing syslog > over any kind of secure transport is a good thing. This was > the whole idea of separating syslog-protocol from > syslog-transport. Frankly, I don't think it will be a lot of > work to define those transport mappings. > > > 2) Why? > > SSL/TLS is the most widely deployed network security protocol > today. All e-commerce happens over it. Dozens of companies > provide all shapes and forms of SSL accelerators. Many > routers now have SSL accelartor modules. > > If I need to manage a large environment of servers where > distributed logging really makes sense, being able to re-use > existing infrastructure for scaling really helps. A search > for "SSH accelerator" on google does not reveal anything > interesting, but "SSL accelarator" shows up with a bunch of > listings, several of which claim thousands of new SSL > sessions per second. This confirms my experience. BTW, with > SSL session caching, accelerators (ie. load balancers) can do > 100,000 connections per second and more. So, to scale syslog > over SSH would I have to wait for SSH accelerators to come to market? > > I see that there is a lot of work around SSH connection > protocol and its potential use in new protocols. I have not > followed these developments. There must have been a good > reason for it. I would like to understand why people object > to SSL, which is a well established technology. Any pointers? > > Thanks, > Anton. > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 06:18:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiMb-0006kH-PT; Wed, 26 Oct 2005 06:18:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiMY-0006hO-E6 for syslog@megatron.ietf.org; Wed, 26 Oct 2005 06:18:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09330 for ; Wed, 26 Oct 2005 06:18:14 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiZg-0004Do-3K for syslog@ietf.org; Wed, 26 Oct 2005 06:32:05 -0400 Received: from pc6 (1Cust93.tnt29.lnd3.gbr.da.uu.net [62.188.120.93]) by ranger.systems.pipex.net (Postfix) with SMTP id 3A6C2E0003DF; Wed, 26 Oct 2005 11:18:10 +0100 (BST) Message-ID: <03fe01c5da0e$056c2d20$0601a8c0@pc6> From: "Tom Petch" To: "Rodney Thayer" , References: <98AE08B66FAD1742BED6CB9522B73122A9ED50@xmb-rtp-20d.amer.cisco.com><0e5801c5d983$c717dc20$0601a8c0@pc6> <435EA7BF.2090308@canola-jones.com> Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 11:16:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Just to add the figures that support my assertion, in an e-mail from Wes Hardaker, who surveyed the network operators, to isms "Of the various authentication systems in use at that time by the people that responded: 66% local accounts 49% SSH-keys 40% Radius 29% TACACS+ 14% X.509 Certificates 10% Kerberos [numbers don't add to 100 because more than one option could be selected]" which I have paraphrased as SSH a significant number TLS so small as to be invisible Of course, as I hope is clear, I am talking in the context of network operations, not of Web access (where I accept that SSL dominates). Tom Petch ----- Original Message ----- From: "Rodney Thayer" To: Sent: Tuesday, October 25, 2005 11:46 PM Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input > Tom Petch wrote: > > In the context of isms, ie SNMP, the choice was SSH v TLS + SASL; TLS provides > > the security but not the authentication while SSH does both. And SSH is a > > well-established protocol. > > > > I agree that TLS/SSL is the most widely used but that is because more people > > access websites (securely) than access network devices. If you limit yourself > > to network operations of network devices, then it appears to be > > SSH a significant number > > TLS so small as to be invisible > > A couple of comments - > > I disagree that TLS is rare. TLS is common, in my experience, because > many devices have web-based management interfaces and those are secured with > TLS. > > Also, if your logic were correct, then all those SASL folks who hassled us > TLS people into going with STARTLS/SASL/etc must have been wrong - this > is one of those "the IETF can't declare both 1 and 0 to be truth, depending > on which RFC you read" problems. > > OTOH you are using SOME standard protocol so I'm fine with SSH... > > _______________________________________________ > 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 Oct 26 08:49:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkiS-0003kB-Ic; Wed, 26 Oct 2005 08:49:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkiQ-0003jL-Ju for syslog@megatron.ietf.org; Wed, 26 Oct 2005 08:49:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17091 for ; Wed, 26 Oct 2005 08:48:59 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkvV-0000KE-RH for syslog@ietf.org; Wed, 26 Oct 2005 09:02:47 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9QCmXfs008313; Wed, 26 Oct 2005 22:48:33 +1000 (EST) From: Darren Reed Message-Id: <200510261248.j9QCm2IV022572@firewall.reed.wattle.id.au> Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input In-Reply-To: <03fe01c5da0e$056c2d20$0601a8c0@pc6> To: Tom Petch Date: Wed, 26 Oct 2005 22:48:02 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > Just to add the figures that support my assertion, in an e-mail from Wes > Hardaker, who surveyed the network operators, to isms > > "Of the various authentication systems in use at that time by the people that > responded: > > 66% local accounts > 49% SSH-keys > 40% Radius > 29% TACACS+ > 14% X.509 Certificates > 10% Kerberos > > [numbers don't add to 100 because more than one option could be selected]" > > which I have paraphrased as > SSH a significant number > TLS so small as to be invisible I disagree. I don't think the numbers above provide that kind of conclusion at all. We don't know what the survey was, etc. Just like any set of statistics, they can be interpreted to mean many things, depending on how you want to read them. Anyway, I'm not interested in that. But, to put the problem differently, in how many different places can you use TLS/SSL for authentication today, to sign in ? If there's nowhere for people to use TLS then of course the numbers won't be high. Darrn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 08:55:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkoG-0004fg-Hl; Wed, 26 Oct 2005 08:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkoF-0004f0-IF for syslog@megatron.ietf.org; Wed, 26 Oct 2005 08:55:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17340 for ; Wed, 26 Oct 2005 08:55:00 -0400 (EDT) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUl1P-0000UF-6A for syslog@ietf.org; Wed, 26 Oct 2005 09:08:52 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j9QCsrge020021; Wed, 26 Oct 2005 22:54:53 +1000 (EST) From: Darren Reed Message-Id: <200510261254.j9QCsdhH018457@firewall.reed.wattle.id.au> Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input In-Reply-To: <03fd01c5da0e$03084c80$0601a8c0@pc6> To: Tom Petch Date: Wed, 26 Oct 2005 22:54:39 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > I think that the issue of I-Ds is a red herring. TLS is a string of I-Ds, > reflecting recent work on a protocol that many have not heard of, knowing > only of SSL. SSH is a string of I-Ds, reflecting recent work on a protocol > that many are familiar with. In both cases, there are problems of > conformance, of there being different, not quite standard flavours, and > the work of the IETF is to bring conformity to two well established > protocols (bit like syslog:-). I think most people are going to be about as familiar with the TLS protocol as they are with the SSH one - in terms of depth of knowledge. As for use, well as you've pointed out, anyone using "https" is using TLS/SSL, so it's hard to say people are unaware of it. In both cases, people generally follow a specific "script" to achieve a given goal without being overly concerned about the flow of bits and bytes in the middle. In summary, I find this line of argument quite specious. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 08:58:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkrn-0006Jv-3j; Wed, 26 Oct 2005 08:58:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkrl-0006Iq-I0 for syslog@megatron.ietf.org; Wed, 26 Oct 2005 08:58:53 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17588 for ; Wed, 26 Oct 2005 08:58:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 72EF127C02A for ; Wed, 26 Oct 2005 14:56:27 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22508-09 for ; Wed, 26 Oct 2005 14:56:27 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 3DBE227C018 for ; Wed, 26 Oct 2005 14:56:27 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 14:58:09 +0200 Content-class: urn:content-classes:message Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Oct 2005 14:57:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3CD3@grfint2.intern.adiscon.com> Thread-Topic: Why not TLS was Re: [Syslog] Secure substrate - need your input Thread-Index: AcXaLGuz0y6UCNlFSuGfJHcomrH+DgAADdSw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 26 Oct 2005 12:58:09.0639 (UTC) FILETIME=[EA6D8770:01C5DA2C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren,=20 please let me add=20 > > TLS so small as to be invisible is probably not true. TLS uses X.509 certificates, so isn't it in that number: > > 14% X.509 Certificates Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 11:25:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUn9q-00019u-MV; Wed, 26 Oct 2005 11:25:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUn9p-00017v-4J for syslog@megatron.ietf.org; Wed, 26 Oct 2005 11:25:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01045 for ; Wed, 26 Oct 2005 11:25:25 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnMz-0006yb-CP for syslog@ietf.org; Wed, 26 Oct 2005 11:39:18 -0400 Received: from pc6 (1Cust219.tnt16.lnd4.gbr.da.uu.net [62.188.145.219]) by astro.systems.pipex.net (Postfix) with SMTP id 0A360E00012C for ; Wed, 26 Oct 2005 16:25:22 +0100 (BST) Message-ID: <014201c5da38$efda1dc0$0601a8c0@pc6> From: "Tom Petch" To: References: <200510261248.j9QCm2IV022572@firewall.reed.wattle.id.au> Subject: Aside - isms genesis was Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 16:21:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org In case anyone else should be interested, the survey I keep referring to was performed of 149 operators at NANOG at the request of the IETF AD to provide evidence that there was a problem with SNMPv3 security that the IETF should work on. The results were presented at IETF60 and the IESG were convinced; hence the isms WG. I refer to it because the IETF often bemoans the lack of operator input and this is one time when it was sought and obtained. And yes, as Rainer pointed out, we don't know what X.509 means and SSL/TLS (and a few others) could be lurking in there (nothing like a survey for creating the need for more surveys:-(. Tom Petch ----- Original Message ----- From: "Darren Reed" To: "Tom Petch" Cc: "Rodney Thayer" ; Sent: Wednesday, October 26, 2005 2:48 PM Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input > [ Charset ISO-8859-1 unsupported, converting... ] > > Just to add the figures that support my assertion, in an e-mail from Wes > > Hardaker, who surveyed the network operators, to isms > > > > "Of the various authentication systems in use at that time by the people that > > responded: > > > > 66% local accounts > > 49% SSH-keys > > 40% Radius > > 29% TACACS+ > > 14% X.509 Certificates > > 10% Kerberos > > > > [numbers don't add to 100 because more than one option could be selected]" > > > > which I have paraphrased as > > SSH a significant number > > TLS so small as to be invisible > > I disagree. I don't think the numbers above provide that kind of > conclusion at all. We don't know what the survey was, etc. Just > like any set of statistics, they can be interpreted to mean many > things, depending on how you want to read them. > > Anyway, I'm not interested in that. > > But, to put the problem differently, in how many different places can > you use TLS/SSL for authentication today, to sign in ? > > If there's nowhere for people to use TLS then of course the numbers > won't be high. > > Darrn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 11:27:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnBk-000350-M0; Wed, 26 Oct 2005 11:27:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnBi-000311-RF for syslog@megatron.ietf.org; Wed, 26 Oct 2005 11:27:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01195 for ; Wed, 26 Oct 2005 11:27:23 -0400 (EDT) Message-Id: <200510261527.LAA01195@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnOs-00073S-DE for syslog@ietf.org; Wed, 26 Oct 2005 11:41:16 -0400 Received: from d55py901 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2005102615272701400j5rn2e>; Wed, 26 Oct 2005 15:27:27 +0000 From: "David B Harrington" To: Subject: Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 11:26:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXaLNzvTPcpvskFQUG857DVL884BAAElI3A In-Reply-To: <200510261254.j9QCsdhH018457@firewall.reed.wattle.id.au> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, As this WG struggles with the question of which secure transport to use, I recommend reading RFC3535 - "Overview of the 2002 IAB Network Management Workshop". This workshop, a "world tour" of ISP organizations, and the survey of which Tom speaks were part of an effort by the IAB and the O&M Area Directors to get direct input from operators to ensure that future O&M work would meet operators' needs. Netconf and ISMS directions are largely the result of the information gathered during this effort. The survey was put together by Wes Hardaker of NET-SNMP, and the operators at NANOG were asked to take the survey online. Tom, do you have a URL for that survey, so the syslog WG can see the questions and responses, so they can assess how applicable the survey is to syslog? Dave Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 12:01:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUniI-00081i-EL; Wed, 26 Oct 2005 12:01:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUniG-00080A-TD for syslog@megatron.ietf.org; Wed, 26 Oct 2005 12:01:16 -0400 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03421 for ; Wed, 26 Oct 2005 12:00:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 0774D27C02C for ; Wed, 26 Oct 2005 17:58:50 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26064-04 for ; Wed, 26 Oct 2005 17:58:49 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 7F32027C018 for ; Wed, 26 Oct 2005 17:58:49 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Oct 2005 18:00:41 +0200 Content-class: urn:content-classes:message Subject: RE: Aside - isms genesis was Re: Why not TLS was Re: [Syslog] Securesubstrate - need your input MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Oct 2005 17:59:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3CE2@grfint2.intern.adiscon.com> Thread-Topic: Aside - isms genesis was Re: Why not TLS was Re: [Syslog] Securesubstrate - need your input Thread-Index: AcXaQZPqdjIwAtAGTEeqO0t9SDal+QAAS0Sw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 26 Oct 2005 16:00:41.0479 (UTC) FILETIME=[6A3BB170:01C5DA46] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, I think part of the problem ob being out of sync in our interpretation is that we are probably thinking about different user bases. As of my understanding, SNMP most often has the "high end" users, the guys with many ressources and good knowledge. Many of them also use syslog. HOWEVER, syslog is also used by many "low end" users, those with limited ressources and knowledge and only a handful of servers and routers. Most probably, the later would not install SNMP based solutions and even not care about things like NETCONF. Their problem is to see these few events they have on a central machine and (hopefully) run some analysis against it. This diverse user base might be the root problem. In my experience, syslog solutions and development tend to lean toward the low end, in part because the high end already uses other event notification methods. With syslog, we also have application developers who simply want to log an error message somewhere. If we are lucky, they know about the syslog() call, if not, they'll dump the message somewhere... What I am trying to convey is that the different target user base eventually requires different approaches for the protocols. Then, there is the fact that syslog currently *is* being *deployed* via TCP and via SSL(TLS). For example, these links are quite popular: http://freshmeat.net/articles/view/1781/ http://www.stunnel.org/examples/syslog-ng.html http://www.monitorware.com/Common/en/Articles/eventlog-stunnel-syslog.ph p http://www.sun.com/bigadmin/features/articles/syslog_ng.html?biga=3D15 Is actual *deployment* of a technology not a good indication that there is need in the market for it? Frankly, the syslog developer community cares very little about the IETF. This community develops what is in demand, and unfortunately what we are currently doing is not demanded... I think it is not wise to ignore the fact that a healthy developer and user community has already solved (well, mostly) the problems we are discussing. We just do not like their conclusions. The results that practice tells us. But if practice is so broken, how can it work? The one thing that is asked for ever and ever again by syslog users is standardization of message *content*. That is the topic that urgently needs work. That is the topic we have excluded in our charter ;) Folks, I know this is my personal rant and frustration, but aren't we ready for a reality check? Ok, cooling down... I am sure that the survey you mentioned did very well look at the needs and whishes of the big guys. But does it equally well tell about the small ones? As a side note, I would find a link to the survey questions (as suggested by David) very helpful. Co-incidently, I'd begun to craft a small survey in the mean time. Definitely not as well thought-out, but hopefully good enough to see what is deployed in practice. I intended to ask for participation on several mailing list. Now that I have finished it, I think I at least provide a link to the proposal I intended to make http://survey2.adiscon.com/phpESP/public/survey.php?name=3Dsyslog1_NonLiv= e 1 (This survey is NOT LIVE - do NOT pass it to anyone outside the WG; results will be discarded) Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Wednesday, October 26, 2005 4:22 PM > To: syslog@ietf.org > Subject: Aside - isms genesis was Re: Why not TLS was Re:=20 > [Syslog] Securesubstrate - need your input >=20 > In case anyone else should be interested, the survey I keep=20 > referring to was > performed of 149 operators at NANOG at the request of the=20 > IETF AD to provide > evidence that there was a problem with SNMPv3 security that=20 > the IETF should work > on. The results were presented at IETF60 and the IESG were=20 > convinced; hence the > isms WG. >=20 > I refer to it because the IETF often bemoans the lack of=20 > operator input and this > is one time when it was sought and obtained. >=20 > And yes, as Rainer pointed out, we don't know what X.509=20 > means and SSL/TLS (and > a few others) could be lurking in there (nothing like a=20 > survey for creating the > need for more surveys:-(. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Darren Reed" > To: "Tom Petch" > Cc: "Rodney Thayer" ; > Sent: Wednesday, October 26, 2005 2:48 PM > Subject: Re: Why not TLS was Re: [Syslog] Secure substrate -=20 > need your input >=20 >=20 > > [ Charset ISO-8859-1 unsupported, converting... ] > > > Just to add the figures that support my assertion, in an=20 > e-mail from Wes > > > Hardaker, who surveyed the network operators, to isms > > > > > > "Of the various authentication systems in use at that=20 > time by the people > that > > > responded: > > > > > > 66% local accounts > > > 49% SSH-keys > > > 40% Radius > > > 29% TACACS+ > > > 14% X.509 Certificates > > > 10% Kerberos > > > > > > [numbers don't add to 100 because more than one option=20 > could be selected]" > > > > > > which I have paraphrased as > > > SSH a significant number > > > TLS so small as to be invisible > > > > I disagree. I don't think the numbers above provide that kind of > > conclusion at all. We don't know what the survey was, etc. Just > > like any set of statistics, they can be interpreted to mean many > > things, depending on how you want to read them. > > > > Anyway, I'm not interested in that. > > > > But, to put the problem differently, in how many different=20 > places can > > you use TLS/SSL for authentication today, to sign in ? > > > > If there's nowhere for people to use TLS then of course the numbers > > won't be high. > > > > Darrn >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 12:08:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnph-00012Q-VL; Wed, 26 Oct 2005 12:08:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnph-00011p-3A for syslog@megatron.ietf.org; Wed, 26 Oct 2005 12:08:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04014 for ; Wed, 26 Oct 2005 12:08:41 -0400 (EDT) Received: from ext-nj2ut-9.online-age.net ([64.14.54.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUo2r-0008Sp-Tn for syslog@ietf.org; Wed, 26 Oct 2005 12:22:35 -0400 Received: from int-nj2ut-5.online-age.net (int-nj2ut-5.online-age.net [3.159.237.74]) by ext-nj2ut-9.online-age.net (8.13.4/8.13.4/20050902-SVVS-TLS) with ESMTP id j9QG8WtV000402 for ; Wed, 26 Oct 2005 12:08:36 -0400 Received: from cinmlef06.e2k.ad.ge.com (localhost.localdomain [127.0.0.1]) by int-nj2ut-5.online-age.net (8.11.6/8.11.6/20050510-SVVS) with ESMTP id j9QG8Ua18006 for ; Wed, 26 Oct 2005 12:08:31 -0400 Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:07:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 11:07:53 -0500 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C08F5A690@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: Why not TLS was Re: [Syslog] Secure substrate - need your input Thread-Index: AcXaFwD+2gXRuSMwS0uEdEUXl1DCkAALR5pw From: "Moehrke, John \(GE Healthcare\)" To: X-OriginalArrivalTime: 26 Oct 2005 16:07:57.0676 (UTC) FILETIME=[6E3A12C0:01C5DA47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org There is a miss understanding of the information I have seen given by many people on this list regarding TLS. I think this miss understanding is also being applied to SSH. Most people get the facts right on server-side-authentication. SSL for years supported Server side authentication. This allows a common-user to know that they are indeed connecting to the right service. Thus they know that this is indeed their bank that they are providing their credentials to. There is a wealth of standards and tools that accomplish this. The facts get much more confused when people start to add requirements to authenticate the client side. The first confusion comes when people don't really ask 'who do they want to authenticate?' Most common authentication schemes want to authenticate the user. The advantage to these services is that they then can apply preferences, user behavior tracking, access controls based on user/role, etc. The problem with this mode of client authentication is that the service knows nothing about the machine that the user is using at this time. For most portals this is a benefit as it allows the user to use any kiosk, thus user frustration is low. The problem is that that kiosk could be highly compromised... Enough said.=20 Thus there is a need to authenticate the client-machine. Given the above concern, this is becoming more and more common.=20 So, SYSLOG needs to ask do they want to authenticate the user, machine, or both? TLS does support mutual node authentication. The healthcare world has been using mutual-node-authenticated-TLS for over three years. We use it often to ensure that a X-Ray device is actually talking to the Picture Archiving Service. Both systems need to know that they are talking to the right 'other' system. This transaction doesn't need to have user authentication as the process is fully automated. Indeed we don't always turn on TLS encryption. But we do always do mutual-authentication. Yes this means that there is a X.509 certificate managed for both nodes. But this certificate management is not nearly as complex as person-certificates (another discussion we can have on miss-understandings due to the wrong questions being asked). The problem is that many people quickly associate TLS/SSL with it's earlier SSL, which leads to HTTPS, which leads them to look at browsers. The end result is that you find at most one browser that supports mutual-authenticated-TLS. Note that the browsers will claim to authenticate the 'client', but this is HTTP-authentication. This HTTP-authentication is a different layer than the TLS authentication. I don't think that the SYSLOG community is likely to be using browsers. They will likely be using tools like JAVA, and the good news is these tools do support mutual-node-authentication (See: JAVA SSLSocket). John _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 12:31:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoBc-0002rA-Et; Wed, 26 Oct 2005 12:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnzO-0008H1-6d for syslog@megatron.ietf.org; Wed, 26 Oct 2005 12:18:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05232 for ; Wed, 26 Oct 2005 12:18:42 -0400 (EDT) Message-Id: <200510261618.MAA05232@ietf.org> Received: from [63.240.77.82] (helo=sccrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUoCT-0000Yw-3T for syslog@ietf.org; Wed, 26 Oct 2005 12:32:36 -0400 Received: from d55py901 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2005102616182801200q8fcre>; Wed, 26 Oct 2005 16:18:28 +0000 From: "David Harrington" To: Date: Wed, 26 Oct 2005 12:17:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXaR2O373u602CMSyGXzPJu7MCyxQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 Oct 2005 12:31:36 -0400 Cc: Subject: [Syslog] survey X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, The survey was summarized at IETF 60 in the following presentation: http://www3.ietf.org/proceedings/04aug/slides/isms-1.pdf Dave Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 14:24:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpws-0005Y4-GX; Wed, 26 Oct 2005 14:24:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpwr-0005Xq-FN for syslog@megatron.ietf.org; Wed, 26 Oct 2005 14:24:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12218 for ; Wed, 26 Oct 2005 14:24:14 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUqA3-0004RU-Il for syslog@ietf.org; Wed, 26 Oct 2005 14:38:08 -0400 Received: from pc6 (1Cust14.tnt10.lnd4.gbr.da.uu.net [62.188.139.14]) by astro.systems.pipex.net (Postfix) with SMTP id 4DE00E000158; Wed, 26 Oct 2005 19:24:09 +0100 (BST) Message-ID: <01d001c5da51$ea76fd80$0601a8c0@pc6> From: "Tom Petch" To: "Moehrke, John \(GE Healthcare\)" , References: <45A5295FFA1CBE4D9BF44E8534D2686C08F5A690@MKEMLVEM07.e2k.ad.ge.com> Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 19:21:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Moehrke, John (GE Healthcare)" To: Sent: Wednesday, October 26, 2005 6:07 PM Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input There is a miss understanding of the information I have seen given by many people on this list regarding TLS. I think this miss understanding is also being applied to SSH. So, SYSLOG needs to ask do they want to authenticate the user, machine, or both? Tom - yes, agree strongly but I don't know the answer. TLS does support mutual node authentication. The healthcare world has been using mutual-node-authenticated-TLS for over three years. We use it often to ensure that a X-Ray device is actually talking to the Picture Archiving Service. Both systems need to know that they are talking to the right 'other' system. This transaction doesn't need to have user authentication as the process is fully automated. Indeed we don't always turn on TLS encryption. But we do always do mutual-authentication. Yes this means that there is a X.509 certificate managed for both nodes. But this certificate management is not nearly as complex as person-certificates (another discussion we can have on miss-understandings due to the wrong questions being asked). Tom- this one puzzles me. SSH has got server and client authorisation defined in the I-Ds, soon to be RFCs. Reading the TLS I-Ds I see no sign of client authorisation and since that is a must for SNMP, then the note I quoted earlier, to the isms list, saying that SASL would needed alongside TLS made perfect sense (as I would expect since it came from the Security AD:-). So where does mutual authentication come from? What RFC or I-D defines it? Is it a proprietary extension? Is it two simplex transmissions with only server authentication? Sometimes it does matter to know what goes on under the covers. (Of course, if client authentication is not needed then this is academic). John _______________________________________________ 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 Oct 26 14:34:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUq6a-0004L2-7D; Wed, 26 Oct 2005 14:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUq6Y-0004Hp-Tw for syslog@megatron.ietf.org; Wed, 26 Oct 2005 14:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13083 for ; Wed, 26 Oct 2005 14:34:16 -0400 (EDT) Received: from ext-nj2ut-6.online-age.net ([64.14.54.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUqJj-0004sn-A0 for syslog@ietf.org; Wed, 26 Oct 2005 14:48:10 -0400 Received: from int-nj2ut-2.online-age.net (int-nj2ut-2.online-age.net [3.159.237.71]) by ext-nj2ut-6.online-age.net (8.13.4/8.13.4/20050902-SVVS-TLS) with ESMTP id j9QIYGAj020060 for ; Wed, 26 Oct 2005 14:34:17 -0400 Received: from cinmlef09.e2k.ad.ge.com (localhost.localdomain [127.0.0.1]) by int-nj2ut-2.online-age.net (8.11.6/8.11.6/20050510-SVVS) with ESMTP id j9QIYG820931 for ; Wed, 26 Oct 2005 14:34:16 -0400 Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 14:34:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 13:34:15 -0500 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C08F5A9D5@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: Why not TLS was Re: [Syslog] Secure substrate - need your input Thread-Index: AcXaWnocMJ3i9TwMQM6ivzfZGns/eQAAKfrw From: "Moehrke, John \(GE Healthcare\)" To: "Tom Petch" , X-OriginalArrivalTime: 26 Oct 2005 18:34:15.0974 (UTC) FILETIME=[DE800C60:01C5DA5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org TLS Version 1.0 January 1999 RFC-2246 Section=20 7.4.6 Client Certificate=20 I did assume that when you said "authorisation" that you really meant "authentication". If this assumption is wrong, then you have yet more questions to ask. Authorization is not handled by any of the protocols at this layer. John -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Wednesday, October 26, 2005 12:22 PM To: Moehrke, John (GE Healthcare); syslog@ietf.org Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Tom Petch ----- Original Message ----- From: "Moehrke, John (GE Healthcare)" To: Sent: Wednesday, October 26, 2005 6:07 PM Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input There is a miss understanding of the information I have seen given by many people on this list regarding TLS. I think this miss understanding is also being applied to SSH. So, SYSLOG needs to ask do they want to authenticate the user, machine, or both? Tom - yes, agree strongly but I don't know the answer. TLS does support mutual node authentication. The healthcare world has been using mutual-node-authenticated-TLS for over three years. We use it often to ensure that a X-Ray device is actually talking to the Picture Archiving Service. Both systems need to know that they are talking to the right 'other' system. This transaction doesn't need to have user authentication as the process is fully automated. Indeed we don't always turn on TLS encryption. But we do always do mutual-authentication. Yes this means that there is a X.509 certificate managed for both nodes. But this certificate management is not nearly as complex as person-certificates (another discussion we can have on miss-understandings due to the wrong questions being asked). Tom- this one puzzles me. SSH has got server and client authorisation defined in the I-Ds, soon to be RFCs. Reading the TLS I-Ds I see no sign of client authorisation and since that is a must for SNMP, then the note I quoted earlier, to the isms list, saying that SASL would needed alongside TLS made perfect sense (as I would expect since it came from the Security AD:-). So where does mutual authentication come from? What RFC or I-D defines it? Is it a proprietary extension? Is it two simplex transmissions with only server authentication? Sometimes it does matter to know what goes on under the covers. (Of course, if client authentication is not needed then this is academic). John _______________________________________________ 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 Oct 26 14:44:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqFo-0001V1-CY; Wed, 26 Oct 2005 14:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqFm-0001Ut-Jq for syslog@megatron.ietf.org; Wed, 26 Oct 2005 14:44:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13512 for ; Wed, 26 Oct 2005 14:43:47 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUqSx-000581-HE for syslog@ietf.org; Wed, 26 Oct 2005 14:57:41 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2005 11:43:41 -0700 X-IronPort-AV: i="3.97,254,1125903600"; d="scan'208"; a="224164558:sNHT4621502364" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9QIhS8q000432; Wed, 26 Oct 2005 11:43:36 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 14:43:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 14:43:35 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122A9F237@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Why not TLS was Re: [Syslog] Secure substrate - need your input Thread-Index: AcXaWwcSkty7IKPYQYaRqEKFjJF3WwAAQirA From: "Anton Okmianski \(aokmians\)" To: "Tom Petch" , "Moehrke, John \(GE Healthcare\)" , X-OriginalArrivalTime: 26 Oct 2005 18:43:36.0149 (UTC) FILETIME=[2C63F850:01C5DA5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > TLS does support mutual node authentication. The healthcare=20 > world has been using mutual-node-authenticated-TLS for over=20 > three years. We use it often to ensure that a X-Ray device is=20 > actually talking to the Picture Archiving Service. Both=20 > systems need to know that they are talking to the right=20 > 'other' system. This transaction doesn't need to have user=20 > authentication as the process is fully automated. Indeed we=20 > don't always turn on TLS encryption. But we do always do=20 > mutual-authentication. Yes this means that there is a X.509=20 > certificate managed for both nodes. But this certificate=20 > management is not nearly as complex as person-certificates=20 > (another discussion we can have on miss-understandings due to=20 > the wrong questions being asked). >=20 > Tom- this one puzzles me. SSH has got server and client=20 > authorisation defined in the I-Ds, soon to be RFCs. Reading=20 > the TLS I-Ds I see no sign of client authorisation and since=20 > that is a must for SNMP, then the note I quoted earlier, to=20 > the isms list, saying that SASL would needed alongside TLS=20 > made perfect sense (as I would expect since it came from the=20 > Security AD:-). So where does mutual authentication come=20 > from? What RFC or I-D defines it? Is it a proprietary=20 > extension? Is it two simplex transmissions with only server=20 > authentication? > Sometimes it does matter to know what goes on under the=20 > covers. (Of course, if client authentication is not needed=20 > then this is academic). Client auth is a fundamental feature of TLS. It is all over the TLS = RFC: http://www.faqs.org/rfcs/rfc2246.html Search it for "client authentication" or "client certificate". There are = whole sections on it. It is part of the initial SSL/TLS setup. Server = may require client-auth if configured so. =20 If you don't believe that it is deployed, open you browser security = settings. John mentioned that not all browsers supports client certs for = SSL/TLS. Well... At least IE, Netscape, Firefox support it and had for = some time. In fact, they have pretty advanced features around client = certs. For example, you can use a different client cert with different = sites.=20 The real question IMO, again, is whether or not symmetric auth (password = / shared secret based) is considered important. SSH has it. TLS does = not. If client certs are acceptable to people, then TLS is a perfect = solution. I think certificate-based infrastructure is more secure and = easier to manage in the end. No interactive user auth is needed for = syslog, as John mentioned. And if you store passwords instead of having = user type them in, then you are really only one-step away from using = certs. =20 Thanks, Anton.=20 >=20 > > John >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 15:00:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqW3-0001XQ-0e; Wed, 26 Oct 2005 15:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqW1-0001WZ-9e for syslog@megatron.ietf.org; Wed, 26 Oct 2005 15:00:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14650 for ; Wed, 26 Oct 2005 15:00:34 -0400 (EDT) Received: from ext-ch1gw-8.online-age.net ([64.37.194.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUqjD-0005g5-FK for syslog@ietf.org; Wed, 26 Oct 2005 15:14:29 -0400 Received: from int-ch1gw-4.online-age.net (int-ch1gw-4 [3.159.232.68]) by ext-ch1gw-8.online-age.net (8.13.4/8.12.11/20050527-JWF) with ESMTP id j9QJ0W0l003752 for ; Wed, 26 Oct 2005 15:00:32 -0400 Received: from cinmlef08.e2k.ad.ge.com (localhost [127.0.0.1]) by int-ch1gw-4.online-age.net (8.12.9/8.12.3/990426-RLH) with ESMTP id j9QJ0VUc007867 for ; Wed, 26 Oct 2005 15:00:32 -0400 (EDT) Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 15:00:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 14:00:30 -0500 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C08F5AA70@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: Why not TLS was Re: [Syslog] Secure substrate - need your input Thread-Index: AcXaWwcSkty7IKPYQYaRqEKFjJF3WwAAQirAAACLauA= From: "Moehrke, John \(GE Healthcare\)" To: X-OriginalArrivalTime: 26 Oct 2005 19:00:31.0071 (UTC) FILETIME=[8954C6F0:01C5DA5F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton, Thanks for your support. I do want to caution your enthusiasm for the browser support. I believe that all current production browsers implement the feature you found using HTTP-authentication, not TLS/SSL. Trying to create a user interface for this complex concept can't be easy, and the prevailing reason to use client certificates was for user authentication. Thus they took the most logical short-cut. It is my understanding that IE7 will have true TLS/SSL client-certificate authentication.=20 It is also my understanding that firefox current 1.5 has TLS/SSL client-certificate authentication. I had seen test results that indicated this was true.=20 http://www.mozilla.org/projects/security/pki/nss/results.html I have not been able to confirm this personally. John -----Original Message----- From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 Sent: Wednesday, October 26, 2005 1:44 PM To: Tom Petch; Moehrke, John (GE Healthcare); syslog@ietf.org Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input > TLS does support mutual node authentication. The healthcare=20 > world has been using mutual-node-authenticated-TLS for over=20 > three years. We use it often to ensure that a X-Ray device is=20 > actually talking to the Picture Archiving Service. Both=20 > systems need to know that they are talking to the right=20 > 'other' system. This transaction doesn't need to have user=20 > authentication as the process is fully automated. Indeed we=20 > don't always turn on TLS encryption. But we do always do=20 > mutual-authentication. Yes this means that there is a X.509=20 > certificate managed for both nodes. But this certificate=20 > management is not nearly as complex as person-certificates=20 > (another discussion we can have on miss-understandings due to=20 > the wrong questions being asked). >=20 > Tom- this one puzzles me. SSH has got server and client=20 > authorisation defined in the I-Ds, soon to be RFCs. Reading=20 > the TLS I-Ds I see no sign of client authorisation and since=20 > that is a must for SNMP, then the note I quoted earlier, to=20 > the isms list, saying that SASL would needed alongside TLS=20 > made perfect sense (as I would expect since it came from the=20 > Security AD:-). So where does mutual authentication come=20 > from? What RFC or I-D defines it? Is it a proprietary=20 > extension? Is it two simplex transmissions with only server=20 > authentication? > Sometimes it does matter to know what goes on under the=20 > covers. (Of course, if client authentication is not needed=20 > then this is academic). Client auth is a fundamental feature of TLS. It is all over the TLS RFC: http://www.faqs.org/rfcs/rfc2246.html Search it for "client authentication" or "client certificate". There are whole sections on it. It is part of the initial SSL/TLS setup. Server may require client-auth if configured so. =20 If you don't believe that it is deployed, open you browser security settings. John mentioned that not all browsers supports client certs for SSL/TLS. Well... At least IE, Netscape, Firefox support it and had for some time. In fact, they have pretty advanced features around client certs. For example, you can use a different client cert with different sites.=20 The real question IMO, again, is whether or not symmetric auth (password / shared secret based) is considered important. SSH has it. TLS does not. If client certs are acceptable to people, then TLS is a perfect solution. I think certificate-based infrastructure is more secure and easier to manage in the end. No interactive user auth is needed for syslog, as John mentioned. And if you store passwords instead of having user type them in, then you are really only one-step away from using certs. =20 Thanks, Anton.=20 >=20 > > John >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 15:29:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqxs-0007pK-Fh; Wed, 26 Oct 2005 15:29:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqxp-0007oa-Kb for syslog@megatron.ietf.org; Wed, 26 Oct 2005 15:29:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16700 for ; Wed, 26 Oct 2005 15:29:18 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUrB2-0006l3-2o for syslog@ietf.org; Wed, 26 Oct 2005 15:43:13 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2005 12:29:23 -0700 X-IronPort-AV: i="3.97,254,1125903600"; d="scan'208"; a="669539104:sNHT27870700" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9QJTI96000123; Wed, 26 Oct 2005 12:29:20 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 15:29:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 15:29:06 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122A9F294@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Why not TLS was Re: [Syslog] Secure substrate - need your input Thread-Index: AcXaWwcSkty7IKPYQYaRqEKFjJF3WwAAQirAAACLauAAAPE00A== From: "Anton Okmianski \(aokmians\)" To: "Moehrke, John \(GE Healthcare\)" , X-OriginalArrivalTime: 26 Oct 2005 19:29:07.0161 (UTC) FILETIME=[88335490:01C5DA63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org John: My experience is slightly different. That client cert support in = browsers has been there for years. HTTP basic/digest auth does not use = certs. HTTP auth is used when you are prompted for username/password.=20 But not many servers in the wild require client-certs -- no public = e-commerce site would do that if it wanted to get business. It is mostly = targeted at closed corporate environments at this point where employees = get individual certs to authenticate to corporate servers. Same is used = for mail.=20 You will also notice that a bunch of public certificate authorities sell = personal certificates. These are used predominantly in email clients, = for message signing (end-to-end message authenticity) instead of auth to = server. Although, some organizations do use client certs for = authenticating to mail servers with SMTP/POP3 over TLS.=20 But anyhow... I agree that the client-certs are not used as often as = server-certs. But they are a very established technology in TLS world. = I think we both agree on that.=20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Moehrke,=20 > John (GE Healthcare) > Sent: Wednesday, October 26, 2005 3:01 PM > To: syslog@ietf.org > Subject: RE: Why not TLS was Re: [Syslog] Secure substrate -=20 > need your input >=20 > Anton, Thanks for your support. I do want to caution your=20 > enthusiasm for the browser support. I believe that all=20 > current production browsers implement the feature you found=20 > using HTTP-authentication, not TLS/SSL. > Trying to create a user interface for this complex concept=20 > can't be easy, and the prevailing reason to use client=20 > certificates was for user authentication. Thus they took the=20 > most logical short-cut. >=20 > It is my understanding that IE7 will have true TLS/SSL=20 > client-certificate authentication.=20 >=20 > It is also my understanding that firefox current 1.5 has=20 > TLS/SSL client-certificate authentication. I had seen test=20 > results that indicated this was true.=20 > http://www.mozilla.org/projects/security/pki/nss/results.html >=20 > I have not been able to confirm this personally. >=20 > John >=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Wednesday, October 26, 2005 1:44 PM > To: Tom Petch; Moehrke, John (GE Healthcare); syslog@ietf.org > Subject: RE: Why not TLS was Re: [Syslog] Secure substrate -=20 > need your input >=20 >=20 > > TLS does support mutual node authentication. The healthcare=20 > > world has been using mutual-node-authenticated-TLS for over=20 > > three years. We use it often to ensure that a X-Ray device is=20 > > actually talking to the Picture Archiving Service. Both=20 > > systems need to know that they are talking to the right=20 > > 'other' system. This transaction doesn't need to have user=20 > > authentication as the process is fully automated. Indeed we=20 > > don't always turn on TLS encryption. But we do always do=20 > > mutual-authentication. Yes this means that there is a X.509=20 > > certificate managed for both nodes. But this certificate=20 > > management is not nearly as complex as person-certificates=20 > > (another discussion we can have on miss-understandings due to=20 > > the wrong questions being asked). > >=20 > > Tom- this one puzzles me. SSH has got server and client=20 > > authorisation defined in the I-Ds, soon to be RFCs. Reading=20 > > the TLS I-Ds I see no sign of client authorisation and since=20 > > that is a must for SNMP, then the note I quoted earlier, to=20 > > the isms list, saying that SASL would needed alongside TLS=20 > > made perfect sense (as I would expect since it came from the=20 > > Security AD:-). So where does mutual authentication come=20 > > from? What RFC or I-D defines it? Is it a proprietary=20 > > extension? Is it two simplex transmissions with only server=20 > > authentication? > > Sometimes it does matter to know what goes on under the=20 > > covers. (Of course, if client authentication is not needed=20 > > then this is academic). >=20 > Client auth is a fundamental feature of TLS. It is all over the TLS > RFC: > http://www.faqs.org/rfcs/rfc2246.html >=20 > Search it for "client authentication" or "client=20 > certificate". There are > whole sections on it. It is part of the initial SSL/TLS setup. Server > may require client-auth if configured so. =20 >=20 > If you don't believe that it is deployed, open you browser security > settings. John mentioned that not all browsers supports=20 > client certs for > SSL/TLS. Well... At least IE, Netscape, Firefox support it and had for > some time. In fact, they have pretty advanced features around client > certs. For example, you can use a different client cert with=20 > different > sites.=20 >=20 > The real question IMO, again, is whether or not symmetric=20 > auth (password > / shared secret based) is considered important. SSH has it. TLS does > not. If client certs are acceptable to people, then TLS is a perfect > solution. I think certificate-based infrastructure is more secure and > easier to manage in the end. No interactive user auth is needed for > syslog, as John mentioned. And if you store passwords instead=20 > of having > user type them in, then you are really only one-step away from using > certs. =20 >=20 > Thanks, > Anton.=20 >=20 >=20 > >=20 > > > > John > >=20 > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 26 15:57:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrOP-0007a9-9S; Wed, 26 Oct 2005 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrON-0007Zw-J6 for syslog@megatron.ietf.org; Wed, 26 Oct 2005 15:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19240 for ; Wed, 26 Oct 2005 15:56:44 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUrba-00080f-9J for syslog@ietf.org; Wed, 26 Oct 2005 16:10:39 -0400 Received: from pc6 (1Cust104.tnt27.lnd4.gbr.da.uu.net [62.188.154.104]) by blaster.systems.pipex.net (Postfix) with SMTP id 7784BE00027E; Wed, 26 Oct 2005 20:56:43 +0100 (BST) Message-ID: <004f01c5da5e$d89d5de0$0601a8c0@pc6> From: "Tom Petch" To: "Moehrke, John (GE Healthcare)" , References: <45A5295FFA1CBE4D9BF44E8534D2686C08F5A9D5@MKEMLVEM07.e2k.ad.ge.com> Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Date: Wed, 26 Oct 2005 20:55:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Miss information indeed on my part, thanks for putting me right. And yet, and yet, there was a reason why TLS alone would not work for SNMP and so SASL would be needed alongside TLS for that context, as the extract I quoted from the Security AD said. I will dig some more to find what it was. More generally, I would ask the chairs of this WG to see if their Security advisor has any generic thoughts on what protocols are appropriate. The isms group got one or two surprises along the way in this area, perhaps reflecting a preponderance of operations skills over security skills. Tom Petch ----- Original Message ----- From: "Moehrke, John (GE Healthcare)" To: "Tom Petch" ; Sent: Wednesday, October 26, 2005 8:34 PM Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input TLS Version 1.0 January 1999 RFC-2246 Section 7.4.6 Client Certificate I did assume that when you said "authorisation" that you really meant "authentication". If this assumption is wrong, then you have yet more questions to ask. Authorization is not handled by any of the protocols at this layer. John -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com] Sent: Wednesday, October 26, 2005 12:22 PM To: Moehrke, John (GE Healthcare); syslog@ietf.org Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Tom Petch ----- Original Message ----- From: "Moehrke, John (GE Healthcare)" To: Sent: Wednesday, October 26, 2005 6:07 PM Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input There is a miss understanding of the information I have seen given by many people on this list regarding TLS. I think this miss understanding is also being applied to SSH. So, SYSLOG needs to ask do they want to authenticate the user, machine, or both? Tom - yes, agree strongly but I don't know the answer. TLS does support mutual node authentication. The healthcare world has been using mutual-node-authenticated-TLS for over three years. We use it often to ensure that a X-Ray device is actually talking to the Picture Archiving Service. Both systems need to know that they are talking to the right 'other' system. This transaction doesn't need to have user authentication as the process is fully automated. Indeed we don't always turn on TLS encryption. But we do always do mutual-authentication. Yes this means that there is a X.509 certificate managed for both nodes. But this certificate management is not nearly as complex as person-certificates (another discussion we can have on miss-understandings due to the wrong questions being asked). Tom- this one puzzles me. SSH has got server and client authorisation defined in the I-Ds, soon to be RFCs. Reading the TLS I-Ds I see no sign of client authorisation and since that is a must for SNMP, then the note I quoted earlier, to the isms list, saying that SASL would needed alongside TLS made perfect sense (as I would expect since it came from the Security AD:-). So where does mutual authentication come from? What RFC or I-D defines it? Is it a proprietary extension? Is it two simplex transmissions with only server authentication? Sometimes it does matter to know what goes on under the covers. (Of course, if client authentication is not needed then this is academic). John _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Oct 27 09:42:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV81d-0003k6-BQ; Thu, 27 Oct 2005 09:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV81a-0003k1-IV for syslog@megatron.ietf.org; Thu, 27 Oct 2005 09:42:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00052 for ; Thu, 27 Oct 2005 09:42:18 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8Ex-0002QX-Ds for syslog@ietf.org; Thu, 27 Oct 2005 09:56:24 -0400 Received: from pc6 (1Cust22.tnt5.lnd4.gbr.da.uu.net [62.188.134.22]) by galaxy.systems.pipex.net (Postfix) with SMTP id 45075E0002B3; Thu, 27 Oct 2005 14:42:14 +0100 (BST) Message-ID: <06c301c5daf3$b2a39420$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA0E3C34@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Date: Thu, 27 Oct 2005 14:40:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I am not quite clear about this. In the I-D, it isn't really English (or American) that we are restricting SD-NAME to but, as the I-D says, to PRINTUSASCII except =3D SP ] " There are lots of other English characters - which this keyboard won't generate - we do not want to see in there:-) So far so good. But you seem to be saying more, that SD-NAME SHOULD be an English word, a= s opposed to German or French or .. as well as being limited to the charact= er set above. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" ; Sent: Monday, October 17, 2005 12:19 PM Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-proto= col-14 Anton: thanks for your reply. I agree that structured data can contain (and prob= ably does in a real use case) data that is also present in the MSG part. As of= this, there is need to support Unicode there, too. As you outline, STRUCTURED-D= ATA is mostly machine-processed. I do not fully agree that it won't be interpret= ed by a human, so there eventually is some hit by visual spoofing. This is accept= able as the security concerns are outweighted by the required functionality. However, there might still be one thing that we could consider to do: STRUCTURED-DATA consists of SD-IDs, PARAM-NAMEs and PARAM-VALUEs. Your ar= gument definitely shows that PARAM-VALUEs must support Unicode. But is it true f= or the other two entities, too? Will we loose required functionality for the international community if we restrict either SD-ID, PARAM-NAME or both t= o US-ASCII? If the answer is "no", then we can probably restrict some entit= ies. I know that local characters in these identifiers might be helpful. But is = it really something we MUST have? Let me use an example. In Germany, "M=FCller" (containing u with Umlaut -= =FC) is a common name. As such, a user name "M=FCller" is something we can have. No= w, if I encode this in (hypothetical) STRUCTRED-DATA, I may end up with something= like USER=3D"M=FCller" [PARAM-NAME =3D PARAM-VALUE] The "USER=3D" part should be locale- and language-ignorant - at least in = my point of view. So it is probably not a good idea that a German implementation w= ould encode it as BENUTZER=3D"M=FCller" ["Benutzer" is German for "User"] While the extension-mechanism for vendor- and experimental extensions doe= s not specify any details, it probably is a good idea to use English language t= ags in order to facilitate interpretation of the tags (and universal) adoption. = The extension mechanism should not be used as a translation tool. (Maybe this= is also something we should point out in syslog-protocol). But if we intend = to facilitate universal adoption of tags, we can probably require them to be English names. And in such a case, US-ASCII would be sufficient. Please do not misunderstand me. I am not suggesting that using local lang= uage is a bad thing per se. I also do not think of the use of English in this con= text as the use of the local language of e.g. the US and the British. I am thinki= ng about the use of English as the language of IT, the language that - at le= ast currently - lays the foundation for international collaboration (and as s= uch conceptually should not be tied to some nations). The fact that I am from= a non-native English speaking country might proove my point a little. My concern is that if we encourage implementors to create language-specif= ic tag names, interoperability might become a much bigger problem than when we s= tick with a single, universal (in this context!) language. I currently do not = see any samples where local-language tag names will actually be required. Maybe I= am overlooking the obvious. Maybe English is not sufficiently enough conside= red to be the "univesal language of IT", so that local policies might require ta= g names to be in local language. But at the same time, would this not also mean t= hat we would need to support not a single, universal, timestamp but rather a wea= lth of different local formats? Any feedback is deeply appreciated. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Friday, October 14, 2005 5:56 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Unicode - was: AD Review for > draft-ietf-syslog-protocol-14 > > Rainer: > > > So it might be useful to think about where we have an issue > > at all. The MSG field, I think, does not count as identifying > > information. It is meant as a human-readable message. Even > > though it obviously carries information, I think it is not > > subject to an easy visual spoofing attack. Ok, one can think > > about scenarios where visual spoofing might cause confusion, > > but the severity level of this should be fairly low. I think > > it has the same implications as hoax mails, where > > misinformation in the textual part is a simple fact of life > > and not avoidable without stopping to use that service. So I > > conclude that supporting the full set of Unicode characters > > inside MSG is fine. > > Agree. > > > The STRUCTURED-DATA is another story. Here, it includes > > information that might primarily be used as identifying > > information. > > Identifying, but mostly used by software that can filter > messages, which is not susceptible to visual character confusion. > > > Reviewing the current defined SD-IDs, I hardly > > see any need for using Unicode encoding. As far as I recall, > > we have selected Unicode instead of US-ASCII because we > > thought it might be benefitial for further extensions. > > However, given the fact of visual confusability and the need > > to deal with it, I am questioning if it acually is a good > > idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be > > better to use US-ASCII, which relievs us of all of these > > issues? So far, I do not see a compelling reason for full > > Unicode support in SD-IDs. > > With all due respect, I strongly disagree. Structured data > may include anything. It is just structured. It can contain > same pieces of information that may be found in the message. > > We have a very specific use-case where a structured element > is a username. And that username can be in Japanese. I can > see many other use-cases like this. Being from Germany, I am > sure you can easily come with some too. :) How about any > company name in a foreign language? Address? English is not > an exclusive language of system administration anymore. > > > Of course, we could just go ahead and document these issues > > in security considerations. I think, however, that we should > > try to solve them before resorting to that. I think we have a > > good chance of finding a workable solution. > > > > My suggestion to the WG is that we drop Unicode encoding for > > STRUCTURED-DATA and use printable US-ASCII instead. > > > > I would appreciate feedback on the following: > > > > #1 Is it OK the support Unicode - without restriction - in MSG? > > Well, the restriction is that we require use of the most > compact encoding as you mentioned. > > > #2 Is there support in the WG for changing STRUCTURED-DATA encoding > > from Unicode to US-ASCII? > > Not from me. :) In fact, I think it is very critical to > support non-ASCII in structured data. > > Thanks, > Anton. > > > > > If the answer to #2 is "no", please provide reasoning as that > > will help speed up the process. > > > > -- > > Rainer > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Oct 27 12:36:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAkL-0008Po-Et; Thu, 27 Oct 2005 12:36:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAkI-0008JG-OS for syslog@megatron.ietf.org; Thu, 27 Oct 2005 12:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13354 for ; Thu, 27 Oct 2005 12:36:38 -0400 (EDT) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVAxA-0002im-Tj for syslog@ietf.org; Thu, 27 Oct 2005 12:50:45 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id D839027C027 for ; Thu, 27 Oct 2005 18:34:00 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12979-09 for ; Thu, 27 Oct 2005 18:34:00 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4CFE727C018 for ; Thu, 27 Oct 2005 18:34:00 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 18:35:54 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2005 18:35:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3D01@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Thread-Index: AcXa/EQNSfte9NrVRziWZSww/9ybvgAF/HOw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 27 Oct 2005 16:35:54.0881 (UTC) FILETIME=[8054FF10:01C5DB14] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom,=20 > I am not quite clear about this. >=20 > In the I-D, it isn't really English (or American) that we are=20 I talked about English to say that US-ASCII is sufficient. I am somewhat = hesitant to put a requirement into the draft to actually use English. = Maybe in the appendix, but I don't think it is wise to do it in the = standards text. > restricting > SD-NAME to > but, as the I-D says, to > PRINTUSASCII except =3D SP ] " > There are lots of other English characters - which this=20 > keyboard won't > generate - we do not want to see in there:-) =20 Which ones do you think should be excluded, too? > So far so good. >=20 > But you seem to be saying more, that SD-NAME SHOULD be an=20 > English word, as > opposed to German or French or .. as well as being limited to=20 > the character set > above. see note above. Do you recommend we should actually make English an = requirement? Rainer >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Rainer Gerhards" > To: "Anton Okmianski (aokmians)" ;=20 > > Sent: Monday, October 17, 2005 12:19 PM > Subject: RE: [Syslog] Unicode - was: AD Review=20 > fordraft-ietf-syslog-protocol-14 >=20 >=20 > Anton: >=20 > thanks for your reply. I agree that structured data can=20 > contain (and probably > does in a real use case) data that is also present in the MSG=20 > part. As of this, > there is need to support Unicode there, too. As you outline,=20 > STRUCTURED-DATA is > mostly machine-processed. I do not fully agree that it won't=20 > be interpreted by a > human, so there eventually is some hit by visual spoofing.=20 > This is acceptable as > the security concerns are outweighted by the required functionality. >=20 > However, there might still be one thing that we could consider to do: > STRUCTURED-DATA consists of SD-IDs, PARAM-NAMEs and=20 > PARAM-VALUEs. Your argument > definitely shows that PARAM-VALUEs must support Unicode. But=20 > is it true for the > other two entities, too? Will we loose required functionality for the > international community if we restrict either SD-ID,=20 > PARAM-NAME or both to > US-ASCII? If the answer is "no", then we can probably=20 > restrict some entities. I > know that local characters in these identifiers might be=20 > helpful. But is it > really something we MUST have? >=20 > Let me use an example. In Germany, "M=FCller" (containing u=20 > with Umlaut - =FC) is a > common name. As such, a user name "M=FCller" is something we=20 > can have. Now, if I > encode this in (hypothetical) STRUCTRED-DATA, I may end up=20 > with something like >=20 > USER=3D"M=FCller" [PARAM-NAME =3D PARAM-VALUE] >=20 > The "USER=3D" part should be locale- and language-ignorant - at=20 > least in my point > of view. So it is probably not a good idea that a German=20 > implementation would > encode it as >=20 > BENUTZER=3D"M=FCller" ["Benutzer" is German for "User"] >=20 > While the extension-mechanism for vendor- and experimental=20 > extensions does not > specify any details, it probably is a good idea to use=20 > English language tags in > order to facilitate interpretation of the tags (and=20 > universal) adoption. The > extension mechanism should not be used as a translation tool.=20 > (Maybe this is > also something we should point out in syslog-protocol). But=20 > if we intend to > facilitate universal adoption of tags, we can probably=20 > require them to be > English names. And in such a case, US-ASCII would be sufficient. >=20 > Please do not misunderstand me. I am not suggesting that=20 > using local language is > a bad thing per se. I also do not think of the use of English=20 > in this context as > the use of the local language of e.g. the US and the British.=20 > I am thinking > about the use of English as the language of IT, the language=20 > that - at least > currently - lays the foundation for international=20 > collaboration (and as such > conceptually should not be tied to some nations). The fact=20 > that I am from a > non-native English speaking country might proove my point a little. >=20 > My concern is that if we encourage implementors to create=20 > language-specific tag > names, interoperability might become a much bigger problem=20 > than when we stick > with a single, universal (in this context!) language. I=20 > currently do not see any > samples where local-language tag names will actually be=20 > required. Maybe I am > overlooking the obvious. Maybe English is not sufficiently=20 > enough considered to > be the "univesal language of IT", so that local policies=20 > might require tag names > to be in local language. But at the same time, would this not=20 > also mean that we > would need to support not a single, universal, timestamp but=20 > rather a wealth of > different local formats? >=20 > Any feedback is deeply appreciated. > Rainer >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > > Sent: Friday, October 14, 2005 5:56 PM > > To: Rainer Gerhards; syslog@ietf.org > > Subject: RE: [Syslog] Unicode - was: AD Review for > > draft-ietf-syslog-protocol-14 > > > > Rainer: > > > > > So it might be useful to think about where we have an issue > > > at all. The MSG field, I think, does not count as identifying > > > information. It is meant as a human-readable message. Even > > > though it obviously carries information, I think it is not > > > subject to an easy visual spoofing attack. Ok, one can think > > > about scenarios where visual spoofing might cause confusion, > > > but the severity level of this should be fairly low. I think > > > it has the same implications as hoax mails, where > > > misinformation in the textual part is a simple fact of life > > > and not avoidable without stopping to use that service. So I > > > conclude that supporting the full set of Unicode characters > > > inside MSG is fine. > > > > Agree. > > > > > The STRUCTURED-DATA is another story. Here, it includes > > > information that might primarily be used as identifying > > > information. > > > > Identifying, but mostly used by software that can filter > > messages, which is not susceptible to visual character confusion. > > > > > Reviewing the current defined SD-IDs, I hardly > > > see any need for using Unicode encoding. As far as I recall, > > > we have selected Unicode instead of US-ASCII because we > > > thought it might be benefitial for further extensions. > > > However, given the fact of visual confusability and the need > > > to deal with it, I am questioning if it acually is a good > > > idea to encode STRUCTURED-DATA in Unicode. Wouldn't it be > > > better to use US-ASCII, which relievs us of all of these > > > issues? So far, I do not see a compelling reason for full > > > Unicode support in SD-IDs. > > > > With all due respect, I strongly disagree. Structured data > > may include anything. It is just structured. It can contain > > same pieces of information that may be found in the message. > > > > We have a very specific use-case where a structured element > > is a username. And that username can be in Japanese. I can > > see many other use-cases like this. Being from Germany, I am > > sure you can easily come with some too. :) How about any > > company name in a foreign language? Address? English is not > > an exclusive language of system administration anymore. > > > > > Of course, we could just go ahead and document these issues > > > in security considerations. I think, however, that we should > > > try to solve them before resorting to that. I think we have a > > > good chance of finding a workable solution. > > > > > > My suggestion to the WG is that we drop Unicode encoding for > > > STRUCTURED-DATA and use printable US-ASCII instead. > > > > > > I would appreciate feedback on the following: > > > > > > #1 Is it OK the support Unicode - without restriction - in MSG? > > > > Well, the restriction is that we require use of the most > > compact encoding as you mentioned. > > > > > #2 Is there support in the WG for changing=20 > STRUCTURED-DATA encoding > > > from Unicode to US-ASCII? > > > > Not from me. :) In fact, I think it is very critical to > > support non-ASCII in structured data. > > > > Thanks, > > Anton. > > > > > > > > If the answer to #2 is "no", please provide reasoning as that > > > will help speed up the process. > > > > > > -- > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Oct 27 14:21:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCNr-0005RM-V4; Thu, 27 Oct 2005 14:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCNq-0005Pf-2a for syslog@megatron.ietf.org; Thu, 27 Oct 2005 14:21:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20538 for ; Thu, 27 Oct 2005 14:21:32 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVCbE-0006Q4-MA for syslog@ietf.org; Thu, 27 Oct 2005 14:35:41 -0400 Received: from pc6 (1Cust25.tnt9.lnd4.gbr.da.uu.net [62.188.138.25]) by galaxy.systems.pipex.net (Postfix) with SMTP id 0CCD3E0002CD; Thu, 27 Oct 2005 19:21:30 +0100 (BST) Message-ID: <082801c5db1a$b59b1780$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA0E3D01@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Date: Thu, 27 Oct 2005 19:20:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Thursday, October 27, 2005 6:35 PM Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 > I am not quite clear about this. > > In the I-D, it isn't really English (or American) that we are I talked about English to say that US-ASCII is sufficient. I am somewhat hesitant to put a requirement into the draft to actually use English. Maybe in the appendix, but I don't think it is wise to do it in the standards text. Tom Yes, a comment about using English words in an appendix sounds like a good approach. > restricting > SD-NAME to > but, as the I-D says, to > PRINTUSASCII except = SP ] " > There are lots of other English characters - which this > keyboard won't > generate - we do not want to see in there:-) Which ones do you think should be excluded, too? Tom - I am happy with the list we've got. (I was thinking that English does have characters - somewhat obscure - with diacritic marks and these do not appear in USASCII; but they are not as significant as those in French or German so USASCII is perfectly adequate to express what is wanted; but adding any unqualified reference to English characters could be construed as including them). > So far so good. > > But you seem to be saying more, that SD-NAME SHOULD be an > English word, as > opposed to German or French or .. as well as being limited to > the character set > above. see note above. Do you recommend we should actually make English an requirement? Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Oct 27 15:29:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDR2-0000tA-UM; Thu, 27 Oct 2005 15:29:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDR0-0000ss-PL for syslog@megatron.ietf.org; Thu, 27 Oct 2005 15:29:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24147 for ; Thu, 27 Oct 2005 15:28:55 -0400 (EDT) Message-Id: <200510271928.PAA24147@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDeQ-0008L6-5X for syslog@ietf.org; Thu, 27 Oct 2005 15:43:03 -0400 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc14) with SMTP id <2005102719285701400ssg3de>; Thu, 27 Oct 2005 19:28:58 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Rainer Gerhards'" , Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Date: Thu, 27 Oct 2005 15:28:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXbI3JsZBGFH3dmSEOocJW1SI3GLgAB9gTg In-Reply-To: <082801c5db1a$b59b1780$0601a8c0@pc6> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > see note above. Do you recommend we should actually make > English an requirement? I think that would be a mistake. For a vendor, e.g. a Chinese vendor, who produces switches that are sold only to the Chinese market, whose customers speak primarily Chinese and have limited English skills, forcing implementers to hire translators to translate their syslog messages into English and USASCII, and forcing their customers to hire translators to translate the syslog messages back into Chinese so they can understand them is simply stupid. We should make the character set UTF-8, not USASCII, so the whole world can send messages in the language that best suits their customers' environments. For many of those environments, English will be the language of choice because it is widely used in the IT world. But we should not force vendors to implement in languages that are inapprorpriate for their audiences. If we want to force standardization, let's focus on the message content rather than standardizing the language the proprietary content is expressed in. David Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Oct 28 02:04:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNM8-0003LT-Ro; Fri, 28 Oct 2005 02:04:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNM6-0003Jg-Tv for syslog@megatron.ietf.org; Fri, 28 Oct 2005 02:04:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23634 for ; Fri, 28 Oct 2005 02:04:29 -0400 (EDT) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVNZ6-0001z1-NN for syslog@ietf.org; Fri, 28 Oct 2005 02:18:45 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 903A027C027 for ; Fri, 28 Oct 2005 08:01:59 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24115-01 for ; Fri, 28 Oct 2005 08:01:59 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4551727C018 for ; Fri, 28 Oct 2005 08:01:59 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 08:03:54 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Oct 2005 08:03:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3D04@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Unicode - was: AD Review fordraft-ietf-syslog-protocol-14 Thread-Index: AcXbI3JsZBGFH3dmSEOocJW1SI3GLgAB9gTgABZRrEA= From: "Rainer Gerhards" To: X-OriginalArrivalTime: 28 Oct 2005 06:03:54.0738 (UTC) FILETIME=[60941D20:01C5DB85] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org David, I think this thread got a little out-of-sync. I think there is no doubt about the fact that syslog must support all international languages, so that any local information can be conveyed. This was one of the major driving factors behind syslog-protocol. What I have been discussing with Tom here is wheter or not the *tag* (SD-IDs) need to have full international support. The SD-Ids are identifying information, you might think of them like extended header-fields or - maybe a better example - like XML tags. They identify the information that is provided in a given element. =20 The full reasoning is given in=20 http://www.mail-archive.com/syslog%40lists.ietf.org/msg00013.html Rainer > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, October 27, 2005 9:28 PM > To: 'Tom Petch'; Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Unicode - was: AD Review=20 > fordraft-ietf-syslog-protocol-14 >=20 > =20 >=20 > > see note above. Do you recommend we should actually make=20 > > English an requirement? >=20 > I think that would be a mistake.=20 >=20 > For a vendor, e.g. a Chinese vendor, who produces switches that are > sold only to the Chinese market, whose customers speak primarily > Chinese and have limited English skills, forcing implementers to hire > translators to translate their syslog messages into English and > USASCII, and forcing their customers to hire translators to translate > the syslog messages back into Chinese so they can understand them is > simply stupid. >=20 > We should make the character set UTF-8, not USASCII, so the whole > world can send messages in the language that best suits their > customers' environments. For many of those environments, English will > be the language of choice because it is widely used in the IT world. > But we should not force vendors to implement in languages that are > inapprorpriate for their audiences. >=20 > If we want to force standardization, let's focus on the message > content rather than standardizing the language the proprietary content > is expressed in. >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog