Subject: Meeting in Atlanta
From: Christopher Lonvick <[email-masked]>
Date: Sun, 3 Nov 2002 19:35:54 -0800 (PST)

Hi Folks,

We will be meeting in Atlanta on Tuesday, November 19, from 14:15 to
15:15 (2:15pm to 3:15pm).  I'll propose the following Agenda.

Agenda Bashing                               -  2 minutes
Review of Charter and Staus Update           -  8 minutes
Review of syslog-sign                        - 30 minutes
Plea for New Author of syslog-device-mib     - 10 minutes
Wrap Up                                      - 10 minutes

The two outstanding items of this working group are to finalize and submit
to the IESG the syslog-sign ID and the syslog-device-mib ID.  Jon Callas
has agreed to review the syslog-sign work.  Unfortunately, Bruno Pape will
not be able to finish the work he started on the syslog-device-mib.  I
think that we would all like to thank him for his time and effort on this
work and we would now like to continue it and get it finished.  I've been
trying to find another author for this but without luck.  If anyone is
interested, please contact me.  If we do find someone, or a group, I'll
allocate additional time for discussion of this.

Thanks,
Chris

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

Date: 05 Nov 2002 10:28:11 +0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: Relationship of syslog-sign to RFC3195

Hi,

I have been reviewing syslog-sign-07 and notice that it states the
following "Syslog messages are sent over unreliable transport, which
means that they can be lost in transit..."

How does this square with use of the BEEP version of syslog? Is the
intention to use signing only with the UDP transport? SYSLOG-REL is in
the references of sign-07 but I couldn't find an actual reference in the
text.

One other point is that when using reliable syslog with authentication
and encryption, this addresses many of the security requirements of
syslog-sign (origin authentication, detection of missing messages, etc),
at least within a particular session. The crypto overhead would probably
be less, too. However there still could be an application for using both
together, and in particular for having collectors and/or relays use
syslog-sign "on behalf of" a peer connected via syslog-rel. Are proxy
signatures of this type envisaged, and if so are they within the scope
of syslog-sign?

Cheers,
Frank

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

Date: Thu, 07 Nov 2002 15:11:40 -0500
From: The IESG <[email-masked]>
Subject: Note Well Statement

From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.

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

Date: Fri, 8 Nov 2002 08:05:58 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Re: Relationship of syslog-sign to RFC3195

Hello Frank,

On 5 Nov 2002, Frank O'Dwyer wrote:

> Hi,
>
> I have been reviewing syslog-sign-07 and notice that it states the
> following "Syslog messages are sent over unreliable transport, which
> means that they can be lost in transit..."
>
> How does this square with use of the BEEP version of syslog? Is the
> intention to use signing only with the UDP transport? SYSLOG-REL is in
> the references of sign-07 but I couldn't find an actual reference in the
> text.

Both syslog-reliable (now RFC-3195) and syslog-sign were initiated
independently with the thought that they could be complimentary.  It may
be useful to indicate in the syslog-sign work that syslog-sign transported
over syslog-reliable provides cumulative benefits.

>
> One other point is that when using reliable syslog with authentication
> and encryption, this addresses many of the security requirements of
> syslog-sign (origin authentication, detection of missing messages, etc),
> at least within a particular session. The crypto overhead would probably
> be less, too. However there still could be an application for using both
> together,

I think it's actually an implementation detail.  In traditional syslog,
the work provisioning the devices and collectors is pretty minimal.  The
thought was that this could be duplicated with syslog-reliable if we chose
BEEP which may call SASL w/ SSL/TLS.  Authentication may be anonymous and
certificates may only need be presented by the server (or not at all).
This provides confidentiality and message integrity without distributing
and maintaining keys/certificates/passwords/etc.  On the other hand, you
are free to provision and require tougher mechanisms if your policy
requires.  In this ease-of-provisioning model, a rogue device may send
syslog messages to a relay or collector impersonating another device.

In adding syslog-sign, an administrator should be able to get a device to
generate a key and push that along in the syslog-sign certificate block.
If a rogue device tries to impersonate that, then the administrator would
only have to find the public key being held on the 'real' device to decide
if a certificate block and the key were truely associated with that
device.

