Incident Handling (INCH) WG Minutes
IETF 57 - Wednesday, 15.30-17.30, July 16, 2003
Vienna, Austria
Chair: Roman Danyliw <rdd@cert.org>
Security Area Advisor: Steven Bellovin <smb@research.att.com>
---[ Agenda ]-----------------------------------------------------------
o Administrative (Roman Danyliw)
o Data model requirements (Glenn Mansfield Keeni)
- draft-ietf-inch-requirements-01
o Data Model
- draft-ietf-inch-iodef-01 (Jan Meijer)
- XML Schema migration (Yuri Demchenko)
o Implementation Guide (Roman Danyliw)
---[ Administrative ]---------------------------------------------------
presenter: Roman Danyliw
o Steve Bellovin is the new security area adviser to the working group
o Updates to the schedule were made to reflect a slight slippage in the delivery dates (WG last-call) of the WG drafts.
] SEP 03 Initial I-D of the implementation guidelines document
] NOV 03 Submit requirements I-D to the IESG as Informational
] NOV 03 Submit incident data language specification I-D to the IESG as Proposed Standard
] FEB 04 Submit implementation guidelines I-D to the IESG as Informational
---[ Requirements ]-----------------------------------------------------
presenter: Glenn Mansfield Keeni
[1] http://www.andrew.cmu.edu/~rdanyliw/inch/ietf57/ietf57-inch-req.ppt
Keeni presented the remaining open issues in the requirement draft in [1].
Comments and Discussion:
o There is a need for continued discussion of the domain-specific definitions found in Section #3.
- "Impact" reflects a non-technical results on an organization (e.g., loss of customers). On the other hand, "Damage" is a technical impact of an "Attack" on a host (e.g., denial of service).
- Is the definition of "Incident" sufficiently broad to encompass the destruction of information? Yes.
- There appears to be a lack of symmetric in the definitions. If a "Target" and "Victim" are defined, then a corresponding "Source" and "Attacker" must also be added.
- Reuse definitions from other sources. If a term is used in other standards, cite that reference, and provide a description as to why the term is slightly different in the INCH domain.
o The requirements should more clearly reflect the need for multi-lingual text. A proposed change to support this need can be found at: <http://nic.surfnet.nl/scripts/wa.exe?A2=ind03&L=inch&F=&S=&P=14060>
- Provide a requirement that translations (multiple versions of the same text in different languages) of text must be consistent.
o A requirement to deal with time corrections should be added.
The situation of concern is how to convey that a host has their clock set incorrectly.
o The term "data owner" used in several requirements is unclear; expound upon this definition. Does this term refer to the "owner" as the source of the data? person acting on the data?
o Certain terms defined in the requirements draft are NOT used in the data model
o There was some discussion on the time format of FINE: explicitly UTC, or to allow local timezone. Ultimately, it was decided to support only UTC, or a local format easily convertible to UTC.
---[ Data Model ]-------------------------------------------------------
presenter: Jan Meijer
[2] http://www.andrew.cmu.edu/~rdanyliw/inch/ietf57/ietf57-inch-dm.ppt
Meijer presented a review of the open issues related to the current data model in [2].
That said, the data model is beginning to stabilize. There have been no substantial changes (or proposed changes) in the past 4-months. The remaining work is in:
o migrating the current XML DTD implementation to Schema
o addressing remaining issues with multi-lingual free-form text
o examining and further enumerating certain enumerated attribute values
o codifying the semantics of document updates, and making any appropriate data model changes that might be necessary
- At a minimum this will require a careful examination of which fields are explicitly required (rather than optional)
o fully integrating XML-Signature and XML-Encryption
o confirming that all FINE requirements are being met
o proof reading of the text
A new draft incorporating an initial implementation in XML Schema, and all current pending issues will be complete by September 2003. This draft will still include the DTD implementation to ease the transition.
Comments and Discussion:
o Supporting multi-lingual free-form text remains an open issues.
A thread on the particular details can be found at:<http://nic.surfnet.nl/scripts/wa.exe?A2=ind03&L=inch&F=&S=&P=13967>
o The use of terms defined in the requirements document should be consistent with the data model document
---[ XML Security in the IODEF ]----------------------------------------
presenter: Yuri Demchenko
[3] http://www.andrew.cmu.edu/~rdanyliw/inch/ietf57/ietf57-inch-iodef-xmlschema.ppt
Demchenko provided a migration strategy for the data model to XML Schema in [3].
Comments and Discussion
o Many suggestions to the data model were proposed in the presentation. However, not all are explicitly required to make the transition to XML Schema. Yuri was asked to separate the suggested changes from those explicitly required for the migration.
---[ Implementation Guide ]---------------------------------------------
presenter: Roman Danyliw
[4] http://www.andrew.cmu.edu/~rdanyliw/inch/ietf57/ietf57-inch-iguide.ppt
Danyliw presented an overview of the main topics to discuss in the implementation guide in [4]. No draft for this document exists, but an initial version should be complete by September 2003.
The following topics were suggested for inclusion in the draft:
o examples of IDMEF messages included in an IODEF document
o best practices in CSIRT data exchange protocols
o an interoperability matrix, when a sufficient number of implementations are available