2.5.5 Intrusion Detection Exchange Format (idwg)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


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:

Apr 99


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

Working Group Meeting Minutes, 48th IETF

The IDWG met at 0900 on both Thursday and Friday of the 48th IETF meeting in Pittsburgh PA.

1. General status
2. XML document
3. XML - SNMP mapping
4. Charter changes
5. Intrusion Alert Protocol
6. Data Model Issues

First meeting - 3 August 2000

Mike Erlinger spoke first, on the status of some elements of the IDWG's work:

1. The IDWG mailing list will stay at IBM Zurich, although Herve Debar has moved from there. The recent flurry of comments on the mailing list has resulted partly from DARPA interest in the IDWG work. They have encouraged ID-related activities they sponsor to participate.

2. The requirements document was accidentally not forwarded to the IESG for comment. This has now been done, and a new version, incorporating IESG comments, will be out to the mailing list by 21 August. Comments will then be accepted, but only regarding changes related to the IESG comments. Goal is publication as an informational RFC in October 2000 (more on the schedule later).

3. Hervé will continue to develop the Data Model document. It needs to stay in sync with the XML document.

4. The XML/SMI comparison document will be out for last call about 1 September. It is intended as an informational RFC, essentially as an historical record.

David Curry spoke about the XML document. He first reviewed its history and the reasoning behind the IDWG decision to use XML. The current spec is the one dated 6 July. It follows the data model, with the following exceptions:

1. The model uses inheritance, but XML DTD's don't support it (though schemas do). No substantive effect.
2. <Heartbeat> has been added.
3. <AdditionalData> has been added for extension.
4. <DetectTime> and <AnalyzerTime> have been added.
5. <portlist> has been added to support multiple port numbers.

The main changes in the document from the previous version are:
1. Query and Response are gone.
2. NTP timestamps have been added (it was agreed that the inclusion of both humanly readable and NTP timestamps is inelegant, but pragmatically useful).
3. Real numbers now support exponents.
4. XML digital signatures are now expressly permitted.

The possibility of migrating from the DTD to an XML Schema was discussed. XML Schemas add data typing, inheritance, and constraints on content, which DTD's cannot specify. Consensus was that Schemas are more attractive in the long run, but that they are quite new, still subject to change, and not many tools support them yet. The advice of XML mavens will be sought as to whether and when the changeover should be made.

There was some discussion about the adequacy of the document (and the model) to support host-based ID systems, since the developers are more expert on network-based approaches. John White agreed to post some host-based XML examples to the mailing list, since he has found it necessary to use <AdditionalData> in almost every case.

Glenn Mansfield discussed the mapping from the XML representation to an SMI-MIB. The requirement is for a one-to-one mapping between the two. The MIB is structured as a set of tables, with rows indexed. He plans to do some experimentation, to develop a set of conventions for the mapping, but he sees no problems there. His goal is to produce drafts of the MIB and a mapping document by the end of August; they are specifically intended a suggestions, not as standards, so they will be intended as informational or experimental RFC's. The question of the impact (on indexing of the MIB tables)of default (i.e., 0) alert id's was raised. Consensus was that it would be appropriate to require unique alert id's although the scope of the uniqueness was vague (more on this later).

Mike Erlinger then proposed, and the group agreed to, some changes to the group's charter, specifically to the dates mentioned there since some of them are past.

1. Requirements document - Informational RFC to IESG 1 October 2000 (Mike, working with Mark Wood).
2. XML/SMI comparison document - Informational RFC to IESG 1 October 2000.
3. Data Model and XML documents - IDWG last call 15 October 2000, proposed RFC's to IESG 1 November 2000, new version before the 49th IETF in December.
4. IAP - proposed RFC 15 November 2000.

Potential future issues for the WG are expected to be command and control, and sensor to analyzer standards.

The meeting was then adjourned for the day.

Second meeting - 4 August 2000

Dipankar Gupta spoke about the Intrusion Alert Protocol (IAP), which is intended to move alerts from analyzers to consoles. He described the security/integrity requirements for the protocol, and the stages the protocol goes through to meet them. Some specific desirable attributes of IAP are that it allows the use of long-lived TCP sessions, that it permits session establishment from either end, that it is proxy-friendly, and that it allows TLS session resumption.

The following issues were discussed:

1. Should we use HTTP? Although it would allow use of available tools, it requires that contact be initiated by the client, and it has many features which would go unused. Consensus was that IAP is more appropriate; it was also noted that the use of the message format doesn't mandate the use of IAP.

2. What about command and control? Port usage discipline may require that the same channel be used as for IAP, but the draft doesn't specify how to do that. This may be dealt with later, and suggestions are welcome.

