tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4765

Experimental
Pages: 157
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IDWG

The Intrusion Detection Message Exchange Format (IDMEF)

Part 1 of 6, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
      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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
   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

Top      ToC       Page 7 
   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

Top      ToC       Page 8 
   (of the form "name='value'").  But where "<p>" 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:

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
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:

   <?xml version="1.0" encoding="UTF-8"?>

   <idmef:IDMEF-Message version="1.0"
                        xmlns:idmef="http://iana.org/idmef"/>

Top      ToC       Page 11 
   IDMEF-compliant applications MAY choose to omit the XML declaration
   internally to conserve space, adding it only when the message is sent
   to another destination (e.g., a web browser).  This practice is NOT
   RECOMMENDED unless it can be accomplished without loss of each
   message's version and encoding information.

   In order to be valid (see Section 6.1), an XML document must contain
   a document type definition.  However, this represents significant
   overhead to an IDMEF-compliant application, both in the bandwidth it
   consumes as well as the requirements it places on the XML processor
   (not only to parse the declaration itself, but also to parse the DTD
   it references).

   Implementors MAY decide, therefore, to have analyzers and managers
   agree out-of-band on the particular document type definition they
   will be using to exchange messages (the standard one as defined here,
   or one with extensions), and then omit the document type definition
   from IDMEF messages.  The method for negotiating this agreement is
   outside the scope of this document.  Note that great care must be
   taken in negotiating any such agreements, as the manager may have to
   accept messages from many different analyzers, each using a DTD with
   a different set of extensions.

3.1.2.  Character Data Processing in IDMEF

   For portability reasons, IDMEF-compliant applications SHOULD NOT use,
   and IDMEF messages SHOULD NOT be encoded in, character encodings
   other than UTF-8 and UTF-16.  Consistent with the XML standard, if no
   encoding is specified for an IDMEF message, UTF-8 is assumed.

   NOTE:  The ASCII character set is a subset of the UTF-8 encoding, and
      therefore may be used to encode IDMEF messages.

   Per the XML standard, IDMEF documents encoded in UTF-16 MUST begin
   with the Byte Order Mark described by ISO/IEC 10646 Annex E and
   Unicode Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character,
   #xFEFF).

