Status report on syslog BOF outcome As I reported last week, the syslog BOF was held at the 46th IETF as scheduled. Discussion was mixed positive and negative on redesign of a logging protocol, but there was general recognition of the security problems with the current syslog implementation. From the minutes (see ftp://ftp.3com-ne.com/pub/syslog/bof-minutes.txt): > Open discussion comments: > > - An encryption algorithm should not be considered as a factor in this > effort even for low-end devices. > > - TLS and/or IPSec protect the sessions and not the records > themselves. This separates transport and storage. > > - Should this group get into the secure storage of records or keep to > the secure delivery of them? > > - Are strong authentication and tamper proofing needed? > > - A lot of the prior work was dealing with the transport of financial > records. All of this may not be fully needed for the secure > transport and storage of syslog messages. > > - Some messages may need crypto and some may not. This may be an > option. > > - Logs must be kept confidential as is required in certain countries. > > - Some systems need specific protection in different environments > (confidentiality, authentication, etc.). Some properties may not be > needed (anonymity?). Stored records need to be stored in clear-text > so they may be read and manipulted. The Schneier work is not needed > for this application. > > - Scenarios should be given for use in different environments. > > - There must not be any conflict with the workings of the IDWG. > > - The solutions proposed should use "common, off-the-shelf tools wherever > possible." > > - The message format must be excluded from the efforts of the WG. > > - The WG must focus on the protocols only. > > - Message formats are not in scope of this WG (if formed). > > - The IDWG (Intrusion Detection WG) has the authority to describe their message >formats. There has been no firm decision by the IESG on how to proceed with this BOF, but as the attached message from a Security Area director indicates, we have a good chance of getting this work recognized by the IETF if there is both some agreement on a specification among a large group of interested parties, and running code that implements the specification. As he indicates, > The IETF is strongly biased toward "running code." I would encourage > all to actually put together implementations. Given the subject matter > a "drop in" replacement for syslog would be the form of "running code" > for this group. I take this to mean that any replacement should observe the syslog(3) API at each UNIX client. Semantics of the parameter lists can be extended (e.g. more facilities can be added) but there should be general backwards compatibility to allow existing client applications to use the replacement with only relinking. It does not seem necessary to retain the syslogd.conf(4) specification. I believe it's appropriate to write up any possible candidate protocol (NOT file format) as an Internet Draft, i.e. draft RFC. Any code authors who would like to be part of a possible WG process should make both implementation code and a protocol specification in draft RFC form available. It seems that the XML encoding of the ULM data model, which we've discussed on this list prior to the BOF and which is described in a rough draft at ftp://ftp.3com-ne.com/pub/syslog/drafts/calabrese/xml-log.txt does not fit well with a requirement that the syslog(3) client API be retained. However, it's probably still worth developing this approach for discussion; to be considered there must be a prototype implementation. Is anyone interested in trying implementation of a DTD, client, and server? I'm ready to help within my resources but this would not be a funded 3Com project. Thanks again for your support and participation. -- Alex Brown <[EMAIL PROTECTED]> +1 617 504 8761 <[EMAIL PROTECTED]> +1 508 323 2283Return-Path: <[EMAIL PROTECTED]> Received: from ruebert.ieee.org (ruebert.ieee.org [199.172.136.3]) by world.std.com (8.9.3/8.9.3) with ESMTP id VAA03201 for <[EMAIL PROTECTED]>; Sat, 20 Nov 1999 21:38:18 -0500 (EST) Received: from gemini.ieee.org by ruebert.ieee.org (8.9.3/8.9.3) with ESMTP id VAA02144; Sat, 20 Nov 1999 21:38:16 -0500 (EST) Received: from rw-101.mit.edu (RW-101.MIT.EDU [18.101.0.17]) by gemini.ieee.org (8.9.3/8.9.3) with ESMTP id VAA05922 for <[EMAIL PROTECTED]>; Sat, 20 Nov 1999 21:38:14 -0500 (EST) Received: from rw-101.mit.edu (localhost [127.0.0.1]) by rw-101.mit.edu (8.8.7/8.8.7) with SMTP id VAA00800; Sat, 20 Nov 1999 21:12:42 -0500 From: Jeffrey Schiller <[EMAIL PROTECTED]> Date: Sun, 21 Nov 1999 02:12:42 GMT Message-ID: <[EMAIL PROTECTED]> Subject: Re: Syslog BOF: should I continue with draft IDs? To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> X-Mailer: Mozilla/4.5 [en] (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by world.std.com id VAA03201 Content-Transfer-Encoding: 8bit You should take the documents you have and submit them to the Internet Drafts directory. I would also encourage the folks pushing for the XML approach to post their documents as well. The IETF is strongly biased toward "running code." I would encourage all to actually put together implementations. Given the subject matter a "drop in" replacement for syslog would be the form of "running code" for this group. -Jeff >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 11/15/99, 4:12:10 PM, [EMAIL PROTECTED] wrote regarding Syslog BOF: should I continue with draft IDs?: > Hello Jeff -- > I need to know how to proceed with the ID material we've developed in > preparation for the syslog BOF (descriptive BCP rough ID, XML-encoded ULM > rough ID -- see ftp://msg.ne.mediaone.net). > I wrote to "Chris M. Lonvick" <[EMAIL PROTECTED]> who has spoken with you > and Marcus Leech about a future syslog WG and would like to chair it: > "I'm happy to have you chair the WG -- thanks. I've already begun to split > the BCP draft as we discussed, and these two drafts (informational draft > recording UNIX syslog, and UNIX syslog Best Common Practice draft) could > indeed be available in the next few weeks as I indicated. I don't think > there's any good reason for delay, and I'd like to get this completed as > soon as possible." > and Chris replied: > "The document editor that Marcus recommended was the person that originally > wrote syslog. The implication (that I heard ;-) was that it would be > really nice to have his name on the RFC." > I have no problem with his name appearing on it, but I think it needs to be > done promptly. I can continue with the draft ID material I've already > written and produce the informational draft for his review. However, > unless he can contribute to the security discussion and BCP draft, I don't > feel he should have authorship there. Unfortunately, the BCP ID would > follow and refer to the informational ID, so I also don't think it's > appropriate to wait until he's satisfied. > I also would like to know what to do with the draft ID proposal for XML > encoding of ULM - since ULM is expiring this month. The author > <[EMAIL PROTECTED]> is willing to complete the draft, and > Volker Wiegand <[EMAIL PROTECTED]> is willing to implement a prototype > following further discussion. My sense of the XML digital signature > presentation was that it's not quite ready for prime time, but that too > might be tested as an authentication wrapper. This whole approach might > yield a prototype TCP syslog replacement very quickly. > The sense I got from comments at the BOF, however, was that any syslog > replacement protocol requirements or specification was out of scope of the > WG. Certainly the security issues are only a part of any log system > design. > How do you think I should proceed? > Alex Brown <[EMAIL PROTECTED]> +1 508 323 2283 > NB: Material from this BOF is still available at > ftp://msg.ne.mediaone.net/pub.
