Hi Chris,
Comments in-line.
At 08:20 AM 11/9/00 -0500, Chris Calabrese wrote:
>As one of the people who have been pushing storage
>security since the beginning, let me address this...
>
>When the mailing list first started, there were two factions.
>The first was biased toward solving the "entire" problem
>of system logging, including cradle-to-grave confidentiality
>and integrity. As such, the group pondered many different
>avenues, the most fully-cooked of which was an XML-based
>log format that built on the UML work and used digital
>signatures to provide integrity and key distro for
>confidentiality (see attachments xml-log.{html|txt}).
>
>The second wanted to bring reasonably secure logging
>functionality to low-end embedded devices (i.e., sub $500
>switches and hubs) and thought the public-key crypto of the first
>group was too much overhead.
>
>Eventually, the IETF agreed to form a working group to support
>some of this work, but told us not to work on the end-to-end
>roblem as it was also being worked on by the Intrusion Detection
>Working Group (IDWG). Additionally they said that they were
>only interested in the protocol and security aspects and that any
>message-formatting issues beyond these aspects were a
>secondary affair.
>
>As a result, work on the end-to-end problem was suspended
>and work on simple authentication for embedded devices
>moved forward.
There are two parts to that. First, this IETF effort has not tried
to stop or slow any work on the formatting of the messages. You,
as well as everyone else in the world, are free to continue that
work. As I've noted in prior postings to this list, I am supportive
of that work yet it is outside the scope of this Working Group.
For the second part, this Working Group was never formed to only
work on any particular device. There is no mention of this Working
Group being limited to any particular device in our Charter.
http://www.ietf.org/html.charters/syslog-charter.html
You brought this up a few weeks ago as well. Perhaps you missed my
reply at that time? Here is what I wrote then and I stand by it
today:
>At 03:52 PM 10/25/00 -0400, Chris Calabrese wrote:
>>Maybe I missed something, but I thought some folks were working
>>on a 'lightweight' authentication protocol that could be used by
>>low-computing-power embedded systems (like routers and
>>switches). This statement related to the idea that a relay
>>might sign data as authentic that came in under this protocol
>>as the authentication data couldn't be forwarded
>At 02:59 PM 10/25/00 -0500, Chris M. Lonvick wrote:
>Ahh. That's Alex's draft. It won't just be for routers, switches
>and other embedded systems. It _should_ be available for everything.
>That's what I've called the Authenticated format or the A device.
>Now, however, it has become clear that the work coming out of
>the IDWG will not address the concerns of generalized
>end-to-end secure logging. And therefore there is renewed
>interest in addressing that issue within that group.
>
>The fundamental question is... Is it really true that embedded
>devices don't have enough horsepower to do public-key crypto
>at the speeds required? This is a non-trivial question because
>first we have to answer the question of what speed really is
>required (i.e., how often secure messages really have to be
>sent anyway).
We are not discussing embedded systems.
>If they can do it, then I believe we should concentrate only on
>end-to-end solutions. I also believe that shared secret solutions
>are a fundamentally wrong approach to this problem.
>
>If they can't, we'll need end-to-end solutions for systems that do
>have the horsepower and an "on-ramp" solution to getting
>messages from systems that don't.
>
>Personally I'd be surprised if there really are any devices being
>planned for manufacture within the timeframe of when this stuff
>will become real (say a year from now) that couldn't handle the
>computations. After all, you can get a $150 LinkSys router that
>can do several mb/s of IPsec these days, and the IKE bits of that
>are pretty similar to the stuff we're talking about. Yes, I know
>IKE
>key negotiation is only a small fraction of the overall traffic, but
>so is logging.
>
>Either way we need to develop the end-to-end solution.
We need to develop a practicable solution.
The reason that I've wanted to separate the two efforts (I think
that I've posted this somewhere before) is that I believe that
the step from today's implementation of syslog, up to a "total
solution" (that mandates formatting) is too steep. It would not
be implemented and would therefore be a futile effort.
Instead, I've been proposing that we take incremental steps to
achieve this. The first is a method to add some authentication
of the message. The second is a method to provide reliable
delivery of the message. Both of these must transport the current
"freeform" message but neither of these precludes a structured
format. I would like to keep it that way so that a future effort
may propose a way to fit a structured format into either or both.
>That doesn't necessarily mean that the solution has to address
>internal formatting of messages (as my original proposal did).
>Another approach would be to specify a framework that provides
>the security bits to protect free-form messages, but also allows
>extensions to do more formatted stuff later. Essentially this would
>be something like my proposal with some of the formatting stuff
>stripped out. Some of the formatting bits could actually stay
>because the system knows how to fill the answers in without help
>from the logging application (timestamps, for example). The other
>bits that were stripped out could be specified in a seperate
>extension document published in another forum (W3C, POSIX,
>and X/Open come to mind).
>
>Another approach would be to beef up the current Syslog-Reliable
>to do confidentiality and integrity.
---remainder deleted for brevity---
As I've mentioned to you before, BEEP provides both.
Your draft has merit. Also, as I've suggested before, you should
consider formatting it properly and submitting it as an ID. It
cannot be a product of this Working Group as that is outside of our
Charter, but I'm certain that many people on this list would find
time to comment on it.
Later,
Chris
[EMAIL PROTECTED] for separate replies
