draft-ietf-mile-rolie-08.txt   draft-ietf-mile-rolie-09.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: January 18, 2018 D. Waltermire Expires: March 30, 2018 D. Waltermire
NIST NIST
July 17, 2017 September 26, 2017
Resource-Oriented Lightweight Information Exchange Resource-Oriented Lightweight Information Exchange
draft-ietf-mile-rolie-08 draft-ietf-mile-rolie-09
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 1, line 44 skipping to change at page 1, line 44
substantial issues need to be discussed on the MILE mailing list. substantial issues need to be discussed on the MILE mailing list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at 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 January 18, 2018. This Internet-Draft will expire on March 30, 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 18 skipping to change at page 3, line 18
7.3. The Link Relation Extension Point . . . . . . . . . . . . 23 7.3. The Link Relation Extension Point . . . . . . . . . . . . 23
7.4. The "rolie:property" Extension Point . . . . . . . . . . 23 7.4. The "rolie:property" Extension Point . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24
8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25
8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25
8.4. ROLIE Security Resource Information Type Sub-Registry . . 28 8.4. ROLIE Security Resource Information Type Sub-Registry . . 28
8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28 8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 34
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 35 Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 36
Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 36 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 37
B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 36 B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 37
B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 39 B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 40
B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 41 B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 42
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 42 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 4, line 9 skipping to change at page 4, line 9
The goal of this approach is to increase the communication and The goal of this approach is to increase the communication and
sharing of security information between providers and consumers that sharing of security information between providers and consumers that
can be used to automate security processes (e.g., incident reports, can be used to automate security processes (e.g., incident reports,
vulnerability assessments, configuration checklists, and other vulnerability assessments, configuration checklists, and other
security automation information). Such sharing allows human security automation information). Such sharing allows human
operators and computer systems to leverage this standardized operators and computer systems to leverage this standardized
communication system to gather information that supports the communication system to gather information that supports the
automation of security processes. automation of security processes.
In for new types of security automation information and associated To support new types of security automation information being used as
resource representations to be shared over time, this specification time goes on, this specification defines a number of extension points
defines extension points that can be used to add support for new that can be used either privately or globally. These global
information types and associated resource representations by means of extensions are IANA registered by ROLIE extension specifications, and
additional supplementary specification documents. Sections 5 and 6 provide enhanced interoperability for new use cases and domains.
of this document define the core requirements of all implementations Sections 5 and 6 of this document define the core requirements of all
of this specification, and is resource representation agnostic. An implementations of this specification, and is resource representation
overview of the extension system is provided in Section 7. agnostic. An overview of the extension system is provided in
Implementers seeking to provide support for specific security Section 7. Implementers seeking to provide support for specific
automation information types should refer to the specification for security automation information types should refer to the
that domain described by the IANA registry found in section 8.4. specification for that domain described by the IANA registry found in
section 8.4.
2. Terminology 2. Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The previous key words are used in this document to define the The previous key words are used in this document to define the
conformance requirements for implementations of this specification. conformance requirements for implementations of this specification.
This document does not give any recommendations for the use of ROLIE, This document does not give any recommendations for the use of ROLIE,
skipping to change at page 10, line 20 skipping to change at page 10, line 20
This allows clients to have a well-known location to find a ROLIE This allows clients to have a well-known location to find a ROLIE
category document, while giving implementations flexibility over how category document, while giving implementations flexibility over how
the service is deployed. the service is deployed.
This document registers the "rolie/categorydocument" well-known URI This document registers the "rolie/categorydocument" well-known URI
as per [RFC5785] in Section 8.5. 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. The following requirements
have been derived from [RFC7589]. have been in part derived from [RFC7589].
The most recent published version of TLS MUST be supported, and any TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented
mandatory-to-implement (MTI) cipher suites in that version MUST be according to all recommendations and best practices present in
supported as well. [RFC7525].
It is RECOMMENDED that the most recent published version of TLS is
supported. If this version is TLS 1.3, 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 The server MUST support certificate-based client authentication. An
implementation MUST support the set of TLS cipher suites that are implementation MUST support the set of TLS cipher suites that are
REQUIRED by the latest published version of the TLS specification. REQUIRED by the latest published version of the TLS specification.
An implementation MUST also support the TLS cipher suites that An implementation MUST also support the TLS cipher suites that
provide support for mutual authentication of clients and servers. provide support for mutual authentication of clients and servers.
During the TLS negotiation, the client MUST carefully examine the During the TLS negotiation, the client MUST carefully examine the
certificate presented by the server to determine if it meets the certificate presented by the server to determine if it meets the
client's expectations. Particularly, the client MUST check its client's expectations. Particularly, the client MUST check its
skipping to change at page 11, line 15 skipping to change at page 11, line 21
configuration or state data is sent to or received from the client. 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 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.
(e.g., SAML 2.0).
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, provide 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
skipping to change at page 20, line 47 skipping to change at page 20, line 47
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 The namespace "urn:ietf:params:rolie:category:local" has been
reserved in the IANA ROLIE Parameters table for private use as reserved in the IANA ROLIE Parameters table for private use as
defined in [RFC5226]. Any category whose "scheme" attribute uses defined in [RFC8126]. Any category whose "scheme" attribute uses
this as a prefix MUST be considered private use. Implementations this as a prefix MUST be considered private use. Implementations
encountering such a category MUST parse the content without error, encountering such a category MUST parse the content without error,
but MAY otherwise ignore the element. 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
skipping to change at page 21, line 31 skipping to change at page 21, line 31
support the registration of new category "scheme" attribute values by support the registration of new category "scheme" attribute values by
ROLIE extension specifications. Use of this extension point is ROLIE extension specifications. Use of this extension point is
discussed in section 8.3 using the name field with a type parameter discussed in section 8.3 using the name field with a type parameter
of "category" to indicate a category extension. of "category" to indicate a category extension.
7.1.2. Identification of Security Automation Information Types 7.1.2. Identification of Security Automation Information Types
A ROLIE specific extension point is provided through the A ROLIE specific extension point is provided through the
atom:category "scheme" value atom:category "scheme" value
"urn:ietf:params:rolie:category:information-type". This value is a "urn:ietf:params:rolie:category:information-type". This value is a
Uniform Resource Name (URN) [RFC2141] that is registered with IANA as Uniform Resource Name (URN) [RFC8141] that is registered with IANA as
described in section 8.3. When used as the "scheme" attribute in described in section 8.3. When used as the "scheme" attribute in
this way, the "term" attribute is expected to be a registered value this way, the "term" attribute is expected to be a registered value
as defined in section Section 8.4. Through this mechanism a given as defined in section Section 8.4. Through this mechanism a given
security automation information type can be used to: security automation information type can be used to:
1. identify that an "app:collection" element in a Service Document 1. identify that an "app:collection" element in a Service Document
points to an Atom Feed that contains Entries pertaining to a points to an Atom Feed that contains Entries pertaining to a
specific type of security automation information (see section specific type of security automation information (see section
5.1.2), or 5.1.2), or
skipping to change at page 22, line 32 skipping to change at page 22, line 32
configuration checklists: Content that can be used to assess the configuration checklists: Content that can be used to assess the
configuration settings related to installed software. configuration settings related to installed software.
software tags: Metadata used to identify and characterize software tags: Metadata used to identify and characterize
installable software. installable software.
This is a short list to inspire new engineering of information type This is a short list to inspire new engineering of information type
extensions that support the automation of security processes. extensions that support the automation of security processes.
This document does not specific any information types. Instead, This document does not specify any information types. Instead,
information types in ROLIE are expected to be registered in extension information types in ROLIE are expected to be registered in extension
documents that describe one or more new information types. This documents that describe one or more new information types. This
allows the information types used by ROLIE implementations to grow allows the information types used by ROLIE implementations to grow
over time to support new security automation use cases. These over time to support new security automation use cases. These
extension documents may also enhance ROLIE Service, Category, Feed, extension documents may also enhance ROLIE Service, Category, Feed,
and Entry documents by defining link relations, other categories, and and Entry documents by defining link relations, other categories, and
Format data model extensions to address the representational needs of Format data model extensions to address the representational needs of
these specific information types. New information types are added to these specific information types. New information types are added to
ROLIE through registrations to the IANA ROLIE Security Resource ROLIE through registrations to the IANA ROLIE Security Resource
Information Type registry defined in section 8.4. Information Type registry defined in section 8.4.
skipping to change at page 23, line 40 skipping to change at page 23, line 40
name field with a type parameter of "property" to indicate a property name field with a type parameter of "property" to indicate a property
extension. Implementations SHOULD prefer the use of registered extension. Implementations SHOULD prefer the use of registered
properties over implementation specific properties when possible. properties over implementation specific properties when possible.
ROLIE extensions are expected to register new and use existing ROLIE extensions are expected to register new and use existing
properties to provide valuable identifying and characterizing properties to provide valuable identifying and characterizing
information for a given information type and/or format. information for a given information type and/or format.
The namespace "urn:ietf:params:rolie:property:local" has been The namespace "urn:ietf:params:rolie:property:local" has been
reserved in the IANA ROLIE Parameters table for private use as reserved in the IANA ROLIE Parameters table for private use as
defined in [RFC5226]. Any property whose "name" attribute uses this defined in [RFC8126]. Any property whose "name" attribute uses this
as a prefix MUST be considered private use. Implementations as a prefix MUST be considered private use. Implementations
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
skipping to change at page 25, line 36 skipping to change at page 25, line 36
8.3. ROLIE URN Parameters 8.3. ROLIE URN Parameters
A new top-level registry has been created, entitled "Resource A new top-level registry has been created, entitled "Resource
Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO
BE REMOVED: This registration should take place at the following BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/rolie] location: https://www.iana.org/assignments/rolie]
In this top-level registry, a sub-registry entitled "ROLIE URN In this top-level registry, a sub-registry entitled "ROLIE URN
Parameters" has been created. Registration in this repository is via Parameters" has been created. Registration in this repository is via
the Specification Required policy [RFC5226]. Designated Expert the Specification Required policy [RFC8126]. Designated Expert
reviews should be routed through the MILE WG mailing list. Failing reviews should be routed through the MILE WG mailing list. Failing
this, the Designated Expert will be assigned by the IESG. this, the Designated Expert will be assigned by the IESG. The
authors recommend the following individuals be assigned by the IESG
as Designated Experts:
Stephen Banghart <stephen.banghart@nist.gov>
David Waltermire <david.waltermire@nist.gov>
Each entry in this sub-registry must record the following fields: Each entry in this sub-registry must record the following fields:
Name: A URN segment that adheres to the pattern {type}:{label}. Name: A URN segment that adheres to the pattern {type}:{label}.
The keywords are defined as follows: The keywords are defined as follows:
{type}: The parameter type. The allowed values are "category" {type}: The parameter type. The allowed values are "category"
or "property". "category" denotes a category extension as or "property". "category" denotes a category extension as
discussed in Section 7.1. "property" denotes a property discussed in Section 7.1. "property" denotes a property
extension as discussed in Section 7.4. extension as discussed in Section 7.4.
{label}: A required US-ASCII string that conforms to the URN {label}: A required US-ASCII string that conforms to the URN
syntax requirements (see [RFC2141]). This string must be syntax requirements (see [RFC8141]). This string must be
unique within the namespace defined by the {type} keyword. The unique within the namespace defined by the {type} keyword. The
"local" label for both the "category" and "property" types has "local" label for both the "category" and "property" types has
been reserved for private use. been reserved for private use.
Extension IRI: The identifier to use within ROLIE, which is the Extension IRI: The identifier to use within ROLIE, which is the
full URN using the form: urn:ietf:params:rolie:{name}, where full URN using the form: urn:ietf:params:rolie:{name}, where
{name} is the "name" field of this registration. {name} is the "name" field of this registration.
Reference: A static link to the specification and section that the Reference: A static link to the specification and section that the
definition of the parameter can be found. definition of the parameter can be found.
skipping to change at page 28, line 34 skipping to change at page 28, line 34
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
specification MUST be readily and publicly available from that specification MUST be readily and publicly available from that
URI. The URI SHOULD be a stable reference. URI. The URI SHOULD be a stable reference.
Allocation Policy: Specification required as per [RFC5226] Allocation Policy: Specification required as per [RFC8126]
8.5. Well-Known URI Registrations 8.5. Well-Known URI Registrations
This document makes the follow two registrations to the Well-Known This document makes the follow two registrations to the Well-Known
URI Registry at https://www.iana.org/assignments/well-known-uris/ URI Registry at https://www.iana.org/assignments/well-known-uris/
well-known-uris.xhtml. well-known-uris.xhtml.
Service Document registration: Service Document registration:
URI suffix: rolie/servicedocument URI suffix: rolie/servicedocument
skipping to change at page 29, line 36 skipping to change at page 29, line 36
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 The approach described herein is based upon all policy enforcements
being implemented at the point when a resource representation is being implemented at the point when a resource representation is
created. As such, producers sharing cyber security information using created. As such, producers sharing cyber security information using
this specification must take care to authenticate their HTTP clients this specification must take care to authenticate their HTTP clients
using a suitably strong user authentication mechanism. Sharing using a suitably strong user authentication mechanism. Sharing
communities that are exchanging information on well-known indicators communities that are exchanging information on well-known indicators
and incidents for purposes of public education may choose to rely and incidents for purposes of public education may choose to rely
upon HTTP Authentication or similar. However, sharing communities upon HTTP Authentication or similar. A number of authentication
that are engaged in sensitive collaborative analysis and/or schemes are defined in the HTTP Authentication Schemes Registry [3].
operational response for indicators and incidents targeting high Of these, HOBA [RFC7486] and SCRAM-SHA-256 [RFC7804] provide improved
value information systems should adopt a suitably stronger user 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 authentication solution, such as a risk-based or multi-factor
approach. In general, trust in the sharing consortium will depend approach. In general, trust in the sharing consortium will depend
upon the members maintaining adequate user authentication mechanisms. upon the members maintaining adequate user authentication mechanisms.
Collaborating consortiums may benefit from the adoption of a Collaborating consortiums may benefit from the adoption of a
federated identity solution, such as those based upon SAML-core federated identity solution, such as those based upon [RFC6749], or
[SAML-core], SAML-bind [SAML-bind], and SAML-prof [SAML-prof] for SAML-core [SAML-core], SAML-bind [SAML-bind], and SAML-prof
Web-based authentication and cross-organizational single sign-on. [SAML-prof] for Web-based authentication and cross-organizational
Dependency on a trusted third party identity provider implies that single sign-on. Dependency on a trusted third party identity
appropriate care must be exercised to sufficiently secure the provider implies that appropriate care must be exercised to
Identity provider. Any attacks on the federated identity system sufficiently secure the Identity provider. Any attacks on the
would present a risk to the consortium, as a relying party. federated identity system would present a risk to the consortium, as
Potential mitigations include deployment of a federation-aware a relying party. Potential mitigations include deployment of a
identity provider that is under the control of the information federation-aware identity provider that is under the control of the
sharing consortium, with suitably stringent technical and management information sharing consortium, with suitably stringent technical and
controls. management controls.
Authorization of resource representations is the responsibility of Authorization of resource representations is the responsibility of
the source system, i.e. based on the authenticated user identity the source system, i.e. based on the authenticated user identity
associated with an HTTP(S) request. The required authorization associated with an HTTP(S) request. The required authorization
policies that are to be enforced must therefore be managed by the policies that are to be enforced must therefore be managed by the
security administrators of the source system. Various authorization security administrators of the source system. Various authorization
architectures would be suitable for this purpose, such as RBAC [3] architectures would be suitable for this purpose, such as RBAC [4]
and/or ABAC, as embodied in XACML [XACML]. In particular, and/or ABAC, as embodied in XACML [XACML]. In particular,
implementers adopting XACML may benefit from the capability to implementers adopting XACML may benefit from the capability to
represent their authorization policies in a standardized, represent their authorization policies in a standardized,
interoperable format. Note that implementers are free to choose any interoperable format. Note that implementers are free to choose any
suitable authorization mechanism that is capable of fulfilling the suitable authorization mechanism that is capable of fulfilling the
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. 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.
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
skipping to change at page 31, line 41 skipping to change at page 31, line 45
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
made many suggestions that have helped to improve this document. made many suggestions that have helped to improve this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[relax-NG] [relax-NG]
Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002, Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002,
<https://www.oasis-open.org/committees/relax-ng/compact- <https://www.oasis-open.org/committees/relax-ng/
20021121.html>. compact-20021121.html>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>. 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>. December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using
Transport Layer Security (TLS) with Network News Transfer Transport Layer Security (TLS) with Network News Transfer
Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October
2006, <http://www.rfc-editor.org/info/rfc4642>. 2006, <https://www.rfc-editor.org/info/rfc4642>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
DOI 10.17487/RFC5005, September 2007, DOI 10.17487/RFC5005, September 2007,
<http://www.rfc-editor.org/info/rfc5005>. <https://www.rfc-editor.org/info/rfc5005>.
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
October 2007, <http://www.rfc-editor.org/info/rfc5023>. October 2007, <https://www.rfc-editor.org/info/rfc5023>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546, Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012, DOI 10.17487/RFC6546, April 2012,
<http://www.rfc-editor.org/info/rfc6546>. <https://www.rfc-editor.org/info/rfc6546>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589, Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015, DOI 10.17487/RFC7589, June 2015,
<http://www.rfc-editor.org/info/rfc7589>. <https://www.rfc-editor.org/info/rfc7589>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange [RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970, Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <http://www.rfc-editor.org/info/rfc7970>. November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[W3C.REC-xml-names-20091208] [W3C.REC-xml-names-20091208]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208, Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
12.2. Informative References 12.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>. top.htm>.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <https://www.rfc-editor.org/info/rfc2782>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, DOI 10.17487/RFC3275, March 2002,
<https://www.rfc-editor.org/info/rfc3275>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-
Bound Authentication (HOBA)", RFC 7486,
DOI 10.17487/RFC7486, March 2015,
<https://www.rfc-editor.org/info/rfc7486>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>.
[RFC7804] Melnikov, A., "Salted Challenge Response HTTP
Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
March 2016, <https://www.rfc-editor.org/info/rfc7804>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>.
[SAML-bind] [SAML-bind]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Standard saml-bindings- Language (SAML) V2.0", OASIS Standard saml-bindings-
2.0-os, March 2005, <http://docs.oasis- 2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>. open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>.
[SAML-core] [SAML-core]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
skipping to change at page 35, line 13 skipping to change at page 36, line 17
open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>. open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>.
12.3. URIs 12.3. URIs
[1] https://www.iana.org/assignments/link-relations/link- [1] https://www.iana.org/assignments/link-relations/link-
relations.xhtml relations.xhtml
[2] https://www.iana.org/assignments/link-relations/link- [2] https://www.iana.org/assignments/link-relations/link-
relations.xhtml relations.xhtml
[3] http://csrc.nist.gov/groups/SNS/rbac/ [3] https://www.iana.org/assignments/http-authschemes/http-
authschemes.xhtml
[4] http://csrc.nist.gov/groups/SNS/rbac/
Appendix A. Relax NG Compact Schema for ROLIE Appendix A. Relax NG Compact Schema for ROLIE
This appendix is informative. This appendix is informative.
The Relax NG schema below defines the rolie:format element. The Relax NG schema below defines the rolie:format element.
# -*- rnc -*- # -*- rnc -*-
# RELAX NG Compact Syntax Grammar for the rolie ns # RELAX NG Compact Syntax Grammar for the rolie ns
skipping to change at page 42, line 7 skipping to change at page 43, 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-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.
IANA Expert review clarified.
Editorial changes from AD review/WGLC.
Changes in draft-ietf-mile-rolie-08 since draft-ietf-mile-rolie-07 Changes in draft-ietf-mile-rolie-08 since draft-ietf-mile-rolie-07
revision: revision:
Reworked "usage of app:collection" and "usage of atom:feed" Reworked "usage of app:collection" and "usage of atom:feed"
sections to clarify ROLIE vs non-ROLIE collections/feeds sections to clarify ROLIE vs non-ROLIE collections/feeds
Removed requirement from Security Considerations that was a Removed requirement from Security Considerations that was a
duplicate of text earlier in the document duplicate of text earlier in the document
TLS requirement clarifications around mutal authentication TLS requirement clarifications around mutal authentication
skipping to change at page 45, line 4 skipping to change at page 46, line 18
Authors' Addresses Authors' Addresses
John P. Field John P. Field
Pivotal Software, Inc. Pivotal Software, Inc.
625 Avenue of the Americas 625 Avenue of the Americas
New York, New York New York, New York
USA USA
Phone: (646)792-5770 Phone: (646)792-5770
Email: jfield@pivotal.io Email: jfield@pivotal.io
Stephen A. Banghart Stephen A. Banghart
National Institute of Standards and Technology National Institute of Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, Maryland Gaithersburg, Maryland
USA USA
Phone: (301)975-4288 Phone: (301)975-4288
Email: sab3@nist.gov Email: stephen.banghart@nist.gov
David Waltermire David Waltermire
National Institute of Standards and Technology National Institute of Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, Maryland 20877 Gaithersburg, Maryland 20877
USA USA
Email: david.waltermire@nist.gov Email: david.waltermire@nist.gov
 End of changes. 51 change blocks. 
90 lines changed or deleted 173 lines changed or added

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