On Sun, Mar 05, 2000 at 05:03:44AM -0500, Chris Calabrese wrote:
> 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.
No encryption is needed to provide authenticity. After the keyexchange you
have a shared secret key, then each MAC (=message authenticity code) is
calculated:
MAC = H(message || secret)
where H is a one-way hash function like md5 or sha1. Since the secret is
known on both sides if and only if the authenticity of the other side is
already established, the MAC itself ensures authenticity as well. Digitally
signing the MAC with an algorithm like RSA or DSA is a waste of resources,
and AFAIK IPsec doesn't do this either. SECSH (or ssh2) doesn't use digital
signing, that's for sure (I'm among the lsh developers, a GPLd secsh
implementation).
SSH uses a diffie-helmann keyexchange at startup, where the keyexchange
packets are signed by the hostkey. The resulting shared secret is then used
two derive several keys:
1) session key to encrypt communication (client to server, server to client)
3) encryption IV (client to server, server to client)
2) MAC key (client to server, server to client)
For more info check out draft-ietf-secsh-transport-*.txt
> > ---------------------------------------------------------------
> >
> > 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.).
Hmm... and do we want to define an UDP based protocol having this capability?
or we just state that in environments with this requirement TCP transport
has to be used. I agree in the second case.
>
> > 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.
Hmmm... maybe I'll add some kind of flow control into syslog-ng, but that
will be optional, just to conform with TCSEC.
> > 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.
not yet.
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
url: http://www.balabit.hu/pgpkey.txt
