--- 1/draft-ietf-mile-rolie-04.txt 2016-10-31 15:16:11.524589450 -0700 +++ 2/draft-ietf-mile-rolie-05.txt 2016-10-31 15:16:11.596591238 -0700 @@ -1,20 +1,20 @@ MILE Working Group J. Field Internet-Draft Pivotal Intended status: Informational S. Banghart -Expires: April 27, 2017 D. Waltermire +Expires: May 4, 2017 D. Waltermire NIST - October 24, 2016 + October 31, 2016 Resource-Oriented Lightweight Information Exchange - draft-ietf-mile-rolie-04 + draft-ietf-mile-rolie-05 Abstract This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as Web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security @@ -39,21 +39,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 27, 2017. + This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -71,25 +71,26 @@ 3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4 3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5 4. Background and Motivation . . . . . . . . . . . . . . . . . . 5 4.1. Proactive Sharing . . . . . . . . . . . . . . . . . . . . 5 4.2. Knowledge Aggregation . . . . . . . . . . . . . . . . . . 6 4.3. Resource-oriented Architecture . . . . . . . . . . . . . 6 5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 7 5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7 5.1.1. Use of the "app:workspace" Element . . . . . . . . . 8 5.1.2. Use of the "app:collection" Element . . . . . . . . . 8 - 5.2. Service Discovery . . . . . . . . . . . . . . . . . . . . 9 + 5.1.3. Service Discovery . . . . . . . . . . . . . . . . . . 9 + 5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 10 5.3. Transport Layer Security . . . . . . . . . . . . . . . . 10 5.4. User Authentication and Authorization . . . . . . . . . . 11 5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 11 - 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 11 + 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 12 6. ROLIE Requirements for the Atom Syndication Format . . . . . 12 6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 12 6.1.1. Use of the "atom:category" Element . . . . . . . . . 13 6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 14 6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 15 6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 15 6.2.1. Use of the "atom:content" Element . . . . . . . . . . 16 6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 16 6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 17 6.2.4. Requirements for a Standalone Entry . . . . . . . . . 18 @@ -164,20 +166,29 @@ 2. Terminology The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Definitions for some of the common computer security-related terminology used in this document can be found in Section 2 of [RFC5070]. + The following terms are unqiue to this specification: + + Information Type A class of security automation information, having + an associated data model, that is the subject of a security + process that can be automated. See section 7.1.2 for more + information. + + Do we need other terms to be defined? + 3. XML-related Conventions 3.1. XML Namespaces This specification uses XML Namespaces [W3C.REC-xml-names-20091208] to uniquely identify XML element names. It uses the following namespace prefix mappings for the indicated namespace URI: "app" is used for the "http://www.w3.org/2007/app" namespace defined in [RFC5023]. @@ -298,24 +309,25 @@ representation. The client may also be provided with hypertext links that can be used to navigate to any related resource. For example, the resource representation for an object may contain links to the related resource(s). In this way, the server remains stateless with respect to a series of client requests. 5. ROLIE Requirements for the Atom Publishing Protocol This section describes a number of restrictions of and extensions to the Atom Publishing Protocol (AtomPub) [RFC5023] that define the use - of that protocol in the context of a ROLIE-based solution. - - This document assumes that the reader has an understanding of the - Atom Publishing Protocol specification. + of that protocol in the context of a ROLIE-based solution. The + normative requirements in this section are generally oriented towards + client and server implementations. An understanding of the Atom + Publishing Protocol specification [RFC5023] is helpful to understand + the requirements in this section. 5.1. AtomPub Service Documents As described in RFC5023 section 8 [RFC5023], a Service Document is an XML-based document format that allows a client to dynamically discover the Collections provided by a publisher. A Service Document consists of one or more app:workspace elements that may each contain a number of app:collection elements. The general structure of a service document is as follows (from @@ -364,21 +376,22 @@ In AtomPub, a Collection in a Service Document, represented by the "app:collection" element, provides metadata that can be used to point to a specific Atom Feed that contains information Entries that may be of interest to a client. The association between a Collection and a Feed is provided by the "href" attribute of the app:collection element. Building on the AtomPub concept of a Collection, in ROLIE a Collection represents a pointer to a group of security automation information resources pertaining to a given type of security automation information. Collections are represented as Atom Feeds as - per RFC 5023. Feed specific requirements are defined in section 6.1. + per RFC 5023. Atom Feed specific requirements are defined in section + 6.1. The following restrictions are imposed on the use of the app:collection element for ROLIE: o The atom:category elements contained in the app:categories element MUST be the same set of atom:categories used in the Atom Feed resource indicated by the app:collection "href" attribute value. This ensures that the category metadata associated with the Collection is discoverable in both the Feed and the corresponding Collection in the Service Document. @@ -398,42 +411,55 @@ considered a non-ROLIE Collection. This allows Collections pertaining to security automation information to co-exist alongside Collections of other non-ROLIE information within the same AtomPub instance. o The app:categories element in an app:collection MAY include additional atom:category elements using a scheme other than "urn:ietf:params:rolie:category:information-type". This allows other category metadata to be included. -5.2. Service Discovery +5.1.3. Service Discovery This specification requires that an implementation MUST publish an Atom Service Document that describes the set of security information sharing Collections that are provided by the repository. - The service document SHOULD be discoverable via the organization's + The Service Document SHOULD be discoverable via the organization's Web home page or another well-known public resource. An example of this can be found in appendix B.1. - The service document SHOULD be located at the standardized location + The Service Document SHOULD be located at the standardized location "https://{host:port}/rolie/servicedocument", where {host:port} is the authority portion of the URI. Dereferencing this URI MAY result in a redirect based on a HTTP 3xx status code to direct the client to the - actual service document. This allows clients to have a well-known + actual Service Document. This allows clients to have a well-known location to find a ROLIE service document, while giving implementations flexibility over how the service is deployed. - When deploying a service document for use by a closed consortium, the + When deploying a Service Document for use by a closed consortium, the service document MAY also be digitally signed and/or encrypted. For example, consider XML Signature Syntax and Processing [xmldsig] and - XML Encryption Syntax and Processing [xmlenc] + XML Encryption Syntax and Processing. [xmlenc] + +5.2. AtomPub Category Documents + + As described in RFC5023 section 7 [RFC5023], a Category Document is + an XML-based document format that allows a client to dynamically + discover the Categories used within AtomPub Service Documents, and + Atom Syndication Feed and Entry documents provided by a publisher. A + Category Document consists of one or more app:categories elements + that may each contain a number of app:collection elements. + + A ROLIE implementation MUST publish an Category Document that + describes the set of atom:category elements and associated terms used + within the implemented repository. 5.3. Transport Layer Security ROLIE is intended to be handled with TLS. The following requirements have been derived from [RFC7589]. The most recent published version of TLS MUST be supported, and any mandatory-to-implement (MTI) cipher suites in that version MUST be supported as well. @@ -506,46 +532,47 @@ 5.6. HTTP methods Clients MUST be capable of recognizing and processing any standard HTTP status code, as defined in [RFC5023] Section 5. 6. ROLIE Requirements for the Atom Syndication Format This section describes a number of restrictions of and extensions to the Atom Syndication Format [RFC4287] that define the use of that - format in the context of a ROLIE-based solution. - - This document assumes that the reader has an understanding of the - Atom Syndication Format specification. + format in the context of a ROLIE-based solution. The normative + requirements in this section are generally oriented towards content + to be published to a ROLIE repository. An understanding of the Atom + Syndication Format specification [RFC4287] is helpful to understand + the requirements in this section. 6.1. Use of the "atom:feed" element As described in RFC4287 section 4.1.1 [RFC4287], an Atom Feed is an XML-based document format that describes a list of related information items, also known as a Collection. Each Feed document, - represented using the atom:feed element, contains a Collection of - zero or more related information items individually called a "member + represented using the atom:feed element, contains a collection of + zero or more related information items individually called a "Member Entry" or "Entry". When applied to the problem domain of security automation information sharing, an Atom Feed may be used to represent any meaningful - Collection of security automation information resources. Each Entry + collection of security automation information resources. Each Entry in an atom:feed represents an individual resource (e.g., a specific checklist , a software vulnerability record). Additional Feeds can - be used to represent other Collections of security automation + be used to represent other collections of security automation resources. - This Atom Feed definition represents a stricter definition of the - atom:feed element defined in RFC 4287 for use in a ROLIE Any element - not specified here inherits its definition and requirements from - [RFC4287]. + The following Atom Feed definition represents a stricter definition + of the atom:feed element defined in RFC 4287 for use in a ROLIE Any + element not specified here inherits its definition and requirements + from [RFC4287]. atomFeed = element atom:feed { atomCommonAttributes, (atomAuthor* & atomCategory+ & atomContributor* & atomGenerator? & atomIcon? & atomId @@ -566,24 +593,24 @@ meaning of the terms used to identify an Atom category are application-defined. The following restrictions are imposed on the use of the atom:category element when used in an atom:feed: o An atom:feed element MUST minimally contain a single atom:category element with the "scheme" attribute value of "urn:ietf:params:rolie:category:information-type". This category MUST have an appropriate "term" attribute value as defined in - section 7.1.1. This ensures that a given Collection corresponds - to a specific type of security automation information. All member - entries in the Collection MUST represent security automation - information records of this information type. + section 7.1.1. This ensures that a given Feed corresponds to a + specific type of security automation information. All member + Entries in the Feed MUST represent security automation information + records of this information type. o Any atom:feed element that does not contain a child atom:category element with the "scheme" attribute value of "urn:ietf:params:rolie:category:information-type" MUST NOT be considered a ROLIE Collection. This allows Feeds pertaining to security automation information to co-exist alongside Feeds of other non-ROLIE information within the same AtomPub instance. o An atom:feed may include additional atom:category elements using a scheme other than "urn:ietf:params:rolie:category:information- @@ -791,53 +818,59 @@ its containing Feed, then the following additional requirements apply: o The Entry MUST have a atom:link element with rel="collection" and href="[IRI of the containing Collection]". This allows the Feed or Feeds for which the Entry is a member to be discovered, along with the related information the Feed may contain. In the case of the Entry have multiple containing Feeds, the Entry MUST have one atom:link for each related Feed. - o The Entry MUST declare the information-type of the content + o The Entry MUST declare the information type of the content resource referenced by the Entry (see Section 7.1.2). 7. Available Extension Points Provided by ROLIE This specification does not require particular information types or - data formats, rather, ROLIE is intended to be extended by additional - specifications that add new categories and link relations. The - primary point of extension is through the information-type category, - which is used to enumerate the set of all types of information - supported by ROLIE. Additional specifications can register new - information-type records with IANA that serve as the main - characterizing feature of a ROLIE Collection or Resource. These - additional specifications defining new information-type values, can - describe requirements for including specific categories, link - relations, as well as, use of specific data formats supporting a - given information-type. + data formats; rather, ROLIE is intended to be extended by additional + specifications that define the use of new categories and link + relations. The primary point of extension is through the definition + of new information type category terms. Additional specifications + can register new information type category terms with IANA that serve + as the main characterizing feature of a ROLIE Collection/Feed or + Resource/Entry. These additional specifications defining new + information type terms, can describe additional requirements for + including specific categories, link relations, as well as, use of + specific data formats supporting a given information type term. 7.1. The Category Extension Point The atom:category element, defined in RFC 4287 section 4.2.2 [RFC4287], provides a mechanism to provide additional categorization information for a content resource in ROLIE. The ability to define new categories is one of the core extension points provided by Atom. + A Category Document, defined in RFC 5023 section 7 [RFC5023], provides a mechanism for an Atom repository to make discoverable the atom:category terms and allowed values used by a given repository. - ROLIE adds to this existing Atom extension mechanism by allowing - ROLIE specific category extensions to be registered with IANA, and - additionally has assigned an information-type category that has - special meaning for implementations of ROLIE. These aspects are - discussed in the following subsections. + ROLIE further defines the use of the existing Atom extension category + mechanism by allowing ROLIE specific category extensions to be + registered with IANA, and additionally has assigned the + "urn:ietf:params:rolie:category:information-type" category scheme + that has special meaning for implementations of ROLIE. This allows + category scheme namespaces to be managed in a more consistent way, + allowing for greater interoperability between content producers and + consumers. + + Use of the "atom:category" element is discussed in the following + subsections. 7.1.1. General Use of the "atom:category" Element The atom:category element can be used for characterizing a ROLIE Resource. As discussed earlier in this document, an atom:category element has a "term" attribute that indicates the assigned category value, and a "scheme" attribute that provides an identifier for the category type. The "scheme" provides a means to describe how a set of category terms should be used and provides a namespace that can be used to differentiate terms provided by multiple organizations with @@ -854,29 +887,29 @@ A ROLIE specific extension point is provided through the atom:category "scheme" value "urn:ietf:params:rolie:category:information-type". This value is a Uniform Resource Name (URN) [RFC2141] that is registered with IANA as described in section 8.3. When used as the "scheme" attribute in this way, the "term" attribute is expected to be a registered value as defined in section Section 8.4. Through this mechanism a given security automation information type can be used to: 1. identify that an "app:collection" element in a Service Document - points to an Atom Feed that contains entries pertaining to a + points to an Atom Feed that contains Entries pertaining to a specific type of security automation information (see section 5.1.2), or 2. identify that an "atom:feed" element in an Atom Feed contains - entries pertaining to a specific type of security automation + Entries pertaining to a specific type of security automation information (see section 6.1.1). - 3. identify the information-type of a standalone Resource (see + 3. identify the information type of a standalone Resource (see section 6.2.4). For example, the notional security automation information type "incident" would be identified as follows: A security automation information type represents a class of @@ -901,41 +934,40 @@ installable software. This is a short list to inspire new engineering of information type extensions that support the automation of security processes. This document does not specific any information types. Instead, information types in ROLIE are expected to be registered in extension documents that describe one or more new information types. This allows the information types used by ROLIE implementations to grow over time to support new security automation use cases. These - extension documents may also enhance ROLIE Resource representations - by defining link relations, other categories, and other AtomPub and - Atom Syndication Format data model extensions to address the - representational needs of these specific information types. New - information types are added to ROLIE through registrations to the - IANA ROLIE Security Resource Information Type registry defined in - section 8.4. + extension documents may also enhance ROLIE Service, Category, Feed, + and Entry documents by defining link relations, other categories, and + Format data model extensions to address the representational needs of + these specific information types. New information types are added to + ROLIE through registrations to the IANA ROLIE Security Resource + Information Type registry defined in section 8.4. 7.2. The "rolie:format" Extension Point Security automation data pertaining to a given information type may be expressed using a number of supported formats. As described in section 6.2.3, the rolie:format element is used to describe the - specific data model used to represent the Resource referenced by a + specific data model used to represent the resource referenced by a given "atom:entry". The structure provided by the rolie:format element, provides a mechanism for extension within the atom:entry model. ROLIE extensions MAY further restrict which data models are - allowed to be used for a given information-type + allowed to be used for a given information type. By declaring the data model used for a given Resource, a consumer can - choose to download or ignore the resource, or look for alternate + choose to download or ignore the Resource, or look for alternate formats. This saves the consumer from downloading and parsing resources that the consumer is not interested in or resources expressed in formats that are not supported by the consumer. 7.3. The Link Relation Extension Point This document uses several link relations defined in the IANA Link Relation Types registry [2]. Additional link relations can be registered in this registry to allow new relationships to be represented in ROLIE according to RFC 4287 section 4.2.7.2 [RFC4287]. @@ -1001,24 +1033,25 @@ Parameters" has been created. Registration in this repository is via the Specification Required policy [RFC5226]. Designated Expert reviews should be routed through the MILE WG mailing list. Failing this, the Designated Expert will be assigned by the IESG. Each entry in this sub-registry must record the following fields: Name: A URN segment that adheres to the pattern {type}:{label}. The keywords are defined as follows: - {type}: The parameter type. The allowed values are "category" - and "format". "category" denotes a category extension as - discussed in Section 7.1, "format" denotes a additional - supported format as discussed in Section 7.2. + {type}: The parameter type. The allowed value is "category". + "category" denotes a category extension as discussed in + Section 7.1. While a single value is used in this + specification, future revisions or extensions of this + specification may define additional {type} values. {label}: A required US-ASCII string that conforms to the URN syntax requirements (see [RFC2141]). This string must be unique within the namespace defined by the {type} keyword. Extension IRI: The identifier to use within ROLIE, which is the full URN using the form: urn:ietf:params:rolie:{name}, where {name} is the "name" field of this registration. Reference: A static link to the specification and section that the @@ -1041,24 +1074,24 @@ | informati | lie:category | docu | registration should take | | on-type | :information-type | ment | place at the following | | | | , Se | location: https://www.ian | | | | ctio | a.org/assignments/rolie/c | | | | n | ategory/information-type] | | | | 9.4 | | +-----------+--------------------+------+---------------------------+ 8.4. ROLIE Security Resource Information Type Sub-Registry - A new sub-registry has been created to store ROLIE information-type + A new sub-registry has been created to store ROLIE information type values. - Name of Registry: "ROLIE Information-Types" + Name of Registry: "ROLIE Information Types" Location of Registry: https://www.iana.org/assignments/rolie/category/information-type Fields to record in the registry: name: The full name of the security resource information type as a string from the printable ASCII character set [RFC0020] with individual embedded spaces allowed. The ABNF [RFC5234] syntax for this field is: @@ -1102,21 +1135,21 @@ upon HTTP Authentication or similar. However, sharing communities that are engaged in sensitive collaborative analysis and/or operational response for indicators and incidents targeting high value information systems should adopt a suitably stronger user authentication solution, such as a risk-based or multi-factor approach. In general, trust in the sharing consortium will depend upon the members maintaining adequate user authentication mechanisms. Collaborating consortiums may benefit from the adoption of a federated identity solution, such as those based upon SAML-core - [SAML-core] and SAML-bind [SAML-bind] and SAML-prof [SAML-prof] for + [SAML-core], SAML-bind [SAML-bind], and SAML-prof [SAML-prof] for Web-based authentication and cross-organizational single sign-on. Dependency on a trusted third party identity provider implies that appropriate care must be exercised to sufficiently secure the Identity provider. Any attacks on the federated identity system would present a risk to the CSIRT, as a relying party. Potential mitigations include deployment of a federation-aware identity provider that is under the control of the information sharing consortium, with suitably stringent technical and management controls.