mile WG meeting notes Vancouver, BC, Canada July 31, 2012, 3:20p-4:50p (notetaker: David Black) ------------------------- Chairs: Kathleen Moriarty Brian Trammell --- 1. Agenda-bashing and WG status --- Note Well shown. Agenda bashed - no changes. The following drafts have been published: draft-ietf-mile-template -> RFC 6684 draft-ietf-mile-iodef-xmlreg -> RFC 6685 --- 2. Active WG documents --- *** IODEF-extension to support structured cybersecurity information draft-ietf-mile-sci (T. Takahashi) Current version is -04. -- How to handle identifier references Can embed identifiers in SCI draft's extension classes, or could define identifier format/usage in new draft. Next presentation discusses how to format the references. Need to determine whether new draft will modify IODEF::Reference class, as such a change would require corresponding changes in the SCI draft. -- IPR concerns with the SCAP specs Sean Turner (AD) raised IPR concerns with the Mitre SCAP specs. The mandatory to implement spec, CVE, has a problematic IPR status (IPR held by Mitre) that makes CVE unacceptable as a normative reference in a standards-track RFC. This is generally the case for all SCAP specs. It would be better for these SCAP specs to be published as IETF Informational RFCs with change control given to the IETF. Kathleen Moriarty (co-chair) noted that the mandatory to implement requirement for CVE needs to change in any case, as CVE is not a good choice. These concerns will also affect the sacm pre-WG effort. Sean and Kathleen agree that it is procedurally ok for the SCI draft to include specs that are ok for a standards-track RFC to normatively reference, and deal with the rest of the specs as submissions to the registry created by the RFC. The designated expert for the registry (Kathleen) will get to decide on the additional submissions following guidance in the published SCI document, but the initial registry must not be completely empty. The IPR issues include not only copyright, but also trademark (e.g., Mitre owns the "CPE" trademark). To fully support use of the SCAP specs by IETF, Mitre should turn over change control on the specs and the right to use the trademark in order to make them usable in IETF. It's possible to avoid the trademark concerns by renaming the protocol (e.g., it's been done before by IETF for SSH). Kathleen listed some non-Mitre specs - XCCDF can definitely be used, CVSS and CVRF may be possible because they're controlled by consortia, not Mitre. It would be a very good idea for someone to file an IPR notice that says that the relevant documents for these specs are in the public domain - affiliation of the person making that statement will affect the weight assigned to that statement (e.g., by the IESG). XCCDF could be used as the mandatory-to-implement spec, even though its functionality is different from CVE. What to require as mandatory-to-implement will be taken to the list. As things stand, the Mitre specs have to come out of the SCI draft - there's no other choice. Mitre was not present at the meeting to comment and Mitre has been asked about making the SCAP specs usable by the IETF for at least 6 months. Discussion ensued around how to make a stronger request to Mitre. The mile WG can't make a request as a WG - individuals would have to make their own requests. Another possibility is that the formal NFS request to Sun was issued by the IESG - that sort of approach could be tried again. Back to the registry - would an SCI registry with no SCAP specs be useful? This is rather unclear - those SCAP specs are important. There are lots of product implementations of the SCAP specs - CVE in particular is widely implemented/used. Sean (AD) will look into NFS request made to Sun. Next version of draft needs to remove all the problematic Mitre SCAP specs. Need to take discussion to list and in particular determine whether current IANA registration requirements need to be strengthened (e.g., RFC is not currently required - it could be required). *** Formalizing Enumerations via the Reference class in IODEF (A. Montville) Three options for embedding an identifier in the IODEF::Reference class (see slides). Option 3 requires an IODEF change (to RFC 5070), others just provide additional details on how to use the existing IODEF::Reference class. Could use one of the URIs as a mandatory canonical reference to the spec that the identifier comes from. Meeting discussion concludes that this is overkill - not needed as a cross-check because the info in IANA registry ought to suffice. On top of that, expecting that URI to be resolvable is problematic. Media types provide a reasonable example for an IANA registration procedure where the registry entries are compact and there's extensive registration info in the document (typically an RFC) referenced by each registry entry. There was a brief debate about whether to require one of the URIs to refer to the spec that the identifier came from. The clear conclusion was to thoroughly rubbish and discard that idea ... Past list discussion favored option 2 now and option 3 in the future. Kathleen (as individual) suggests that if option 3 is what's wanted, it should be done now as RFC 5070 modification work will start soon (see last item on agenda) Further discussion will be on the mailing list. *** GRC Exchange draft-ietf-mile-grc-exchange (D. Waltermire) Proposed modifications to GRC exchange message types - see slides. Request IDs have to be globally unique. Discussion of what the ActionRequest does - it's a request to gather information for reports that will be requested later (e.g., weeks later). Code and many other things could be embedded in the xs:any block in the Acknowledgement message. Meeting discussion concludes that this is too general, as it enables arbitrary mischief. A whitelist should be used ot explicitly allow what's needed for the use cases of interest. Open issue for list - Are both Report and Acknowledgement messages needed? Details on how a requested report is returned later are TBD. Polling is possible, but probably not the best approach (e.g., an async return of the report would be better). Will query types and report types be included in this draft? Yes, want to use an IANA registry for those purposes.. Next version of the draft will follow approach outlined in slides. --- 4. IODEF Maintenance --- *** Implementation Guidance for IODEF (K. Moriarty) & Updating IODEF Kathleen Moriarty presented on behalf of Reosella Mattioli. This is entirely open questions and suggestions - everything is going to the mailing list for further discussion on what to do. Additional suggestions are welcome, as are suggestions for things in these slides that may not be appropriate to do at this time for some reason. See slides for details, and *please* contribute to the mailing list discussion!! Use cases to which these updates apply are important to being to the mailing list discussion to ensure that the updates made are actually useful. Slide 4: LEA (Law Enforcement Agency) is not a good term - another one needs to be selected. Intent is to have two documents - an IODEF update and a separate guidance document. May need a new WG milestone for this on charter for the IODEF update. Sean (AD): What is scope of effort - extent of changes and use cases covered? Kathleen: Looking to get use cases from groups actively involved in the sort of information sharing that IODEF is used for. Sean:XML vs. JSON? Should IODEF move to JSON? Kathleen: Should preserve IODEF data model, even if XML to JSON change made.