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 model - new Date-Time representation - new DTD extension mechanism for blobs with the "type=3Dxml" attribute name-value pair - has a single element and can be defined under and -
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. - and were removed, moving and 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 b.tabbaa@pentasafe.com 713-523-1992