#11 COOKED ENTRY CDATA contents

[Rainer Gerhards]

As of RFC 3195, 4.4.2, page 13, "The character data for
the element is the unstructured syslog event message
being logged. " It seems to be (maybe my config fault)
that SDSC does not send the original message but only
the TAG and MSG part of it. If it is not my configuration
fault, this is a serious issue, as this will break syslog-
sign signed messages when transmitted over COOKED.

My config for the output is as follows:

output loghost1 {
type beep;
format-type cooked;
format-options { pri; ts_rfc3339; };
output-path "1.1.1.1";
priority { *.debug; local7.none; };
};
connect system to loghost1;

Rainer

[Devin Kowatch]

Logged In: YES
user_id=31465

I'm not quite sure what you mean by this. SDSC Syslog will
parse and break out the attributes in the COOKED message,
but MSG part should pass through without change.

This policy may cause problems with syslog-sign, but
syslog-sign was not a target for SDSC syslog because I saw
little point (what can it do that BEEP security profiles
can't?) However, its probably time to review the new
version of syslog-sign.

[Rainer Gerhards]

Logged In: YES
user_id=389195

Have a look at 3195, page 17. At the bottom, there is a
sample:

<166> Oct 22 01:00:00 bomb tick[0]: BOOM!

This should be transmitted via COOKED at:

C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net'
deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:00' tag='tick'
C: ><166> Oct 22 01:00:00 bomb tick[0]: BOOM!
</entry>

However, from what I see, it would be transmitted by sdsc as:

C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net'
deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:00' tag='tick'
C: >tick[0]: BOOM!</entry>

notice the missing

<166> Oct 22 01:00:00 bomb

part. This is actually DUPLICATED according to 3195 (it is
parsed, but it is *still* in the CDATA).

Does this clarify?

Regarding what -sign can do what beep security profiles can
not: provide signatures in the stored messages that can be
reviewed after years ;) Probably this is also an issue you
should voice yourself on the IETF list...

Rainer