At 09:53 AM 11/10/00 -0500, Chris Calabrese wrote:
---some deleted for brevity---
>Meanwhile, that still begs the question of whether
>Syslog-Auth is really needed.
>
>The charter says we need something that works over UDP.
>Of course, we can always say just use IPsec for that.
Not quit IMHO. Just pushing the traditional message across IPsec
tunnels doesn't really buy you much. There is no association between
IPsec and any process that utilizes it. The syslog process on the
sending machine could be broken in such a way that it sends off
garbage. It would go through the IPsec tunnel and be delivered to
the collector. At that time, or at some later time, a savvy
administrator would be able to look at that and say with great
certainty, "Yes, this garbage must have come from one or more of the
devices in my network that has the ability to form an IPsec tunnel
with this collector. ..but, dang if I can figure out which one or
what the original message was supposed to be."
I still think that we need some form of syslog-auth.
>But if there's a strong feeling that IPsec is not the
>right answer, and Syslog-Reliable can't work over UDP,
>then we still need Syslog-Auth. But in that case,
>maybe Syslog-Auth should also do crypto and then
>we strip hop-by-hop crypto/auth from Syslog-Reliable
>(since Syslog-Auth would already be doing it).
>We can also strip this stuff if using IPsec
>underneath Syslog-Reliable.
I'm not sure what you want in the way of "crypto" in syslog-auth.
I'd suggest we wait until John gets a draft in front of us.
>Remember that we're
>talking about something that won't be in wide-spread
>use for at least a year or two.
Why? Things with great appeal are implemented very quickly
across the Internet.
>By that time, all
>major shipping OS distributions and embedded platforms
>will likely have IPsec built in.
hmm.. Why wait for IPsec? Most of the devices that you've mentioned
have TLS/SSL in them now.
IPsec mandates bi-directional authentication. That's great for IPsec
but I see that as a hindrance to a practical deployment of syslog-reliable.
Consider the traditional set up. You open up a server, or group of
servers, then you walk around to each of your other devices, point them,
and go. Using IPsec would require any of: a PKI or at least a single CA,
the distribution of pre-shared keys, or perhaps something like DNSSEC.
That's a lot of effort to go through. TLS/SSL on the other hand does
not require bi-directional authentication. It can be used with neither
side having a certificate. If that fits the security policy of the
organization using it, then it's a lot easier to set up. On the other
hand, TLS/SSL does support bi-directional authentication and then
authoritatively signed certificates would have to be placed on each
device.
If the proposed syslog-reliable uses the shared secret hashing method
proposed in syslog-auth, you could start up the server and place
the shared key on it. You'd then go around to each of the devices, place
the shared secret on them, point them and then go. If you had a more
restrictive policy, you could have each of the devices generate a key,
fill out a cert, have it signed, and then loaded back into the device.
That process is getting to be easy as well.
All in all, I havn't seen any reasons to change the course that has
been specified in the charter. syslog-auth should give a simple tack-on
authentication to syslog, and syslog-reliable should give a way to deliver
it with verifiable receipt. All with hopefully little heart-ache.
Thanks,
Chris
