Subject: Remote syslog message retrieval
From: [email-masked]
Date: Thu, 24 Apr 2003 08:31:35 -0600

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 <[email-masked]>
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: [email-masked]
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:
	[email-masked].
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: "[email-masked]" <[email-masked]>
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:      [email-masked]
Send business  mail to: [email-masked]