Subject: RFC 3195 syslog daemons?
From: Tom Perrine <[email-masked]>
Date: Tue, 10 Dec 2002 09:52:07 -0800

Last week I posted an announcement of SDSC's secure syslog project to
the Loganalysis mailing list.  The announcement was fully
buzzword-compliant, as required by tradition :-)  It was also /.'ed

Christopher Lonvick <[email-masked]> has asked that I post the
same announcement here  (see below).  We are *really* looking for other RFC 3195
compliant syslog systems to test with.  Are there any, especially
non-proprietary?

- ----------------------------------------
Announcing SDSC Secure Syslog (Release Candidate)

The Security Technologies group at the San Diego Supercomputer Center
(SDSC) is pleased to announce the early availability of "SDSC secure
syslog", a replacement for the standard Linux/UNIX syslog daemon that
adds security and performance features, while retaining backwards
compatibility.

We believe it is the first syslog implementation to target
"syslog-reliable" (RFC 3195) functionality and it is the first syslog
targeted at very high performance and forensically-sound auditing.

The project home page is at:
http://security.sdsc.edu/software/sdsc-syslog

Authors of other RFC3195-compliant software, please contact us at
[email-masked], so we can explore inter-operability testing with
you.

This is a release candidate for version 1.0.

SDSC syslog is intended as a high-performance and high-security
replacement for "syslog classic".  It is intended for sites with high
volumes of syslog transactions that also want security and integrity
features and compatibility with new audit standards.

SDSC syslog is a complete new design incorporating new features and
capabilities, including:
    *modular
	*input modules for socket, UDP network connections,
	    TCP/BEEP, etc.
	* a message switch to perform log message routing
	* multiple output modules for UDP, TCP/BEEP, "syslog
        classic" files, structured files

    *multi-processing - handles more input syslog steams, provides
        better scalability
    *support for draft standards such as "syslog-reliable" (RFC
        3195, syslog messages over BEEP)

This Release Candidate does not yet have complete support for
RFC 3195, but is fully backwards compatible with "syslog classic"
using 514/UDP.

Note that this software ***currently*** carries the standard
University of California copyright statement, permitting free use for
educational and non-profit activities.  We are exploring a transition
to an Open Source license, such as the "BSD license".  This requires
completion of the pending approval of the University of California.

- ----------------------------------------

- -- 
Tom E. Perrine <[email-masked]> | San Diego Supercomputer Center
http://www.sdsc.edu/~tep/     |

------------------------------

Date: Tue, 10 Dec 2002 11:23:30 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: RFC 3195 syslog daemons?

> Last week I posted an announcement of SDSC's secure syslog project to
> the Loganalysis mailing list.  The announcement was fully
> buzzword-compliant, as required by tradition :-)  It was also /.'ed
>
> Christopher Lonvick <[email-masked]> has asked that I post the
> same announcement here  (see below).  We are *really* looking for other RFC
> 3195 compliant syslog systems to test with.  Are there any, especially
> non-proprietary?

http://beepcore-tcl.sf.net/ has a listener and a (very minimal) initiator. both
were intended for testing purposes.

/mtr

------------------------------

Date: Thu, 12 Dec 2002 15:21:32 +0100
From: Rainer Gerhards <[email-masked]>
Subject: Syslog time stamp

Hi all,

A current discussion on the loganalysis mailing list has shown that many
people are not quite happy with the syslog timestamp. Specifically, the
absence of time zone information is causing problems to many
geographically spread locations.

The problem with the current [RFC3164] timestamp is that it is not
possible to reliably consolidate log data over multiple time zones, not
even when proper time synchronization is in place. The only way to do
this would be to configure the central collector(s) to know each device
generating syslog messages and be configured to adjust the reported time
accordingly. Obviously, this is error-prone and work-intensive.

As such, I am asking for a modification to the current syslog-sign
draft, specifically section 2.2 (HEADER) where the TIMESTAMP is
discussed. I suggest that a timestamp as described in [RFC3339]
"date-time" format should become recommended but the [RFC3164] timestamp
should still be allowed (but be depraciated). That way, it would be
possible for a collector to detect both formats and act on the less
precise accordingly.

Any support for this on the WG?

Rainer Gerhards
Adiscon

------------------------------

Date: Fri, 13 Dec 2002 16:40:55 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog time stamp

Hi Darren,

> I think that this is getting into message content and that's
> outside the charter for this WG.

I think you have mixed this up with the discussion on the loganalysis
list and anticipated questions that I have not yet asked and don't
intend to - at least not on the syslog-sec list ;) Here is the relevant
quote from my mail:

> > As such, I am asking for a modification to the current syslog-sign
> > draft, specifically section 2.2 (HEADER) where the TIMESTAMP is
> > discussed. I suggest that a timestamp as described in [RFC3339]

Clearly, I am speaking on the HEADER part, not on MSG. Does this change
your view of things?

Rainer

------------------------------

Date: Sat, 14 Dec 2002 02:18:16 +1100 (EST)
From: Darren Reed <[email-masked]>
Subject: Re: Syslog time stamp

In some email I received from Rainer Gerhards, sie wrote:
> Hi all,
>
> A current discussion on the loganalysis mailing list has shown that many
> people are not quite happy with the syslog timestamp. Specifically, the
> absence of time zone information is causing problems to many
> geographically spread locations.
>
> The problem with the current [RFC3164] timestamp is that it is not
> possible to reliably consolidate log data over multiple time zones, not
> even when proper time synchronization is in place. The only way to do
> this would be to configure the central collector(s) to know each device
> generating syslog messages and be configured to adjust the reported time
> accordingly. Obviously, this is error-prone and work-intensive.
>
> As such, I am asking for a modification to the current syslog-sign
> draft, specifically section 2.2 (HEADER) where the TIMESTAMP is
> discussed. I suggest that a timestamp as described in [RFC3339]
> "date-time" format should become recommended but the [RFC3164] timestamp
> should still be allowed (but be depraciated). That way, it would be
> possible for a collector to detect both formats and act on the less
> precise accordingly.
>
> Any support for this on the WG?

I think that this is getting into message content and that's outside
the charter for this WG.

------------------------------

Date: Fri, 13 Dec 2002 15:35:09 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Re: Syslog time stamp

Hi Darren,

On Sat, 14 Dec 2002, Darren Reed wrote:

> In some email I received from Rainer Gerhards, sie wrote:
> > Hi all,
> >
> > A current discussion on the loganalysis mailing list has shown that many
> > people are not quite happy with the syslog timestamp. Specifically, the
> > absence of time zone information is causing problems to many
> > geographically spread locations.
> >
> > The problem with the current [RFC3164] timestamp is that it is not
> > possible to reliably consolidate log data over multiple time zones, not
> > even when proper time synchronization is in place. The only way to do
> > this would be to configure the central collector(s) to know each device
> > generating syslog messages and be configured to adjust the reported time
> > accordingly. Obviously, this is error-prone and work-intensive.
> >
> > As such, I am asking for a modification to the current syslog-sign
> > draft, specifically section 2.2 (HEADER) where the TIMESTAMP is
> > discussed. I suggest that a timestamp as described in [RFC3339]
> > "date-time" format should become recommended but the [RFC3164] timestamp
> > should still be allowed (but be depraciated). That way, it would be
> > possible for a collector to detect both formats and act on the less
> > precise accordingly.
> >
> > Any support for this on the WG?
>
> I think that this is getting into message content and that's outside
> the charter for this WG.

Rainer is saying that no one is following the timestamp as described in
3164 anyway so we should take this opportunity to standardize upon
something suitable to the community.  Making this change will entail the
following:

- - Text will have to be provided.

- - A note will have to be appended in the syslog-sign ID to state that
relays should be liberal in what they receive.

- - Another note will have to tell people deploying syslog-sign that will
have to ensure that no relay will modify messages between the device and
the collector.

- - RFC-3195 may have to be revised to state that it will accept additional
time formats.

Is there any violent opposition to doing this?  If none, would someone
propose some suitable text?

Thanks,
Chris

------------------------------

Date: Mon, 16 Dec 2002 12:35:24 +0100
From: Rainer Gerhards <[email-masked]>
Subject: Any chance for a Simple Reliable Syslog Protocol?

Hi all,

Based on discussions I had outside of this WG, I would like to ask for
the possibility to specify a kind of "simple reliable syslog protocol".
RFC3195 is definitely well done work. However, I see some serious issues
with it:

- - (Un)availibility of BEEP
As it looks, BEEP has limited availability to say the least. I have
posted a question on the BEEPwg mailing list last week asking for
library implementations. I got no response at all (except for Marshal
Rose who requested that new libraries should be registered at
beepcore.org). So as it looks, BEEP is limited to BEEPcore (which has
some serious issues right now) and Roadrunner (which is hard to use
without redisigning your whole application [and also hard to use for
closed-source projects]).

- - Complexity of BEEP
I wonder if we will ever see an implementation of BEEP (and thus
RFC3195) in routers and especially low-end devices like printers and
small vendor's routers.

- - Need to redesign your application
If I got it correctly, there is strong need to redisign an application
in order to use it with BEEP. Honestly, we do not want to redisign our
full product line just to add support for one additional protocol.

I have followed the relevant lists and so far have the impression that
most implementors stay away from RFC3195 for one or more of the above
reasons.

So in (current) reality, we are back to the usage of "traditional"
(maybe not even RFC3164) syslog if we would like to receive messages
from a heterogeneous set of sources. The good point is that we have a
widely accepted protocol and it performs relatively good most of the
time. But there are weaknesses. Most stem from UDP usage.

I hope that it is possible to specify a protocol that fills the gap
between RFC3164 and RFC3195. A *simple* syslog reliable protocol, that
provides:

- - reliable transport via TCP
- - a much larger allowed message size than 1024 characters
- - support for non-western characters
- - some more meta data (like the full-blown timestamp, but this might go
into the content area and as such might be outside the charter of this
WG. I am still mentioning it so at least some header changes can be
considered)
- - maybe hooks for optional encryption and authenticy - but this might go
too far
- - most importantly is easy to implement and does rely on right now
readily available libraries, which unfortunately means sockets, only...

I wonder if this WG would be willing to step forward into that
direction. I am sure such a protocol would not the least be as elegant
and advanced as RFC3195, but I think this is it's key advantage: being
simple, we would be able to get more implementors to actually implement
it. So we wouldn't achieve the 100% that RFC3195 brings, but maybe the
important 50% of it. Well, and that looks much more than we currently
have...

Keep in mind: my key point is that improovement is needed *now* (which
means quickly), so I am looking for a solution for the next few years.
Maybe this would even be an interim-solution until BEEP becomes actually
available...

Any feedback is highly appreciated,
Rainer Gerhards
Adiscon

------------------------------

Date: Tue, 17 Dec 2002 15:41:51 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

> possibility to specify a kind of "simple reliable syslog protocol".

I second the idea of a new simple reliable protocol. It needs to be very
easily implemented, flexible, easy to parse and check for accuracy and
use standard "off the shelf" components. Mostly, it needs to be simple
if we ever expect hardware manufactures to adopt it.

If a simple standard was proposed and agreed upon, would any of you
implement it in preference to the current RFC?

Some things that spring to mind that need fixing are...

Timestamp needs to include time, date and time zone. Maybe even a
millisecond count.

A consistent delimiter or message length field needs to be added to
ensure messages can be extracted from the TCP stream in the correct
manner. It is not always possible to use the TCP Push flag on all Oses
(eg. Winsock).

A consistent set of header fields in a consistent order needs to be
defined.

Maybe the option for block hashing

Plain TCP socket, or wrapped in SSH or SSL.

I have some ideas on how to implement the above, if anyone is interested
in hearing them, let me know.

Cheers

Andrew

------------------------------

Date: Mon, 16 Dec 2002 21:07:58 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

well, as the resident beep guy, i guess i get to comment. however,
rather than answer your questions directly, i'm going to state a general
principle and then let you apply it to your situation.

the principle is this:

    there is nothing stopping anyone from writing their own limited beep
    stack that integrates exactly with their application exactly the way
    they want it to.

people who write generalized stacks have a set of constraints that are
probably inconsistent with what you're interested in. that's fine, we
don't have to have a one size fits all model.

beep is designed in such a way that you basically pay for what you
use. if you know before hand that you're going to have at most two
channels open (channel zero for management, and another channel for data
exchange), then you can write the transport mapping stuff in one screen
of C (maybe two pages if you like comments). (hint: when the peer asks
to start another channel, send back an <error/>).

in fact, the "just say no" thing works great for most of beep's
features. what you're left with is a mandatory framing mechanism and
some xml parsing for channel 0.

if you want your beep stack to support a threading model, great; if not,
then don't. it's up to you.

here's an interesting thought experiment: list all the requirements that
the community has for the-next-syslog, e.g.,

> - reliable transport via TCP
> - a much larger allowed message size than 1024 characters
> - support for non-western characters
> - some more meta data (like the full-blown timestamp, but this might go
> into the content area and as such might be outside the charter of this
> WG. I am still mentioning it so at least some header changes can be
> considered)
> - maybe hooks for optional encryption and authenticy - but this might go
> too far
> - most importantly is easy to implement and does rely on right now
> readily available libraries, which unfortunately means sockets, only...

is a good start (although the liklihood that the security guys will let
you avoid requirements for authenticity, integrity, and privacy are nil).

anyway, when you compile the final list and then start the design work,
i think it likely that what you have will be at least as complex, and
probably more complex than beep. why? because the secret of beep is that
it's nothing more than a tight integration to a number of proven
solutions to doing applications stuff. the integration part is new, the
rest of it isn't.

now, the parts of your requirements that don't deal with protocol
exchanges (e.g., i18n) are interesting, and i think that may be an
interesting thing for the wg to get into, assuming the ADs are
interested in extending the charter, and depending on your reasoning,
they may very well be...

/mtr

------------------------------

Date: Tue, 17 Dec 2002 12:29:57 -0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

Rainer,

I had a similar reaction when I first looked at RFC3195 and BEEP etc, with a
view to implementing it. However, I don't think it is as complex as it
appears at first glance. It also seems to me that any of the "overhead" is
actually stuff that you would be doomed to reinvent in any alternative (just
like UDP was originally chosen for being "simple" but it turns out TCP was
needed).

Maybe I've missed something, but try this: print out RFC3195, throw away all
the pages referring to the COOKED profile and "additional provisioning", and
see how many pages you are left with. Then refer to the example exchanges.

It looks to me like a sockets programmer could figure out how to talk to
this inside of an day or two, even without any BEEP library. I'd be
surprised if the resulting code was very long, too.

How does this (the RAW profile of RFC3195) differ from the "simple reliable"
you describe below, except that it's upwardly compatible with the remainder
of 3195?

If something like RAW++ is desired (more than 1024 characters, etc), that
should be easy to define as either a new profile or an upgrade to RAW (i.e.
the underlying RFC3164), and still keep the implementation requirements very
light.

Cheers,
Frank

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rainer Gerhards
> Sent: 16 December 2002 11:35
> To: Christopher Lonvick; [email-masked]
> Subject: Any chance for a Simple Reliable Syslog Protocol?
>
>
> Hi all,
>
> Based on discussions I had outside of this WG, I would like to ask for
> the possibility to specify a kind of "simple reliable syslog protocol".
> RFC3195 is definitely well done work. However, I see some serious issues
> with it:
>
> - (Un)availibility of BEEP
> As it looks, BEEP has limited availability to say the least. I have
> posted a question on the BEEPwg mailing list last week asking for
> library implementations. I got no response at all (except for Marshal
> Rose who requested that new libraries should be registered at
> beepcore.org). So as it looks, BEEP is limited to BEEPcore (which has
> some serious issues right now) and Roadrunner (which is hard to use
> without redisigning your whole application [and also hard to use for
> closed-source projects]).
>
> - Complexity of BEEP
> I wonder if we will ever see an implementation of BEEP (and thus
> RFC3195) in routers and especially low-end devices like printers and
> small vendor's routers.
>
> - Need to redesign your application
> If I got it correctly, there is strong need to redisign an application
> in order to use it with BEEP. Honestly, we do not want to redisign our
> full product line just to add support for one additional protocol.
>
> I have followed the relevant lists and so far have the impression that
> most implementors stay away from RFC3195 for one or more of the above
> reasons.
>
> So in (current) reality, we are back to the usage of "traditional"
> (maybe not even RFC3164) syslog if we would like to receive messages
> from a heterogeneous set of sources. The good point is that we have a
> widely accepted protocol and it performs relatively good most of the
> time. But there are weaknesses. Most stem from UDP usage.
>
> I hope that it is possible to specify a protocol that fills the gap
> between RFC3164 and RFC3195. A *simple* syslog reliable protocol, that
> provides:
>
> - reliable transport via TCP
> - a much larger allowed message size than 1024 characters
> - support for non-western characters
> - some more meta data (like the full-blown timestamp, but this might go
> into the content area and as such might be outside the charter of this
> WG. I am still mentioning it so at least some header changes can be
> considered)
> - maybe hooks for optional encryption and authenticy - but this might go
> too far
> - most importantly is easy to implement and does rely on right now
> readily available libraries, which unfortunately means sockets, only...
>
> I wonder if this WG would be willing to step forward into that
> direction. I am sure such a protocol would not the least be as elegant
> and advanced as RFC3195, but I think this is it's key advantage: being
> simple, we would be able to get more implementors to actually implement
> it. So we wouldn't achieve the 100% that RFC3195 brings, but maybe the
> important 50% of it. Well, and that looks much more than we currently
> have...
>
> Keep in mind: my key point is that improovement is needed *now* (which
> means quickly), so I am looking for a solution for the next few years.
> Maybe this would even be an interim-solution until BEEP becomes actually
> available...
>
> Any feedback is highly appreciated,
> Rainer Gerhards
> Adiscon
>
>
>

------------------------------

Date: Tue, 17 Dec 2002 09:52:44 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

> beep is designed in such a way that you basically pay for
> what you use. if you know before hand that you're going to
> have at most two channels open (channel zero for management,
> and another channel for data exchange), then you can write
> the transport mapping stuff in one screen of C (maybe two
> pages if you like comments).

Mmmmhhh... I sometimes like comments ;) But I am still not convinced
that the minimal implementation can be done over breakfast... Any known
approach for such a minimal lib out there?

> (hint: when the peer asks to
> start another channel, send back an <error/>).
>
> in fact, the "just say no" thing works great for most of
> beep's features. what you're left with is a mandatory framing
> mechanism and some xml parsing for channel 0.

Well, I thought this was not the spirit of BEEP - but I guess you must
know better ;) I'll re-read the RFC in this regard.

Generally speaking, I still feel a little like I will implement SMTP but
need to write the TCP part of the IP stack first... The point is that I
am interested in syslog and interested in implementing RFC3195. Now when
I come to actually try to do it, I see that it relies on another RFC
with very limited availability (in running code). Of course, I see the
point that if the lib needed can be crafted relatively quickly, it might
be worth simply doing that instead of complaining ;) I just wonder
nobody did before...

> here's an interesting thought experiment: list all the
> requirements that the community has for the-next-syslog, e.g.,
>
> > - reliable transport via TCP
> > - a much larger allowed message size than 1024 characters
> > - support for non-western characters

[SNIP for brevity]

> sockets, only...
>
> is a good start (although the liklihood that the security
> guys will let you avoid requirements for authenticity,
> integrity, and privacy are nil).

I know they won't like it - in fact, even I don't like it. But face it:
even an "enhanced" RFC3164 implementation that runs over TCP instead of
UDP brings much in terms of reliability. We know it, because we have
done it. So I don't think the question is if it would be great to omit
it, the question is if it can bring value over the current state of
implementation. And if it is easy enough to bring implementors to use
it...

>
> anyway, when you compile the final list and then start the
> design work, i think it likely that what you have will be at
> least as complex, and probably more complex than beep.

Fully agree. And this is exactly the reason why I omitted many of those
things. I am sure that RFC3195 and syslog-sign properly address (most
of) these needs. I am looking for a damn simple, unsophisticated but
still-better-than-current-practice thing that will be extremely easy to
implement and such *quickly* gets implementations (quickly is the key
word here). I am more looking for an enhanced RFC3164 with some added
reliability than a stripped-down RFC3195.

>  why?
> because the secret of beep is that it's nothing more than a
> tight integration to a number of proven solutions to doing
> applications stuff. the integration part is new, the rest of it isn't.
>
> now, the parts of your requirements that don't deal with
> protocol exchanges (e.g., i18n) are interesting, and i think
> that may be an interesting thing for the wg to get into,
> assuming the ADs are interested in extending the charter, and
> depending on your reasoning, they may very well be...

In fact, we are doing a lot of business with Japanese security folks and
especially the 1024 char limit and the charset hurt *very much* in this
space. We had to take the liberty to violate these sections of 3164 to
make things work...

Rainer

------------------------------

Date: Tue, 17 Dec 2002 11:53:46 -0500
From: Bennett Todd <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

BEEP may or may not pay its freight, but I don't see it becoming
available across the board --- including innumerable embedded gizmos
and weird proprietary OSes --- any time soon.

On the other hand, if we started with syslog-as-it-is-today, added
TCP transport, took off the line length limits, delimited "records"
in the TCP stream with newline, and permitted (as an option)
ISO 8601 / RFC 3339 timestamps[1] instead of the ambiguous and
hard-to-sort ones currently standardized, I think we'd hit most of
the essentials. Plus, with little effort, existing implementations
could be frobbed to interop with it, and I think that spec would
describe an existing mode of extended operation on many of today's
enhanced syslog implementations.

As for having to re-do auth, privacy, etc., it seems odd not to just
standardize a TCP service and use SSL if encryption/authentication
is desired. Especially since, in the huge-horking-central-logserver
scenario, SSL would let you use commodity SSL accellerators to buy
the needed performance.

- -Bennett

E.g. 2002-12-17T11:49:39-0500

I have long argued that that "T" is ugly, but I'm strangely swayed
by Paul Roberton's observation that it's a handy hint that someone's
actually trying to honor the standard.

------------------------------

Date: Tue, 17 Dec 2002 17:56:13 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

As I have written the original message, I feel I should post a quick
reply to clarify...

> As responsible for the RoadRunner software project I'm
> curious as to exactly how you find the library hard to use
> for closed-source projects. I'm quite
> confident there's a misunderstanding regarding the license
> and would happily help explain it, given the chance.

There was in fact a misunderstanding of the license terms on my end and
I am right now sorting this out.

Even if it now turns out that RoadRunner can be used in the
closed-source environment, I am a bit reluctant to rely on a single
library implementation. But I'll evaluate first if it is possible to go
away without a beep lib (as suggested on this list), so this argument
might vanish...

Rainer

------------------------------

Date: 17 Dec 2002 11:50:52 -0500
From: Daniel Lundin <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Rainer Gerhards <[email-masked]> writes:

> Roadrunner (which is hard to use without redisigning your whole application
> [and also hard to use for closed-source projects]).

As responsible for the RoadRunner software project I'm curious as to exactly
how you find the library hard to use for closed-source projects. I'm quite
confident there's a misunderstanding regarding the license and would happily
help explain it, given the chance.

RoadRunner is free as in free speech, but also gives you the option to reduce
freedom for any projects that may require it. Being a commercial product of
CodeFactory, this requires a different (unrelated) license to protect our
work and ourselves. This is [partially] similar in purpose to licenses used
for "common" proprietary software. However, even in this form I dare say we
still provide more flexibility and simpler terms than most software.

Of course, details are definitely outside the interest to this list though,
but I'll gladly answer any questions in private email.

Illustrating the licensing model with an example you're probably familiar
with, RoadRunner has the same license as Berkeley DB, and thus offers equal
[lack of] complexity in regards to use.

A few examples of open and closed source projects using this license model:

 Open Project; Cyrus IMAP, Ximian Evolution, FreeBSD

 Proprietary (Closed): Netscape, Cisco, askjeeves.com

And many more I'm sure.

Regarding freedom and 'openness', the license used throughout the project
is approved both as GPL-Compatible Free Software by the Free Software
Foundation and as Open Source(tm) by the Open Source Initiative:

 http://www.fsf.org/licenses/license-list.html#GPLCompatibleLicenses
 http://www.opensource.org/licenses/sleepycat.php

If you have any further questions regarding the licensing, please don't
hesitate to contact me directly.

- -- 
Daniel Lundin  | [email-masked]
CodeFactory AB | http://www.codefactory.se/

------------------------------

Date: Tue, 17 Dec 2002 21:07:45 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

> On the other hand, if we started with syslog-as-it-is-today,
> added TCP transport, took off the line length limits,
> delimited "records" in the TCP stream with newline, and
> permitted (as an option) ISO 8601 / RFC 3339 timestamps[1]
> instead of the ambiguous and hard-to-sort ones currently
> standardized, I think we'd hit most of the essentials. Plus,
> with little effort, existing implementations could be frobbed
> to interop with it, and I think that spec would describe an
> existing mode of extended operation on many of today's
> enhanced syslog implementations.

