Chris Calabrese wrote:
> So... The idea sound like it's moving in the direction
> of adding signatures to COOKED mode in Syslog-Reliable
> and possibly adding confidentiality to Syslog-Auth.
and:
> As you are no doubt aware by now... I've been pushing
> end-to-end
> message-level integrity through signing.
>
> So far, I've been assuming the natural place for this is in
> the
> COOKED stuff in Syslog-Reliable. However, there's now
> some question as to whether it might be better off in
> Syslog-Auth.
>
> Arguments for moving this to Syslog-Auth:
>
> * It's a lower level in the food-chain
> * It still operates over UDP
> * It's called 'Auth'
>
> Arguments against:
>
> * Syslog-Auth protocols may not come into play when
> you're running Syslog-Reliable with the SASL stuff
> * I thought Syslog-Auth isn't supposed to alter the
> "payload" (i.e. by adding a signature that doesn't
> get stripped).
>
> What does everyone think?
Sounds like it should be available (and perhaps user-selectable optional
and to-order, e.g. neither raw or cooked, but rare or medium well-done
as you prefer) in both versions. True signature authentication in the
Syslog-Auth UDP version would be great if the UDP PDU size limit is not
exceeded. A common signature wrapper for both Syslog-Auth and
Syslog-Reliable/COOKED would make it easier to provide a single loghost
server supporting both new modes as well as an old-fashioned mode.
Same for confidentiality wrappers in the UDP version. These two really
could be quite similar except for the transport and session layers in
TCP/Reliable.
What about combining compression and encryption to squeeze a full
payload with signature etc into the UDP PDU?
And of course the signature wrapper could be turned off in
Reliable/COOKED mode when SASL is provided, unless your legal liability
issues require it to be present in the log files.
> * I thought Syslog-Auth isn't supposed to alter the
> "payload" (i.e. by adding a signature that doesn't
> get stripped).
I personally think all of these contortions of "the payload" are
wrappers around the original message string as constructed at the source
in
syslog( LOG_INFO, "the %s", "payload" );
and this simple API can still be supported in libc. Default
naked/raw/cooked/etc mode could be set system-wide in a syslog-sec
config file, while an enhanced openlog() could allow new applications
some individual runtime control over log mode. If the API's syslog()
parameter list changes there are serious obstacles to adoption, but if
not, either Auth or Reliable would likely be adopted very quickly
through shared libraries.
BTW, I'm interested in prototype code for BEEP etc. and perhaps these
new Syslog creatures. Does anything exist yet?
--
Alex Brown <[EMAIL PROTECTED]> http://www.msg.com/~abrown +1 617 504 8761
