Network Working Group H. Debar
Request for Comments: 4765 France Telecom
Category: Experimental D. Curry
Guardian
B. Feinstein
SecureWorks, Inc.
March 2007
The Intrusion Detection Message Exchange Format (IDMEF)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
IESG Note
The content of this RFC was at one time considered by the IETF, but
the working group concluded before this work was approved as a
standards-track protocol. This RFC is not a candidate for any level
of Internet Standard. The IETF disclaims any knowledge of the
fitness of this RFC for any purpose and in particular notes that the
decision to publish is not based on complete IETF review for such
things as security, congestion control, or inappropriate interaction
with deployed protocols. The IESG has chosen to publish this
document in order to document the work as it was when the working
group concluded and to encourage experimentation and development of
the technology. Readers of this RFC should exercise caution in
evaluating its value for implementation and deployment.
Abstract
The purpose of the Intrusion Detection Message Exchange Format
(IDMEF) is to define data formats and exchange procedures for sharing
information of interest to intrusion detection and response systems
and to the management systems that may need to interact with them.
This document describes a data model to represent information
exported by intrusion detection systems and explains the rationale
for using this model. An implementation of the data model in the
Extensible Markup Language (XML) is presented, an XML Document Type
Definition is developed, and examples are provided.
Debar, et al. Experimental [Page 1]
RFC 4765 The IDMEF March 2007
Table of Contents
1. Introduction ....................................................4
1.1. About the IDMEF Data Model .................................4
1.1.1. Problems Addressed by the Data Model ................5
1.1.2. Data Model Design Goals .............................6
1.2. About the IDMEF XML Implementation .........................7
1.2.1. The Extensible Markup Language ......................7
1.2.2. Rationale for Implementing IDMEF in XML .............8
2. Notices and Conventions Used in This Document ..................10
3. Notational Conventions and Formatting Issues ...................10
3.1. IDMEF XML Documents .......................................10
3.1.1. The Document Prolog ................................10
3.1.2. Character Data Processing in IDMEF .................11
3.1.3. Languages in IDMEF .................................12
3.2. IDMEF Data Types ..........................................12
3.2.1. Integers ...........................................12
3.2.2. Real Numbers .......................................12
3.2.3. Characters and Strings .............................13
3.2.4. Bytes ..............................................14
3.2.5. Enumerated Types ...................................14
3.2.6. Date-Time Strings ..................................14
3.2.7. NTP Timestamps .....................................16
3.2.8. Port Lists .........................................16
3.2.9. Unique Identifiers .................................17
4. The IDMEF Data Model and DTD ...................................18
4.1. Data Model Overview .......................................18
4.2. The Message Classes .......................................20
4.2.1. The IDMEF-Message Class ............................20
4.2.2. The Alert Class ....................................20
4.2.3. The Heartbeat Class ................................27
4.2.4. The Core Classes ...................................29
4.2.5. The Time Classes ...................................41
4.2.6. The Assessment Classes .............................42
4.2.7. The Support Classes ................................47
5. Extending the IDMEF ............................................79
5.1. Extending the Data Model ..................................79
5.2. Extending the IDMEF DTD ...................................80
6. Special Considerations .........................................81
6.1. XML Validity and Well-Formedness ..........................81
6.2. Unrecognized XML Tags .....................................82
6.3. Analyzer-Manager Time Synchronization .....................82
6.4. NTP Timestamp Wrap-Around .................................84
6.5. Digital Signatures ........................................85
7. Examples .......................................................85
7.1. Denial-of-Service Attacks .................................86
7.1.1. The "teardrop" Attack ..............................86
7.1.2. The "ping of death" Attack .........................87
Debar, et al. Experimental [Page 2]
RFC 4765 The IDMEF March 2007
7.2. Port Scanning Attacks .....................................88
7.2.1. Connection to a Disallowed Service .................88
7.2.2. Simple Port Scanning ...............................89
7.3. Local Attacks .............................................90
7.3.1. The "loadmodule" Attack ............................90
7.3.2. The "phf" Attack ...................................93
7.3.3. File Modification ..................................94
7.4. System Policy Violation ...................................96
7.5. Correlated Alerts .........................................98
7.6. Analyzer Assessments ......................................99
7.7. Heartbeat ................................................100
7.8. XML Extension ............................................101
8. The IDMEF Document Type Definition (Normative) ................104
9. Security Considerations .......................................117
10. IANA Considerations ..........................................118
10.1. Adding Values to Existing Attributes ....................118
10.1.1. Attribute Registrations ..........................119
10.1.2. Registration Template ............................130
10.2. Adding New Attributes and Classes .......................131
11. References ...................................................131
11.1. Normative References ....................................131
11.2. Informative References ..................................132
Appendix A. Acknowledgements ....................................134
Appendix B. The IDMEF Schema Definition (Non-normative) .........135
Debar, et al. Experimental [Page 3]
RFC 4765 The IDMEF March 2007
1. Introduction
The Intrusion Detection Message Exchange Format (IDMEF) [2] is
intended to be a standard data format that automated intrusion
detection systems can use to report alerts about events that they
deem suspicious. The development of this standard format will enable
interoperability among commercial, open source, and research systems,
allowing users to mix-and-match the deployment of these systems
according to their strong and weak points to obtain an optimal
implementation.
The most obvious place to implement the IDMEF is in the data channel
between an intrusion detection analyzer (or "sensor") and the manager
(or "console") to which it sends alarms. But there are other places
where the IDMEF can be useful:
o a single database system that could store the results from a
variety of intrusion detection products would make it possible for
data analysis and reporting activities to be performed on "the
whole picture" instead of just a part of it;
o an event correlation system that could accept alerts from a
variety of intrusion detection products would be capable of
performing more sophisticated cross-correlation and cross-
confirmation calculations than one that is limited to a single
product;
o a graphical user interface that could display alerts from a
variety of intrusion detection products would enable the user to
monitor all of the products from a single screen, and require him
or her to learn only one interface, instead of several; and
o a common data exchange format would make it easier for different
organizations (users, vendors, response teams, law enforcement) to
not only exchange data, but also communicate about it.
The diversity of uses for the IDMEF needs to be considered when
selecting its method of implementation.
1.1. About the IDMEF Data Model
The IDMEF data model is an object-oriented representation of the
alert data sent to intrusion detection managers by intrusion
detection analyzers.
Debar, et al. Experimental [Page 4]
RFC 4765 The IDMEF March 2007
1.1.1. Problems Addressed by the Data Model
The data model addresses several problems associated with
representing intrusion detection alert data:
o Alert information is inherently heterogeneous. Some alerts are
defined with very little information, such as origin, destination,
name, and time of the event. Other alerts provide much more
information, such as ports or services, processes, user
information, and so on. The data model that represents this
information must be flexible to accommodate different needs.
An object-oriented model is naturally extensible via aggregation
and subclassing. If an implementation of the data model extends
it with new classes, either by aggregation or subclassing, an
implementation that does not understand these extensions will
still be able to understand the subset of information that is
defined by the data model. Subclassing and aggregation provide
extensibility while preserving the consistency of the model.
o Intrusion detection environments are different. Some analyzers
detect attacks by analyzing network traffic; others use operating
system logs or application audit trail information. Alerts for
the same attack, sent by analyzers with different information
sources, will not contain the same information.
The data model defines support classes that accommodate the
differences in data sources among analyzers. In particular, the
notions of source and target for the alert are represented by the
combination of Node, Process, Service, and User classes.
o Analyzer capabilities are different. Depending on the
environment, one may install a lightweight analyzer that provides
little information in its alerts, or a more complex analyzer that
will have a greater impact on the running system but provide more
detailed alert information. The data model must allow for
conversion to formats used by tools other than intrusion detection
analyzers, for the purpose of further processing the alert
information.
The data model defines extensions to the basic Document Type
Definition (DTD) that allow carrying both simple and complex
alerts. Extensions are accomplished through subclassing or
association of new classes.
Debar, et al. Experimental [Page 5]
RFC 4765 The IDMEF March 2007
o Operating environments are different. Depending on the kind of
network or operating system used, attacks will be observed and
reported with different characteristics. The data model should
accommodate these differences.
Significant flexibility in reporting is provided by the Node and
Service support classes. If additional information must be
reported, subclasses may be defined that extend the data model
with additional attributes.
o Commercial vendor objectives are different. For various reasons,
vendors may wish to deliver more or less information about certain
types of attacks.
The object-oriented approach allows this flexibility while the
subclassing rules preserve the integrity of the model.
1.1.2. Data Model Design Goals
The data model was designed to provide a standard representation of
alerts in an unambiguous fashion, and to permit the relationship
between simple and complex alerts to be described.
1.1.2.1. Representing Events
The goal of the data model is to provide a standard representation of
the information that an intrusion detection analyzer reports when it
detects an occurrence of some unusual event(s). These alerts may be
simple or complex, depending on the capabilities of the analyzer that
creates them.
1.1.2.2. Content-Driven
The design of the data model is content-driven. This means that new
objects are introduced to accommodate additional content, not
semantic differences between alerts. This is an important goal, as
the task of classifying and naming computer vulnerabilities is both
extremely difficult and very subjective.
The data model must be unambiguous. This means that while we allow
analyzers to be more or less precise than one another (i.e., one
analyzer may report more information about an event than another), we
do not allow them to produce contradictory information in two alerts
describing the same event (i.e., the common subset of information
reported by both analyzers must be identical and inserted in the same
placeholders within the alert data structure). Of course, it is
always possible to insert all "interesting" information about an
Debar, et al. Experimental [Page 6]
RFC 4765 The IDMEF March 2007
event in extension fields of the alert instead of in the fields where
it belongs; however, such practice reduces interoperability and
should be avoided whenever possible.
1.1.2.3. Relationship between Alerts
Intrusion detection alerts can be transmitted at several levels.
This document applies to the entire range, from very simple alerts
(e.g., those alerts that are the result of a single action or
operation in the system, such as a failed login report) to very
complex ones (e.g., the aggregation of several events causing an
alert to be generated).
As such, the data model must provide a way for complex alerts that
aggregate several simple alerts to identify those simple alerts in
the complex alert's content.
1.2. About the IDMEF XML Implementation
Two implementations of the IDMEF were originally proposed to the
Intrusion Detection Working Group (IDWG): one using the Structure of
Management Information (SMI) to describe a Simple Network Management
Protocol (SNMP) MIB, and the other using a DTD to describe XML
documents.
These proposed implementations were reviewed by the IDWG at its
September 1999 and February 2000 meetings; it was decided at the
February meeting that the XML solution was best at fulfilling the
IDWG requirements.
1.2.1. The Extensible Markup Language
The Extensible Markup Language (XML) [3] is a simplified version of
the Standard Generalized Markup Language (SGML), a syntax for
specifying text markup defined by the ISO 8879 standard. XML is
gaining widespread attention as a language for representing and
exchanging documents and data on the Internet, and as the solution to
most of the problems inherent in HyperText Markup Language (HTML).
XML was published as a recommendation by the World Wide Web
Consortium (W3C) on February 10, 1998.
XML is a metalanguage -- a language for describing other languages --
that enables an application to define its own markup. XML allows the
definition of customized markup languages for different types of
documents and different applications. This differs from HTML, in
which there is a fixed set of identifiers with preset meanings that
must be "adapted" for specialized uses. Both XML and HTML use
elements (tags) (identifiers delimited by '<' and '>') and attributes
Debar, et al. Experimental [Page 7]
RFC 4765 The IDMEF March 2007
(of the form "name='value'"). But where "" always means
"paragraph" in HTML, it may mean "paragraph", "person", "price", or
"platypus" in XML, or it might have no meaning at all, depending on
the particular application.
NOTE: XML provides both a syntax for declaring document markup and
structure (i.e., defining elements and attributes, specifying the
order in which they appear, and so on) and a syntax for using that
markup in documents. Because markup declarations look radically
different from markup, many people are confused as to which syntax
is called XML. The answer is that they both are, because they are
actually both part of the same language.
For clarity in this document, we will use the terms "XML" and "XML
documents" when speaking in the general case, and the term "IDMEF
markup" when speaking specifically of the elements (tags) and
attributes that describe IDMEF messages.
The publication of XML was followed by the publication of a second
recommendation [4] by the World Wide Web Consortium, defining the use
of namespaces in XML documents. An XML namespace is a collection of
names, identified by a Uniform Resource Identifier (URI) [5]. When
using namespaces, each tag is identified with the namespace it comes
from, allowing tags from different namespaces with the same names to
occur in the same document. For example, a single document could
contain both "usa:football" and "europe:football" tags, each with
different meanings.
In anticipation of the widespread use of XML namespaces, this memo
includes the definition of the URI to be used to identify the IDMEF
namespace.
1.2.2. Rationale for Implementing IDMEF in XML
XML-based applications are being used or developed for a wide variety
of purposes, including electronic data interchange in a variety of
fields, financial data interchange, electronic business cards,
calendar and scheduling, enterprise software distribution, web "push"
technology, and markup languages for chemistry, mathematics, music,
molecular dynamics, astronomy, book and periodical publishing, web
publishing, weather observations, real estate transactions, and many
others.
XML's flexibility makes it a good choice for these applications; that
same flexibility makes it a good choice for implementing the IDMEF as
well. Other, more specific reasons for choosing XML to implement the
IDMEF are:
Debar, et al. Experimental [Page 8]
RFC 4765 The IDMEF March 2007
o XML allows a custom language to be developed specifically for the
purpose of describing intrusion detection alerts. It also defines
a standard way to extend this language, either for later revisions
of this document ("standard" extensions) or for vendor-specific
use ("non-standard" extensions).
o Software tools for processing XML documents are widely available,
in both commercial and open source forms. Numerous tools and APIs
for parsing and/or validating XML are available in a variety of
languages, including Java, C, C++, Tcl, Perl, Python, and GNU
Emacs Lisp. Widespread access to tools will make adoption of the
IDMEF by product developers easier, and hopefully, faster.
o XML meets IDMEF Requirement 5.1 [2], that message formats support
full internationalization and localization. The XML standard
requires support for both the UTF-8 and UTF-16 encodings of ISO/
IEC 10646 (Universal Multiple-Octet Coded Character Set, "UCS")
and Unicode, making all XML applications (and therefore all IDMEF-
compliant applications) compatible with these common character
encodings.
XML also provides support for specifying, on a per-element basis,
the language in which the element's content is written, making
IDMEF easy to adapt to "Natural Language Support" versions of a
product.
o XML meets IDMEF Requirement 5.2 [2], that message formats must
support filtering and aggregation. XML's integration with XSL, a
style language, allows messages to be combined, discarded, and
rearranged.
o Ongoing XML development projects, in the W3C and elsewhere, will
provide object-oriented extensions, database support, and other
useful features. If implemented in XML, the IDMEF immediately
gains these features as well.
o XML is free, with no license, no license fees, and no royalties.
Debar, et al. Experimental [Page 9]
RFC 4765 The IDMEF March 2007
2. Notices and Conventions Used in This Document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
An "IDMEF-compliant application" is a program or program component,
such as an analyzer or manager, that reads and/or writes messages in
the format specified by this memo.
An "IDMEF document" is a message that adheres to the requirements
specified by this memo and that is exchanged by two or more IDMEF
applications. "IDMEF message" is another term for an "IDMEF
document".
3. Notational Conventions and Formatting Issues
This document uses three notations: Unified Modeling Language to
describe the data model [14], XML to describe the markup used in
IDMEF documents, and IDMEF markup to represent the documents
themselves.
3.1. IDMEF XML Documents
This section describes IDMEF XML document formatting rules. Most of
these rules are "inherited" from the rules for formatting XML
documents.
3.1.1. The Document Prolog
The format of an IDMEF XML document prolog is described in the
following sections.
3.1.1.1. XML Declaration
IDMEF documents being exchanged between IDMEF-compliant applications
MUST begin with an XML declaration, and MUST specify the XML version
in use. Specification of the encoding in use is RECOMMENDED.
An IDMEF message SHOULD therefore start with:
element content is described
in Section 3.2.6.
If the date and time represented by the element content and the NTP
timestamp differ (should "never" happen), the value in the NTP
timestamp MUST be used.
4.2.5.1. The CreateTime Class
The CreateTime class is used to indicate the date and time the alert
or heartbeat was created by the analyzer.
4.2.5.2. The DetectTime Class
The DetectTime class is used to indicate the date and time that the
event(s) producing an alert was detected by the analyzer. In the
case of more than one event, it is the time that the first event was
detected. (This may or may not be the same time as CreateTime;
analyzers are not required to send alerts immediately upon
detection).
Debar, et al. Experimental [Page 41]
RFC 4765 The IDMEF March 2007
4.2.5.3. The AnalyzerTime Class
The AnalyzerTime class is used to indicate the current date and time
on the analyzer. Its values should be filled in as late as possible
in the message transmission process, ideally immediately before
placing the message "on the wire".
The use of to perform rudimentary time synchronization
between analyzers and managers is discussed in Section 6.3.
4.2.6. The Assessment Classes
The data model provides three types of "assessments" that an analyzer
can make about an event. These classes are aggregates of the
Assessment class.
4.2.6.1. The Impact Class
The Impact class is used to provide the analyzer's assessment of the
impact of the event on the target(s). It is represented in the IDMEF
DTD as follows:
Debar, et al. Experimental [Page 42]
RFC 4765 The IDMEF March 2007
The Impact class has three attributes:
severity
An estimate of the relative severity of the event. The permitted
values are shown below. There is no default value. (See also
Section 10.)
+------+---------+-----------------------------------------+
| Rank | Keyword | Description |
+------+---------+-----------------------------------------+
| 0 | info | Alert represents informational activity |
| | | |
| 1 | low | Low severity |
| | | |
| 2 | medium | Medium severity |
| | | |
| 3 | high | High severity |
+------+---------+-----------------------------------------+
completion
An indication of whether the analyzer believes the attempt that
the event describes was successful or not. The permitted values
are shown below. There is no default value. (See also
Section 10.)
+------+-----------+--------------------------------+
| Rank | Keyword | Description |
+------+-----------+--------------------------------+
| 0 | failed | The attempt was not successful |
| | | |
| 1 | succeeded | The attempt succeeded |
+------+-----------+--------------------------------+
Debar, et al. Experimental [Page 43]
RFC 4765 The IDMEF March 2007
type
The type of attempt represented by this event, in relatively broad
categories. The permitted values are shown below. The default
value is "other". (See also Section 10.)
+------+---------+--------------------------------------------------+
| Rank | Keyword | Description |
+------+---------+--------------------------------------------------+
| 0 | admin | Administrative privileges were attempted or |
| | | obtained |
| | | |
| 1 | dos | A denial of service was attempted or completed |
| | | |
| 2 | file | An action on a file was attempted or completed |
| | | |
| 3 | recon | A reconnaissance probe was attempted or |
| | | completed |
| | | |
| 4 | user | User privileges were attempted or obtained |
| | | |
| 5 | other | Anything not in one of the above categories |
+------+---------+--------------------------------------------------+
All three attributes are optional. The element itself may be empty,
or may contain a textual description of the impact, if the analyzer
is able to provide additional details.
4.2.6.2. The Action Class
The Action class is used to describe any actions taken by the
analyzer in response to the event. Is is represented in the IDMEF
DTD as follows:
Debar, et al. Experimental [Page 44]
RFC 4765 The IDMEF March 2007
Action has one attribute:
category
The type of action taken. The permitted values are shown below.
The default value is "other". (See also Section 10.)
+------+-------------------+----------------------------------------+
| Rank | Keyword | Description |
+------+-------------------+----------------------------------------+
| 0 | block-installed | A block of some sort was installed to |
| | | prevent an attack from reaching its |
| | | destination. The block could be a |
| | | port block, address block, etc., or |
| | | disabling a user account. |
| | | |
| 1 | notification-sent | A notification message of some sort |
| | | was sent out-of-band (via pager, |
| | | e-mail, etc.). Does not include the |
| | | transmission of this alert. |
| | | |
| 2 | taken-offline | A system, computer, or user was taken |
| | | offline, as when the computer is shut |
| | | down or a user is logged off. |
| | | |
| 3 | other | Anything not in one of the above |
| | | categories. |
+------+-------------------+----------------------------------------+
The element itself may be empty, or may contain a textual
description of the action, if the analyzer is able to provide
additional details.
4.2.6.3. The Confidence Class
The Confidence class is used to represent the analyzer's best
estimate of the validity of its analysis. It is represented in the
IDMEF DTD as follows:
Debar, et al. Experimental [Page 45]
RFC 4765 The IDMEF March 2007
The Confidence class has one attribute:
rating
The analyzer's rating of its analytical validity. The permitted
values are shown below. The default value is "numeric". (See
also Section 10.)
+------+---------+--------------------------------------------------+
| Rank | Keyword | Description |
+------+---------+--------------------------------------------------+
| 0 | low | The analyzer has little confidence in its |
| | | validity |
| | | |
| 1 | medium | The analyzer has average confidence in its |
| | | validity |
| | | |
| 2 | high | The analyzer has high confidence in its validity |
| | | |
| 3 | numeric | The analyzer has provided a posterior |
| | | probability value indicating its confidence in |
| | | its validity |
+------+---------+--------------------------------------------------+
This element should be used only when the analyzer can produce
meaningful information. Systems that can output only a rough
heuristic should use "low", "medium", or "high" as the rating value.
In this case, the element content should be omitted.
Systems capable of producing reasonable probability estimates should
use "numeric" as the rating value and include a numeric confidence
value in the element content. This numeric value should reflect a
posterior probability (the probability that an attack has occurred
given the data seen by the detection system and the model used by the
system). It is a floating point number between 0.0 and 1.0,
inclusive. The number of digits should be limited to those
representable by a single precision floating point value, and may be
represented as described in Section 3.2.2.
NOTE: It should be noted that different types of analyzers may
compute confidence values in different ways and that in many
cases, confidence values from different analyzers should not be
compared (for example, if the analyzers use different methods of
computing or representing confidence, or are of different types or
configurations). Care should be taken when implementing systems
that process confidence values (such as event correlators) not to
make comparisons or assumptions that cannot be supported by the
system's knowledge of the environment in which it is working.
Debar, et al. Experimental [Page 46]
RFC 4765 The IDMEF March 2007
4.2.7. The Support Classes
The support classes make up the major parts of the core classes, and
are shared between them.
4.2.7.1. The Reference Class
The Reference class provides the "name" of an alert, or other
information allowing the manager to determine what it is.
The Reference class is composed of two aggregate classes, as shown in
Figure 13.
+----------------+
| Reference |
+----------------+ +------+
| STRING origin |<>----------| name |
| STRING meaning | +------+
| | +------+
| |<>----------| url |
| | +------+
+----------------+
Figure 13: The Reference Class
The aggregate classes that make up Reference are:
name
Exactly one. STRING. The name of the alert, from one of the
origins listed below.
url
Exactly one. STRING. A URL at which the manager (or the human
operator of the manager) can find additional information about the
alert. The document pointed to by the URL may include an in-depth
description of the attack, appropriate countermeasures, or other
information deemed relevant by the vendor.
Debar, et al. Experimental [Page 47]
RFC 4765 The IDMEF March 2007
This is represented in the IDMEF DTD as follows:
The Reference class has two attributes:
origin
Required. The source from which the name of the alert originates.
The permitted values for this attribute are shown below. The
default value is "unknown". (See also Section 10.)
+------+-----------------+------------------------------------------+
| Rank | Keyword | Description |
+------+-----------------+------------------------------------------+
| 0 | unknown | Origin of the name is not known |
| | | |
| 1 | vendor-specific | A vendor-specific name (and hence, URL); |
| | | this can be used to provide |
| | | product-specific information |
| | | |
| 2 | user-specific | A user-specific name (and hence, URL); |
| | | this can be used to provide |
| | | installation-specific information |
| | | |
| 3 | bugtraqid | The SecurityFocus ("Bugtraq") |
| | | vulnerability database identifier |
| | | (http://www.securityfocus.com/bid) |
| | | |
| 4 | cve | The Common Vulnerabilities and Exposures |
| | | (CVE) name (http://www.cve.mitre.org/) |
| | | |
| 5 | osvdb | The Open Source Vulnerability Database |
| | | (http://www.osvdb.org) |
+------+-----------------+------------------------------------------+
Debar, et al. Experimental [Page 48]
RFC 4765 The IDMEF March 2007
meaning
Optional. The meaning of the reference, as understood by the
alert provider. This field is only valid if the value of the
attribute is set to "vendor-specific" or "user-specific".
4.2.7.2. The Node Class
The Node class is used to identify hosts and other network devices
(routers, switches, etc.).
The Node class is composed of three aggregate classes, as shown in
Figure 14.
+---------------+
| Node |
+---------------+ 0..1 +----------+
| STRING ident |<>----------| location |
| ENUM category | +----------+
| | 0..1 +----------+
| |<>----------| name |
| | +----------+
| | 0..* +----------+
| |<>----------| Address |
| | +----------+
+---------------+
Figure 14: The Node Class
The aggregate classes that make up Node are:
location
Zero or one. STRING. The location of the equipment.
name
Zero or one. STRING. The name of the equipment. This
information MUST be provided if no Address information is given.
Address
Zero or more. The network or hardware address of the equipment.
Unless a name (above) is provided, at least one address must be
specified.
Debar, et al. Experimental [Page 49]
RFC 4765 The IDMEF March 2007
This is represented in the IDMEF DTD as follows:
Debar, et al. Experimental [Page 50]
RFC 4765 The IDMEF March 2007
The Node class has two attributes:
ident
Optional. A unique identifier for the node; see Section 3.2.9.
category
Optional. The "domain" from which the name information was
obtained, if relevant. The permitted values for this attribute
are shown in the table below. The default value is "unknown".
(See also Section 10 for extensions to the table.)
+------+----------+------------------------------------------+
| Rank | Keyword | Description |
+------+----------+------------------------------------------+
| 0 | unknown | Domain unknown or not relevant |
| | | |
| 1 | ads | Windows 2000 Advanced Directory Services |
| | | |
| 2 | afs | Andrew File System (Transarc) |
| | | |
| 3 | coda | Coda Distributed File System |
| | | |
| 4 | dfs | Distributed File System (IBM) |
| | | |
| 5 | dns | Domain Name System |
| | | |
| 6 | hosts | Local hosts file |
| | | |
| 7 | kerberos | Kerberos realm |
| | | |
| 8 | nds | Novell Directory Services |
| | | |
| 9 | nis | Network Information Services (Sun) |
| | | |
| 10 | nisplus | Network Information Services Plus (Sun) |
| | | |
| 11 | nt | Windows NT domain |
| | | |
| 12 | wfw | Windows for Workgroups |
+------+----------+------------------------------------------+
Debar, et al. Experimental [Page 51]
RFC 4765 The IDMEF March 2007
4.2.7.2.1. The Address Class
The Address class is used to represent network, hardware, and
application addresses.
The Address class is composed of two aggregate classes, as shown in
Figure 15.
+------------------+
| Address |
+------------------+ +---------+
| STRING ident |<>----------| address |
| ENUM category | +---------+
| STRING vlan-name | 0..1 +---------+
| INTEGER vlan-num |<>----------| netmask |
| | +---------+
+------------------+
Figure 15: The Address Class
The aggregate classes that make up Address are:
address
Exactly one. STRING. The address information. The format of
this data is governed by the category attribute.
netmask
Zero or one. STRING. The network mask for the address, if
appropriate.
Debar, et al. Experimental [Page 52]
RFC 4765 The IDMEF March 2007
This is represented in the IDMEF DTD as follows:
The Address class has four attributes:
ident
Optional. A unique identifier for the address; see Section 3.2.9.
category
Optional. The type of address represented. The permitted values
for this attribute are shown below. The default value is
"unknown". (See also Section 10.)
Debar, et al. Experimental [Page 53]
RFC 4765 The IDMEF March 2007
+------+---------------+--------------------------------------------+
| Rank | Keyword | Description |
+------+---------------+--------------------------------------------+
| 0 | unknown | Address type unknown |
| | | |
| 1 | atm | Asynchronous Transfer Mode network address |
| | | |
| 2 | e-mail | Electronic mail address (RFC 2822 [12]) |
| | | |
| 3 | lotus-notes | Lotus Notes e-mail address |
| | | |
| 4 | mac | Media Access Control (MAC) address |
| | | |
| 5 | sna | IBM Shared Network Architecture (SNA) |
| | | address |
| | | |
| 6 | vm | IBM VM ("PROFS") e-mail address |
| | | |
| 7 | ipv4-addr | IPv4 host address in dotted-decimal |
| | | notation (a.b.c.d) |
| | | |
| 8 | ipv4-addr-hex | IPv4 host address in hexadecimal notation |
| | | |
| 9 | ipv4-net | IPv4 network address in dotted-decimal |
| | | notation, slash, significant bits |
| | | (a.b.c.d/nn) |
| | | |
| 10 | ipv4-net-mask | IPv4 network address in dotted-decimal |
| | | notation, slash, network mask in |
| | | dotted-decimal notation (a.b.c.d/w.x.y.z) |
| | | |
| 11 | ipv6-addr | IPv6 host address |
| | | |
| 12 | ipv6-addr-hex | IPv6 host address in hexadecimal notation |
| | | |
| 13 | ipv6-net | IPv6 network address, slash, significant |
| | | bits |
| | | |
| 14 | ipv6-net-mask | IPv6 network address, slash, network mask |
+------+---------------+--------------------------------------------+
vlan-name
Optional. The name of the Virtual LAN to which the address
belongs.
Debar, et al. Experimental [Page 54]
RFC 4765 The IDMEF March 2007
vlan-num
Optional. The number of the Virtual LAN to which the address
belongs.
4.2.7.3. The User Class
The User class is used to describe users. It is primarily used as a
"container" class for the UserId aggregate class, as shown in
Figure 16.
+---------------+
| User |
+---------------+ 1..* +--------+
| STRING ident |<>----------| UserId |
| ENUM category | +--------+
+---------------+
Figure 16: The User Class
The aggregate class contained in User is:
UserId
One or more. Identification of a user, as indicated by its type
attribute (see Section 4.2.7.3.1).
This is represented in the IDMEF DTD as follows:
Debar, et al. Experimental [Page 55]
RFC 4765 The IDMEF March 2007
The User class has two attributes:
ident
Optional. A unique identifier for the user; see Section 3.2.9.
category
Optional. The type of user represented. The permitted values for
this attribute are shown below. The default value is "unknown".
(See also Section 10.)
+------+-------------+------------------------------------+
| Rank | Keyword | Description |
+------+-------------+------------------------------------+
| 0 | unknown | User type unknown |
| | | |
| 1 | application | An application user |
| | | |
| 2 | os-device | An operating system or device user |
+------+-------------+------------------------------------+
4.2.7.3.1. The UserId Class
The UserId class provides specific information about a user. More
than one UserId can be used within the User class to indicate
attempts to transition from one user to another, or to provide
complete information about a user's (or process') privileges.
The UserId class is composed of two aggregate classes, as shown in
Figure 17.
+--------------+
| UserId |
+--------------+ 0..1 +--------+
| STRING ident |<>----------| name |
| ENUM type | +--------+
| STRING tty | 0..1 +--------+
| |<>----------| number |
| | +--------+
+--------------+
Figure 17: The UserId Class
Debar, et al. Experimental [Page 56]
RFC 4765 The IDMEF March 2007
The aggregate classes that make up UserId are:
name
Zero or one. STRING. A user or group name.
number
Zero or one. INTEGER. A user or group number.
This is represented in the IDMEF DTD as follows:
The UserId class has three attributes:
ident
Optional. A unique identifier for the user id, see Section 3.2.9.
type
Optional. The type of user information represented. The
permitted values for this attribute are shown below. The default
value is "original-user". (See also Section 10.)
Debar, et al. Experimental [Page 57]
RFC 4765 The IDMEF March 2007
+------+---------------+--------------------------------------------+
| Rank | Keyword | Description |
+------+---------------+--------------------------------------------+
| 0 | current-user | The current user id being used by the user |
| | | or process. On Unix systems, this would |
| | | be the "real" user id, in general. |
| | | |
| 1 | original-user | The actual identity of the user or process |
| | | being reported on. On those systems that |
| | | (a) do some type of auditing and (b) |
| | | support extracting a user id from the |
| | | "audit id" token, that value should be |
| | | used. On those systems that do not |
| | | support this, and where the user has |
| | | logged into the system, the "login id" |
| | | should be used. |
| | | |
| 2 | target-user | The user id the user or process is |
| | | attempting to become. This would apply, |
| | | on Unix systems for example, when the user |
| | | attempts to use "su", "rlogin", "telnet", |
| | | etc. |
| | | |
| 3 | user-privs | Another user id the user or process has |
| | | the ability to use, or a user id |
| | | associated with a file permission. On |
| | | Unix systems, this would be the |
| | | "effective" user id in a user or process |
| | | context, and the owner permissions in a |
| | | file context. Multiple UserId elements of |
| | | this type may be used to specify a list of |
| | | privileges. |
| | | |
| 4 | current-group | The current group id (if applicable) being |
| | | used by the user or process. On Unix |
| | | systems, this would be the "real" group |
| | | id, in general. |
| | | |
| 5 | group-privs | Another group id the group or process has |
| | | the ability to use, or a group id |
| | | associated with a file permission. On |
| | | Unix systems, this would be the |
| | | "effective" group id in a group or process |
| | | context, and the group permissions in a |
| | | file context. On BSD-derived Unix |
| | | systems, multiple UserId elements of this |
| | | type would be used to include all the |
| | | group ids on the "group list". |
Debar, et al. Experimental [Page 58]
RFC 4765 The IDMEF March 2007
| 6 | other-privs | Not used in a user, group, or process |
| | | context, only used in the file context. |
| | | The file permissions assigned to users who |
| | | do not match either the user or group |
| | | permissions on the file. On Unix systems, |
| | | this would be the "world" permissions. |
+------+---------------+--------------------------------------------+
tty
Optional. STRING. The tty the user is using.
4.2.7.4. The Process Class
The Process class is used to describe processes being executed on
sources, targets, and analyzers.
The Process class is composed of five aggregate classes, as shown in
Figure 18.
+--------------+
| Process |
+--------------+ +------+
| STRING ident |<>----------| name |
| | +------+
| | 0..1 +------+
| |<>----------| pid |
| | +------+
| | 0..1 +------+
| |<>----------| path |
| | +------+
| | 0..* +------+
| |<>----------| arg |
| | +------+
| | 0..* +------+
| |<>----------| env |
| | +------+
+--------------+
Figure 18: The Process Class
Debar, et al. Experimental [Page 59]
RFC 4765 The IDMEF March 2007
The aggregate classes that make up Process are:
name
Exactly one. STRING. The name of the program being executed.
This is a short name; path and argument information are provided
elsewhere.
pid
Zero or one. INTEGER. The process identifier of the process.
path
Zero or one. STRING. The full path of the program being
executed.
arg
Zero or more. STRING. A command-line argument to the program.
Multiple arguments may be specified (they are assumed to have
occurred in the same order they are provided) with multiple uses
of arg.
env
Zero or more. STRING. An environment string associated with the
process; generally of the format "VARIABLE=value". Multiple
environment strings may be specified with multiple uses of env.
This is represented in the IDMEF DTD as follows:
The Process class has one attribute:
ident
Optional. A unique identifier for the process; see Section 3.2.9.
Debar, et al. Experimental [Page 60]
RFC 4765 The IDMEF March 2007
4.2.7.5. The Service Class
The Service class describes network services on sources and targets.
It can identify services by name, port, and protocol. When Service
occurs as an aggregate class of Source, it is understood that the
service is one from which activity of interest is originating; and
that the service is "attached" to the Node, Process, and User
information also contained in Source. Likewise, when Service occurs
as an aggregate class of Target, it is understood that the service is
one to which activity of interest is being directed; and that the
service is "attached" to the Node, Process, and User information also
contained in Target. If Service occurs in both Source and Target,
then information in both locations should be the same. If
information is the same in both locations and implementers wish to
carry it in only one location, they should specify it as an aggregate
of the Target class.
The Service class is composed of four aggregate classes, as shown in
Figure 19.
+-----------------------------+
| Service |
+-----------------------------+ 0..1 +----------+
| STRING ident |<>----------| name |
| INTEGER ip_version | +----------+
| INTEGER iana_protocol_number| 0..1 +----------+
| STRING iana_protocol_name |<>----------| port |
| | +----------+
| | 0..1 +----------+
| |<>----------| portlist |
| | +----------+
| | 0..1 +----------+
| |<>----------| protocol |
| | +----------+
+-----------------------------+
/_\
|
+---------+--------+
| |
+-------------+ +-------------+
| SNMPService | | WebService |
+-------------+ +-------------+
Figure 19: The Service Class
Debar, et al. Experimental [Page 61]
RFC 4765 The IDMEF March 2007
The aggregate classes that make up Service are:
name
Zero or one. STRING. The name of the service. Whenever
possible, the name from the IANA list of well-known ports SHOULD
be used.
port
Zero or one. INTEGER. The port number being used.
portlist
Zero or one. PORTLIST. A list of port numbers being used; see
Section 3.2.8 for formatting rules. If a portlist is given, the
iana_protocol_number and iana_protocol_name MUST apply to all the
elements of the list.
protocol
Zero or one. STRING. Additional information about the protocol
being used. The intent of the protocol field is to carry
additional information related to the protocol being used when the
attributes iana_protocol_number or/and
iana_protocol_name are filed.
A Service MUST be specified as either (a) a name or a port or (b) a
portlist. The protocol is optional in all cases, but no other
combinations are permitted.
Service is represented in the IDMEF DTD as follows:
Debar, et al. Experimental [Page 62]
RFC 4765 The IDMEF March 2007
The Service class has four attributes:
ident
Optional. A unique identifier for the service; see Section 3.2.9.
ip_version
Optional. INTEGER. The IP version number.
iana_protocol_number
Optional. INTEGER. The IANA protocol number.
iana_protocol_name
Optional. STRING. The IANA protocol name.
4.2.7.5.1. The WebService Class
The WebService class carries additional information related to web
traffic.
The WebService class is composed of four aggregate classes, as shown
in Figure 20.
+-------------+
| Service |
+-------------+
/_\
|
+-------------+
| WebService |
+-------------+ +-------------+
| |<>----------| url |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| cgi |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| http-method |
| | +-------------+
| | 0..* +-------------+
| |<>----------| arg |
| | +-------------+
+-------------+
Figure 20: The WebService Class
Debar, et al. Experimental [Page 63]
RFC 4765 The IDMEF March 2007
The aggregate classes that make up WebService are:
url
Exactly one. STRING. The URL in the request.
cgi
Zero or one. STRING. The CGI script in the request, without
arguments.
http-method
Zero or one. STRING. The HTTP method (PUT, GET) used in the
request.
arg
Zero or more. STRING. The arguments to the CGI script.
This is represented in the IDMEF DTD as follows:
4.2.7.5.2. The SNMPService Class
The SNMPService class carries additional information related to SNMP
traffic. The aggregate classes composing SNMPService must be
interpreted as described in RFC 3411 [15] and RFC 3584 [16].
The SNMPService class is composed of eight aggregate classes, as
shown in Figure 21.
Debar, et al. Experimental [Page 64]
RFC 4765 The IDMEF March 2007
+-------------+
| Service |
+-------------+
/_\
|
+-------------+
| SNMPService |
+-------------+ 0..1 +----------------------+
| |<>----------| oid |
| | +----------------------+
| | 0..1 +----------------------+
| |<>----------|messageProcessingModel|
| | +----------------------+
| | 0..1 +----------------------+
| |<>----------| securityModel |
| | +----------------------+
| | 0..1 +----------------------+
| |<>----------| securityName |
| | +----------------------+
| | 0..1 +----------------------+
| |<>----------| securityLevel |
| | +----------------------+
| | 0..1 +----------------------+
| |<>----------| contextName |
| | +----------------------+
| | 0..1 +----------------------+
| |<>----------| contextEngineID |
| | +----------------------+
| | 0..1 +----------------------+
| |<>----------| command |
| | +----------------------+
+-------------+
Figure 21: The SNMPService Class
The aggregate classes that make up SNMPService are:
oid
Zero or one. STRING. The object identifier in the request.
messageProcessingModel
Zero or one. INTEGER. The SNMP version, typically 0 for SNMPv1,
1 for SNMPv2c, 2 for SNMPv2u and SNMPv2*, and 3 for SNMPv3; see
RFC 3411 [15] Section 5 for appropriate values.
Debar, et al. Experimental [Page 65]
RFC 4765 The IDMEF March 2007
securityModel
Zero or one. INTEGER. The identification of the security model
in use, typically 0 for any, 1 for SNMPv1, 2 for SNMPv2c, and 3
for USM; see RFC 3411 [15] Section 5 for appropriate values.
securityName
Zero or one. STRING. The object's security name; see RFC 3411
[15] Section 3.2.2.
securityLevel
Zero or one. INTEGER. The security level of the SNMP request;
see RFC 3411 [15] Section 3.4.3.
contextName
Zero or one. STRING. The object's context name; see RFC 3411
[15] Section 3.3.3.
contextEngineID
Zero or one. STRING. The object's context engine identifier; see
RFC 3411 [15] Section 3.3.2.
command
Zero or one. STRING. The command sent to the SNMP server (GET,
SET, etc.).
If other fields of an SNMP message are available and should be
incorporated in the IDMEF alert, they must be located in the
additionaldata structure with the meaning being an object definition
defined in RFC 3411 [15] Section 5 and the value located within the
additionaldata payload.
This is represented in the IDMEF DTD as follows:
Debar, et al. Experimental [Page 66]
RFC 4765 The IDMEF March 2007
4.2.7.6. The File Class
The File class provides specific information about a file or other
file-like object that has been created, deleted, or modified on the
target. The description can provide either the file settings prior
to the event or the file settings at the time of the event, as
specified using the "category" attribute.
The File class is composed of eleven aggregate classes, as shown in
Figure 22.
+--------------+
| File |
+--------------+ +-------------+
| |<>----------| name |
| | +-------------+
| | +-------------+
| |<>----------| path |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| create-time |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| modify-time |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| access-time |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| data-size |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| disk-size |
| | +-------------+
| | 0..* +-------------+
| |<>----------| FileAccess |
| | +-------------+
| | 0..* +-------------+
| |<>----------| Linkage |
| | +-------------+
| | 0..1 +-------------+
| |<>----------| Inode |
| | +-------------+
| | 0..* +-------------+
| |<>----------| Checksum |
| | +-------------+
+--------------+
Figure 22: The File Class
Debar, et al. Experimental [Page 67]
RFC 4765 The IDMEF March 2007
The aggregate classes that make up File are:
name
Exactly one. STRING. The name of the file to which the alert
applies, not including the path to the file.
path
Exactly one. STRING. The full path to the file, including the
name. The path name should be represented in as "universal" a
manner as possible, to facilitate processing of the alert.
For Windows systems, the path should be specified using the
Universal Naming Convention (UNC) for remote files, and using a
drive letter for local files (e.g., "C:\boot.ini"). For Unix
systems, paths on network file systems should use the name of the
mounted resource instead of the local mount point (e.g.,
"fileserver:/usr/local/bin/foo"). The mount point can be provided
using the element.
create-time
Zero or one. DATETIME. Time the file was created. Note that
this is *not* the Unix "st_ctime" file attribute (which is not
file creation time). The Unix "st_ctime" attribute is contained
in the "Inode" class.
modify-time
Zero or one. DATETIME. Time the file was last modified.
access-time
Zero or one. DATETIME. Time the file was last accessed.
data-size
Zero or one. INTEGER. The size of the data, in bytes. Typically
what is meant when referring to file size. On Unix UFS file
systems, this value corresponds to stat.st_size. On Windows NTFS,
this value corresponds to Valid Data Length (VDL).
Debar, et al. Experimental [Page 68]
RFC 4765 The IDMEF March 2007
disk-size
Zero or one. INTEGER. The physical space on disk consumed by the
file, in bytes. On Unix UFS file systems, this value corresponds
to 512 * stat.st_blocks. On Windows NTFS, this value corresponds
to End of File (EOF).
FileAccess
Zero or more. Access permissions on the file.
Linkage
Zero or more. File system objects to which this file is linked
(other references for the file).
Inode
Zero or one. Inode information for this file (relevant to Unix).
Checksum
Zero or more. Checksum information for this file.
This is represented in the IDMEF DTD as follows:
The File class has four attributes (one required and three optional):
ident
Optional. A unique identifier for this file; see Section 3.2.9.
Debar, et al. Experimental [Page 69]
RFC 4765 The IDMEF March 2007
category
Required. The context for the information being provided. The
permitted values are shown below. There is no default value.
(See also Section 10.)
+------+----------+-------------------------------------------------+
| Rank | Keyword | Description |
+------+----------+-------------------------------------------------+
| 0 | current | The file information is from after the reported |
| | | change |
| | | |
| 1 | original | The file information is from before the |
| | | reported change |
+------+----------+-------------------------------------------------+
fstype
Optional. The type of file system the file resides on. This
attribute governs how path names and other attributes are
interpreted.
+------+---------+-------------------------------------+
| Rank | Keyword | Description |
+------+---------+-------------------------------------+
| 0 | ufs | Berkeley Unix Fast File System |
| 1 | efs | Linux "efs" file system |
| 2 | nfs | Network File System |
| 3 | afs | Andrew File System |
| 4 | ntfs | Windows NT File System |
| 5 | fat16 | 16-bit Windows FAT File System |
| 6 | fat32 | 32-bit Windows FAT File System |
| 7 | pcfs | "PC" (MS-DOS) file system on CD-ROM |
| 8 | joliet | Joliet CD-ROM file system |
| 9 | iso9660 | ISO 9660 CD-ROM file system |
+------+---------+-------------------------------------+
file-type
Optional. The type of file, as a mime-type.
Debar, et al. Experimental [Page 70]
RFC 4765 The IDMEF March 2007
4.2.7.6.1. The FileAccess Class
The FileAccess class represents the access permissions on a file.
The representation is intended to be useful across operating systems.
The FileAccess class is composed of two aggregate classes, as shown
in Figure 23.
+--------------+
| FileAccess |
+--------------+ +------------+
| |<>----------| UserId |
| | +------------+
| | 1..* +------------+
| |<>----------| Permission |
| | +------------+
+--------------+
Figure 23: The FileAccess Class
The aggregate classes that make up FileAccess are:
UserId
Exactly one. The user (or group) to which these permissions
apply. The value of the "type" attribute must be "user-privs",
"group-privs", or "other-privs" as appropriate. Other values for
"type" MUST NOT be used in this context.
Debar, et al. Experimental [Page 71]
RFC 4765 The IDMEF March 2007
Permission
One or more. ENUM. Level of access allowed. The permitted
values are shown below. There is no default value. (See also
Section 10.)
+------+-------------------+----------------------------------------+
| Rank | Keyword | Description |
+------+-------------------+----------------------------------------+
| 0 | noAccess | No access at all is allowed for this |
| | | user |
| | | |
| 1 | read | This user has read access to the file |
| | | |
| 2 | write | This user has write access to the file |
| | | |
| 3 | execute | This user has the ability to execute |
| | | the file |
| | | |
| 4 | search | This user has the ability to search |
| | | this file (applies to "execute" |
| | | permission on directories in Unix) |
| | | |
| 5 | delete | This user has the ability to delete |
| | | this file |
| | | |
| 6 | executeAs | This user has the ability to execute |
| | | this file as another user |
| | | |
| 7 | changePermissions | This user has the ability to change |
| | | the access permissions on this file |
| | | |
| 8 | takeOwnership | This user has the ability to take |
| | | ownership of this file |
+------+-------------------+----------------------------------------+
The "changePermissions" and "takeOwnership" strings represent those
concepts in Windows. On Unix, the owner of the file always has
"changePermissions" access, even if no other access is allowed for
that user. "Full Control" in Windows is represented by enumerating
the permissions it contains. The "executeAs" string represents the
set-user-id and set-group-id features in Unix.
Debar, et al. Experimental [Page 72]
RFC 4765 The IDMEF March 2007
This is represented in the IDMEF DTD as follows:
4.2.7.6.2. The Linkage Class
The Linkage class represents file system connections between the file
described in the element and other objects in the file system.
For example, if the element is a symbolic link or shortcut,
then the element should contain the name of the object the
link points to. Further information can be provided about the object
in the element with another element, if appropriate.
The Linkage class is composed of three aggregate classes, as shown in
Figure 24.
+--------------+
| Linkage |
+--------------+ +------+
| |<>----------| name |
| | +------+
| | +------+
| |<>----------| path |
| | +------+
| | +------+
| |<>----------| File |
| | +------+
+--------------+
Figure 24: The Linkage Class
The aggregate classes that make up Linkage are:
name
Exactly one. STRING. The name of the file system object, not
including the path.
Debar, et al. Experimental [Page 73]
RFC 4765 The IDMEF March 2007
path
Exactly one. STRING. The full path to the file system object,
including the name. The path name should be represented in as
"universal" a manner as possible, to facilitate processing of the
alert.
File
Exactly one. A element may be used in place of the
and elements if additional information about the file is to
be included.
This is represented in the IDMEF DTD as follows:
Debar, et al. Experimental [Page 74]
RFC 4765 The IDMEF March 2007
The Linkage class has one attribute:
category
The type of object that the link describes. The permitted values
are shown below. There is no default value. (See also
Section 10.)
+------+---------------+--------------------------------------------+
| Rank | Keyword | Description |
+------+---------------+--------------------------------------------+
| 0 | hard-link | The element represents another name |
| | | for this file. This information may be |
| | | more easily obtainable on NTFS file |
| | | systems than others. |
| | | |
| 1 | mount-point | An alias for the directory specified by |
| | | the parent's and elements. |
| | | |
| 2 | reparse-point | Applies only to Windows; excludes symbolic |
| | | links and mount points, which are specific |
| | | types of reparse points. |
| | | |
| 3 | shortcut | The file represented by a Windows |
| | | "shortcut". A shortcut is distinguished |
| | | from a symbolic link because of the |
| | | difference in their contents, which may be |
| | | of importance to the manager. |
| | | |
| 4 | stream | An Alternate Data Stream (ADS) in Windows; |
| | | a fork on MacOS. Separate file system |
| | | entity that is considered an extension of |
| | | the main . |
| 5 | symbolic-link | The element represents the file to |
| | | which the link points. |
+------+---------------+--------------------------------------------+
Debar, et al. Experimental [Page 75]
RFC 4765 The IDMEF March 2007
4.2.7.6.3. The Inode Class
The Inode class is used to represent the additional information
contained in a Unix file system i-node.
The Inode class is composed of six aggregate classes, as shown in
Figure 25.
+--------------+
| Inode |
+--------------+ +----------------+
| |<>----------| change-time |
| | +----------------+
| | +----------------+
| |<>----------| number |
| | +----------------+
| | +----------------+
| |<>----------| major-device |
| | +----------------+
| | +----------------+
| |<>----------| minor-device |
| | +----------------+
| | +----------------+
| |<>----------| c-major-device |
| | +----------------+
| | +----------------+
| |<>----------| c-minor-device |
| | +----------------+
+--------------+
Figure 25: The Inode Class
The aggregate classes that make up Inode are:
change-time
Zero or one. DATETIME. The time of the last inode change, given
by the st_ctime element of "struct stat".
number
Zero or one. INTEGER. The inode number.
major-device
Zero or one. INTEGER. The major device number of the device the
file resides on.
Debar, et al. Experimental [Page 76]
RFC 4765 The IDMEF March 2007
minor-device
Zero or one. INTEGER. The minor device number of the device the
file resides on.
c-major-device
Zero or one. INTEGER. The major device of the file itself, if it
is a character special device.
c-minor-device
Zero or one. INTEGER. The minor device of the file itself, if it
is a character special device.
Note that , , and must be given
together, and the and must be given
together.
This is represented in the IDMEF DTD as follows:
Debar, et al. Experimental [Page 77]
RFC 4765 The IDMEF March 2007
4.2.7.6.4. The Checksum Class
The Checksum class represents checksum information associated with
the file. This checksum information can be provided by file
integrity checkers, among others.
The checksum class is composed of two aggregate classes, as shown in
Figure 26.
+--------------+
| Checksum |
+--------------+ +-------+
| algorithm |<>----------| value |
| | +-------+
| | 0..1+-------+
| |<>----------| key |
| | +-------+
+--------------+
Figure 26: The Checksum Class
The aggregate classes that make up Checksum are:
value
Exactly one. STRING. The value of the checksum.
key
Zero or one. STRING. The key to the checksum, if appropriate.
This is represented in the IDMEF DTD as follows:
Debar, et al. Experimental [Page 78]
RFC 4765 The IDMEF March 2007
The Checksum class has one attribute:
algorithm
The cryptographic algorithm used for the computation of the
checksum. The permitted values are shown below. There is no
default value. (See also Section 10.)
+------+----------+------------------------------------------+
| Rank | Keyword | Description |
+------+----------+------------------------------------------+
| 0 | MD4 | The MD4 algorithm. |
| | | |
| 1 | MD5 | The MD5 algorithm. |
| | | |
| 2 | SHA1 | The SHA1 algorithm. |
| | | |
| 3 | SHA2-256 | The SHA2 algorithm with 256 bits length. |
| | | |
| 4 | SHA2-384 | The SHA2 algorithm with 384 bits length. |
| | | |
| 5 | SHA2-512 | The SHA2 algorithm with 512 bits length. |
| | | |
| 6 | CRC-32 | The CRC algorithm with 32 bits length. |
| | | |
| 7 | Haval | The Haval algorithm. |
| | | |
| 8 | Tiger | The Tiger algorithm. |
| | | |
| 9 | Gost | The Gost algorithm. |
+------+----------+------------------------------------------+
5. Extending the IDMEF
As intrusion detection systems evolve, the IDMEF data model and DTD
will have to evolve along with them. To allow new features to be
added as they are developed, both the data model and the DTD can be
extended as described in this section. As these extensions mature,
they can then be incorporated into future versions of the
specification.
5.1. Extending the Data Model
There are two mechanisms for extending the IDMEF data model,
inheritance and aggregation:
o Inheritance denotes a superclass/subclass type of relationship
where the subclass inherits all the attributes, operations, and
Debar, et al. Experimental [Page 79]
RFC 4765 The IDMEF March 2007
relationships of the superclass. This type of relationship is
also called a "is-a" or "kind-of" relationship. Subclasses may
have additional attributes or operations that apply only to the
subclass and not to the superclass.
o Aggregation is a form of association in which the whole is related
to its parts. This type of relationship is also referred to as a
"part-of" relationship. In this case, the aggregate class
contains all of its own attributes and as many of the attributes
associated with its parts as required and specified by occurrence
indicators.
Of the two mechanisms, inheritance is preferred, because it preserves
the existing data model structure and also preserves the operations
(methods) executed on the classes of the structure.
Note that the rules for extending the IDMEF DTD (see below) set
limits on the places where extensions to the data model may be made.
5.2. Extending the IDMEF DTD
There are two ways to extend the IDMEF DTD:
1. The AdditionalData class (see Section 4.2.4.6) allows
implementors to include arbitrary "atomic" data items (integers,
strings, etc.) in an Alert or Heartbeat message. This approach
SHOULD be used whenever possible. See Section 7.4 and
Section 7.5.
2. The AdditionalData class allows implementors to extend the IDMEF
DTD with additional DTD "modules" that describe arbitrarily
complex data types and relationships. The remainder of this
section describes this extension method.
To extend the IDMEF DTD with a new DTD "module", the following steps
MUST be followed:
1. The document declaration MUST define a DTD location that defines
the namespace and contains the location of the extension DTD, and
then reference that namespace.
2. Multiple extensions may be included by defining multiple
namespaces and DTD locations, and referencing them.
3. Extension DTDs MUST declare all of their elements and attributes
in a separate XML namespace. Extension DTDs MUST NOT declare any
elements or attributes in the "idmef" or default namespaces.
Debar, et al. Experimental [Page 80]
RFC 4765 The IDMEF March 2007
4. Extensions MUST only be included in IDMEF Alert and Heartbeat
messages under an element whose "type" attribute
contains the value "xml". For example:
In this example, the "vendorco" namespace is defined and then
referenced, causing the DTD for the extension to be read by the XML
parser.
...
content element of example
See Section 7.8 for another example of extending the IDMEF DTD.
6. Special Considerations
This section discusses some of the special considerations that must
be taken into account by implementors of the IDMEF.
6.1. XML Validity and Well-Formedness
It is expected that IDMEF-compliant applications will not normally
include the IDMEF DTD itself in their communications. Instead, the
DTD will be referenced in the document type definition in the IDMEF
message. Such IDMEF documents will be well-formed and valid as
defined in [3].
Other IDMEF documents will be specified that do not include the
document prolog (e.g., entries in an IDMEF-format database). Such
IDMEF documents will be well-formed but not valid.
Debar, et al. Experimental [Page 81]
RFC 4765 The IDMEF March 2007
Generally, well-formedness implies that a document has a single
element that contains everything else (e.g., "") and that all
the other elements nest nicely within each other without any
overlapping (e.g., a "chapter" does not start in the middle of
another "chapter").
Validity further implies that not only is the document well-formed,
but it also follows specific rules (contained in the Document Type
Definition) about which elements are "legal" in the document, how
those elements nest within other elements, and so on (e.g., a
"chapter" does not begin in the middle of a "title"). A document
cannot be valid unless it references a DTD.
XML processors are required to be able to parse any well-formed
document, valid or not. The purpose of validation is to make the
processing of that document (what's done with the data after it's
parsed) easier. Without validation, a document may contain elements
in nonsense order, elements "invented" by the author that the
processing application doesn't understand, and so forth.
IDMEF documents MUST be well-formed. IDMEF documents SHOULD be valid
whenever both possible and practical.
6.2. Unrecognized XML Tags
On occasion, an IDMEF-compliant application may receive a well-
formed, or even well-formed and valid, IDMEF message containing tags
that it does not understand. The tags may be either:
o Recognized as "legitimate" (a valid document), but the application
does not know the semantic meaning of the element's content; or
o Not recognized at all.
IDMEF-compliant applications MUST continue to process IDMEF messages
that contain unknown tags, provided that such messages meet the well-
formedness requirement of Section 6.1. It is up to the individual
application to decide how to process (or ignore) any content from the
unknown elements(s).
6.3. Analyzer-Manager Time Synchronization
Synchronization of time-of-day clocks between analyzers and managers
is outside the scope of this document. However, the following
comments and suggestions are offered:
Debar, et al. Experimental [Page 82]
RFC 4765 The IDMEF March 2007
1. Whenever possible, all analyzers and managers should have their
time-of-day clocks synchronized to an external source such as NTP
[7] or SNTP [8] Global Positioning System (GPS), Geosynchronous
Operational Environmental Satellite (GOES), NIST radio station
WWV clocks, or some other reliable time standard.
2. When external time synchronization is not possible, the IDMEF
provides the element, which may be used to perform
rudimentary time synchronization (see below).
3. IDMEF-compliant applications SHOULD permit the user to enable/
disable the method of time synchronization as a
configuration option.
A number of caveats apply to the use of for time
synchronization:
1. works best in a "flat" environment where analyzers
report up to a single level of managers. When a tree topology of
high-level managers, intermediate relays, and analyzers is used,
the problem becomes more complex.
2. When intermediate message relays (managers or otherwise) are
involved, two scenarios are possible:
* The intermediaries may forward entire IDMEF messages, or may
perform aggregation or correlation, but MUST NOT inject delay.
In this case, time synchronization is end-to-end between the
analyzer and the highest-level manager.
* The intermediaries may inject delay, due to storage or
additional processing. In this case, time synchronization
MUST be performed at each hop. This means each intermediary
must decompose the IDMEF message, adjust all time values, and
then reconstruct the message before sending it on.
3. When the environment is mixed, with some analyzers and managers
using external time synchronization and some not, all managers
and intermediaries must perform synchronization.
This is because determining whether or not compensation is
actually needed between two parties rapidly becomes very complex,
and requires knowledge of other parts of the topology.
4. If an alert can take alternate paths, or be stored in multiple
locations, the recorded times may be different depending on the
path taken.
Debar, et al. Experimental [Page 83]
RFC 4765 The IDMEF March 2007
The above being said, synchronization is probably
still better than nothing in many environments. To implement this
type of synchronization, the following procedure is suggested:
1. When an analyzer or manager sends an IDMEF message, it should
place the current value of its time-of-day clock in an
element. This should occur as late as possible in
the message transmission process, ideally right before the
message is "put on the wire".
2. When a manager receives an IDMEF message, it should compute the
difference between its own time-of-day clock and the time in the
element of the message. This difference should
then be used to adjust the times in the and
elements (NTP timestamps should also be adjusted).
3. If the manager is an intermediary and sends the IDMEF message on
to a higher-level manager, and hop-by-hop synchronization is in
effect, it should regenerate the value to contain
the value of its own time-of-day clock.
6.4. NTP Timestamp Wrap-Around
From [8]:
Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of the integer part) has been set and that
the 64-bit field will overflow some time in 2036 (second
4,294,967,296). Should NTP or SNTP be in use in 2036, some
external means will be necessary to qualify time relative to 1900
and time relative to 2036 (and other multiples of 136 years).
There will exist a 200-picosecond interval, henceforth ignored,
every 136 years when the 64-bit field will be 0, which by
convention is interpreted as an invalid or unavailable timestamp.
IDMEF-compliant applications MUST NOT send a zero-valued NTP
timestamp unless they mean to indicate that it is invalid or
unavailable. If an IDMEF-compliant application must send an IDMEF
message at the time of rollover, the application should wait for 200
picoseconds until the timestamp will have a non-zero value.
Also from [8]:
As the NTP timestamp format has been in use for the last 17 years,
it remains a possibility that it will be in use 40 years from now
when the seconds field overflows. As it is probably inappropriate
to archive NTP timestamps before bit 0 was set in 1968, a
Debar, et al. Experimental [Page 84]
RFC 4765 The IDMEF March 2007
convenient way to extend the useful life of NTP timestamps is the
following convention:
If bit 0 is set, the UTC time is in the range 1968-2036 and UTC
time is reckoned from 0h 0m 0s UTC on 1 January 1900.
If bit 0 is not set, the time is in the range 2036-2104 and UTC
time is reckoned from 6h 28m 16s UTC on 7 February 2036.
Note that when calculating the correspondence, 2000 is not a leap
year. Note also that leap seconds are not counted in the
reckoning.
IDMEF-compliant applications in use after 2036-02-07T06:28:16Z MUST
adhere to the above convention.
6.5. Digital Signatures
Standard XML digital signature processing rules and syntax are
specified in [13]. XML Signatures provide integrity, message
authentication, and/or signer authentication services for data of any
type, whether located within the XML that includes the signature or
elsewhere.
The IDMEF requirements document [2] assigns responsibility for
message integrity and authentication to the communications protocol,
not the message format. However, in situations where IDMEF messages
are exchanged over other, less secure protocols, or in cases where
the digital signatures must be archived for later use, the inclusion
of digital signatures within an IDMEF message itself may be
desirable.
Specifications for the use of digital signatures within IDMEF
messages are outside the scope of this document. However, if such
functionality is needed, use of the XML Signature standard is
RECOMMENDED.
7. Examples
The examples shown in this section demonstrate how the IDMEF is used
to encode alert data. These examples are for illustrative purposes
only, and do not necessarily represent the only (or even the "best")
way to encode these particular alerts. These examples should not be
taken as guidelines on how alerts should be classified.
Debar, et al. Experimental [Page 85]
RFC 4765 The IDMEF March 2007
7.1. Denial-of-Service Attacks
The following examples show how some common denial-of-service attacks
could be represented in the IDMEF.
7.1.1. The "teardrop" Attack
Network-based detection of the "teardrop" attack. This shows the
basic format of an alert.
Headquarters DMZ Network
analyzer01.example.com
2000-03-09T10:01:25.93464-05:00
badguy.example.net
192.0.2.50
255.255.255.255
0xde796f70
124
http://www.securityfocus.com/bid/124
Debar, et al. Experimental [Page 86]
RFC 4765 The IDMEF March 2007
7.1.2. The "ping of death" Attack
Network-based detection of the "ping of death" attack. Note the
identification of multiple targets, and the identification of the
source as a spoofed address.
NOTE: The URL has been cut to fit the IETF formating requirements.
sensor.example.com
2000-03-09T10:01:25.93464Z
192.0.2.200
192.0.2.50
lollipop
Cabinet B10
Cisco.router.b10
Debar, et al. Experimental [Page 87]
RFC 4765 The IDMEF March 2007
CVE-1999-128
http://www.cve.mitre.org/cgi-bin/
cvename.cgi?name=CVE-1999-128
7.2. Port Scanning Attacks
The following examples show how some common port scanning attacks
could be represented in the IDMEF.
7.2.1. Connection to a Disallowed Service
Host-based detection of a policy violation (attempt to obtain
information via "finger"). Note the identification of the target
service, as well as the originating user (obtained, e.g., through RFC
1413 [11]).
sensor.example.com
2000-03-09T18:47:25+02:00
192.0.2.200
badguy
31532
Debar, et al. Experimental [Page 88]
RFC 4765 The IDMEF March 2007
myhost
192.0.2.50
finger
79
finger
http://www.vendor.com/finger
Distributed attack
http://www.vendor.com/distributed
7.2.2. Simple Port Scanning
Network-based detection of a port scan. This shows detection by a
single analyzer; see Section 7.5 for the same attack as detected by a
correlation engine. Note the use of to show the ports
that were scanned.
Headquarters Web Server
analyzer62.example.com
2000-03-09T15:31:00-08:00
Debar, et al. Experimental [Page 89]
RFC 4765 The IDMEF March 2007
192.0.2.200
www.example.com
192.0.2.50
5-25,37,42,43,53,69-119,123-514
portscan
http://www.vendor.com/portscan
7.3. Local Attacks
The following examples show how some common local host attacks could
be represented in the IDMEF.
7.3.1. The "loadmodule" Attack
Host-based detection of the "loadmodule" exploit. This attack
involves tricking the "loadmodule" program into running another
program; since "loadmodule" is set-user-id "root", the executed
program runs with super-user privileges. Note the use of and
to identify the user attempting the exploit and how he's
doing it.
Debar, et al. Experimental [Page 90]
RFC 4765 The IDMEF March 2007
fileserver.example.com
monitor
8956
monitor
-d
-m
idmanager.example.com
-l
/var/logs/idlog
2000-03-09T08:12:32.3-05:00
joe
13243
loadmodule
/usr/openwin/bin
fileserver.example.com
33
http://www.securityfocus.com
Debar, et al. Experimental [Page 91]
RFC 4765 The IDMEF March 2007
The Intrusion Detection System (IDS) could also indicate that the
target user is the "root" user, and show the attempted command; the
alert might then look like:
fileserver.example.com
monitor
8956
monitor
-d
-m
idmanager.example.com
-l
/var/logs/idlog
2000-03-09T08:12:32.3-05:00
joe
13243
loadmodule
/usr/openwin/bin
fileserver.example.com
root
0
Debar, et al. Experimental [Page 92]
RFC 4765 The IDMEF March 2007
sh
25134
/bin/sh
Note that the identification of the classification is used.
7.3.2. The "phf" Attack
Network-based detection of the "phf" attack. Note the use of the
element to provide more details about this particular
attack.
sensor.example.com
2000-03-09T08:12:32-01:00
192.0.2.200
21534
www.example.com
Debar, et al. Experimental [Page 93]
RFC 4765 The IDMEF March 2007
192.0.2.100
8080
http://www.example.com/cgi-bin/phf?/etc/group
/cgi-bin/phf
GET
629
http://www.securityfocus.com/bid/629
7.3.3. File Modification
Host-based detection of a race condition attack. Note the use of the
to provide information about the files that are used to
perform the attack.
etude
192.0.2.1
Debar, et al. Experimental [Page 94]
RFC 4765 The IDMEF March 2007
2000-03-09T08:12:32-01:00
console
192.0.2.1
local
192.0.2.1
456
fred
456
456
xxx000238483
/tmp/xxx000238483
alice
777
user
42
Debar, et al. Experimental [Page 95]
RFC 4765 The IDMEF March 2007
world
passwd
/etc/passwd
DOM race condition
file://attack-info/race.html
7.4. System Policy Violation
In this example, logins are restricted to daytime hours. The alert
reports a violation of this policy that occurs when a user logs in a
little after 10:00 pm. Note the use of to provide
information about the policy being violated.
dialserver.example.com
2000-03-09T22:18:07-05:00
Debar, et al. Experimental [Page 96]
RFC 4765 The IDMEF March 2007
127.0.0.1
4325
mainframe.example.com
louis
501
login
23
out-of-hours activity
http://my.company.com/policies
2000-03-09T07:00:00-05:00
2000-03-09T19:30:00-05:00
Debar, et al. Experimental [Page 97]
RFC 4765 The IDMEF March 2007
7.5. Correlated Alerts
The following example shows how the port scan alert from
Section 7.2.2 could be represented if it had been detected and sent
from a correlation engine, instead of a single analyzer.
correlator01.example.com
2000-03-09T15:31:07Z
192.0.2.200
www.example.com
192.0.2.50
5-25,37,42,43,53,69-119,123-514
portscan
http://www.vendor.com/portscan
multiple ports in short time
123456781
123456782
Debar, et al. Experimental [Page 98]
RFC 4765 The IDMEF March 2007
123456783
123456784
123456785
123456786
987654321
987654322
7.6. Analyzer Assessments
Host-based detection of a successful unauthorized acquisition of root
access through the eject buffer overflow. Note the use of
to provide information about the analyzer's evaluation
of and reaction to the attack.
2000-03-09T08:12:32-01:00
console
192.0.2.1
local
192.0.2.1
456
Debar, et al. Experimental [Page 99]
RFC 4765 The IDMEF March 2007
root
0
0
eject
32451
/usr/bin/eject
\x90\x80\x3f\xff...\x08/bin/sh
Unauthorized user to superuser
file://attack-info/u2s.html
page
disabled user (fred)
logout user (fred)
7.7. Heartbeat
This example shows a Heartbeat message that provides "I'm alive and
working" information to the manager. Note the use of
elements, with "meaning" attributes, to provide some
additional information.
Debar, et al. Experimental [Page 100]
RFC 4765 The IDMEF March 2007
Headquarters DMZ Network
analyzer01.example.com
2000-03-09T14:07:58Z
62.5
87.1
7.8. XML Extension
The following example shows how to extend the IDMEF DTD. In the
example, the VendorCo company has decided it wants to add geographic
information to the Node class. To do this, VendorCo creates a
Document Type Definition or DTD that defines how their class will be
formatted:
Intrusion Detection Message Exchange Format (IDMEF) Extension
for geographic information
The VendorCo:NodeGeography class will contain the geographic data in
three aggregate classes, VendorCo:latitude, VendorCo:longitude, and
VendorCo:elevation. To associate the information in this class with
a particular node, the "VendorCo:node-ident" attribute is provided;
it must contain the same value as the "ident" attribute on the
relevant Node element.
To make use of this DTD now, VendorCo follows the rules in
Section 5.2 and defines a parameter entity called "x-vendorco" within
the Document Type Definition, and then references this entity. In
the alert, the VendorCo elements are included under the
AdditionalData element, with a "type" attribute of "xml", as shown
below.
Headquarters DMZ Network
analyzer01.example.com
2000-03-09T10:01:25.93464-05:00
Debar, et al. Experimental [Page 102]
RFC 4765 The IDMEF March 2007
badguy.example.net
192.0.2.50
255.255.255.255
0xde796f70
124
http://www.securityfocus.com/bid/124
38.89
-77.02
Debar, et al. Experimental [Page 103]
RFC 4765 The IDMEF March 2007
8. The IDMEF Document Type Definition (Normative)
Debar, et al. Experimental [Page 104]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 105]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 107]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 110]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 111]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 114]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 115]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 116]
RFC 4765 The IDMEF March 2007
9. Security Considerations
This document describes a data representation for exchanging
security-related information between intrusion detection system
implementations. Although there are no security concerns directly
applicable to the format of this data, the data itself may contain
security-sensitive information whose confidentiality, integrity,
and/or availability may need to be protected.
Debar, et al. Experimental [Page 117]
RFC 4765 The IDMEF March 2007
This suggests that the systems used to collect, transmit, process,
and store this data should be protected against unauthorized use and
that the data itself should be protected against unauthorized access.
The means for achieving this protection are outside the scope of this
document.
Section 5 of [2] describes the required and recommended security
characteristics of the transmission protocol that will be used to
deliver IDMEF data from analyzers to managers. These requirements
include message confidentiality, message integrity, non-repudiation,
and avoidance of duplicate messages. Both standard and proposed
protocols exist that provide these features.
Where a protocol that does not meet the requirements of Section 5 of
[2] is used to exchange IDMEF messages, it may be desirable to use
digital signatures to certify the integrity of these messages; this
is discussed in Section 6.5 of this document.
10. IANA Considerations
Section 5 describes how to use the AdditionalData class to include
arbitrary "atomic" data items in an IDMEF message, as well as how
AdditionalData may be used to extend the DTD itself by adding new
classes and attributes.
From time to time, it may be desirable to move an extension from its
private or local use status (as all extensions made via the above
mechanism are) to "standard" status that should be supported by all
implementations.
This may be accomplished as described in this section.
10.1. Adding Values to Existing Attributes
Several of the attributes specified in this document have lists of
permissible values that they may contain. To allow the addition of
new values to these lists, the IANA created a repository for
attribute values called "Intrusion Detection Message Exchange Format
(IDMEF) Attribute Values".
Following the policies outlined in [9], this repository is
"Specification Required" by RFC. Section 10.1.1 describes the
initial values for this repository.
Debar, et al. Experimental [Page 118]
RFC 4765 The IDMEF March 2007
To create a new attribute, you MUST publish an RFC to document the
type. In the RFC, include a copy of the registration template found
in Section 10.1.2 of this document. Put the template in your IANA
Considerations section, filling in the appropriate fields. You MUST
describe any interoperability and security issues in your document.
When adding a new attribute value to the repository, the IANA shall
assign the next rank number in numerical sequence for the value.
10.1.1. Attribute Registrations
IDMEF Class Name: Reference
IDMEF Attribute Name: origin
Registered Values:
+------+-----------------+------------------------------------------+
| Rank | Keyword | Description |
+------+-----------------+------------------------------------------+
| 0 | unknown | Origin of the name is not known |
| 1 | vendor-specific | A vendor-specific name (and hence, URL); |
| | | this can be used to provide |
| | | product-specific information |
| 2 | user-specific | A user-specific name (and hence, URL); |
| | | this can be used to provide |
| | | installation-specific information |
| 3 | bugtraqid | The SecurityFocus ("Bugtraq") |
| | | vulnerability database identifier |
| | | (http://www.securityfocus.com/bid) |
| 4 | cve | The Common Vulnerabilities and Exposures |
| | | (CVE) name (http://cve.mitre.org/) |
| 5 | osvdb | The Open Source Vulnerability Database |
| | | (http://www.osvdb.org) |
+------+-----------------+------------------------------------------+
Debar, et al. Experimental [Page 119]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Source
IDMEF Attribute Name: spoofed
Registered Values:
+------+---------+----------------------------------------+
| Rank | Keyword | Description |
+------+---------+----------------------------------------+
| 0 | unknown | Accuracy of source information unknown |
| 1 | yes | Source is believed to be a decoy |
| 2 | no | Source is believed to be "real" |
+------+---------+----------------------------------------+
IDMEF Class Name: Target
IDMEF Attribute Name: decoy
Registered Values:
+------+---------+----------------------------------------+
| Rank | Keyword | Description |
+------+---------+----------------------------------------+
| 0 | unknown | Accuracy of target information unknown |
| 1 | yes | Target is believed to be a decoy |
| 2 | no | Target is believed to be "real" |
+------+---------+----------------------------------------+
Debar, et al. Experimental [Page 120]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: AdditionalData
IDMEF Attribute Name: type
Registered Values:
+------+-------------+----------------------------------------------+
| Rank | Keyword | Description |
+------+-------------+----------------------------------------------+
| 0 | boolean | The element contains a boolean value, i.e., |
| | | the strings "true" or "false" |
| 1 | byte | The element content is a single 8-bit byte |
| | | (see Section 3.2.4) |
| 2 | character | The element content is a single character |
| | | (see Section 3.2.3) |
| 3 | date-time | The element content is a date-time string |
| | | (see Section 3.2.6) |
| 4 | integer | The element content is an integer (see |
| | | Section 3.2.1) |
| 5 | ntpstamp | The element content is an NTP timestamp (see |
| | | Section 3.2.7) |
| 6 | portlist | The element content is a list of ports (see |
| | | Section 3.2.8) |
| 7 | real | The element content is a real number (see |
| | | Section 3.2.2) |
| 8 | string | The element content is a string (see |
| | | Section 3.2.3) |
| 9 | byte-string | The element content is a byte[] (see |
| | | Section 3.2.4) |
| 10 | xmltext | The element content is XML-tagged data (see |
| | | Section 5.2) |
+------+-------------+----------------------------------------------+
Debar, et al. Experimental [Page 121]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Impact
IDMEF Attribute Name: severity
Registered Values:
+------+---------+-----------------------------------------+
| Rank | Keyword | Description |
+------+---------+-----------------------------------------+
| 0 | info | Alert represents informational activity |
| | | |
| 1 | low | Low severity |
| | | |
| 2 | medium | Medium severity |
| | | |
| 3 | high | High severity |
+------+---------+-----------------------------------------+
IDMEF Class Name: Impact
IDMEF Attribute Name: completion
Registered Values:
+------+-----------+--------------------------------+
| Rank | Keyword | Description |
+------+-----------+--------------------------------+
| 0 | failed | The attempt was not successful |
| 1 | succeeded | The attempt succeeded |
+------+-----------+--------------------------------+
Debar, et al. Experimental [Page 122]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Impact
IDMEF Attribute Name: type
Registered Values:
+------+---------+--------------------------------------------------+
| Rank | Keyword | Description |
+------+---------+--------------------------------------------------+
| 0 | admin | Administrative privileges were attempted or |
| | | obtained |
| 1 | dos | A denial of service was attempted or completed |
| 2 | file | An action on a file was attempted or completed |
| 3 | recon | A reconnaissance probe was attempted or |
| | | completed |
| 4 | user | User privileges were attempted or obtained |
| 5 | other | Anything not in one of the above categories |
+------+---------+--------------------------------------------------+
IDMEF Class Name: Action
IDMEF Attribute Name: category
Registered Values:
+------+-------------------+----------------------------------------+
| Rank | Keyword | Description |
+------+-------------------+----------------------------------------+
| 0 | block-installed | A block of some sort was installed to |
| | | prevent an attack from reaching its |
| | | destination. The block could be a |
| | | port block, address block, etc., or |
| | | disabling a user account. |
| 1 | notification-sent | A notification message of some sort |
| | | was sent out-of-band (via pager, |
| | | e-mail, etc.). Does not include the |
| | | transmission of this alert. |
| 2 | taken-offline | A system, computer, or user was taken |
| | | offline, as when the computer is shut |
| | | down or a user is logged off. |
| 3 | other | Anything not in one of the above |
| | | categories. |
+------+-------------------+----------------------------------------+
Debar, et al. Experimental [Page 123]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Confidence
IDMEF Attribute Name: rating
Registered Values:
+------+---------+--------------------------------------------------+
| Rank | Keyword | Description |
+------+---------+--------------------------------------------------+
| 0 | low | The analyzer has little confidence in its |
| | | validity |
| 1 | medium | The analyzer has average confidence in its |
| | | validity |
| 2 | high | The analyzer has high confidence in its validity |
| 3 | numeric | The analyzer has provided a posterior |
| | | probability value indicating its confidence in |
| | | its validity |
+------+---------+--------------------------------------------------+
IDMEF Class Name: Node
IDMEF Attribute Name: category
Registered Values:
+------+----------+------------------------------------------+
| Rank | Keyword | Description |
+------+----------+------------------------------------------+
| 0 | unknown | Domain unknown or not relevant |
| 1 | ads | Windows 2000 Advanced Directory Services |
| 2 | afs | Andrew File System (Transarc) |
| 3 | coda | Coda Distributed File System |
| 4 | dfs | Distributed File System (IBM) |
| 5 | dns | Domain Name System |
| 6 | hosts | Local hosts file |
| 7 | kerberos | Kerberos realm |
| 8 | nds | Novell Directory Services |
| 9 | nis | Network Information Services (Sun) |
| 10 | nisplus | Network Information Services Plus (Sun) |
| 11 | nt | Windows NT domain |
| 12 | wfw | Windows for Workgroups |
+------+----------+------------------------------------------+
Debar, et al. Experimental [Page 124]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Address
IDMEF Attribute Name: category
Registered Values:
+------+---------------+--------------------------------------------+
| Rank | Keyword | Description |
+------+---------------+--------------------------------------------+
| 0 | unknown | Address type unknown |
| 1 | atm | Asynchronous Transfer Mode network address |
| 2 | e-mail | Electronic mail address (RFC 822) |
| 3 | lotus-notes | Lotus Notes e-mail address |
| 4 | mac | Media Access Control (MAC) address |
| 5 | sna | IBM Shared Network Architecture (SNA) |
| | | address |
| 6 | vm | IBM VM ("PROFS") e-mail address |
| 7 | ipv4-addr | IPv4 host address in dotted-decimal |
| | | notation (a.b.c.d) |
| 8 | ipv4-addr-hex | IPv4 host address in hexadecimal notation |
| 9 | ipv4-net | IPv4 network address in dotted-decimal |
| | | notation, slash, significant bits |
| | | (a.b.c.d/nn) |
| 10 | ipv4-net-mask | IPv4 network address in dotted-decimal |
| | | notation, slash, network mask in |
| | | dotted-decimal notation (a.b.c.d/w.x.y.z) |
| 11 | ipv6-addr | IPv6 host address |
| 12 | ipv6-addr-hex | IPv6 host address in hexadecimal notation |
| 13 | ipv6-net | IPv6 network address, slash, significant |
| | | bits |
| 14 | ipv6-net-mask | IPv6 network address, slash, network mask |
+------+---------------+--------------------------------------------+
Debar, et al. Experimental [Page 125]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: User
IDMEF Attribute Name: category
Registered Values:
+------+-------------+------------------------------------+
| Rank | Keyword | Description |
+------+-------------+------------------------------------+
| 0 | unknown | User type unknown |
| 1 | application | An application user |
| 2 | os-device | An operating system or device user |
+------+-------------+------------------------------------+
IDMEF Class Name: UserId
IDMEF Attribute Name: category
Registered Values:
+------+---------------+--------------------------------------------+
| Rank | Keyword | Description |
+------+---------------+--------------------------------------------+
| 0 | current-user | The current user id being used by the user |
| | | or process. On Unix systems, this would |
| | | be the "real" user id, in general. |
| 1 | original-user | The actual identity of the user or process |
| | | being reported on. On those systems that |
| | | (a) do some type of auditing and (b) |
| | | support extracting a user id from the |
| | | "audit id" token, that value should be |
| | | used. On those systems that do not |
| | | support this, and where the user has |
| | | logged into the system, the "login id" |
| | | should be used. |
| 2 | target-user | The user id the user or process is |
| | | attempting to become. This would apply, |
| | | on Unix systems for example, when the user |
| | | attempts to use "su", "rlogin", "telnet", |
| | | etc. |
Debar, et al. Experimental [Page 126]
RFC 4765 The IDMEF March 2007
| 3 | user-privs | Another user id the user or process has |
| | | the ability to use, or a user id |
| | | associated with a file permission. On |
| | | Unix systems, this would be the |
| | | "effective" user id in a user or process |
| | | context, and the owner permissions in a |
| | | file context. Multiple UserId elements of |
| | | this type may be used to specify a list of |
| | | privileges. |
| 4 | current-group | The current group id (if applicable) being |
| | | used by the user or process. On Unix |
| | | systems, this would be the "real" group |
| | | id, in general. |
| 5 | group-privs | Another group id the group or process has |
| | | the ability to use, or a group id |
| | | associated with a file permission. On |
| | | Unix systems, this would be the |
| | | "effective" group id in a group or process |
| | | context, and the group permissions in a |
| | | file context. On BSD-derived Unix |
| | | systems, multiple UserId elements of this |
| | | type would be used to include all the |
| | | group ids on the "group list". |
| 6 | other-privs | Not used in a user, group, or process |
| | | context, only used in the file context. |
| | | The file permissions assigned to users who |
| | | do not match either the user or group |
| | | permissions on the file. On Unix systems, |
| | | this would be the "world" permissions. |
+------+---------------+--------------------------------------------+
IDMEF Class Name: File
IDMEF Attribute Name: category
Registered Values:
+------+----------+-------------------------------------------------+
| Rank | Keyword | Description |
+------+----------+-------------------------------------------------+
| 0 | current | The file information is from after the reported |
| | | change |
| 1 | original | The file information is from before the |
| | | reported change |
+------+----------+-------------------------------------------------+
Debar, et al. Experimental [Page 127]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: File
IDMEF Attribute Name: fstype
Registered Values:
+------+---------+-------------------------------------+
| Rank | Keyword | Description |
+------+---------+-------------------------------------+
| 0 | ufs | Berkeley Unix Fast File System |
| 1 | efs | Linux "efs" file system |
| 2 | nfs | Network File System |
| 3 | afs | Andrew File System |
| 4 | ntfs | Windows NT File System |
| 5 | fat16 | 16-bit Windows FAT File System |
| 6 | fat32 | 32-bit Windows FAT File System |
| 7 | pcfs | "PC" (MS-DOS) file system on CD-ROM |
| 8 | joliet | Joliet CD-ROM file system |
| 9 | iso9660 | ISO 9660 CD-ROM file system |
+------+---------+-------------------------------------+
IDMEF Class Name: FileAccess
IDMEF Attribute Name: permission
Registered Values:
+------+-------------------+----------------------------------------+
| Rank | Keyword | Description |
+------+-------------------+----------------------------------------+
| 0 | noAccess | No access at all is allowed for this |
| | | user |
| 1 | read | This user has read access to the file |
| 2 | write | This user has write access to the file |
| 3 | execute | This user has the ability to execute |
| | | the file |
| 4 | search | This user has the ability to search |
| | | this file (applies to "execute" |
| | | permission on directories in Unix) |
| 5 | delete | This user has the ability to delete |
| | | this file |
| 6 | executeAs | This user has the ability to execute |
| | | this file as another user |
| 7 | changePermissions | This user has the ability to change |
| | | the access permissions on this file |
| 8 | takeOwnership | This user has the ability to take |
| | | ownership of this file |
+------+-------------------+----------------------------------------+
Debar, et al. Experimental [Page 128]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Linkage
IDMEF Attribute Name: category
Registered Values:
+------+---------------+--------------------------------------------+
| Rank | Keyword | Description |
+------+---------------+--------------------------------------------+
| 0 | hard-link | The element represents another name |
| | | for this file. This information may be |
| | | more easily obtainable on NTFS file |
| | | systems than others. |
| 1 | mount-point | An alias for the directory specified by |
| | | the parent's and elements. |
| 2 | reparse-point | Applies only to Windows; excludes symbolic |
| | | links and mount points, which are specific |
| | | types of reparse points. |
| 3 | shortcut | The file represented by a Windows |
| | | "shortcut". A shortcut is distinguished |
| | | from a symbolic link because of the |
| | | difference in their contents, which may be |
| | | of importance to the manager. |
| 4 | stream | An Alternate Data Stream (ADS) in Windows; |
| | | a fork on MacOS. Separate file system |
| | | entity that is considered an extension of |
| | | the main . |
| 5 | symbolic-link | The element represents the file to |
| | | which the link points. |
+------+---------------+--------------------------------------------+
Debar, et al. Experimental [Page 129]
RFC 4765 The IDMEF March 2007
IDMEF Class Name: Checksum
IDMEF Attribute Name: algorithm
Registered Values:
+------+----------+------------------------------------------+
| Rank | Keyword | Description |
+------+----------+------------------------------------------+
| 0 | MD4 | The MD4 algorithm. |
| 1 | MD5 | The MD5 algorithm. |
| 2 | SHA1 | The SHA1 algorithm. |
| 3 | SHA2-256 | The SHA2 algorithm with 256 bits length. |
| 4 | SHA2-384 | The SHA2 algorithm with 384 bits length. |
| 5 | SHA2-512 | The SHA2 algorithm with 512 bits length. |
| 6 | CRC-32 | The CRC algorithm with 32 bits length. |
| 7 | Haval | The Haval algorithm. |
| 8 | Tiger | The Tiger algorithm. |
| 9 | Gost | The Gost algorithm. |
+------+----------+------------------------------------------+
10.1.2. Registration Template
IDMEF Class Name:
IDMEF Attribute Name:
New Attribute Value to Be Defined:
Meaning of New Attribute Value:
Contact Person and E-Mail Address:
Debar, et al. Experimental [Page 130]
RFC 4765 The IDMEF March 2007
10.2. Adding New Attributes and Classes
To the extent possible, the IDMEF classes and attributes specified in
this document have been designed to accommodate all current and near-
future needs. Although it is recognized that the addition of new
classes, as well as the addition of new attributes to existing
classes, will be necessary in the future, these actions should not be
taken lightly.
Any addition of new attributes or classes should only be undertaken
when the current classes and attributes simply cannot be used to
represent the information in a "clean" way -- and such additions
should only be made to represent generally-useful types of data.
Vendor-specific information, obscure information provided by only a
particular type of analyzer or used only by a particular type of
manager, "pet" attributes, and the like are not good reasons to make
class and attribute additions.
At the time this RFC was written, the first anticipated case for
which new classes and attributes will need to be added is to handle
host-based intrusion detection systems. However, such additions
should not be made until some level of consensus has been reached
about the set of data that will be provided by these systems.
Following the policies outlined in [9], the addition of new classes
and attributes to the IDMEF requires "IETF Consensus".
To add new attributes or classes, you MUST publish an RFC to document
them, and get that RFC approved by the IESG. Typically, the IESG
will seek input on prospective additions from appropriate persons
(e.g., a relevant working group if one exists). You MUST describe
any interoperability and security issues in your document.
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Wood, M. and M. Erlinger, "Intrusion Detection Mesage Exchange
Requirements", RFC 4766, March 2007.
Debar, et al. Experimental [Page 131]
RFC 4765 The IDMEF March 2007
[3] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium
FirstEdition http://www.w3.org/TR/2000/REC-xml-20001006,
October 2000.
[4] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML",
World Wide Web Consortium
Recommendation http://www.w3.org/TR/1999/
REC-xml-names-19990114, January 1999.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[6] International Organization for Standardization, "Data elements
and interchange formats - Information interchange -
Representation of dates and times", ISO Standard 8601, Second
Edition, December 2000.
[7] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[8] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330, January 2006.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[10] Phillips, A. and M. Davis, "Tags for Identifying Languages",
BCP 47, RFC 4646, September 2006.
11.2. Informative References
[11] St. Johns, M., "Identification Protocol", RFC 1413,
February 1993.
[12] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[13] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[14] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling
Language Reference Model", ISBN 020130998X, 1998.
Debar, et al. Experimental [Page 132]
RFC 4765 The IDMEF March 2007
[15] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[16] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence
between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework", BCP 74,
RFC 3584, August 2003.
Debar, et al. Experimental [Page 133]
RFC 4765 The IDMEF March 2007
Appendix A. Acknowledgements
The following individuals contributed substantially to this document
and should be recognized for their efforts. This document would not
exist without their help:
Dominique Alessandri, IBM Corporation
Spencer Allain, Teknowledge Corporation
James L. Burden, California Independent Systems Operator
Marc Dacier, IBM Corporation
Oliver Dain, MIT Lincoln Laboratory
Nicolas Delon, Prelude Hybrid IDS project
David J. Donahoo, AFIWC
Michael Erlinger, Harvey Mudd College
Reinhard Handwerker, Internet Security Systems, Inc.
Ming-Yuh Huang, The Boeing Company
Glenn Mansfield, Cyber Solutions, Inc.
Joe McAlerney, Silicon Defense
Cynthia McLain, MIT Lincoln Laboratory
Paul Osterwald, Intrusion.com
Jean-Philippe Pouzol
James Riordan, IBM Corporation
Paul Sangree, Cisco Systems
Stephane Schitter, IBM Corporation
Michael J. Slifcak, Trusted Network Technologies, Inc.
Steven R. Snapp, CyberSafe Corporation
Stuart Staniford-Chen, Silicon Defense
Michael Steiner, University of Saarland
Maureen Stillman, Nokia IP Telephony
Vimal Vaidya, AXENT
Yoann Vandoorselaere, Prelude Hybrid IDS project
Andy Walther, Harvey Mudd College
Andreas Wespi, IBM Corporation
John C. C. White, MITRE
Eric D. Williams, Information Brokers, Inc.
S. Felix Wu, University of California Davis
Debar, et al. Experimental [Page 134]
RFC 4765 The IDMEF March 2007
Appendix B. The IDMEF Schema Definition (Non-normative)
Intrusion Detection Message Exchange Format (IDMEF) Version 1.0
Debar, et al. Experimental [Page 136]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 139]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 140]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 141]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 154]
RFC 4765 The IDMEF March 2007
Debar, et al. Experimental [Page 155]
RFC 4765 The IDMEF March 2007
Authors' Addresses
Herve Debar
France Telecom R & D
42 Rue des Coutures
Caen 14000
FR
Phone: +33 2 31 75 92 61
EMail: herve.debar@orange-ftgroup.com
URI: http://www.francetelecom.fr/
David A. Curry
Guardian Life Insurance Company of America
7 Hanover Square, 24th Floor
New York, NY 10004
US
Phone: +1 212 919-3086
EMail: david_a_curry@glic.com
URI: http://www.glic.com/
Benjamin S. Feinstein
SecureWorks, Inc.
PO Box 95007
Atlanta, GA 30347
US
Phone: +1 404 327-6339
Email: bfeinstein@acm.org
URI: http://www.secureworks.com/
Debar, et al. Experimental [Page 156]
RFC 4765 The IDMEF March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Debar, et al. Experimental [Page 157]
RFC, FYI, BCP