2.6.5 Intrusion Detection Exchange Format (idwg)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Michael Erlinger <mike@cs.hmc.edu>
Stuart Staniford-Chen <stanifor@cs.ucdavis.edu>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:idwg-public@zurich.ibm.com
To Subscribe: idwg-public-request@zurich.ibm.com
Archive: http://www.semper.org/idwg-public/

Description of Working Group:

Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress.

The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them. The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups.
The outputs of this working group will be:
1. A requirements document, which describes the high-level functional requirements for communication between intrusion detection systems and requirements for communication between intrusion detection systems and with management systems, including the rationale for those requirements. Scenarios will be used to illustrate the requirements.
2. A common intrusion language specification, which describes data formats that satisfy the requirements.
3. A framework document, which identifies existing protocols best used for communication between intrusion detection systems, and describes how the devised data formats relate to them.

Goals and Milestones:



Submit Requirements document as an Internet-Draft

Aug 99


Submit Framework and Language documents as Internet-Drafts

Aug 99


Submit Requirements document to IESG for consideration as an RFC.

Dec 99


Submit Framework and Language documents to IESG for consideration as RFCs.

No Request For Comments

Current Meeting Report

Meeting Minutes, 50th IETF.
INTRUSION DETECTION Working Group (IDWG) of the Security Area.

The IDWG met at 0900 on Wednesday and Thursday of the 50th IETF meeting in Minneapolis, MN.

First Session - 21 March 2000

The first presentation covered updates to the Intrusion Alert Protocol (IAP). It was presented by Greg Matthews and Ben Feinstein. (see posted presentation slides) Changes include: - "Source" header was added.

Issues raised:
- TLS session resumption: the answer depends on the underlying implementation of SSL. Ben noted that OpenSSL (http://www.openssl.org) performs session resumption. Sun's SSL implementation in Java and it does this as well.


The second presentation discussed the Intrusion Detection eXchange Protocol (IDXP) based on the Blocks Extensible Exchange Protocol (BEEP). Greg and Ben made the presentation (see posted presentation slides for details).


The third presentation concerned a BEEP profile for tunneling via proxies and was delivered by Darren New. The discussion focused on:

- addressing the next "hop" in the tunnel. This can be done by "source routing", e.g., (1) IP+port, (2) FQDN+port, (3) FQDN+SRV or by "hop-by-hop" using (1) a profile URI or (2) endpoint URI.
- security by hop. Authentication at the end-to-proxy and proxy-to-proxy points can be added in addition to the end-to-end security as dictated by BEEP's use SASL and TLS.
- also mentioned was encryption by hop, but the tunnel author recommended against this approach

The TUNNEL profile is an Internet Draft


The fourth presentation given by Mike Erlinger discussed issues recently raised by Glenn Mansfield in the IDWG requirements document.

Issue: Activity vs attack definition consistency
Resolution: None

Issue: Scenario removal/modification
Resolution: None

Issue: MUST/SHOULD references and relationship to RFC 2119
Resolution: Leave as is.

Issue: Should the trust model be explicitly expressed as a requirement or delegated to the protocol design?
Resolution: Stuart noted that the requirement of proxy tunneling presupposes a trust model. Ben suggested leaving it up to the protocol. Herve said the protocol should define the trust model.
Resolution: Requirements Doc will contain words indicating that the trust model is left to the protocol to define.

Issue: Language dealing with firewall mgmt.
Resolution: Instead of "to send IDMEF messages through the firewalls", the following alternatives were suggested:
- "to relay messages via proxy across the firewalls"
- "to transport messages across the firewalls"

Issue: IPSec and authentication
Resolution: Herve suggested the following "application-layer authentication is required irrespective of the underlying transport layer".

Issue: What are authoritative names for events as opposed to attacks? Suppose different analyzers reported the "same" event/attack to the manager. Is this unacceptable?
Resolution: We can't enforce this [yet]. So it is our intention and not yet a requirement.

Issue: What is a "device"?
Resolution: "A device is a uniquely addressable element on the network."
This is no less inclusive but clearer than saying "a device is anything that is involved in intrusion detection".

Issue: Should a standard list of "impact" values be specified?
Resolution: No.

Issue: Activity vs attack uniqueness
Resolution: Move section 8.2 into section 7. Delete the rest of = section 8.

Action Item:
Mike will create a new version of the Requirements Document and post by 1 May. With the idea of WG last call and consensus by 13 May.


The last presentation discussed the commonalities of the Incident Object Description and Exchange Format (IODEF) and Intrusion Detection Message Exchange Format (IDMEF) (see posted presentation).

Yuri Demchenko updated the IDWG on Terena's IODEF work. The suggestion was made to factor out common objects in a separate DTD. The question of whether IODEF and its underlying requirements should be pursued by IDWG was put to the group. The consensus was that the IDWG focus on completing the transport and alert format.

The session was then adjourned for the day at about 1130.

Second Session - 22 March 2000


Greg and Ben compared IAP and IDXP. The differences mentioned:
- philosophy: IAP looks like HTTP and custom defines proxying. IDXP offers more choices based on BEEP-profile.
- security cost amortization: BEEP allows you to pay the cost of authentication and negotiation of a secure transport layer once for potentially m BEEP channels running with a single BEEP session. For example, many configuration and alert data exchanges (each with potentially different ID roles) could be performed using a separate channel for each excehange in the same BEEP session.

The consensus was that IAP should remain an Internet Draft as is; it will NOT be upgraded to an informational or experimental draft for the purposes of avoiding expiration unless IDXP and TUNNEL prove themselves unworthy of meeting IDWG requirements and member expectations. BEEP SDKs for Jave and Tcl are available from http://www.sourceforge.net. Other information related to BEEP can be found at http://www.beepcore.org

Action Item:
Mike Erlinger will post a similar proposal to the IDWG mail list.
Hopefully consensus will be reached on the future of IAP and IDXP.


Dave Curry presented mods to the data model and XML DTD since the last IDWG meeting in San Diego (see posted presentation). The main points were:

- new <User> model
- new Date-Time representation
- new DTD extension mechanism for <AdditionalData> blobs with the "type=3Dxml" attribute name-value pair
- <Service> has a single <port> element and can be defined under <Target> and <Source>
- <Address> elements now have "vlan-name" and "vlan-number" attributes to accomdate multiple virtual hosts on a single physical host.
- "analyzerid" must be unique across analyzers within the IDS; "ident" replaces all other unique id attributes for the remaining elements.
- <Argument> and <Environment> were removed, moving <arg> and <env> up one level

Two outstanding issues were then debated:
- Bandwidth conservation: There existed the possibility of referencing elements using the "ident", "isref", or "id" attributes, but this presupposed stateful analyzers and managers with a persistent storage mechanism as well as a protocol for querying for and responding with referenced, missing data. The preclusion of "lite" analyzers and managers was considered unacceptable and the work needed to carefully design the query-response protocol expected to be nontrivial.
- Adequacy of uniqueness rules: should "analyzerid" be globally unique? Some suggested this was a configuration issue. Others stressed the importance of global uniqueness for simplifying correlation of alert data. Another question raised was whether this was appropriate in an IDMEF context or an underlying requirements issue. [unresolved?]

The session was adjourned at about 1130.

Respectfully submitted,
Bishr Tabbaa


Intrusion Alert Protocol Presentation
Intrusion Detection Exchange Protocol
Comparing IAP and IDXP
Intrusion Detection Message Exchange Format
TUNNEL: An Application Proxy Profile