RE: [Syslog] #5 - character encoding (was: Consensus?)
Chris: I think having SD-ID with [enc="utf-8" lang="English"] may be a good approach. If different language use utf-8 encoding, then "lang=" can distinguish it. Also want to clarify that you suggest that if the message is in ASCII, it will not required SD-ID, but for all other encodings, SD-ID will be required. Note most other encoding methods already imply the language used, for example, in Chinese, there are several encoding methods, Traditional Chinese used in Taiwan and Hong Kong is Big5, and simplified Chinese used in Mainland China is GBK, so if the message is in traditional Chinese char, it will be shown as [enc="Big5", lang="Traditional Chinese"], a little bit redundant. The Big5 also includes all English char so it can be a mix of Chinese and English. Regards, Sheran -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick (clonvick) Sent: Tuesday, November 29, 2005 10:22 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Hi Rainer, Why don't we look at it from the other direction? We could state that any encoding is acceptable - for ease-of-use/migration with existing syslog implementations. It is RECOMMENDED that UTF-8 be used. When it is used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" lang="en"] Thoughts? All: Let's discuss this and close this issue. Thanks, Chris On Tue, 29 Nov 2005, Rainer Gerhards wrote: > Chris & WG, > >>> #5 Character encoding in MSG: due to my proof-of-concept >>> implementation, I have raised the (ugly) question if we need >>> to allow encodings other than UTF-8. Please note that this >>> question arises from needs introduced by e.g. POSIX. So we >>> can't easily argue them away by whishful thinking ;) >>> >>> Not even discussed yet. >> >> I haven't reviewed that yet. However, I'll note that allowing >> different encoding can be accomplished in the future as long as we >> establish a default encoding and a way to identify it in our current >> work. > > I have read a little in the mailing archive. Please note that in 2000 > it was consensus that the MSG part may contain encodings other then > US-ASCII. Follow this threat: > > http://www.syslog.cc/ietf/autoarc/msg00127.html > > This discussion lead to RFC 3164 saying "other encodings MAY be used". > While this was observed behaviour, we need still to be aware that the > POSIX (and glibc) API places the restrictions on us that we simply do > not know the character encoding used by the application. As such, no > *nix syslogd can be programmed to be compliant to syslog-protocol if > we demand UTF-8 exclusively. > > I propose that we RECOMMEND UTF-8 that MUST start with the Unicode > Byte Order Mask (BOM) if used. If the MSG part does not start with the > BOM, it may be any encoding just as in RFC 3164. I do not see any > alternative to this. > > 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
[Syslog] Syslog sign - draft 17 (draft-ietf-syslog-sign-17.txt)
Hello, I just wanted to let you all know that I have submitted a new draft of syslog sign, as the old one was about to expire. The new draft should appear shortly if it hasn't already; here is a summary of the changes and updates that were made. The changes were along the lines of what was presented at the Vancouver meeting, the most important of which concerns utilizing structured data to capture the fields of Signature and Certificate Blocks - a prudent use of structured data which avoids having a payload that is essentially "binary". Of course, unfortunately syslog-protocol now appears to be further away from completion than it did earlier, and really we would like syslog protocol to be stable to that respect before basing further work on that. However, at the same time, the consensus of the group by and large seems to be to retain structured data, so this provides perhaps a view of how it can be utilized. At the same time, please note that syslog sign as currently worded is actually not dependent on a specific syslog protocol syntax - if you will, you could send syslog messages with a message body that happens to be formatted respectively conform to the syntax as set forth in syslog-sign. Note that the Payload Block format was not changed. Payload Blocks are essentially carried as part of Certificate Blocks; those utilize structured data, but as Payload Blocks are not associated with an actual syslog message directly it seems as if it is not necessary to change the way Payload Blocks are encoded. Quite possibly, this will of course be subject to further discussion. The cookie field was removed. Identification of a Signature Block respectively Certificate Block can occur through use of an according SD-ID. Another modification that was made, which will surely require more discussion, concerns the reboot session ID. For devices to be able to conform to this, they would need to be able to persist the reboot session ID such that it survives reboots (so to be able to increment after a reboot). The question is to allow for the possibility of allowing devices who cannot support such a feature to still support syslog-sign, with the understanding that in this case, there would be no guarantee that messages would be uniquely distinguished across reboots. It appears that this would still be useful, provided it can be easily distinguished whether or not reboot session ID is supported, which can be accomplished by the choice of ID (0 if not supported, 1 through 99 otherwise). Comments or thoughts? Beyond that, you will find a number of editorial updates with the goal of making the document slightly more readable. Updated sections include for example section 4.4 on Signature Group and Signature Priority. There is of course more work to be done. In addition on closing on the suggested items, one aspect that is currently not addressed and requires discussion concerns any aspects about the message header of syslog messages carrying a Signature or Certificate Block - for example, assignment of a message ID, proper PRI etc. Looking forward to fruitful discussions --- Alex ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] I-D ACTION:draft-ietf-syslog-sign-17.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 : Signed syslog Messages Author(s) : J. Kelsey, et al. Filename: draft-ietf-syslog-sign-17.txt Pages : 33 Date: 2005-11-29 This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification draws upon the work defined in RFC xxx, "The syslog Protocol", however it may be used atop any message delivery mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", or in the RAW mode of "RFC 3195, "The Reliable Delivery of syslog". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-17.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] 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-sign-17.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: [EMAIL PROTECTED] In the body type: "FILE /internet-drafts/draft-ietf-syslog-sign-17.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. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Consensus on Charter?
Darren, I am not long enough with the IETF to know how much trouble it is to recharter - but I think whatever it is, it is acceptable. You very correctly said that we need to do baby steps. And as a matter of past discussions, it seems to be necessary to explicitely exclude some things to get the first steps done. So, yes, I would accept it. Rainer > -Original Message- > From: Darren Reed [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 29, 2005 7:46 PM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] Consensus on Charter? > > > > Are we happy to recharter when these are done to cover TCP ? > > Darren > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #5 - character encoding (was: Consensus?)
Chris, I think that is a good compromise. It would also enable us to convey the enconding information if we have it (anyhow, in that case it would be more smarter to convert to UTF-8, but that's not yet important). Rainer > -Original Message- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 29, 2005 7:22 PM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > > Hi Rainer, > > Why don't we look at it from the other direction? We could > state that any > encoding is acceptable - for ease-of-use/migration with > existing syslog > implementations. It is RECOMMENDED that UTF-8 be used. When it is > used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" > lang="en"] > > Thoughts? > > All: Let's discuss this and close this issue. > > Thanks, > Chris > > On Tue, 29 Nov 2005, Rainer Gerhards wrote: > > > Chris & WG, > > > >>> #5 Character encoding in MSG: due to my proof-of-concept > >>> implementation, I have raised the (ugly) question if we need > >>> to allow encodings other than UTF-8. Please note that this > >>> question arises from needs introduced by e.g. POSIX. So we > >>> can't easily argue them away by whishful thinking ;) > >>> > >>> Not even discussed yet. > >> > >> I haven't reviewed that yet. However, I'll note that allowing > >> different encoding can be accomplished in the future as long as we > >> establish a default encoding and a way to identify it in > our current > >> work. > > > > I have read a little in the mailing archive. Please note > that in 2000 > > it was consensus that the MSG part may contain encodings other then > > US-ASCII. Follow this threat: > > > > http://www.syslog.cc/ietf/autoarc/msg00127.html > > > > This discussion lead to RFC 3164 saying "other encodings > MAY be used". > > While this was observed behaviour, we need still to be > aware that the > > POSIX (and glibc) API places the restrictions on us that we > simply do > > not know the character encoding used by the application. As > such, no > > *nix syslogd can be programmed to be compliant to > syslog-protocol if > > we demand UTF-8 exclusively. > > > > I propose that we RECOMMEND UTF-8 that MUST start with the Unicode > > Byte Order Mask (BOM) if used. If the MSG part does not > start with the > > BOM, it may be any encoding just as in RFC 3164. I do not see any > > alternative to this. > > > > 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
Re: [Syslog] Consensus on Charter?
Are we happy to recharter when these are done to cover TCP ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #5 - character encoding (was: Consensus?)
> Hi Rainer, > > Why don't we look at it from the other direction? We could state that any > encoding is acceptable - for ease-of-use/migration with existing syslog > implementations. It is RECOMMENDED that UTF-8 be used. When it is > used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" lang="en"] > > Thoughts? I think this is a very sensible approach. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #5 - character encoding (was: Consensus?)
Hi Rainer, Why don't we look at it from the other direction? We could state that any encoding is acceptable - for ease-of-use/migration with existing syslog implementations. It is RECOMMENDED that UTF-8 be used. When it is used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" lang="en"] Thoughts? All: Let's discuss this and close this issue. Thanks, Chris On Tue, 29 Nov 2005, Rainer Gerhards wrote: Chris & WG, #5 Character encoding in MSG: due to my proof-of-concept implementation, I have raised the (ugly) question if we need to allow encodings other than UTF-8. Please note that this question arises from needs introduced by e.g. POSIX. So we can't easily argue them away by whishful thinking ;) Not even discussed yet. I haven't reviewed that yet. However, I'll note that allowing different encoding can be accomplished in the future as long as we establish a default encoding and a way to identify it in our current work. I have read a little in the mailing archive. Please note that in 2000 it was consensus that the MSG part may contain encodings other then US-ASCII. Follow this threat: http://www.syslog.cc/ietf/autoarc/msg00127.html This discussion lead to RFC 3164 saying "other encodings MAY be used". While this was observed behaviour, we need still to be aware that the POSIX (and glibc) API places the restrictions on us that we simply do not know the character encoding used by the application. As such, no *nix syslogd can be programmed to be compliant to syslog-protocol if we demand UTF-8 exclusively. I propose that we RECOMMEND UTF-8 that MUST start with the Unicode Byte Order Mask (BOM) if used. If the MSG part does not start with the BOM, it may be any encoding just as in RFC 3164. I do not see any alternative to this. 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
Re: [Syslog] Consensus on Charter?
Hi Rainer, I've already sent my comments to Sam including the v2 of the charter. I'm still waiting on feedback from him. The proposed charter below looks good. Please do send your comments to him. As he said, it's good to send them to the WG list as well. Thanks, Chris On Tue, 29 Nov 2005, Rainer Gerhards wrote: Chris, WG: as you are probably aware, Sam's deadline for comments about the future of this WG is quickly approaching (it is December, 1st). I plan to formally update my comment. To do so, I would like to know if we have reached consensus on the charter. I have taken the liberty to merge some changes discussed on-list into v2 of Chris' charter proposal. Is this the charter we are looking for? I would appreciate quick feedback because I have to write my mail to Sam tomorrow. Rainer MODIFIED Version of Chris's v2 of proposed charter === Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. While compatability with existing syslog systems is desirable, research shows that these are so diverse that there is nothing in common amongst them apart from so that whilst that field will be retained, other fields may not be. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. - A MIB definition for syslog will be produced. === === ___ 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] Consensus on Charter?
Chris, WG: as you are probably aware, Sam's deadline for comments about the future of this WG is quickly approaching (it is December, 1st). I plan to formally update my comment. To do so, I would like to know if we have reached consensus on the charter. I have taken the liberty to merge some changes discussed on-list into v2 of Chris' charter proposal. Is this the charter we are looking for? I would appreciate quick feedback because I have to write my mail to Sam tomorrow. Rainer MODIFIED Version of Chris's v2 of proposed charter === Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. While compatability with existing syslog systems is desirable, research shows that these are so diverse that there is nothing in common amongst them apart from so that whilst that field will be retained, other fields may not be. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. - A MIB definition for syslog will be produced. === === ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #5 - character encoding (was: Consensus?)
Chris & WG, > > #5 Character encoding in MSG: due to my proof-of-concept > > implementation, I have raised the (ugly) question if we need > > to allow encodings other than UTF-8. Please note that this > > question arises from needs introduced by e.g. POSIX. So we > > can't easily argue them away by whishful thinking ;) > > > > Not even discussed yet. > > I haven't reviewed that yet. However, I'll note that > allowing different > encoding can be accomplished in the future as long as we establish a > default encoding and a way to identify it in our current work. I have read a little in the mailing archive. Please note that in 2000 it was consensus that the MSG part may contain encodings other then US-ASCII. Follow this threat: http://www.syslog.cc/ietf/autoarc/msg00127.html This discussion lead to RFC 3164 saying "other encodings MAY be used". While this was observed behaviour, we need still to be aware that the POSIX (and glibc) API places the restrictions on us that we simply do not know the character encoding used by the application. As such, no *nix syslogd can be programmed to be compliant to syslog-protocol if we demand UTF-8 exclusively. I propose that we RECOMMEND UTF-8 that MUST start with the Unicode Byte Order Mask (BOM) if used. If the MSG part does not start with the BOM, it may be any encoding just as in RFC 3164. I do not see any alternative to this. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #1 - RFC3164, was: Consensus?
Darren & WG: I have used this morning to compile a short list of currently existing and deployed syslogds. As I suggested, I have sent several messages to them. I suggest you have a look at the results at http://www.syslog.cc/ietf/existing-syslog.html I do not see much in that result backing the theory that retaining the old-style timestamp would do any good. Maybe I am overlooking the obvious, so you can point me. Ah, yes: Of course I see that sometimes the 3164 timestamp survives in the first column of the log entry where the -protocol formatted does not. But when I look at relaying, I think it is far better to have the timestamp replaced by the time of reception than to have it throw away. In most cases, digital signatures would be borken anyhow. Surprisingly, the -protocol formatted message has a better chance to survive being relayed by existing syslogd than the RFC 3164 formatted message. I propose that we accept this testing as proof of irrelevance of sticking with the rfc 3164 timestamp. Anybody with a different view please object. Rainer > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed > Sent: Tuesday, November 29, 2005 7:39 AM > To: Anton Okmianski (aokmians) > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] #1 - RFC3164, was: Consensus? > > [ Charset ISO-8859-1 unsupported, converting... ] > > Which system is this source from? > > BSD > > > On Solaris, if you send \r\n characters, you will see > "^M\n" in the log. > > Yes and Solaris allows for non-ascii data through the use of escaping. > > Darren > > ___ > 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
