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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/