file:/home/abrown/ietf/syslog-sec/abrown-draft/draft-syslog-auth.htm -- Alex Brown <[EMAIL PROTECTED]> http://www.msg.com/~abrown +1 617 504 8761Title: Simple authentication of syslog messages for embedded network devices
Simple authentication of syslog messages for embedded network devices
Alex Brown, [EMAIL PROTECTED]
Sat Oct 28 12:33:32 EDT 2000
Network logging is a security concern because it handles authentication and authorization event information and is itself a potential path for attack. The UNIX syslog service has become a de facto logging protocol for network systems, despite significant security flaws; strategies for cautious use of the service are recommended in this memo. This document is a draft of an Internet Draft recommending a Best Common Practice for use of UNIX syslog. Distribution of this memo is unlimited.
1. Introduction
1.1 Status of this Memo
This document is a draft of an Internet Draft. Distribution of this memo is unlimited.
1.2 Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
2. UNIX syslog as a de facto standard logging protocol
As a result of the close relationship between the UNIX operating system and the Internet protocols, the UNIX syslog service has become a de facto logging protocol for network systems, despite severe deficiencies as a protocol, either for a persistent storage service or for protection of critical information about device and service status. This is because the syslog service was provided initially for local event logging within a UNIX host, and only later grew into a general network log service.
(Because of this close relationship, the following description assumes a UNIX system environment. Other system environments also have implementations of syslog, notably Microsoft Windows PCs servers, and clients in network devices such as routers, switches, and firewalls.)
UNIX syslog is both an API and a very simple protocol, for persistent storage of text messages, used throughout UNIX network service software. The protocol and its security issues are described in [LOG00].
In early UNIX and Internet practice, syslog was primarily a local UNIX logging mechanism, which provided a convenient debugging and monitoring facility for software in all parts of the system -- kernel, system applications, and user applications. Logging was often carried out only to the hard-copy system console, to capture transient events leading to a system failure that would destroy the event record before it reached a file.
Syslog is now widely used in network operations to record authentication events, originating both in the authentication agents of UNIX network server applications such as login(1), su(1M), getty(1M), ftp(1) and others, and in network devices such as remote dialup access servers. It has therefore become a security feature of UNIX networks, and is often used in supporting access from user networks of non-UNIX personal computers.
As network installation size grows, and administrators are responsible for more and more system activity, forwarding of syslog messages over more than one hop is widely used to relay event records to a central system, where scripts and other offline analysis tools can be used either periodically scheduled, or interactively, to identify attack sequences. The integrity of both the syslog configuration files, as well as the syslog output logfiles, are therefore also security concerns. Resource limitations for log message traffic on the network, and especially log storage on disk, are significant security vulnerabilities, primarily due to lack of authentication, which would permit a log server to discard bogus messages.
3. Current practice
Syslog is still the most widespread and usable tool for network event logging, and it is especially useful for embedded network devices because it is a low-cost protocol that can be easily added to even the smallest devices. These devices are a major concern of this recommendation: while improved security event logging mechanisms such as Intrusion Alert Protocol [IAP00] can provide far better solutions in the long run, these mechanisms require more cryptographic resources in the originating device than an embedded device can easily afford, as well as coordinated deployment of analyzer and reporting facilities. (The smallest devices may also lack persistent storage and/or a time of day clock, both needed by many security systems.)
The following recommendations are for cautious interim use of an existing insecure syslog infrastructure, and are not intended to provide an alternative to a fully secure network logging and intrusion alert facility.
3.1 Vulnerabilities in current common pracitce
- Log files, configuration files are stored in cleartext
- Denial of service by flood of unauthorized logging exhausting disk space
- Several implementation-specific root access attacks (historical)
- No authentication of log clients whatsoever
- Cannot detect dropped log messages
- Cannot detect inserted log messages
- Cannot detect replayed log messages
3.2 Best common practice strategies for cautious use of syslog include:
- Ensure logfiles and configuration files are visible only with correct authorization: Check file permissions for all logfiles and syslog.conf at each log host.
- Provide adequate log storage to handle DOS attack by unauthorized logging: Provide syslog servers with CPU and disk capacity far exceeding normal needs.
- Control access to log hosts: Design network to limit access for udp/514 syslog, and isolate syslog regions within a network as well as inside from outside.
3.3 Basic security enhancements
- Identify sender properly at log client: Add IP address or DNS FQDN of originator to message text so it's not lost in forwarding.
- Identify known senders at each log host: Use an IP access list to permit the receiver to filter all packets not claiming to be from a valid source address, either in IP header or in message text.
3.4 Ideal security enhancement
- If possible, provide IPSEC tunnel protection for log host UDP/514 access. The remainder of this memo presumes that this is not possible.
4. Security requirements and design
A cryptographic hash as a message authentication code (MAC, e.g. HMAC-MD5) in the message text using a secret shared between client and server can provide authentication, making it possible to filter out individual falsified syslog messages. (The shared secret string must be initialized in the originating device in some secure way during installation.) However, an attacker will also attempt to suppress individual valid syslog messages.
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 MAC value can be added by the syslog client library to existing log message text, as an optional feature, and interpreted by a syslogd filter, or by a postprocessor filter. The added text impacts delivery to an unmodified server only by increasing message length.
Assuming an unprotected network environment carrying the log message stream from a log client to a log host, and a syslog infrastructure of forwarders and log hosts with no special enhancements, we must provide message string extensions that make it possible to:
- Authenticate known senders: verify that sender is who he claims to be.
- Verify known forwarders
- Verify each sender's stream for message loss, insertion and
corruption:
- Detect altered log messages
- Detect dropped log messages
- Detect inserted log messages
- Detect replayed log messages
4.1 Security design
Syslog message texts are unrestricted in content except for length (must fit in a single atomic UDP packet). To distinguish extension fields added by syslog(3) from those provided by the caller, "name=value" string pairs in the style of [ULM99] are appended to the application's message, delimited by space characters (ASCII 20). To minimize the length of the extension strings, single uppercase character name strings are used. The application message ends at the non-space character before the first such delimiter. (Neither "name" nor "value" string may contain space characters.)
The basic extension field is a Message Authentication Code (MAC) using HMAC-MD5 in the manner of [RFC2869], with ASCII hexadecimal encoding of the binary MAC value computed as follows:
M=[MAC]
where
[MAC] = HMAC-MD5-string (
concat( Leading-fields, Application-message, Attributes ),
Shared-secret
)
with the HMAC-MD5-string function returning a hexadecimal-encoded
string value corresponding to the HMAC-MD5 calculation over the
string concatenation of the argument list within parentheses, and
"Attributes" denoting the concatenation of other "name=value" string
pairs delimited by spaces, supplied by the syslog(3) implementation.
The Shared-secret string of sixteen binary octets, which may be
selected as an ASCII key string, is never transmitted between client
and host; it has the role of key as described in [HMAC]. An
Application-message string that consists of or contains such
"name=value" string pairs must be contained within quotation marks,
supplied by the syslog(3) implementation if necessary.
The syslog client and host implementors must agree on leading string fields in the transmitted and received message, normally (in BSD) a time and a hostname field, and a program name field. If any additional leading fields are provided by the syslog(3) client implementation, the Application-message string must again be contained within quotation marks, supplied by the syslog(3) implementation if necessary. These Leading-fields are all space-delimited and concatenated with the Application-message string for the purposes of computing the HMAC-MD5-string function value.
The "M=[MAC]" pair is not concatenated to the Attributes string, and must be the last Attribute pair in the message. This pair is required; others are optional as described below.
Other parameters used by log client and log host include the shared secret string, and two 32 bit integers: a message counter l, and a log session identifier h.
The following extensions are defined:
- "S=fqdn]" where [fqdn] is the ASCII string representation of the fully-qualified domain name or IP address of the sender of the message
- "H=[h]" where [h] is an ASCII string representation of the hexadecimal value of h
- "L=[l]" where [l] is an ASCII string representation of the hexadecimal value of l
- "M=[MAC]", described above
- "C=[MAC]", a chained authenticator as described below
To calculate the HMAC-MD5-string parameter value, the Leading-fields (delimited by a space) and Application-message are concatenated with the Shared-secret octet string, followed by the Attributes, the concatenation of these extension pairs. After calculation the "M=[MAC]" string is appended (delimited by a space) to make up the final message string of the syslog message.
The syslog session ID h is intended to provide an identifier for sequences of values of l incremented from its agreed initial value at the start of logging, zero by default. The message counter l is then reset to this initial value when the log client reboots or otherwise loses its current state, but the session ID must take on a nearly unique value, either a time-of-day clock value, or a reboot counter, or a value established by a running hash initialization procedure.
Running hash session ID initialization
(John Kelsey)
Not every device has any persistent state (like a clock, reboot counter, or flash memory) across reboot sessions. The question is then how to get a unique H value on those machines. If we had a random number generator on the machine, we could just generate H randomly; a 128-bit H would more-or-less guarantee, in practice, that we'd never see two reboot sessions with the same H value from the same device. But a device with no clock, persistent memory or reboot counter is unlikely to have a good random number generator, and a crappy one (like an LCG based on a 32 bit seed) won't work for this application.
My general solution to this is to use an initial value of H==0, which is defined to be a special ``null'' reboot session identifier, and then to keep a running hash of messages sent, and eventually, to generate a new H from it. Thus, most messages from these very low-end devices will have a unique reboot session ID, but the first few messages from each reboot session will have H==0, and so won't be able to be placed in a known sequence with certainty.
To do this, we start with some assumption about how many messages, N, it takes before we are all but certain that this sequence of messages is unique among reboot sessions. We then take the hash of those N messages, and use it as the reboot session ID. Included in this hash may be any number of optional inputs taken from the device's internal state. If there's an internal clock which is reset each time the system reboots, then hashing in the value of that internal clock along with each message is a good idea.
The idea here is to use the messages themselves to generate H. There's no authentication going on from this, but using a hash function here ensures that if there's even one bit changed in one message, we get a different H.
The whole proposal thus looks like this:
a. At reboot time, if we can, we generate a guaranteed-unique H. The first couple bits in H specify what other properties it has, such as whether H includes a timestamp, reboot counter, etc. There's nothing about H that requires any secrecy or unpredictability, we just want to make sure it's always unique.
If we can't generate a guaranteed-unique H, we set H = 0, and start accumulating the running hash of messages for the first N messages.
In either case, we set L = 0.
b. Each time we send a message, we increment L. The message we send is
message-text,H,L,M
where M = the MAC of (H,L,message-text).
If H == 0, then we also keep a running hash of messages sent so far.
If H == 0 and L == N, we compute the final hash value for all those messages we've hashed together, and use it for our new H value. We keep using the same L value.
c. When we receive a message, we verify the MAC, and then look at H and L to see whether they're consistent with what we've been receiving lately. Whenever H changes, we consider that a discontinuity--we know how to arrange messages with the same H value, but not necessarily how to arrange messages with different H values.
The first couple bits of H signal what kind of reboot session ID this is: 00 means it's random, 01 means it's based on a clock, 10 means it's based on some kind of counter.
Simplified unsequenced hash chain
(Alex Brown)
The "H=[h] L=[l]" sequence numbering of the above scheme is a discriminator ensuring that any two computations of HMAC-MD5-string() with the same Shared-secret will very rarely have the same data. Such a discriminator is called a "nonce". Without it, if more than one message with the same text occurs (as is common in syslog) the "M=[MAC]" field could have the same value; this makes a variety of spoofing attacks possible.
Verification at the log host of the sequence of messages from a log client requires storing substantial history of past log activity from each client, and may require substantial memory for sorting of log records by (h,l) keys.
In limited resource clients and hosts, real-time computation of the verification can be simplified by omitting the "H=[h] L=[l]" sequence number and instead using the MAC chain attribute "C=[MAC]" as a nonce, where [MAC] is the last previous MAC sent from the log client, so that only the shared secret and that last previous MAC value need to be stored. Use of chained hash codes for authentication of message sequences is discussed in detail in [PEO95], [CSL98], [PEO98], [SAL99], and [RAL99].
Each individual record can still be authenticated independently from all others, but also can be sequenced by verifying the "chain" field. The first record from each source will be unsequenceable, because no previous MAC value is available; however an initial "previous" MAC value can be agreed upon between client and server during security initialization.
This form of authentication provides significantly reduced information in the event of failure or attack. Successful authentication states only that the current log message originated with its declared sender, and that the last received message was the last sent. Accidental reordering in transmission is interpreted as a gap. A missing or corrupted record or a gap can be identified but not recovered. Short segments separated by short gaps cannot be reliably sequenced. Without provision for prompt secure change of the Shared-secret value, the scheme is vulnerable to replay attacks. This approach is useful only for light security applications.
4.2 Fulfillment of requirements
Authenticate known senders
Calculation of the MAC value by the same HMAC-MD5-string() procedure at the destination log host, will verify that sender and receiver both have the same value of Shared-secret. Since this is not disclosed in transmission and cannot be computed from the MAC value, this shared knowledge authenticates sender to receiver.
Verify known forwarders
A forwarder may enclose a received message in quotation marks and resend it with its own Attributes and MAC value. Any quotation marks within the message must be escaped with backslash. Neither enclosing quotation marks or escape backslash characters enter into the MAC calculation.
Detecting altered log messages
Any alteration of a message text will result in an altered MAC value.
Detect dropped log messages
Sequence number gaps identify dropped messages.
Detect inserted log messages
Sequence number discontinuities identify insertions.
Detect replayed log messages
The use of a nearly-unique session ID value prevents undetected replay of log messages.
5. Recommended improved practice
Recommended improved practies include:
- Where the log host, log client and network can support it, use IPSEC to protect the syslog message stream.
- In an unprotected syslog environment where the resource-constrained client implementation can be modified, add sequenced MAC authentication parameters as described above.
- Add filtering of messages to syslog server implementations, based on sequenced MAC in message text, added by syslog client implementation.
- Where client and host resources are very limited, and security requirements are light, an unsequenced chain may be used as an alternative.
5.1 Limitations
These practices provide authentication for the syslog mechanism but are intended only for cautious interim use of an existing insecure syslog infrastructure, and are not intended to provide an alternative to a fully secure network logging and intrusion alert facility.
6. Security Considerations
This document is primarily concerned with security issues in network logging. Other related issues in UNIX system and network administration are not within its scope.
7. Acknowlegements
The methods described here are a simplified use of chained hash codes for authentication of message sequences, as discussed in detail in [PEO95], [CSL98], [PEO98], [SAL99], and [RAL99]. Thanks are due to John Kelsey, Ivan Arce, Herve Schauer, Darren Reed, and Chris Lonvick, who contributed comments.
8. References
[LOG00]
C. Lonvick, "Syslog Protocol" (draft).
The Internet Society, July 2000. Available from
http://www.employees.org/~lonvick/draft3.txt
[IAP00]
D. Gupta, "Intrusion Alert Protocol - IAP"
The Internet Society, March 2000. Available from
ftp.ietf.org/internet-drafts/draft-ietf-idwg-iap-01.txt
[ULM99]
J. Abela and T. Debeaupis, "Universal Format for Logger Messages."
The Internet Society, May 1999. Available from
ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt.
[PEO95]
Emiliano Kargieman and Ariel Futoransky, "PEO y VCR - Dos
protocolos simples", 25 Jornadas Argentinas de Informatica e
Investigacion Operativa, July 1995.
http://www.core-sdi.com/papers/vcr_peo.pdf
[PEO98]
Emiliano Kargieman and Ariel Futoransky, "VCR and PEO
Revised", October 1998.
http://www.core-sdi.com/papers/peo.pdf
[CSL98]
B. Schneier and J. Kelsey, "Cryptographic Support for Secure
Logs on Untrusted Machines", The Seventh USENIX Security
Symposium Proceedings, USENIX Press, January 1998, pp. 53-62.
http://www.counterpane.com/secure-logs.html
[SAL99]
B. Schneier and J. Kelsey, "Secure Audit Logs to Support
Computer Forensics", ACM Transactions on Information and
System Security, v. 1, n. 3, 1999.
http://www.counterpane.com/audit-logs.html
[RAL99]
B. Schneier and J. Kelsey, "Minimizing Bandwidth for Remote
Access to Cryptographically Protected Audit Logs", Second
International Workshop on the Recent Advances in Intrusion
Detection (RAID '99), September 1999.
http://www.counterpane.com/auditlog2.html
[MD5]
R. Rivest, "The MD5 Message-Digest Algorithm".
The Internet Society, April 1992. Available from
ftp://ftp.isi.edu/in-notes/rfc1321.txt
[HMAC]
Krawczyk, H., Bellare, M., and R. Canetti,
"HMAC: Keyed-Hashing for Message Authentication",
RFC 2104, February 1997.
[RFC2869]
Rigney, C., Willats, W., and Calhoun, P.,
"RADIUS Extensions", RFC 2869, June 2000.
9. Author's Address
Alex Brown http://www.msg.com/~abrown Phone: +1 617 504 8761 EMail: [EMAIL PROTECTED]
Simple authentication of syslog messages for embedded net-
work devices
Alex Brown, [EMAIL PROTECTED]
Sat Oct 28 12:33:32 EDT 2000
Network logging is a security concern because it handles authentica-
tion and authorization event information and is itself a potential
path for attack. The UNIX syslog service has become a de facto log-
ging protocol for network systems, despite significant security flaws;
strategies for cautious use of the service are recommended in this
memo. This document is a draft of an Internet Draft recommending a
Best Common Practice for use of UNIX syslog. Distribution of this
memo is unlimited.
______________________________________________________________________
Table of Contents
1. Introduction
1.1 Status of this Memo
1.2 Copyright Notice
2. UNIX syslog as a de facto standard logging protocol
3. Current practice
3.1 Vulnerabilities in current common pracitce
3.2 Best common practice strategies for cautious use of syslog include:
3.3 Basic security enhancements
3.4 Ideal security enhancement
4. Security requirements and design
4.1 Security design
4.1.1 Running hash session ID initialization
4.1.2 Simplified unsequenced hash chain
4.2 Fulfillment of requirements
4.2.1 Authenticate known senders
4.2.2 Verify known forwarders
4.2.3 Detecting altered log messages
4.2.4 Detect dropped log messages
4.2.5 Detect inserted log messages
4.2.6 Detect replayed log messages
5. Recommended improved practice
5.1 Limitations
6. Security Considerations
7. Acknowlegements
8. References
9. Author's Address
______________________________________________________________________
1.
Introduction
1.1.
Status of this Memo
This document is a draft of an Internet Draft. Distribution of this
memo is unlimited.
1.2.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
2. UNIX syslog as a de facto standard logging protocol
As a result of the close relationship between the UNIX operating
system and the Internet protocols, the UNIX syslog service has become
a de facto logging protocol for network systems, despite severe
deficiencies as a protocol, either for a persistent storage service or
for protection of critical information about device and service
status. This is because the syslog service was provided initially for
local event logging within a UNIX host, and only later grew into a
general network log service.
(Because of this close relationship, the following description assumes
a UNIX system environment. Other system environments also have
implementations of syslog, notably Microsoft Windows PCs servers, and
clients in network devices such as routers, switches, and firewalls.)
UNIX syslog is both an API and a very simple protocol, for persistent
storage of text messages, used throughout UNIX network service
software. The protocol and its security issues are described in
[LOG00].
In early UNIX and Internet practice, syslog was primarily a local UNIX
logging mechanism, which provided a convenient debugging and
monitoring facility for software in all parts of the system -- kernel,
system applications, and user applications. Logging was often carried
out only to the hard-copy system console, to capture transient events
leading to a system failure that would destroy the event record before
it reached a file.
Syslog is now widely used in network operations to record
authentication events, originating both in the authentication agents
of UNIX network server applications such as login(1), su(1M),
getty(1M), ftp(1) and others, and in network devices such as remote
dialup access servers. It has therefore become a security feature of
UNIX networks, and is often used in supporting access from user
networks of non-UNIX personal computers.
As network installation size grows, and administrators are responsible
for more and more system activity, forwarding of syslog messages over
more than one hop is widely used to relay event records to a central
system, where scripts and other offline analysis tools can be used
either periodically scheduled, or interactively, to identify attack
sequences. The integrity of both the syslog configuration files, as
well as the syslog output logfiles, are therefore also security
concerns. Resource limitations for log message traffic on the
network, and especially log storage on disk, are significant security
vulnerabilities, primarily due to lack of authentication, which would
permit a log server to discard bogus messages.
3. Current practice
Syslog is still the most widespread and usable tool for network event
logging, and it is especially useful for embedded network devices
because it is a low-cost protocol that can be easily added to even the
smallest devices. These devices are a major concern of this
recommendation: while improved security event logging mechanisms such
as Intrusion Alert Protocol [IAP00] can provide far better solutions
in the long run, these mechanisms require more cryptographic resources
in the originating device than an embedded device can easily afford,
as well as coordinated deployment of analyzer and reporting
facilities. (The smallest devices may also lack persistent storage
and/or a time of day clock, both needed by many security systems.)
The following recommendations are for cautious interim use of an
existing insecure syslog infrastructure, and are not intended to
provide an alternative to a fully secure network logging and intrusion
alert facility.
3.1.
Vulnerabilities in current common pracitce
o Log files, configuration files are stored in cleartext
o Denial of service by flood of unauthorized logging exhausting disk
space
o Several implementation-specific root access attacks (historical)
o No authentication of log clients whatsoever
o Cannot detect dropped log messages
o Cannot detect inserted log messages
o Cannot detect replayed log messages
3.2.
Best common practice strategies for cautious use of syslog include:
o Ensure logfiles and configuration files are visible only with
correct authorization: Check file permissions for all logfiles and
syslog.conf at each log host.
o Provide adequate log storage to handle DOS attack by unauthorized
logging: Provide syslog servers with CPU and disk capacity far
exceeding normal needs.
o Control access to log hosts: Design network to limit access for
udp/514 syslog, and isolate syslog regions within a network as well
as inside from outside.
3.3.
Basic security enhancements
o Identify sender properly at log client: Add IP address or DNS FQDN
of originator to message text so it's not lost in forwarding.
o Identify known senders at each log host: Use an IP access list to
permit the receiver to filter all packets not claiming to be from a
valid source address, either in IP header or in message text.
3.4.
Ideal security enhancement
o If possible, provide IPSEC tunnel protection for log host UDP/514
access. The remainder of this memo presumes that this is not
possible.
4. Security requirements and design
A cryptographic hash as a message authentication code (MAC, e.g. HMAC-
MD5) in the message text using a secret shared between client and
server can provide authentication, making it possible to filter out
individual falsified syslog messages. (The shared secret string must
be initialized in the originating device in some secure way during
installation.) However, an attacker will also attempt to suppress
individual valid syslog messages.
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 MAC value can be
added by the syslog client library to existing log message text, as an
optional feature, and interpreted by a syslogd filter, or by a
postprocessor filter. The added text impacts delivery to an
unmodified server only by increasing message length.
Assuming an unprotected network environment carrying the log message
stream from a log client to a log host, and a syslog infrastructure of
forwarders and log hosts with no special enhancements, we must provide
message string extensions that make it possible to:
o Authenticate known senders: verify that sender is who he claims to
be.
o Verify known forwarders
o Verify each sender's stream for message loss, insertion and
corruption:
o Detect altered log messages
o Detect dropped log messages
o Detect inserted log messages
o Detect replayed log messages
4.1.
Security design
Syslog message texts are unrestricted in content except for length
(must fit in a single atomic UDP packet). To distinguish extension
fields added by syslog(3) from those provided by the caller,
"name=value" string pairs in the style of [ULM99] are appended to the
application's message, delimited by space characters (ASCII 20). To
minimize the length of the extension strings, single uppercase
character name strings are used. The application message ends at the
non-space character before the first such delimiter. (Neither "name"
nor "value" string may contain space characters.)
The basic extension field is a Message Authentication Code (MAC) using
HMAC-MD5 in the manner of [RFC2869], with ASCII hexadecimal encoding
of the binary MAC value computed as follows:
M=[MAC]
where
[MAC] = HMAC-MD5-string (
concat( Leading-fields, Application-message, Attributes ),
Shared-secret
)
with the HMAC-MD5-string function returning a hexadecimal-encoded
string value corresponding to the HMAC-MD5 calculation over the string
concatenation of the argument list within parentheses, and
"Attributes" denoting the concatenation of other "name=value" string
pairs delimited by spaces, supplied by the syslog(3) implementation.
The Shared-secret string of sixteen binary octets, which may be
selected as an ASCII key string, is never transmitted between client
and host; it has the role of key as described in [HMAC]. An Applica-
tion-message string that consists of or contains such "name=value"
string pairs must be contained within quotation marks, supplied by the
syslog(3) implementation if necessary.
The syslog client and host implementors must agree on leading string
fields in the transmitted and received message, normally (in BSD) a
time and a hostname field, and a program name field. If any
additional leading fields are provided by the syslog(3) client
implementation, the Application-message string must again be contained
within quotation marks, supplied by the syslog(3) implementation if
necessary. These Leading-fields are all space-delimited and
concatenated with the Application-message string for the purposes of
computing the HMAC-MD5-string function value.
The "M=[MAC]" pair is not concatenated to the Attributes string, and
must be the last Attribute pair in the message. This pair is
required; others are optional as described below.
Other parameters used by log client and log host include the shared
secret string, and two 32 bit integers: a message counter l, and a log
session identifier h.
The following extensions are defined:
o "S=fqdn]" where [fqdn] is the ASCII string representation of the
fully-qualified domain name or IP address of the sender of the
message
o "H=[h]" where [h] is an ASCII string representation of the
hexadecimal value of h
o "L=[l]" where [l] is an ASCII string representation of the
hexadecimal value of l
o "M=[MAC]", described above
o "C=[MAC]", a chained authenticator as described below
To calculate the HMAC-MD5-string parameter value, the Leading-fields
(delimited by a space) and Application-message are concatenated with
the Shared-secret octet string, followed by the Attributes, the
concatenation of these extension pairs. After calculation the
"M=[MAC]" string is appended (delimited by a space) to make up the
final message string of the syslog message.
The syslog session ID h is intended to provide an identifier for
sequences of values of l incremented from its agreed initial value at
the start of logging, zero by default. The message counter l is then
reset to this initial value when the log client reboots or otherwise
loses its current state, but the session ID must take on a nearly
unique value, either a time-of-day clock value, or a reboot counter,
or a value established by a running hash initialization procedure.
4.1.1. Running hash session ID initialization
(John Kelsey)
Not every device has any persistent state (like a clock, reboot
counter, or flash memory) across reboot sessions. The question is
then how to get a unique H value on those machines. If we had a
random number generator on the machine, we could just generate H
randomly; a 128-bit H would more-or-less guarantee, in practice, that
we'd never see two reboot sessions with the same H value from the same
device. But a device with no clock, persistent memory or reboot
counter is unlikely to have a good random number generator, and a
crappy one (like an LCG based on a 32 bit seed) won't work for this
application.
My general solution to this is to use an initial value of H==0, which
is defined to be a special ``null'' reboot session identifier, and
then to keep a running hash of messages sent, and eventually, to
generate a new H from it. Thus, most messages from these very low-end
devices will have a unique reboot session ID, but the first few
messages from each reboot session will have H==0, and so won't be able
to be placed in a known sequence with certainty.
To do this, we start with some assumption about how many messages, N,
it takes before we are all but certain that this sequence of messages
is unique among reboot sessions. We then take the hash of those N
messages, and use it as the reboot session ID. Included in this hash
may be any number of optional inputs taken from the device's internal
state. If there's an internal clock which is reset each time the
system reboots, then hashing in the value of that internal clock along
with each message is a good idea.
The idea here is to use the messages themselves to generate H.
There's no authentication going on from this, but using a hash
function here ensures that if there's even one bit changed in one
message, we get a different H.
The whole proposal thus looks like this:
a. At reboot time, if we can, we generate a guaranteed-unique H. The
first couple bits in H specify what other properties it has, such as
whether H includes a timestamp, reboot counter, etc. There's nothing
about H that requires any secrecy or unpredictability, we just want to
make sure it's always unique.
If we can't generate a guaranteed-unique H, we set H = 0, and start
accumulating the running hash of messages for the first N messages.
In either case, we set L = 0.
b. Each time we send a message, we increment L. The message we send
is
message-text,H,L,M
where M = the MAC of (H,L,message-text).
If H == 0, then we also keep a running hash of messages sent so far.
If H == 0 and L == N, we compute the final hash value for all those
messages we've hashed together, and use it for our new H value. We
keep using the same L value.
c. When we receive a message, we verify the MAC, and then look at H
and L to see whether they're consistent with what we've been receiving
lately. Whenever H changes, we consider that a discontinuity--we know
how to arrange messages with the same H value, but not necessarily how
to arrange messages with different H values.
The first couple bits of H signal what kind of reboot session ID this
is: 00 means it's random, 01 means it's based on a clock, 10 means
it's based on some kind of counter.
4.1.2. Simplified unsequenced hash chain
(Alex Brown)
The "H=[h] L=[l]" sequence numbering of the above scheme is a
discriminator ensuring that any two computations of HMAC-MD5-string()
with the same Shared-secret will very rarely have the same data. Such
a discriminator is called a "nonce". Without it, if more than one
message with the same text occurs (as is common in syslog) the
"M=[MAC]" field could have the same value; this makes a variety of
spoofing attacks possible.
Verification at the log host of the sequence of messages from a log
client requires storing substantial history of past log activity from
each client, and may require substantial memory for sorting of log
records by (h,l) keys.
In limited resource clients and hosts, real-time computation of the
verification can be simplified by omitting the "H=[h] L=[l]" sequence
number and instead using the MAC chain attribute "C=[MAC]" as a nonce,
where [MAC] is the last previous MAC sent from the log client, so that
only the shared secret and that last previous MAC value need to be
stored. Use of chained hash codes for authentication of message
sequences is discussed in detail in [PEO95], [CSL98], [PEO98],
[SAL99], and [RAL99].
Each individual record can still be authenticated independently from
all others, but also can be sequenced by verifying the "chain" field.
The first record from each source will be unsequenceable, because no
previous MAC value is available; however an initial "previous" MAC
value can be agreed upon between client and server during security
initialization.
This form of authentication provides significantly reduced information
in the event of failure or attack. Successful authentication states
only that the current log message originated with its declared sender,
and that the last received message was the last sent. Accidental
reordering in transmission is interpreted as a gap. A missing or
corrupted record or a gap can be identified but not recovered. Short
segments separated by short gaps cannot be reliably sequenced.
Without provision for prompt secure change of the Shared-secret value,
the scheme is vulnerable to replay attacks. This approach is useful
only for light security applications.
4.2.
Fulfillment of requirements
4.2.1.
Authenticate known senders
Calculation of the MAC value by the same HMAC-MD5-string() procedure
at the destination log host, will verify that sender and receiver both
have the same value of Shared-secret. Since this is not disclosed in
transmission and cannot be computed from the MAC value, this shared
knowledge authenticates sender to receiver.
4.2.2.
Verify known forwarders
A forwarder may enclose a received message in quotation marks and
resend it with its own Attributes and MAC value. Any quotation marks
within the message must be escaped with backslash. Neither enclosing
quotation marks or escape backslash characters enter into the MAC
calculation.
4.2.3.
Detecting altered log messages
Any alteration of a message text will result in an altered MAC value.
4.2.4.
Detect dropped log messages
Sequence number gaps identify dropped messages.
4.2.5.
Detect inserted log messages
Sequence number discontinuities identify insertions.
4.2.6.
Detect replayed log messages
The use of a nearly-unique session ID value prevents undetected replay
of log messages.
5. Recommended improved practice
Recommended improved practies include:
o Where the log host, log client and network can support it, use
IPSEC to protect the syslog message stream.
o In an unprotected syslog environment where the resource-constrained
client implementation can be modified, add sequenced MAC
authentication parameters as described above.
o Add filtering of messages to syslog server implementations, based
on sequenced MAC in message text, added by syslog client
implementation.
o Where client and host resources are very limited, and security
requirements are light, an unsequenced chain may be used as an
alternative.
5.1.
Limitations
These practices provide authentication for the syslog mechanism but
are intended only for cautious interim use of an existing insecure
syslog infrastructure, and are not intended to provide an alternative
to a fully secure network logging and intrusion alert facility.
6. Security Considerations
This document is primarily concerned with security issues in network
logging. Other related issues in UNIX system and network
administration are not within its scope.
7. Acknowlegements
The methods described here are a simplified use of chained hash codes
for authentication of message sequences, as discussed in detail in
[PEO95], [CSL98], [PEO98], [SAL99], and [RAL99]. Thanks are due to
John Kelsey, Ivan Arce, Herve Schauer, Darren Reed, and Chris Lonvick,
who contributed comments.
8. References
[LOG00]
C. Lonvick, "Syslog Protocol" (draft).
The Internet Society, July 2000. Available from
http://www.employees.org/~lonvick/draft3.txt
[IAP00]
D. Gupta, "Intrusion Alert Protocol - IAP"
The Internet Society, March 2000. Available from
ftp.ietf.org/internet-drafts/draft-ietf-idwg-iap-01.txt
[ULM99]
J. Abela and T. Debeaupis, "Universal Format for Logger Messages."
The Internet Society, May 1999. Available from
ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt.
[PEO95]
Emiliano Kargieman and Ariel Futoransky, "PEO y VCR - Dos
protocolos simples", 25 Jornadas Argentinas de Informatica e
Investigacion Operativa, July 1995.
http://www.core-sdi.com/papers/vcr_peo.pdf
[PEO98]
Emiliano Kargieman and Ariel Futoransky, "VCR and PEO
Revised", October 1998.
http://www.core-sdi.com/papers/peo.pdf
[CSL98]
B. Schneier and J. Kelsey, "Cryptographic Support for Secure
Logs on Untrusted Machines", The Seventh USENIX Security
Symposium Proceedings, USENIX Press, January 1998, pp. 53-62.
http://www.counterpane.com/secure-logs.html
[SAL99]
B. Schneier and J. Kelsey, "Secure Audit Logs to Support
Computer Forensics", ACM Transactions on Information and
System Security, v. 1, n. 3, 1999.
http://www.counterpane.com/audit-logs.html
[RAL99]
B. Schneier and J. Kelsey, "Minimizing Bandwidth for Remote
Access to Cryptographically Protected Audit Logs", Second
International Workshop on the Recent Advances in Intrusion
Detection (RAID '99), September 1999.
http://www.counterpane.com/auditlog2.html
[MD5]
R. Rivest, "The MD5 Message-Digest Algorithm".
The Internet Society, April 1992. Available from
ftp://ftp.isi.edu/in-notes/rfc1321.txt
[HMAC]
Krawczyk, H., Bellare, M., and R. Canetti,
"HMAC: Keyed-Hashing for Message Authentication",
RFC 2104, February 1997.
[RFC2869]
Rigney, C., Willats, W., and Calhoun, P.,
"RADIUS Extensions", RFC 2869, June 2000.
9. Author's Address
Alex Brown
http://www.msg.com/~abrown
Phone: +1 617 504 8761
EMail: [EMAIL PROTECTED]
