draft-ietf-mile-rolie-10.txt   draft-ietf-mile-rolie-11.txt 
MILE Working Group J. Field MILE Working Group J. Field
Internet-Draft Pivotal Internet-Draft Pivotal
Intended status: Standards Track S. Banghart Intended status: Standards Track S. Banghart
Expires: April 1, 2018 D. Waltermire Expires: April 22, 2018 D. Waltermire
NIST NIST
September 28, 2017 October 19, 2017
Resource-Oriented Lightweight Information Exchange Resource-Oriented Lightweight Information Exchange
draft-ietf-mile-rolie-10 draft-ietf-mile-rolie-11
Abstract Abstract
This document defines a resource-oriented approach for security This document defines a resource-oriented approach for security
automation information publication, discovery, and sharing. Using automation information publication, discovery, and sharing. Using
this approach, producers may publish, share, and exchange this approach, producers may publish, share, and exchange
representations of software descriptors, security incidents, attack representations of software descriptors, security incidents, attack
indicators, software vulnerabilities, configuration checklists, and indicators, software vulnerabilities, configuration checklists, and
other security automation information as web-addressable resources. other security automation information as web-addressable resources.
Furthermore, consumers and other stakeholders may access and search Furthermore, consumers and other stakeholders may access and search
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 1, 2018. This Internet-Draft will expire on April 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 4 3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 4
3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4 3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4
3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5 3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5
4. Background and Motivation . . . . . . . . . . . . . . . . . . 5 4. Background and Motivation . . . . . . . . . . . . . . . . . . 5
5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 6 5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 6
5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7 5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7
5.1.1. Use of the "app:workspace" Element . . . . . . . . . 7 5.1.1. Use of the "app:workspace" Element . . . . . . . . . 7
5.1.2. Use of the "app:collection" Element . . . . . . . . . 8 5.1.2. Use of the "app:collection" Element . . . . . . . . . 8
5.1.3. Service Discovery . . . . . . . . . . . . . . . . . . 9 5.1.3. Service Document Discovery . . . . . . . . . . . . . 9
5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 9 5.2. Category Documents . . . . . . . . . . . . . . . . . . . 9
5.3. Transport Layer Security . . . . . . . . . . . . . . . . 10 5.3. Transport Layer Security . . . . . . . . . . . . . . . . 9
5.4. User Authentication and Authorization . . . . . . . . . . 11 5.4. User Authentication and Authorization . . . . . . . . . . 10
5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 11 5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 10
5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 12 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 11
6. ROLIE Requirements for the Atom Syndication Format . . . . . 12 6. ROLIE Requirements for the Atom Syndication Format . . . . . 11
6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 12 6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 11
6.1.1. Use of the "atom:category" Element . . . . . . . . . 13 6.1.1. Use of the "atom:category" Element . . . . . . . . . 12
6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 14 6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 13
6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 15 6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 14
6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 15 6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 14
6.2.1. Use of the "atom:content" Element . . . . . . . . . . 16 6.2.1. Use of the "atom:content" Element . . . . . . . . . . 15
6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 17 6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 16
6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 17 6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 16
6.2.4. Use of the rolie:property Element . . . . . . . . . . 18 6.2.4. Use of the rolie:property Element . . . . . . . . . . 17
6.2.5. Requirements for a Standalone Entry . . . . . . . . . 19 6.2.5. Requirements for a Standalone Entry . . . . . . . . . 18
7. Available Extension Points Provided by ROLIE . . . . . . . . 20 7. Available Extension Points Provided by ROLIE . . . . . . . . 19
7.1. The Category Extension Point . . . . . . . . . . . . . . 20 7.1. The Category Extension Point . . . . . . . . . . . . . . 19
7.1.1. General Use of the "atom:category" Element . . . . . 21 7.1.1. General Use of the "atom:category" Element . . . . . 20
7.1.2. Identification of Security Automation Information 7.1.2. Identification of Security Automation Information
Types . . . . . . . . . . . . . . . . . . . . . . . . 21 Types . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. The "rolie:format" Extension Point . . . . . . . . . . . 22 7.2. The "rolie:format" Extension Point . . . . . . . . . . . 21
7.3. The Link Relation Extension Point . . . . . . . . . . . . 23 7.3. The Link Relation Extension Point . . . . . . . . . . . . 22
7.4. The "rolie:property" Extension Point . . . . . . . . . . 23 7.4. The "rolie:property" Extension Point . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 23
8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 24
8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 24
8.4. ROLIE Security Resource Information Type Sub-Registry . . 28 8.4. ROLIE Security Resource Information Type Sub-Registry . . 26
8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28 8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 33
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 36 Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 35
Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 37 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 36
B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 37 B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 36
B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 40 B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 39
B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 42 B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 41
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 43 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
This document defines a resource-oriented approach to security This document defines a resource-oriented approach to security
automation information sharing that follows the Representational automation information sharing that follows the Representational
State Transfer (REST) architectural style [REST]. In this approach, State Transfer (REST) architectural style [REST]. In this approach,
computer security resources are maintained in web-accessible computer security resources are maintained in web-accessible
repositories structured as Atom Syndication Format [RFC4287] Feeds. repositories structured as Atom Syndication Format [RFC4287] Feeds.
Within a given Feed, which may be requested by the consumer, Within a given Feed, which may be requested by the consumer,
representations of specific types of security automation information representations of specific types of security automation information
skipping to change at page 5, line 29 skipping to change at page 5, line 29
"http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom" "http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom"
namespaces appear in RFC5023 appendix B [RFC5023] and RFC4287 namespaces appear in RFC5023 appendix B [RFC5023] and RFC4287
appendix B [RFC4287] respectively. appendix B [RFC4287] respectively.
A complete informative RELAX NG Compact Schema for the new elements A complete informative RELAX NG Compact Schema for the new elements
introduced by ROLIE is provided in Appendix A. introduced by ROLIE is provided in Appendix A.
4. Background and Motivation 4. Background and Motivation
In order to automate security process, tools need access to In order to automate security process, tools need access to
sufficient sources of structured, security information that can be sufficient sources of structured security information that can be
used to drive security processes. Thus, security information sharing used to drive security processes. Thus, security information sharing
is one of the core components of automating security processes. is one of the core components of automating security processes.
Vulnerabilities, configurations, software identification, security Vulnerabilities, configurations, software identification, security
incidents, and patch data are just a few of the classes of incidents, and patch data are just a few of the classes of
information that are shared today to enable effective security on a information that are shared today to enable effective security on a
wide scale. However, as the scale of defense broadens as networks wide scale. However, as the scale of defense broadens as networks
become larger and more complex, and the volume of information to become larger and more complex, and the volume of information to
process makes humans-in-the-loop difficult to scale, the need for process makes humans-in-the-loop difficult to scale, the need for
automation and machine-to-machine communication becomes increasingly automation and machine-to-machine communication becomes increasingly
critical. critical.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
In AtomPub, a Workspace, represented by the "app:workspace" element, In AtomPub, a Workspace, represented by the "app:workspace" element,
describes a group of one or more Collections. Building on the describes a group of one or more Collections. Building on the
AtomPub concept of a Workspace, in ROLIE a Workspace represents an AtomPub concept of a Workspace, in ROLIE a Workspace represents an
aggregation of Collections pertaining to security automation aggregation of Collections pertaining to security automation
information resources. This specification does not restrict the information resources. This specification does not restrict the
number of Workspaces that may be in a Service Document or the number of Workspaces that may be in a Service Document or the
specific Collections to be provided within a given Workspace. specific Collections to be provided within a given Workspace.
A ROLIE implementation can host Collections containing both public A ROLIE implementation can host Collections containing both public
and private information entries. It is RECOMMENDED that and private information entries. It is suggested that
implementations segregate public and private Collections into implementations segregate Collections into different app:workspace
different app:workspace elements. By doing this, Workspaces that elements by their client access requirements. With proper naming of
contain private information can be ignored by clients or can be workspaces, this reduces the amount of trial and error a human user
omitted from the Service Document provided to a client that lacks the would need to utilize to discover accessible Collections.
appropriate privilege to access the set of Collections associated
with the Workspace.
5.1.2. Use of the "app:collection" Element 5.1.2. Use of the "app:collection" Element
In AtomPub, a Collection in a Service Document, represented by the In AtomPub, a Collection in a Service Document, represented by the
"app:collection" element, provides metadata that can be used to point "app:collection" element, provides metadata that can be used to point
to a specific Atom Feed that contains information Entries that may be to a specific Atom Feed that contains information Entries that may be
of interest to a client. The association between a Collection and a of interest to a client. The association between a Collection and a
Feed is provided by the "href" attribute of the app:collection Feed is provided by the "href" attribute of the app:collection
element. Building on the AtomPub concept of a Collection, in ROLIE a element. Building on the AtomPub concept of a Collection, in ROLIE a
Collection represents a pointer to a group of security automation Collection represents a pointer to a group of security automation
skipping to change at page 9, line 17 skipping to change at page 9, line 13
Atom Feed resource referenced by the app:collection "href" Atom Feed resource referenced by the app:collection "href"
attribute value. This ensures that the category metadata attribute value. This ensures that the category metadata
associated with the Collection and the associated Feed is associated with the Collection and the associated Feed is
discoverable in both of these resources. discoverable in both of these resources.
o The app:categories element in an app:collection MAY include o The app:categories element in an app:collection MAY include
additional atom:category elements using a scheme other than additional atom:category elements using a scheme other than
"urn:ietf:params:rolie:category:information-type". This allows "urn:ietf:params:rolie:category:information-type". This allows
other category metadata to be included. other category metadata to be included.
5.1.3. Service Discovery 5.1.3. Service Document Discovery
This specification requires that an implementation MUST publish an ..his specification requires that an implementation MUST publish an
Atom Service Document that describes the set of security information Atom Service Document that describes the set of security information
Collections provided by the service. The Service Document MUST be Collections provided by the service. The Service Document MUST be
retrievable using the standardized URI template retrievable using the standardized URI template
"https://{host:port}/.well-known/rolie/servicedocument", where "https://{host:port}/.well-known/rolie/servicedocument", where
{host:port} is the authority portion of the URI. Dereferencing this {host:port} is the authority portion of the URI. Dereferencing this
URI MAY result in a redirect based on an appropriate HTTP 3xx status URI MAY result in a redirect based on an appropriate HTTP 3xx status
code to direct the client to the actual Service Document. This code to direct the client to the actual Service Document. This
allows clients to have a well-known location to find a ROLIE service allows clients to have a well-known location to find a ROLIE service
document, while giving implementations flexibility over how the document, while giving implementations flexibility over how the
service is deployed. service is deployed.
This document registers the "rolie/servicedocument" well-known URI as This document registers the "rolie/servicedocument" well-known URI as
per [RFC5785] in Section 8.5. per [RFC5785] in Section 8.5.
A mechanism to determine which host and port to use is not specified A mechanism to determine which host and port to use is not specified
in this document. Use of a mechanism such as DNS SRV Records in this document. Use of a mechanism such as DNS SRV Records
[RFC2782] can provide a secure and reliable discovery mechanism for [RFC2782] can provide a secure and reliable discovery mechanism for
determining a specific host and port to use for retrieving a Service determining a specific host and port to use for retrieving a Service
Document for a given DNS domain. Document for a given DNS domain.
5.2. AtomPub Category Documents 5.2. Category Documents
As described in RFC5023 section 7 [RFC5023], a Category Document is As described in RFC5023 section 7 [RFC5023], a Category Document is
an XML-based document format that allows a client to dynamically an XML-based document format that allows a client to dynamically
discover the Categories used within AtomPub Service Documents, and discover the Categories used within AtomPub Service Documents, Atom
Atom Syndication Feed and Entry documents provided by a publisher. A Syndication Feeds, and Entry documents provided by a publisher. A
Category Document consists of one app:categories element that Category Document consists of one app:categories element that
contains a number of inline atom:category elements, or a URI contains a number of inline atom:category elements, or a URI
referencing a Category Document. referencing a Category Document.
A ROLIE implementation MUST publish a Category Document that
describes the set of atom:category elements and associated terms
currently used by the service.
The Category Document MUST be retrievable using the standardized URI
template "https://{host:port}/.well-known/rolie/categorydocument",
where {host:port} is the authority portion of the URI. Dereferencing
this URI MAY result in a redirect based on an appropriate HTTP 3xx
status code to direct the client to the actual Category Document.
This allows clients to have a well-known location to find a ROLIE
category document, while giving implementations flexibility over how
the service is deployed.
This document registers the "rolie/categorydocument" well-known URI
as per [RFC5785] in Section 8.5.
5.3. Transport Layer Security 5.3. Transport Layer Security
ROLIE is intended to be handled with TLS. The following requirements ROLIE is intended to be handled with TLS. TLS version 1.2 MUST be
have been in part derived from [RFC7589]. supported. TLS 1.2 SHOULD be implemented according to all
recommendations and best practices present in [RFC7525].
TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented
according to all recommendations and best practices present in
[RFC7525].
It is RECOMMENDED that the most recent published version of TLS is It is RECOMMENDED that the most recent published version of TLS is
supported. If this version is TLS 1.3 [I-D.ietf-tls-tls13], it is supported. If this version is TLS 1.3 [I-D.ietf-tls-tls13], it is
recommended that 0-RTT (Zero Round Trip Time Resumption) is not used, recommended that 0-RTT (Zero Round Trip Time Resumption) is not used,
as there is a replay attack that is possible with that option. as there is a replay attack that is possible with that option.
The server MUST support certificate-based client authentication. An The server MUST implement certificate-based client authentication.
implementation MUST support the set of TLS cipher suites that are This MAY be enabled on a workspace by workspace basis.
REQUIRED by the latest published version of the TLS specification.
An implementation MUST also support the TLS cipher suites that
provide support for mutual authentication of clients and servers.
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 [RFC4642]. 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. If the client has external information as to
the expected identity of the server, the hostname check MAY be
omitted.
Clients MUST verify the binding between the identity of the servers
to which they connect and the public keys presented by those servers.
Client implementations SHOULD support a certificate validation
approach based on section 6 of [RFC5280].
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.
5.4. User Authentication and Authorization 5.4. User Authentication and Authorization
Implementations MUST support user authentication. However, a given Implementations MUST support user authentication. However, a given
implementation MAY allow user authentication to be disabled on a feed implementation MAY allow user authentication to be disabled on a Feed
by feed basis. by Feed, or Workspace by Workspace basis.
Servers participating in an information sharing consortium and Servers participating in an information sharing consortium and
supporting interactive user logins by members of the consortium supporting interactive user logins by members of the consortium
SHOULD support client authentication via a federated identity scheme. SHOULD support client authentication via a federated identity scheme.
This document does not mandate the use of any specific user This document does not mandate the use of any specific user
authorization mechanisms. However, service implementers SHOULD authorization mechanisms. However, service implementers SHOULD
provide appropriate authorization checking for all resource accesses, support appropriate authorization checking for all resource accesses,
including individual Atom Entries, Atom Feeds, and Atom Service including individual Atom Entries, Atom Feeds, and Atom Service
Documents. Documents.
5.5. / (forward slash) Resource URL 5.5. / (forward slash) Resource URL
The "/" resource MAY be supported for compatibility with existing The "/" resource MAY be supported for compatibility with existing
deployments that are using Transport of Real-time Inter-network deployments that are using Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS [RFC6546]. Defense (RID) Messages over HTTP/TLS [RFC6546].
The following additional requirements apply for implementations The following additional requirements only apply if a implementation
supporting handling of the "/" resource:: is supporting the "/" resource as described above:
o Consistent with RFC6546 errata, a client requesting a GET on the o Consistent with RFC6546 errata, a client requesting a GET on the
"/" resource SHOULD receive an HTTP status code 405 Method Not "/" resource SHOULD receive an HTTP status code 405 Method Not
Allowed. Allowed.
o An implementation MAY provide full support for [RFC6546] such that o An implementation MAY provide full support for [RFC6546] such that
a POST to the "/" resource containing a recognized RID message is a POST to the "/" resource containing a recognized RID message is
handled correctly as a RID request. Alternatively, a client handled correctly as a RID request. Alternatively, a client
requesting a POST to "/" MAY receive an HTTP status code 307 requesting a POST to "/" MAY receive an HTTP status code 307
Temporary Redirect. In this case, the location header in the HTTP Temporary Redirect. In this case, the location header in the HTTP
response will provide the URL of the appropriate RID endpoint, and response will provide the URL of the appropriate RID endpoint, and
the client may repeat the POST method at the indicated location. the client may repeat the POST method at the indicated location.
If the "/" resource is unsupported, then a request for this resource If the "/" resource is unsupported, then a request for this resource
MUST provide a 404 HTTP status code. MAY be handled as deemed appropriate by the server.
5.6. HTTP methods 5.6. HTTP methods
Servers MAY accept request methods beyond those specified in this Servers MAY accept request methods beyond those specified in this
document. document.
Clients MUST be capable of recognizing and processing any standard Clients MUST be capable of recognizing and processing any standard
HTTP status code, as defined in [RFC5023] Section 5. HTTP status code, as defined in [RFC5023] Section 5.
6. ROLIE Requirements for the Atom Syndication Format 6. ROLIE Requirements for the Atom Syndication Format
skipping to change at page 13, line 45 skipping to change at page 12, line 45
& atomTitle & atomTitle
& atomUpdated & atomUpdated
& extensionElement*), & extensionElement*),
atomEntry* atomEntry*
} }
The following subsections contain requirements for a ROLIE Feed. The following subsections contain requirements for a ROLIE Feed.
6.1.1. Use of the "atom:category" Element 6.1.1. Use of the "atom:category" Element
An atom:feed can contain zero or more atom:category elements. In An atom:feed can contain one or more atom:category elements. In Atom
Atom the naming scheme and the semantic meaning of the terms used to the naming scheme and the semantic meaning of the terms used to
identify an Atom category are application-defined. identify an Atom category are application-defined.
The following are additional requirements on the use of the The following are additional requirements on the use of the
atom:category element when used in a ROLIE Feed: atom:category element when used in a ROLIE Feed:
o All member Entries in the Feed MUST represent security automation o All member Entries in the Feed MUST represent security automation
information records of the provided information type category. information records of the provided information type category.
o An atom:feed MAY include additional atom:category elements using a o An atom:feed MAY include additional atom:category elements using a
scheme other than "urn:ietf:params:rolie:category:information- scheme other than "urn:ietf:params:rolie:category:information-
skipping to change at page 15, line 38 skipping to change at page 14, line 38
An atom:feed MAY include additional link relationships not specified An atom:feed MAY include additional link relationships not specified
in this document. If a client encounters an unknown link in this document. If a client encounters an unknown link
relationship type, the client MUST ignore the unrecognized link and relationship type, the client MUST ignore the unrecognized link and
continue processing as if the unrecognized link element did not continue processing as if the unrecognized link element did not
appear. The definition of new Link relations that provide additional appear. The definition of new Link relations that provide additional
state transition extensions is discussed in section 7.3. state transition extensions is discussed in section 7.3.
6.1.3. Use of the "atom:updated" Element 6.1.3. Use of the "atom:updated" Element
The atom:updated element identifies the date and time that an Entry The atom:updated element identifies the date and time that a Feed was
was last updated. last updated.
The atom:updated element MUST be populated with the current time at The atom:updated element MUST be populated with the current time at
the instant the Feed representation was last updated by adding, the instant the Feed was last updated by adding, updating, or
updating, or deleting an Entry; or changing any metadata for the deleting an Entry; or changing any metadata for the Feed.
Feed.
6.2. Use of the "atom:entry" Element 6.2. Use of the "atom:entry" Element
Each Entry in an Atom Feed, represented by the atom:entry element, Each Entry in an Atom Feed, represented by the atom:entry element,
describes a single referenced information record, along with describes a single referenced information record, along with
descriptive information about its format, media type, and other descriptive information about its format, media type, and other
publication metadata. The following atom:entry schema definition publication metadata. The following atom:entry schema definition
represents a stricter representation of the atom:entry element represents a stricter representation of the atom:entry element
defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in
section 6.1.1. section 6.1.1.
skipping to change at page 16, line 27 skipping to change at page 15, line 27
& atomRights? & atomRights?
& atomSource? & atomSource?
& atomSummary? & atomSummary?
& atomTitle & atomTitle
& atomUpdated & atomUpdated
& rolieFormat & rolieFormat
& rolieProperty* & rolieProperty*
& extensionElement*) & extensionElement*)
} }
The notable changes from [RFC4287] are the addition of rolieFormat
and rolieProperty, and atomContent no longer being optional.
The following subsections contain requirements for Entries in a ROLIE The following subsections contain requirements for Entries in a ROLIE
Feed. Feed.
6.2.1. Use of the "atom:content" Element 6.2.1. Use of the "atom:content" Element
An atom:content element associates its containing Entry with a An atom:content element associates its containing Entry with a
content resource identified by the src attribute. content resource identified by the src attribute.
There MUST be exactly one atom:content element in the Entry. The There MUST be exactly one atom:content element in the Entry. The
content element MUST adhere to this definition, which is a stricter content element MUST adhere to this definition, which is a stricter
representation of the atom:content element defined in [RFC4287]: representation of the atom:content element defined in [RFC4287]:
atomContent = atomContent =
element atom:content { element atom:content {
atomCommonAttributes, atomCommonAttributes,
attribute type { atomMediaType }, attribute type { atomMediaType },
attribute src { atomUri }, attribute src { atomUri },
empty empty
} }
This restricts atomContent in ROLIE to the atomOutofLine forumulation
presented in[RFC4287].
The type attribute MUST identify the serialization type of the The type attribute MUST identify the serialization type of the
content, for example, application/xml or application/json. A content, for example, application/xml or application/json. A
prefixed media type MAY be used to reflect a specific model used with prefixed media type MAY be used to reflect a specific model used with
a given serialization approach (e.g., application/rdf+xml). The src a given serialization approach (e.g., application/rdf+xml). The src
attribute MUST be an IRI that can be dereferenced to retrieve the attribute MUST be an IRI that can be dereferenced to retrieve the
related content data. related content data.
6.2.2. Use of the "atom:link" Element 6.2.2. Use of the "atom:link" Element
Link relations can be included in an atom:entry to represent state Link relations can be included in an atom:entry to represent state
skipping to change at page 20, line 45 skipping to change at page 19, line 45
ROLIE further defines the use of the existing Atom extension category ROLIE further defines the use of the existing Atom extension category
mechanism by allowing ROLIE specific category extensions to be mechanism by allowing ROLIE specific category extensions to be
registered with IANA, and additionally has assigned the registered with IANA, and additionally has assigned the
"urn:ietf:params:rolie:category:information-type" category scheme "urn:ietf:params:rolie:category:information-type" category scheme
that has special meaning for implementations of ROLIE. This allows that has special meaning for implementations of ROLIE. This allows
category scheme namespaces to be managed in a more consistent way, category scheme namespaces to be managed in a more consistent way,
allowing for greater interoperability between content producers and allowing for greater interoperability between content producers and
consumers. consumers.
The namespace "urn:ietf:params:rolie:category:local" has been Any category whose "scheme" attribute uses an unregistered scheme
reserved in the IANA ROLIE Parameters table for private use as MUST be considered private use. Implementations encountering such a
defined in [RFC8126]. Any category whose "scheme" attribute uses category MUST parse the content without error, but MAY otherwise
this as a prefix MUST be considered private use. Implementations ignore the element.
encountering such a category MUST parse the content without error,
but MAY otherwise ignore the element.
Use of the "atom:category" element is discussed in the following Use of the "atom:category" element is discussed in the following
subsections. subsections.
7.1.1. General Use of the "atom:category" Element 7.1.1. General Use of the "atom:category" Element
The atom:category element can be used for characterizing a ROLIE The atom:category element can be used for characterizing a ROLIE
Resource. As discussed earlier in this document, an atom:category Resource. As discussed earlier in this document, an atom:category
element has a "term" attribute that indicates the assigned category element has a "term" attribute that indicates the assigned category
value, and a "scheme" attribute that provides an identifier for the value, and a "scheme" attribute that provides an identifier for the
skipping to change at page 22, line 11 skipping to change at page 21, line 7
For example, the notional security automation information type For example, the notional security automation information type
"incident" would be identified as follows: "incident" would be identified as follows:
<atom:category <atom:category
scheme="urn:ietf:params:rolie:category:information-type" scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/> term="incident"/>
A security automation information type represents a class of A security automation information type represents a class of
information that represents the same or similar information model information that represents the same or similar information model
[RFC3444]. Notional examples of information types include: [RFC3444]. Note that this document does not register any information
types, but offers the following as examples of potential information
types:
indicator: Computing device- or network-related "observable features indicator: Computing device- or network-related "observable features
and phenomenon that aid in the forensic or proactive detection of and phenomenon that aid in the forensic or proactive detection of
malicious activity; and associated meta-data" (from [RFC7970]). malicious activity; and associated meta-data" (from [RFC7970]).
incident: Information pertaining to and "derived analysis from incident: Information pertaining to and "derived analysis from
security incidents" (from [RFC7970]). security incidents" (from [RFC7970]).
vulnerability reports: Information identifying and describing a vulnerability reports: Information identifying and describing a
vulnerability in hardware or software. vulnerability in hardware or software.
skipping to change at page 24, line 5 skipping to change at page 22, line 50
encountering such a property MUST parse the content without error, encountering such a property MUST parse the content without error,
but MAY otherwise ignore the element. but MAY otherwise ignore the element.
This document also registers a number of general use properties that This document also registers a number of general use properties that
can be used to expose content information in any ROLIE use case. The can be used to expose content information in any ROLIE use case. The
following are descriptions of how to use these registered properties: following are descriptions of how to use these registered properties:
urn:ietf:params:rolie:property:content-author-name The "value" urn:ietf:params:rolie:property:content-author-name The "value"
attribute of this property is a text representation indicating the attribute of this property is a text representation indicating the
individual or organization that authored the content referenced by individual or organization that authored the content referenced by
the "src" attribute of the entry's atom:content element. the "src" attribute of the entry's atom:content element. This
author may differ from the atom:author when the author of the
content and the entry are different people or entities.
urn:ietf:params:rolie:property:content-id The "value" attribute of urn:ietf:params:rolie:property:content-id The "value" attribute of
this property is a text representation of an identifier pertaining this property is a text representation of an identifier pertaining
to or extracted from the content referenced by the "src" attribute to or extracted from the content referenced by the "src" attribute
of the entry's atom:content element. of the entry's atom:content element.
urn:ietf:params:rolie:property:content-published-date The "value" urn:ietf:params:rolie:property:content-published-date The "value"
attribute of this property is a text representation indicating the attribute of this property is a text representation indicating the
original publication date of the content referenced by the "src" original publication date of the content referenced by the "src"
attribute of the entry's atom:content element. This date may attribute of the entry's atom:content element. This date may
skipping to change at page 27, line 22 skipping to change at page 26, line 22
| | | Secti | following location: htt | | | | Secti | following location: htt |
| | | on | ps://www.iana.org/assig | | | | on | ps://www.iana.org/assig |
| | | 8.4 | nments/rolie/category | | | | 8.4 | nments/rolie/category |
| | | | /information-type] | | | | | /information-type] |
| property:l | urn:ietf:params:ro | This | None | | property:l | urn:ietf:params:ro | This | None |
| ocal | lie:property:local | docum | | | ocal | lie:property:local | docum | |
| | | ent, | | | | | ent, | |
| | | Secti | | | | | Secti | |
| | | on | | | | | on | |
| | | 7.4 | | | | | 7.4 | |
| category:l | urn:ietf:params:ro | This | None |
| ocal | lie:category:local | docum | |
| | | ent, | |
| | | Secti | |
| | | on | |
| | | 7.1 | |
| property | urn:ietf:params:ro | This | None | | property | urn:ietf:params:ro | This | None |
| :content- | lie:property | docum | | | :content- | lie:property | docum | |
| author- | :content-author- | ent, | | | author- | :content-author- | ent, | |
| name | name | Secti | | | name | name | Secti | |
| | | on | | | | | on | |
| | | 7.4 | | | | | 7.4 | |
| property | urn:ietf:params:ro | This | None | | property | urn:ietf:params:ro | This | None |
| :content- | lie:property | docum | | | :content- | lie:property | docum | |
| id | :content-id | ent, | | | id | :content-id | ent, | |
| | | Secti | | | | | Secti | |
skipping to change at page 28, line 19 skipping to change at page 27, line 14
Name of Registry: "ROLIE Information Types" Name of Registry: "ROLIE Information Types"
Location of Registry: Location of Registry:
https://www.iana.org/assignments/rolie/category/information-type https://www.iana.org/assignments/rolie/category/information-type
Fields to record in the registry: Fields to record in the registry:
name: The full name of the security resource information type name: The full name of the security resource information type
as a string from the printable ASCII character set [RFC0020] as a string from the printable ASCII character set [RFC0020]
with individual embedded spaces allowed. The ABNF [RFC5234] with individual embedded spaces allowed. This value must be
syntax for this field is: unique in the context of this table. The ABNF [RFC5234] syntax
for this field is:
1*VCHAR *(SP 1*VCHAR) 1*VCHAR *(SP 1*VCHAR)
index: This is an IANA-assigned positive integer that index: This is an IANA-assigned positive integer that
identifies the registration. The first entry added to this identifies the registration. The first entry added to this
registry uses the value 1, and this value is incremented for registry uses the value 1, and this value is incremented for
each subsequent entry added to the registry. each subsequent entry added to the registry.
reference: A list of one or more URIs [RFC3986] from which the reference: A list of one or more URIs [RFC3986] from which the
registered specification can be obtained. The registered registered specification can be obtained. The registered
skipping to change at page 28, line 52 skipping to change at page 27, line 48
Service Document registration: Service Document registration:
URI suffix: rolie/servicedocument URI suffix: rolie/servicedocument
Change controller: IETF Change controller: IETF
Specification document: This document, Section 5.1.3 Specification document: This document, Section 5.1.3
Related information: None Related information: None
Category Document registration:
URI suffix: rolie/categorydocument
Change controller: IETF
Specification document: This document, Section 5.2
Related information: None
9. Security Considerations 9. Security Considerations
This document defines a resource-oriented approach for lightweight This document defines a resource-oriented approach for lightweight
information exchange using HTTP over TLS, the Atom Syndication information exchange using HTTP over TLS, the Atom Syndication
Format, and the Atom Publishing Protocol. As such, implementers must Format, and the Atom Publishing Protocol. As such, implementers must
understand the security considerations described in those understand the security considerations described in those
specifications. All that follows is guidance, more specific specifications. All that follows is guidance, more specific
instruction is out of scope for this document. instruction is out of scope for this document.
To protect the confidentiality of a given resource provided by a To protect the confidentiality of a given resource provided by a
ROLIE implementation, requests for retrieval of the resource need to ROLIE implementation, requests for retrieval of the resource need to
be authenticated to prevent unauthorized users from accessing the be authenticated to prevent unauthorized users from accessing the
resource (see section 5.4). It can also be useful to log and audit resource (see section 5.4). It can also be useful to log and audit
access to sensitive resources to verify that proper access controls access to sensitive resources to verify that proper access controls
remain in place over time. remain in place over time.
The approach described herein is based upon all policy enforcements Access control to information published using ROLIE should use
being implemented at the point when a resource representation is mechanisms that are appropriate to the sensitivity of the
created. As such, producers sharing cyber security information using information. Primitive authentication mechanisms like HTTP Basic
this specification must take care to authenticate their HTTP clients Authentication [RFC7617] are rarely appropriate for sensitive
using a suitably strong user authentication mechanism. Sharing information. A number of authentication schemes are defined in the
communities that are exchanging information on well-known indicators HTTP Authentication Schemes Registry [3]. Of these, HOBA [RFC7486]
and incidents for purposes of public education may choose to rely and SCRAM-SHA-256 [RFC7804] provide improved security properties over
upon HTTP Authentication or similar. A number of authentication HTTP Basic [RFC7617]and Digest [RFC7616] Authentication Schemes.
schemes are defined in the HTTP Authentication Schemes Registry [3]. However, sharing communities that are engaged in sensitive
Of these, HOBA [RFC7486] and SCRAM-SHA-256 [RFC7804] provide improved collaborative analysis and/or operational response for indicators and
security properties over HTTP Basic [RFC7617]and Digest [RFC7616] incidents targeting high value information systems should adopt a
Authentication Schemes. However, sharing communities that are suitably stronger user authentication solution, such as a risk-based
engaged in sensitive collaborative analysis and/or operational or multi-factor approach.
response for indicators and incidents targeting high value
information systems should adopt a suitably stronger user
authentication solution, such as a risk-based or multi-factor
approach. In general, trust in the sharing consortium will depend
upon the members maintaining adequate user authentication mechanisms.
Collaborating consortiums may benefit from the adoption of a Collaborating consortiums may benefit from the adoption of a
federated identity solution, such as those based upon OAuth [RFC6749] federated identity solution, such as those based upon OAuth [RFC6749]
with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind], with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind],
and SAML-prof [SAML-prof] for Web-based authentication and cross- and SAML-prof [SAML-prof] for Web-based authentication and cross-
organizational single sign-on. Dependency on a trusted third party organizational single sign-on. Dependency on a trusted third party
identity provider implies that appropriate care must be exercised to identity provider implies that appropriate care must be exercised to
sufficiently secure the Identity provider. Any attacks on the sufficiently secure the Identity provider. Any attacks on the
federated identity system would present a risk to the consortium, as federated identity system would present a risk to the consortium, as
a relying party. Potential mitigations include deployment of a a relying party. Potential mitigations include deployment of a
skipping to change at page 30, line 33 skipping to change at page 29, line 15
policy enforcement requirements relevant to their consortium and/or policy enforcement requirements relevant to their consortium and/or
organization. organization.
Additional security requirements such as enforcing message-level Additional security requirements such as enforcing message-level
security at the destination system could supplement the security security at the destination system could supplement the security
enforcements performed at the source system, however these enforcements performed at the source system, however these
destination-provided policy enforcements are out of scope for this destination-provided policy enforcements are out of scope for this
specification. Implementers requiring this capability should specification. Implementers requiring this capability should
consider leveraging, e.g. the <RIDPolicy> element in the RID schema. consider leveraging, e.g. the <RIDPolicy> element in the RID schema.
Refer to RFC6545 section 9 for more information. Additionally, the Refer to RFC6545 section 9 for more information. Additionally, the
underlying serialization approach used in the message (e.g., XML, underlying serialization approach used in the representation (e.g.,
JSON) can offer encryption and message authentication capabilities. XML, JSON) can offer encryption and message authentication
For example, XMLDSig [RFC3275] for XML, and JSON Web Encryption capabilities. For example, XMLDSig [RFC3275] for XML, and JSON Web
[RFC7516] and JSON Web Signature[RFC7515] for JSON can provide such Encryption [RFC7516] and JSON Web Signature[RFC7515] for JSON can
mechanisms. provide such mechanisms.
When security policies relevant to the source system are to be When security policies relevant to the source system are to be
enforced at both the source and destination systems, implementers enforced at both the source and destination systems, implementers
must take care to avoid unintended interactions of the separately must take care to avoid unintended interactions of the separately
enforced policies. Potential risks will include unintended denial of enforced policies. Potential risks will include unintended denial of
service and/or unintended information leakage. These problems may be service and/or unintended information leakage. These problems may be
mitigated by avoiding any dependence upon enforcements performed at mitigated by avoiding any dependence upon enforcements performed at
the destination system. When distributed enforcement is unavoidable, the destination system. When distributed enforcement is unavoidable,
the usage of a standard language (e.g. XACML) for the expression of the usage of a standard language (e.g. XACML) for the expression of
authorization policies will enable the source and destination systems authorization policies will enable the source and destination systems
to better coordinate and align their respective policy expressions. to better coordinate and align their respective policy expressions.
A service discovery mechanism is not explicitly specified in this A service discovery mechanism is not explicitly specified in this
document, and there are several approaches available for document, and there are several approaches available for
implementers. When selecting this mechanism, implementations need to implementers. When selecting this mechanism, implementations need to
ensure that their choice provides a means for authenticating the ensure that their choice provides a means for authenticating the
server. As described in the discovery section, DNS SRV Records are a server. As described in the discovery section, DNS SRV Records are a
possible secure solution to discovery. possible solution to discovery.
10. Privacy Considerations 10. Privacy Considerations
The optional author field may provide an identification privacy issue The optional author field may provide an identification privacy issue
if populated without the author's consent. This information may if populated without the author's consent. This information may
become public if posted to a public feed. Special care should be become public if posted to a public feed. Special care should be
taken when aggregating or sharing entries from other feeds, or when taken when aggregating or sharing entries from other feeds, or when
programmatically generating ROLIE entries from some data source that programmatically generating ROLIE entries from some data source that
the author's personal info is not shared without their consent. the author's personal info is not shared without their consent.
When using the Atom Publishing Protocol to POST entries to a feed, When using the Atom Publishing Protocol to POST entries to a feed,
attackers may use correlating techniques to profile the user. The attackers may use correlating techniques to profile the user. The
request time can be compared to the generated "updated" field of the request time can be compared to the generated "updated" field of the
entry in order to build out information about a given user. This entry in order to build out information about a given user. This
correlation attempt can be mitigated by not using HTTP requests to correlation attempt can be mitigated by not using HTTP requests to
POST entries when profiling is a risk, and rather use backend control POST entries when profiling is a risk, and rather use backend control
of the feeds. of the Feeds.
Adoption of the information sharing approach described in this Adoption of the information sharing approach described in this
document will enable users to more easily perform correlations across document will enable users to more easily perform correlations across
separate, and potentially unrelated, cyber security information separate, and potentially unrelated, cyber security information
providers. A client may succeed in assembling a data set that would providers. A client may succeed in assembling a data set that would
not have been permitted within the context of the authorization not have been permitted within the context of the authorization
policies of either provider when considered individually. Thus, policies of either provider when considered individually. Thus,
providers may face a risk of an attacker obtaining an access that providers may face a risk of an attacker obtaining an access that
constitutes an undetected separation of duties (SOD) violation. It constitutes an undetected separation of duties (SOD) violation. It
is important to note that this risk is not unique to this is important to note that this risk is not unique to this
specification, and a similar potential for abuse exists with any specification, and a similar potential for abuse exists with any
other cyber security information sharing protocol. However, the wide other cyber security information sharing protocol. However, the wide
availability of tools for HTTP clients and Atom Feed handling implies availability of tools for HTTP clients and Atom Feed handling implies
that the resources and technical skills required for a successful that the resources and technical skills required for a successful
exploit may be less than it was previously. This risk can be best exploit may be less than it was previously. This risk can be best
mitigated through appropriate vetting of the client at account mitigated through appropriate vetting of the client at account
provisioning time. In addition, any increase in the risk of this provisioning time. In addition, any increase in the risk of this
type of abuse should be offset by the corresponding increase in type of abuse should be offset by the corresponding increase in
effectiveness that this specification affords to the defenders. effectiveness that this specification affords to the defenders.
Proper usage of TLS as described in Section 5.3 will in many cases
aid in the mitigation of these issues.
Overall, ROLIE introduces few privacy concerns above and beyond those Overall, ROLIE introduces few privacy concerns above and beyond those
present in any other HTTP protocol. Those that exist can be present in any other HTTP protocol. Those that exist can be
mitigated by following security considerations and carefully using mitigated by following security considerations and carefully using
the optional identifying elements. the optional identifying elements.
11. Acknowledgements 11. Acknowledgements
The authors gratefully acknowledge the valuable contributions of Tom The authors gratefully acknowledge the valuable contributions of Tom
Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These
individuals provided detailed review comments on earlier drafts, and individuals provided detailed review comments on earlier drafts, and
skipping to change at page 43, line 7 skipping to change at page 42, line 7
src="http://www.example.org/provider/vulns/123456/data"> src="http://www.example.org/provider/vulns/123456/data">
</content> </content>
</entry> </entry>
The example response above shows an XML document referenced by the The example response above shows an XML document referenced by the
"src" attribute of the atom:content element. The client may retrieve "src" attribute of the atom:content element. The client may retrieve
the document using this URL. the document using this URL.
Appendix C. Change History Appendix C. Change History
Changes in draft-ietf-mile-rolie-11 since draft-ietf-mile-rolie-09
revision:
Incorporated ART last call review and AD review changes
Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08 Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08
revision: revision:
TLS requirements changed to clarify TLS versioning and TLS requirements changed to clarify TLS versioning and
recommendations recommendations
Informative references and textual discussion added to Security Informative references and textual discussion added to Security
Considerations around HTTP Authentication and content Signing/ Considerations around HTTP Authentication and content Signing/
Encryption. Encryption.
 End of changes. 36 change blocks. 
179 lines changed or deleted 120 lines changed or added

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