Date: Thu, 24 Apr 2003 08:31:35 -0600 From: brett.w.steinicke@l-3com.com Subject: Remote syslog message retrieval I have a question for consideration. I was looking over the draft syslog mib and wondered why there is no mechanism to retrieve messages that have been stored locally on the remote device? I realize that under normal operation the device would be sending its syslog messages to a syslog server. However, there are situations where the syslog server may have been unreachable for a period of time. It would be nice if the locally-stored messages could be read via SNMP. Brett ------------------------------ Date: Fri, 23 May 2003 05:24:40 -0700 (PDT) From: Chris Lonvick Subject: Meeting in Vienna? Hi Folks, Would anyone like to have a WG meeting in Vienna? I believe that the open items are: - - Completion of syslog-sign ID - On track with Jon getting a new revision ready. - - Completion of the syslog-mib ID - On track with Glenn working on a revision from comments from the WG meeting at IETF56. - - Need to prepare an ID on the internationalization of the messages. The current methods are to transport US-ASCII only. I've been talking with someone who may be interested in drafting that work. If you have thoughts on the subject, please bring them up to the list. - - Waiting to see what happens with the Enns draft and NetConf. http://www.ietf.org/internet-drafts/draft-enns-xmlconf-spec-00.txt RFC 3195 has been proposed as the basis for the transport for NetConf (formerly the XMLconf effort) and the WG accepted at IETF56 that NetConf requirements may influence the updating of this work. Does anyone have any other items for the group? From that, I don't think that the WG has any issues that need to be discussed/resolved at IETF57. If anyone thinks that we do, please bring it up to the list. I'll be glad to call a meeting if we do. Thanks, Chris ------------------------------ Date: Fri, 30 May 2003 07:15:41 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-syslog-sign-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog-Sign Protocol Author(s) : J. Kelsey, J. Callas Filename : draft-ietf-syslog-sign-11.txt Pages : 40 Date : 2003-5-29 This document describes syslog-sign, a mechanism adding origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to syslog. Syslog-sign provides these security features in a way that has minimal requirements and minimal impact on existing syslog implementations. It is possible to support syslog-sign and gain some of its security attributes by only changing the behavior of the devices generating syslog messages. Some additional processing of the received syslog messages and the syslog-sign messages on the relays and collectors may realize additional security benefits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sign-11.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-sign-11.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. ------------------------------ Date: Wed, 04 Jun 2003 15:12:41 +0100 From: "ALbert@ons-huis.net" Subject: My comments on syslog-sign draf-11 Hoi (dutch for hello:-) I've been a bit passive lately, but starting to catch up ... Yesterday, I downloaded draft-11, and I see a lot of work has been spent on it. Great work! Also, I continued implementing it and so I found a few items. Furthermore, I did see some improvements to the "old" syslog protocol are made, like long timestamp and long hostname. Great! I know, there has been a bit of discussion about that. I didn't follow that (actively), and _*_don't_*_ want to start that thread again! However, I will raise some remarks on the current draft issuing those. Things I find hard to understand/implement. Please comment on them, by pointing to those threads, (of I missed them). Or maybe the text can be a little clearer. Again, I welcome the improvements. I only raise them to understand (and clarify) how to implement that for an environment where both "rfc3164" and "syslog-sign" should be operated. (mixed). The order of the issues is unsorted, but for the items issuing "compatibility", which can be found at the end. GENERAL (by topic) ================== * TAG (Page 9) - -------------- Would it be an improvement to allow a dot (.) in the tag. In general a tag will contain a programname, and a process id like: ``name[number]:'' In some environments, it should welcome (I assume) to extent this an detail a thread-ID. When a dot is allowed the "number" can formatted as a partial-number instead of an int, giving space to an thread id. Note: this enhancement will not break rfc3164, as the tag (then) is part of the "free formatted" part. * "message flow" (introduction) - ------------------------------- Although I do understand the setup of syslog-sign and how certificates should be chained to groups of messages, possible (new) readers will find it hard to understand. The explain syslog, I use the word "flow" (or path) and notice that this generally is understand well. Therefore, I suggest to extent the introduction a little, to explain that messages are routed and so create one or more "flows". And that is in important that several flows can be separated and use other "signatures" (to skip a few details). I'm willing write a proposal. * Spaces and crypto (P 16 sec 3.10) - ------------------------------------ The current proposal solves my earlier remark(s) about exactness of spaces! However, this implies the crypto routines become complicated. Does everybody accepts this? (Just to mention the topic) * Signature over .. (P16 & P20 (Sec 3.10 & 4.3.8) - -------------------------------------------------- Possible, someone will misread these sections (which fields are used to calculated the signature). Maybe we should add a line as `` So the signature is calculated over the completely formatted syslog-message, excluding spaces between field, and also excluding this signature field.'' COMPATIBILITY ============== General - ------- Syslog-sign claims to use only "valid" rfc3164 messages (which is compatible: the can be routed by rfc3164 relays) However, some extensions break this. In rfc3164 is written the HOSTNAME should be without a domain. syslog-sign changes this. On page 6 is written "a sender SHOULD ..." use the long version. This means I can not write syslog-sign-daemon that uses short-hostname (to be able so send to "old" syslogd's) and use signatures at the same time. Iff that is true, I will break the rfc:-) This applies both to HOSTNAME and TIMESTAMP. Detail: an alternative is "repeating" hostname and timestamp in the "free format" part of rfc3164, as that rfc suggest. Section 3.1 (page 11) - --------------------- The remark "don't need to be backward compatible" is _wrong_. rfc3164-relays are allowed to route on (e.g.) hostname. So, the should be able to parse HOSTNAME. Which means only HOSTNAME-3164 formatted headers should be used! Only a "device" must to understand syslog-sign. And the (offline) signature-checker. Both relay and collector can route en store all kind of (UDP) syslog messages! Note: this implies the collector should store messages as-is, including the PRI field. Most syslogd's don't do so; but that is a implementation detail. I have a syslogd, that does store transparent, to be able to use offline -sign verification! Conclusion - ---------- Least but not last, I think I can implement syslog-sign "know". Which (for me) means it the draft is clear. This implies the remarks are mainly suggestions to improve the document, not the standard. John and Jon (and others) GREAT WORK! - -- - --ALbert Mietus Send prive mail to: albert@ons-huis.net Send business mail to: albert.mietus@PTS.nl