3. Retry and heartbeat. Should the draft address how to reestablish a lost connection? There is a compromise needed between defense against a malicious attacker and being a good net citizen. Should the heartbeat be mandatory? Consensus was that it should be available, but not required; some sensors send too much data already. It was also pointed out that the heartbeat could flow in either direction.

4. There are some questions about the strength of the connection between the PKI certificate identity and the analyzer's identity which need to be resolved, or at least clarified.

Some questions (and answers):

1. What about DoS attacks against IAP/TCP? There are documented practical measures against SYN attacks, and malicious insertion of RST requires guessing the sequence number, so it is thought that the vulnerability is acceptably low.

2. Why not use IPSec? Packets are often in the clear outside an IPSec tunnel, so transport-mode IPSec would be needed, which is atypical.

3. What about Blocks Extensible Exchange Protocol (beep)? The IETF BEEP working group is developing a standards-track application protocol framework for connection-oriented, asynchronous request/response interactions. We should be aware of their work.

The goal for the next draft of the IAP document is early September.

Stuart Staniford presented a list of twenty data model issues, most of which were raised recently via the mailing list. Some of them had previously been discussed, and Stuart followed the principle of not re-opening old issues in the absence of compelling reasons to do so.

Issue 1: The time of alert does not allow for start and stop times, detection and report times, perhaps others. Should there be the option of start and end times whenever time is specified? Is an enumeration needed (for XML)? Too many different times give problems to correlators.

Post-processors may be far from real time, so arrival time isn't always known.
Resolution: Alert creation time will be required. Other times will be optional.

Issue 2: The impact attribute is not well-defined.
Resolution: Previously discussed.

Issue 3: The model provides poor support for anomaly detectors (e.g., what was anomalous?)
Resolution: The IDWG awaits a good proposal for handling this.

Issue 4: ToolAlert names are not a standardized enumeration, just a string.
Resolution: Unfortunately, no standardized list is known. The names will have value in a mono-vendor environment, at least, so for now no change.

Issue 5: Lack of ID state management.
Resolution: Previously discussed.

Issue 6: Lack of Effective UID etc. fields for UNIX. Do we need to model each OS separately? {real|audit|effective}uid?
Resolution: A better model is needed. David and Glenn will pursue this.

Issue 7: Lack of portlists in the Service class.
Resolution: Add to the model, to match the XML.

Issue 8: Lack of support for other than alerts.
Resolution: Previously discussed.

Issue 9: OverflowAlert is too specific; maybe SNMPAlert and WebAlert are also. How does the analyzer know the buffer size? The positive side of these specific alert types is that they allow additional data to be specified which is related to the particular kind of exploit.
Resolution: None at the time; this should be taken up on the mailing list.

Issue 10: Thread id's are needed, to allow updates or connections to previous alerts. Correlation alert could do this, but doesn't seem to at present.
Resolution: An attribute of {replaces|updates|is related to} is also needed. Mike will make a proposal to the mailing list.

Issue 11: Classification should not be mandatory, as there may be no known vulnerability.
Resolution: Leave as is, vendor-specific names may be used.

Issue 12: Service class lacks support for RPC, maybe other service classes also (e.g., CORBA).
Resolution: Ask Todd Heberlein (who raised the issue) for suggestions.

Issue 13: TODO sections not done.
Resolution: Hervé will do them.

Issue 14: The scope of the uniqueness requirement for alert id's is unclear.
Resolution: Global uniqueness is desired; Dipankar will make a proposal.

Issue 15: Some guidance is needed on use of the impact field.
Resolution: Stuart will make a proposal.

Issue 16: Both name and URL are mandatory in classification. This is excessive, especially for CVE and Bugtraq.
Resolution: Require URL only for vendor-specific cases, not for CVE and Bugtraq.

Issue 17: How to provide required access to CERT Advisory numbers (Requirements 7.3)?
Resolution: Requirements have been clarified, this is no longer a problem.

Issue 18: How to provide reference to underlying details of events (Requirements 7.4)?
Resolution: Possibilities include a "MoreInfo" URL, use of <AdditionalData>, some kind of reachback. Putting the requirement on IAP would violate layering, and be a bad idea. This will be left unresolved for now.

Issue 19: How to provide information about automated response taken by an IDS (Requirements 7.8)?
Resolution: Fix the requirements document.

Issue 20: How to provide information about analyzer brand/model (Requirements 7.10)?
Resolution: Add the information to the Analyzer class.

Finally, Stuart mentioned that he will be presenting a paper "IDWG:
Progress towards an open IDS alert standard" at the RAID2000 conference, which will be held in Toulouse, France, 2-4 October 2000.

The meeting was adjourned at about 1130.

Respectfully submitted,
John C. C. White


None received.