Balazs Scheidler wrote:
>
> > I've made some minor revisions and placed the latest here:
> >
> > http://www.employees.org/~lonvick/draft3.txt
> >
> > If I can get some reviewers to say that the Security Concerns
> > section is acceptable (or to note areas that need changes as
> > some of you have), then I'll start accepting proposals for
> > - an authenticated syslog protocol and,
> > - a protocol that can provide authentication, integrity and
> > confidentiality for syslog message transport.
> > Both of these are loosely defined in the Charter but they need
> > to address the security concerns of the current syslog protocol.
>
> I think section 5 is acceptable (but please note my previous mail), and I
> think we owe you a big "Thank you" for writing it.
>
> As for your request for proposals on authenticated syslog protocols: it was
> mentioned previously that off-the-shelf products/packages should be used.
> Let's try to sum it up what options we have available.
>
> If I were developing a secured syslog solution in a given case, I think I
> had completely different ways of doing that:
>
> 1 implement authentication, protection at the network layer (IPSec)
> 2 implement authentication, protection at the transport layer (SSL, SSH)
> 3 implement authentication, protection at the application layer, in our
> protocol
>
> #1 would work, but requires a huge infrastructure behind it, and to develop
> a general enough solution, we should not depend on something like IPSec. (or
> equivalent)
>
> #2 is off-the-shelf, requires the least modification to our protocol, and
> requires some CA infrastructure for authentication.
>
> #3 is the most difficult to implement, but can be tailored to our
> application.
>
> I for one would go with #2, though it has some requirements. Any other ideas?
>
> --
> Scheidler Bal�zs BalaBit IT Biztons�gtechnikai Kft.
> tel/fax: +36-1/217-14-98 1092 Bp. K�ztelek u. 4/B
> http://www.balabit.hu
yes, but
#1 can be used tranparently by the OS
#2 SSL needs carefull coding
#3 reinventing the wheel once again
Also it would be nice to make a sort of "stream" inside
this protocol, so helping not to mix different kind
of logs. Say a host collects logs from n routers on
a LAN and forwards them secure to a remote site that
can even be overseas. But this same host may collect
dialup logins taht go to the same remote host, and
nature of both logs is completely different. So a
"stream" concept at protocol level would be handy.
Internals of syslog-ng use this, and there's work
going on to make msyslog support that too.
Cheers,
Alejo
--
Alejo Sanchez - Developer [EMAIL PROTECTED]
Core SDI S.A. http://www.core-sdi.com
--- For a personal reply use [EMAIL PROTECTED]