--- 1/draft-ietf-mile-rolie-10.txt 2017-10-20 09:13:19.255343831 -0700
+++ 2/draft-ietf-mile-rolie-11.txt 2017-10-20 09:13:19.343345911 -0700
@@ -1,20 +1,20 @@
MILE Working Group J. Field
Internet-Draft Pivotal
Intended status: Standards Track S. Banghart
-Expires: April 1, 2018 D. Waltermire
+Expires: April 22, 2018 D. Waltermire
NIST
- September 28, 2017
+ October 19, 2017
Resource-Oriented Lightweight Information Exchange
- draft-ietf-mile-rolie-10
+ draft-ietf-mile-rolie-11
Abstract
This document defines a resource-oriented approach for security
automation information publication, discovery, and sharing. Using
this approach, producers may publish, share, and exchange
representations of software descriptors, 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
@@ -39,21 +39,21 @@
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on April 1, 2018.
+ This Internet-Draft will expire on April 22, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
@@ -68,65 +68,65 @@
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 4
3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4
3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5
4. Background and Motivation . . . . . . . . . . . . . . . . . . 5
5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 6
5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7
5.1.1. Use of the "app:workspace" Element . . . . . . . . . 7
5.1.2. Use of the "app:collection" Element . . . . . . . . . 8
- 5.1.3. Service Discovery . . . . . . . . . . . . . . . . . . 9
- 5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 9
- 5.3. Transport Layer Security . . . . . . . . . . . . . . . . 10
- 5.4. User Authentication and Authorization . . . . . . . . . . 11
- 5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 11
- 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 12
- 6. ROLIE Requirements for the Atom Syndication Format . . . . . 12
- 6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 12
- 6.1.1. Use of the "atom:category" Element . . . . . . . . . 13
- 6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 14
- 6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 15
- 6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 15
- 6.2.1. Use of the "atom:content" Element . . . . . . . . . . 16
- 6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 17
- 6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 17
- 6.2.4. Use of the rolie:property Element . . . . . . . . . . 18
- 6.2.5. Requirements for a Standalone Entry . . . . . . . . . 19
- 7. Available Extension Points Provided by ROLIE . . . . . . . . 20
- 7.1. The Category Extension Point . . . . . . . . . . . . . . 20
- 7.1.1. General Use of the "atom:category" Element . . . . . 21
+ 5.1.3. Service Document Discovery . . . . . . . . . . . . . 9
+ 5.2. Category Documents . . . . . . . . . . . . . . . . . . . 9
+ 5.3. Transport Layer Security . . . . . . . . . . . . . . . . 9
+ 5.4. User Authentication and Authorization . . . . . . . . . . 10
+ 5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 10
+ 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 11
+ 6. ROLIE Requirements for the Atom Syndication Format . . . . . 11
+ 6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 11
+ 6.1.1. Use of the "atom:category" Element . . . . . . . . . 12
+ 6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 13
+ 6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 14
+ 6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 14
+ 6.2.1. Use of the "atom:content" Element . . . . . . . . . . 15
+ 6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 16
+ 6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 16
+ 6.2.4. Use of the rolie:property Element . . . . . . . . . . 17
+ 6.2.5. Requirements for a Standalone Entry . . . . . . . . . 18
+ 7. Available Extension Points Provided by ROLIE . . . . . . . . 19
+ 7.1. The Category Extension Point . . . . . . . . . . . . . . 19
+ 7.1.1. General Use of the "atom:category" Element . . . . . 20
7.1.2. Identification of Security Automation Information
- Types . . . . . . . . . . . . . . . . . . . . . . . . 21
- 7.2. The "rolie:format" Extension Point . . . . . . . . . . . 22
- 7.3. The Link Relation Extension Point . . . . . . . . . . . . 23
- 7.4. The "rolie:property" Extension Point . . . . . . . . . . 23
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
- 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24
- 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25
- 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25
- 8.4. ROLIE Security Resource Information Type Sub-Registry . . 28
- 8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
- 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
- 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
- 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
- 12.2. Informative References . . . . . . . . . . . . . . . . . 34
- 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
- Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 36
- Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 37
- B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 37
- B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 40
- B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 42
- Appendix C. Change History . . . . . . . . . . . . . . . . . . . 43
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
+ Types . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7.2. The "rolie:format" Extension Point . . . . . . . . . . . 21
+ 7.3. The Link Relation Extension Point . . . . . . . . . . . . 22
+ 7.4. The "rolie:property" Extension Point . . . . . . . . . . 22
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
+ 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 23
+ 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 24
+ 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 24
+ 8.4. ROLIE Security Resource Information Type Sub-Registry . . 26
+ 8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 27
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
+ 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 33
+ 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
+ Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 35
+ Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 36
+ B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 36
+ B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 39
+ B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 41
+ Appendix C. Change History . . . . . . . . . . . . . . . . . . . 42
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
This document defines a resource-oriented approach to security
automation information sharing that follows the Representational
State Transfer (REST) architectural style [REST]. In this approach,
computer security resources are maintained in web-accessible
repositories structured as Atom Syndication Format [RFC4287] Feeds.
Within a given Feed, which may be requested by the consumer,
representations of specific types of security automation information
@@ -208,21 +208,21 @@
"http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom"
namespaces appear in RFC5023 appendix B [RFC5023] and RFC4287
appendix B [RFC4287] respectively.
A complete informative RELAX NG Compact Schema for the new elements
introduced by ROLIE is provided in Appendix A.
4. Background and Motivation
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
is one of the core components of automating security processes.
Vulnerabilities, configurations, software identification, security
incidents, and patch data are just a few of the classes of
information that are shared today to enable effective security on a
wide scale. However, as the scale of defense broadens as networks
become larger and more complex, and the volume of information to
process makes humans-in-the-loop difficult to scale, the need for
automation and machine-to-machine communication becomes increasingly
critical.
@@ -326,27 +326,25 @@
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 restrict the
number of Workspaces that may be in a Service Document or the
specific Collections to be provided within a given Workspace.
A ROLIE implementation can host Collections containing both public
- and private information entries. It is RECOMMENDED that
- implementations segregate public and private Collections into
- different app:workspace elements. By doing this, Workspaces that
- contain private information can be ignored by clients or can be
- omitted from the Service Document provided to a client that lacks the
- appropriate privilege to access the set of Collections associated
- with the Workspace.
+ and private information entries. It is suggested that
+ implementations segregate Collections into different app:workspace
+ elements by their client access requirements. With proper naming of
+ workspaces, this reduces the amount of trial and error a human user
+ would need to utilize to discover accessible Collections.
5.1.2. Use of the "app:collection" Element
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
@@ -387,152 +385,106 @@
Atom Feed resource referenced by the app:collection "href"
attribute value. This ensures that the category metadata
associated with the Collection and the associated Feed is
discoverable in both of these resources.
o The app:categories element in an app:collection MAY include
additional atom:category elements using a scheme other than
"urn:ietf:params:rolie:category:information-type". This allows
other category metadata to be included.
-5.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
Collections provided by the service. The Service Document MUST be
retrievable using the standardized URI template
"https://{host:port}/.well-known/rolie/servicedocument", 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 Service Document. This
allows clients to have a well-known location to find a ROLIE service
document, while giving implementations flexibility over how the
service is deployed.
This document registers the "rolie/servicedocument" well-known URI as
per [RFC5785] in Section 8.5.
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
[RFC2782] can provide a secure and reliable discovery mechanism for
determining a specific host and port to use for retrieving a Service
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
an XML-based document format that allows a client to dynamically
- discover the Categories used within AtomPub Service Documents, and
- Atom Syndication Feed and Entry documents provided by a publisher. A
+ discover the Categories used within AtomPub Service Documents, Atom
+ Syndication Feeds, and Entry documents provided by a publisher. A
Category Document consists of one app:categories element that
contains a number of inline atom:category elements, or a URI
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
- ROLIE is intended to be handled with TLS. The following requirements
- have been in part derived from [RFC7589].
-
- TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented
- according to all recommendations and best practices present in
- [RFC7525].
+ ROLIE is intended to be handled with TLS. 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
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,
as there is a replay attack that is possible with that option.
- The server MUST support certificate-based client authentication. An
- implementation MUST support the set of TLS cipher suites that are
- 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.
+ The server MUST implement certificate-based client authentication.
+ This MAY be enabled on a workspace by workspace basis.
5.4. User Authentication and Authorization
Implementations MUST support user authentication. However, a given
- implementation MAY allow user authentication to be disabled on a feed
- by feed basis.
+ implementation MAY allow user authentication to be disabled on a Feed
+ by Feed, or Workspace by Workspace basis.
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.
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,
+ support appropriate authorization checking for all resource accesses,
including individual Atom Entries, Atom Feeds, and Atom Service
Documents.
5.5. / (forward slash) Resource URL
The "/" resource MAY be supported for compatibility with existing
deployments that are using Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS [RFC6546].
- The following additional requirements apply for implementations
- supporting handling of the "/" resource::
+ The following additional requirements only apply if a implementation
+ is supporting the "/" resource as described above:
o Consistent with RFC6546 errata, a client requesting a GET on the
"/" resource SHOULD receive an HTTP status code 405 Method Not
Allowed.
o An implementation MAY provide full support for [RFC6546] such that
a POST to the "/" resource containing a recognized RID message is
handled correctly as a RID request. Alternatively, a client
requesting a POST to "/" MAY receive an HTTP status code 307
Temporary Redirect. In this case, the location header in the HTTP
response will provide the URL of the appropriate RID endpoint, and
the client may repeat the POST method at the indicated location.
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
Servers MAY accept request methods beyond those specified in this
document.
Clients MUST be capable of recognizing and processing any standard
HTTP status code, as defined in [RFC5023] Section 5.
6. ROLIE Requirements for the Atom Syndication Format
@@ -607,22 +559,22 @@
& atomTitle
& atomUpdated
& extensionElement*),
atomEntry*
}
The following subsections contain requirements for a ROLIE Feed.
6.1.1. Use of the "atom:category" Element
- An atom:feed can contain zero or more atom:category elements. In
- Atom the naming scheme and the semantic meaning of the terms used to
+ An atom:feed can contain one or more atom:category elements. In Atom
+ the naming scheme and the semantic meaning of the terms used to
identify an Atom category are application-defined.
The following are additional requirements on the use of the
atom:category element when used in a ROLIE Feed:
o All member Entries in the Feed MUST represent security automation
information records of the provided information type category.
o An atom:feed MAY include additional atom:category elements using a
scheme other than "urn:ietf:params:rolie:category:information-
@@ -695,27 +647,26 @@
An atom:feed MAY include additional link relationships not specified
in this document. If a client encounters an unknown link
relationship type, the client MUST ignore the unrecognized link and
continue processing as if the unrecognized link element did not
appear. The definition of new Link relations that provide additional
state transition extensions is discussed in section 7.3.
6.1.3. Use of the "atom:updated" Element
- The atom:updated element identifies the date and time that an Entry
- was last updated.
+ The atom:updated element identifies the date and time that a Feed was
+ last updated.
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.
+ the instant the Feed was last updated by adding, updating, or
+ deleting an Entry; or changing any metadata for the Feed.
6.2. Use of the "atom:entry" Element
Each Entry in an Atom Feed, represented by the atom:entry element,
describes a single referenced information record, along with
descriptive information about its format, media type, and other
publication metadata. The following atom:entry schema definition
represents a stricter representation of the atom:entry element
defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in
section 6.1.1.
@@ -733,40 +684,46 @@
& atomRights?
& atomSource?
& atomSummary?
& atomTitle
& atomUpdated
& rolieFormat
& rolieProperty*
& 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
Feed.
6.2.1. Use of the "atom:content" Element
An atom:content element associates its containing Entry with a
content resource identified by the src attribute.
There MUST be exactly one atom:content element in the Entry. The
content element MUST adhere to this definition, which is a stricter
representation of the atom:content element defined in [RFC4287]:
atomContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType },
attribute src { atomUri },
empty
}
+ This restricts atomContent in ROLIE to the atomOutofLine forumulation
+ presented in[RFC4287].
+
The type attribute MUST identify the serialization type of the
content, for example, application/xml or application/json. A
prefixed media type MAY be used to reflect a specific model used with
a given serialization approach (e.g., application/rdf+xml). The src
attribute MUST be an IRI that can be dereferenced to retrieve the
related content data.
6.2.2. Use of the "atom:link" Element
Link relations can be included in an atom:entry to represent state
@@ -936,26 +893,24 @@
ROLIE further defines the use of the existing Atom extension category
mechanism by allowing ROLIE specific category extensions to be
registered with IANA, and additionally has assigned the
"urn:ietf:params:rolie:category:information-type" category scheme
that has special meaning for implementations of ROLIE. This allows
category scheme namespaces to be managed in a more consistent way,
allowing for greater interoperability between content producers and
consumers.
- The namespace "urn:ietf:params:rolie:category:local" has been
- reserved in the IANA ROLIE Parameters table for private use as
- defined in [RFC8126]. Any category whose "scheme" attribute uses
- this as a prefix MUST be considered private use. Implementations
- encountering such a category MUST parse the content without error,
- but MAY otherwise ignore the element.
+ Any category whose "scheme" attribute uses an unregistered scheme
+ MUST be considered private use. Implementations 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
subsections.
7.1.1. General Use of the "atom:category" Element
The atom:category element can be used for characterizing a ROLIE
Resource. As discussed earlier in this document, an atom:category
element has a "term" attribute that indicates the assigned category
value, and a "scheme" attribute that provides an identifier for the
@@ -996,21 +951,23 @@
For example, the notional security automation information type
"incident" would be identified as follows:
A security automation information type represents a class of
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
and phenomenon that aid in the forensic or proactive detection of
malicious activity; and associated meta-data" (from [RFC7970]).
incident: Information pertaining to and "derived analysis from
security incidents" (from [RFC7970]).
vulnerability reports: Information identifying and describing a
vulnerability in hardware or software.
@@ -1085,21 +1042,23 @@
encountering such a property MUST parse the content without error,
but MAY otherwise ignore the element.
This document also registers a number of general use properties that
can be used to expose content information in any ROLIE use case. The
following are descriptions of how to use these registered properties:
urn:ietf:params:rolie:property:content-author-name The "value"
attribute of this property is a text representation indicating the
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
this property is a text representation of an identifier pertaining
to or extracted from the content referenced by the "src" attribute
of the entry's atom:content element.
urn:ietf:params:rolie:property:content-published-date The "value"
attribute of this property is a text representation indicating the
original publication date of the content referenced by the "src"
attribute of the entry's atom:content element. This date may
@@ -1215,26 +1175,20 @@
| | | Secti | following location: htt |
| | | on | ps://www.iana.org/assig |
| | | 8.4 | nments/rolie/category |
| | | | /information-type] |
| property:l | urn:ietf:params:ro | This | None |
| ocal | lie:property:local | docum | |
| | | ent, | |
| | | Secti | |
| | | on | |
| | | 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 |
| :content- | lie:property | docum | |
| author- | :content-author- | ent, | |
| name | name | Secti | |
| | | on | |
| | | 7.4 | |
| property | urn:ietf:params:ro | This | None |
| :content- | lie:property | docum | |
| id | :content-id | ent, | |
| | | Secti | |
@@ -1261,22 +1215,23 @@
Name of Registry: "ROLIE Information Types"
Location of Registry:
https://www.iana.org/assignments/rolie/category/information-type
Fields to record in the registry:
name: The full name of the security resource information type
as a string from the printable ASCII character set [RFC0020]
- with individual embedded spaces allowed. The ABNF [RFC5234]
- syntax for this field is:
+ with individual embedded spaces allowed. This value must be
+ unique in the context of this table. The ABNF [RFC5234] syntax
+ for this field is:
1*VCHAR *(SP 1*VCHAR)
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.
reference: A list of one or more URIs [RFC3986] from which the
registered specification can be obtained. The registered
@@ -1294,64 +1249,49 @@
Service Document registration:
URI suffix: rolie/servicedocument
Change controller: IETF
Specification document: This document, Section 5.1.3
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
This document defines a resource-oriented approach for lightweight
information exchange using HTTP over TLS, the Atom Syndication
Format, and the Atom Publishing Protocol. As such, implementers must
understand the security considerations described in those
specifications. All that follows is guidance, more specific
instruction is out of scope for this document.
To protect the confidentiality of a given resource provided by a
ROLIE implementation, requests for retrieval of the resource need to
be authenticated to prevent unauthorized users from accessing the
resource (see section 5.4). It can also be useful to log and audit
access to sensitive resources to verify that proper access controls
remain in place over time.
- The approach described herein is based upon all policy enforcements
- being implemented at the point when a resource representation is
- created. As such, producers sharing cyber security information using
- this specification must take care to authenticate their HTTP clients
- using a suitably strong user authentication mechanism. Sharing
- communities that are exchanging information on well-known indicators
- and incidents for purposes of public education may choose to rely
- upon HTTP Authentication or similar. A number of authentication
- schemes are defined in the HTTP Authentication Schemes Registry [3].
- Of these, HOBA [RFC7486] and SCRAM-SHA-256 [RFC7804] provide improved
- security properties over HTTP Basic [RFC7617]and Digest [RFC7616]
- Authentication Schemes. However, sharing communities that are
- engaged in sensitive collaborative analysis and/or operational
- response for indicators and incidents targeting high value
- information systems should adopt a suitably stronger user
- authentication solution, such as a risk-based or multi-factor
- approach. In general, trust in the sharing consortium will depend
- upon the members maintaining adequate user authentication mechanisms.
+ Access control to information published using ROLIE should use
+ mechanisms that are appropriate to the sensitivity of the
+ information. Primitive authentication mechanisms like HTTP Basic
+ Authentication [RFC7617] are rarely appropriate for sensitive
+ information. A number of authentication schemes are defined in the
+ HTTP Authentication Schemes Registry [3]. Of these, HOBA [RFC7486]
+ and SCRAM-SHA-256 [RFC7804] provide improved security properties over
+ HTTP Basic [RFC7617]and Digest [RFC7616] Authentication Schemes.
+ However, sharing communities that are engaged in sensitive
+ collaborative analysis and/or operational response for indicators and
+ incidents targeting high value information systems should adopt a
+ suitably stronger user authentication solution, such as a risk-based
+ or multi-factor approach.
Collaborating consortiums may benefit from the adoption of a
federated identity solution, such as those based upon OAuth [RFC6749]
with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind],
and SAML-prof [SAML-prof] for Web-based authentication and cross-
organizational single sign-on. Dependency on a trusted third party
identity provider implies that appropriate care must be exercised to
sufficiently secure the Identity provider. Any attacks on the
federated identity system would present a risk to the consortium, as
a relying party. Potential mitigations include deployment of a
@@ -1373,83 +1313,80 @@
policy enforcement requirements relevant to their consortium and/or
organization.
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 element in the RID schema.
Refer to RFC6545 section 9 for more information. Additionally, the
- underlying serialization approach used in the message (e.g., XML,
- JSON) can offer encryption and message authentication capabilities.
- For example, XMLDSig [RFC3275] for XML, and JSON Web Encryption
- [RFC7516] and JSON Web Signature[RFC7515] for JSON can provide such
- mechanisms.
+ underlying serialization approach used in the representation (e.g.,
+ XML, JSON) can offer encryption and message authentication
+ capabilities. For example, XMLDSig [RFC3275] for XML, and JSON Web
+ Encryption [RFC7516] and JSON Web Signature[RFC7515] for JSON can
+ provide such mechanisms.
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.
A service discovery mechanism is not explicitly specified in this
document, and there are several approaches available for
implementers. When selecting this mechanism, implementations need to
ensure that their choice provides a means for authenticating the
server. As described in the discovery section, DNS SRV Records are a
- possible secure solution to discovery.
+ possible solution to discovery.
10. Privacy Considerations
The optional author field may provide an identification privacy issue
if populated without the author's consent. This information may
become public if posted to a public feed. Special care should be
taken when aggregating or sharing entries from other feeds, or when
programmatically generating ROLIE entries from some data source that
the author's personal info is not shared without their consent.
When using the Atom Publishing Protocol to POST entries to a feed,
attackers may use correlating techniques to profile the user. 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
correlation attempt can be mitigated by not using HTTP requests to
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
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.
- 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
present in any other HTTP protocol. Those that exist can be
mitigated by following security considerations and carefully using
the optional identifying elements.
11. Acknowledgements
The authors gratefully acknowledge the valuable contributions of Tom
Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These
individuals provided detailed review comments on earlier drafts, and
@@ -1927,20 +1864,25 @@
src="http://www.example.org/provider/vulns/123456/data">
The example response above shows an XML document referenced by the
"src" attribute of the atom:content element. The client may retrieve
the document using this URL.
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
revision:
TLS requirements changed to clarify TLS versioning and
recommendations
Informative references and textual discussion added to Security
Considerations around HTTP Authentication and content Signing/
Encryption.