This is exactly my point. Is it really such a bad idea that there is so
much opposition inside this WG against this? It sounds so easy to do
(even an option in RFC3164 would do) and - based on my discussion with
other implementors - would receive quick acceptance...

Honestly, I would appreciate if someone could point out why this is so a
bad idea.

Cheers,
Rainer

------------------------------

Date: Tue, 17 Dec 2002 10:42:38 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

> As for having to re-do auth, privacy, etc., it seems odd not to just
> standardize a TCP service and use SSL if encryption/authentication
> is desired. Especially since, in the huge-horking-central-logserver
> scenario, SSL would let you use commodity SSL accellerators to buy
> the needed performance.

and this works great, right until someone decides they have a requirement for a
security technology not met by ssl, at which point it's fatal.

there's 20 years of experience in designing application protocols that says you
want to make stuff like this negotiatiable. just picking one (and having an
option to turn it on or off) lacks durability...

/mtr

------------------------------

Date: Tue, 17 Dec 2002 19:50:28 -0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

> As for having to re-do auth, privacy, etc., it seems odd not to just
> standardize a TCP service and use SSL if encryption/authentication
> is desired. Especially since, in the huge-horking-central-logserver
> scenario, SSL would let you use commodity SSL accellerators to buy
> the needed performance.

SSL doesn't provide client authentication (at least not easily & on its
own). So given such a service you'd still be able to fire up a client to
impersonate any other, or indeed any relay, and inject garbage into the
logs. Which of course, you can do right now, but you'd be able to do it much
more reliably with this :)

That would be easily addressed by adding some simple authentication to the
protocol itself, but once you go down that road things are already getting
complicated. Or alternatively you could perhaps leverage IPSEC to get client
authentication.

But it's not clear to me how any client device that could do SSL or IPSEC,
or for that matter do anything at all worth logging, could not manage BEEP!
BEEP has a much lower entry level than either of those. The idea that BEEP
is some hugely complicated stack doesn't really bear close scrutiny.

(Am I reading an out-of-date BEEP RFC or something? Have they gone and added
ASN.1 while I wasn't looking?:)

Cheers,
Frank

------------------------------

Date: Tue, 17 Dec 2002 15:17:59 -0500
From: Bennett Todd <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

2002-12-17-14:50:28 Frank O'Dwyer:
> SSL doesn't provide client authentication (at least not easily &
> on its own).

What's wrong with client certificates?

- -Bennett

------------------------------

Date: Tue, 17 Dec 2002 14:04:29 -0500
From: Bennett Todd <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

2002-12-17-13:42:38 Marshall Rose:
> Bennett Todd:
> > [ use SSL for auth and encryption ]
>
> and this works great, right until someone decides they have a requirement for a
> security technology not met by ssl, at which point it's fatal.

Well, it's fatal, or else it's not.

If an additional function, not currently provided by SSL, should
turn out to be needed, careful design would be required; and if
there's any chance that that function might be useful to other
services _besides_ simple logging, it'd be nicer to add it to some
future release of TLS, rather than restricting it to one particular
passenger app.

> there's 20 years of experience in designing application protocols
> that says you want to make stuff like this negotiatiable. just
> picking one (and having an option to turn it on or off) lacks
> durability...

SSL itself has an elaborate negotiation phase.

And if it should turn out to be desireable to add some new function
that really must be in the payload rather than the transport,
negotiate it by extending the payload format. At the moment we've
got two possibilities on the plate. Syslog Classic records start
with [ADFJMNOS]; the proposal on the table would add the possibility
of [0-9] for ISO 8601 / RFC 3339 timestamps; if some other funky
payload varient were needed, we'd just need to start 'em with some
other character.

- -Bennett

------------------------------

Date: Tue, 17 Dec 2002 10:49:25 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

> > in fact, the "just say no" thing works great for most of
> > beep's features. what you're left with is a mandatory framing
> > mechanism and some xml parsing for channel 0.
>
> Well, I thought this was not the spirit of BEEP - but I guess you must
> know better ;) I'll re-read the RFC in this regard.

the thing to understand about *any* protocol specification is that it is
specifies only what goes on the wire. how you choose to implement it, and what
you choose to implement is immaterial, providing that what goes on the wire
looks like what the specification says it has to look like.

philosophically, this comes from a 30-year old directive to not constrain actual
implementations.

in the grand scheme of things syslog is a rather specialized function. that's
fine, it has a job to do and it does it well.  (contrast this with something
like ftp which provides a generalized file access service that is presumably O/S
and FS independent...)

in situations like this, it makes a lot more sense (to me), to start with the
expertise for a given syslog implementation and figure out what the correct
model and api is for the underlying beep layer.

frank o'dwyer is right when he says a good way to start is by looking at the
syslog-raw protocol examples in 3195. that probably illustrates 90% of the
functionality that your beep stack would need.  the other 10% might deal with
things like connection caching, determining whether you want sasl/tls, etc.

> In fact, we are doing a lot of business with Japanese security folks and
> especially the 1024 char limit and the charset hurt *very much* in this
> space. We had to take the liberty to violate these sections of 3164 to
> make things work...

which certainly does argue for putting together an additional set of
requirements and getting the wg rechartered for address those.

/mtr

------------------------------

Date: Tue, 17 Dec 2002 14:25:20 -0800
From: Tom Perrine <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

The BEEP protocol looks like it has all the right features (and then
some!).  But as Marshall pointed out, the syslog over BEEP doesn't
need all the flexibility and power of every single BEEP feature.

From our standpoint, the problem has never been BEEP, its the
complicated and oftimes buggy (or overly paternalistic) libraries.

A BEEPLite (TM) :-) library that looked a *lot* like "sockets" and
perhaps "sub-sockets" without requiring threads and some other
heavyweight stuff that isn't needed for syslog, would make this whole
discussion of "to BEEP or not to BEEP", moot.

Once you start adding authentication, integrity and security features,
you're going to end up with something just as complicated as BEEP, as
far as I can tell.

And if I don't get at least client authentication, integrity and
privacy features, why go to a new syslog protocol?

- --tep

------------------------------

Date: Tue, 17 Dec 2002 14:41:11 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: What Can Be Changed in syslog

Hi,

I appreciate the thoughts of everyone on the topics brought up so far.
Let's make sure that we all understand what we can do within the current
scope of the WG.

TIMESTAMP  This field may be changed in syslog-sign.  We'll have to rev
           3195 to accept this after syslog-sign is accepted as an RFC.

non-US-ASCII characters in the payload.  This may be addressed in
           syslog-sign, or specified in another Internet Draft (which will
           be accepted as a WG document if there are enough people
           supporting the idea).  Just for reference:
           ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
             A Tangled Web: Issues of I18N, Domain Names, and the
                        Other Internet protocols

payload length.  It's up to the WG to change this.  It may be changed in
           syslog-sign if that's the concensus of the WG.  In that case,
           syslog-sign will have to have dire warnings of trying to push
           the new format through old-style (3164) relays or collectors.
           We'll have to do that anyway if we change the TIMESTAMP.

payload format.  Out of scope.  I'll allow discussion on the WG mailing
           list (here) but anything coming from that cannot be a document
           of this WG.  After we accomplish our Charter Goals, we may ask
           the ADs to allow the WG to reCharter the WG to address that.
           ..but not at this time.

I'll ask anyone interested in making changes to any of these to post notes
to the WG list preferably with a suggestion of modifications to the
current IDs, or a suggestion to write a new ID (with the commitment of
being the author. :)

Let's separate these components apart from the discussion topic of a
"light" reliable transport.

Thanks,
Chris

------------------------------

Date: Tue, 17 Dec 2002 23:22:02 -0500
From: Marshall Glen <[email-masked]>
Subject: Syslog Payload (was "What Can Be Changed in syslog")

Relative to syslog payload format, that may be partly a function of
application domains.  I'll call your attention to a draft I posted at the
beginning of this month:

http://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt

Conceptually, this defines what could be a security audit payload for RFC
3195 in the healthcare application domain.

Best,
Glen F. Marshall

- -----Original Message-----
From: Christopher Lonvick [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 17:41
To: [email-masked]
Subject: What Can Be Changed in syslog

Hi,

I appreciate the thoughts of everyone on the topics brought up so far. Let's
make sure that we all understand what we can do within the current scope of
the WG.

TIMESTAMP  This field may be changed in syslog-sign.  We'll have to rev
           3195 to accept this after syslog-sign is accepted as an RFC.

non-US-ASCII characters in the payload.  This may be addressed in
           syslog-sign, or specified in another Internet Draft (which will
           be accepted as a WG document if there are enough people
           supporting the idea).  Just for reference:
           ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
             A Tangled Web: Issues of I18N, Domain Names, and the
                        Other Internet protocols

payload length.  It's up to the WG to change this.  It may be changed in
           syslog-sign if that's the concensus of the WG.  In that case,
           syslog-sign will have to have dire warnings of trying to push
           the new format through old-style (3164) relays or collectors.
           We'll have to do that anyway if we change the TIMESTAMP.

payload format.  Out of scope.  I'll allow discussion on the WG mailing
           list (here) but anything coming from that cannot be a document
           of this WG.  After we accomplish our Charter Goals, we may ask
           the ADs to allow the WG to reCharter the WG to address that.
           ..but not at this time.

I'll ask anyone interested in making changes to any of these to post notes
to the WG list preferably with a suggestion of modifications to the current
IDs, or a suggestion to write a new ID (with the commitment of being the
author. :)

Let's separate these components apart from the discussion topic of a "light"
reliable transport.

Thanks,
Chris

- -------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
Health Services Corporation 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 [email-masked].  Thank you

------------------------------

Date: Wed, 18 Dec 2002 12:28:01 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog time stamp

Chris,

> Rainer is saying that no one is following the timestamp as
> described in 3164 anyway so we should take this opportunity
> to standardize upon something suitable to the community.
> Making this change will entail the
> following:
>
> - Text will have to be provided.
>
> - A note will have to be appended in the syslog-sign ID to
> state that relays should be liberal in what they receive.
>
> - Another note will have to tell people deploying syslog-sign
> that will have to ensure that no relay will modify messages
> between the device and the collector.
>
> - RFC-3195 may have to be revised to state that it will
> accept additional time formats.
>
> Is there any violent opposition to doing this?  If none,
> would someone propose some suitable text?
>

I have tried to provide some new text for syslog-sign, section 2.2 where
the TIMESTAMP is described. It is my first try in RFCish style, so all
please bear with me ;-)

- ------ begin of proposed text -----

  The TIMESTAMP field is either a RFC3164-TIMESTAMP or a
RFC3339-TIMESTAMP. A sender SHOULD format the timestamp as a
RFC3339-TIMESTAMP. A receiver MUST accept both formats.

The RFC3164-TIMESTAMP is the local time and is in the format of "Mmm
   dd hh:mm:ss" (without the quote marks) where:

       Mmm is the English language abbreviation for the month of the
       year with the first character in uppercase and the other two
       characters in lowercase. The following are the only acceptable
       values:

           Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec

       dd is the day of the month. If the day of the month is less than
       10, then it MUST be represented as a space and then the number.
       For example, the 7th day of August would be represented as "Aug
       7", with two spaces between the "g" and the "7".

       hh:mm:ss is the local time. The hour (hh) is represented in a
       24-hour format. Valid entries are between 00 and 23, inclusive.
       The minute (mm) and second (ss) entries are between 00 and 59
       inclusive.

The RFC3339-TIMESTAMP is as specified in [RFC3339]:

The following syntax MUST be used when using a RFC3339-TIMESTAMP. This
is specified using the syntax description notation defined in [ABNF].

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

  Other than in RFC3339

  - the "T" and "Z" characters in this syntax MUST be in upper case.
  - usage of the "T" character is mandatory. It MUST NOT be replaced by
    any other character (like a space character).
  - the sender SHOULD include time-secfrac (fractional seconds) if its
    clock accuracy permits so
  - the timestap SHOULD be formatted in UTC format ("zulu" time)

A sample of this format is:

      1985-04-12T23:20:50.52Z

   This represents 20 minutes and 50.52 seconds after the 23rd hour of
   April 12th, 1985 in UTC.

For complete details and samples see RFC3339.

   A single space character MUST follow the TIMESTAMP field.
Receivers parsing the date format SHOULD check if the TIMESTAMP is a
RFC3339-TIMESTAMP. The "T" character at position 11 of the string can be
used as a rough indication for this. However, the receiver MUST NOT rely
solely on the "T" character but also parse the other data for validity.
A receiver SHOULD check for RFC3339-TIMESTAMP format first and, if
unsuccessful, assume a RFC3164-TIMESTAMP. If it is also not a
RFC3164-TIMESTAMP the receiver MUST NOT try any other timestamp format
but consider this message to be invalid.

A relay MUST NOT reformat the time stamp. This could create a wrong
concept of time accuracy at the next receiver. If a relay receives a
RFC3164-TIMESTAMP, it MUST forward the message with a RFC3164-TIMESTAMP
and similarly if a relay receives a RFC3339-TIMESTAMP it MUST forward
the message with a RFC3164-TIMESTAMP.

- ------ end of proposed text -----

There besides section 2.2, there are is other wording to be changed in
syslog-sign if the spirit of above proposal is accepted. I am not
providing any suggestion for that by now, as I guess we will need to
reach consensus on the above first before going any further...

Please note that I myself have not totally made up my mind if the
suggestion to use UTC is really a good one. On the pro side, this will
make log analysis (of stored text file logs) much easier. On the other
hand, we loose the information of the time zone the exact device is in.

Looking forward to all comments,
Rainer

------------------------------

Date: Wed, 18 Dec 2002 11:03:15 -0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: RE: What Can Be Changed in syslog

Chris,

There is one other issue which I would like to bring up, which may be within
the scope of this WG, and that is extensibility.

For example, RFC3195 by virtue of its use of BEEP, potentially allows for
additional (optional) profiles which may relate to the events themselves.
Some uses of this that I can think of are:

- - event routing (an upstream node telling a downstream one where to send
various events)
- - event filtering (an upstream node telling a downstream one that nothing
upstream is interested in event 'foo', so don't bother sending it)
- - event prioritisation (assigning events to channels, for example separating
out stuff that needs to be delivered real-time from stuff that doesn't)
- - negotiating a payload format and/or a superset of the COOKED DTD

What I am after here is not a standardisation of the details of all that
(though that would be nice), but at least a standard way to hook it in, and
a means of publishing new profiles and enhanced COOKED DTDs without having
to revisit the base standards.

Maybe this is as simple as stating that the greeting message MAY contain
additional profiles that allow nodes to install filters, routes, priorities,
request a payload format, switch the DTD, etc. Obviously if both ends do not
support a given profile, format or DTD it would simply be ignored.

Cheers,
Frank

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Christopher Lonvick
> Sent: 17 December 2002 22:41
> To: [email-masked]
> Subject: What Can Be Changed in syslog
>
>
> Hi,
>
> I appreciate the thoughts of everyone on the topics brought up so far.
> Let's make sure that we all understand what we can do within the current
> scope of the WG.
>
> TIMESTAMP  This field may be changed in syslog-sign.  We'll have to rev
>            3195 to accept this after syslog-sign is accepted as an RFC.
>
> non-US-ASCII characters in the payload.  This may be addressed in
>            syslog-sign, or specified in another Internet Draft (which will
>            be accepted as a WG document if there are enough people
>            supporting the idea).  Just for reference:
>            ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
>              A Tangled Web: Issues of I18N, Domain Names, and the
>                         Other Internet protocols
>
> payload length.  It's up to the WG to change this.  It may be changed in
>            syslog-sign if that's the concensus of the WG.  In that case,
>            syslog-sign will have to have dire warnings of trying to push
>            the new format through old-style (3164) relays or collectors.
>            We'll have to do that anyway if we change the TIMESTAMP.
>
> payload format.  Out of scope.  I'll allow discussion on the WG mailing
>            list (here) but anything coming from that cannot be a document
>            of this WG.  After we accomplish our Charter Goals, we may ask
>            the ADs to allow the WG to reCharter the WG to address that.
>            ..but not at this time.
>
> I'll ask anyone interested in making changes to any of these to post notes
> to the WG list preferably with a suggestion of modifications to the
> current IDs, or a suggestion to write a new ID (with the commitment of
> being the author. :)
>
> Let's separate these components apart from the discussion topic of a
> "light" reliable transport.
>
> Thanks,
> Chris
>
>
>

------------------------------

Date: Tue, 17 Dec 2002 23:40:18 -0800
From: Rodney Thayer <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

At 07:50 PM 12/17/2002 +0000, Frank O'Dwyer wrote:
> > As for having to re-do auth, privacy, etc., it seems odd not to just
> > standardize a TCP service and use SSL if encryption/authentication
> > is desired. Especially since, in the huge-horking-central-logserver
> > scenario, SSL would let you use commodity SSL accellerators to buy
> > the needed performance.
>
>SSL doesn't provide client authentication (at least not easily & on its
>own).

It certainly does -- you can use certificates at the client end.  And
you can choose not to if you wish.

------------------------------

Date: Wed, 18 Dec 2002 15:10:28 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

On Tue, Dec 17, 2002 at 02:25:20PM -0800, Tom Perrine wrote:
>
> And if I don't get at least client authentication, integrity and
> privacy features, why go to a new syslog protocol?

TCP + TLS and you certainly have client authentication, integrity and
privacy features.

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Wed, 18 Dec 2002 15:20:15 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Syslog time stamp

On Wed, Dec 18, 2002 at 03:16:55PM +0100, Rainer Gerhards wrote:
> > I assume the last sentence was mistyped, and you meant that
> > the relay should send RFC3339-TIMESTAMP if it receives a
> > message with RFC3339-TIMESTAMP
>
> I am sorry, yes, it was meant to be:
>
> ===
> If a relay receives a RFC3164-TIMESTAMP, it MUST forward the message
> with a RFC3164-TIMESTAMP and similarly if a relay receives a
> RFC3339-TIMESTAMP it MUST forward the message with a RFC3339-TIMESTAMP.
> ===
>
> >
> > Btw, why is this a requirement a _MUST_? I think 'SHOULD' is
> > perfectly enough, a relay can be smart enough to convert from
> > RFC3164 to RFC3339 timestamps if configured this way. (for
> > example tz information can be added, assuming the relay is in
> > the same zone as the sender)
> ====
> If a relay receives a RFC3164-TIMESTAMP, it SHOULD forward the message
> with a RFC3164-TIMESTAMP but MAY reformat it to a RFC3339-TIMESTAMP if
> configured to do so. If a relay receives a RFC3339-TIMESTAMP it MUST
> forward the message with a RFC3339-TIMESTAMP. It MUST NOT reformat it to
> a RFC3164-TIMESTAMP.
> ====

it sounds fine to me.

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Wed, 18 Dec 2002 14:35:43 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: What Can Be Changed in syslog

> payload format.  Out of scope.  I'll allow discussion on the
> WG mailing
>            list (here) but anything coming from that cannot
> be a document
>            of this WG.  After we accomplish our Charter
> Goals, we may ask
>            the ADs to allow the WG to reCharter the WG to
> address that.
>            ..but not at this time.

I would be willing to take the task to (try to) write a new ID on this
once we have some basic comments and agreement. It is just that I have
never done so and a little help from someone experienced wouldn't hurt
;)

Rainer

------------------------------

Date: Wed, 18 Dec 2002 08:49:20 -0500
From: Bennett Todd <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

2002-12-17-17:25:20 Tom Perrine:
> The BEEP protocol looks like it has all the right features (and then
> some!).

Yes indeedy "and then some". Multiplexed streams of
MIME-structure-framed XML seems a bit over the top, no?

> But as Marshall pointed out, the syslog over BEEP doesn't need all
> the flexibility and power of every single BEEP feature.

If a very simple-to-implement, simple-to-analyze subset of BEEP
features suffices for this syslog application, this syslog
application should be defined in terms of that subset; else somone
will field a syslog implementation against a generic BEEP library
(assuming they can find one they can work with), and it'll require
features not implemented in the subset.

> Once you start adding authentication, integrity and security features,
> you're going to end up with something just as complicated as BEEP, as
> far as I can tell.

_THAT_ is what really makes me object to BEEP in this application.
Rather than using an existing, widely-deployed generic transport
wrapping for adding authentication, integrity, and privacy (i.e.
SSL), we're using a new one with far far less application base.

Let's get reliability by just shoving our syslog data over TCP, and
where people want authentication, integrity, and privacy, let 'em
carry it over SSL.

> And if I don't get at least client authentication, integrity and
> privacy features, why go to a new syslog protocol?

For the reliability of TCP, to lose line-length limits, and to get
unambiguous and meaningful timestamps? Would that not be enough
reason? If you want in addition client auth, integrity, and privacy,
carry your syslog-over-tcp through SSL, of which there are many,
many implementations, including hardware-assisted ones, and which
has undergone much analysis. Please let's not invent new crypto
protocols if we don't have to, that's one of the most error-prone
areas of engineering.

- -Bennett

------------------------------

Date: Wed, 18 Dec 2002 14:59:42 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Syslog time stamp

On Wed, Dec 18, 2002 at 12:28:01PM +0100, Rainer Gerhards wrote:
> The RFC3339-TIMESTAMP is as specified in [RFC3339]:
>
> The following syntax MUST be used when using a RFC3339-TIMESTAMP. This
> is specified using the syntax description notation defined in [ABNF].
>
>    date-fullyear   = 4DIGIT
>    date-month      = 2DIGIT  ; 01-12
>    date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
>                              ; month/year
>    time-hour       = 2DIGIT  ; 00-23
>    time-minute     = 2DIGIT  ; 00-59
>    time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
>                              ; rules
>    time-secfrac    = "." 1*DIGIT
>    time-numoffset  = ("+" / "-") time-hour ":" time-minute
>    time-offset     = "Z" / time-numoffset
>
>    partial-time    = time-hour ":" time-minute ":" time-second
>                      [time-secfrac]
>    full-date       = date-fullyear "-" date-month "-" date-mday
>    full-time       = partial-time time-offset
>
>    date-time       = full-date "T" full-time
>
>   Other than in RFC3339
>
>   - the "T" and "Z" characters in this syntax MUST be in upper case.
>   - usage of the "T" character is mandatory. It MUST NOT be replaced by
>     any other character (like a space character).
>   - the sender SHOULD include time-secfrac (fractional seconds) if its
>     clock accuracy permits so
>   - the timestap SHOULD be formatted in UTC format ("zulu" time)

I think the requirement of sending the stamp in GMT is not good. You'd lose
the time zone information. It is possible to convert to a given timezone (be
it Zulu or something else) on the receiver side.

> A relay MUST NOT reformat the time stamp. This could create a wrong
> concept of time accuracy at the next receiver. If a relay receives a
> RFC3164-TIMESTAMP, it MUST forward the message with a RFC3164-TIMESTAMP
> and similarly if a relay receives a RFC3339-TIMESTAMP it MUST forward
> the message with a RFC3164-TIMESTAMP.

I assume the last sentence was mistyped, and you meant that the relay should
send RFC3339-TIMESTAMP if it receives a message with RFC3339-TIMESTAMP

Btw, why is this a requirement a _MUST_? I think 'SHOULD' is perfectly enough,
a relay can be smart enough to convert from RFC3164 to RFC3339 timestamps if
configured this way. (for example tz information can be added, assuming the
relay is in the same zone as the sender)

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Wed, 18 Dec 2002 15:16:55 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog time stamp

Bazsi,

>   - the timestap SHOULD be formatted in UTC format ("zulu" time)
>
> I think the requirement of sending the stamp in GMT is not
> good. You'd lose the time zone information. It is possible to
> convert to a given timezone (be it Zulu or something else) on
> the receiver side.
>
> > A relay MUST NOT reformat the time stamp. This could create a wrong
> > concept of time accuracy at the next receiver. If a relay
> receives a
> > RFC3164-TIMESTAMP, it MUST forward the message with a
> > RFC3164-TIMESTAMP and similarly if a relay receives a
> > RFC3339-TIMESTAMP it MUST forward the message with a
> > RFC3164-TIMESTAMP.
>
> I assume the last sentence was mistyped, and you meant that
> the relay should send RFC3339-TIMESTAMP if it receives a
> message with RFC3339-TIMESTAMP

I am sorry, yes, it was meant to be:

===
If a relay receives a RFC3164-TIMESTAMP, it MUST forward the message
with a RFC3164-TIMESTAMP and similarly if a relay receives a
RFC3339-TIMESTAMP it MUST forward the message with a RFC3339-TIMESTAMP.
===

