Balazs Scheidler wrote:
> Comments:
>
> 3.2.5.2. Message integrity
>
> A simple MAC is less demanding than digital signatures and should be
> sufficient. At least it is sufficient for SSH and IPSEC packets.
Sufficient to insure the message has not
been altered, but not sufficient to insure
that the message is authentic. That's usually
done by signing the MAC. Though if
the stream is encrypted with a session key
negotiated by two parties that authenticated
with their public-keys/signatures, I guess you don't
really need to sign the MAC.
I'll put something in there about that.
> ---------------------------------------------------------------
>
> 4. Logging protocols should provide the
> capability to retransmit unacknowledged
> messages. Therefore also making denial of
> service attacks on log senders more
> difficult through the generation of
> excessive traffic on a particular network
> link.
>
> By choosing TCP as transport medium there are no unacked messages,
> either
> the connection is lost or all messages went through.
True, but since this doc is all about high level requirements,
we need this kind of language because we don't want
to require TCP (you can meet the requirements with TCP,
UDP, ICMP with interesting payloads, bits on a serial
line, etc.).
> There are two ways to completely avoid lost messages:
>
> 1) you block the programs sending log messages while output queues are
> full
> 2) you don't block programs, read all messages and store them in memory.
>
> Both ways leads to easy DoS, the first blocks all services, the second
> eats all your memory.
The US DOD Trusted Computing System Evaluation Criteria
(TSEC) requires that the system shut down if you can't
log security-related events, so in that context, blocking
when output queues are full is clearly the right thing to do.
I tried to word things to say that this needs to be done
for some applications, but not for all applications.
> Currently syslog-ng does as follows:
>
> * always reads incoming messages to avoid blocking services
> * stores outgoing messages in a fifo up to a given number of messages.
> If
> the fifo is full, message gets dropped.
Pretty reasonable for non TSEC type stuff.
> If you want to be absolutely sure, that no message is dropped you log to
> a local file (in addition to network logging).
And what if you run out of disk space?
Again, the TSEC is pretty clear here -
you shut down the application trying
to log the security-related messages.
And if it's the kernel logging privileged
system call usage, for example, you would
shut down the entire system.
> That's for now, it's a great start in the right direction. I'm in the
> process of adding cryptographic functionalities to syslog-ng (MAC
> protected logfiles for now), and try to wait for some protocol spec for
> inter-syslog communication. However my schedule is to provide full crypto
> functionality by May, so I'll implement a protocol on my own if nothing
> becomes
> available by then.
Have you talked to the IDWG folks? Presumably they're dealing with the
same issues.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