3.1.2.1.  Character Entity References

   It is RECOMMENDED that IDMEF-compliant applications use the entity
   reference form (see Section 3.2.3.1) of the characters '&', ,'<',
   '>', '"', and ''' (single-quote) whenever writing these characters in
   data, to avoid any possibility of misinterpretation.

3.1.2.2.  White Space Processing

   All IDMEF elements MUST support the "xml:space" attribute.

Top      ToC       Page 12 
3.1.3.  Languages in IDMEF

   IDMEF-compliant applications MUST specify the language in which their
   contents are encoded; in general this can be done by specifying the
   "xml:lang" attribute for the top-level element and letting all other
   elements "inherit" that definition [10].

3.2.  IDMEF Data Types

   Within an XML IDMEF message, all data will be expressed as "text" (as
   opposed to "binary"), since XML is a text formatting language.  We
   provide typing information for the attributes of the classes in the
   data model, however, to convey to the reader the type of data that
   the model expects for each attribute.

   Each data type in the model has specific formatting requirements in
   an XML IDMEF message; these requirements are set forth in this
   section.

3.2.1.  Integers

   Integer attributes are represented by the INTEGER data type.  Integer
   data MUST be encoded in Base 10 or Base 16.

   Base 10 integer encoding uses the digits '0' through '9' and an
   optional sign ('+' or '-').  For example, "123", "-456".

   Base 16 integer encoding uses the digits '0' through '9' and 'a'
   through 'f' (or their uppercase equivalents), and is preceded by the
   characters "0x".  For example, "0x1a2b".

3.2.2.  Real Numbers

   Real (floating-point) attributes are represented by the REAL data
   type.  Real data MUST be encoded in Base 10.

   Real encoding is that of the POSIX 1003.1 "strtod" library function:
   an optional sign ('+' or '-') followed by a non-empty string of
   decimal digits, optionally containing a radix character, then an
   optional exponent part.  An exponent part consists of an 'e' or 'E',
   followed by an optional sign, followed by one or more decimal digits.
   For example, "123.45e02", "-567,89e-03".

   IDMEF-compliant applications MUST support both the '.' and ',' radix
   characters.

Top      ToC       Page 13 
3.2.3.  Characters and Strings

   Single-character attributes are represented by the CHARACTER data
   type.  Multi-character attributes of known length are represented by
   the STRING data type.

   Character and string data have no special formatting requirements,
   other than the need to occasionally use character references (see
   Section 3.2.3.1 and Section 3.2.3.2) to represent special characters.

3.2.3.1.  Character Entity References

   Within XML documents, certain characters have special meanings in
   some contexts.  To include the actual character itself in one of
   these contexts, a special escape sequence, called an entity
   reference, must be used.

   The characters that sometimes need to be escaped, and their entity
   references, are:

                     +-----------+------------------+
                     | Character | Entity Reference |
                     +-----------+------------------+
                     |         & | &amp;            |
                     |           |                  |
                     |         < | &lt;             |
                     |           |                  |
                     |         > | &gt;             |
                     |           |                  |
                     |         " | &quot;           |
                     |           |                  |
                     |         ' | &apos;           |
                     +-----------+------------------+

3.2.3.2.  Character Code References

   Any character defined by the ISO/IEC 10646 and Unicode standards may
   be included in an XML document by the use of a character reference.
   A character reference is started with the characters '&' and '#', and
   ended with the character ';'.  Between these characters, the
   character code for the character is inserted.

   If the character code is preceded by an 'x' it is interpreted in
   hexadecimal (base 16); otherwise, it is interpreted in decimal (base
   10).  For instance, the ampersand (&) is encoded as &#38; or &#x0026;
   and the less-than sign (<) is encoded as &#60; or &#x003C;.

Top      ToC       Page 14 
   Any one-, two-, or four-byte character specified in the ISO/IEC 10646
   and Unicode standards can be included in a document using this
   technique.

3.2.4.  Bytes

   Binary data is represented by the BYTE (and BYTE[]) data type.

   Binary data MUST be encoded in its entirety using base64.

3.2.5.  Enumerated Types

   Enumerated types are represented by the ENUM data type, and consist
   of an ordered list of acceptable values.

3.2.6.  Date-Time Strings

   Date-time strings are represented by the DATETIME data type.  Each
   date-time string identifies a particular instant in time; ranges are
   not supported.

   Date-time strings are formatted according to a subset of ISO 8601:
   2000 [6], as show below.  Section references in parentheses refer to
   sections of the ISO 8601:2000 standard [6].

   1.  Dates MUST be formatted as follows:

          YYYY-MM-DD

       where YYYY is the four-digit year, MM is the two-digit month
       (01-12), and DD is the two-digit day (01-31).  (Section 5.2.1.1,
       "Complete representation -- Extended format".)

   2.  Times MUST be formatted as follows:

          hh:mm:ss

       where hh is the two-digit hour (00-24), mm is the two-digit
       minute (00-59), and ss is the two-digit second (00-60).  (Section
       5.3.1.1, "Complete representation -- Extended format".)

       Note that midnight has two representations, 00:00:00 and
       24:00:00.  Both representations MUST be supported by IDMEF-
       compliant applications; however, the 00:00:00 representation
       SHOULD be used whenever possible.

Top      ToC       Page 15 
       Note also that this format accounts for leap seconds.  Positive
       leap seconds are inserted between 23:59:59Z and 24:00:00Z and are
       represented as 23:59:60Z.  Negative leap seconds are achieved by
       the omission of 23:59:59Z.  IDMEF-compliant applications MUST
       support leap seconds.

   3.  Times MAY be formatted to include a decimal fraction of seconds,
       as follows:

          hh:mm:ss.ss or
          hh:mm:ss,ss

       As many digits as necessary may follow the decimal sign (at least
       one digit must follow the decimal sign).  Decimal fractions of
       hours and minutes are not supported.  (Section 5.3.1.3,
       "Representation of decimal fractions".)

       IDMEF-compliant applications MUST support the use of both decimal
       signs ('.' and ',').

       Note that the number of digits in the fraction part does not
       imply anything about accuracy -- i.e., "00.100000", "00,1000",
       and "00.1" are all equivalent.

   4.  Times MUST be formatted to include (a) an indication that the
       time is in Coordinated Universal Time (UTC) or (b) an indication
       of the difference between the specified time and Coordinated
       Universal Time.

       *  Times in UTC MUST be formatted by appending the letter 'Z' to
          the time string as follows:

             hh:mm:ssZ
             hh:mm:ss.ssZ
             hh:mm:ss,ssZ

          (Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended
          format".)

       *  If the time is ahead of or equal to UTC, a '+' sign is
          appended to the time string; if the time is behind UTC, a '-'
          sign is appended.  Following the sign, the number of hours and
          minutes representing the different from UTC is appended, as
          follows:

             hh:mm:ss+hh:mm
             hh:mm:ss-hh:mm
             hh:mm:ss.ss+hh:mm

Top      ToC       Page 16 
             hh:mm:ss.ss-hh:mm
             hh:mm:ss,ss+hh:mm
             hh:mm:ss,ss-hh:mm

          The difference from UTC MUST be specified in both hours and
          minutes, even if the minutes component is 0.  A "difference"
          of "+00:00" is equivalent to UTC.  (Section 5.3.4.2, "Local
          time and the difference with Coordinated Universal Time --
          Extended Format".)

   5.  Date-time strings are created by joining the date and time
       strings with the letter 'T', as shown below:

          YYYY-MM-DDThh:mm:ssZ
          YYYY-MM-DDThh:mm:ss.ssZ
          YYYY-MM-DDThh:mm:ss,ssZ
          YYYY-MM-DDThh:mm:ss+hh:mm
          YYYY-MM-DDThh:mm:ss-hh:mm
          YYYY-MM-DDThh:mm:ss.ss+hh:mm
          YYYY-MM-DDThh:mm:ss.ss-hh:mm
          YYYY-MM-DDThh:mm:ss,ss+hh:mm
          YYYY-MM-DDThh:mm:ss,ss-hh:mm

       (Section 5.4.1, "Complete representation -- Extended format".)

   In summary, IDMEF date-time strings MUST adhere to one of the nine
   templates identified in Paragraph 5, above.

3.2.7.  NTP Timestamps

   NTP timestamps are represented by the NTPSTAMP data type and are
   described in detail in [7] and [8].  An NTP timestamp is a 64-bit
   unsigned fixed-point number.  The integer part is in the first 32
   bits, and the fraction part is in the last 32 bits.

   Within IDMEF messages, NTP timestamps MUST be encoded as two 32-bit
   hexadecimal values, separated by a period ('.').  For example,
   "0x12345678.0x87654321".

   See also Section 6.4 for more information on NTP timestamps.

3.2.8.  Port Lists

   Port lists are represented by the PORTLIST data type and consist of a
   comma-separated list of numbers (individual integers) and ranges (N-M
   means ports N through M, inclusive).  Any combination of numbers and
   ranges may be used in a single list.  For example,
   "5-25,37,42,43,53,69-119,123-514".

Top      ToC       Page 17 
3.2.9.  Unique Identifiers

   There are two types of unique identifiers used in this specification.
   Both types are represented by STRING data types.

   These identifiers are implemented as attributes on the relevant XML
   elements, and they must have unique values as follows:

   1.  The Analyzer class' (Section 4.2.4.1) "analyzerid" attribute, if
       specified, MUST have a value that is unique across all analyzers
       in the intrusion detection environment.

       The "analyzerid" attribute is not required to be globally unique,
       only unique within the intrusion detection environment of which
       the analyzer is a member.  It is permissible for two analyzers,
       in different intrusion detection environments, to have the same
       value for "analyzerid".

       The default value is "0", which indicates that the analyzer
       cannot generate unique identifiers.

   2.  The Alert and Heartbeat messages (Sections 4.2.2, 4.2.3) must be
       uniquely identified by the couple (analyzerid,messageid), if the
       analyzer supports the generation of message identifiers.

   3.  The Classification, Source, Target, Node, User, Process, Service,
       File, Address, and UserId classes' (Sections 4.2.4.2, 4.2.4.3,
       4.2.4.4, 4.2.7.2, 4.2.7.3, 4.2.7.4, 4.2.7.5, 4.2.7.6, 4.2.7.2.1,
       and 4.2.7.3.1) "ident" attribute, if specified, MUST have a value
       that is unique across all messages sent by the individual
       analyzer.

       The "ident" attribute value MUST be unique for each particular
       combination of data identifying an object, not for each object.
       Objects may have more than one "ident" value associated with
       them.  For example, an identification of a host by name would
       have one value, while an identification of that host by address
       would have another value, and an identification of that host by
       both name and address would have still another value.
       Furthermore, different analyzers may produce different values for
       the same information.

       The "ident" attribute by itself provides a unique identifier only
       among all the "ident" values sent by a particular analyzer.  But
       when combined with the "analyzerid" value for the analyzer, a
       value that is unique across the intrusion detection environment
       is created.  Again, there is no requirement for global
       uniqueness.

Top      ToC       Page 18 
       The default value is "0", which indicates that the analyzer
       cannot generate unique identifiers.

   The specification of methods for creating the unique values contained
   in these attributes is outside the scope of this document.



(page 18 continued on part 2)

Next RFC Part