>
> Btw, why is this a requirement a _MUST_? I think 'SHOULD' is
> perfectly enough, a relay can be smart enough to convert from
> RFC3164 to RFC3339 timestamps if configured this way. (for
> example tz information can be added, assuming the relay is in
> the same zone as the sender)

Good point. I was concerned about the ability to trust the timestamp. I
thought it should be a MUST as the receiver - if receiving a
RFC3339-TIMESTAMP - thinks it knows the exact time (zone) of the
original sender. However, the relay can take over the job to become the
"trust source" for the time information (based on its configuration). It
might even be helpful for situations, where RFC3164-TIMESTAMPs being
send by routers to a local relay on the bottom of the relay chain...

So how about this wording:

====
If a relay receives a RFC3164-TIMESTAMP, it SHOULD forward the message
with a RFC3164-TIMESTAMP but MAY reformat it to a RFC3339-TIMESTAMP if
configured to do so. If a relay receives a RFC3339-TIMESTAMP it MUST
forward the message with a RFC3339-TIMESTAMP. It MUST NOT reformat it to
a RFC3164-TIMESTAMP.
====

Rainer

------------------------------

Date: Wed, 18 Dec 2002 09:08:52 -0500
From: Bennett Todd <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

2002-12-17-18:11:43 Marshall Rose:
> here's an interesting thought experiment: if TLS (nee SSL) is
> around, why did the IETF add SASL to all of its application
> protocols?

Errh, because the Cyrus team implemented it, and nobody was
offering a better way to stuff authentication into SMTP? The
hideous overcomplexity of SASL has been the main barrier to getting
authenticated SMTP more widely deployed. Notably, the Cyrus SASL
libraries --- the only SASL implementation available[1] --- have
been found to have security bugs in them.

> to understand the answer to this, is to understand why TLS, while
> very good at what it does, doesn't meet the requirements of many
> environments.

To understand why SMTP auth is so rarely deployed, and why so many
people are using the revolting pop-before-smtp kluge instead, is to
understand why wading off into the bright open and inventing your
own crypto protocols from scratch is best avoided.

> here are two hints: kerberized enterprises?

Haven't ever cared especially; even when I've worked in a totally
kerberized enterprise, certs were just as good for host-to-host
auth (and operationally equivalent). But now that I do a quick RFC
search, it looks like RFC 2712 describes Kerberos authentication for
TLS, so it looks like someone decided to enable the general-purpose
tool to encompass that problem.

> integrity-sans-privacy?

I'm having trouble envisioning a real motivation for that, but it
seems to be supported within TLS as it stands, BulkCipherAlgorithm
null.

> again, it's not that TLS isn't adequate, it's perfectly adequate
> and extensible for its mission. the problem is that its mission
> may not have quite the reach that a lot of folks require...

Before concluding that, it's good to make positively certain TLS
can't do the job as it stands, and that it's impractical to extend
it, before going out and re-inventing the functionality; there's a
lot of engineering benefit to re-using existing analysis and
implementation, and if the existing protocol is inadequate for a new
job, better to extend it, and thereby leave it fitted to a broader
set of tasks, then re-implementing the functionality elsewhere.

I really think the security needs of syslog are best met by just
getting it off UDP and onto TCP, whereupon it's easy to transport it
securely.

- -Bennett

[1] I've heard of other SASL library implementation attempts. I
    haven't heard of any that got far enough to be a viable
    alternative to Cyrus SASL for a real application.

------------------------------

Date: Wed, 18 Dec 2002 09:16:52 -0500
From: Bennett Todd <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

2002-12-17-18:43:20 Frank O'Dwyer:
> Bennett Todd:
> > 2002-12-17-14:50:28 Frank O'Dwyer:
> > > SSL doesn't provide client authentication (at least not easily &
> > > on its own).
> >
> > What's wrong with client certificates?
>
> PKI, basically, and the lack of it.

The myth that PKI is required for client certs is one of the more
successfull marketing games that have been played recently. Client
certs are just like server certs (which are routinely used for
https); they're just deployed on the client end of the connection.

If you want client authentication, e.g. for syslog-secure, why then
the client positively has to hold a secret, there's no way around
that. The secret could be a password, or it could be a private key;
either way, it's a bag of bits, and the client has to be able to
access it.

Invest in PKIs for buzzword compliance, but you can get work
done by hand-distributing client certs the exact same way you'd
hand-distribute client passwords for other authentication protocols.

> Also in a lot of organisations the mere mention of PKI will
> trigger the formation of a committee that meets for 3 years to
> decide what colour the CPS should be, and not much else will
> happen.

Nicely put. Sounds like there are a lot of healthy organizations,
with strong immune systems. Hmm. Committees operate like white
cells, to surround and hence disable an intruder ... hmm.

Yup, I routinely advise avoiding clutching the PKI tarbaby.

Client cert auth requires no PKI, it requires only what you'd have
to do to enable any other kind of auth, namely installing a small
bag of secret bits on the client. If the bits were a simple
password, I'd be generating them by pulling them out of /dev/random.
If the bits are a client cert, I'd be pulling them out of openssl. I
just don't see the big difference here.

> Admittedly you'd have a much better chance getting it in place
> for servers and devices, and especially if you can limit it to a
> smallish set of managed devices (relays and collectors say, in
> syslog speak), but you still have to think about key change and
> revocation, which are both problems that get harder as you add
> nodes.

Those problems are no different whether the secrets you must
distribute and manage are client certificates, or passwords. The
problem is authenticating clients, specifically distributing
the credentials to be used; it's not the choice of passwd -vs-
certificate to do so.

- -Bennett

------------------------------

Date: Wed, 18 Dec 2002 08:04:16 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-sign-08.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-08.txt
	Pages		: 22
	Date		: 2002-12-16

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-08.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-08.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-08.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, 18 Dec 2002 13:52:28 -0800
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: can i get some help with the unwashed?

At 11:57 AM 12/18/2002, Bennett Todd <[email-masked]> wrote:
>2002-12-17-18:11:43 Marshall Rose:
>> here's an interesting thought experiment: if TLS (nee SSL) is
>> around, why did the IETF add SASL to all of its application
>> protocols?

Because TLS does not solve the whole problem.  Neither does SASL.
(Neither does GSSAPI.  Neither does IPSEC.)  Bur together they
provide fairly complete coverage of the authentication mechanisms
and security layers that most designers need to engineer
secure protocols (and allow them to offer appropriate flexibility
to deployers).

>Errh, because the Cyrus team implemented it, and nobody was
>offering a better way to stuff authentication into SMTP?

IIRC, the Cyrus SASL effort was started AFTER RFC 2222 was
published.  SASL was, of course, invented at same company
which invented SSL (TLS), Netscape.  And, of course, SASL was
initially targeted for IMAP.

You might ask yourself, why would the company which invented
SSL find it appropriate to develop SASL?

If you cannot find the answer, though it be obvious, I'll
give it to you: SASL and TLS (SSL) complement each other.

>The hideous overcomplexity of SASL has been the main barrier to getting
>authenticated SMTP more widely deployed. Notably, the Cyrus SASL
>libraries --- the only SASL implementation available[1] --- have
>been found to have security bugs in them.

First off, Cyrus SASL is only one of many available SASL "library"
implementations. And, second, many SASL mechanisms are so simple
that no library is needed.  I've personally implemented multiple
SASL mechanisms without use of libraries, so it's been my
experience that SASL is actually quite simple.  (Of course, some
mechanisms are easier to implement than others... but the ones
designed to be used over transport layer security are trivial
to implement).

With regards to implementation bugs, sure, I'm sure some have been
found in this and other implementations.  But, I don't think the
quality of available implementations should be an issue here.

>> to understand the answer to this, is to understand why TLS, while
>> very good at what it does, doesn't meet the requirements of many
>> environments.
>
>To understand why SMTP auth is so rarely deployed, and why so many
>people are using the revolting pop-before-smtp kluge instead, is to
>understand why wading off into the bright open and inventing your
>own crypto protocols from scratch is best avoided.

Which is, after all, why you should use SASL and other security
frameworks.  There is no need to reinvent PKI-based authentication,
simple password authentication, digest password authentication,
Kerberos authentication, one-time passwords, secure-id, etc..  And
use of these frameworks in specifications has led to plugin APIs
so that one can adapt the software one acquires to the local
environment.  The ability to support legacy environments is quite
valuable.

>> here are two hints: kerberized enterprises?
>
>Haven't ever cared especially; even when I've worked in a totally
>kerberized enterprise, certs were just as good for host-to-host
>auth (and operationally equivalent).  But now that I do a quick RFC
>search, it looks like RFC 2712 describes Kerberos authentication for
>TLS, so it looks like someone decided to enable the general-purpose
>tool to encompass that problem.

Whilst one can certainly add cipher suites to TLS... that's
not necessarily the best approach.

>> integrity-sans-privacy?
>
>I'm having trouble envisioning a real motivation for that, but it
>seems to be supported within TLS as it stands, BulkCipherAlgorithm
>null.
>
>> again, it's not that TLS isn't adequate, it's perfectly adequate
>> and extensible for its mission. the problem is that its mission
>> may not have quite the reach that a lot of folks require...
>
>Before concluding that, it's good to make positively certain TLS
>can't do the job as it stands, and that it's impractical to extend
>it, before going out and re-inventing the functionality;

To add the capabilities that SASL offers to TLS would require
reinvention of functionality.  And likewise for trying to add
all of TLS capabilities to SASL.

>there's a
>lot of engineering benefit to re-using existing analysis and
>implementation, and if the existing protocol is inadequate for a new
>job, better to extend it, and thereby leave it fitted to a broader
>set of tasks, then re-implementing the functionality elsewhere.

You just made a good argument for the use of SASL.

>I really think the security needs of syslog are best met by just
>getting it off UDP and onto TCP, whereupon it's easy to transport it
>securely.

Hell, why don't you just use IPSEC and not worry about it at all?
(I say this in jest.)

>-Bennett
>
>[1] I've heard of other SASL library implementation attempts. I
>    haven't heard of any that got far enough to be a viable
>    alternative to Cyrus SASL for a real application.

------------------------------

Date: Wed, 18 Dec 2002 13:48:04 -0800
From: Darren New <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Bennett Todd wrote:
> Yes indeedy "and then some". Multiplexed streams of
> MIME-structure-framed XML seems a bit over the top, no?

The multiplexed streams don't have to be XML. Just MIME. With the
default being application/octet-stream (last I looked). So in other
words, if you're happy with exchanging a single stream of binary blobs,
everything you named is not required.

> If a very simple-to-implement, simple-to-analyze subset of BEEP
> features suffices for this syslog application, this syslog
> application should be defined in terms of that subset;

It is.

> else somone
> will field a syslog implementation against a generic BEEP library
> (assuming they can find one they can work with), and it'll require
> features not implemented in the subset.

Like what?

> > Once you start adding authentication, integrity and security features,
> > you're going to end up with something just as complicated as BEEP, as
> > far as I can tell.
>
> _THAT_ is what really makes me object to BEEP in this application.
> Rather than using an existing, widely-deployed generic transport
> wrapping for adding authentication, integrity, and privacy (i.e.
> SSL), we're using a new one with far far less application base.

Um.... BEEP uses SSL. BEEP includes a mechanism for saying you want to
use SSL. (Well, TLS, but you know that.) BEEP does not replace TLS - it
merely provides a way for you to ask the other side to use TLS, and for
the other side to accept or refuse.

I'm not sure I understand why you don't already know this, if you've
read the syslog-reliable spec.

> Let's get reliability by just shoving our syslog data over TCP, and
> where people want authentication, integrity, and privacy, let 'em
> carry it over SSL.

Yes. This is what syslog-reliable does. And it uses BEEP to say where
people want authentication, integrity, and privacy. So what's the
problem? Are you under the mistaken impression that BEEP is a
replacement for TLS or something?

- --
Darren New
San Diego, CA, USA (PST)
"I'm allergic to antihistamines."
    "Oh? What do you break out in?"

------------------------------

Date: Wed, 18 Dec 2002 15:30:27 -0800
From: Rodney Thayer <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

At 01:48 PM 12/18/2002 -0800, Darren New wrote:
>Bennett Todd wrote:
> > Yes indeedy "and then some". Multiplexed streams of
> > MIME-structure-framed XML seems a bit over the top, no?
>
>Um.... BEEP uses SSL. BEEP includes a mechanism for saying you want to
>use SSL. (Well, TLS, but you know that.) BEEP does not replace TLS - it
>merely provides a way for you to ask the other side to use TLS, and for
>the other side to accept or refuse.

AND it introduces more processing in between your payload and TLS.

>I'm not sure I understand why you don't already know this, if you've
>read the syslog-reliable spec.

because in the syslig-reliable spec (RFC 3195) on page 5 it says...

    "At the time of this writing, only one such transport is defined, in [4],
    which specifies BEEP over TCP."

Now in fact it specifies BEEP over TLS, I gather.

The point is, BEEP adds a layer of overhead that people are debating the
value of.

------------------------------

Date: Thu, 19 Dec 2002 13:47:07 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: Syslog time stamp

YYYY-MM-DDTHH:MM:SS.NNNZ+09:30

How about mentioning that the time stamp must be a fixed length, with
leading zeros for padding. This makes parsing and verification much
simpler.

For example: time-secfrac SHOULD be 3 digits (milliseconds).

Also, if sub second count is not used, it SHOULD be set to 000 rather
than making it optional.

I think the time should be in local time, with the offset indicating the
difference from UTC/GMT. This requires less calculation at the sending
side since the time zone is a constant. You can always convert to UTC at
the receiving end if you want to.

The time offset should be in the format -0100 or +0930 (can you tell I
used to live in Adelaide).
Alternatively a : could be added in the middle -01:00 or +09:30.
The HH:MM should be fixed length and require the use of +/- indicator.

My reasons for defining everything as fixed length are to keep the
parsing simple and make for easy verification of the messages. The
problem with the current 3164 RFC is that the PID can sometimes be
missing and it makes it tricky to work out if we are looking at a
hostname or PID in the field. Well defined, non optional, fixed length
fields will make it very nice to work with.

Cheers

Andrew

------------------------------

Date: Wed, 18 Dec 2002 18:42:09 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

> At 01:48 PM 12/18/2002 -0800, Darren New wrote:
> >Bennett Todd wrote:
> > > Yes indeedy "and then some". Multiplexed streams of
> > > MIME-structure-framed XML seems a bit over the top, no?
> >
> >Um.... BEEP uses SSL. BEEP includes a mechanism for saying you want to
> >use SSL. (Well, TLS, but you know that.) BEEP does not replace TLS - it
> >merely provides a way for you to ask the other side to use TLS, and for
> >the other side to accept or refuse.
>
> AND it introduces more processing in between your payload and TLS.

uh, not exactly. see below.

> >I'm not sure I understand why you don't already know this, if you've
> >read the syslog-reliable spec.
>
> because in the syslig-reliable spec (RFC 3195) on page 5 it says...
>
>     "At the time of this writing, only one such transport is defined, in [4],
>     which specifies BEEP over TCP."
>
> Now in fact it specifies BEEP over TLS, I gather.

bzzzt. wrong answer. read 3080 and you'll see that tls sits on top of tcp.

> The point is, BEEP adds a layer of overhead that people are debating the
> value of.

and would you educate as to exactly what that layer is? let's see is it:

  - the framing?  well, i suppose we could view syslog messages as
    self-terminating with the \n?

  - the security?  well, beep just lets you determine whether it's
    available and if you want to make use of it

  - the negotiated release? well, that's probably something we don't
    need (be sure to mention that to the http folks).

my (admittedly biased) theory is that when you sit down and try to find
exactly what the "layer of overhead" is, you'll find that it's all those
things that you need to do anyway...

/mtr

------------------------------

Date: Wed, 18 Dec 2002 19:11:05 -0800
From: Darren New <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Rodney Thayer wrote:
> AND it introduces more processing in between your payload and TLS.

About 30 bytes per message, yes. If you're doing encryption, the
overhead of TLS is likely going to be larger than the overhead of BEEP.
If you can't spare 30 bytes per message, then you probably are getting
messages fast enough to pile them all up into one BEEP frame, so you get
2 extra bytes per message instead.

>     "At the time of this writing, only one such transport is defined, in [4],
>     which specifies BEEP over TCP."
>
> Now in fact it specifies BEEP over TLS, I gather.

I suppose if you consider TLS a transport protocol, you could say that
BEEP specifies how to change its own transport protocol. I don't think
people use this sort of terminology. Invoking TLS is part of BEEP. TLS
isn't a transport protocol as such. The spec defined BEEP over TCP, not
BEEP over UDP or BEEP over SNA or .... TLS is just something that runs
over TCP also.

> The point is, BEEP adds a layer of overhead that people are debating the
> value of.

The debate was already dealt with ages ago, and modifications to the
profile were made to minimize the overhead. The amount of processing
overhead introduced is roughly the same order of magnitude as the
processing overhead of using TCP instead of UDP, I would guess.
Basically, adding two mod-2^32 numbers together and converting them to
strings of ASCII digits is the extent of it. What part of the overhead
do you think is unacceptable, specifically, and why do you think that?

- --
Darren New
San Diego, CA, USA (PST)
"I'm allergic to antihistamines."
    "Oh? What do you break out in?"

------------------------------

Date: Wed, 18 Dec 2002 20:21:17 -0700
From: Lyndon Nerenberg <[email-masked]>
Subject: Anthropology of SASL

>IIRC, the Cyrus SASL effort was started AFTER RFC 2222 was
>published.  SASL was, of course, invented at same company
>which invented SSL (TLS), Netscape.  And, of course, SASL was
>initially targeted for IMAP.

The above is mostly incorrect.

SASL originated in the IMAP4 AUTHENTICATE command. When it became
apparent that the authentication protocol framework provided by the
AUTHENTICATE command in IMAP4 would be generally useful, it was
split out into a seperate specification (SASL, RFC2222).

SASL was first implemented in the Cyrus IMAP4 and IMSP servers (although
it wasn't called SASL at the time). This work pre-dated John Myers'
joining Netscape by quite some time.

The standalone Cyrus SASL library appeared in conjunction with the
release of the Cyrus version 2 IMAP4 server.

- --lyndon

------------------------------

Date: Wed, 18 Dec 2002 19:40:07 -0800
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Anthropology of SASL

At 07:21 PM 12/18/2002, Lyndon Nerenberg wrote:
>The above is mostly incorrect.

Thanks for setting me (and the list) straight.  For some reason
I thought John was already at Netscape when he published the
early SASL I-Ds.  In checking the archives, I am obviously
wrong.

        Kurt

------------------------------

Date: Thu, 19 Dec 2002 10:25:25 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

On Wed, Dec 18, 2002 at 07:11:05PM -0800, Darren New wrote:
> Rodney Thayer wrote:
> > AND it introduces more processing in between your payload and TLS.
> > The point is, BEEP adds a layer of overhead that people are debating the
> > value of.
>
> The debate was already dealt with ages ago, and modifications to the
> profile were made to minimize the overhead. The amount of processing
> overhead introduced is roughly the same order of magnitude as the
> processing overhead of using TCP instead of UDP, I would guess.
> Basically, adding two mod-2^32 numbers together and converting them to
> strings of ASCII digits is the extent of it. What part of the overhead
> do you think is unacceptable, specifically, and why do you think that?

BEEP is not a bad protocol, it offers features that other protocols
implement on their own (think of SSH2 and its channels). What we are
questioning is right now is the need for negotiation.

Syslog infrastructures as deployed today are very simple:

- - each client sends messages to one or more destinations

There's no negotiation going on right now. There's nothing the sender or
client sides must agree on. Not even the maximum length of messages, not
whether to use TLS or not. These are defined externally, in the configuration
of the syslog implementation.

You might raise the fact that this causes management problems, as each
decision (e.g. configuration option) must be distributed to each syslog
endpoint (be it sender, relay or collector), and that a given point-to-point
syslog stream works if and only if both sides are configured the same (to
use TLS, to use RFC3339 timestamps and so on)

This might become a real problem if you have thousands of devices, but these
problems are minor compared to the fact that we are still using UDP and
messages limited to 1024 bytes.

Another feature that BEEP provides us is the notion of channels, e.g. it
lets you multiplex several full-duplex channels into the same TCP session.
For this it uses its own windowing, has its own channel control messages
etc. This does not mean too much to syslog right now either. We can use
several TCP streams if we need to.

The possibility of requesting parts of the syslog stream in a separate
channel might be useful in the future, but the control messages to achieve
this needs to be defined. The problem with RFC3195 is that it provides
solutions for the future, but does not solve our current problems. Plain TCP
transport is supported in more-and-more implementations but they not
necessarily interoperate, even end devices support it sometimes:

- - kiwisyslog
- - msyslog
- - nsyslogd
- - syslog-ng
- - Cisco PIX

And I'm sure I've forgotten some. These should interoperate, most of them do
I guess, but an RFC would help in this area right _NOW_. The BEEP solution
might be the future, but first it needs implementations, and further updates
that makes the overhead explainable.

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Thu, 19 Dec 2002 14:21:54 +0100
From: Klaus Moeller <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

- -----BEGIN PGP SIGNED MESSAGE-----

On Thursday 19 December 2002 10:25, Balazs Scheidler wrote:

> Another feature that BEEP provides us is the notion of channels, e.g.
> it lets you multiplex several full-duplex channels into the same TCP
> session. For this it uses its own windowing, has its own channel
> control messages etc. This does not mean too much to syslog right now
> either. We can use several TCP streams if we need to.

Well, seeing this I'm wondering if anybody has yet thought of doing
syslog over SCTP ? Not that I suppose switching to SCTP now, but as a
furture consideration, this might look promising.

		Klaus Moeller, DFN-CERT

- - --
Klaus Moeller          |                      mailto:[email-masked]
DFN-CERT GmbH          |            http://www.cert.dfn.de/team/moeller/
Heidenkampsweg 41      |                        Phone: +49(40)808077-555
D-20097 Hamburg        |                          FAX: +49(40)808077-556
Germany	               |              PGP-Key: RSA 2048 Bit ID: 0BB7C8F9

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQEVAwUBPgHH84rEggYLt8j5AQE9tgf/SR0snQtAJKCLHDDciSH9oYPmVfNqTViz
BxAETRN+etjX4AKr+/dpn1v0JdaG9Sc0Xhaia9qbHWs5/4B46aDNTnK0fx1ktc2b
SfS/57mgOtTy4ewv9HvR3tmgIMwUgCgRYdr08rMaj8xmWx+F4uLO5D/QuRJ1E3Br
cTLPWKBeR2ao8bLC7QCYeyAjTBAX7/jhNKx/67KCtORIMi+Jd3uFZ8XX6yoJG+Yy
wVVPE2J2lEHvsEi4JJF/rhL+cQStKa+dbXC9HvUZFSatPC9WyUTo46cioZpeuxzW
2mO22XSnDGIfYuG1poUXOXUOsKf380DwDG4pogPzQg+jk7wiaIA0Ag==
=nlZY
- -----END PGP SIGNATURE-----

------------------------------

Date: Thu, 19 Dec 2002 17:30:50 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

> they not necessarily interoperate, even end devices support
> it sometimes:
>
> - kiwisyslog
> - msyslog
> - nsyslogd
> - syslog-ng
> - Cisco PIX
>
> And I'm sure I've forgotten some. These should interoperate,

I'd like to add

- - MonitorWare Agent
- - EventReporter
- - WinSyslog

to the list ;) Not only for marketing purposes, but to get it complete.
Any other ones out there? I am asking because if we already do support
syslog over TCP, we might at least in this group agree on a way to do
it. If it then prooves to be doing nicely, we could try to get some
attention for such a protocol (you know, running code... ;))

Please note that I have been relatively silent on the list as I am
exploring mtr's "simple beep, just say no approach". I am not sure yet,
but maybe the negotation is not as bad as all. We may write a small lib
to cover this (probably as open source...). Needs to be seen...

Rainer

------------------------------

Date: Thu, 19 Dec 2002 10:51:39 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Re: Syslog Payload (was "What Can Be Changed in syslog")

Hi Glen,

I don't mind if you ask this WG for input on your ID.  However, our
charter won't allow it to become a document of this Working Group.
The same goes for any other proposal related to the formatting of
the payload of syslog messages.

All:  Glen would like to get this ID through the process so it may
become an RFC.  Having it reviewed by like-minded people helps that
process.  If you have time+effort, please send comments either to
the list or to Glen.

Thanks,
Chris

On Tue, 17 Dec 2002, Marshall Glen wrote:

