One document matched: draft-ietf-mile-rolie-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY xml-names SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-names-20091208.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3986 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4287 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml">
<!ENTITY RFC5070 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5070.xml">
<!ENTITY RFC5023 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5023.xml">
<!ENTITY RFC5005 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5005.xml">
<!ENTITY RFC6545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6545.xml">
<!ENTITY RFC6546 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6546.xml">
<!ENTITY RFC5070bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mile-rfc5070-bis-25.xml">
]>
<?xml-stylesheet type="text/css" href="rfc7749.css"?>
<rfc ipr="trust200902" category="info" docName="draft-ietf-mile-rolie-03">
<!-- Working draft of draft03 -->
<?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 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 in 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. Those seeking to provide support for specific
security automation information types should refer to the
specification for that format 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>
</section>
<section title="XML-related Conventions">
<section title="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>
<!-- TODO: Add IANA entry for http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns -->
<t>"rolie" is used for the "urn:ietf:params:xml:ns:rolie:1.0"
namespace defined in section <xref target="iana-urn"
format="counter"/> of this specification.</t>
</list></t>
</section>
<section title="RELAX NG Schema">
<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. Complete schemas appear
for the "urn:ietf:params:xml:ns:rolie-1.0" namespace in
appendix <xref target="appendix-schema" format="counter"/>.
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>It is well known thatthreats to computer security are evolving
ever more rapidly as time goes on. As software increases in
complexity, the number of vulnerabilities in systems and networks
can increase exponentially. Threat actors looking to exploit
these vulnerabilities are making more frequent and more widely
distributed attacks across a large variety of systems. The
adoption of liberal information sharing amongst attackers creates
a window of as little as a few hours between the discovery of a
vulnerability and attacks on a vulnerable system. As the skills
and knowledge required to identify and combat these attacks
become more and more specialized, even a well established and
secure system may find itself unable to quickly respond to an
incident. Effective identification of and response to a
sophisticated attack requires open cooperation and collaboration
between defending operators, software vendors, and end-users. To
improve the timeliness of responses, automation must be used to
acquire, contextualize, and put to use shared computer security
information.</t>
<t>Existing approaches to computer security information sharing
often use message exchange patterns that are point-to-point, and
event-driven. 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 exsisting 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 enabled to
share selected information proactively as appropriate. Proactive
sharing greatly aids knowledge dissemination, and improves
response times and usability.</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>
<t>Consider also the case of an automated endpoint management
system attempting to proactively prevent software flaws from
compromising the security of the affected systems. During its
full network sweep, the endpoint monitoring system would check
each endpoint for outdated or vulnerable software. This system
would benefit from having access to not only the software
vendor's list of vulnerabilities, but also vulnerabilities
discovered by other vulnerability researchers. An advanced system
could even give back to this sharing consortium by sharing any
vulnerabilities that it discovers. The natural conclusion of such
a sharing network is an automated security solution that can
dynamically find and collect information from a globally
distributed web of information repositories.</t>
<t>The following section discusses additional specific technical
issues that motivated the development of this alternative
approach.</t>
<section
title="Message-oriented versus Resource-oriented Architecture"
anchor="msg-vs-roa">
<t>The existing approaches to computer security information
sharing are based upon message-oriented interactions. The
following paragraphs explore some of the architectural
constraints associated with message-oriented interactions and
consider the relative merits of an alternative model based on a
resource-oriented architecture for use in some use case
scenarios.</t>
<t>ROLIE specifies a resource-oriented architecture that attempts
to address the issues present in a message-oriented
architecture.</t>
<section title="Message-oriented Architecture" anchor="message">
<t>In general, message-based integration architectures may be
based upon either an RPC-style or a document-style binding.
The message types defined by <xref target="RFC6545">Real-time
Inter-network Defense (RID)</xref> represents an example of
an RPC-style request. This approach imposes implied
requirements for conversational state management on both of
the communicating RID endpoint(s). Experience has shown that
this state management frequently becomes the limiting factor
with respect to the runtime scalability of an RPC-style
architecture.</t>
<t>In addition, the practical scalability of a peer-to-peer
message-based approach will be limited by the administrative
procedures required to manage O(N^2) trust relationships and
at least O(N) policy groups.</t>
<t>As long as the number of participating entities in an
information sharing consortium is limited to a relatively
small number of nodes (i.e., O(2^N), where N < 5), these
scalability constraints may not represent a critical concern.
However, when there is a requirement to support a
significantly larger number of participating peers, a
different architectural approach will be required. Towards
the goal to create a large-scale network of entities sharing
information, this traditional architecture only creates small
and isolated groupings of sharing, encouraging effort
duplication between these sharing islands. One alternative to
the message-based approach that has demonstrated scalability
and a high degree of connectedness is the <xref target="REST"
>REST</xref> architectural style.</t>
</section>
<section title="Resource-Oriented Architecture"
anchor="roa-benefits">
<t>Applying the REST architectural style to the problem domain
of security information sharing involves exposing information
in 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
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
incident object may contain links to the related indicator
resource(s). In this way, the server remains stateless with
respect to a series of client requests.</t>
<section
title="A Resource-Oriented Use Case: "Mashup""
anchor="mashup">
<t>In this section we consider an example scenario for
creating a computer security "mashup".</t>
<t>A producer creates and maintains a feed of information on
threat actors, whilst another creates and maintains a feed
of attack indicators. Each has authorized a large
consortium of security analysts to access these feeds as
they see fit. Any one of these analysts can then make
HTTP(s) requests to the servers to collect sets of
information from each provider. The resulting correlations
may yield new insights that enable a more timely and
effective defensive response. Of course, this report may,
in turn, be made available to others as a new
Web-addressable resource, reachable via another URL. By
exposing information using the RESTful approach in this
way, the effectiveness of the collaboration amongst a
consortium of cyber security stakeholders can be greatly
improved.</t>
</section>
</section>
</section>
<section title="Use of the Atom Publishing Protocol">
<t>This specification defines a profile of the <xref
target="RFC5023">Atom Publishing Protocol (AtomPub)</xref> and
<xref target="RFC4287">Atom Syndication Format</xref> providing
implementation requirements for a security information sharing
solution as a RESTful Web service.</t>
<t>This document assumes that the reader has an understanding of
both the AtomPub and Atom Syndication Format
specifications.</t>
<t>The following two sections of this document provide
requirements for using the Atom Syndication Format and AtomPub
as a RESTful binding for security automation information
sharing.</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.</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 ROLE 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.</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 clients.</t>
<t>An implementation can provide any number of Collections
within a given Workspace. It is RECOMMENDED that each
collection appear in only a single Workspace. This helps to
reduce the number of duplicate collections that need to be
examined to discover information that is relevant to a
given client.</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. 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 indicated by the app:collection "href" attribute
value. This ensures that the category metadata associated
with the Feed is discoverable in 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:information-type". This category
MUST have an appropriate "term" attribute value as defined
in section <xref target="category-information-type"
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: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:information-type". This
allows other category metadata to be included.</t>
</list></t>
</section>
</section>
<section title="Service Discovery">
<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>
<!-- Discoverable how? This level of specificity does not really do anything for discovery-->
<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="svc-doc" format="counter"/>.</t>
<t>The service document SHOULD (TODO: MUST?) 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 implmentations 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.<!-- reference the specs for this --></t>
</section>
<section title="Transport Layer Security"
anchor="normative-transport-sec">
<!-- This section needs to be more descriptive-->
<t>Implementations MUST support server-authenticated TLS.</t>
<t>Implementations MAY support mutually authenticated TLS.</t>
<t>Implementations MAY support client authenticated TLS.</t>
</section>
<section title="User Authentication" anchor="normative-user-auth">
<t>Implementations MUST support user authentication. User
authentication MAY be enabled for specific feeds.</t>
<t>Implementations MAY support more than one client
authentication method.</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 as per SAML 2.0.</t>
</section>
<section title="User Authorization" anchor="normative-user-authz">
<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>
<t>Authorization for a resource MAY be adjudicated based on the
value(s) of the associated Atom <category>
element(s).</t>
</section>
<section title="/ (forward slash) Resource URL" anchor="rid-ref">
<!-- 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>. Consistent with RFC6546 errata, a client
requesting a GET on "/" MUST receive an HTTP status code 405
Method Not Allowed. An implementation MAY provide full support
for RFC6546 such that a POST to "/" containing a recognized RID
message type just works. 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. This resource could also leverage the new draft by
reschke that proposes HTTP status code 308 (cf:
draft-reschke-http-status-308-07.txt). TODO</t>
</section>
<section title="HTTP methods" anchor="inc-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.</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 including a set of configuration checklists or
software vulnerabilities. Each entry in an atom:feed represents
an individual resource, such as a specific checklist or
software vulnerability record. Additional Feeds can be used to
represent collections of other meaningful and useful security
automation resources.</t>
<t>This Atom feed definition represents a stricter definition of
the Atom entry element. Any element not specified here inherits
its definition and requirements from RFC 4287.</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 may be categorized and may 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 a ROLIE 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:information-type". This category
MUST have an appropriate "term" attribute value as defined
in section <xref target="category-information-type"
format="counter"/>. This ensures that a given Collection
corresponds to a specific type of security automation
information. All member entries in the collection MUST
represent security automation information records of this
information type.</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: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: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. The following are link relations that
provide state transitions related to a ROLIE Atom feed.<list
style="symbols">
<t>"service" - Indicates that the href value of the link
identifies a resource IRI that can be used to retrieve an
Atom Service Document associated with the feed. A feed MUST
include one or more links with rel="service" to point to
the service document(s) that are associated with the feed.
The "service" link relationship type is defined in the
<eref
target="https://www.iana.org/assignments/link-relations/link-relations.xhtml"
>IANA Link Relations Registry</eref>.</t>
<t>"search" - Indicates that the href value of the link
identifies a resource IRI that can be used to search
through the containing feed and related resources. A feed
MAY include one or more links with rel="search" to point
TBD.<!-- Figure out search --> The "search" link
relationship type is defined in the <eref
target="https://www.iana.org/assignments/link-relations/link-relations.xhtml"
>IANA Link Relations Registry</eref>.</t>
</list> </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 the remaining
resource representation as if the unrecognized link element
did not appear.</t>
<t>The <xref target="RFC5005">Feed Paging and Archiving</xref>
Atom extension provides capabilities for paging and archiving
of feeds.</t>
<t>A 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 retriving the first X entries in a feed to process only
the entries that have changed since the last access to a
ROLIE repository feed. As a practical matter, the full result
set will likely need to be divided into more manageable
portions. Based on <xref target="RFC5005">RFC5005 section
3</xref>, the links SHOULD be included in all feeds to
support paging using the following link relation types:<list
style="symbols">
<t>"first" - Indicates that the href value of the link
identifies a resource IRI for the furthest preceding page
of the feed.</t>
<t>"last" - Indicates that the href value of the link
identifies a resource IRI for the furthest following page
of the feed.</t>
<t>"previous" - Indicates that the href value of the link
identifies a resource IRI for the immediately preceeding
page of the feed.</t>
<t>"next" - Indicates that the href 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">
<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>An historical feed may need to be stable, and/or divided
into some defined epochs. Implementations SHOULD support the
mechanisms described in <xref target="RFC5005">RFC5005
section 4</xref> to provide capabilities for maintaining
archiving of feeds.</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 RFC 4287 for use in a ROLE-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: </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 be the serialization type of the
content, for example, XML or JSON. The src attribute is a
link to the payload.</t>
<!-- Discuss complex types -->
</section>
<section title="Use of the "atom:link" Element"
anchor="atom-synd-entry-link">
<t>There MAY be zero or more atom:link elements in the entry.
The content element MUST adhere to this definition:</t>
<t>The link element follows the definition laid out in the Atom
Syndication Document.</t>
<t>If there entries with the same format and category but a
different type, it MUST be linked to using the "alternate"
link relation.</t>
<!--
<c>history (use version-history and/or next-archive, prev-archive, and current: keep?)</c>
<c>Provides a link to a collection of zero or more historical
entries that are associated with the resource.</c>
<c>information (not sure what this does: keep?)</c>
<c>Provides a link to a collection of zero or more instances
of information that are associated with the resource.</c>
</texttable>
-->
</section>
<section title="Use of the "rolie:format" Element"
anchor="atom-synd-entry-rolie-format">
<t>There MUST be exactly one rolie:format element in the Entry.
This format SHOULD be one of the formats listed under the
category of this entry as discussed in the and Content Model
section. The format is contained in the content of this
tag.</t>
</section>
</section>
<section title="Link Relations">
<t>In addition to the standard Link Relations defined by the Atom
specification, this specification defines the following
additional Link Relation terms, which are introduced
specifically in support of the Resource-Oriented Lightweight
Information Exchange protocol.</t>
<!--
<texttable anchor="link-relations-table"
title="Link Relations for Resource-Oriented Lightweight Indicator Exchange">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Conformance</ttcol>
<c>service</c>
<c>Provides a link to an atom service document associated with
the collection feed.</c>
<c>MUST</c>
<c>search</c>
<c>Provides a link to an associated Open Search document that
describes a URL template for search queries.</c>
<c>MUST</c>
<c>history</c>
<c>Provides a link to a collection of zero or more historical
entries that are associated with the resource.</c>
<c>MUST</c>
<c>information</c>
<c>Provides a link to a collection of zero or more instances
of information that are associated with the resource.</c>
<c>MUST</c>
</texttable>
<t>Unless specifically registered with IANA these short names
MUST be fully qualified via concatenation with a base-uri. An
appropriate base-uri could be established via agreement
amongst the members of an information sharing consortium. For
example, the rel="indicators" relationship would become
rel="http://www.example.org/rolie/incidents/relationships/indicators."</t>
<t>An Atom Entry MAY include additional link relationships not
specified here. If a client encounters a link relationship of
an unknown type the client MUST ignore the offending link and
continue processing the remaining resource representation as
if the offending link element did not appear.</t>
-->
<t>TODO: This section needs to be expanded.</t>
</section>
</section>
<section title="Use of OpenSearch">
<t>Implementers MUST support <xref target="opensearch">OpenSearch
1.1</xref> as the mechanism for describing how clients may form
search requests.</t>
<t>Implementers MUST provide a link with a relationship type of
"search". This link SHALL return an Open Search Description
Document as defined in OpenSearch 1.1.</t>
<t>Implementers MUST fully qualify all OpenSearch URL template
parameter names using the defined XML namespaces, as
appropriate.</t>
</section>
<section title="Characterizing ROLIE Collections and Resources"
anchor="content-model">
<t>This specification does not require a particular security
automation information type or content format; rather, it
provides extension points using IANA tables to allow for future
extensions of supported information types and formats.</t>
<t>A given security automation information type is respresented
using the "atom:category" element. In this way, an
"atom:category" element 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>
</list></t>
<t>As mentioned earlier, a key goal of this specification is to
allow a consumer to identify security automation information
resources of interest, and then choose a suitable format of the
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 following sections describe how information types are
defined and used, and how specific content formats are declared
in ROLIE.</t>
<section
title="Identification of Security Automation Information Types">
<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 thought on possible
information types, which will also include other information
used to automate security processes.</t>
<t>This document does not specific any information types.
Instead, information types in ROLIE are expected to be defined
in extension documents that describe one or more new
information types. This allows the information types used by
ROLIE implementations to grow over time to support new security
automation use cases. These extension documents may also
enhance ROLIE resource representations by defining link
relations, categories, and other AtomPub and Atom Syndication
Format data model extensions to address the representational
needs of specific information types. New information types are
added to ROLIE through registrations to the IANA Security
Resource Information Type registry defined in section <xref
target="iana-information-type" format="counter"/>.</t>
</section>
<section
title="General Use of the "atom:category" Element"
anchor="category-information-type">
<t>The core extension point within this specification is the
ability to define different security automation information
types, which can be used to characterize the type of
information contained in a ROLIE resource collection. The
information type of a resource collection is characterized
using an "atom:category" element with a "scheme" attribute
value of "urn:ietf:params:rolie:information-type", and a "term"
attribute value identifying the specific information type
declared.</t>
<t>For example, the security automation information type
"incident" would be identified as follows:<list style="none">
<t><atom:category
scheme="urn:ietf:params:rolie:information-type"
term="incident"/></t>
</list></t>
<t>The Uniform Resource Name (URN) <xref target="RFC2141"/>
"urn:ietf:params:rolie:information-type" is registered with
IANA as described in section <xref target="iana-parameters"
format="counter"/>.</t>
<t>Registered security automation information type values are
defined in the IANA table described in section <xref
target="iana-information-type" format="counter"/>.</t>
</section>
<section
title="Identification of Security Automation Information Formats">
<t>A given information type may have a number of supported
formats. Each format is expected to have a specification that
defines the data model for the format. 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". By declaring the data model used in this way, 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 understandable by
the consumer.</t>
<!--
<t>The general category of information as given by the "Category"
Column in the IANA table is declared in the atomCategory element
of the collection. The supported formats of representation of
the category are provided by the "Formats" column, and declared
in the rolie:format element in the entry. Finally, links to the
specifications for the format are provided in the "schema"
column. The particular serialization of a format is stored
within the type attribute of the content element in the
entry.</t>
<t>Feed implementers MAY provide Atom categories that do not
correspond to categories described in that IANA table, but run
the risk of losing interoperability when doing so. Note that
additional documents may specify mandatory-to-implement
categories for domain-specific reasons. This draft is not
concerned with such MTI categories.</t>
-->
<t>TODO: Need to describe the structure and use of the
rolie:format element.</t>
</section>
</section>
<section title="Formal Syntax for the ROLIE Schema"
anchor="formal-syntax">
<t>TODO: define a schema for the "rolie:format" element.</t>
</section>
<section title="IANA Considerations TODO" anchor="sec-iana">
<t>This document defines a resource-oriented approach to security
information sharing, where such information may include a variety
of security resource categories, such as software identifiers
(e.g. tags), incident reports, configuration assessment guidance,
vulnerability assessment guidance, and so on.</t>
<t>TODO: Complete registration request specifics.</t>
<section title="XML Namespaces and Schema URNs" anchor="iana-urn">
<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="formal-syntax" format="counter"/> of this
document.</t>
</list> </t>
</section>
<section title="ROLIE Parameters" anchor="iana-parameters">
<t>ROLIE uses URNs to represent category schemes. This section
creates and registers an IETF URN sub-namespace for use in
ROLIE specifications and future extensions.</t>
<!-- Add IANA entry for this scheme -->
<t>TODO: Add entry for:
"urn:ietf:params:rolie:category:information-type"</t>
<!-- Use as an example: https://tools.ietf.org/html/rfc7643#section-10.2 -->
</section>
<section title="Security Resource Information Type Registry"
anchor="iana-information-type">
<t>This document creates the following registry for IANA to
manage: <list hangIndent="0">
<t>Name of Registry: "Security Resource Information Type"</t>
<t>Location of Registry:
https://www.iana.org/assignments/security-resource-information-type</t>
<t>Fields to record in the registry:</t>
<t><list hangIndent="0">
<t>Full Name: The full name of the security resource
information type as a string from the printable ASCII
character set RFC0020 with individual embedded spaces
allowed. The ABNF RFC5234 syntax for this field is: <list>
<t>1*VCHAR *(SP 1*VCHAR)</t>
</list></t>
<t>Security Resource 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>Description: A complete description of the security
resource information type as a string from the printable
ASCII character set RFC0020 with individual embedded spaces
allowed. The ABNF RFC5324 syntax for this field is: <list
hangIndent="0">
<t>1*VCHAR *(SP 1*VCHAR)</t>
</list> </t>
<t>Specification URI/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>Initial registry contents: None.</t>
<t>Allocation Policy: Specification required RFC5226 (which
implies expert review RFC5226).</t>
</list></t>
<t>The Designated Expert is expected to consult with the MILE
(Managed Incident Lightweight Exchange) working group or is
successor if any such WG exists (e.g., via email to the working
group's mailing list). The Designated Expert is expected to
review the request and validate the appropriateness of the
name, description, and associated specifications for the
security resource category.</t>
</section>
</section>
<section title="Security Considerations TODO" anchor="sec-security">
<t>This document defines a resource-oriented approach to
lightweight information exchange using HTTP, TLS, Atom Syndicate
Format, and Atom Publishing Protocol. As such, implementers must
understand the security considerations described in those
specifications.</t>
<t>In addition, there are a number of additional security
considerations that are unique to this specification.</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, e.g. 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 TLS client certificates, or 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> and <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>All security measures MUST be enforced at the source, that is, a
provider SHALL NOT return any feed content or member entry
content for which the client identity has not been specifically
authenticated, authorized, and audited.</t>
<t>Sharing communities that have a requirement for forward message
security (such that client systems are required to participate in
providing message level security and/or distributed authorization
policy enforcement), MUST use TODO.</t>
<t>The implementation details of the authorization scheme chosen by
a ROLIE-compliant provider are out of scope for this
specification. 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>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.</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>
<t>While it is a goal of this specification to enable more agile
cyber security information sharing across a broader and varying
constituency, there is nothing in this specification that
necessarily requires this type of deployment. A cyber security
information sharing consortium may chose to adopt this
specification while continuing to operate as a gated community
with strictly limited membership.</t>
</section>
<section title="Acknowledgements" anchor="acknowledgements">
<t>The author gratefully acknowledges the valuable contributions of
Tom Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These
individuals provided detailed review comments on earlier drafts,
and many suggestions that have helped to improve this document
.</t>
</section>
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC3688;
&RFC3986;
&RFC4287; &RFC5005; &RFC5023; &RFC5070; &RFC6546;
&xml-names; <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="opensearch"
target="http://www.opensearch.org/Specifications/OpenSearch/1.1">
<front>
<title>OpenSearch 1.1 draft 5 specification</title>
<author initials="D." surname="Clinton"
fullname="Dewitt Clinton">
<organization abbrev="OpenSearch">OpenSearch
Community</organization>
</author>
<date year="2011"/>
</front>
<seriesInfo name="OASIS Committee Specification"
value="saml-core-2.0-os"/>
<format type="text/html"
target="https://www.oasis-open.org/committees/relax-ng/compact-20021121.html"
/>
</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;
&RFC6545; &RFC5070bis; <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="Use Case Examples">
<section title="Service Discovery" anchor="svc-doc">
<t>This section provides a non-normative example of a client
doing service discovery. TODO: Standardize location of doc?</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. The
service document could be made available at any well known
location, such as via a link from the CSIRT's home page. One
common technique is to include a link in the <HEAD>
section of the organization's home page, as shown below: </t>
<t>Example of bootstrapping Service Document discovery:</t>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
<link rel="introspection"
type="application/atomsvc+xml"
title="Atom Publishing Protocol Service Document"
href="/csirt/svcdoc.xml" /> ]]></artwork>
</figure>
<t>A client may then format an HTTP GET request to retrieve the
service document:</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/svcdoc.xml
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
CSIRT. </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"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xml:lang="en-US">
<workspace>
<atom:title type="text">Incidents</atom:title>
<collection href="http://example.org/provider/incidents">
<atom:title type="text">Incidents Feed</atom:title>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:information-type"
term="vulnerability"/>
</categories>
<accept>application/atom+xml; type=entry</accept>
</collection>
</workspace>
</service> ]]></artwork>
</figure>
<t>This simple Service Document example shows that this server
provides one workspace, named "Incidents". Within that
workspace, the producer makes one feed collection available.
When attempting to GET or POST entries to that feed collection,
the client must indicate a content type of
application/atom+xml.</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/vulnerabilties">
<atom:title>Public Vulnerabilities</atom:title>
<accept>application/atom+xml; type=entry</accept>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:information-type"
term="vulnerability"/>
</categories>
</collection>
<collection
href="http://example.org/provider/public/incidents">
<atom:title>Public Incidents</atom:title>
<accept>application/atom+xml; type=entry</accept>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:information-type"
term="incident"/>
</categories>
</collection>
</workspace>
<workspace>
<atom:title>Private Consortium Sharing</atom:title>
<collection
href="http://example.org/provider/private/incidents" >
<atom:title>Incidents</atom:title>
<accept>application/atom+xml;type=entry</accept>
<categories fixed="yes">
<atom:category
scheme="urn:ietf:params:rolie:information-type"
term="incident"/>
</categories>
</collection>
</workspace>
</service> ]]></artwork>
</figure>
<t>In this example, the CSIRT is providing a total of three feed
collections, organized into two different workspaces. The first
workspace contains two feeds, consisting of publicly available
software vulnerabilities and publicly available incidents,
respectively. The second workspace provides one additional
feed, for use by a sharing consortium. The feed contains
incident information containing entries related to three
purposes: traceback, mitigation, and reporting. The entries in
this feed are categorized with a restriction of either
"Need-to-Know" or "private". 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="feed-doc">
<t>This section provides a non-normative example of a client
retrieving an incident feed. TODO</t>
<t>Having discovered the available security information sharing
feeds, an authenticated and authorized client who is a member
of the private sharing consortium may be interested in
receiving the feed of known incidents. 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/private/incidents
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">
<generator version="1.0">
Example Provider ROLIE Feed Generator
</generator>
<id>http://www.example.org/provider/private/incidents</id>
<title type="text">
Atom formatted representation of
a feed of XML incident documents
</title>
<!-- The category is taken from the related IANA table -->
<atom:category
scheme="urn:ietf:params:rolie:information-type"
term="incident"/>
<updated>2012-05-04T18:13:51.0Z</updated>
<author>
<email>provider@example.org</email>
<name>Example Provider</name>
</author>
<!-- By convention there is usually a self link for the feed -->
<link href="http://www.example.org/provider/private/incidents"
rel="self" type="application/atom+xml"/>
<entry>
<id>
http://www.example.org/provider/private/incidents/123456
</id>
<title>Sample Incident</title>
<!-- by convention -->
<link
href="http://www.example.org/provider/private/incidents/12345"
rel="self" type="application/atom+xml"/>
<!-- required by Atom spec -->
<link
href="http://www.example.org/provider/private/incidents/12345"
rel="alternate" type="xml"/>
<published>2014-08-04T18:13:51.0Z</published>
<updated>2014-08-05T18:13:51.0Z</updated>
<summary>A short description of this resource</summary>
</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="entry-doc">
<t>This section provides a non-normative example of a client
retrieving an incident as an Atom entry. TODO</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/private/incidents/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/private/incidents/123456</id>
<title>Sample Incident</title>
<!-- by convention -->
<link href="http://www.example.org/csirt/private/incidents/123456"
rel="self" type="application/atom+xml"/>
<!-- required by Atom spec -->
<link href="http://www.example.org/csirt/private/incidents/123456"
rel="alternate" type="IODEF"/>
<published>2012-08-04T18:13:51.0Z</published>
<updated>2012-08-05T18:13:51.0Z</updated>
<!-- The category is taken from the related IANA table -->
<atom:category
scheme="urn:ietf:params:rolie:information-type"
term="incident"/>
<summary>A short description of this incident resource</summary>
<!-- Typical operations that can be
performed on this entry include edit -->
<link href="http://www.example.org/csirt/private/incidents/123456"
rel="edit"/>
<!-- the next and previous are just sequential access,
may not map to anything related to this resource -->
<link href="http://www.example.org/csirt/private/incidents/123457"
rel="next"/>
<link href="http://www.example.org/csirt/private/incidents/123455"
rel="previous"/>
<!-- navigate up to the full collection.
Might also be rel="collection" as per IANA registry -->
<link href="http://www.example.org/csirt/private/incidents"
rel="up"/>
<content type="application/xml">
<xml>
<tag>
<data> Example </data>
</tag>
</xml>
</content>
</entry> ]]></artwork>
</figure>
<t>As can be seen in the example response, above, an XML document
is contained within 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 the entry content inline, as
part of the feed document. That is, an Atom <entry>
element within a Feed document may contain an Atom
<content> element as a child. In this case, the client
will receive the full content of the entries within the feed.
The decision of whether to include the entry content 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 title="Use Case: Search" anchor="search-query">
<t>This section provides a non-normative example of a search use
case. </t>
<t> The following example provides a RESTful solution to handling
search results. Note that in the RESTful approach described
herein there is no requirement to define a query language.
Instead, implementations may provide support for search
operations via existing search facilities, and advertise these
capabilities via an appropriate URL template. Clients
dynamically retrieve the search description document, and
invoke specific searches via an instantiated URL template. </t>
<t>An HTTP response body may include a link relationship of type
"search." This link provides a reference to an OpenSearch
description document.</t>
<t>Example HTTP response that includes a "search" link:</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: nnnn
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"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2005/Atom file:/
C:/schemas/atom.xsd
urn:ietf:params:xml:ns:iodef-1.0
file:/C:/schemas/iodef-1.0.xsd"
xml:lang="en-US">
<link href="http://www.example.org/opensearchdescription.xml"
rel="search"
type="application/opensearchdescription+xml"
title="CSIRT search facility" />
<!-- ...other links... -->
<entry>
<!-- ...zero or more entries... -->
</entry>
</feed> ]]></artwork>
</figure>
<t>The OpenSearch Description document contains the information
needed by a client to request a search. An example of an Open
Search description document is shown below:</t>
<t>Example HTTP response that includes a "search" link:</t>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>CSIRT search example</ShortName>
<Description>Cyber security information
sharing consortium search interface</Description>
<Tags>example csirt indicator search</Tags>
<Contact>admin@example.org</Contact>
<!-- optionally, other elements, as per OpenSearch specification -->
<Url type="application/opensearchdescription+xml" rel="self"
template="http://www.example.com/csirt/opensearchdescription.xml"/>
<Url type="application/atom+xml" rel="results"
template="http://www.example.org/csirt?q={searchTerms}&
format=Atom+xml"/>
<LongName>www.example.org CSIRT search</LongName>
<Query role="example" searchTerms="incident" />
<Language>en-us</Language>
<OutputEncoding>UTF-8</OutputEncoding>
<InputEncoding>UTF-8</InputEncoding>
</OpenSearchDescription> ]]></artwork>
</figure>
<t>The OpenSearch Description document shown above contains two
<Url> elements that contain parametrized URL templates.
These templates provide a representation of how the client
should make search requests. The exact format of the query
string, including the parametrization is specified by the feed
provider</t>
<t>This OpenSearch Description Document also contains an example
of a <Query> element. Each <Query> element
describes a specific search request that can be made by the
client. Note that the parameters of the <Query> element
correspond to the URL template parameters. In this way, a
provider may fully describe the search interface available to
the clients. The search section, above, provides specific
NORMATIVE requirements for the use of Open Search. </t>
</section>
</section>
<section title="XACML Guidance" anchor="xacml">
<t>ROLIE assumes that all authorization policy enforcement is
provided at the source server. The implementation details of the
authorization scheme chosen by a ROLIE-compliant provider are out
of scope for this specification. 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>It is
well known that one of the major barriers to information sharing
is ensuring acceptable use of the information shared. In the case
of ROLIE, one way to lower that barrier may be to develop a XACML
profile. Use of XACML would allow a ROLIE-compliant provider to
express their information sharing authorization policies in a
standards-compliant, and machine-readable format. </t>
<t>This improved interoperability may, in turn,
enable more agile interactions in the cyber security sharing
community. For example, a peer CSIRT, or another interested
stakeholder such as an auditor, would be able to review and
compare CSIRT sharing policies using appropriate tooling. </t>
<t>The XACML 3.0 standard is based upon the notion
that authorization policies are defined in terms of predicate
logic expressions written against the attributes associated with
one or more of the following four entities: <list style="symbols">
<t>SUBJECT</t>
<t>ACTION</t>
<t>RESOURCE</t>
<t>ENVIRONMENT</t>
</list>
Thus, a suitable approach to a XACML 3.0 profile for
ROLIE authorization policies could begin by using the 3-tuple of
[SUBJECT, ACTION, RESOURCE] where: <list style="symbols">
<t>SUBJECT is the suitably authenticated identity of the
requestor.</t>
<t>ACTION is the associated HTTP method, GET, PUT, POST, DELETE,
HEAD, (PATCH).</t>
<t>RESOURCE is an XPath expression that uniquely identifies the
instance or type of the ROLIE resource being requested.</t>
</list> Implementers who have a need may also choose to evaluate
based upon the additional ENVIRONMENT factors, such as current
threat level, and so on. One could also write policy to consider
the CVSS score associated with the resource, or the lifecycle
phase of the resource (vulnerability unverified, confirmed, patch
available, etc.), and so on. </t>
<t> Having these policies expressed in a standards-compliant and
machine-readable format could improve the agility and
effectiveness of a cyber security information sharing group or
consortium, and enable better cyber defenses. </t>
</section>
<section title="Relax NG Schema for ROLIE Extensions"
anchor="appendix-schema">
<t>TODO</t>
</section>
<section title="Change Tracking" anchor="appendix-delta">
<t>Changes 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:19:05 |