======================================================================= Managed Incident Lightweight Exchange (mile) Working Group Minutes for IETF 85, Atlanta Tuesday 6 November 2012, 15:20 - 16:50 Salon E Chairs: Kathleen Moriarty Brian Trammell Thanks to Chris Inacio and David Waltermire for taking notes! Started and ended on time. ======================================================================= 1. Agenda-bashing and WG status ------------------------------- - Looking for input into RFC5070-bis. Work with Omar Santos et al. to provide feedback on possible areas of work. - No takers on offer for someone to pick up data markers: will leave on charter and drop on recharter, if there's interest we can re-add later. - C. Inacio will have a forensics -02 draft for Orlando - We'll wait for 5070-bis and IODEF-Guidance individual drafts, then make a call for adoption for them and for draft-montville-enum-refernces and draft-field-rolie out on the list. IODEF-extension to support structured cybersecurity information draft-ietf-mile-sci (T. Takahashi) -------------------------------------------------------------------- - Take will switch the focus of this draft to a use case discussion as opposed to what schemas should be integrated. The intent is to engage incident handlers and ensure that the work meets relevant use cases and vendors are able to implement to the relevant use cases. The extensions supported would be determined by what data is needed to represent to focus the effort and hopefully minimize the support levels needed by vendors for interoperable solutions. - Paul Hoffman: IETF doesn't put trademarks in documents; please fix - Sean Turner: concur - Paul: You can have a normative reference to a published document where the best reference is a URL; this is generally acceptable in the IETF and IANA registries. - Kathleen: we can discuss later, changing focus for now to use case enumeration and exploration - Kent: where do we stand on IPR? - Sean: we're good to go - Dave: what has to be in a document for it to be acceptable as a normative reference? - Brian: philosophical answer: definition that is specific enough to allow creation of interoperable implementations. - John Baker: are the URLs adequate or not? - Sean: no, this is decided first by WG consensus, then AD approval, then IESG approval, would be surprised if it would make it through. - Paul: disagrees - Brian: it appears we're going to keep talking about this. let's take it to the list. IODEF Enumeration Reference Format draft-montville-mile-enum-reference-format (A. Montville) -------------------------------------------------------------------- - Chris: clarification: please update the example with the new format and the new table info. How do you know version x.y? Should be before the colon? - Adam Montville - Represented as short name + version as id_type. - Lief Johansson: IANA should have reserved code-points to keep vendors from taking certain protected name. Provide guidance on reserved short names; How do you prevent others from using recognized short names. - Brian: this IANA registry will be 5226 Expert Review - C. Henry Adams - Definition of full and short name? Resource-Oriented Lightweight Indicator Exchange draft-field-mile-rolie (J. Field) -------------------------------------------------------------------- - Reviewed "What is rest?" - Uniform interface using HTTP request types (e.g. GET, HEAD, PUT) - Hypertext links enable access to adjacent resources. - Review high-level goals for ROLIE - Review ROLIE use cases - C. Henry Adams: can the format handle multimedia (sound/video)? - John Field: via media-types in documents via links Reviewed "Technical drivers for ROLIE" - John Field - Message-based architectures more complex to implement vs. REST-based architectures Reviewed "Ease of Adoption" Reviewed slide describing ROI and other characteristics of message-based approached Reviewed "Improved Scalability and Complexity" - Kathleen - Talk about handling updates in the IODEF revision. - John Field - Possible options are 1) new report as a replacement 2) incremental. Expectation that all new responded are the "latest". Essentially, use needs to detect change. Review "Sharing Agreements & Security Profiles" - John Field - Caveat - Coordination is needed between source and destination. Essentially MAC with labels vs. DAC. Review Distributed Message -based Security" - John Field - IHS - Incident Handling System - John Field - How do we coordinate authorization needs? Use frameworks like Spring to determine what appears in a web page. - John Field - Following not in current draft: Review "Security Profile Management" Review "Interoperable Profiles" Review "ROLIE Authorization" - John Fields - SAML, in addition to, XACML used for interoperable policy management. Review "XACML Profile" Reviewed "Relationship to existing RFCs" Reviewed "Next Steps" - Lief: shouldn't take on XACML until you have experience with other auth models first - John Field: Any recommendations? - Lief: Folks with large scale deployments use 3-tuples successfully. Can you find someone to interop test with? Use XAMCL simple authorization models first. Triplet models of application, role and scope. MIT has a system named "permit?". - John Field - Need a way to expression the authorization profile in a machine readable way to enable automation. Draft provides examples of exchanging using Atom for this approach to better understand authorization scenarios. - Adam: need a statement of which verbs are supported. - Adam: Need REST security considerations. Extension of Atom for incident response. Consider taking the repository "core" into another effort, maybe in APPS area. - Adam: if this is really just a content repository extended for incident response, why not a different area e.g. apps? - Dave: +1 -- more generalization and move to apps? reiterate: work is important regardless. - Brian: please submit next revision, take to list about adoption and for new charter item. Other Business: --------------- Peter St. Andre: on the subject of other transports, there might be an XMPP binding, if there's interest would be willing to help. Lief: project (name missing) is doing exactly this, IODEFish info over XMPP. Brian - (As RID transport editor) This is great work. Current transport is very simple. This provides a lot more. Kathleen - Some communities use "abuse helper". If we could map out requirements and use cases, that might help. We may want to tie in XMPP for "chat". Paul: note incident info drove atompub two years ago.