This reflects the feedback I've received on the XML proposal
so far. But I have not yet resolved the syntax issue
described earlier today. Feedback is most welcome.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
INTERNET DRAFT C. Calabrese
Expires: ??? Merck-Medco Managed Care, L.L.C.
<xml-log.html> 28 Oct. 1999
XML for Secure System Logs
----------
Status of this Memo
This document is rough sketch/draft Internet Request for Comments for the Internet
Community, and requests discussion and suggestions for improvement. Distribution of
this memo is unlimited.
----------
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
----------
Table of Contents
* Overview
* Specification
* Implementation Considerations
* Discussion
* Security Considerations
* References
* Author's Address
----------
1. Overview
One of the most important aspects of system, application, and security administration
is event logging. Such logging involves capturing information about important events,
possibly transmitting that information to a centralized logging facility,
timestamping/filtering/manipulating the information, recording the information to
persistent storage, and finally filtering, retrieval and analysis by events by an
off-line program or person.
This memo concerns itself with the ability to the presentation layer and application
layer issues of expressing logging information transport over a network or for
persistent storage while maintaining ensuring log privacy and authenticity.
In particular, this memo introduces Extensible Markup Language (XML) encodings to deal
with the problem of expressing log entries as well as authentication and encryption of
those entries [W3C98].
----------
2. Specification
The scheme employed for basic log entries is, for the most part, an "XML-ization" of
the Universal Format for Logger Messages (ULM) [ULM99].
Privacy and authenticity for log entries is handled by "wrapping" the basic log
entries in privacy and authenticity XML elements much the same way that network
traffic may be wrapped in IPsec, SSL, TLS, etc. This would most likely be done using
standard for XML digital signatures being worked on by the IETF and W3C [W3C99].
However, an alternative scheme could be developed if this standard turns out not to
meet the needs of secure system logging.
Finally, intermediate-hop and final-hop hosts may put their own mark on the logs by
putting their own privacy, authenticity, or timestamp wrappers around the messages
they receive.
2.1. XML Specification
Here is the full XML specification (Note: This actually isn't complete XML at this
point in the draft):
2.1.1. Basic Log Entry
<!ELEMENT log:ENTRY (log:ENTRY)*>
<!ATTLIST log:ENTRY
log:SEV log:Severity_Type #IMPLIED
log:PROG CDATA #IMPLIED
log:PROG.INSTANCE CDATA #IMPLIED
log:EVENT.TYPE log:Event_Type_Enumeration #IMPLIED
log:XML:LANG LangCode "EN"
log:DUR Seconds.Decimal #IMPLIED
log:SRC.ADDR log:Address_Format #IMPLIED
log:SRC.PROT log:Protocol_Format #IMPLIED
log:SRC.FQDN CDATA #IMPLIED
log:SRC.NAME CDATA #IMPLIED
log:SRC.USR CDATA #IMPLIED
log:SRC.MAIL CDATA #IMPLIED
log:DST.ADDR log:Address_Format #IMPLIED
log:DST.PROT log:Protocol_Format #IMPLIED
log:DST.FQDN CDATA #IMPLIED
log:DST.NAME CDATA #IMPLIED
log:DST.USR CDATA #IMPLIED
log:DST.MAIL CDATA #IMPLIED
log:REL.IN.ADDR log:Address_Format #IMPLIED
log:REL.IN.PROT log:Protocol_Format #IMPLIED
log:REL.IN.FQDN CDATA #IMPLIED
log:REL.IN.NAME CDATA #IMPLIED
log:REL.IN.USR CDATA #IMPLIED
log:REL.IN.MAIL CDATA #IMPLIED
log:REL.OUT.ADDR log:Address_Format #IMPLIED
log:REL.OUT.PROT log:Protocol_Format #IMPLIED
log:REL.OUT.FQDN CDATA #IMPLIED
log:REL.OUT.NAME CDATA #IMPLIED
log:REL.OUT.USR CDATA #IMPLIED
log:REL.OUT.MAIL CDATA #IMPLIED
log:VOL Integer #IMPLIED
log:VOL.SENT Integer #IMPLIED
log:VOL.RCVD Integer #IMPLIED
log:CNT Integer #IMPLIED
log:CNT.SENT Integer #IMPLIED
log:CNT.RCVD Integer #IMPLIED
log:PROG.FILE CDATA #IMPLIED
log:PROG.LINE Integer #IMPLIED
log:TTY CDATA #IMPLIED
log:DOC CDATA #IMPLIED
log:CMD CDATA #IMPLIED
log:MSG CDATA #IMPLIED
>
2.1.2. Receiving Identifiers
<!ELEMENT log:RCVD ALL>
<!ATTLIST log:RCVD
log:HOST CDATA #REQUIRED
log:DATE ISO.8601:1998_Date_Format #IMPLIED
log:SEQ Integer #IMPLIED
>
2.1.3. Data Types
<!NOTATION log:Severity_Type ('0'|'1'|...|'99')> <!NOTATION ISO.8601:1998_Date_Format
(YYYY '-' MM '-' DD 'T' hh ':' mm [':' ss ['.' f+]]('+' | '-') zzzz)> <!NOTATION
log:Event_Type_Enumeration ('AUTH.FAIL'|'AUTH.SUCCESS'|'PROG.FAIL'|'PROG.START'|...)>
<!NOTATION Seconds.Decimal ...> <!NOTATION log:Address_Format (IPv4_Address
|IPv_Address|...)> <!NOTATION IPv4_Address dotted-decimal notation> <!NOTATION
IPv6_Address hex notation> <!NOTATION log:Protocol_Format
((('IP'('/UDP'|'/TCP'|...)*)|IPX|...)(/CDATA)*)> <!NOTATION
sec:Signature_Type_Enumeration ('RSA'|'X.509'|'SHARED_SECRET')> <!NOTATION
sec:Hash_Type_Enumeration ('MD5'|'SHA-1')>
2.2. Explanation
2.2.1. Basic Log Entry
The log:ENTRY element contains information generated by the original process
generating the log entry.
2.2.1.1. Attributes
log:SEV
Severity of the event as an integer in the space 0..99, with 0 as the lowest severity.
Although not strictly required by the XML schema, it is strongly recommended that this
attribute be defined in every log entry. Note: A future draft of this memo should
contain a standard mapping from syslog and SNMP severity levels into the 0..99 space
of log:SEV.
log:PROG
Identifier for the program generating the event. Can either be a simple name
("Sendmail"), or a hierarchy identifying the program and it's facility
("Mail/MTA/Sendmail", "Audit/Tripwire", "Kernel/FS/Buffer_Cache"). Although not
strictly required by the XML schema, it is strongly recommended that this attribute be
defined in every log entry. Note: A future draft of this memo should specify standard
facility hierarchies.
log:PROG.INSTANCE
Identifies which instance of the program generated the event. On a Unix system this
would by the process identification (PID) or the PID plus the thread identifier for
multi-threaded processes ("2207.3"). Although not strictly required by the XML schema,
it is strongly recommended that this attribute be defined in every log entry.
log:EVENT.TYPE
Gives a further taxonomy of the type of event that occurred. Allowed values given
under log:Event_Type_Enumeration.
XML:LANG
The language used for any textual messages in the standard XML LangCode format
[W3C98].
log:DUR
Duration of the event being logged in seconds.
log:SRC.ADDR, log:SRC.PROT, log:SRC.FQDN, log:SRC.NAME, log:SRC.USR, log:SRC.MAIL
For events representing network traffic, these attributes represent information about
the source of the traffic. Respectively, they are the network source address in
log:Address_Format, the network protocols/ports used in log:Protocol_Format
("IP/TCP/25/ESMTP", "IP/ICMP/Source_Quench"), the fully qualified domain name for the
source host, some other unique identifier for the source host, the source
user/login/account, and an e-mail address associated with the traffic source.
log:DST.ADDR, log:DST.PROT, log:DST.FQDN, log:DST.NAME, log:DST.USR, log:DST.MAIL
Attributes representing the traffic destination.
log:REL.IN.ADDR, log:REL.IN.PROT, log:REL.IN.FQDN, log:REL.IN.NAME, log:REL.IN.USR,
log:REL.IN.MAIL, log:REL.OUT.ADDR, log:REL.OUT.PROT, log:REL.OUT.FQDN,
log:REL.OUT.NAME, log:REL.OUT.USR, log:REL.OUT.MAIL,
Attributes representing inbound and outbound traffic to a relay or proxy.
log:VOL, VOL.SENT, VOL.RCVD
Total data volume in octets, volume sent, and volume received.
log:CNT, log:CNT.SENT, log:CNT.RCVD
Total data volume in records, records sent, and records received.
log:PROG.FILE, log:PROG.LINE
The name of the program source file and line number within the source file. Typically
used for debugging and assert messages.
log:TTY
TTY or other description of the user's physical connection to the host generating the
event.
log:DOC
Name of an accessed document/file, such as an FTP file, a newsgroup, or a URL.
log:CMD
Issued command that generated the event.
log:MSG
Free form message text.
2.2.1.2. Nested Entries
At first blush, it's not obvious why we need a MSG attribute when we could use
something like:
<log:ENTRY ...>this is the text</log:ENTRY>
The reason is to allow log:ENTRY elements to nest. One possible interpretation of
nested log entries is to be able to represent complex relationships in the data.
Instead, here we use nesting to collapse redundant data. For example, the following
are considered equivalent:
<log:RCVD log:HOST=myhost log:DATE=1999-10-27T2:58>
<log:ENTRY log:PROG="Audit/Tripwire"
log:MSG="unexpected file" log:DOC="/a/b/c"/>
<log:ENTRY log:PROG="Audit/Tripwire"
log:MSG="unexpected file" log:DOC="/a/b/d"/>
<log:ENTRY log:PROG="Audit/Tripwire"
log:MSG="unexpected file" log:DOC="/a/b/e"/>
</log:RCVD>
<log:RCVD log:HOST=myhost log:DATE=1999-10-27T2:58>
<log:ENTRY log:PROG="Audit/Tripwire"
log:MSG="unexpected file">
<log:ENTRY log:DOC="/a/b/c"/>
<log:ENTRY log:DOC="/a/b/d"/>
<log:ENTRY log:DOC="/a/b/e"/>
</log:ENTRY>
</log:RCVD>
As a result, only inner-most log:ENTRY elements are log entries. Outer log:ENTRY
elements set attributes common to the contained entries.
2.2.2. Receiving Identifiers
The log:RCVD element contains information generated by logging subsystems. When a
program generates a log:ENTRY, the receiving logging subsystem (most likely part of
the trusted computing base on the same machine) will wrap it with its own identifiers.
When one machine transmits a log stream to another, the receiving machine may also
wish to wrap the log stream received with its identifiers.
Note: The log:RCVD element could also be extended to provide authenticity and
non-repudiation guarantees by adding digital signature elements. However, these
capabilities have not been specified in the the current draft of this memo because it
is assumed they will be provided the forthcoming standard for XML digital standards
[W3C99].
2.2.2.1. Attributes
log:HOST
The host receiving the log.
log:DATE
The date/time at which the log was received in ISO.8601:1998_Date_Format.
log:SEQ
A sequence number other than date/time used to serialize logs received by the host and
for detecting deleted logs.
2.3. Deviations from XML
Although XML is a good fit for the structure needed to describe system logs, it is not
a perfect fit. In particular:
* In the interest of compactness, logs will be considered complete even if they do
not contain the standard XML prolog containing the XML version, element declarations,
etc.
* Also in the interest of compactness, log message streams not beginning with <
will assume to be bracketed by '<log:' and '>'. This way, the existing syslog behavior
of sending a single log entry inside a single UDP packet may be preserved.
* Some might argue that having the free-form messages as log:MSG attribute values
is somewhat messy from an XML standpoint and that "proper" XML would be to unravel the
nesting and put the message text in as the "payload" of the log:ENTRY elements.
Implementations may contain a tool to generate 100% XML compliant "documents" from log
files so that the logs may be processed by standard XML tools.
----------
3. Implementation Considerations
3.1. Network Communications
3.1.1. Transport
3.1.1.1. Transmission Over UDP
3.1.1.2. Transmission Over TCP
3.1.1.3. Non-IP Transport
3.1.2. Session, Transport, and Network Layer Security
3.1.2.1. TLS/SSL
3.1.2.2. IPsec
3.1.3. Delivery Guarantees
3.2. Event Filtering
3.3. Event Viewing/Reporting
3.4. Logging API's
3.5. Backward Compatibility
3.5.1. Syslog
3.5.2. NT Event Logger
----------
4. Discussion
----------
5. Security Considerations
5.1. Privacy of Log Messages
5.2. Authenticity of Log Messages
5.3. Non-Repudiation of Log Messages
5.4. Immutability of Log Messages Without Detection
5.5. Denial of Service Attacks Against Log Servers
----------
6. References
[ULM99]
J. Abela and T. Debeaupis, "Universal Format for Logger Messages." The Internet
Society, May 1999. Available from
<ftp://ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt>ftp.ietf.org/internet-drafts/draft-abela-ulm-05.<ftp://ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt>txt.
[W3C98]
World Wide Web Consortium, "Extensible Markup Language (XML) 1.0." February 1998.
Available from
<http://www.w3.org/tr/rec-xml>www.w3.org/TR/REC-<http://www.w3.org/tr/rec-xml>xml.
[W3C99]
World Wide Web Consortium, "Digital Signature Initiative Activity Statement." October
1999. Available from
<http://www.w3.org/signature/activity.html>www.w3.org/Signature/Activity.<http://www.w3.org/signature/activity.html>html.
----------
7. Author's Address
C. Calabrese
Merck-Medco Managed Care, L.L.C.
1900 Pollitt Drive
Fair Lawn, NJ, USA 07410
Phone: (201) 703-7218
EMail:
<mailto:[EMAIL PROTECTED]>christopher_calabrese@merck.<mailto:[EMAIL PROTECTED]>com
