One document matched: draft-ietf-mile-rolie-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY xml-names SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-xml-names-20091208.xml">
<!ENTITY RFC0020 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml">
<!ENTITY RFC3688 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2141 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY RFC3444 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC3553 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3553.xml">
<!ENTITY RFC3986 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4287 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4287.xml">
<!ENTITY RFC4642 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4642.xml">
<!ENTITY RFC5070 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5070.xml">
<!ENTITY RFC5070bis SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mile-rfc5070-bis-26.xml">
<!ENTITY RFC5023 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5023.xml">
<!ENTITY RFC5005 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5005.xml">
<!ENTITY RFC5226 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5234 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC6546 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6546.xml">
<!ENTITY RFC7589 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7589.xml">
]>
<?xml-stylesheet type="text/css" href="rfc7749.css"?>
<rfc ipr="trust200902" category="info" docName="draft-ietf-mile-rolie-05">
<!-- Working draft of draft05 -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="ROLIE">Resource-Oriented Lightweight Information
Exchange</title>
<author initials="J.P." surname="Field" fullname="John P. Field">
<organization abbrev="Pivotal">Pivotal Software,
Inc.</organization>
<address>
<postal>
<street>625 Avenue of the Americas</street>
<city>New York</city>
<region>New York</region>
<country>USA</country>
</postal>
<phone>(646)792-5770</phone>
<email>jfield@pivotal.io</email>
</address>
</author>
<author initials="S.A." surname="Banghart" fullname="Stephen A. Banghart">
<organization abbrev="NIST">National Institute of Standards and
Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<country>USA</country>
</postal>
<phone>(301)975-4288</phone>
<email>sab3@nist.gov</email>
</address>
</author>
<author fullname="David Waltermire" initials="D.W." surname="Waltermire">
<organization abbrev="NIST">National Institute of Standards and
Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<code>20877</code>
<country>USA</country>
</postal>
<phone/>
<email>david.waltermire@nist.gov</email>
</address>
</author>
<date month="October" day="31" year="2016"/>
<area>Security</area>
<workgroup>MILE Working Group</workgroup>
<abstract>
<t>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 information as needed, establishing a rapid
and on-demand information exchange network for restricted
internal use or public access repositories. This specification
extends the Atom Publishing Protocol and Atom Syndication Format
to transport and share security automation resource
representations.</t>
</abstract>
<note title="Contributing to this document">
<!--RFC EDITOR - Please remove this note before publishing -->
<t>The source for this draft is being maintained on GitHub.
Suggested changes should be submitted as pull requests at <eref
target="https://github.com/CISecurity/ROLIE"/>. Instructions are
on that page as well. Editorial changes can be managed in GitHub,
but any substantial issues need to be discussed on the MILE
mailing list.</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="starting-intro">
<t>This document defines a resource-oriented approach to security
automation information sharing that follows the <xref target="REST" format="title" pageno="false">REST</xref>
architectural style. In this approach, computer security
resources are maintained in web-accessible repositories
structured as <xref target="RFC4287">Atom Syndication
Format</xref> Feeds. Representations of specific types of
security automation information are categorized and organized
into indexed Collections which may be requested by the consumer.
As the set of resource Collections are forward facing, the
consumer may search all available content for which they are
authorized to view, and request the information resources which
are desired. Through use of granular authentication and access
controls, only authorized consumers may be permitted the ability
to read or write to a given Feed. This approach is in contrast
to, and meant to improve on, the traditional point-to-point
messaging system, in which consumers must request individual
pieces of information from a server following a triggering event.
The point-to-point approach creates a closed system of
information sharing that encourages duplication of effort and
hinders automated security systems.</t>
<t>The goal of this document is to define a RESTful approach to
security information communication with two primary intents: 1)
increasing communication and sharing of incident reports,
vulnerability assessments, configuration checklists, and other
security automation information between providers and consumers;
and 2) establishing a standardized communication system to
support automated computer security systems.</t>
<t>In order to deal with the great variety in security automation
information types and associated resource representations, this
specification defines extension points that can be used to add
support for new information types and associated resource
representations by means of additional supplementary
specification documents. This primary document is resource
representation agnostic, and defines the core requirements of all
implementations. An overview of the extension system is provided
in <xref target="content-model"/>.Those seeking to provide
support for specific security automation information types should
refer to the specification for that domain described by the IANA
registry found in section <xref target="iana-information-type"
format="counter"/>.</t>
</section>
<section title="Terminology" anchor="ext-terminology">
<t>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
<xref target="RFC2119"/>.</t>
<t>Definitions for some of the common computer security-related
terminology used in this document can be found in Section 2 of
<xref target="RFC5070"/>.</t>
<t>The following terms are unqiue to this specification:<list style="hanging">
<t hangText="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 <xref target="content-model-category-info-type"
format="counter"/> for more information.</t>
<t>Do we need other terms to be defined?</t>
</list></t>
</section>
<section title="XML-related Conventions">
<section title="XML Namespaces" anchor="xml-namespaces">
<t>This specification uses XML Namespaces <xref target="W3C.REC-xml-names-20091208"/> to uniquely identify XML
element names. It uses the following namespace prefix mappings
for the indicated namespace URI:<list>
<t>"app" is used for the "http://www.w3.org/2007/app" namespace
defined in <xref target="RFC5023"/>.</t>
<t>"atom" is used for the "http://www.w3.org/2005/Atom"
namespace defined in <xref target="RFC4287"/>.</t>
<t>"rolie" is used for the "urn:ietf:params:xml:ns:rolie:1.0"
namespace defined in section <xref target="iana-xml" format="counter"/> of this specification.</t>
</list></t>
</section>
<section title="RELAX NG Compact Schema" anchor="rnc-schema-intro">
<t>Some sections of this specification are illustrated with
fragments of a non-normative RELAX NG Compact schema <xref
target="relax-NG"/>. However, the text of this specification
provides the definition of conformance. Schema for the
"http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom"
namespaces appear in <xref target="RFC5023">RFC5023 appendix
B</xref> and <xref target="RFC4287">RFC4287 appendix B</xref>
respectively.</t>
</section>
</section>
<section title="Background and Motivation" anchor="back-motive">
<t>Information sharing is one of the core components of automating
security processes. Vulnerabilities, configurations, software
identification, security incidents, and patching data are just a
few of the classes of information that are shared today to
enable effective security on a wide scale. However, as the scale
of defense broadens to sometimes global networks, and the
inherent scaling issues of human-in-the-loop sharing become
apparent, the need for automation and machine-to-machine
communication becomes apparent.</t>
<section title="Proactive Sharing" anchor="sharing">
<t>Existing approaches to computer security information sharing
often use message exchange patterns that are point-to-point.
Sometimes, information that may be useful to share with
multiple peers is only made available to peers after they have
specifically requested it. Unfortunately, a sharing peer may
not know, a priori, what information to request from another
peer. Some existing systems provide a mechanism for unsolicited
information requests, however, these reports are again sent
point-to-point, and must be reviewed for relevance and then
prioritized for action by the recipient, introducing additional
latency.</t>
<t>In order to adequately combat evolving threats, computer
security information resource providers should be able to share
selected information proactively. Proactive sharing greatly
aids knowledge dissemination, and improves response times and
usability by allowing the consumer to choose which information
is relevant to its needs.</t>
<t>For example, a security analyst can benefit by having the
ability to search a comprehensive collection of attack
indicators that have been published by a government agency, or
by another member of a sharing consortium. The representation
of each indicator may include links to the related resources,
enabling an appropriately authenticated and authorized analyst
to freely navigate the information space of indicators,
incidents, vulnerabilities, and other computer security domain
concepts as needed. In this way, an analyst can more
effectively utilize the super set of information made publicly
available.</t>
</section>
<section title="Knowledge Aggregation" anchor="aggregation">
<t>Additionally, there is value in maintaining a repository of
knowledge that can be queried by a new consumer, allowing this
consumer to identify and retrieve any information that is
relevant to its needs. In this way, the consumer can gain
access to meaningful current and historic information, catching
up to the knowledge level of its peers.</t>
<t>Consider the case of an automated endpoint management system
attempting to proactively prevent software flaws and
mis-configured software from compromising the security of the
affected systems. During its full network sweep, the endpoint
monitoring system would check each endpoint for outdated,
vulnerable, and mis-configured software. This system would
benefit from having access to not only the software vendor's
list of vulnerabilities and configuration baselines, but also
similar information discovered by other security researchers.
An advanced system could even give back to this sharing
consortium by sharing any relevant information discovered. </t>
<t>These capabilities support a federated collection of
information repositories that can be queried and contributed to
by an organization, further supporting automated security
solutions.</t>
</section>
<section title="Resource-oriented Architecture" anchor="roa">
<t>Applying the REST architectural style to the problem domain of
security information sharing involves exposing information of
any relevant type as simple Web-addressable resources. Each
provider maintains their own repository of data, with public
and private sections as needed. Any producer or consumer can
then discover these repositories, search for relevant Feeds,
and pull information from them. By using this approach, an
organization can more quickly and easily share relevant data
representations with a much larger and potentially more diverse
constituency. A consumer may leverage virtually any available
HTTP user agent in order to make requests of the service
provider. This improved ease of use enables more rapid adoption
and broader participation, thereby improving security for
everyone.</t>
<t>A key aspect of any RESTful Web service is the ability to
provide multiple resource representations. For example, clients
may request that a given resource representation be returned as
XML, JSON, or in some other format. In order to enable
backwards-compatibility and interoperability with existing
implementations, the RESTful approach allows the provider to
make differing formats available proactively, allowing the
consumer to simply select the version that best suits them.</t>
<t>Finally, an important principle of the REST architectural
style is the focus on hypermedia as the engine of application
state (HATEOAS). Rather than the server maintaining
conversational state for each client, the server will instead
include a suitable set of hyperlinks in the resource
representation that is returned to the client. The included
hyperlinks provide the client with a specific set of permitted
state transitions. Using these links the client may perform an
operation, such as updating or deleting the resource
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.</t>
</section>
</section>
<section title="ROLIE Requirements for the Atom Publishing Protocol" anchor="atompub">
<t>This section describes a number of restrictions of and
extensions to the <xref target="RFC5023">Atom Publishing
Protocol (AtomPub)</xref> that define the use 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 <xref target="RFC5023"/> is
helpful to understand the requirements in this section.</t>
<section title="AtomPub Service Documents" anchor="atompub-service">
<t>As described in <xref target="RFC5023">RFC5023 section
8</xref>, 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.</t>
<t>The general structure of a service document is as follows
(from <xref target="RFC5023">RFC5023 section 4.2</xref>):</t>
<figure>
<artwork><![CDATA[
Service
o- Workspace
| |
| o- Collection
| |
| o- IRI, categories, media types
|
o- Workspace
|
o- Collection
|
o- IRI, categories, media types
]]></artwork>
</figure>
<section title="Use of the "app:workspace" Element" anchor="atompub-service-workspace">
<t>In AtomPub, a Workspace, represented by the "app:workspace"
element, describes a group of one or more Collections.
Building on the AtomPub concept of a Workspace, in ROLIE a
Workspace represents an aggregation of Collections pertaining
to security automation information resources. This
specification does not impose any restrictions on the number
of Workspaces that may be in a Service Document or the
specific Collections to be provided within a given
Workspace.</t>
<t>The following restrictions are imposed on the use of the
app:workspace element in ROLIE:<list style="symbols">
<t>A ROLIE repository can host Collections containing both
public and private information entries. It is
RECOMMENDED that public and private Collections be
segregated into different Workspaces. By doing this,
Workspaces that contain private information can be
ignored by clients or can be omitted from the Service
Document provided to a client that lacks the appropriate
privilege to access the set of Collections associated
with the Workspace.</t>
<t>Appropriate descriptions and naming conventions SHOULD be
used to indicate the intended audience of each
workspace. This helps to facilitate the selection of
appropriate Workspaces by users.</t>
</list></t>
</section>
<section title="Use of the "app:collection" Element" anchor="atompub-service-collection">
<t>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. Atom Feed
specific requirements are defined in section <xref
target="atom-synd-feed" format="counter"/>.</t>
<t>The following restrictions are imposed on the use of the
app:collection element for ROLIE:<list style="symbols">
<t>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.</t>
<t>An app:collection pertaining to a security automation
information resource Feed MUST contain an app:categories
element that minimally contains 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 <xref target="content-model-category-general" format="counter"/>.
This ensures that a given Collection corresponds to a
specific type of security automation information.</t>
<t>Any app:collection element that does not contain a
descendant atom:category element with the "scheme"
attribute value of
"urn:ietf:params:rolie:category:information-type" MUST be
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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Service Discovery" anchor="atompub-discover">
<t>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.</t>
<t>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 <xref
target="example-svcdoc" format="counter"/>.</t>
<t>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
location to find a ROLIE service document, while giving
implementations flexibility over how the service is
deployed.</t>
<t>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 <xref
target="xmldsig">XML Signature Syntax and
Processing</xref> and <xref target="xmlenc">XML Encryption
Syntax and Processing.</xref>
</t>
</section>
</section>
<section title="AtomPub Category Documents">
<t>As described in <xref target="RFC5023">RFC5023 section
7</xref>, 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.</t>
<t>A ROLIE implementation MUST
publish an Category Document that describes the set of
atom:category elements and associated terms used within the
implemented repository.</t>
</section>
<section title="Transport Layer Security" anchor="atompub-tls">
<t>ROLIE is intended to be handled with TLS. The following
requirements have been derived from <xref target="RFC7589"/>.</t>
<t>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.</t>
<t>The server MUST support certificate-based client
authentication. The implementation MAY use any TLS cipher suite
that supports mutual authentication.</t>
<t>During the TLS negotiation, the client MUST carefully examine
the certificate presented by the server to determine if it
meets the client’s expectations. Particularly, the client MUST
check its understanding of the server hostname against the
server’s identity as presented in the server Certificate
message, in order to prevent man-in-the-middle attacks.
Matching is performed according to the rules laid out in the
Security Considerations section of <xref target="RFC4642"/>.</t>
<t>If the match fails, the client MUST either ask for explicit
user confirmation or terminate the connection and indicate the
server’s identity is suspect. Additionally, clients MUST verify
the binding between the identity of the servers to which they
connect and the public keys presented by those servers. Clients
SHOULD implement the algorithm in Section 6 of <xref target="RFC5280"/> for general certificate validation, but MAY
supplement that algorithm with other validation methods that
achieve equivalent levels of verification (such as comparing
the server certificate against a local store of
already-verified certificates and identity bindings). If the
client has external information as to the expected identity of
the server, the hostname check MAY be omitted.</t>
<t>The server MUST be capable of verifying the identity of the
client with certificate-based authentication according to
local policy to ensure that the incoming client request is
legitimate before any configuration or state data is sent to
or received from the client.</t>
</section>
<section title="User Authentication and Authorization" anchor="atompub-auth-authz">
<t>Implementations MUST support user authentication. User
authentication MAY be enabled for specific Feeds.</t>
<t>Servers participating in an information sharing consortium
and supporting interactive user logins by members of the
consortium SHOULD support client authentication via a
federated identity scheme (e.g., SAML 2.0).</t>
<t>This document does not mandate the use of any specific user
authorization mechanisms. However, service implementers SHOULD
provide appropriate authorization checking for all resource
accesses, including individual Atom Entries, Atom Feeds, and
Atom Service Documents.</t>
</section>
<section title="/ (forward slash) Resource URL" anchor="atompub-rid">
<!-- Should this be moved to the CSIRT document? -->
<t>The "/" resource MAY be provided for compatibility with
existing deployments that are using <xref target="RFC6546">
Transport of Real-time Inter-network Defense (RID) Messages
over HTTP/TLS</xref>. If the "/" resource is supported the
following behavior MUST be also supported:<list style="symbols">
<t>Consistent with RFC6546 errata, a client requesting a GET
on "/" SHOULD receive an HTTP status code 405 Method Not
Allowed.</t>
<t>An implementation MAY provide full support for <xref target="RFC6546"/>
such that a POST to "/" containing a recognized RID
message is handled correctly as a RID request.
Alternatively, a client requesting a POST to "/" MAY
receive an HTTP status code 307 Temporary Redirect. In
this case, the location header in the HTTP response will
provide the URL of the appropriate RID endpoint, and the
client may repeat the POST method at the indicated
location.</t>
</list></t>
<t>If the "/" resource is unsupported, then a request for this resource MUST provide a 404 HTTP status code.</t>
</section>
<section title="HTTP methods" anchor="atompub-http-methods">
<t>Clients MUST be capable of recognizing and processing any
standard HTTP status code, as defined in <xref target="RFC5023"/> Section 5.</t>
</section>
</section>
<section title="ROLIE Requirements for the Atom Syndication Format" anchor="atom-synd">
<t>This section describes a number of restrictions of and
extensions to the <xref target="RFC4287">Atom Syndication
Format</xref> that define the use of that 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 <xref target="RFC4287"/> is
helpful to understand the requirements in this section.</t>
<section title="Use of the "atom:feed" element" anchor="atom-synd-feed">
<t>As described in <xref target="RFC4287">RFC4287 section
4.1.1</xref>, 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 Entry" or
"Entry".</t>
<t>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 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
resources.</t>
<t>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 <xref target="RFC4287"/>.</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
atomFeed =
element atom:feed {
atomCommonAttributes,
(atomAuthor*
& atomCategory+
& atomContributor*
& atomGenerator?
& atomIcon?
& atomId
& atomLink+
& atomLogo?
& atomRights?
& atomSubtitle?
& atomTitle
& atomUpdated
& extensionElement*),
atomEntry*
}]]></artwork>
</figure>
<section title="Use of the "atom:category" Element" anchor="atom-synd-feed-category">
<t>An atom:feed can be categorized and can contain information
from zero or more categories. In Atom the naming scheme and
the semantic meaning of the terms used to identify an Atom
category are application-defined.</t>
<t>The following restrictions are imposed on the use of the
atom:category element when used in an atom:feed:<list style="symbols">
<t>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 <xref target="content-model-category-general" format="counter"/>. 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.</t>
<t>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.</t>
<t>An atom:feed 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.</t>
</list></t>
</section>
<section title="Use of the "atom:link" Element" anchor="atom-synd-feed-link">
<t>Link relations defined by the atom:link element are used to
represent state transitions using a stateless approach. In
Atom a type of link relationship can be defined using the
"rel" attribute.</t>
<t>A ROLIE atom:feed MUST contain one or more atom:link
elements with rel="service" and href attribute whose value
is a IRI that points to an Atom Service Document associated
with the atom:feed. When a client is presented with a Feed
as its initial view into a repository, a link with the
service relationship provides a means to discover additional
security automation information. The "service" link
relationship is defined in the <eref
target="https://www.iana.org/assignments/link-relations/link-relations.xhtml"
>IANA Link Relations Registry</eref>.</t>
<t>An atom:feed can contain an arbitrary number of Entries. In
some cases, a complete Feed may consist of a large number of
Entries. Additionally, as new and updated Entries are
ordered at the beginning of a Feed, a client may only be
interested in retrieving the first N entries in a Feed to
process only the Entries that have changed since the last
retrieval of the Feed. As a practical matter, a large set of
Entries will likely need to be divided into more manageable
portions. Based on <xref target="RFC5005">RFC5005 section
3</xref>, link elements SHOULD be included in all Feeds to
support paging using the following link relation types:<list style="symbols">
<t>"first" - Indicates that the href attribute value of
the link identifies a resource IRI for the furthest
preceding page of the Feed.</t>
<t>"last" - Indicates that the href attribute value of the
link identifies a resource IRI for the furthest
following page of the Feed.</t>
<t>"previous" - Indicates that the href attribute value of
the link identifies a resource IRI for the immediately
preceding page of the Feed.</t>
<t>"next" - Indicates that the href attribute value of the
link identifies a resource IRI for the immediately
following page of the Feed.</t>
</list>
</t>
<t>For example:</t>
<figure height="" suppress-title="false" width="" alt="" title="Example Paged Feed" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<id>b7f65304-b63b-4246-88e2-c104049c5fd7</id>
<title>Paged Feed</title>
<link rel="self" href="http://example.org/feedA?page=5"/>
<link rel="first" href="http://example.org/feedA?page=1"/>
<link rel="prev" href="http://example.org/feedA?page=4"/>
<link rel="next" href="http://example.org/feedA?page=6"/>
<link rel="last" href="http://example.org/feedA?page=10"/>
<updated>2012-05-04T18:13:51.0Z</updated>
<!-- remainder of feed elements -->
</feed> ]]></artwork>
</figure>
<t>A reference to a historical Feed may need to be stable,
and/or a Feed may need to be divided into a series of
defined epochs. Implementations SHOULD support the
mechanisms described in <xref target="RFC5005">RFC5005
section 4</xref> to provide link-based state transitions
for maintaining archiving of Feeds.</t>
<t>An atom:feed MAY include additional link relationships not
specified in this document. If a client encounters an
unknown link relationship type, the client MUST ignore the
unrecognized link and continue processing as if the
unrecognized link element did not appear. The definition of
new Link relations that provide additional state transition
extensions is discussed in section <xref target="content-model-link" format="counter"/>.</t>
</section>
<section title="Use of the "atom:updated" Element" anchor="atom-synd-feed-updated">
<t>The atom:updated element MUST be populated with the current
time at the instant the Feed representation was last updated
by adding, updating, or deleting an Entry; or changing any
metadata for the Feed.</t>
</section>
</section>
<section title="Use of the "atom:entry" Element" anchor="atom-synd-entry">
<t>Each Entry in an Atom Feed, represented by the atom:entry
element, describes a single information record, format, and
type combination. The following atom:entry schema definition
represents a stricter representation of the atom:entry element
defined in <xref target="RFC4287"/> for use in a ROLIE-based Atom Feed.</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
atomEntry =
element atom:entry {
atomCommonAttributes,
(atomAuthor*
& atomCategory*
& atomContent
& atomContributor*
& atomId
& atomLink*
& atomPublished?
& atomRights?
& atomSource?
& atomSummary?
& atomTitle
& atomUpdated
& rolieFormat
& extensionElement*)
} ]]></artwork>
</figure>
<section title="Use of the "atom:content" Element" anchor="atom-synd-entry-content">
<t>There MUST be exactly one atomContent element in the Entry.
The content element MUST adhere to this definition, which is
a stricter representation of the atom:content element
defined in <xref target="RFC4287"/>:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
atomContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType },
attribute src { atomUri },
empty
} ]]></artwork>
</figure>
<t>The type attribute MUST identify the serialization type of
the content, for example, application/xml or
application/json. A prefixed media type MAY be used to
reflect a specific model used with a given serialization
approach (e.g., application/rdf+xml). The src attribute MUST
be an IRI that can be dereferenced to retrieve the related
content data.</t>
</section>
<section title="Use of the "atom:link" Element" anchor="atom-synd-entry-link">
<t>Link relations can be included in an atom:entry to
represent state transitions for the Entry.</t>
<t>If there is a need to provide the same information in
different data models and/or serialization formats, separate
Entry instances can be included in the same or a different
Feed. Such an alternate content representation can be
indicated using an atom:link having a rel attribute with the
value "alternate".</t>
<t>An atom:feed MAY include additional link relationships not
specified in this document. If a client encounters an
unknown link relationship type, the client MUST ignore the
unrecognized link and continue processing as if the
unrecognized link element did not appear. The definition of
new Link relations that provide additional state transition
extensions is discussed in section <xref target="content-model-link" format="counter"/>.</t>
</section>
<section title="Use of the "rolie:format" Element" anchor="atom-synd-entry-rolie-format">
<t>As mentioned earlier, a key goal of this specification is
to allow a consumer to review a set of published security
automation information resources, and then identify and
retrieve any resources of interest. The format of the data
is a key criteria to consider when deciding what information
to retrieve. For a given type of security automation
information, it is expected that a number of different
formats may be used to represent this information. To
support this use case, both the serialization format and the
specific data model expressed in that format must be known
by the consumer.</t>
<t>The rolie:format element is used to describe the data model
used to express the information referenced in the
atom:content element of an atom:entry. It also allows a
schema to be identified that can be used when parsing the
content to verify or better understand the structure of the
content.</t>
<t>There MUST be exactly one rolie:format element in an
atom:entry. The element MUST adhere to this definition:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
rolieFormat =
element rolie:format {
atomCommonAttributes,
attribute ns { atomURI },
attribute version { text } ?,
attribute schema-location { atomURI } ?,
attribute schema-type { atomMediaType } ?,
empty
} ]]></artwork>
</figure>
<t>The rolie:format element MUST provide a "ns" attribute that
identifies the data model of the resource referenced by the
atom:content element. For example, the namespace used may be
an XML namespace URI, or an identifier that represents a
serialized JSON model. The URI used for the "ns" attribute
value MUST be an absolute or opaque URI. The resource
identified by the URI need not be resolvable.</t>
<t>The rolie:format element MAY provide a "version" attribute
that identifies the version of the format used for the
related atom:content. </t>
<t>The rolie:format element MAY provide a "schema-location"
element that is a URI that identifies a schema resource that
can be used to validate the related atom:content.</t>
<t>The rolie:format element MAY provide a "schema-type"
element, which is a mime type identifying the format of the
schema resource identified by the "schema-location"
attribute.</t>
</section>
<section title="Requirements for a Standalone Entry" anchor="atom-synd-entry-standalone">
<t>If an Entry is ever shared as a standalone resource,
separate from its containing Feed, then the following
additional requirements apply:<list style="symbols"><t>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.</t>
<t>The Entry MUST declare the information type of the
content resource referenced by the Entry (see <xref
target="content-model-category-info-type"/>).</t>
</list></t>
</section>
</section>
</section>
<section title="Available Extension Points Provided by ROLIE" anchor="content-model">
<t>This specification does not require particular information
types or 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.</t>
<section title="The Category Extension Point" anchor="content-model-category">
<t>The atom:category element, defined in <xref target="RFC4287">RFC 4287 section 4.2.2</xref>, 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 <xref target="RFC5023">RFC 5023 section
7</xref>, provides a mechanism for an Atom repository to
make discoverable the atom:category terms and allowed values
used by a given repository.</t>
<t>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.</t>
<t>Use of the "atom:category" element is discussed in the
following subsections.</t>
<section title="General Use of the "atom:category" Element" anchor="content-model-category-general">
<t>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
different semantic meaning.</t>
<t>To further differentiate category types used in ROLIE, an
IANA sub-registry has been established for ROLIE protocol
parameters to support the registration of new category
"scheme" attribute values by ROLIE extension specifications.
Use of this extension point is discussed in section <xref target="iana-parameters" format="counter"/>.</t>
</section>
<section title="Identification of Security Automation Information Types" anchor="content-model-category-info-type">
<t>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) <xref target="RFC2141"/> that is registered with IANA as
described in section <xref target="iana-parameters" format="counter"/>. When used as the "scheme" attribute in
this way, the "term" attribute is expected to be a
registered value as defined in section <xref target="iana-information-type"/>. Through this mechanism a
given security automation information type can be used
to:<list style="numbers">
<t>identify that an "app:collection" element in a Service
Document points to an Atom Feed that contains Entries
pertaining to a specific type of security automation
information (see section <xref target="atompub-service-collection" format="counter"/>), or</t>
<t>identify that an "atom:feed" element in an Atom Feed
contains Entries pertaining to a specific type of
security automation information (see section <xref target="atom-synd-feed-category" format="counter"/>).</t>
<t>identify the information type of a standalone Resource
(see section <xref target="atom-synd-entry-standalone"
format="counter"/>).</t>
</list></t>
<t>For example, the notional security automation information
type "incident" would be identified as follows:</t>
<figure alt="" title="" align="left">
<artwork align="left" xml:space="preserve"><![CDATA[
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/>]]></artwork>
</figure>
<t>A security automation information type represents a class of
information that represents the same or similar information
model <xref target="RFC3444"/>. Notional examples of
information types include:<list style="hanging" hangIndent="4">
<t hangText="indicator:">Computing device- or network-related
"observable features and phenomenon that aid in the
forensic or proactive detection of malicious activity; and
associated meta-data" (from <xref target="I-D.ietf-mile-rfc5070-bis"/>).</t>
<t hangText="incident:">Information pertaining to and
"derived analysis from security incidents" (from <xref target="I-D.ietf-mile-rfc5070-bis"/>).</t>
<t hangText="vulnerability reports:">Information identifying
and describing a vulnerability in hardware or software.</t>
<t hangText="configuration checklists:">Content that can be
used to assess the configuration settings related to
installed software.</t>
<t hangText="software tags:">Metadata used to identify and
characterize installable software.</t>
</list></t>
<t>This is a short list to inspire new engineering of
information type extensions that support the automation of
security processes.</t>
<t>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 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 <xref target="iana-information-type" format="counter"/>.</t>
</section>
</section>
<section title="The "rolie:format" Extension Point" anchor="content-model-format">
<t>Security automation data pertaining to a given information
type may be expressed using a number of supported formats. As
described in section <xref
target="atom-synd-entry-rolie-format" format="counter"/>,
the rolie:format element is used to describe the 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.</t>
<t>By declaring the data model used for a given Resource, a
consumer can 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.</t>
</section>
<section title="The Link Relation Extension Point" anchor="content-model-link">
<t>This document uses several link relations defined in the
<eref
target="https://www.iana.org/assignments/link-relations/link-relations.xhtml"
>IANA Link Relation Types registry</eref>. Additional link
relations can be registered in this registry to allow new
relationships to be represented in ROLIE according to <xref
target="RFC4287">RFC 4287 section 4.2.7.2</xref>. Based on
the preceding reference, if the link relation is too specific
or limited in the intended use, an absolute IRI can be used in
lieu of registering a new simple name with IANA.</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document has a number of IANA considerations described in
the following subsections.</t>
<section title="XML Namespaces and Schema URNs" anchor="iana-xml">
<t>This document uses URNs to describe XML namespaces and XML
schemas conforming to a registry mechanism described in <xref target="RFC3688"/>. <list style="hanging" hangIndent="4">
<t hangText="ROLIE XML Namespace">The ROLIE namespace
(rolie-1.0) has been registered in the "ns" registry.
<vspace blankLines="1"/>URI:
urn:ietf:params:xml:ns:rolie-1.0 <vspace blankLines="1"
/>Registrant Contact: IESG <vspace blankLines="1"/>XML:
None. Namespace URIs do not represent an XML
specification.</t>
<t hangText="ROLIE XML Schema">The ROLIE schema (rolie-1.0)
has been registered in the "schema" registry. <vspace
blankLines="1"/>URI:
urn:ietf:params:xml:schema:rolie-1.0 <vspace
blankLines="1"/>Registrant Contact: IESG <vspace
blankLines="1"/>XML: See section <xref
target="appendix-schema" format="counter"/> of this
document.</t>
</list></t>
</section>
<section title="ROLIE URN Sub-namespace" anchor="iana-urn">
<t>IANA has added an entry to the "IETF URN Sub-namespace for
Registered Protocol Parameter Identifiers" registry located at
<eref target="http://www.iana.org/assignments/params/params.xml#params-1"/> as per <xref target="RFC3553">RFC3553</xref>. </t>
<t>The entry is as follows:<list>
<t>Registry name: rolie</t>
<t>Specification: This document</t>
<t>Repository: ROLIE URN Parameters. See <xref target="iana-parameters"/> [TO BE REMOVED: This registration
should take place at the following location:
https://www.iana.org/assignments/rolie]</t>
<t>Index value: See <xref target="iana-parameters"/></t>
</list></t>
</section>
<section title="ROLIE URN Parameters" anchor="iana-parameters">
<t>A new top-level registry has been created, entitled "Resource
Oriented Lightweight Information Exchange (ROLIE) Parameters".
[TO BE REMOVED: This registration should take place at the
following location: https://www.iana.org/assignments/rolie]</t>
<t>In this top-level registry, a sub-registry entitled "ROLIE URN
Parameters" has been created. Registration in this repository
is via the Specification Required policy <xref target="RFC5226"/>. Designated Expert reviews should be routed through the MILE
WG mailing list. Failing this, the Designated Expert will be
assigned by the IESG.</t>
<t>Each entry in this sub-registry must record the following fields:<list>
<t>Name: A URN segment that adheres to the pattern
{type}:{label}. The keywords are defined as follows:<list>
<t>{type}: The parameter type. The allowed value is
"category". "category" denotes a category extension as
discussed in <xref target="content-model-category"/>. While
a single value is used in this specification, future
revisions or extensions of this specification may define
additional {type} values.</t>
<t>{label}: A required US-ASCII string that conforms to the
URN syntax requirements (see <xref target="RFC2141"/>).
This string must be unique within the namespace defined by
the {type} keyword.</t>
</list></t>
<t>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.</t>
<t>Reference: A static link to the specification and section
that the definition of the parameter can be found.</t>
<t>Sub-registry: An optional field that links to an IANA
sub-registry for this parameter. If the {type} is "category",
the sub-registry must contain a "name" field whose registered
values MUST be US-ASCII. The list of names are the allowed
values of the "term" attribute in the atom:category element.
(See <xref target="content-model-category-info-type"/>). </t>
</list></t>
<t>This repository has the following initial values:</t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Extension IRI</ttcol>
<ttcol>Reference</ttcol>
<ttcol>Sub-Registry</ttcol>
<c>category:information-type</c>
<c>urn:ietf:params:rolie:category:information-type</c>
<c>This document, Section 9.4</c>
<c>[TO BE REMOVED: This registration should take place at the
following location:
https://www.iana.org/assignments/rolie/category/information-type]</c>
</texttable>
</section>
<section
title="ROLIE Security Resource Information Type Sub-Registry"
anchor="iana-information-type">
<t>A new sub-registry has been created to store ROLIE
information type values.<list hangIndent="0">
<t>Name of Registry: "ROLIE Information Types"</t>
<t>Location of Registry:
https://www.iana.org/assignments/rolie/category/information-type</t>
<t>Fields to record in the registry: <list hangIndent="0">
<t>name: The full name of the security resource
information type as a string from the printable ASCII
character set <xref target="RFC0020"/> with individual
embedded spaces allowed. The ABNF <xref
target="RFC5234"/> syntax for this field is: <list>
<t>1*VCHAR *(SP 1*VCHAR)</t>
</list></t>
<t>index: This is an IANA-assigned positive integer that
identifies the registration. The first entry added to
this registry uses the value 1, and this value is
incremented for each subsequent entry added to the
registry.</t>
<t>reference: A list of one or more URIs <xref
target="RFC3986"/> from which the registered
specification can be obtained. The registered
specification MUST be readily and publicly available
from that URI. The URI SHOULD be a stable
reference.</t>
</list></t>
<t>Allocation Policy: Specification required as per <xref
target="RFC5226"/></t>
</list></t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>This document defines a resource-oriented approach for
lightweight information exchange using HTTP over TLS, the Atom
Syndication Format, and the Atom Publishing Protocol. As such,
implementers must understand the security considerations
described in those specifications. All that follows is guidance, more specific instruction is out
of scope for this document and will be located in a dedicated
informational document.</t>
<t>All security measures SHOULD be enforced at the source, that is, a
provider SHOULD NOT return any Feed content or member Entry
content for which the client identity has not been specifically
authenticated, authorized, and audited.</t>
<t>The approach described herein is based upon all policy
enforcements being implemented at the point when a resource
representation is created. As such, producers sharing cyber
security information using this specification must take care to
authenticate their HTTP clients using a suitably strong user
authentication mechanism. Sharing communities that are exchanging
information on well-known indicators and incidents for purposes
of public education may choose to rely 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.</t>
<t>Collaborating consortiums may benefit from the adoption of a
federated identity solution, such as those based upon <xref target="SAML-core">SAML-core</xref>, <xref target="SAML-bind">SAML-bind</xref>, and <xref target="SAML-prof">SAML-prof</xref>
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.</t>
<t>Authorization of resource representations is the responsibility
of the source system, i.e. based on the authenticated user
identity associated with an HTTP(S) request. The required
authorization policies that are to be enforced must therefore be
managed by the security administrators of the source system.
Various authorization architectures would be suitable for this
purpose, such as <eref target="http://csrc.nist.gov/groups/SNS/rbac/">RBAC</eref> and/or
ABAC, as embodied in <xref target="XACML">XACML</xref>. In
particular, implementers adopting XACML may benefit from the
capability to represent their authorization policies in a
standardized, interoperable format. Note that implementers are
free to choose any suitable authorization mechanism that is
capable of fulfilling the policy enforcement requirements
relevant to their consortium and/or organization.</t>
<t>Additional security requirements such as enforcing message-level
security at the destination system could supplement the security
enforcements performed at the source system, however these
destination-provided policy enforcements are out of scope for
this specification. Implementers requiring this capability should
consider leveraging, e.g. the <RIDPolicy> element in the
RID schema. Refer to RFC6545 section 9 for more information.</t>
<t>When security policies relevant to the source system are to be
enforced at both the source and destination systems, implementers
must take care to avoid unintended interactions of the separately
enforced policies. Potential risks will include unintended denial
of service and/or unintended information leakage. These problems
may be mitigated by avoiding any dependence upon enforcements
performed at the destination system. When distributed enforcement
is unavoidable, the usage of a standard language (e.g. XACML) for
the expression of authorization policies will enable the source
and destination systems to better coordinate and align their
respective policy expressions.</t>
<t>Adoption of the information sharing approach described in this
document will enable users to more easily perform correlations
across separate, and potentially unrelated, cyber security
information providers. A client may succeed in assembling a data
set that would not have been permitted within the context of the
authorization policies of either provider when considered
individually. Thus, providers may face a risk of an attacker
obtaining an access that constitutes an undetected separation of
duties (SOD) violation. It is important to note that this risk is
not unique to this specification, and a similar potential for
abuse exists with any other cyber security information sharing
protocol. However, the wide availability of tools for HTTP
clients and Atom Feed handling implies that the resources and
technical skills required for a successful exploit may be less
than it was previously. This risk can be best mitigated through
appropriate vetting of the client at account provisioning time.
In addition, any increase in the risk of this type of abuse
should be offset by the corresponding increase in effectiveness
that this specification affords to the defenders.</t>
</section>
<section title="Acknowledgements" anchor="acknowledgements">
<t>The authors gratefully acknowledge the valuable contributions
of Tom Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj.
These individuals provided detailed review comments on earlier
drafts, and made many suggestions that have helped to improve
this document.</t>
</section>
</middle>
<back>
<!-- TODO: check normative vs informative reference use -->
<references title="Normative References"> &RFC0020;&RFC2119; &RFC3688;
&RFC3986; &RFC4287; &RFC5005; &RFC5023; &RFC5070; &RFC6546;
&RFC3553; &RFC5226; &xml-names; &RFC7589; &RFC5280; &RFC4642;
<reference anchor="relax-NG" target="https://www.oasis-open.org/committees/relax-ng/compact-20021121.html">
<front>
<title>RELAX NG Compact Syntax</title>
<author initials="J." surname="Clark" fullname="James Clark" role="editor">
<address>
<email>jjc@jclark.com</email>
</address>
</author>
<date year="2002" month="11" day="21"/>
</front>
</reference>
<reference anchor="SAML-core" target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">
<front>
<title>Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0</title>
<author fullname="Scott Cantor" initials="S." surname="Cantor">
<organization>Internet2</organization>
<address>
<email>cantor.2@osu.edu</email>
</address>
</author>
<author fullname="John Kemp" initials="J." surname="Kemp">
<organization>Nokia</organization>
<address>
<email>John.Kemp@nokia.com</email>
</address>
</author>
<author fullname="Rob Philpott" initials="R." surname="Philpott">
<organization>RSA Security</organization>
<address>
<email>rphilpott@rsasecurity.com</email>
</address>
</author>
<author fullname="Eve Maler" initials="E." surname="Maler">
<organization>Sun Microsystems</organization>
<address>
<email>eve.maler@sun.com</email>
</address>
</author>
<date year="2005" month="March"/>
</front>
<seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
<format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf"/>
</reference>
<reference anchor="SAML-prof" target="http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf">
<front>
<title>Profiles for the OASIS Security Assertion Markup
Language (SAML) V2.0</title>
<author fullname="John Hughes" initials="J." surname="Hughes">
<organization>Altos Origin</organization>
<address>
<email/>
</address>
</author>
<author fullname="Scott Cantor" initials="S." surname="Cantor">
<organization>Internet2</organization>
<address>
<email>cantor.2@osu.edu</email>
</address>
</author>
<author fullname="Jeff Hodges" initials="J." surname="Hodges">
<organization>NeuStar</organization>
<address>
<email>Jeff.Hodges@neustar.biz</email>
</address>
</author>
<author fullname="Frederick Hirsch" initials="F." surname="Hirsch">
<organization>Nokia</organization>
<address>
<email>Frederick.Hirsch@nokia.com</email>
</address>
</author>
<author fullname="Prateek Mishra" initials="P." surname="Mishra">
<organization>Principal Identity</organization>
<address>
<email>pmishra@principalidentity.com</email>
</address>
</author>
<author fullname="Rob Philpott" initials="R." surname="Philpott">
<organization>RSA Security</organization>
<address>
<email>rphilpott@rsasecurity.com</email>
</address>
</author>
<author fullname="Eve Maler" initials="E." surname="Maler">
<organization>Sun Microsystems</organization>
<address>
<email>eve.maler@sun.com</email>
</address>
</author>
<date year="2005" month="March"/>
</front>
<seriesInfo name="OASIS Standard" value="OASIS.saml-profiles-2.0-os"/>
<format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf"/>
</reference>
<reference anchor="SAML-bind" target="http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf">
<front>
<title>Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0</title>
<author fullname="Scott Cantor" initials="S." surname="Cantor">
<organization>Internet2</organization>
<address>
<email>cantor.2@osu.edu</email>
</address>
</author>
<author fullname="Frederick Hirsch" initials="F." surname="Hirsch">
<organization>Nokia</organization>
<address>
<email>Frederick.Hirsch@nokia.com</email>
</address>
</author>
<author fullname="John Kemp" initials="J." surname="Kemp">
<organization>Nokia</organization>
<address>
<email>John.Kemp@nokia.com</email>
</address>
</author>
<author fullname="Rob Philpott" initials="R." surname="Philpott">
<organization>RSA Security</organization>
<address>
<email>rphilpott@rsasecurity.com</email>
</address>
</author>
<author fullname="Eve Maler" initials="E." surname="Maler">
<organization>Sun Microsystems</organization>
<address>
<email>eve.maler@sun.com</email>
</address>
</author>
<date year="2005" month="March"/>
</front>
<seriesInfo name="OASIS Standard" value="saml-bindings-2.0-os"/>
<format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf"/>
</reference>
</references>
<references title="Informative References"> &RFC2141; &RFC3444;
&RFC5070bis; &RFC5234;
<reference anchor="xmldsig" target="https://www.w3.org/TR/xmldsig-core/">
<front>
<title>XML Signature Syntax and Processing (Second Edition)</title>
<author initials="M." surname="Bartel" fullname="Mark Bartel">
<organization/>
</author>
<author initials="J." surname="Boyer" fullname="John Boyer">
<organization/>
</author>
<author initials="B." surname="Fox" fullname="Barb Fox">
<organization/>
</author>
<author initials="B." surname="LaMacchia" fullname="Brian LaMacchia">
<organization/>
</author>
<author initials="E." surname="Simon" fullname="Ed Simon">
<organization/>
</author>
<date day="10" month="June" year="2008"/>
</front>
</reference>
<reference anchor="xmlenc" target="https://www.w3.org/TR/xmlenc-core/">
<front>
<title>XML Encryption Syntax and Processing</title>
<author initials="T." surname="Imamura" fullname="Takeshi Rissanen">
<organization/>
</author>
<author initials="B." surname="Dillaway" fullname="Blair Dillaway">
<organization/>
</author>
<author initials="E." surname="Simon" fullname="Ed Simon">
<organization/>
</author>
<date day="10" month="December" year="2002"/>
</front>
</reference>
<reference anchor="XACML" target="http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf">
<front>
<title>eXtensible Access Control Markup Language (XACML)
Version 3.0</title>
<author initials="E." surname="Rissanen" fullname="Erik Rissanen">
<organization/>
</author>
<date day="10" month="August" year="2010"/>
</front>
</reference>
<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">
<front>
<title>Architectural Styles and the Design of Network-based
Software Architectures</title>
<author initials="R." surname="Fielding" fullname="Roy Thomas Fielding">
<organization abbrev="UCI"> University of California, Irvine;
Department of Information and Computer Science
</organization>
</author>
<date year="2000"/>
</front>
<format type="text/html" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm" octets="7287"/>
</reference>
</references>
<section title="Relax NG Compact Schema for ROLIE" anchor="appendix-schema">
<t>This appendix is informative.</t>
<t>The Relax NG schema below defines the rolie:format element.</t>
<figure>
<artwork><![CDATA[
# -*- rnc -*-
# RELAX NG Compact Syntax Grammar for the rolie:format element
namespace rolie = "urn:ietf:params:xml:ns:rolie-1.0"
namespace atom = "http://www.w3.org/2005/Atom"
# rolie:format
rolieFormat =
element rolie:format {
atom:atomCommonAttributes,
attribute ns { atom:atomURI },
attribute version { text } ?,
attribute schema-location { atom:atomURI } ?,
attribute schema-type { atom:atomMediaType } ?,
empty
}]]></artwork>
</figure>
</section>
<section title="Examples of Use">
<section title="Service Discovery" anchor="example-svcdoc">
<t>This section provides a non-normative example of a client
doing service discovery.</t>
<t>An Atom service document enables a client to dynamically
discover what Feeds a particular publisher makes available.
Thus, a provider uses an Atom service document to enable
clients or other authorized parties to determine what specific
information the provider makes available to the community.
While the service document is at a required location, the
service document could also be made available at any well known
location, such as via a link from the producer's home page. </t>
<t>A client may format an HTTP GET request to retrieve the
service document from the specified location:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
GET /rolie/servicedocument
Host: www.example.org
Accept: application/atomsvc+xml ]]></artwork>
</figure>
<t>Notice the use of the HTTP Accept: request header, indicating
the MIME type for Atom service discovery. The response to this
GET request will be an XML document that contains information
on the specific Feed Collections that are provided by the
provider. </t>
<t>Example HTTP GET response:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:09:11 GMT
Content-Length: 570
Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title type="text">Vulnerabilities</atom:title>
<collection href="http://example.org/provider/vulns">
<atom:title type="text">Vulnerabilities Feed</atom:title>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
</categories>
</collection>
</workspace>
</service>]]></artwork>
</figure>
<t>This simple Service Document example shows that this server
provides one workspace, named "Vunerabilities". Within that
workspace, the producer makes one Feed Collection
available.</t>
<t>A server may also offer a number of different Feeds, each
containing different types of security automation information.
In the following example, the Feeds have been categorized. This
categorization will help the clients to decide which Feeds will
meet their needs. </t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:10:11 GMT
Content-Length: 1912
Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>Public Security Information Sharing</atom:title>
<collection
href="http://example.org/provider/public/vulns">
<atom:title>Public Vulnerabilities</atom:title>
<link rel="service"
href="www.example.com/rolie/servicedocument">
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
</categories>
</collection>
</workspace>
<workspace>
<atom:title>Private Consortium Sharing</atom:title>
<collection
href="http://example.org/provider/private/vulns">
<atom:title>Incidents</atom:title>
<link rel="service"
href="www.example.com/rolie/servicedocument">
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="incidents"/>
</categories>
</collection>
</workspace>
</service>]]></artwork>
</figure>
<t>In this example, the provider is making available a total of
two Feed Collections, organized into two different workspaces.
The first workspace contains a Feed consisting of publicly
available software vulnerabilities. The second workspace
provides one additional vulnerability Feed, for use by a
private sharing consortium. An appropriately authenticated and
authorized client may then proceed to make GET requests for one
or more of these Feeds. The publicly provided incident
information may be accessible with or without authentication.
However, users accessing the Feed targeted to the private
sharing consortium would be expected to authenticate, and
appropriate authorization policies would subsequently be
enforced by the Feed provider.</t>
</section>
<section title="Feed Retrieval" anchor="example-feed">
<t>This section provides a non-normative example of a client
retrieving an incident Feed.</t>
<t>Having discovered the available security information sharing
Feeds, a client who is a member of the general public may be
interested in receiving the Feed of public vulnerabilities. The
client may retrieve this Feed by performing an HTTP GET
operation on the indicated URL. </t>
<t>Example HTTP GET request for a Feed:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
GET /provider/vulns
Host: www.example.org
Accept: application/atom+xml ]]></artwork>
</figure>
<t>The corresponding HTTP response would be an XML document
containing the incidents Feed:</t>
<t>Example HTTP GET response for a Feed:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:20:11 GMT
Content-Length: 2882
Content-Type: application/atom+xml;type=feed;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xml:lang="en-US">
<id>http://www.example.org/provider/vulns</id>
<title type="text">
Atom formatted representation of
a feed of XML incident documents
</title>
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/>
<updated>2012-05-04T18:13:51.0Z</updated>
<link rel="self" href="http://example.org/provider/vulns" />
<link rel="service"
href="http://example.org/rolie/servicedocument"/>
<entry>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<id>
http://www.example.org/provider/vulns/123456
</id>
<title>Sample Incident</title>
<published>2014-08-04T18:13:51.0Z</published>
<updated>2014-08-05T18:13:51.0Z</updated>
<summary>A short description of this resource</summary>
<content type="application/xml"
src="http://www.example.org/provider/vulns/123456/data"
</entry>
<entry>
<!-- ...another entry... -->
</entry>
</feed> ]]></artwork>
</figure>
<t>This Feed document has two atom entries, one of which has been
elided. The completed Entry illustrates an Atom <entry>
element that provides a summary of essential details about one
particular incident. Based upon this summary information and
the provided category information, a client may choose to do an
HTTP GET operation to retrieve the full details of the
incident. This example exemplifies the benefits a RESTful
alternative has to traditional point-to-point messaging
systems.</t>
</section>
<section title="Entry Retrieval" anchor="example-entry">
<t>This section provides a non-normative example of a client
retrieving an incident as an Atom Entry.</t>
<t>Having retrieved the Feed of interest, the client may then
decide based on the description and/or category information
that one of the entries in the Feed is of further interest. The
client may retrieve this incident Entry by performing an HTTP
GET operation on the indicated URL. </t>
<t>Example HTTP GET request for an Entry:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
GET /provider/vulns/123456
Host: www.example.org
Accept: application/atom+xml ]]></artwork>
</figure>
<t>The corresponding HTTP response would be an XML document
containing the incident: </t>
<t>Example HTTP GET response for an Entry:</t>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:30:11 GMT
Content-Length: 4965
Content-Type: application/atom+xml;type=entry;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<entry>
<id>http://www.example.org/provider/vulns/123456</id>
<title>Sample Incident</title>
<published>2012-08-04T18:13:51.0Z</published>
<updated>2012-08-05T18:13:51.0Z</updated>
<atom:category
scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/>
<summary>A short description of this incident resource</summary>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<content type="application/xml"
src="http://www.example.org/provider/vulns/123456/data">
</content>
</entry> ]]></artwork>
</figure>
<t>As can be seen in the example response, above, an XML document
is linked to in the attributes of the Atom <content>
element. The client may now process the XML document as
needed.</t>
<t>Note also that, as described previously, the content of the
Atom <category> element is application-defined. The Atom
categories have been assigned based on the IANA table content
model.</t>
<t>Finally, it should be noted that in order to optimize the
client experience, and avoid an additional round trip, a Feed
provider may choose to include certain Entry elements inline,
as part of the Feed document. That is, an Atom <entry>
element within a Feed document may contain arbitrary
non-required Atom elements as children. In this case, the
client will receive the more explicit information on entries
from within the Feed. The decision of whether to include extra
Entry elements inline or to include it as a link is a design
choice left to the Feed provider (e.g. based upon local
environmental factors such as the number of entries contained
in a Feed, the available network bandwidth, the available
server compute cycles, the expected client usage patterns,
etc.). </t>
</section>
</section>
<section title="Change History" anchor="appendix-delta">
<t>Changes in draft-ietf-mile-rolie-04 since
draft-ietf-mile-rolie-04 version, July 8, 2016 to October 31,
2016<list style="symbols">
<t>Further specification and clarification of requirements</t>
<t>IANA Considerations and extension system fleshed out and
described.</t>
<t>Examples and References updated.</t>
<t>Schema created.</t>
<t>Fixed both internal section and external document
referencing.</t>
<t>Removed XACML Guidance Appendix. This will be added to a
future draft on ROLIE Authentication and Access Control.</t>
</list></t>
<t>Changes made in draft-ietf-mile-rolie-03 since
draft-ietf-mile-rolie-02 version, May 27, 2016 to July 8, 2015
<list style="symbols">
<t>Atom Syndication and Atom Pub requirements split and greatly
expanded for increased justification and technical
specification.</t>
<t>Reintroduction and reformatting of some use case examples in
order to provide some guidance on use.</t>
<t>Established rough version of IANA table extension system along
with explanations of said system.</t>
<t>Re-organized document to put non-vital information in
appendices.</t>
</list> </t>
<t>Changes made in draft-ietf-mile-rolie-02 since
draft-field-mile-rolie-01 version, December, 2015 to May 27,
2016: <list style="symbols">
<t>All CSIRT and IODEF/RID material moved to companion CSIRT
document TODO: add reference </t>
<t>Recast document into a more general use perspective. The
implication of CSIRTs as the defacto end-user has been removed
where ever possible. All of the original CSIRT based use cases
remain completely supported by this document, it has been
opened up to support many other use cases.</t>
<t>Changed the content model to broaden support of
representation</t>
<t>Edited and rewrote much of sections 1,2 and 3 in order to
accomplish a broader scope and greater readability</t>
<t>Removed any requirements from the Background section and, if
not already stated, placed them in the requirements section</t>
<t>Re-formatted the requirements section to make it clearer that
it contains the lions-share of the requirements of the
specification</t>
</list> </t>
<t>Changes made in draft-ietf-mile-rolie-01 since
draft-field-mile-rolie-02 version, August 15, 2013 to December 2,
2015: <list style="symbols">
<t>Added section specifying the use of RFC5005 for Archive and
Paging of Feeds.</t>
<t>Added section describing use of atom categories that
correspond to IODEF expectation class and impact classes. See:
normative-expectation-impact </t>
<t>Dropped references to adoption of a MILE-specific HTTP media
type parameter.</t>
<t>Updated IANA Considerations section to clarify that no IANA
actions are required.</t>
</list> </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:18:59 |