RE: syslog implementations etc.

[by way of "Chris M. Lonvick" <[EMAIL PROTECTED]>]

d <[EMAIL PROTECTED]> wrote:  "[WRT to this list, I think it'd be great to have
it online, searchable, etc., so newcomers or lurkers can see what's up
here.  (Or I just want to look something up myself and can't find/lose my
mail archive).  Can anyone do this, or is there any problem with this?]"

I don't know whether there's a web server on our mail gateway, and admin
time to set this up, but I'll look into it.

"[...sorry, not sure who said this...]
 > Last call:  has ANYONE had contact with Lucio Torre from Buenos Aires, or
 > been able to download and test his work??  If not, I suggest we drop his
 > work from the discussion, because there is just not enough information
 > available."

It was me.  Just to clarify to all the newcomers:  I am the convener of
this BOF; I work on device and network access security at 3Com's LAN switch
division, and my company hopes the BOF will result in IETF consideration of
syslog's role as a de facto standard for network logging of authentication
events -- with recognition of its long history of security problems.  We
believe that event log streams from network device management processors
and other embedded devices pose different threat scenarios and call for
different solutions than those proposed and implemented so far, largely due
to limited processor resources.

I am delighted to have the contribution of Ivan Arce, and I apologize for
my haphazard attempts to contact his company in recent weeks.

We at 3Com don't have a preferred solution, but we do have specific
scenarios of concern, which seem not to have been considered so far;  we're
delighted to find active discussion of the problem as well as several
implementations, but we do want to look at a variety of realistic threats
and risks, and a corresponding variety of solutions. At this point I think
we need to learn more about the various solutions in order to understand
the assumptions about threat scenarios behind them.

(Schneier's paper makes the very important contribution of an extremely
precise statement of the attack scenario against which it defends.  We need
to work towards similar descriptions of other real-world problems and
solutions.)

Chris Calabrese wrote: "... Log Authenticity, Reliability, Immutability,
Privacy, and other meaty security issues: ..."

These are the most important for our discussion.  Because this is a
Security Area BOF, we should emphasize these security related issues in
making feature wishlists.  Nothing wrong with getting all the others down,
to make it clear what the operations environment covers!!

[EMAIL PROTECTED] wrote:  "Time synchronization is _definitely_ outside
the scope of a logging protocol."

I agree that there should be as few protocol dependencies in the solutions
chosen as possible, esp. at the client, but it is important to identify
security-related information dependencies that they might indicate.   For
example, the log timestamp not only confirms serialization of events, but
gives them a quantifiable relationship in time.  It's well worth
identifying needs for accuracy and trust in a time source at the logging
system.

Alex Brown <[EMAIL PROTECTED]> +1 508 323 2283