Thanks for your comments. I'd hoped to ignore initial conditions of any
sort by using the previous MAC value as the chain value, rather than a
sequence number which implies an origin to the sequence and thus a need
to identify the sequence as a "session", but you're right, it imposes an
additional unnecessary hash computation. Since we are compiling a list
of simple approaches to chained authentication, your recommendations can
follow the others.
Alex Brown <[EMAIL PROTECTED]> +1 617 504 8761
John Kelsey wrote:
> -----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.
And I'm definitely an amateur as a cryptographer. There are a few ugly
facts of life with syslog that are tangled up with UNIX and
TCP/IP (actually unreliable UDP datagrams) but it's basically just the
worst case log transport, with no guarantees on anything, including
tampering and falsification. If you're interested Chris Lonvik
<[EMAIL PROTECTED]> has a draft describing the basic operation of the
"protocol" at http://www.employees.org/~lonvick/draft3.txt.
> >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.
>
There is no concept of "session" in typical syslog usage, so there's
nothing obvious other than another sequence number to use as log ID.
Some small devices have a "boot count" in nonvolatile storage that
serves as an "era" identifier and this could serve as a log ID value.
But many do not, and most do not have a time of day clock. At any
rate, a log ID should have this sense of "session" or "era" whatever the
mechanism for generating it.
> 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.
>
Encryption was never in the picture that I was painting. This is really
just a band-aid for the most serious well-known vulnerabilities of
syslog; secure transport of log data should definitely use something
more robust. But it would certainly be valuable to generate a new
Z for each log "session" at both source and sink. Would the presence
of a new value of L in the stream indicate that Z had been recomputed?
>
> >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.
Thanks - noted and corrected.
> >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.)
Well, Z would now be a new secret Z(L) following your suggestion. But
yes, this is reasonable. I think the only question is whether the
notion of "session" really applies to ordinary syslog usage -- what
event causes N to be reset and L to be advanced? In small network
devices, the only reasonable events are a network management control
operation (perhaps a soft reset) or a power cycle (hard reboot).
> >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.
>
The MAC value in the "chain=" field is saved from the previous message,
not recomputed. I actually don't think there is an added computational
burden --it's just like any other nonce value. The main benefit, as
I've said, is that there is no sense of session in syslog usage that
would lead to a natural log ID value L to accompany a sequence number N,
and this approach doesn't impose one.
> >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.
>
All easier to do with sequence numbering, it's true.
> 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.)
>
For truly secure delivery a secure transport is essential. There are
several standard approaches, but the first step is moving to TCP, and
one might as well bid farewell to syslog at that point. Encryption may
also be needed for secure storage, but this would be based on the nature
of the log data and perhaps local site policy. For many uses tamper
resistance through chained authentication in the logfile would be
sufficient.
>
> 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.)
Yes, some form of error correcting encoding might be possible too, but
syslog transport is probably not worth the effort.
>
>
> - --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-----
--
Alex Brown http://www.msg.com/~abrown +1 617 504 8761
