-----BEGIN PGP SIGNED MESSAGE-----
I have a couple comments on this document. I'll point out
up front that I'm a cryptographer, but know an embarrasingly
small amount about either Unix or TCP/IP, so let me know if
I'm making dumb assumptions about something.
>Simple authentication of syslog messages for embedded
>network devices
...
>4.2 Authentication filtering enhancements
>A cryptographic hash in the message text using a secret
>shared between client and server can provide authentication,
>making it possible to filter out falsified syslog messages.
>(The shared secret string must be initialized in the
>originating device in some secure way during installation.)
We ought to discuss how to do this intelligently. For now,
suppose Z is the shared secret. If we start a new log, we
generate a unique log ID, L. We then include L in every
log message. If the source machine (logging client) has
some nonvolatile storage, it can just remember the previous
L and increment it. If the source machine doesn't have
nonvolatile memory, but can generate random numbers, L can
be a 128-bit random number.
Eventually, I think it would make sense to derive a new key
for each log created using shared secret Z. Among other
things, this would simplify adding encryption to the interim
format.
>By adding chaining of hash codes in a sequence of
>authenticated messages, missing messages can be detected and
>falsified messages can be dropped. Use of chained hash codes
>for authentication of message sequences is discussed in
>detail in [CSL98], [SAL99], and [RAL99].
>Crypto hash functions, e.g. HMAC-MD5 [RFC1321], are fast and
>small, and are often present in even the smallest network
>devices and therefore pose little additional code burden. A
>hash value can be added by the client to existing log
>message text, as an optional feature, and interpreted by a
>syslogd filter, or by a postprocessor filter.
Nitpick: HMAC-MD5 is a MAC (message authentication code);
MD5 is a cryptographic hash function.
>Nonce field within message text
>
>If more than one message with the same text occurs (as is
>common in syslog) the authentication field can have the same
>value; this makes a variety of spoofing attacks possible. To
>reduce the likelihood of messages with identical text, a
>nonrepeating nonce can be placed in plaintext in the message
>(same secret):
>
>Nov 5 14:14:54 zorilla PAM_pwdb[509]: (login) session
> opened \ for user abrown by (uid=0) nonce=941841456 \
> md5=227c40a6cde84f49bfad43c412490110
Why not specify this as a sequence number? That way, your
nonce size can be kept reasonable, and you can always detect
missing messages, and correctly reorder your messages on the
logging server side. When combined with a unique ID per
log, you get something like this:
Z = long term shared secret
L = unique log ID
N = log entry sequence number
M = raw log message
LogMessage = L,N,M,HMAC(Z,(L,N,M))
That is, the full log message is: logID, sequence number,
message, and MAC. (You can think of (L,N) as the nonce, if
you like.)
>Chained authentication
>
>The nonce may be replaced with the last MAC sent from the
>log client, making it possible to detect an insertion or gap
>in the syslog stream from a client (same secret):
>
>... Nov 5 14:14:54 zorilla PAM_pwdb[509]: (login) session
>opened \ for user abrown by (uid=0)
>chain=227c40a6cde84f49bfad43c412490110 \
>md5=a6739e57964c9dec7613d663f049c0f7 Nov 5 14:14:55 zorilla
>PAM_pwdb[509]: (login) session closed \ for user abrown
>chain=a6739e57964c9dec7613d663f049c0f7 \
>md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb ...
I don't see what this buys you. If you use a sequence
number and MAC all your log messages, you'll be able to
detect an insertion or gap, and you'll be able to
authenticate your messages. But you save the extra hash
operation.
>Each individual record can still be authenticated
>independently from all others, but also can be sequenced by
>verifying the "chain" field. The log host syslogd or filter
>must retain the previous MAC value for each log source. The
>first record from each source will be unsequenceable,
>because no prior MAC value is available. A missing or
>corrupted record or a gap can be identified but not
>recovered.
Using a sequence number here is much better. We used the
hash chain in the secure audit log design to make it easy to
verify the logfile's accuracy remotely, over a very low
bandwidth channel. (Verify that the hash chain works, then
verify the first and last records' MACs.) This application
doesn't need it.
To defend against replays, we keep track of the most
recently received sequence number, and the current log ID,
and have some limit for how long a message can reasonably be
delayed. (This can be huge, e.g. 1000 messages.) To detect
insertions or deletions, we look for sequence numbers. To
deal with out-of-order log messages, we sort them by
sequence number either when they arrive, or when they're
reviewed.
Some other areas left to discuss:
a. Encryption (We have a shared secret, we can certainly
define encryption for this in a straightforward way. But
there are still some legal hassles about this, right? Also,
we don't want to reinvent anymore of IPSec or TLS than we
have to. But don't get fooled into thinking that this is
unbearably complex, if we just want to specify one
acceptable way to do encryption.)
b. TLS (A good interim recommendation is that, if the
infrastructure exists, the log messages be sent over a TLS
connection. This won't always exist, but if it does, it's
smarter to use it than to reinvent the wheel.)
c. UDP (Can we set up a format for sending these messages
so that an implausibly large number of packets have to be
dropped to lose messages? I have some ideas on this, which
I'll write up in a separate note.)
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOYcx3CZv+/Ry/LrBAQGDXgP+JXF6WLrASxTwH1WmedyBy0I6Nhs9H4WM
f4KOg9z5Ulr8oZwzqwmSIpXrm63APH+3M7wNVh7IskI7ETHoevsVhUXF+efn03B7
wXI3Q/hkOrOGqWib2FhL0hbJxQZUDmyH2pg9kP3QifNK8dP/wkQeQW4jpp34v2Jv
lPpd5SoVI0w=
=LFE/
-----END PGP SIGNATURE-----