> and in particular for having collectors and/or relays use
> syslog-sign "on behalf of" a peer connected via syslog-rel. Are proxy
> signatures of this type envisaged, and if so are they within the scope
> of syslog-sign?

I hadn't thought of a relay/proxy being able to sign traditional messages
from another device.  I don't think that's a particularly good idea as the
original syslog messages may be so easily spoofed.  I am, however, very
open to a discussion on this.  Thoughts from others?

Thanks,
Chris

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

Date: Fri, 8 Nov 2002 08:40:04 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Re: text conferencing at the 55th IETF meeting in Atlanta (fwd)

Hi Folks,

There have been several reqests that we try to work it out so that we can
get more participation from people who can't physically be at the IETF WG
meetings.  Marshall Rose and others are proposing an experiment for
Atlanta where we try to do text conferencing.  It sounds like a good thing
to try.  Would anyone be willing to volunteer to be the text conferencing
scribe at our WG meeting?  I'll take multiple volunteers now with the
thought that we select a primary scribe as the meeting starts.  In this
way, we won't be upset if our pre-designated scribe doesn't show up.
Also, we can designate a secondary just in case the primary wants to
approach the microphone.  Please send in your name to me directly if
interested.  Please send discussion comments to the list.

On another note, it appears that we are scheduled for the room wired for
multicast - so don't be making any of those rude noises by the
microphones.  If you can't be in Atlanta but would like to watch the
meeting over multicast, now would be a good time to make sure that you can
set this up.

Thanks,
Chris

- ---------- Forwarded message ----------
Date: Thu, 7 Nov 2002 15:21:56 -0800
From: Marshall Rose <[email-masked]>
To: Marshall Rose <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: text conferencing at the 55th IETF meeting in Atlanta

hi. the conference rooms for the atlanta ietf have been set-up.

there is one conference room for each wg/bof meeting in atlanta. the
name of the room is the official IETF abbreviation found in the agenda
(e.g., "apparea", "dhc", "forces", etc.) there is one exception, the
room for the "fax&vpim" meeting is called "fax+vpim".

i have attached the instructions for accessing the rooms, etc.

now would probably be a good time to send a note out to each mailing
list letting folks know that text conferencing will be available at
atlanta. in that message, you can also ask for a volunteer scribe (so as
to minimize time spent at the beginning of the meeting asking for one).

enjoy!

/mtr

	     Remote Access for the 55th IETF meeting in Atlanta:
			     Text Conferencing

At each IETF meeting, two of the working group meeting rooms are equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 55th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

    conference.ietf.jabber.com

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.

1. Before the meeting:

1.1. If you want to participate

If you don't already have one, get yourself a Jabber client, here are some
suggestions:

    platform	suggestion
    --------	----------
    win32	http://exodus.jabberstudio.org
    'nix	http://gabber.sf.net
    macos	http://jabberfox.sf.net

When you start the client for the first time, it will eventually ask if
you want to register on a public server. Go ahead and do
that.

If you want to find out more, instead of choosing these defaults, here
are pointers to some additional information:

    list of clients:    http://www.jabber.org/user/clientlist.php
              howto:    http://www.jabber.org/user/userguide/
        server list:    http://www.jabber.org/user/publicservers.php

To make sure everything is running ok, do a "Join Group Chat" with your
Jabber client:

    Group/Room: testing
    Server:     conference.ietf.jabber.com

This conference room is up and running right now (although probably no
one will be in it when you connect).

1.2. What the Chair does

If you want to make text conferencing available, you'll need to have a
volunteer scribe in the meeting room. The scribe will be typing in a
running commentary as to what's going on in the room (who's presenting,
what question is being asked, etc.)

So, why not send an email out on the mailing list now, before the
meeting, to ask for volunteers?

2. At the meeting

2.1. What the Chair does

When a session starts, the chair asks if someone in the room is willing
to act as "scribe". If no one volunteers, read no further, we're done!

Otherwise, the scribe should do a "Join Group Chat" with their Jabber
client, e.g.,

    Group/Room: foobar
    Server:     conference.ietf.jabber.com

2.2. What the Scribe does

The scribe types in a running commentary as to what's going on in the
room. For example, if a speaker makes a presentation, the scribe types
in the URL for the presentation (more on this in a bit).

Simlarly, during question time, a remote participant can type a question
into the room and the scribe can pass it on to the speaker.