>
> Relative to syslog payload format, that may be partly a function of
> application domains.  I'll call your attention to a draft I posted at the
> beginning of this month:
>
> http://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt
>
> Conceptually, this defines what could be a security audit payload for RFC
> 3195 in the healthcare application domain.
>
> Best,
> Glen F. Marshall
>
>
> -----Original Message-----
> From: Christopher Lonvick [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 17:41
> To: [email-masked]
> Subject: What Can Be Changed in syslog
>
>
> Hi,
>
> I appreciate the thoughts of everyone on the topics brought up so far. Let's
> make sure that we all understand what we can do within the current scope of
> the WG.
>
> TIMESTAMP  This field may be changed in syslog-sign.  We'll have to rev
>            3195 to accept this after syslog-sign is accepted as an RFC.
>
> non-US-ASCII characters in the payload.  This may be addressed in
>            syslog-sign, or specified in another Internet Draft (which will
>            be accepted as a WG document if there are enough people
>            supporting the idea).  Just for reference:
>            ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
>              A Tangled Web: Issues of I18N, Domain Names, and the
>                         Other Internet protocols
>
> payload length.  It's up to the WG to change this.  It may be changed in
>            syslog-sign if that's the concensus of the WG.  In that case,
>            syslog-sign will have to have dire warnings of trying to push
>            the new format through old-style (3164) relays or collectors.
>            We'll have to do that anyway if we change the TIMESTAMP.
>
> payload format.  Out of scope.  I'll allow discussion on the WG mailing
>            list (here) but anything coming from that cannot be a document
>            of this WG.  After we accomplish our Charter Goals, we may ask
>            the ADs to allow the WG to reCharter the WG to address that.
>            ..but not at this time.
>
> I'll ask anyone interested in making changes to any of these to post notes
> to the WG list preferably with a suggestion of modifications to the current
> IDs, or a suggestion to write a new ID (with the commitment of being the
> author. :)
>
> Let's separate these components apart from the discussion topic of a "light"
> reliable transport.
>
> Thanks,
> Chris
>
>
> -------------------------------------------------------------------------------
> This message and any included attachments are from Siemens Medical Solutions
> Health Services Corporation 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 [email-masked].  Thank you
>
>

------------------------------

Date: Thu, 19 Dec 2002 10:58:14 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: RE: What Can Be Changed in syslog

Hi Frank,

Interesting thought.  Does anyone else support this?  Would this be "just
anyone" or should the profiles be registered with IANA?

Thanks,
Chris

On Wed, 18 Dec 2002, Frank O'Dwyer wrote:

> Chris,
>
> There is one other issue which I would like to bring up, which may be within
> the scope of this WG, and that is extensibility.
>
> For example, RFC3195 by virtue of its use of BEEP, potentially allows for
> additional (optional) profiles which may relate to the events themselves.
> Some uses of this that I can think of are:
>
> - event routing (an upstream node telling a downstream one where to send
> various events)
> - event filtering (an upstream node telling a downstream one that nothing
> upstream is interested in event 'foo', so don't bother sending it)
> - event prioritisation (assigning events to channels, for example separating
> out stuff that needs to be delivered real-time from stuff that doesn't)
> - negotiating a payload format and/or a superset of the COOKED DTD
>
> What I am after here is not a standardisation of the details of all that
> (though that would be nice), but at least a standard way to hook it in, and
> a means of publishing new profiles and enhanced COOKED DTDs without having
> to revisit the base standards.
>
> Maybe this is as simple as stating that the greeting message MAY contain
> additional profiles that allow nodes to install filters, routes, priorities,
> request a payload format, switch the DTD, etc. Obviously if both ends do not
> support a given profile, format or DTD it would simply be ignored.
>
> Cheers,
> Frank
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Christopher Lonvick
> > Sent: 17 December 2002 22:41
> > To: [email-masked]
> > Subject: What Can Be Changed in syslog
> >
> >
> > Hi,
> >
> > I appreciate the thoughts of everyone on the topics brought up so far.
> > Let's make sure that we all understand what we can do within the current
> > scope of the WG.
> >
> > TIMESTAMP  This field may be changed in syslog-sign.  We'll have to rev
> >            3195 to accept this after syslog-sign is accepted as an RFC.
> >
> > non-US-ASCII characters in the payload.  This may be addressed in
> >            syslog-sign, or specified in another Internet Draft (which will
> >            be accepted as a WG document if there are enough people
> >            supporting the idea).  Just for reference:
> >            ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
> >              A Tangled Web: Issues of I18N, Domain Names, and the
> >                         Other Internet protocols
> >
> > payload length.  It's up to the WG to change this.  It may be changed in
> >            syslog-sign if that's the concensus of the WG.  In that case,
> >            syslog-sign will have to have dire warnings of trying to push
> >            the new format through old-style (3164) relays or collectors.
> >            We'll have to do that anyway if we change the TIMESTAMP.
> >
> > payload format.  Out of scope.  I'll allow discussion on the WG mailing
> >            list (here) but anything coming from that cannot be a document
> >            of this WG.  After we accomplish our Charter Goals, we may ask
> >            the ADs to allow the WG to reCharter the WG to address that.
> >            ..but not at this time.
> >
> > I'll ask anyone interested in making changes to any of these to post notes
> > to the WG list preferably with a suggestion of modifications to the
> > current IDs, or a suggestion to write a new ID (with the commitment of
> > being the author. :)
> >
> > Let's separate these components apart from the discussion topic of a
> > "light" reliable transport.
> >
> > Thanks,
> > Chris
> >
> >
> >
>
>

------------------------------

Date: Thu, 19 Dec 2002 14:33:28 -0500
From: Marshall Glen <[email-masked]>
Subject: RE: Syslog Payload (was "What Can Be Changed in syslog")

Thanks, Chris.

Yes, mine is an independent effort and not a document for this Working
Group.  I just provided it here as an example of the sort of payload that
could be carried by a syslog message.

Some of the people I'm working with would like to implement RFC 3195 as the
message transport, but the message itself is specified in a way that makes
it transport-independent.  There are two basic cases:

1) Dedicated-function devices such as clinical monitors and digital medical
imaging would like a simple but reliable method to report audit data (and,
conceptually, other system events) to a central event processing and
repository service.  This is where syslog is seen as the best solution
direction.

2) Some multi-function systems, such as healthcare information systems and
distributed networks, could use a standard method that enables
two-interaction for audits (e.g., security alarm actions) and system events
(e.g., enabling partial failure operating modes).  In this case a messaging
transport such as ebXML might be a better choice.

Having only recently started following the listserv traffic in this group, I
don't know if these sorts of distinctions have been discussed previously.

Best,
Glen

- -----Original Message-----
From: Christopher Lonvick [mailto:[email-masked]]
Sent: Thursday, December 19, 2002 1:52 PM
To: Marshall Glen
Cc: [email-masked]
Subject: Re: Syslog Payload (was "What Can Be Changed in syslog")

Hi Glen,

I don't mind if you ask this WG for input on your ID.  However, our
charter won't allow it to become a document of this Working Group.
The same goes for any other proposal related to the formatting of
the payload of syslog messages.

All:  Glen would like to get this ID through the process so it may
become an RFC.  Having it reviewed by like-minded people helps that
process.  If you have time+effort, please send comments either to
the list or to Glen.

Thanks,
Chris

On Tue, 17 Dec 2002, Marshall Glen wrote:

>
> Relative to syslog payload format, that may be partly a function of
> application domains.  I'll call your attention to a draft I posted at the
> beginning of this month:
>
> http://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt
>
> Conceptually, this defines what could be a security audit payload for RFC
> 3195 in the healthcare application domain.
>
> Best,
> Glen F. Marshall
>
>
> -----Original Message-----
> From: Christopher Lonvick [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2002 17:41
> To: [email-masked]
> Subject: What Can Be Changed in syslog
>
>
> Hi,
>
> I appreciate the thoughts of everyone on the topics brought up so far.
Let's
> make sure that we all understand what we can do within the current scope
of
> the WG.
>
> TIMESTAMP  This field may be changed in syslog-sign.  We'll have to rev
>            3195 to accept this after syslog-sign is accepted as an RFC.
>
> non-US-ASCII characters in the payload.  This may be addressed in
>            syslog-sign, or specified in another Internet Draft (which will
>            be accepted as a WG document if there are enough people
>            supporting the idea).  Just for reference:
>            ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
>              A Tangled Web: Issues of I18N, Domain Names, and the
>                         Other Internet protocols
>
> payload length.  It's up to the WG to change this.  It may be changed in
>            syslog-sign if that's the concensus of the WG.  In that case,
>            syslog-sign will have to have dire warnings of trying to push
>            the new format through old-style (3164) relays or collectors.
>            We'll have to do that anyway if we change the TIMESTAMP.
>
> payload format.  Out of scope.  I'll allow discussion on the WG mailing
>            list (here) but anything coming from that cannot be a document
>            of this WG.  After we accomplish our Charter Goals, we may ask
>            the ADs to allow the WG to reCharter the WG to address that.
>            ..but not at this time.
>
> I'll ask anyone interested in making changes to any of these to post notes
> to the WG list preferably with a suggestion of modifications to the
current
> IDs, or a suggestion to write a new ID (with the commitment of being the
> author. :)
>
> Let's separate these components apart from the discussion topic of a
"light"
> reliable transport.
>
> Thanks,
> Chris
>
>
>
- ----------------------------------------------------------------------------
- ---
> This message and any included attachments are from Siemens Medical
Solutions
> Health Services Corporation 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 [email-masked].  Thank you
>
>

- -------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
Health Services Corporation 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 [email-masked].  Thank you

------------------------------

Date: Thu, 19 Dec 2002 20:07:36 -0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: RE: What Can Be Changed in syslog

> Interesting thought.  Does anyone else support this?  Would this be "just
> anyone" or should the profiles be registered with IANA?

Anyone could put together an experimental or private profile with an
associated URI, and perhaps publish it as internet draft in the first
instance. Since nobody would be required to implement it in order to interop
with the basics, it shouldn't impact anyone else.

If a particular profile caught on and proved its usefulness, then that could
be put forward for standardisation and registration.

I believe the particular ones I mention below all fall into the category of
possible tuning profiles, so it's just a matter of using that existing
mechanism within BEEP, and it would still interop with existing
implementations.

Cheers,
Frank

> On Wed, 18 Dec 2002, Frank O'Dwyer wrote:
>
> > Chris,
> >
> > There is one other issue which I would like to bring up, which
> may be within
> > the scope of this WG, and that is extensibility.
> >
> > For example, RFC3195 by virtue of its use of BEEP, potentially
> allows for
> > additional (optional) profiles which may relate to the events
> themselves.
> > Some uses of this that I can think of are:
> >
> > - event routing (an upstream node telling a downstream one where to send
> > various events)
> > - event filtering (an upstream node telling a downstream one
> that nothing
> > upstream is interested in event 'foo', so don't bother sending it)
> > - event prioritisation (assigning events to channels, for
> example separating
> > out stuff that needs to be delivered real-time from stuff that doesn't)
> > - negotiating a payload format and/or a superset of the COOKED DTD
> >
> > What I am after here is not a standardisation of the details of all that
> > (though that would be nice), but at least a standard way to
> hook it in, and
> > a means of publishing new profiles and enhanced COOKED DTDs
> without having
> > to revisit the base standards.
> >
> > Maybe this is as simple as stating that the greeting message MAY contain
> > additional profiles that allow nodes to install filters,
> routes, priorities,
> > request a payload format, switch the DTD, etc. Obviously if
> both ends do not
> > support a given profile, format or DTD it would simply be ignored.
> >
> > Cheers,
> > Frank
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> Christopher Lonvick
> > > Sent: 17 December 2002 22:41
> > > To: [email-masked]
> > > Subject: What Can Be Changed in syslog
> > >
> > >
> > > Hi,
> > >
> > > I appreciate the thoughts of everyone on the topics brought up so far.
> > > Let's make sure that we all understand what we can do within
> the current
> > > scope of the WG.
> > >
> > > TIMESTAMP  This field may be changed in syslog-sign.  We'll
> have to rev
> > >            3195 to accept this after syslog-sign is accepted
> as an RFC.
> > >
> > > non-US-ASCII characters in the payload.  This may be addressed in
> > >            syslog-sign, or specified in another Internet
> Draft (which will
> > >            be accepted as a WG document if there are enough people
> > >            supporting the idea).  Just for reference:
> > >            ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
> > >              A Tangled Web: Issues of I18N, Domain Names, and the
> > >                         Other Internet protocols
> > >
> > > payload length.  It's up to the WG to change this.  It may be
> changed in
> > >            syslog-sign if that's the concensus of the WG.  In
> that case,
> > >            syslog-sign will have to have dire warnings of
> trying to push
> > >            the new format through old-style (3164) relays or
> collectors.
> > >            We'll have to do that anyway if we change the TIMESTAMP.
> > >
> > > payload format.  Out of scope.  I'll allow discussion on the
> WG mailing
> > >            list (here) but anything coming from that cannot
> be a document
> > >            of this WG.  After we accomplish our Charter
> Goals, we may ask
> > >            the ADs to allow the WG to reCharter the WG to
> address that.
> > >            ..but not at this time.
> > >
> > > I'll ask anyone interested in making changes to any of these
> to post notes
> > > to the WG list preferably with a suggestion of modifications to the
> > > current IDs, or a suggestion to write a new ID (with the commitment of
> > > being the author. :)
> > >
> > > Let's separate these components apart from the discussion topic of a
> > > "light" reliable transport.
> > >
> > > Thanks,
> > > Chris
> > >
> > >
> > >
> >
> >
>
>

------------------------------

Date: Thu, 19 Dec 2002 15:17:54 -0500
From: Chris Calabrese <[email-masked]>
Subject: Re: Syslog Payload (was "What Can Be Changed in syslog")

FYI,

I was working on similar stuff a while back. It was an XML model based
on Abela and Debeaupuis' ULM model, and Nicolas Jombart had modifed
HSC's ULM-ified syslog to deal with it. There was also some vendor interest.

I'm too busy with Center for Internet Security stuff to work on this
actively, but feel free to borrow/steal liberally (just give me credit
where due)..

Marshall Glen wrote:

>Thanks, Chris.
>
>Yes, mine is an independent effort and not a document for this Working
>Group.  I just provided it here as an example of the sort of payload that
>could be carried by a syslog message.
>
>Some of the people I'm working with would like to implement RFC 3195 as the
>message transport, but the message itself is specified in a way that makes
>it transport-independent.  There are two basic cases:
>
>1) Dedicated-function devices such as clinical monitors and digital medical
>imaging would like a simple but reliable method to report audit data (and,
>conceptually, other system events) to a central event processing and
>repository service.  This is where syslog is seen as the best solution
>direction.
>
>2) Some multi-function systems, such as healthcare information systems and
>distributed networks, could use a standard method that enables
>two-interaction for audits (e.g., security alarm actions) and system events
>(e.g., enabling partial failure operating modes).  In this case a messaging
>transport such as ebXML might be a better choice.
>
>Having only recently started following the listserv traffic in this group, I
>don't know if these sorts of distinctions have been discussed previously.
>
>Best,
>Glen
>
>-----Original Message-----
>From: Christopher Lonvick [mailto:[email-masked]]
>Sent: Thursday, December 19, 2002 1:52 PM
>To: Marshall Glen
>Cc: [email-masked]
>Subject: Re: Syslog Payload (was "What Can Be Changed in syslog")
>
>
>Hi Glen,
>
>I don't mind if you ask this WG for input on your ID.  However, our
>charter won't allow it to become a document of this Working Group.
>The same goes for any other proposal related to the formatting of
>the payload of syslog messages.
>
>All:  Glen would like to get this ID through the process so it may
>become an RFC.  Having it reviewed by like-minded people helps that
>process.  If you have time+effort, please send comments either to
>the list or to Glen.
>
>Thanks,
>Chris
>
>On Tue, 17 Dec 2002, Marshall Glen wrote:
>
>
>
>>Relative to syslog payload format, that may be partly a function of
>>application domains.  I'll call your attention to a draft I posted at the
>>beginning of this month:
>>
>>http://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt
>>
>>Conceptually, this defines what could be a security audit payload for RFC
>>3195 in the healthcare application domain.
>>
>>Best,
>>Glen F. Marshall
>>
>>
>>-----Original Message-----
>>From: Christopher Lonvick [mailto:[email-masked]]
>>Sent: Tuesday, December 17, 2002 17:41
>>To: [email-masked]
>>Subject: What Can Be Changed in syslog
>>
>>
>>Hi,
>>
>>I appreciate the thoughts of everyone on the topics brought up so far.
>>
>>
>Let's
>
>
>>make sure that we all understand what we can do within the current scope
>>
>>
>of
>
>
>>the WG.
>>
>>TIMESTAMP  This field may be changed in syslog-sign.  We'll have to rev
>>           3195 to accept this after syslog-sign is accepted as an RFC.
>>
>>non-US-ASCII characters in the payload.  This may be addressed in
>>           syslog-sign, or specified in another Internet Draft (which will
>>           be accepted as a WG document if there are enough people
>>           supporting the idea).  Just for reference:
>>           ftp://ftp.rfc-editor.org/in-notes/rfc2825.txt
>>             A Tangled Web: Issues of I18N, Domain Names, and the
>>                        Other Internet protocols
>>
>>payload length.  It's up to the WG to change this.  It may be changed in
>>           syslog-sign if that's the concensus of the WG.  In that case,
>>           syslog-sign will have to have dire warnings of trying to push
>>           the new format through old-style (3164) relays or collectors.
>>           We'll have to do that anyway if we change the TIMESTAMP.
>>
>>payload format.  Out of scope.  I'll allow discussion on the WG mailing
>>           list (here) but anything coming from that cannot be a document
>>           of this WG.  After we accomplish our Charter Goals, we may ask
>>           the ADs to allow the WG to reCharter the WG to address that.
>>           ..but not at this time.
>>
>>I'll ask anyone interested in making changes to any of these to post notes
>>to the WG list preferably with a suggestion of modifications to the
>>
>>
>current
>
>
>>IDs, or a suggestion to write a new ID (with the commitment of being the
>>author. :)
>>
>>Let's separate these components apart from the discussion topic of a
>>
>>
>"light"
>
>
>>reliable transport.
>>
>>Thanks,
>>Chris
>>
>>
>>
>>
>>
>----------------------------------------------------------------------------
>---
>
>
>>This message and any included attachments are from Siemens Medical
>>
>>
>Solutions
>
>
>>Health Services Corporation 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 [email-masked].  Thank you
>>
>>
>>
>>
>
>-------------------------------------------------------------------------------
>This message and any included attachments are from Siemens Medical Solutions
>Health Services Corporation 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 [email-masked].  Thank you
>
>
>
>

- -- 
Chris Calabrese, GCIA, GCFA
Internet Security Analyst
MedcoHealth.com

<html><head><title>XML for Secure System Logs</title>
<STYLE type='text/css'>
    .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
             font-family: helvetica, arial, sans-serif }
    .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
                  font-family: helvetica, arial, sans-serif }
    p.copyright { color: #000000; font-size: 10px;
                  font-family: verdana, charcoal, helvetica, arial, sans-serif }
    p { margin-left: 2em; margin-right: 2em; }
    ol { margin-left: 2em; margin-right: 2em; }
    ul.text { margin-left: 2em; margin-right: 2em; }
    pre { margin-left: 3em; color: #333333 }
    ul.toc { color: #000000; line-height: 16px;
             font-family: verdana, charcoal, helvetica, arial, sans-serif }
    H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
    H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
    TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
    TD.author-text { color: #000000; font-size: 10px;
                     font-family: verdana, charcoal, helvetica, arial, sans-serif }
    TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
    A:link { color: #990000; font-size: 10px; text-transform: uppercase; font-weight: bold;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
    A:visited { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase;
                font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
    A:name { color: #333333; font-weight: bold; font-size: 10px; text-transform: uppercase;
             font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
    .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
             font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
             font-size: 9px }
    .RFC { color:#666666; font-weight: bold; text-decoration: none;
           font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
           font-size: 9px }
    .hotText { color:#ffffff; font-weight: normal; text-decoration: none;
               font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
               font-size: 9px }
</style>
</head>
<body bgcolor="#ffffff"text="#000000" alink="#000000" vlink="#666666" link="#990000">
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Network Working Group</td><td width="33%" bgcolor="#666666" class="header">C. J. Calabrese</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">The SANS Institute</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: July 16, 2001</td><td width="33%" bgcolor="#666666" class="header">January 15, 2001</td></tr>
</table></td></tr></table>
<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">XML for Secure System Logs</span></b></font></div>
<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-calabrese-xml-log-00</span></b></font></div>
<font face="verdana, helvetica, arial, sans-serif" size="2">

<h3>Status of this Memo</h3>
<p>
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on July 16, 2001.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (C) The Internet Society (2001). All Rights Reserved.</p>

<h3>Abstract</h3>

<p>

		This memo presents an Extensible Markup Language
		<a href="#W3C98">(XML)</a>[16]
		encoding that applications may use to express logging
		information in a structured manner.  Thus making these logs
		easier for computer programs to parse the the free-form
		data traditionally associated with
		<a href="#CSRG">Syslog</a>[3]-based logs.

</p>
<a name="toc"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Table of Contents</h3>
<ul compact class="toc">
<b><a href="#introduction">1.</a>&nbsp;
Introduction<br></b>
<b><a href="#overview">2.</a>&nbsp;
Schema Overview<br></b>
<b><a href="#examples">3.</a>&nbsp;
Examples<br></b>
<b><a href="#anchor1">3.1</a>&nbsp;
Nested `log:EVNT' Entries<br></b>
<b><a href="#xml-deviation">4.</a>&nbsp;
Deviation from Pure XML<br></b>
<b><a href="#implementation">5.</a>&nbsp;
Implementation Considerations<br></b>
<b><a href="#anchor2">5.1</a>&nbsp;
Event Filtering<br></b>
<b><a href="#anchor3">5.2</a>&nbsp;
Event Viewing/Reporting<br></b>
<b><a href="#anchor4">5.3</a>&nbsp;
Logging API's<br></b>
<b><a href="#anchor5">5.4</a>&nbsp;
Backward Compatibility<br></b>
<b><a href="#anchor6">5.4.1</a>&nbsp;
Syslog<br></b>
<b><a href="#anchor7">5.4.2</a>&nbsp;
NT Event Logger<br></b>
<b><a href="#anchor8">5.5</a>&nbsp;
Network Communications<br></b>
<b><a href="#sec">6.</a>&nbsp;
Security Considerations<br></b>
<b><a href="#anchor9">6.1</a>&nbsp;
Correctness and Completeness of Identifying Information<br></b>
<b><a href="#anchor10">6.2</a>&nbsp;
Confidentiality, Integrity, and Availability of Log Messages<br></b>
<b><a href="#rfc.references">&#167;</a>&nbsp;
References<br></b>
<b><a href="#rfc.authors">&#167;</a>&nbsp;
Author's Address<br></b>
<b><a href="#anchor11">A.</a>&nbsp;
XML DTD for the `log:EVNT' Element<br></b>
<b><a href="#data_types">B.</a>&nbsp;
XML DTD for Data Types Used in the `log:EVNT' Element<br></b>
<b><a href="#rfc.copyright">&#167;</a>&nbsp;
Full Copyright Statement<br></b>
</ul>
<br clear="all">

<a name="introduction"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>1.&nbsp;Introduction</h3>

<p>

		One of the most important aspects of system, application,
		and security administration is event logging.
		Such logging involves capturing information about
		important events, possibly transmitting that information
		to a centralized logging facility,
		timestamping/filtering/manipulating the information,
		recording the information to persistent storage,
		and finally filtering, retrieval and analysis by events
		by an off-line program or person.
		  <br>
<br>

		This memo presents an Extensible Markup Language
		<a href="#W3C98">(XML)</a>[16]
		encoding that applications may use to express logging
		information in a structured manner.  Thus making these logs
		easier for computer programs to parse the the free-form
		data traditionally associated with
		<a href="#CSRG">Syslog</a>[3]-based logs.
		  <br>
<br>

		This  scheme is, for the most part, an
		"XML-ization" of the Abela and Debeaupuis'
		Universal Format for Logger Messages
		<a href="#ULM">(ULM)</a>[11].
		A new version of their ULM tool
		has been written by Nicolas Jombart to deal with an
		earlier version of this XML-ized
		format<a href="#Jombart">[12]</a>.
		  <br>
<br>

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
		"MAY", and "OPTIONAL" in this document are to be
		interpreted as described in
		<a href="#RFC2119">RFC 2119</a>[1].

</p>

<a name="overview"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>2.&nbsp;Schema Overview</h3>

<p>

		The basic idea is very straight forward.  Each log entry
		is represented by a 'log:EVNT' element.  Inside this
		element are the following attributes:

<blockquote class="text"><dl>

<dt>log:HOST</dt>
<dd>

			The host on which the log entry was originally
			generated.

</dd>

<dt>log:DATE</dt>
<dd>

			The date/time at which the log was generated in
			'<a href="#data_types">ISO.8601:1998_Date_Format</a>'.
			<a href="#ISO.8601">[2]</a>
</dd>

<dt>log:SEV</dt>
<dd>

			Severity of the event using the standard
			<a href="#CSRG">Syslog</a>[3]
			as enumerated in
			'<a href="#data_types">log:SEV_Format</a>'
			(`LOG_DEBUG',
			 `LOG_INFO',
			 `LOG_NOTICE',
			 `LOG_WARNING',
			 `LOG_ERR',
			 `LOG_CRIT',
			 `LOG_ALERT',
			 `LOG_EMERG',).
			  <br>

			When operating in Windows NT environments,
			the native NT Event Types (`Information', `Warning',
			`Error', `Success Audit', and `Falure Audit')
			should map into `LOG_INFO', `LOG_WARNING',,
			`LOG_ERR', `LOG_INFO', and `LOG_INFO'
			respecitively.
			  <br>
<br>

			Similarly, the standard SNMP Trap Severities
			(`Normal', `Warning', `Minor', `Major',
			and `Critical') should map into `LOG_INFO',
			`LOG_WARNING', `LOG_ERR', `LOG_ERR', and
			`LOG_CRIT' respecitively.
			  <br>
<br>

			NOTE: Need references for NT and SNMP

</dd>

<dt>log:PROC.NAME</dt>
<dd>

			The name of the program generating the event.
			Can either be a simple name (`Sendmail'),
			or a hierarchy identifying the program and
			it's Facility (`Mail/MTA/Sendmail',
			`Audit/Tripwire', `Kernel/FS/Buffer_Cache').

			NOTE: Standard hiercharies need to be specified.

</dd>

<dt>log:PROC.ID</dt>
<dd>

			An identification of the instance of the
			program/process that generated the event.
			On a Unix system, this would by the
			process identification (`PID')
			plus the thread identifier for multi-threaded
			processes (`2207.3').

</dd>

<dt>log:PROC.PRIV</dt>
<dd>

			A list of any security ID's/groups/labels
			associated with the process generating the log
			entry (`USR-chris, UID-748, GRP-adm, GRP-sys,
			GRP-users, EUID-root, EGID-kmem, DAC_READ,
			SYSTEM_HIGH')

			NOTE: Need to specify standard nonclemature for
			Unix, NT, and IEEE 1003.1e/2c priveleges.
			Also, do we really want to do it this way, or
			would it be better done as different attribute
			types, or even nested elements or something?

</dd>

<dt>log:PROC.MAIL</dt>
<dd>

			An e-mail address associated with the
			usr/login/account the process is running as.

</dd>

<dt>log:PROC.TTY</dt>
<dd>

			The TTY or other description of the
			user's physical connection to the
			host generating the event.

</dd>

<dt>log:EVENT.TYPE</dt>
<dd>

			Gives a further taxonomy of the type of event that
			occurred.  Allowed values given under
			'<a href="#data_types">log:Event_Type_Enumeration</a>'.

</dd>

<dt>XML:LANG</dt>
<dd>

			The language used for any textual messages in the
			standard XML `LangCode'
			format<a href="#W3C98">[16]</a>.

</dd>

<dt>log:DUR</dt>
<dd>

			Duration of the event being logged in
			'<a href="#data_types">Seconds.Decimel</a>' format.

</dd>

<dt>log:SRC.ADDR (log:DST.ADDR)</dt>
<dd>

			The network source (destination)
			address of any network traffic represented
			by this event in
			'<a href="#data_types">log:Address_Format</a>'.

</dd>

<dt>log:SRC.PROT (log:DST.PROT)</dt>
<dd>

			The network protocols/ports used by the
			source (destination) of network traffic in
			'<a href="#data_types">log:Protocol_Format</a>'
			(`IP/TCP/25/ESMTP', `IP/ICMP/Source_Quench').

</dd>

<dt>log:SRC.FQDN (log:DST.FQDN)</dt>
<dd>

			The fully qualified domain name for
			the traffic source (destination).

</dd>

<dt>log:SRC.NAME (log:DST.NAME)</dt>
<dd>

			Some other unique identifier for the
			traffic source (destination).

</dd>

<dt>log:SRC.USR (log:DST.USR)</dt>
<dd>

			A user/login/account associated with the
			traffic source (destination).

</dd>

<dt>log:SRC.MAIL (log.DST.MAIL)</dt>
<dd>

			An e-mail address associated with the
			traffic source (destination).

</dd>

<dt>log:REL.IN.ADDR, log:REL.IN.PROT, log:REL.IN.FQDN, log:REL.IN.NAME, log:REL.IN.USR, log:REL.IN.MAIL, log:REL.OUT.ADDR, log:REL.OUT.PROT, log:REL.OUT.FQDN, log:REL.OUT.NAME, log:REL.OUT.USR, log:REL.OUT.MAIL</dt>
<dd>

			Similar to the `log:SRC.' and `log:DST.'
			attributes, but representing inbound and outbound
			traffic through a relay or proxy.

</dd>

<dt>log:VOL, VOL.SENT, VOL.RCVD</dt>
<dd>

			Total data volume in octets, volume sent, and
			volume received.

</dd>

<dt>log:CNT, log:CNT.SENT, log:CNT.RCVD</dt>
<dd>

			Total data volume in records, records sent, and
			records received.

</dd>

<dt>log:PROG.FILE, log:PROG.LINE</dt>
<dd>

			The name of the program source file and line
			number within the source file.  Typically used for
			debugging and assert messages.

</dd>

<dt>log:DOC</dt>
<dd>

			Name of an accessed document/file, such as an FTP
			file, a newsgroup, or a URL.

</dd>

<dt>log:CMD</dt>
<dd>

			Issued command that generated the event.
			For example:
			</font><pre>
&lt;log:EVNT ... log:CMD="/bin/rm -rf /"&gt;
				</pre><font face="verdana, helvetica, arial, sans-serif" size="2">

</dd>

<dt>log:MSG</dt>
<dd>

			Free form message text.

</dd>

</dl></blockquote>

</p>

<a name="examples"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>3.&nbsp;Examples</h3>

<h4><a name="anchor1">3.1</a>&nbsp;Nested `log:EVNT' Entries</h4>

<p>

		    At first blush, it's not obvious why we need a MSG
		    attribute when we could use something like:
		    </font><pre>
&lt;log:EVNT ...&gt;this is the text&lt;/log:EVNT&gt;
			    </pre><font face="verdana, helvetica, arial, sans-serif" size="2">

		    The reason is to allow `log:EVNT' elements to nest.
		    One possible interpretation of nested log entries is to
		    be able to represent complex relationships in the data.
		    Instead, here we use nesting to collapse redundant data.
		    For example, the following are considered equivalent:
		    </font><pre>
&lt;log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
 log:PROC.ID=1234 log:MSG="unexpected file"
 log:DOC="/a/b/c"/&gt;
&lt;log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
 log:PROC.ID=1234 log:MSG="unexpected file"
 log:DOC="/a/b/d"/&gt;
&lt;log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
 log:PROC.ID=1234 log:MSG="unexpected file"
 log:DOC="/a/b/e"/&gt;

&lt;log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
log:PROC.ID=1234 log:MSG="unexpected file"&gt;
    &lt;log:EVNT log:DOC="/a/b/c"/&gt;
    &lt;log:EVNT log:DOC="/a/b/d"/&gt;
    &lt;log:EVNT log:DOC="/a/b/e"/&gt;
    &lt;/log:EVNT&gt;
			    </pre><font face="verdana, helvetica, arial, sans-serif" size="2">

		    As a result, only inner-most `log:EVNT'
		    elements are log entries.
		    Outer `log:EVNT' elements set
		    attributes common to the contained entries.

</p>

<a name="xml-deviation"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>4.&nbsp;Deviation from Pure XML</h3>

<p>

		Although XML is a good fit for the structure needed to describe
		system logs, it is not a perfect fit.  In particular:

<ol class="text">

<li>

			In the interest of compactness, logs will be
			considered complete even if they do not contain
			the standard XML prolog containing the XML version,
			element declarations, etc.

</li>

<li>

			Also in the interest of compactness, log message streams
			not beginning with `&lt;' will assume to be
			bracketed by `&lt;log:' and `&gt;'.
			This way, the existing syslog behavior of sending a
			single log entry inside a single UDP packet may be
			preserved.

</li>

<li>

			Some might argue that having the free-form messages as
			`log:MSG' attribute values is somewhat messy from an XML
			standpoint and that "proper" XML would be to unravel the
			nesting and put the message text in as the "payload"
			of the `log:EVNT' elements.

</li>

</ol>

		Implementations may contain a tool to generate 100% XML
		compliant "documents" from log files so that the logs may
		be processed by standard XML tools.

</p>

<a name="implementation"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>5.&nbsp;Implementation Considerations</h3>

<h4><a name="anchor2">5.1</a>&nbsp;Event Filtering</h4>

<p>

		    NOTE: Need info about filtering...

</p>

<h4><a name="anchor3">5.2</a>&nbsp;Event Viewing/Reporting</h4>

<p>

		    NOTE: Need info viewing/reporting...

</p>

<h4><a name="anchor4">5.3</a>&nbsp;Logging API's</h4>

<p>

		    NOTE: Need info on API's, especially making sure that
		    the TCB generates whatever information it can.
		    Refer to sec section.

</p>

<h4><a name="anchor5">5.4</a>&nbsp;Backward Compatibility</h4>

<h4><a name="anchor6">5.4.1</a>&nbsp;Syslog</h4>

<p>

			NOTE: Need info on this..., especially issue of
			including level/facility info in both XML and
			native syslog levels.

</p>

<h4><a name="anchor7">5.4.2</a>&nbsp;NT Event Logger</h4>

<p>

			NOTE: Need info on this...

</p>

<h4><a name="anchor8">5.5</a>&nbsp;Network Communications</h4>

<p>

			NOTE: Need info on this..., including references
			to Syslog WG work.

</p>

<a name="sec"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>6.&nbsp;Security Considerations</h3>

<h4><a name="anchor9">6.1</a>&nbsp;Correctness and Completeness of Identifying Information</h4>

<p>

		    NOTE: TCB should/must generate
		    log:HOST log:DATE log:SEV
		    log:PROC.NAME log:PROC.ID log:PROC.PRIV

</p>

<h4><a name="anchor10">6.2</a>&nbsp;Confidentiality, Integrity, and Availability of Log Messages</h4>

<p>

		    The confidentiality, integrity, and availability of log
		    messages or logging mechanisms is beyond the scope of
		    this memo.  However, these issues are addressed in the
		    following places.
		      <br>

		    NOTE: need references here...

</p>
<a name="rfc.references"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>
References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><b><a name="RFC2119">[1]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to
			Indicate Requirement Levels</a>", RFC 2119, BCP 14, March 1997.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="ISO.8601">[2]</a></b></td>
<td class="author-text">International Standards Organization, "Data elements and interchange formats -
			Information interchange - Representation of dates
			and times", International Standard ISO 8601:1988, available from http://www.iso.ch/markete/8601.pdf, 1988.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="CSRG">[3]</a></b></td>
<td class="author-text">University of California Computer Systems
			    Research Group, "Unix Programmer's Manual, 4.3 Berkeley
			Software Distribution, Virtual VAX-11 Version", April 1986.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="TCSEC">[4]</a></b></td>
<td class="author-text">U.S. Department of Defense,
			    Assistant Secretary of Defense for
			    Command, Control, Communications,
			    and Intelligence, "Department of Defense Trusted Computer System
			Evaluation Criteria", DoD 5200.28-STD, available from http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html, December 1985.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="CC">[5]</a></b></td>
<td class="author-text">International Standards Organization, "Common Criteria for Information Technology
			Security Evaluation Version 2.1", International Standard ISO/IEC 15408:1999, available from http://www.radium.ncsc.mil/tpep/library/ccitse/ccitse.html, August 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="LSPP">[6]</a></b></td>
<td class="author-text">U.S. National Security Agency,
			    Information Systems Security Organization, "Labeled Security Protection Profile", available from http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html, October 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="CAPP">[7]</a></b></td>
<td class="author-text">U.S. National Security Agency,
			    Information Systems Security Organization, "Controlled Access Protection Profile", available from http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html, October 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="Lonvick">[8]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Lonvick, C.M.</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-syslog-03.txt">syslog Protocol</a>", draft-ietf-syslog-syslog-03 (work in progress), January 2001.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="SK98">[9]</a></b></td>
<td class="author-text"><a href="http://www.counterpane.com">Schneier, B.</a> and <a href="mailto:[email-masked]">J. Kelsey</a>, "Cryptographic Support for Secure
			Logs on Untrusted Machines", The Seventh USENIX Security Symposium Proceedings, USENIX Press pp. 53-62, available from http://www.counterpane.com/secure-logs.html, January 1998.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="SK99">[10]</a></b></td>
<td class="author-text"><a href="http://www.counterpane.com">Schneier, B.</a> and <a href="mailto:[email-masked]">J. Kelsey</a>, "Minimizing Bandwidth for Remote Access to
			Cryptographically Protected Audit Logs", Second International Workshop on the Recent Advances inIntrusion Detection (RAID '99), available from http://www.counterpane.com/auditlog2.html, September 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="ULM">[11]</a></b></td>
<td class="author-text"><a href="http://www.hsc.fr">Abela, J.</a> and <a href="http://www.hsc.fr">T. Debeaupuis</a>, "Universal Format for Logger Messages", May 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="Jombart">[12]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Jombart, N.</a>, "Private correspondence", May 2000.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="syslog-reliable">[13]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">New, D.</a> and <a href="mailto:[email-masked]">M.T. Rose</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-reliable-02.txt">Reliable Delivery for Syslog</a>", draft-ietf-syslog-reliable-02 (work in progress), November 2000.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="syslog-auth">[14]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Kelsey, J.</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-auth-00.txt">Syslog-Auth Protocol</a>", draft-ietf-syslog-auth-00 (work in progress), December 2000.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="syslog-sign">[15]</a></b></td>
<td class="author-text"><a href="mailto:[email-masked]">Kelsey, J.</a>, "<a href="http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-00.txt">Syslog-Sign Protocol</a>", draft-ietf-syslog-sign-00 (work in progress), December 2000.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="W3C98">[16]</a></b></td>
<td class="author-text"><a href="http://www.w3c.org">World Wide Web Consortium</a>, "Extensible Markup Language (XML) 1.0.", available from http://www.w3.org/TR/REC-xml, February 1998.</td></tr>
</table>

<a name="rfc.authors"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Christopher J. Calabrese</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">The SANS Institute</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">26 Wellesley Road</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Upper Montclair, NJ  07043</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">US</td></tr>
<tr><td class="author" align="right">Phone:&nbsp;</td>
<td class="author-text">+1 973 233 1464</td></tr>
<tr><td class="author" align="right">EMail:&nbsp;</td>
<td class="author-text"><a href="mailto:[email-masked]">[email-masked]</a></td></tr>
</table>

<a name="anchor11"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix A.&nbsp;XML DTD for the `log:EVNT' Element</h3>

<p>
</font><pre>
&lt;!-- Note that attributes are marked REQUIRED
  -- here if it is implied by draft-calabrese-requir-loggprot-01.
  -- This assumes this information is not being provided by
  -- another source.
  --&gt;
&lt;!ELEMENT log:ENTRY (log:ENTRY)*&gt;
&lt;!ATTLIST log:ENTRY
    log:HOST CDATA #REQUIRED
    log:DATE ISO.8601:1998_Date_Format #REQUIRED
    log:SEV log:Severity_Type #REQUIRED
    log:PROC.NAME CDATA #REQUIRED
    log:PROC.ID CDATA #REQUIRED
    log:PROC.PRIV CDATA #REQUIRED
    log:PROC.MAIL CDATA #IMPLIED
    log:PROC.TTY CDATA #IMPLIED
    log:EVENT.TYPE log:Event_Type_Enumeration #IMPLIED
    log:XML:LANG LangCode "EN"
    log:DUR Seconds.Decimal #IMPLIED
    log:SRC.ADDR log:Address_Format #IMPLIED
    log:SRC.PROT log:Protocol_Format #IMPLIED
    log:SRC.FQDN CDATA #IMPLIED
    log:SRC.NAME CDATA #IMPLIED
    log:SRC.USR CDATA #IMPLIED
    log:SRC.MAIL CDATA #IMPLIED
    log:DST.ADDR log:Address_Format #IMPLIED
    log:DST.PROT log:Protocol_Format #IMPLIED
    log:DST.FQDN CDATA #IMPLIED
    log:DST.NAME CDATA #IMPLIED
    log:DST.USR CDATA #IMPLIED
    log:DST.MAIL CDATA #IMPLIED
    log:REL.IN.ADDR log:Address_Format #IMPLIED
    log:REL.IN.PROT log:Protocol_Format #IMPLIED
    log:REL.IN.FQDN CDATA #IMPLIED
    log:REL.IN.NAME CDATA #IMPLIED
    log:REL.IN.USR CDATA #IMPLIED
    log:REL.IN.MAIL CDATA #IMPLIED
    log:REL.OUT.ADDR log:Address_Format #IMPLIED
    log:REL.OUT.PROT log:Protocol_Format #IMPLIED
    log:REL.OUT.FQDN CDATA #IMPLIED
    log:REL.OUT.NAME CDATA #IMPLIED
    log:REL.OUT.USR CDATA #IMPLIED
    log:REL.OUT.MAIL CDATA #IMPLIED
    log:VOL Integer #IMPLIED
    log:VOL.SENT Integer #IMPLIED
    log:VOL.RCVD Integer #IMPLIED
    log:CNT Integer #IMPLIED
    log:CNT.SENT Integer #IMPLIED
    log:CNT.RCVD Integer #IMPLIED
    log:PROG.FILE CDATA #IMPLIED
    log:PROG.LINE Integer #IMPLIED
    log:DOC CDATA #IMPLIED
    log:CMD CDATA #IMPLIED
    log:MSG CDATA #IMPLIED
    &gt;
			</pre><font face="verdana, helvetica, arial, sans-serif" size="2">

</p>

<a name="data_types"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Appendix B.&nbsp;XML DTD for Data Types Used in the `log:EVNT' Element</h3>

<p>
</font><pre>
&lt;!NOTATION log:Severity_Type ('0'|'1'|...|'99')&gt;
&lt;!NOTATION ISO.8601:1998_Date_Format
    (YYYY '-' MM '-' DD 'T' hh ':'
     mm [':' ss ['.' f+]]('+' | '-') zzzz)&gt;
    &lt;!-- NOTE: Need reference and further
     explanation of date format --&gt;
&lt;!NOTATION Seconds.Decimal
    (ss ['.' f+])
&lt;!NOTATION log:Event_Type_Enumeration
    ('AUTH.FAIL'|'AUTH.SUCCESS'|'PROG.FAIL'|'PROG.START'|...)&gt;
    &lt;!-- NOTE: Need more complete enumeration. --&gt;
&lt;!NOTATION log:Address_Format
    (IPv4_Address|IPv6_Address|IPX_Address|...)&gt;
    &lt;!-- NOTE: Do we need more a complete
     enumeration? of address types? --&gt;
&lt;!NOTATION IPv4_Address CDATA &gt;
    &lt;!-- NOTE: Need proper definition
     and reference for IPv4 addresses --&gt;
&lt;!NOTATION IPv6_Address CDATA&gt;
    &lt;!-- NOTE: Need proper definition
     and reference for IPv6 addresses --&gt;
&lt;!NOTATION IPX_Address CDATA&gt;
    &lt;!-- NOTE: Need proper definition
     and reference for IPX addresses --&gt;
&lt;!NOTATION log:Protocol_Format
    ( ('IPv4/' ('UDP'|'TCP') '/' IPv4_Port_Number ['/' CDATA])
    | ('IPv4/ICMP/' IPv4_ICMP_Message_Type)
    | ( ('IPv6/' ('UDP'|'TCP') '/' IPv6_Port_Number ['/' CDATA])
    | ('IPv6/ICMP/' IP64_ICMP_Message_Type)
    | ('IPX' ['/SPX/'] IPX_Port_Number ['/' CDATA])
    )
    &lt;!-- NOTE: Need further definitions of
     referenced types... --&gt;
			</pre><font face="verdana, helvetica, arial, sans-serif" size="2">

</p>
<a name="rfc.copyright"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b>&nbsp;TOC&nbsp;</b></font></a><br></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class='copyright'>
Copyright (C) The Internet Society (2001). All Rights Reserved.</p>
<p class='copyright'>
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.</p>
<p class='copyright'>
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.</p>
<p class='copyright'>
This document and the information contained herein is provided on an
&quot;AS IS&quot; basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p>
<h3>Acknowledgement</h3>
<p class='copyright'>
Funding for the RFC editor function is currently provided by the
Internet Society.</p>
</font></body></html>

Network Working Group                                    C. J. Calabrese
Internet-Draft                                        The SANS Institute
Expires: July 16, 2001                                  January 15, 2001

                       XML for Secure System Logs
                       draft-calabrese-xml-log-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 16, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   This memo presents an Extensible Markup Language (XML)[16] encoding
   that applications may use to express logging information in a
   structured manner.  Thus making these logs easier for computer
   programs to parse the the free-form data traditionally associated
   with Syslog[3]-based logs.

Calabrese                Expires July 16, 2001                  [Page 1]

Internet-Draft         XML for Secure System Logs           January 2001

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Schema Overview  . . . . . . . . . . . . . . . . . . . . . .  4
   3.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1   Nested `log:EVNT' Entries  . . . . . . . . . . . . . . . . .  7
   4.    Deviation from Pure XML  . . . . . . . . . . . . . . . . . .  8
   5.    Implementation Considerations  . . . . . . . . . . . . . . .  9
   5.1   Event Filtering  . . . . . . . . . . . . . . . . . . . . . .  9
   5.2   Event Viewing/Reporting  . . . . . . . . . . . . . . . . . .  9
   5.3   Logging API's  . . . . . . . . . . . . . . . . . . . . . . .  9
   5.4   Backward Compatibility . . . . . . . . . . . . . . . . . . .  9
   5.4.1 Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.4.2 NT Event Logger  . . . . . . . . . . . . . . . . . . . . . .  9
   5.5   Network Communications . . . . . . . . . . . . . . . . . . .  9
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
   6.1   Correctness and Completeness of Identifying Information  . . 10
   6.2   Confidentiality, Integrity, and Availability of Log Messages 10
         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
   A.    XML DTD for the `log:EVNT' Element . . . . . . . . . . . . . 13
   B.    XML DTD for Data Types Used in the `log:EVNT' Element  . . . 15
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 16

Calabrese                Expires July 16, 2001                  [Page 2]

Internet-Draft         XML for Secure System Logs           January 2001

1. Introduction

   One of the most important aspects of system, application, and
   security administration is event logging. Such logging involves
   capturing information about important events, possibly transmitting
   that information to a centralized logging facility,
   timestamping/filtering/manipulating the information, recording the
   information to persistent storage, and finally filtering, retrieval
   and analysis by events by an off-line program or person.

   This memo presents an Extensible Markup Language (XML)[16] encoding
   that applications may use to express logging information in a
   structured manner.  Thus making these logs easier for computer
   programs to parse the the free-form data traditionally associated
   with Syslog[3]-based logs.

   This  scheme is, for the most part, an "XML-ization" of the Abela
   and Debeaupuis' Universal Format for Logger Messages (ULM)[11]. A
   new version of their ULM tool has been written by Nicolas Jombart to
   deal with an earlier version of this XML-ized format[12].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119[1].

Calabrese                Expires July 16, 2001                  [Page 3]

Internet-Draft         XML for Secure System Logs           January 2001

2. Schema Overview

   The basic idea is very straight forward.  Each log entry is
   represented by a 'log:EVNT' element.  Inside this element are the
   following attributes:

   log:HOST The host on which the log entry was originally generated.

   log:DATE The date/time at which the log was generated in
      'ISO.8601:1998_Date_Format (Appendix B)'. [2]

   log:SEV Severity of the event using the standard Syslog[3] as
      enumerated in 'log:SEV_Format (Appendix B)' (`LOG_DEBUG',
      `LOG_INFO', `LOG_NOTICE', `LOG_WARNING', `LOG_ERR', `LOG_CRIT',
      `LOG_ALERT', `LOG_EMERG',).

      When operating in Windows NT environments, the native NT Event
      Types (`Information', `Warning', `Error', `Success Audit', and
      `Falure Audit') should map into `LOG_INFO', `LOG_WARNING',,
      `LOG_ERR', `LOG_INFO', and `LOG_INFO' respecitively.

      Similarly, the standard SNMP Trap Severities (`Normal',
      `Warning', `Minor', `Major', and `Critical') should map into
      `LOG_INFO', `LOG_WARNING', `LOG_ERR', `LOG_ERR', and `LOG_CRIT'
      respecitively.

      NOTE: Need references for NT and SNMP

   log:PROC.NAME The name of the program generating the event. Can
      either be a simple name (`Sendmail'), or a hierarchy identifying
      the program and it's Facility (`Mail/MTA/Sendmail',
      `Audit/Tripwire', `Kernel/FS/Buffer_Cache').
      NOTE: Standard hiercharies need to be specified.

   log:PROC.ID An identification of the instance of the program/process
      that generated the event. On a Unix system, this would by the
      process identification (`PID') plus the thread identifier for
      multi-threaded processes (`2207.3').

   log:PROC.PRIV A list of any security ID's/groups/labels associated
      with the process generating the log entry (`USR-chris, UID-748,
      GRP-adm, GRP-sys, GRP-users, EUID-root, EGID-kmem, DAC_READ,
      SYSTEM_HIGH')
      NOTE: Need to specify standard nonclemature for Unix, NT, and
      IEEE 1003.1e/2c priveleges. Also, do we really want to do it this
      way, or would it be better done as different attribute types, or
      even nested elements or something?

   log:PROC.MAIL An e-mail address associated with the

Calabrese                Expires July 16, 2001                  [Page 4]

Internet-Draft         XML for Secure System Logs           January 2001

      usr/login/account the process is running as.

   log:PROC.TTY The TTY or other description of the user's physical
      connection to the host generating the event.

   log:EVENT.TYPE Gives a further taxonomy of the type of event that
      occurred.  Allowed values given under 'log:Event_Type_Enumeration
      (Appendix B)'.

   XML:LANG The language used for any textual messages in the standard
      XML `LangCode' format[16].

   log:DUR Duration of the event being logged in 'Seconds.Decimel
      (Appendix B)' format.

   log:SRC.ADDR (log:DST.ADDR) The network source (destination) address
      of any network traffic represented by this event in
      'log:Address_Format (Appendix B)'.

   log:SRC.PROT (log:DST.PROT) The network protocols/ports used by the
      source (destination) of network traffic in 'log:Protocol_Format
      (Appendix B)' (`IP/TCP/25/ESMTP', `IP/ICMP/Source_Quench').

   log:SRC.FQDN (log:DST.FQDN) The fully qualified domain name for the
      traffic source (destination).

   log:SRC.NAME (log:DST.NAME) Some other unique identifier for the
      traffic source (destination).

   log:SRC.USR (log:DST.USR) A user/login/account associated with the
      traffic source (destination).

   log:SRC.MAIL (log.DST.MAIL) An e-mail address associated with the
      traffic source (destination).

   log:REL.IN.ADDR, log:REL.IN.PROT, log:REL.IN.FQDN, log:REL.IN.NAME,
   log:REL.IN.USR, log:REL.IN.MAIL, log:REL.OUT.ADDR, log:REL.OUT.PROT,
   log:REL.OUT.FQDN, log:REL.OUT.NAME, log:REL.OUT.USR,
   log:REL.OUT.MAIL Similar to the `log:SRC.' and `log:DST.'
      attributes, but representing inbound and outbound traffic through
      a relay or proxy.

   log:VOL, VOL.SENT, VOL.RCVD Total data volume in octets, volume
      sent, and volume received.

   log:CNT, log:CNT.SENT, log:CNT.RCVD Total data volume in records,
      records sent, and records received.

   log:PROG.FILE, log:PROG.LINE The name of the program source file and

Calabrese                Expires July 16, 2001                  [Page 5]

Internet-Draft         XML for Secure System Logs           January 2001

      line number within the source file.  Typically used for debugging
      and assert messages.

   log:DOC Name of an accessed document/file, such as an FTP file, a
      newsgroup, or a URL.

   log:CMD Issued command that generated the event. For example:

   <log:EVNT ... log:CMD="/bin/rm -rf /">

   log:MSG Free form message text.

Calabrese                Expires July 16, 2001                  [Page 6]

Internet-Draft         XML for Secure System Logs           January 2001

3. Examples

3.1 Nested `log:EVNT' Entries

   At first blush, it's not obvious why we need a MSG attribute when we
   could use something like:

   <log:EVNT ...>this is the text</log:EVNT>

    The reason is to allow `log:EVNT' elements to nest. One possible
   interpretation of nested log entries is to be able to represent
   complex relationships in the data. Instead, here we use nesting to
   collapse redundant data. For example, the following are considered
   equivalent:

   <log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
    log:PROC.ID=1234 log:MSG="unexpected file"
    log:DOC="/a/b/c"/>
   <log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
    log:PROC.ID=1234 log:MSG="unexpected file"
    log:DOC="/a/b/d"/>
   <log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
    log:PROC.ID=1234 log:MSG="unexpected file"
    log:DOC="/a/b/e"/>

   <log:EVNT log:SEV=80 log:PROC.NAME="Audit/Tripwire"
   log:PROC.ID=1234 log:MSG="unexpected file">
       <log:EVNT log:DOC="/a/b/c"/>
       <log:EVNT log:DOC="/a/b/d"/>
       <log:EVNT log:DOC="/a/b/e"/>
       </log:EVNT>

    As a result, only inner-most `log:EVNT' elements are log entries.
   Outer `log:EVNT' elements set attributes common to the contained
   entries.

Calabrese                Expires July 16, 2001                  [Page 7]

Internet-Draft         XML for Secure System Logs           January 2001

4. Deviation from Pure XML

   Although XML is a good fit for the structure needed to describe
   system logs, it is not a perfect fit.  In particular:

   1.  In the interest of compactness, logs will be considered complete
       even if they do not contain the standard XML prolog containing
       the XML version, element declarations, etc.

   2.  Also in the interest of compactness, log message streams not
       beginning with `<' will assume to be bracketed by `<log:' and
       `>'. This way, the existing syslog behavior of sending a single
       log entry inside a single UDP packet may be preserved.

   3.  Some might argue that having the free-form messages as `log:MSG'
       attribute values is somewhat messy from an XML standpoint and
       that "proper" XML would be to unravel the nesting and put the
       message text in as the "payload" of the `log:EVNT' elements.

   Implementations may contain a tool to generate 100% XML compliant
   "documents" from log files so that the logs may be processed by
   standard XML tools.

Calabrese                Expires July 16, 2001                  [Page 8]

Internet-Draft         XML for Secure System Logs           January 2001

5. Implementation Considerations

5.1 Event Filtering

   NOTE: Need info about filtering...

5.2 Event Viewing/Reporting

   NOTE: Need info viewing/reporting...

5.3 Logging API's

   NOTE: Need info on API's, especially making sure that the TCB
   generates whatever information it can. Refer to sec section.

5.4 Backward Compatibility

5.4.1 Syslog

   NOTE: Need info on this..., especially issue of including
   level/facility info in both XML and native syslog levels.

5.4.2 NT Event Logger

   NOTE: Need info on this...

5.5 Network Communications

   NOTE: Need info on this..., including references to Syslog WG work.

Calabrese                Expires July 16, 2001                  [Page 9]

Internet-Draft         XML for Secure System Logs           January 2001

6. Security Considerations

6.1 Correctness and Completeness of Identifying Information

   NOTE: TCB should/must generate log:HOST log:DATE log:SEV
   log:PROC.NAME log:PROC.ID log:PROC.PRIV

6.2 Confidentiality, Integrity, and Availability of Log Messages

   The confidentiality, integrity, and availability of log messages or
   logging mechanisms is beyond the scope of this memo.  However, these
   issues are addressed in the following places.
   NOTE: need references here...

Calabrese                Expires July 16, 2001                 [Page 10]

Internet-Draft         XML for Secure System Logs           January 2001

References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", RFC 2119, BCP 14, March 1997.

   [2]   International Standards Organization, "Data elements and
         interchange formats - Information interchange - Representation
         of dates and times", International Standard ISO 8601:1988,
         available from http://www.iso.ch/markete/8601.pdf, 1988.

   [3]   University of California Computer Systems Research Group,
         "Unix Programmer's Manual, 4.3 Berkeley Software Distribution,
         Virtual VAX-11 Version", April 1986.

   [4]   U.S. Department of Defense, Assistant Secretary of Defense for
         Command, Control, Communications, and Intelligence,
         "Department of Defense Trusted Computer System Evaluation
         Criteria", DoD 5200.28-STD, available from
         http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
         , December 1985.

   [5]   International Standards Organization, "Common Criteria for
         Information Technology Security Evaluation Version 2.1",
         International Standard ISO/IEC 15408:1999, available from
         http://www.radium.ncsc.mil/tpep/library/ccitse/ccitse.html,
         August 1999.

   [6]   U.S. National Security Agency, Information Systems Security
         Organization, "Labeled Security Protection Profile", available
         from
         http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html
         , October 1999.

   [7]   U.S. National Security Agency, Information Systems Security
         Organization, "Controlled Access Protection Profile",
         available from
         http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html
         , October 1999.

   [8]   Lonvick, C.M., "syslog Protocol", draft-ietf-syslog-syslog-03
         (work in progress), January 2001.

   [9]   Schneier, B. and J. Kelsey, "Cryptographic Support for Secure
         Logs on Untrusted Machines", The Seventh USENIX Security
         Symposium Proceedings, USENIX Press pp. 53-62, available from
         http://www.counterpane.com/secure-logs.html, January 1998.

   [10]  Schneier, B. and J. Kelsey, "Minimizing Bandwidth for Remote
         Access to Cryptographically Protected Audit Logs", Second

Calabrese                Expires July 16, 2001                 [Page 11]

Internet-Draft         XML for Secure System Logs           January 2001

         International Workshop on the Recent Advances inIntrusion
         Detection (RAID '99), available from
         http://www.counterpane.com/auditlog2.html, September 1999.

   [11]  Abela, J. and T. Debeaupuis, "Universal Format for Logger
         Messages", May 1999.

   [12]  Jombart, N., "Private correspondence", May 2000.

   [13]  New, D. and M.T. Rose, "Reliable Delivery for Syslog",
         draft-ietf-syslog-reliable-02 (work in progress), November
         2000.

   [14]  Kelsey, J., "Syslog-Auth Protocol", draft-ietf-syslog-auth-00
         (work in progress), December 2000.

   [15]  Kelsey, J., "Syslog-Sign Protocol", draft-ietf-syslog-sign-00
         (work in progress), December 2000.

   [16]  World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0.", available from http://www.w3.org/TR/REC-xml, February
         1998.

Author's Address

   Christopher J. Calabrese
   The SANS Institute
   26 Wellesley Road
   Upper Montclair, NJ  07043
   US

   Phone: +1 973 233 1464
   EMail: [email-masked]

Calabrese                Expires July 16, 2001                 [Page 12]

Internet-Draft         XML for Secure System Logs           January 2001

Appendix A. XML DTD for the `log:EVNT' Element

   <!-- Note that attributes are marked REQUIRED
     -- here if it is implied by draft-calabrese-requir-loggprot-01.
     -- This assumes this information is not being provided by
     -- another source.
     -->
   <!ELEMENT log:ENTRY (log:ENTRY)*>
   <!ATTLIST log:ENTRY
       log:HOST CDATA #REQUIRED
       log:DATE ISO.8601:1998_Date_Format #REQUIRED
       log:SEV log:Severity_Type #REQUIRED
       log:PROC.NAME CDATA #REQUIRED
       log:PROC.ID CDATA #REQUIRED
       log:PROC.PRIV CDATA #REQUIRED
       log:PROC.MAIL CDATA #IMPLIED
       log:PROC.TTY CDATA #IMPLIED
       log:EVENT.TYPE log:Event_Type_Enumeration #IMPLIED
       log:XML:LANG LangCode "EN"
       log:DUR Seconds.Decimal #IMPLIED
       log:SRC.ADDR log:Address_Format #IMPLIED
       log:SRC.PROT log:Protocol_Format #IMPLIED
       log:SRC.FQDN CDATA #IMPLIED
       log:SRC.NAME CDATA #IMPLIED
       log:SRC.USR CDATA #IMPLIED
       log:SRC.MAIL CDATA #IMPLIED
       log:DST.ADDR log:Address_Format #IMPLIED
       log:DST.PROT log:Protocol_Format #IMPLIED
       log:DST.FQDN CDATA #IMPLIED
       log:DST.NAME CDATA #IMPLIED
       log:DST.USR CDATA #IMPLIED
       log:DST.MAIL CDATA #IMPLIED
       log:REL.IN.ADDR log:Address_Format #IMPLIED
       log:REL.IN.PROT log:Protocol_Format #IMPLIED
       log:REL.IN.FQDN CDATA #IMPLIED
       log:REL.IN.NAME CDATA #IMPLIED
       log:REL.IN.USR CDATA #IMPLIED
       log:REL.IN.MAIL CDATA #IMPLIED
       log:REL.OUT.ADDR log:Address_Format #IMPLIED
       log:REL.OUT.PROT log:Protocol_Format #IMPLIED
       log:REL.OUT.FQDN CDATA #IMPLIED
       log:REL.OUT.NAME CDATA #IMPLIED
       log:REL.OUT.USR CDATA #IMPLIED
       log:REL.OUT.MAIL CDATA #IMPLIED
       log:VOL Integer #IMPLIED
       log:VOL.SENT Integer #IMPLIED
       log:VOL.RCVD Integer #IMPLIED
       log:CNT Integer #IMPLIED

Calabrese                Expires July 16, 2001                 [Page 13]

Internet-Draft         XML for Secure System Logs           January 2001

       log:CNT.SENT Integer #IMPLIED
       log:CNT.RCVD Integer #IMPLIED
       log:PROG.FILE CDATA #IMPLIED
       log:PROG.LINE Integer #IMPLIED
       log:DOC CDATA #IMPLIED
       log:CMD CDATA #IMPLIED
       log:MSG CDATA #IMPLIED
       >

Calabrese                Expires July 16, 2001                 [Page 14]

Internet-Draft         XML for Secure System Logs           January 2001

Appendix B. XML DTD for Data Types Used in the `log:EVNT' Element

   <!NOTATION log:Severity_Type ('0'|'1'|...|'99')>
   <!NOTATION ISO.8601:1998_Date_Format
       (YYYY '-' MM '-' DD 'T' hh ':'
        mm [':' ss ['.' f+]]('+' | '-') zzzz)>
       <!-- NOTE: Need reference and further
        explanation of date format -->
   <!NOTATION Seconds.Decimal
       (ss ['.' f+])
   <!NOTATION log:Event_Type_Enumeration
       ('AUTH.FAIL'|'AUTH.SUCCESS'|'PROG.FAIL'|'PROG.START'|...)>
       <!-- NOTE: Need more complete enumeration. -->
   <!NOTATION log:Address_Format
       (IPv4_Address|IPv6_Address|IPX_Address|...)>
       <!-- NOTE: Do we need more a complete
        enumeration? of address types? -->
   <!NOTATION IPv4_Address CDATA >
       <!-- NOTE: Need proper definition
        and reference for IPv4 addresses -->
   <!NOTATION IPv6_Address CDATA>
       <!-- NOTE: Need proper definition
        and reference for IPv6 addresses -->
   <!NOTATION IPX_Address CDATA>
       <!-- NOTE: Need proper definition
        and reference for IPX addresses -->
   <!NOTATION log:Protocol_Format
       ( ('IPv4/' ('UDP'|'TCP') '/' IPv4_Port_Number ['/' CDATA])
       | ('IPv4/ICMP/' IPv4_ICMP_Message_Type)
       | ( ('IPv6/' ('UDP'|'TCP') '/' IPv6_Port_Number ['/' CDATA])
       | ('IPv6/ICMP/' IP64_ICMP_Message_Type)
       | ('IPX' ['/SPX/'] IPX_Port_Number ['/' CDATA])
       )
       <!-- NOTE: Need further definitions of
        referenced types... -->

Calabrese                Expires July 16, 2001                 [Page 15]

Internet-Draft         XML for Secure System Logs           January 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.

Calabrese                Expires July 16, 2001                 [Page 16]

------------------------------

Date: Sat, 21 Dec 2002 01:14:43 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

How about adding SL4NT from www.netal.com, I believe it can do TCP too.

> they not necessarily interoperate, even end devices support
> it sometimes:
>
> - kiwisyslog
> - msyslog
> - nsyslogd
> - syslog-ng
> - Cisco PIX
>
> And I'm sure I've forgotten some. These should interoperate,

I'd like to add

- - MonitorWare Agent
- - EventReporter
- - WinSyslog

to the list ;) Not only for marketing purposes, but to get it complete.
Any other ones out there? I am asking because if we already do support
syslog over TCP, we might at least in this group agree on a way to do
it. If it then prooves to be doing nicely, we could try to get some
attention for such a protocol (you know, running code... ;))

Please note that I have been relatively silent on the list as I am
exploring mtr's "simple beep, just say no approach". I am not sure yet,
but maybe the negotation is not as bad as all. We may write a small lib
to cover this (probably as open source...). Needs to be seen...

Rainer

------------------------------

Date: Fri, 20 Dec 2002 09:47:15 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

this message is longer than i'd like, for which i apologize in advance.

> The possibility of requesting parts of the syslog stream in a separate
> channel might be useful in the future, but the control messages to achieve
> this needs to be defined. The problem with RFC3195 is that it provides
> solutions for the future, but does not solve our current problems. Plain TCP
> transport is supported in more-and-more implementations but they not
> necessarily interoperate, even end devices support it sometimes:
>
> - kiwisyslog
> - msyslog
> - nsyslogd
> - syslog-ng
> - Cisco PIX
>
> And I'm sure I've forgotten some. These should interoperate, most of them do
> I guess, but an RFC would help in this area right _NOW_. The BEEP solution
> might be the future, but first it needs implementations, and further updates
> that makes the overhead explainable.

one of the values behind standardization, and in particular,
standardization of open protocols is that you get a concensus behind
something which is going to support a wider range of environments than
if N people go off and independently do their own thing for their own
little part of the internet.

if the variations between the different requirements are relatively
small, then you tend to get results that are reasonably optimal for most
environments.

the larger the range of variations, the harder it is to do this. at some
point, the variation is so large that a single engineering solution is
untenable. in that case, you either cut back on the requirements or do
multiple efforts targetted towards clusters of requirements that are
largely self-consistent.

in the case of the syslog wg, while there are some folks who say "all i
need is reliability and tcp does that", there are also a lot of other
folks who have requirements that are more nuanced. some people care
about privacy, some don't. some people care about authenticity (but not
privacy), and some don't. some people care about particular security
protocols or enterprise infrastructures, and some don't.

more interestingly, there are some folks who realize that their
requirements today are going to be different 3 months, 6 months, and a
year from now, and they'd rather not have to deploy a new syslog
protocol to meet those requirements. rather, they'd prefer to edit some
config files to enable/disable various features in the existing protocol.

the good news is that it turns out that you can unify the entire class
of requirements for folks who all want different variants of "reliable
syslog" by using a negotiation model.  and that's where beep comes in.

i absolutely guarantee you that i could easily specify 6 different
"reliable syslog" protocols, each targetted towards a particular slice of
requirements, and each no less than 8% more efficient than the general
beep-based solution, and all of them incompatible with each other.

sorry, i'll take the 8% efficiency hit and avoid the incompatibility.
if someone disagrees with this, then i congratulate them on landing a
job where they have to worry about less than 10 computers...

regardless, there is a second class of requirements for syslog that
weren't centered around reliable delivery, but rather around (partial)
ordered delivery in very short time frames. this requirement is
fundamentally different than the reliability requirement. further, it
remains an open research problem as to how to design a single protocol
which satisfies both of these requirements.

thus, the working group developed a second protocol, syslog-signed, to
meet that set of requirements.

from my perspective, syslog-reliable and syslog-signed are complimentary
in the sense that they solve very different problems within the context
of "doing syslog". operators are free to examine their own requirements
and then choose to deploy one or both to meet their needs.

/mtr

------------------------------

Date: Fri, 20 Dec 2002 19:24:57 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Ccing to syslog-sec.

On Fri, Dec 20, 2002 at 09:40:57AM -0800, Darren New wrote:
> Balazs Scheidler wrote:
>> I know I can do that, but there's no need. I wanted to explain that
>> currently deployed syslog implementations don't do negotiation.
>
>Yes, I know that.
>
>The point is that there *is* a need, yes. What you meant to say is *you*
>don't have that need. Which is fine, which is why it can be hardcoded in
>*your* implementation. Others, making more generic implementations, need
>to know whether the other side wants encryption, whether the other side
>is using better timestamps, whether the other side is a creator of
>messages or a relay or both, etc.
>
>> Look, there are implementations of syslog-over-TCP. There was a couple
>> listed in another mail.
>
>So use them.

I do. I want to get router logs on TCP, PIX does that fine (probably because
of its CC audit), but other routers don't. Probably because there's no
document on the protocol.

>> You tell us that everything can be done in BEEP as
>> well, that's true. But what are the _benefits_ of adding BEEP over the
>> already implemented TCP transport?
>
>The ability to negotiate TLS, SASL, raw vs cooked, and the ability to
>tunnel through firewalls to get your messages out. Did you attend any of
>the meetings where the requirements were discussed? Did you read the
>mailing list archives?

Yes, I followed the mailing list, I even contributed to the RFC3164 effort.
And no, I didn't attend any meetings because the meetings were held on a
different continent.

>> The problem is that those TCP implementations does not necessarily
>> interoperate,
>
>Right. In part because they lack any negotiation.

No, because there's no RFC on syslog over TCP, and everybody did it on its
own.

> > I'd argue that BEEP is viable if interoperation is the only benefit.
>
> It's not the only benefit. How would you, for example, implement a
> syslog-over-TCP that could log into a firewall, authenticate itself,
> then have the firewall pass that connection through to the collector on
> the other side of the firewall, then have the device and collector
> negotiate TLS so the firewall (if broken into) cannot see the messages
> going thru it, in the current implementations of
> syslog-over-TCP-without-negotiation?

So BEEP can use TLS on one of its subchannels?  Last I heard it was only
possible to wrap the whole BEEP stream into TLS, thus the whole argument is
void as you'd need to use two BEEP streams (one ended on the
firewall, the other on the collector), the same can be done using two
independent TCP streams.

Firewall authentication (e.g. authentication to cross the firewall) can be
implemented in two different ways:
* inband or inline auth where the authentication is hacked into the protocol
  (as implemented by fwtk for instance where you have to auth twice in FTP:
  first to the firewall, then to the server)
* outband auth: when the authentication is based on a completely separate
  channel

The latter is something that you have in SASL defined as "external" method.
This can mean many things: IPSec VPN, SSL wrapping, special outband protocol
(this is also called session authentication in CheckPoint, or satyr
authentication in Zorp)

If you want automatic authentication on the firewall you either wrap the
stream twice (first wrap is decrypted on the firewall, the second at the
collector)

> > > > For this it uses its own windowing, has its own channel control messages
> > > > etc. This does not mean too much to syslog right now either. We can use
> > > > several TCP streams if we need to.
> > >
> > > The overhead of handling these messages when there's only one window is
> > > trivial.
> >
> > It is trivial, but is overhead (in both run-time and development time) which
> > gives us nothing.
>
> Except that it doesn't give you nothing. It gives you the ability to do
> more in the future. I'm sure when folks did syslog-over-UDP, they said
> things like "TCP gives us overead we don't need."

... and we are left in the cold while BEEP based products are developed.
I'm not arguing that BEEP is cool and is not necessary. I'd like to extend
RFC3164 (or syslog-sign) with TCP transport.

I might propose some text but I'd first like to be sure that it would be
accepted.

Chris, would proposed updates to syslog/sign be accepted?

> > Certainly there are implementations of syslog-over-TCP.
>
> Right. But they don't do what you need. If they do what you need, great,
> use em. If they're not interoperable enough for you, propose a new RFC.
> Write it up and send it to the right WG. You know how the process works.
> :-)

Is this the right WG?

> > I have implemented a syslog implementation, and also deployed it in
> > demanding environments. Those implementations work *right* now.
>
> So explain again what the problem is?

That there are some other plain TCP implementations, and as there's no RFC
on this matter I'd doubt they interoperate. If they do without an RFC, it
would still be wise to document it, just like it was the first
accomplishment of this WG to release RFC3164.

> > We *have* implementations, or implementations that are trivial to make
> > RFC conformant.
>
> Um, trivially conformant to what RFC? Did I do all this syslog-over-TCP
> RFC work for nothing? Is there another syslog-over-TCP RFC already
> approved?

I don't know about any. I meant that if there was an RFC which defined plain
TCP transport (messages going one way, '\n' terminated lines which should be
in the format that was described in rfc3164), _then_ many of the current
implementations could be trivially modified to match that RFC.

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Fri, 20 Dec 2002 12:45:47 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Hi Bazsi,

Pardon me for not putting comments in-line but I'd like to summarize and
see where this discussion is going.  As I see it, various people have
said:

- - 3195 is too heavy
- - a minimal implementation (just say 'no') of 3195 may be light enough
- - there are many tcp-based implementations to transport syslog but none
  of them interoperate
- - a simple tcp-based implementation would need all of the aspects of
  BEEP to optionally call the security features that are desired
  (reliable transport, confidentiality, device authentication)
- - BEEP channels can be a good thing

(Did I miss any other thoughts?)

I'm still not seeing what features/functions are missing from 3195, or
what features/functions a simple tcp-based syslog would fill.  I don't see
that documenting any/all of the old methods would serve a purpose either.

I'll keep this discussion open to see if we can get a clear reason for a
simple reliable tcp protocol.

Thanks,
Chris

On Fri, 20 Dec 2002, Balazs Scheidler wrote:

> Ccing to syslog-sec.
>
> On Fri, Dec 20, 2002 at 09:40:57AM -0800, Darren New wrote:
> > Balazs Scheidler wrote:
> >> I know I can do that, but there's no need. I wanted to explain that
> >> currently deployed syslog implementations don't do negotiation.
> >
> >Yes, I know that.
> >
> >The point is that there *is* a need, yes. What you meant to say is *you*
> >don't have that need. Which is fine, which is why it can be hardcoded in
> >*your* implementation. Others, making more generic implementations, need
> >to know whether the other side wants encryption, whether the other side
> >is using better timestamps, whether the other side is a creator of
> >messages or a relay or both, etc.
> >
> >> Look, there are implementations of syslog-over-TCP. There was a couple
> >> listed in another mail.
> >
> >So use them.
>
> I do. I want to get router logs on TCP, PIX does that fine (probably because
> of its CC audit), but other routers don't. Probably because there's no
> document on the protocol.
>
> >> You tell us that everything can be done in BEEP as
> >> well, that's true. But what are the _benefits_ of adding BEEP over the
> >> already implemented TCP transport?
> >
> >The ability to negotiate TLS, SASL, raw vs cooked, and the ability to
> >tunnel through firewalls to get your messages out. Did you attend any of
> >the meetings where the requirements were discussed? Did you read the
> >mailing list archives?
>
> Yes, I followed the mailing list, I even contributed to the RFC3164 effort.
> And no, I didn't attend any meetings because the meetings were held on a
> different continent.
>
> >> The problem is that those TCP implementations does not necessarily
> >> interoperate,
> >
> >Right. In part because they lack any negotiation.
>
> No, because there's no RFC on syslog over TCP, and everybody did it on its
> own.
>
> > > I'd argue that BEEP is viable if interoperation is the only benefit.
> >
> > It's not the only benefit. How would you, for example, implement a
> > syslog-over-TCP that could log into a firewall, authenticate itself,
> > then have the firewall pass that connection through to the collector on
> > the other side of the firewall, then have the device and collector
> > negotiate TLS so the firewall (if broken into) cannot see the messages
> > going thru it, in the current implementations of
> > syslog-over-TCP-without-negotiation?
>
> So BEEP can use TLS on one of its subchannels?  Last I heard it was only
> possible to wrap the whole BEEP stream into TLS, thus the whole argument is
> void as you'd need to use two BEEP streams (one ended on the
> firewall, the other on the collector), the same can be done using two
> independent TCP streams.
>
> Firewall authentication (e.g. authentication to cross the firewall) can be
> implemented in two different ways:
> * inband or inline auth where the authentication is hacked into the protocol
>   (as implemented by fwtk for instance where you have to auth twice in FTP:
>   first to the firewall, then to the server)
> * outband auth: when the authentication is based on a completely separate
>   channel
>
> The latter is something that you have in SASL defined as "external" method.
> This can mean many things: IPSec VPN, SSL wrapping, special outband protocol
> (this is also called session authentication in CheckPoint, or satyr
> authentication in Zorp)
>
> If you want automatic authentication on the firewall you either wrap the
> stream twice (first wrap is decrypted on the firewall, the second at the
> collector)
>
> > > > > For this it uses its own windowing, has its own channel control messages
> > > > > etc. This does not mean too much to syslog right now either. We can use
> > > > > several TCP streams if we need to.
> > > >
> > > > The overhead of handling these messages when there's only one window is
> > > > trivial.
> > >
> > > It is trivial, but is overhead (in both run-time and development time) which
> > > gives us nothing.
> >
> > Except that it doesn't give you nothing. It gives you the ability to do
> > more in the future. I'm sure when folks did syslog-over-UDP, they said
> > things like "TCP gives us overead we don't need."
>
> ... and we are left in the cold while BEEP based products are developed.
> I'm not arguing that BEEP is cool and is not necessary. I'd like to extend
> RFC3164 (or syslog-sign) with TCP transport.
>
> I might propose some text but I'd first like to be sure that it would be
> accepted.
>
> Chris, would proposed updates to syslog/sign be accepted?
>
> > > Certainly there are implementations of syslog-over-TCP.
> >
> > Right. But they don't do what you need. If they do what you need, great,
> > use em. If they're not interoperable enough for you, propose a new RFC.
> > Write it up and send it to the right WG. You know how the process works.
> > :-)
>
> Is this the right WG?
>
> > > I have implemented a syslog implementation, and also deployed it in
> > > demanding environments. Those implementations work *right* now.
> >
> > So explain again what the problem is?
>
> That there are some other plain TCP implementations, and as there's no RFC
> on this matter I'd doubt they interoperate. If they do without an RFC, it
> would still be wise to document it, just like it was the first
> accomplishment of this WG to release RFC3164.
>
> > > We *have* implementations, or implementations that are trivial to make
> > > RFC conformant.
> >
> > Um, trivially conformant to what RFC? Did I do all this syslog-over-TCP
> > RFC work for nothing? Is there another syslog-over-TCP RFC already
> > approved?
>
> I don't know about any. I meant that if there was an RFC which defined plain
> TCP transport (messages going one way, '\n' terminated lines which should be
> in the format that was described in rfc3164), _then_ many of the current
> implementations could be trivially modified to match that RFC.
>
> --
> Bazsi
> PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
>
>

------------------------------

Date: Fri, 20 Dec 2002 12:28:40 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

> Marshall Rose wrote:
>
> | this message is longer than i'd like, for which i apologize in advance.
> |
> | [...]
> |
> | one of the values behind standardization, and in particular,
> | standardization of open protocols is that you get a concensus behind
> | something [...]
>
> One thing about which there is consensus is the practice of
> finding the location of and using the Shift key when typing.
> This is particularly true when the text is lengthy.
>
> It's a sign of respect for one's readers that one makes an
> effort to make one's writing legible rather than forcing people
> to make an extra effort to read it.  Please learn to capitalise
> in the accepted manner at the start of sentences.

perhaps you have too much time on your hands. if so, kindly provide a URL or two
which documents this concensus. otherwise, why not limit your attention to
techincal issues regarding syslog...

/mtr

------------------------------

Date: Sat, 21 Dec 2002 06:24:39 +1000
From: Greg Black <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Marshall Rose wrote:

| this message is longer than i'd like, for which i apologize in advance.
|
| [...]
|
| one of the values behind standardization, and in particular,
| standardization of open protocols is that you get a concensus behind
| something [...]

One thing about which there is consensus is the practice of
finding the location of and using the Shift key when typing.
This is particularly true when the text is lengthy.

It's a sign of respect for one's readers that one makes an
effort to make one's writing legible rather than forcing people
to make an extra effort to read it.  Please learn to capitalise
in the accepted manner at the start of sentences.

Greg

------------------------------

Date: Sat, 21 Dec 2002 06:42:21 +1000
From: Greg Black <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Marshall Rose wrote:

| > Marshall Rose wrote:
| >
| > | this message is longer than i'd like, for which i apologize in advance.
| > |
| > | [...]
| > |
| > | one of the values behind standardization, and in particular,
| > | standardization of open protocols is that you get a concensus behind
| > | something [...]
| >
| > One thing about which there is consensus is the practice of
| > finding the location of and using the Shift key when typing.
| > This is particularly true when the text is lengthy.
| >
| > It's a sign of respect for one's readers that one makes an
| > effort to make one's writing legible rather than forcing people
| > to make an extra effort to read it.  Please learn to capitalise
| > in the accepted manner at the start of sentences.
|
| perhaps you have too much time on your hands. if so, kindly provide a URL or two
| which documents this concensus. otherwise, why not limit your attention to
| techincal issues regarding syslog...

I'm sure you're as capable as I am of researching this, but here
is one reference.  If you want more, you're on your own.

  http://www.learnenglish.org.uk/grammar/archive/capital_letters.html

As for having time on my hands, I don't.  And since it takes
longer for me (and for most people) to read long pieces of text
without capitals, I'd like to see the quality of the technical
material enhanced by some adherence to this basic rule of
written English.

Greg

------------------------------

Date: Fri, 20 Dec 2002 23:15:54 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Hi Darren and list,

First of all I would like to excuse me for sending part of our private mails
to the mailing list. I shouldn't have done it, sorry. I've deliberately
started a new mail this time.

Surprise: I'm now mostly convinced about BEEP and its use in application
protocols.

I've reread some of the RFCs and also read a couple of drafts. BEEP over
SCTP is the future, BEEP over TCP is just a nuisance while SCTP is being
implemented (SCTP supports multiple streams per connection)

This means that I'll do my best to implement RFC3195 in our syslog
implementation (syslog-ng).

I have a single question left however (to address the legacy problems), is
the working group interested in an update of rfc3164 or syslog/sign with the
possibility of TCP transport, and the RFC3339 timestamp?

My reasoning is:
* solve possible TCP interop problems with current implementations
* to provide a way to send reliable messages for small edge devices which
  probably will never implement SCTP nor BEEP (DSL routers for instance)

This means that implementors would have three options:
* do nothing, log messages are sent via UDP
* do the trivial update to TCP
* do the full blown syslog/reliable implementation

The second option is still much easier to achieve for most vendors, and we
would still have some reliability. Current syslog-over-TCP implementations
will have something to conform to while RFC3195 implementation is done.

What do you think?

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Fri, 20 Dec 2002 14:44:41 -0800
From: Darren New <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Balazs Scheidler wrote:
> My reasoning is:
> * solve possible TCP interop problems with current implementations
> * to provide a way to send reliable messages for small edge devices which
>   probably will never implement SCTP nor BEEP (DSL routers for instance)

Well, during the early days, I tried to push for a better timestamp and
it was considered a modification to the payload. Of course, the cooked
mode does a better job of carrying the timestamp, but that's admittedly
a lot more overhead. However, I'm not the authoratative answer on that.
:-)

I don't think you'll get something standardized from scratch and
deployed faster than  you can get a BEEP implementation deployed. Plus,
for 99% of the uses of BEEP, you're only using one channel at a time
anyway, so whether it's TCP or SCTP is kind of irrelevant.

As for DSL routers, the ones I've seen have a web server for
configuration and status and such, with plenty of oomph for running a
simple (not very configurable) version of syslog-reliable, BEEP and all.
Once the initial connection is established, you're really doing almost
nothing to actually send the messages, at the same level of effort as
tracking a TCP window.

- --
Darren New
San Diego, CA, USA (PST)
"I'm allergic to antihistamines."
    "Oh? What do you break out in?"

------------------------------

Date: Fri, 20 Dec 2002 17:59:29 -0800 (PST)
From: Lonvick <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

- ---------- Forwarded message ----------
Date: Fri, 20 Dec 2002 17:54:51 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
To: Darren New <[email-masked]>
Cc: [email-masked]
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Hi Darren,

On Fri, 20 Dec 2002, Darren New wrote:

> Balazs Scheidler wrote:
> > My reasoning is:
> > * solve possible TCP interop problems with current implementations
> > * to provide a way to send reliable messages for small edge devices which
> >   probably will never implement SCTP nor BEEP (DSL routers for instance)
>
> Well, during the early days, I tried to push for a better timestamp and
> it was considered a modification to the payload. Of course, the cooked
> mode does a better job of carrying the timestamp, but that's admittedly
> a lot more overhead. However, I'm not the authoratative answer on that.
> :-)

Yup.  I appreciate your patience.  The idea was *supposed* to be that
syslog-sign would get the actual syslog format (the "new & improved
version") with an appropriate TIMESTAMP rather than 3164.  ..but, we work
with what we have and we'll continue to work on syslog-sign.  Hopefully
this means that a rev of 3195 will allow for this timestamp.

Switching gears a bit, do you have any thoughts on the proposal from Frank
O'Dwyer to include something along the lines of "MAY accept other
profiles"?

Thanks,
Chris

------------------------------

Date: Sat, 21 Dec 2002 14:55:04 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

On Fri, Dec 20, 2002 at 12:45:47PM -0800, Christopher Lonvick wrote:
> Hi Bazsi,
>
> Pardon me for not putting comments in-line but I'd like to summarize and
> see where this discussion is going.  As I see it, various people have
> said:
>
> - 3195 is too heavy
> - a minimal implementation (just say 'no') of 3195 may be light enough
> - there are many tcp-based implementations to transport syslog but none
>   of them interoperate
> - a simple tcp-based implementation would need all of the aspects of
>   BEEP to optionally call the security features that are desired
>   (reliable transport, confidentiality, device authentication)
> - BEEP channels can be a good thing
>
> (Did I miss any other thoughts?)

the question of rfc3339 timestamps.

> I'm still not seeing what features/functions are missing from 3195, or
> what features/functions a simple tcp-based syslog would fill.  I don't see
> that documenting any/all of the old methods would serve a purpose either.
>
> I'll keep this discussion open to see if we can get a clear reason for a
> simple reliable tcp protocol.

the reason is similar to why RFC3164 was released: document current
practices. The protocol described in RFC3164 has been extended in nearly all
syslog implementations developed recently.

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Sun, 22 Dec 2002 08:07:55 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Hi Bazsi,

On Sat, 21 Dec 2002, Balazs Scheidler wrote:

> On Fri, Dec 20, 2002 at 12:45:47PM -0800, Christopher Lonvick wrote:
> > Hi Bazsi,
> >
> > Pardon me for not putting comments in-line but I'd like to summarize and
> > see where this discussion is going.  As I see it, various people have
> > said:
> >
> > - 3195 is too heavy
> > - a minimal implementation (just say 'no') of 3195 may be light enough
> > - there are many tcp-based implementations to transport syslog but none
> >   of them interoperate
> > - a simple tcp-based implementation would need all of the aspects of
> >   BEEP to optionally call the security features that are desired
> >   (reliable transport, confidentiality, device authentication)
> > - BEEP channels can be a good thing
> >
> > (Did I miss any other thoughts?)
>
> the question of rfc3339 timestamps.

I'd like to discuss that separately from this discussion of a tcp-based
transport.  The last I saw, you had raised a question about sending the
time referenced to GMT rather than local timezone.  Was that resolved?  If
it is the consensus of the WG to use that format (along with accepting
the traditional 3164 timestamp format), then it may be placed into
syslog-sign.

>
> > I'm still not seeing what features/functions are missing from 3195, or
> > what features/functions a simple tcp-based syslog would fill.  I don't see
> > that documenting any/all of the old methods would serve a purpose either.
> >
> > I'll keep this discussion open to see if we can get a clear reason for a
> > simple reliable tcp protocol.
>
> the reason is similar to why RFC3164 was released: document current
> practices. The protocol described in RFC3164 has been extended in nearly all
> syslog implementations developed recently.

Would that be to document all of the ways that the fields were
extended/expanded/morphed, or to describe the various tcp-based
implementations, or both?

Thanks,
Chris

------------------------------

Date: Sun, 22 Dec 2002 19:18:31 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

On Sun, Dec 22, 2002 at 08:07:55AM -0800, Christopher Lonvick wrote:
> > On Fri, Dec 20, 2002 at 12:45:47PM -0800, Christopher Lonvick wrote:
> > the question of rfc3339 timestamps.
>
> I'd like to discuss that separately from this discussion of a tcp-based
> transport.  The last I saw, you had raised a question about sending the
> time referenced to GMT rather than local timezone.  Was that resolved?  If
> it is the consensus of the WG to use that format (along with accepting
> the traditional 3164 timestamp format), then it may be placed into
> syslog-sign.

I was advocating the localtime format. IIRC it was Darren Reed who suggested
the timestamp to be sent in GMT. I think at the end we agreed that the
timestamp should be transmitted in localtime, and converted to GMT on the
receiver if needed.

> > > I'm still not seeing what features/functions are missing from 3195, or
> > > what features/functions a simple tcp-based syslog would fill.  I don't see
> > > that documenting any/all of the old methods would serve a purpose either.
> > >
> > > I'll keep this discussion open to see if we can get a clear reason for a
> > > simple reliable tcp protocol.
> >
> > the reason is similar to why RFC3164 was released: document current
> > practices. The protocol described in RFC3164 has been extended in nearly all
> > syslog implementations developed recently.
>
> Would that be to document all of the ways that the fields were
> extended/expanded/morphed, or to describe the various tcp-based
> implementations, or both?

I would not necessarily go for expanded field description, though I can be
convinced here. Syslog-ng for instance defines a new hostname format which
includes hop information (hop means that each relay appends its hostname to
the chain of hostnames). As this extended hop format is more or less
compatible with plain hostnames, this does not cause incompatibility.

The description should focus on the means of encapsulating one single
message into the TCP stream, where the message has the same format as the
UDP packet in RFC3164.

One example might be (please forgive me my non-native English):

TCP based transport

Syslog/tcp uses the Transport Control Protocol (TCP) as its underlying
transport layer mechanism. The TCP port that has been assigned to syslog/tcp
is 11111 (FIXME an IANA assignment is needed). Either the syslog sender
(push mode) or the receiver (pull mode) may initiate a TCP connection to the
other side. In push mode the sender and the initiating side of the TCP
connection is the same. In pull mode the receiving side connects to the
sender first, thus the side initiating the connection and the one sending
messages are not the same.

The role of the sender/receiver and connection related parameters
(source IP/port, destination IP/port) are specified externally, possibly in
the configuration of the implementation.

After the connection is established in either modes, the sender starts
sending messages in a format defined by RFC3164 section 4. An exception is
that unlike UDP, TCP is stream based, thus a way to separate messages is
needed. For this purpose we reserve the NL (ASCII 10) character which MUST
NOT occur in message bodies. Each message is terminated by a NL (ASCII 10)
character or a CRLF sequence (ASCII 13, 10).

As the communication takes place in one way only either the sender or the
receiver MAY shut the connection down in the unneeded direction.

- ------

Of course a length prefixed protocol would also be possible, where embedded
NLs are not a problem, this is the protocol which is used by syslog-ng, and
- - as I know - by Cisco PIXes. I strongly oppose anything more complex, if
one needs negotiation, optional fields or anything like that the BEEP based
syslog protocol is the route to follow.

As for the extensions of different fields, they are usually simply lifting
some of the restrictions in RFC3164 (for example syslog-ng is able to send
FQDN instead of a simple hostname, as I have users who have over 30 hosts
named ns where the fqdn is unique).

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Sun, 22 Dec 2002 11:03:19 -0800
From: Darren New <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

Balazs Scheidler wrote:
> The description should focus on the means of encapsulating one single
> message into the TCP stream, where the message has the same format as the
> UDP packet in RFC3164.

Actually, that was the intention of syslog-reliable raw mode. The
protocol has restrictions in the RFC to cope with the charter of the WG,
but certainly the transport of the messages themselves is independent of
the (for example) format of the datestamps. It also handles the
pull/push dichotomy.

In terms of having better date stamps, tracking of which hosts the
message had been relayed through, etc, syslog-reliable/cooked is
designed to do that flexibly and informatively and still in a way
compatible with syslog-signed. I.e., it adds all that information
without actually changing the body of the message, so signatures don't
get corrupted and so on.

Just FYI. The problem *has* been solved. :-)

- --
Darren New
San Diego, CA, USA (PST)
"I'm allergic to antihistamines."
    "Oh? What do you break out in?"

------------------------------

Date: Sun, 22 Dec 2002 23:07:34 -0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: RE: Any chance for a Simple Reliable Syslog Protocol?

Darren New wrote:
> In terms of having better date stamps, tracking of which hosts the
> message had been relayed through, etc, syslog-reliable/cooked is
> designed to do that flexibly and informatively and still in a way
> compatible with syslog-signed. I.e., it adds all that information
> without actually changing the body of the message, so signatures don't
> get corrupted and so on.

There is an inherent security flaw in that. Information that can be added
without invalidating the signature is also information that is not protected
by the signature, and can be changed with impunity.

For example, if you produce an entry like this:

 <entry hostname="foo.bar.com" etc.... >
    ... syslog-signed message, unchanged, including hostname etc...
 </entry>

You now have 'hostname' expressed twice - but one is involved in the
signature and the other isn't. That means they need not be the same. That's
a potential security problem for any processor that is relying on the one
that isn't signed, i.e the attribute version.

Same goes for any other attribute of 'entry'. For example a rogue relay
meddling with 'facility', 'severity', or 'tag' might be able to redirect a
lot of urgent messages to /dev/null - effectively deleting messages without
tripping the signature mechanism.

On the other hand, if you do this:
  <entry hostname="foo.bar.com" etc ...>
      ..syslog-signed message, changed to remove hostname and other parsed
attributes...
  </entry>

Now nothing is redundantly expressed and you have to reconstruct the
canonical syslog-signed message before you can validate the signature. This
is a bit more work but you can now trust the parsed attributes because they
are properly involved in the signature validation.

Unfortunately in either case it's difficult to add additional attributes
that are parsed from the payload, and trust them - it may be better (in the
case where the device is also using syslog-reliable cooked), to compute the
signature over a canonical XML form of "<entry ...> .... </entry>", i.e.
consider the whole entry to be the raw syslog message.

Cheers,
Frank

------------------------------

Date: Mon, 23 Dec 2002 09:54:00 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog time stamp

Hi all,

Based on the feedback on this list, I have re-worded my suggestion for
the change to syslog-sign:

- ---- begin suggestion ----
  The TIMESTAMP field is either a RFC3164-TIMESTAMP or a
RFC3339-TIMESTAMP. A sender SHOULD format the timestamp as a
RFC3339-TIMESTAMP. A receiver MUST accept both formats.

The RFC3164-TIMESTAMP is the local time and is in the format of "Mmm
   dd hh:mm:ss" (without the quote marks) where:

       Mmm is the English language abbreviation for the month of the
       year with the first character in uppercase and the other two
       characters in lowercase. The following are the only acceptable
       values:

           Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec

       dd is the day of the month. If the day of the month is less than
       10, then it MUST be represented as a space and then the number.
       For example, the 7th day of August would be represented as "Aug
       7", with two spaces between the "g" and the "7".

       hh:mm:ss is the local time. The hour (hh) is represented in a
       24-hour format. Valid entries are between 00 and 23, inclusive.
       The minute (mm) and second (ss) entries are between 00 and 59
       inclusive.

The RFC3339-TIMESTAMP is as specified in [RFC3339]:

The following syntax MUST be used when using a RFC3339-TIMESTAMP. This
is specified using the syntax description notation defined in [ABNF].

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

  Other than in RFC3339

  - the "T" and "Z" characters in this syntax MUST be upper case.
  - usage of the "T" character is mandatory. It MUST NOT be replaced by
    any other character (like a space character).
  - the sender SHOULD include time-secfrac (fractional seconds) if its
    clock accuracy permits so

A sample of this format is:

      1985-04-12T23:20:50.52Z

   This represents 20 minutes and 50.52 seconds after the 23rd hour of
   April 12th, 1985 in UTC.

For complete details and samples see RFC3339.

   A single space character MUST follow the TIMESTAMP field.

Receivers parsing the date format SHOULD check if the TIMESTAMP is a
RFC3339-TIMESTAMP. The "T" character at position 11 of the string can be
used as a rough indication for this. However, the receiver MUST NOT rely
solely on the "T" character but also parse the other data for validity.
A receiver SHOULD check for RFC3339-TIMESTAMP format first and, if
unsuccessful, assume a RFC3164-TIMESTAMP. If it is also not an
RFC3164-TIMESTAMP the receiver MUST NOT try any other timestamp format
but consider this message to be invalid.

If a relay receives a RFC3164-TIMESTAMP, it SHOULD forward the message
with a RFC3164-TIMESTAMP but MAY reformat it to a RFC3339-TIMESTAMP if
configured to do so. If a relay receives a RFC3339-TIMESTAMP it MUST
forward the message with a RFC3339-TIMESTAMP. It MUST NOT reformat it to
a RFC3164-TIMESTAMP.
- ---- end suggestion ----

There are two changes to my original suggestion:

- - I have removed the requirement to format the timestamp in UTC
- - a relay is now permitted to reformat a RFC3164-TIMESTAMP to a
RFC3339-TIMESTAMP

As far as I kept track, there is one point open to discussion. Andrew
Ross suggested that the timestamp should be fixed length. I will post a
reply to his original message, so if somebody would like to jump in,
that would be fine. Other then that, I think we have reached consensus
on the new text. Any opposition against this?

Rainer

------------------------------

Date: Mon, 23 Dec 2002 10:06:33 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog time stamp

> YYYY-MM-DDTHH:MM:SS.NNNZ+09:30
>
> How about mentioning that the time stamp must be a fixed
> length, with leading zeros for padding. This makes parsing
> and verification much simpler.

It sounds tempting, BUT... (see next paragraph).

>
> For example: time-secfrac SHOULD be 3 digits (milliseconds).
>
> Also, if sub second count is not used, it SHOULD be set to
> 000 rather than making it optional.

I oppose this: if we filled in a numerical value, the receiver would not
be able to distingush between a device who's clock is accurate and who
definitley says ".000" and another one which has just a second
resolution and thus saying ".000". Thus, we would loose much in
accuracy. I would definitly like to see the ms only from devices that
actually support it.

Otherwise, doing analysis, a process relying on the timeing could be
totally fooled when correlating events (much can happen within a single
second).

Now, if you look at RFC3339, you'll see that you can't create a fixed
format, with this in mind. The obvious choice of replacing the ".000"
with ".   " (being  DOT SP SP SP) would violate RFC3339.

>
> The time offset should be in the format -0100 or +0930 (can
> you tell I used to live in Adelaide). Alternatively a : could
> be added in the middle -01:00 or +09:30. The HH:MM should be
> fixed length and require the use of +/- indicator.

RFC3339 specifies ":" and I see no reason to change things here - let's
stick with the accepted standard (which says fixed size and '+/-'HH:MM).

Rainer

------------------------------

Date: Mon, 23 Dec 2002 12:44:14 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

On Sun, Dec 22, 2002 at 11:03:19AM -0800, Darren New wrote:
> Balazs Scheidler wrote:
> > The description should focus on the means of encapsulating one single
> > message into the TCP stream, where the message has the same format as the
> > UDP packet in RFC3164.
>
> [snip]
> Just FYI. The problem *has* been solved. :-)

I know about that. I don't want to enter endless debates again. syslog/tcp
is not competing with syslog-reliable. syslog-reliable will be the future,
syslog/tcp is what current products do. In fact, TCP transport is the most
useful feature of recent syslog implementations, maybe their only reason for
existence.

Simply using syslog/raw and a trivial beep implementation is like using
an SQL server to store your 100 user accounts. Syslog benefits from the
advanced BEEP features, but the RAW profile gives you nothing more than the
three paragraph description I gave in my previous mail. Why should
implementors bother then?

This is what I (as a vendor) consider:

Should I implement RFC3195?

Pros
* It gives me an extendable transport protocol with integrity protection,
  authenticity, and negotiation
* It's standard and documented
* My current implementation has interoperability problems which would be
  solved

Cons
* I already have a protocol over TCP implemented which can be SSL wrapped
  (thus provides integrity protection and authenticity)
* I have no need for negotiation
* My current implementation interops with a couple of others, and it is
  quite easy to solve the interoperability problems with trivial
  modifications
* There are fewer RFC3195 compliant syslog peers than syslog/tcp capable
  syslog peers

So the decision to go for RFC3195 right now is not trivial. In the short
term ensuring interoperability between syslog/tcp implementations would buy
you more than implementing RFC3195. How about adding this paragraph to my
previous description:

NOTE: syslog/tcp is used in legacy syslog implementations and as such new
implementations should favor the protocol described in RFC3195.

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Mon, 23 Dec 2002 15:59:51 +0100
From: Rainer Gerhards <[email-masked]>
Subject: Security Issue with RFC3195

... While digging deeper into BEEP and it's implementation, I see a
security issue with its deployment. BEEP is a multiplexing protocol,
thus multiple profiles can run concurrently on a given BEEP connection
at a given time. From the firewall point of view, we can simply enable
or disable BEEP. When a crypting tuning profile is used, the firewall
can not even look at the application layer into the exchange of BEEP
packages. So effectively BEEP will open up a hole in the firewall (as
does SOAP for HTTP).

How is this WG thinking about this? I fear that this fact can reduce the
acceptance for protocols based on BEEP (at the end-user level, not the
implementors). At least I think it would be a good idea to mention this
issue in the security considerations issue.

Rainer

------------------------------

Date: Mon, 23 Dec 2002 10:39:11 -0500
From: Harald Koch <[email-masked]>
Subject: Re: Security Issue with RFC3195

> From the firewall point of view, we can simply enable
> or disable BEEP.

But you don't "enable or disable BEEP". You enable or disable syslog;
syslog happens to use BEEP for its messaging protocol. Ditto anything
else that uses BEEP; you're still enabling the individual protocol.

> When a crypting tuning profile is used, the firewall
> can not even look at the application layer into the exchange of BEEP
> packages. So effectively BEEP will open up a hole in the firewall (as
> does SOAP for HTTP).

HTTP opens a security hole in a firewall, even with a proxy server. I
have successfully run IP tunnels over HTTP through a proxy using
off-the-shelf software. This is a red herring, IMO.

- -- 
Harald Koch     <[email-masked]>

------------------------------

Date: Mon, 23 Dec 2002 16:49:07 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Security Issue with RFC3195

Harald,

> But you don't "enable or disable BEEP". You enable or disable
> syslog; syslog happens to use BEEP for its messaging
> protocol. Ditto anything else that uses BEEP; you're still
> enabling the individual protocol.

Are there multiple TCP ports involved? I haven't found this mentioned
anywhere (maybe I overlooked the obvious). As long as it is one port, I
can do it. Even with an IANA assigend syslog-reliable port, I can not
totally guarantee that only syslog is spoken there...

>
> > When a crypting tuning profile is used, the firewall
> > can not even look at the application layer into the
> exchange of BEEP
> > packages. So effectively BEEP will open up a hole in the
> firewall (as
> > does SOAP for HTTP).
>
> HTTP opens a security hole in a firewall, even with a proxy
> server. I have successfully run IP tunnels over HTTP through
> a proxy using off-the-shelf software. This is a red herring, IMO.

This is exactly my concern! And I don't see it is addressed in the
syslog RFC series...

Rainer

------------------------------

Date: Mon, 23 Dec 2002 11:53:38 -0500
From: Harald Koch <[email-masked]>
Subject: Re: Security Issue with RFC3195

> Are there multiple TCP ports involved? I haven't found this mentioned
> anywhere (maybe I overlooked the obvious).

That's my understanding. We don't have a single port for SSL, instead
running "blah-over-SSL"; BEEP is the same.

> > HTTP opens a security hole in a firewall, even with a proxy
> > server. I have successfully run IP tunnels over HTTP through
> > a proxy using off-the-shelf software. This is a red herring, IMO.
>
> This is exactly my concern! And I don't see it is addressed in the
> syslog RFC series...

I'm not aware of any IETF protocols that address this problem, which is
my (subtle :-) point. I'm of the opinion that defending against these
attacks is beyond the scope of the individual IETF working groups (and
is, in some cases, impossible :-).

- -- 
Harald Koch     <[email-masked]>

------------------------------

Date: Mon, 23 Dec 2002 18:06:58 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Security Issue with RFC3195

Harald,

> That's my understanding. We don't have a single port for SSL,
> instead running "blah-over-SSL"; BEEP is the same.

Sure - but we know to expect HTTP traffic at port 80 and HTTPS at 443.
So if we don't like HTTPs, we simply block 443 at the firewall. End of
the story.

>
> > > HTTP opens a security hole in a firewall, even with a proxy
> > > server. I have successfully run IP tunnels over HTTP through
> > > a proxy using off-the-shelf software. This is a red herring, IMO.
> >
> > This is exactly my concern! And I don't see it is addressed in the
> > syslog RFC series...
>
> I'm not aware of any IETF protocols that address this
> problem, which is my (subtle :-) point. I'm of the opinion
> that defending against these attacks is beyond the scope of
> the individual IETF working groups (and is, in some cases,
> impossible :-).

Sure - but the fact is that there is the IP standard (I guess you know
which I mean, I don't have the RFC at hand ;)) and itself is a
multiplexing protocol using port numbers to multiplex the different
"channels" on the wire. Current firewall technology provides adequate
measure for this. Most of the other IETF protocols are not multiplexing
protocols, so they don't add any concerns above what IP already does. As
we specifically deal with security issues, I think we should at least
provide some awareness to the fact that we have a protocol that allows
for such doing. Sure, I would always opt to have a dedicated machine
running a prooven and trusted version of an BEEP-based syslog, but it
might be a good idea to provide some additional reasoning for this to
the end user. Also, keep in mind that there are three levels of
acceptance

- - in the standards comittee
- - at the implementors
- - at the end user level

A protocol prooves to be successful only if implementors implement it
AND end users deploy there products. And there are definitely concerns
about muliplexing protocols in the end user level (and I think it is
good so).

Maybe I am overly concerned with that - but look how even smallest spots
are exploited. And tunneling over http is a good sample of what should
not happen to a protocol (how does Microsoft say: ".NET is firewall
friendly"...).

Rainer

------------------------------

Date: Mon, 23 Dec 2002 12:00:57 -0500
From: Carson Gaspar <[email-masked]>
Subject: RE: Security Issue with RFC3195

_Any_ protocol that does end-to-end crypto enables tunneling through the
firewall. If you don't want to allow that, you have to have the firewall
decrypt, analyze, and re-encrypt. For syslog, this is trivial - make the
firewall a syslog forwarder.

Of course, it's practically impossible to stop all tunneling. I could
implement a very slow tunnel by encoding bytes in the milliseconds of my
log timestamps, and you'd be unlikely to discover me. This is not a syslog
problem, it's a generic covert channel problem.

- -- 
Carson

------------------------------

Date: Mon, 23 Dec 2002 20:36:05 +0000
From: Magosányi Árpád <[email-masked]>
Subject: Re: Security Issue with RFC3195

A levelezõm azt hiszi, hogy Harald Koch a következõeket írta:
>
> HTTP opens a security hole in a firewall, even with a proxy server. I
> have successfully run IP tunnels over HTTP through a proxy using
> off-the-shelf software. This is a red herring, IMO.

Can I beat it some more? :)

The most important advantage of flexible protocols that one can
tunnel anything through them.
The most important disadvantage of flexible protocols that one can
tunnel anything through them.

But...

If the designers of protocols would be condemned to implement a real security
proxy for their new protocols, the disadvantage could be at least in an extent
handled.

In the current state of affairs I would venture to say that a good
security proxy (firewall) should be able to stop or at least minimize
the bandwith of any known covert channel (your IP tunnel), on the protocol
it handles.

There _is_ a good security proxy for http; the one implemented in Zorp. It
can either be configured to catch your IP tunnel, or your IP tunnel is not
uses http.

The moral of the story is in the disclaimer: maybe catching the tunnel will
also stop traffic you (or your users) consider as legitimate. This is due
to the following facts:
	#1: Developers barely read the specs while their implementation
		works. Some say that the ones in Redmond read them, only
		to make sure that their implementation differs in little
		but strategic points.
	#2: Developers tend to (ab)use little features of standards to
		do those absolutely unnecessary bells-and-whistles.
		Therefore protocol developers tend to make their
		protocols in a way that the bulk of the protocol is
		in that not-yet-defined-do-as-you-wish feature class.
	#3: If something is (ab)used widely enough, no one will care if
		it is standard or not. If you say that this something
		should not be counted on, or even expressly prohibited
		by the RFC, you will shortly meet some blank sights
		and utter misunderstanding of your point, because someone
		is already depending on it.
		(I would prefer the blank blinks of blondes instead,
		it alliterates better:)

It must be understood that #2 is important here. I guess most of you
(and me) regard the behaviour of the protocol developer as good
engineering practice.

_Until you start to design a proxy for the new shiny protocol._

Sorry for beating that dead red horse (or herring?) so long,
but it is an important point which is heavily underconsidered.

- -- 
GNU GPL: csak tiszta forrásból

------------------------------

Date: Tue, 24 Dec 2002 21:21:34 +1300
From: Andrew Ross <[email-masked]>
Subject: RE: Syslog time stamp

Having a fixed width timestamp would be really nice for parsing, but is
not the end of the world if we can't do it.

> YYYY-MM-DDTHH:MM:SS.NNNZ+09:30

If you think about it from a parsing point of view...

Assume that you have a message type defined...

Type tSyslogMessage
  Time
  Date
  Milliseconds
  Timezone
  HostAddress
  etc
End type

When you receive a timestamp that has no millisecond count, what do you
put in your millisecond variable?
If it was me, I'd initialise it with 000.

I can see Rainer's point about deciding if a host has an accurate clock
or not, but a quick look at the logs would show that every message from
that host was stamped with 000 and therefore assume that it was not
setting the value.

Could we pad it with NNN instead of SP SP SP or 000?

>RFC3339 specifies ":" and I see no reason to change things here - let's
>stick with the accepted standard (which says fixed size and
'+/-'HH:MM).
Yes, agreed.

Merry Christmas everyone!

Andrew
Kiwi Enterprises

------------------------------

Date: Tue, 24 Dec 2002 09:15:18 -0500
From: Bennett Todd <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

2002-12-20T15:45:47 Christopher Lonvick:
> - there are many tcp-based implementations to transport syslog but none
>   of them interoperate

I'm not as sure about that. It's possibly the case that not all of
them interoperate, but I'd expect most of them to; about the only
"interesting" question I can see affecting interop is whether the
records within the TCP stream are delimited by cr, crlf, lf, or some
prefix-count mechanism. I'd expect most implementors to terminate
with lf or crlf when writing; a tolerant listener could terminate on
lf and strip any trailing cr found.

> - a simple tcp-based implementation would need all of the aspects of
>   BEEP to optionally call the security features that are desired
>   (reliable transport, confidentiality, device authentication)

Some of us feel that a simple tcp-based implementation can be
provided with such features on an as-needed basis with external TLS
implementations. There's much dispute about that.

> - BEEP channels can be a good thing

Another disputed topic.

> I'm still not seeing what features/functions are missing from 3195, or
> what features/functions a simple tcp-based syslog would fill.

I believe this discussion thread arose when a syslog implementor
asked if anybody knew of a library implementing BEEP that would
address problems he was having; I don't recall hearing an answer.
There are heavyweight library implementations with various problems
he described, that's he's trying to work with. It's been asserted
here that a very lightweight subset-of-BEEP could be easily
implemented, and would suffice for an RFC 3195-compliant
implementation.

> I'll keep this discussion open to see if we can get a clear reason
> for a simple reliable tcp protocol.

I think the concept offered was that BEEP may or may not be the only
Proper Way to implement any protocol in the future, but if so it
appears to be remaining in the future; for the present, an
intermediate step specifying TCP transport for syslog without
adding multiplexed MIME streams may be helpful.

I think the next step we need is to survey existing sylog-over-tcp
implementations and see who is terminating their records how, and
what sort of interop (if any) is available.

- -Bennett

------------------------------

Date: Tue, 24 Dec 2002 09:20:18 -0800
From: Tom Perrine <[email-masked]>
Subject: Re: Syslog time stamp

>>>>> On Tue, 24 Dec 2002 21:21:34 +1300, Andrew Ross <[email-masked]> said:

    AR> I can see Rainer's point about deciding if a host has an accurate clock
    AR> or not, but a quick look at the logs would show that every message from
    AR> that host was stamped with 000 and therefore assume that it was not
    AR> setting the value.

"Objection your honor, calls for a conclusion from the witness." :-)

    AR> Could we pad it with NNN instead of SP SP SP or 000?

Perhaps "---", since we often use "-" to indicate missing stuff.  But
pretty much anything that is an "out of badn", e.g. not a digit, would
be acceptable.

- --tep

------------------------------

Date: Thu, 26 Dec 2002 17:43:23 +0100
From: Rainer Gerhards <[email-masked]>
Subject: RE: Syslog time stamp

> Perhaps "---", since we often use "-" to indicate missing
> stuff.  But pretty much anything that is an "out of badn",
> e.g. not a digit, would be acceptable.

Unfortunately, this would violate [RFC3339]. I think we should try to
stick with the accepted standard rather then inventing yet another time
stamp. I think it is easy enough to parse RFC3339, the variable length
should not be a to-big issue. Especially as the token is well-defined,
so there is no doubt where it will start and end. This is different to
the tag value that Andrew used as a sample (well, it is defined in
[RFC3164], but in reality there are a number of variations and "smart
detection" causes lots of trouble.

Andrew: can you agree on this? Anybody else oposing it?

Rainer

------------------------------

Date: Thu, 26 Dec 2002 09:31:30 -0800
From: Tom Perrine <[email-masked]>
Subject: Re: Syslog time stamp

>>>>> On Thu, 26 Dec 2002 17:43:23 +0100, "Rainer Gerhards" <[email-masked]> said:

    RG> Andrew: can you agree on this? Anybody else oposing it?

Actually, I'm all *for* RFC 3339 timestamps.  I personally have never
seen a case where I actually cared or needed to match timestamps to
closer than 1 second.

And if my suggestion is non-compliant with 3339, then consider it
withdrawn, with extreme prejudice :-)  Using RFC 3339 is much more
important to the standardization effort.

Now, having all the clocks sync'ed, I'm willing to fight for :-) but
that's obviously beyond the scope of this.

- --tep

------------------------------

Date: Sat, 28 Dec 2002 01:41:34 +1100 (EST)
From: Darren Reed <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

In some email I received from Bennett Todd, sie wrote:
[...]
> I think the next step we need is to survey existing sylog-over-tcp
> implementations and see who is terminating their records how, and
> what sort of interop (if any) is available.

Well since someone has asked, I'll volunteer some information on what
nsyslogd does over TCP :)  The below is part of a text file from it.
I'm not aware of anything being interoperable with it.  Log messages
are limited to somewhere just under 64k and since the message size is
passed through, there is no record delimeters used or required.

btw, I don't think this is perfect (ms or finer resolution might be
nice for timestamps, for example).

Darren

TCP usage.
- ----------
TCP is used for encrypted and authenticated communication between two
hosts.  A shared secret (stored on disk in plain text :-() is used for
peer authentication by each host.  Messages exchanged are sent using
a binary protocol - structures are sent straight out with no regard
as to translating them into text.

TCP protocol.
- -------------
The protocol used is made up of messages.  The minimum size for a message
is 4 bytes - 2 bytes for a command and 2 bytes for any operands.  Commands
are currently recognised as being 0x0000-0x00ff.  Errors are indicated by
sending back the message header with the MSB set (0x8000).  ACK's to
messages are inidcated by setting 0x4000 in the reply header.  A message
which is longer than just 4 bytes is indicated by setting 0x2000 and the
operand to the length of data following.

Currently supported commands:
0 - NULL, operand = 0
1 - HASH function (used to negoiate which to use), operand = hash function
    choice
2 - encryption function (not supported)
3 - nonce (sent to the other end for peer authentication), operand = length
    of nonce.
4 - hash (result of hashing the nonce with the shared secret - peer
    authentication depends on this), operand = length of hash
5 - message (syslog message details), operand = length of data
6 - message hash (not supported, possibly even deprecated)
7 - H0 (not yet supported)
8 - SSL (SSL is encapsulated in message blocks.  This was done so that
    OpenSSL could be used within the scope of the program without making
    too many wholesale changes to either).

The client drives the connection, telling the server what hash function
to use, etc.  If no hash function is agreed to then it falls back to a
null-hash function.  Authentication is performed by both parties and of
the other.

The actual format of messages is as follows:

byte       purpose
      0    version (current is 1)
      1    hash type found at the end
2   - 3    reserved (should be zero)
4   - 7    original source IP#
8   - 11   total length of this message
12  - 15   length of the log message
16  - 19   length of the hash after the message
20  - 23   facility|priority of message
24  - 27   time message was received (seconds since epoch)
28  - x    text syslog message
x+1 - x+n  hash of all the above fields.

------------------------------

Date: Fri, 27 Dec 2002 23:43:57 +0100
From: Balazs Scheidler <[email-masked]>
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

On Sat, Dec 28, 2002 at 01:41:34AM +1100, Darren Reed wrote:
> In some email I received from Bennett Todd, sie wrote:
> [...]
> > I think the next step we need is to survey existing sylog-over-tcp
> > implementations and see who is terminating their records how, and
> > what sort of interop (if any) is available.
>
> Well since someone has asked, I'll volunteer some information on what
> nsyslogd does over TCP :)  The below is part of a text file from it.
> I'm not aware of anything being interoperable with it.  Log messages
> are limited to somewhere just under 64k and since the message size is
> passed through, there is no record delimeters used or required.
>
> btw, I don't think this is perfect (ms or finer resolution might be
> nice for timestamps, for example).

Thanks Darren. Andrew has already sent me a proposal about his protocol,
would you please resend it to the list?

I think it was also Andrew who summarized the PIX TCP protocol:

# Sends on TCP port 1468 by default.
# Can have multiple messages in a single packet. They don't appear to be
seperated by any character. New message is identified by the <PRI> tag.
# TCP connection is made once, and remains open indefinately.
# If the connection is broken and not able to be re-established, the PIX
will stop forwarding network traffic through it's interfaces.
# PIX message format changes depending on timestamp settings on the PIX.

I think messages should be terminated somehow, probably with a '\n'
character? Anyone with a PIX at hand can confirm this? This seem to be
compatible with my previous syslog-over-TCP description (which described the
way syslog-ng behaves).

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Wed, 25 Dec 2002 19:05:31 -0800
From: Darren New <[email-masked]>
Subject: Re: Security Issue with RFC3195

>
>
>In the current state of affairs I would venture to say that a good
>security proxy (firewall) should be able to stop or at least minimize
>the bandwith of any known covert channel (your IP tunnel), on the protocol
>it handles.
>
>
As I've said, take a look at the TUNNEL profile, under development in
the IDWG. It should help. The IDWG seems pretty happy with it.

------------------------------

Date: Mon, 30 Dec 2002 11:25:41 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Certificate Block

Hi,

I was looking over Section 4 of syslog-sign-08 and saw that the Signature
Group is included in the Certificate Block, while the Signature Group and
the Highest Priority are also included in the Payload Block.  (Just for
those who are a bit rusty on this: The Payload Block may be a long blob of
information containing the certificate of the device.  The Certificate
Block can chop that up and transport the pieces of it to a collector using
the normal syslog protocol.  The collector can reassemble the pieces to
find the key/certificate/whatever - See Sec. 4.2e.)

I don't see that this information needs to be duplicated in both the
Certificate Block and the Payload Block and I would think that it would be
better in the Payload Block.  There, a syslog device would be able to use
that information to send out a copy of the Payload Block to each of the
collectors.  Does anyone have any objections to having the SIG and SPRI
(as taken from the table on Page 9) only appear in the Certificate Block?

Thanks and Happy New Year,
Chris

------------------------------

Date: Mon, 30 Dec 2002 12:04:01 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Re: Remarks on syslog-sign (draft 07)

Hi,

OK, I'm reviewing today.  :)

On Thu, 21 Nov 2002, Jon Callas wrote:

> On 11/21/02 3:11 AM, "Albert Mietus" <[email-masked]> wrote:
>
> > ** The TAG is defined to be ending ('MUST')with a _colon_.
> >  This wrong, as rfc3164 defines it can end with a _space_
> > Adv   Rewrite: it terminates with any not alfanum char.
> >
>
> Hmmm. Let me look.

We discussed (a long time ago) that the TAG should be included in the
HEADER rather than in the MSG for people writing code.  See the 3rd
paragraph in Section 2.  This should mean that the TAG should be able to
contain things like:
   syslog[1234]:
Since the next character may, or may not be a space, then we need some way
to define a terminator to the field.  I'll suggest that the colon stay.
That would still allow things like:
   syslog[1234]:Here is my syslog message

That does bring up a point, however.  In "traditional" syslog messages,
there is nothing between the ":" and the message itself in many cases.
Should there be a space between the ":" and the Signature Block, and the
Certifiate Block in the syslog-sign messages?  If so then a Signature
Block would look like:
   syslog[1234]: @#sigSIG 0111 ...
and the Certificate Block would be:
   syslog[1234]: @#sigCER 0111 ...

Thanks,
Chris

------------------------------