2.3. What each Presenter does

Each presenter should put a copy of their presentation on a web server
somewhere, so remote participants can follow along.

If you don't have a server available, email your presentation to

    To: [email-masked]
    Subject: foobar

and the Secretariat will put the presentation in a server so it can be
accessed under:

    http://atlanta.ietf.org/presentations/foobar/

Don't wait until the last minute to send the email.

2.4. Where to find the conference log

    http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/

2.5. Finally

This is an experiment. Let's see how well it works and discuss it after
the meeting.

				  #######

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

Date: 09 Nov 2002 05:39:45 +0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: Re: Relationship of syslog-sign to RFC3195

On Fri, 2002-11-08 at 16:05, Christopher Lonvick wrote:
> On 5 Nov 2002, Frank O'Dwyer wrote:
[...]
> > and in particular for having collectors and/or relays use
> > syslog-sign "on behalf of" a peer connected via syslog-rel. Are proxy
> > signatures of this type envisaged, and if so are they within the scope
> > of syslog-sign?
>
> I hadn't thought of a relay/proxy being able to sign traditional messages
> from another device.  I don't think that's a particularly good idea as the
> original syslog messages may be so easily spoofed.  I am, however, very
> open to a discussion on this.  Thoughts from others?
Just a quick clarification on this - I had in mind that this would only
occur if the original device authenticated itself when connecting over
syslog-rel. Otherwise, as you say, it definitely doesn't make sense.
Specifically I had in mind that the client would use something like a
one-time password derived from a shared secret, or simply use a
password+TLS. (I am assuming that SASL supports such mechanisms, I
haven't actually looked yet.)

Cheers,
Frank

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

Date: 09 Nov 2002 05:40:42 +0000
From: "Frank O'Dwyer" <[email-masked]>
Subject: Re: Relationship of syslog-sign to RFC3195

On Fri, 2002-11-08 at 16:05, Christopher Lonvick wrote:
> On 5 Nov 2002, Frank O'Dwyer wrote:
> > I have been reviewing syslog-sign-07 and notice that it states the
> > following "Syslog messages are sent over unreliable transport, which
> > means that they can be lost in transit..."
> >
> > How does this square with use of the BEEP version of syslog? Is the
> > intention to use signing only with the UDP transport? SYSLOG-REL is in
> > the references of sign-07 but I couldn't find an actual reference in the
> > text.
>
> Both syslog-reliable (now RFC-3195) and syslog-sign were initiated
> independently with the thought that they could be complimentary.  It may
> be useful to indicate in the syslog-sign work that syslog-sign transported
> over syslog-reliable provides cumulative benefits.
Isn't syslog-reliable pretty much a pre-requisite, though? I mean, why
check for deleted messages when you're using a transport (UDP) that is
going to delete messages itself anyway. It is already known that UDP
messages are lost under high load, and a router is more or less free to
drop them and remain compliant. So given that you detect a missing
message over UDP, it's hard for an implementation to know what to do
with that information.

I would have thought that syslog-sign's benefits would be mainly on the
storage side (detecting tampering), and just the general benefits of not
having to establish and manage shared secrets, plus protection against
rogue relays. But without reliable delivery, detection of tampering
doesn't seem to be worth a lot. Am I missing something?

> > One other point is that when using reliable syslog with authentication
> > and encryption, this addresses many of the security requirements of
> > syslog-sign (origin authentication, detection of missing messages, etc),
> > at least within a particular session. The crypto overhead would probably
> > be less, too. However there still could be an application for using both
> > together,
>
> I think it's actually an implementation detail.  In traditional syslog,
> the work provisioning the devices and collectors is pretty minimal.  The
> thought was that this could be duplicated with syslog-reliable if we chose
> BEEP which may call SASL w/ SSL/TLS.  Authentication may be anonymous and
> certificates may only need be presented by the server (or not at all).
> This provides confidentiality and message integrity without distributing
> and maintaining keys/certificates/passwords/etc.  On the other hand, you
> are free to provision and require tougher mechanisms if your policy
> requires.  In this ease-of-provisioning model, a rogue device may send
> syslog messages to a relay or collector impersonating another device.
True. I had in mind a model where every device would authenticate
itself. In that case only a rogue relay could impersonate (which
syslog-sign would detect). That is, relays or collectors could (and
really should) drop messages where the authenticated peer was a device,
but its hostname did not match the hostname in the message.

I would also expect that real implementations would support 'legacy
syslog' (i.e. completely vanilla syslog) for as long as there are
devices out there sending messages that way. However I would expect them
to treat these messages differently, e.g. flag them as unauthenticated
and more or less "FYI".

By the way, are there working implementations of either spec to test
against for interop purposes? Especially, what can be assumed in the way
of SASL and TLS support for interop?

Cheers,
Frank.

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

Date: Wed, 13 Nov 2002 06:13:33 -0800 (PST)
From: Christopher Lonvick <[email-masked]>
Subject: Duplicate Emails?

Hi,

Frank's second email never reached my inbox last Saturday so I've
re-approved it.  It may be that something glitched within Cisco but I
never got the warm-fuzzies that it had gotten out to everyone.  Please
accept my apologies if you've gotten that twice, but I'd rather that
happen than to miss getting something important to the list.

Thanks,
Chris

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

Date: Sun, 17 Nov 2002 12:33:45 +0100
From: Didier Brisebourg <[email-masked]>
Subject: About syslog main applications

Hi,

I am involved in the development of a product to automatically read syslog
files on some UNIX systems, and automaticaly display alerts and sent events
when some patterns are met in these files (i define some filters).

I want to automaticaly recognize the origin of the messages, based on the
content of the line, by identifying keywords within one line.

1. It seems that no standard exists for the format of the syslog lines after
date and hour header.
    Do you agree with this ?

2. What's the main market of syslog mecanism ? CISCO ? Others ?
    Do you have information about that, or may you give me some useful URLs
?

Thank you.

Cheers.

    Didier Brisebourg

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

Date: Wed, 20 Nov 2002 09:13:22 -0500
From: Marshall Rose <[email-masked]>
Subject: draft minutes from syslog meeting, 55th IETF

please comment. any proposed changes due by close of business, wednesday, 11/27,
us/pacific.

thanks,

/mtr

Security Issues in Network Event Logging WG (syslog)

Tuesday, November 19 at 1415-1515
=================================

CHAIR: Chris Lonvick <[email-masked]>

Agenda Bashing

    No changes.

    Marshall Rose to take minutes.

Review of Charter and Status Update

    Reminder: the goal is *not* about defining/changing the content of
    syslog messages.

    RFCs so far:

    RFC 3164 - "The BSD syslog Protocol"

    RFC 3195 - "Reliable Delivery for syslog"

Review of draft-ietf-syslog-sign-07.txt (kelsey)

    Basic idea: insert extra messages into a log stream along with a
    sliding window.

    Document status: finalizing for RFC submission

    Two changes: renaming one of the "PRI" fields to "Signature Pri" to
    avoid confusion; and, transport agnosticism

Plea for New Author of draft-ietf-syslog-device-mib-01.txt

    two folks are interested in helping out on the syslog mib.

Wrap Up

    we know of two implementations of syslog-reliable.

				  #######

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

Date: Thu, 21 Nov 2002 12:11:22 +0100 (CET)
From: Albert Mietus <[email-masked]>
Subject: Remarks on syslog-sign (draft 07)

Hai all,

As said before, I'm implementing a open source versions of syslog-sign.
Last week I have given a presentation about it at the EuroBSDCon-2002
(See http://2002.eurobsdcon.org/papers/#mietus).

This (simple) implementation is working, but needs be tested a bit more
before releasing  (But mail me for info/src).

Another thing what needs to be done is clearing up the draft. There are
(small) parts of the RFC that aren't clear into detail.

I have made a list of "mistakes/missing part" of the draft-07
That list is shown below.

I hope this will help

NB I wasn't able to "be" at the last IETF55 ;-) Nor was I able to
attent the electronic session. And, due to de stress of the meeting of
Eurobsdcon, I did forget to post this before Nov 19. -- Sorry

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

**  A Signature Block contains a signature. of itself
    There is a (at least) 1 space between the signature and
    the hashes before it.
Q:  Should the hash/signature be calculated including or
    excluding those spaces

**  All fields in Signature an Certificate Block should be
    separated by space
Adv: It should be exactly 1 space, except before a (terminating)signature;
     where 2 spaces are recommended

** Same as above (twice) for Certblocks

** The rfc  defines the Fragment Length (field G) of the CertificateBlock
   as base64 coded. This seams wrong, as it is a normal, printable number.
   (The rfc says that base-64 is only used for binary values, generally)

** The rfc is not uniform in "counting" spaces. Sometimes a terminating space
   is part of a field, and the length of the field is "extended" with 1.
   Sometimes, the space is situated between  2 field. And the
   length(s) count the actual (non-space) content.
   Often, it is not clearly specified.

Adv: Always define the space as "between", for Payload, Certificate en
     Signature Blocks  (not for "normal", rfc3164)  messages.
Adv: use "MUST be separated by spaces" ..."RECOMMENDED is to use 1
     space, (except as written above)". "receivers/validators MUST
     accept any number of spaces.

** 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.

** I think, it should be "better" to show a signature Block
   in an example, not "normal" messages

** Make a note about NOT terminating base-64 coded fields with a
   newline. This is normally done in base-64. A short remark can
   simplify the implementator's job

** In 3.5 and in 4.2.c (ii) & (ii), is specified PRI should be "XXX"
   Rfc3164 does not allow this!
   (and so it can't be used here. as all messages should be
   processable by rfc3164-compliant syslog(d)'s.

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

Date: Thu, 21 Nov 2002 14:13:00 -0800
From: Jon Callas <[email-masked]>
Subject: Re: Remarks on syslog-sign (draft 07)

On 11/21/02 3:11 AM, "Albert Mietus" <[email-masked]> wrote:

Here are my opinions:

> ----------------
>
> **  A Signature Block contains a signature. of itself
>   There is a (at least) 1 space between the signature and
>   the hashes before it.
> Q:  Should the hash/signature be calculated including or
>   excluding those spaces
>

Excluding.

> **  All fields in Signature an Certificate Block should be
>   separated by space
> Adv: It should be exactly 1 space, except before a (terminating)signature;
>    where 2 spaces are recommended
>

I'm willing to make it be exactly one space, but I prefer to keep it so that
it's at least one space and whitespace is ignored.

> ** Same as above (twice) for Certblocks
>

The same.

> ** The rfc  defines the Fragment Length (field G) of the CertificateBlock
>  as base64 coded. This seams wrong, as it is a normal, printable number.
>  (The rfc says that base-64 is only used for binary values, generally)
>

This is a tradeoff. If it's base64, then you get 4:3 expansion. If it's in
hex, you get 2:1 expansion. Given that syslog packets are of a fixed,
relatively small size, this can be important.

>
> ** The rfc is not uniform in "counting" spaces. Sometimes a terminating space
>  is part of a field, and the length of the field is "extended" with 1.
>  Sometimes, the space is situated between  2 field. And the
>  length(s) count the actual (non-space) content.
>  Often, it is not clearly specified.
>

I'll take a look, but I'll repeat the above with a comment. There's a
principle of "be conservative in what you generate and liberal in what you
accept." I'd say that best implementer's practice is to only ever emit one
terminating space anywhere. If a space is part of a field, then don't emit
another one. Similarly, best practice is that you shouldn't ever barf
because someone put in an extra space.

> Adv: Always define the space as "between", for Payload, Certificate en
>    Signature Blocks  (not for "normal", rfc3164)  messages.
> Adv: use "MUST be separated by spaces" ..."RECOMMENDED is to use 1
>    space, (except as written above)". "receivers/validators MUST
>    accept any number of spaces.
>

Okay.

> ** 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.

> ** I think, it should be "better" to show a signature Block
>  in an example, not "normal" messages
>
> ** Make a note about NOT terminating base-64 coded fields with a
>  newline. This is normally done in base-64. A short remark can
>  simplify the implementator's job
>

Uh, yeah. There shouldn't be newlines anywhere, should there be? Why would
anyone think there should be?

> ** In 3.5 and in 4.2.c (ii) & (ii), is specified PRI should be "XXX"
>  Rfc3164 does not allow this!
>  (and so it can't be used here. as all messages should be
>  processable by rfc3164-compliant syslog(d)'s.

We're rewriting part of this anyway. Let me see if the new thing meets with
your approval.

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