draft-ietf-mile-rolie-00.txt   draft-ietf-mile-rolie-01.txt 
MILE Working Group J. Field MILE Working Group J. Field
Internet-Draft EMC Internet-Draft Pivotal
Intended status: Informational December 5, 2014 Intended status: Informational December 2, 2015
Expires: June 8, 2015 Expires: June 4, 2016
Resource-Oriented Lightweight Indicator Exchange Resource-Oriented Lightweight Indicator Exchange
draft-ietf-mile-rolie-00.txt draft-ietf-mile-rolie-01
Abstract Abstract
This document defines a resource-oriented approach to cyber security This document defines a resource-oriented approach to cyber security
information sharing. Using this approach, a CSIRT or other information sharing. Using this approach, a CSIRT or other
stakeholder may share and exchange representations of cyber security stakeholder may share and exchange representations of cyber security
incidents, indicators, and other related information as Web- incidents, indicators, and other related information as Web-
addressable resources. The transport protocol binding is specified addressable resources. The transport protocol binding is specified
as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of
link relation types specific to cyber security information sharing is link relation types specific to cyber security information sharing is
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 http://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 June 8, 2015. This Internet-Draft will expire on June 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 (http://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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.3. Authorization Policy Enforcement . . . . . . . . . . . . 7 3.3. Authorization Policy Enforcement . . . . . . . . . . . . 7
3.3.1. Enforcement at Destination System . . . . . . . . . . 8 3.3.1. Enforcement at Destination System . . . . . . . . . . 8
3.3.2. Enforcement at Source System . . . . . . . . . . . . 9 3.3.2. Enforcement at Source System . . . . . . . . . . . . 9
4. RESTful Usage Model . . . . . . . . . . . . . . . . . . . . . 9 4. RESTful Usage Model . . . . . . . . . . . . . . . . . . . . . 9
4.1. Dynamic Service Discovery versus Static URL Template . . 10 4.1. Dynamic Service Discovery versus Static URL Template . . 10
4.2. Non-Normative Examples . . . . . . . . . . . . . . . . . 11 4.2. Non-Normative Examples . . . . . . . . . . . . . . . . . 11
4.2.1. Service Discovery . . . . . . . . . . . . . . . . . . 11 4.2.1. Service Discovery . . . . . . . . . . . . . . . . . . 11
4.2.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . 14 4.2.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . 14
4.2.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . 16 4.2.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . 16
4.2.4. Use of Link Relations . . . . . . . . . . . . . . . . 19 4.2.4. Use of Link Relations . . . . . . . . . . . . . . . . 19
5. Requirements for RESTful (Atom+xml) Binding . . . . . . . . 29 5. Requirements for RESTful (Atom+xml) Binding . . . . . . . . . 29
5.1. Transport Layer Security . . . . . . . . . . . . . . . . 29 5.1. Transport Layer Security . . . . . . . . . . . . . . . . 29
5.2. User Authentication . . . . . . . . . . . . . . . . . . . 29 5.2. Archiving and Paging . . . . . . . . . . . . . . . . . . 29
5.3. User Authorization . . . . . . . . . . . . . . . . . . . 30 5.3. Expectation and Impact Classes . . . . . . . . . . . . . 30
5.4. Content Model . . . . . . . . . . . . . . . . . . . . . . 30 5.4. User Authentication . . . . . . . . . . . . . . . . . . . 30
5.5. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 31 5.5. User Authorization . . . . . . . . . . . . . . . . . . . 30
5.6. Service Discovery . . . . . . . . . . . . . . . . . . . . 31 5.6. Content Model . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1. Workspaces . . . . . . . . . . . . . . . . . . . . . 31 5.7. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 31
5.6.2. Collections . . . . . . . . . . . . . . . . . . . . . 32 5.8. Service Discovery . . . . . . . . . . . . . . . . . . . . 32
5.6.3. Service Document Security . . . . . . . . . . . . . . 32 5.8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . 32
5.7. Category Mapping . . . . . . . . . . . . . . . . . . . . 32 5.8.2. Collections . . . . . . . . . . . . . . . . . . . . . 32
5.7.1. Collection Category . . . . . . . . . . . . . . . . . 32 5.8.3. Service Document Security . . . . . . . . . . . . . . 33
5.7.2. Entry Category . . . . . . . . . . . . . . . . . . . 33 5.9. Category Mapping . . . . . . . . . . . . . . . . . . . . 33
5.8. Entry ID . . . . . . . . . . . . . . . . . . . . . . . . 33 5.9.1. Collection Category . . . . . . . . . . . . . . . . . 33
5.9. Entry Content . . . . . . . . . . . . . . . . . . . . . . 33 5.9.2. Entry Category . . . . . . . . . . . . . . . . . . . 33
5.10. Link Relations . . . . . . . . . . . . . . . . . . . . . 33 5.10. Entry ID . . . . . . . . . . . . . . . . . . . . . . . . 34
5.10.1. Additional Link Relation Requirements . . . . . . . 35 5.11. Entry Content . . . . . . . . . . . . . . . . . . . . . . 34
5.11. Member Entry Forward Security . . . . . . . . . . . . . . 36 5.12. Link Relations . . . . . . . . . . . . . . . . . . . . . 34
5.12. Date Mapping . . . . . . . . . . . . . . . . . . . . . . 36 5.12.1. Additional Link Relation Requirements . . . . . . . 36
5.13. Search . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.14. / (forward slash) Resource URL . . . . . . . . . . . . . 37 5.13. Member Entry Forward Security . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 5.14. Date Mapping . . . . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 5.15. Search . . . . . . . . . . . . . . . . . . . . . . . . . 37
8. ToDo and Open Issues . . . . . . . . . . . . . . . . . . . . 40 5.16. / (forward slash) Resource URL . . . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative References . . . . . . . . . . . . . . . . . . 40 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . 41 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1. Normative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Change Tracking . . . . . . . . . . . . . . . . . . 42 9.2. Informative References . . . . . . . . . . . . . . . . . 42
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix A. Change Tracking . . . . . . . . . . . . . . . . . . 43
Appendix B. Resource Authorization Model . . . . . . . . . . . . 43 Appendix B. Resource Authorization Model . . . . . . . . . . . . 43
B.1. Example XACML Profile . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document defines a resource-oriented approach to cyber security This document defines a resource-oriented approach to cyber security
information sharing that follows the REST (Architectural Styles and t information sharing that follows the REST (Architectural Styles and t
he Design of Network-based Software Architectures) architectural he Design of Network-based Software Architectures) architectural
style. The resource representations leverage the existing IODEF style. The resource representations leverage the existing IODEF
[RFC5070] and RID [RFC6545] specifications as appropriate. The [RFC5070] and RID [RFC6545] specifications as appropriate. The
transport protocol binding is specified as HTTP(S) with a media type transport protocol binding is specified as HTTP(S) with a media type
skipping to change at page 29, line 40 skipping to change at page 29, line 40
format and Atom Pub as a RESTful binding for cyber security format and Atom Pub as a RESTful binding for cyber security
information sharing. information sharing.
5.1. Transport Layer Security 5.1. Transport Layer Security
Servers implementing this specification MUST support server- Servers implementing this specification MUST support server-
authenticated TLS. authenticated TLS.
Servers MAY support mutually authenticated TLS. Servers MAY support mutually authenticated TLS.
5.2. User Authentication 5.2. Archiving and Paging
A feed may contain an arbitrary number of entries. In some cases,
the complete response to a given query may consist of a logical
result set that contains a large number of entries. As a practical
matter, the full result set may need to be divided into more
managable portions. For example, a query may produce a full result
set that may need to be grouped into logical pages, for purposes of
rendering on a user interface.
An historical feed may need to be stable, and/or divided into some
defined epochs.
Use cases that require capabilities for paging and archiving of feeds
SHOULD support the mechanisms described in Feed Paging and Archiving
[RFC5005].
5.3. Expectation and Impact Classes
It is frequently the case that a CSIRT organization will need to
triage their investigation and response activities based upon, e.g.,
the state of the current threat environment, or simply as a result of
having limited resources.
In order to enable CSIRTs to effectively prioritize their response
activity, it is RECOMMENDED that feed implementors provide Atom
categories that correspond to the IODEF Expectation and Impact
classes. The availability of these feed categories will enable
clients to more easily retrieve and prioritize cyber security
information that has already been identified as having a specific
potential impact, or having a specific expectation.
Support for these catagories may also enable efficiencies for
organizations that already have established (or plan to establish)
operational processes and workflows that are based on these IODEF
classes.
5.4. User Authentication
Servers MUST require user authentication. Servers MUST require user authentication.
Servers MAY support more than one client authentication method. Servers MAY support more than one client authentication method.
Servers participating in an information sharing consotium and Servers participating in an information sharing consotium 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
as per SAML 2.0. as per SAML 2.0.
Servers MAY support client authenticated TLS. Servers MAY support client authenticated TLS.
5.3. User Authorization 5.5. User Authorization
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.
Authorization for a resource MAY be adjudicated based on the value(s) Authorization for a resource MAY be adjudicated based on the value(s)
of the associated Atom <category> element(s). of the associated Atom <category> element(s).
When the content model for the Atom <content> element of an Atom When the content model for the Atom <content> element of an Atom
Entry contains an <IODEF-Document>, then authorization MUST be Entry contains an <IODEF-Document>, then authorization MUST be
adjudicated based upon the Atom <category> element(s), whose values adjudicated based upon the Atom <category> element(s), whose values
have been mapped as per Section 5.7. have been mapped as per Section 5.9.
Any use of the <category> element(s) as an input to an authorization Any use of the <category> element(s) as an input to an authorization
policy decision MUST include both the "scheme" and "term" attributes policy decision MUST include both the "scheme" and "term" attributes
contained therein. As described in Section 5.7 below, the namespace contained therein. As described in Section 5.9 below, the namespace
of the "term" attribute is scoped by the associated "scheme" of the "term" attribute is scoped by the associated "scheme"
attribute. attribute.
5.4. Content Model 5.6. Content Model
Member entry resources providing a representation of an incident Member entry resources providing a representation of an incident
resource (e.g., as specified in the link relation type) MUST use the resource (e.g., as specified in the link relation type) MUST use the
IODEF schema as the content model for the Atom Entry <content> IODEF schema as the content model for the Atom Entry <content>
element. element.
Member Entry resources providing a representation of an indicator Member Entry resources providing a representation of an indicator
resource (e.g., as specified in the link relation type) MUST use the resource (e.g., as specified in the link relation type) MUST use the
IODEF schema as the content model for the Atom Entry <content> IODEF schema as the content model for the Atom Entry <content>
element. element.
skipping to change at page 31, line 9 skipping to change at page 31, line 45
RID schema as the content model for the Atom Entry <content> element. RID schema as the content model for the Atom Entry <content> element.
Member Entry resources providing representation of other types, Member Entry resources providing representation of other types,
SHOULD use the IODEF schema as the content model for the Atom Entry SHOULD use the IODEF schema as the content model for the Atom Entry
<content> element. <content> element.
If the member entry content model is not IODEF, then the <content> If the member entry content model is not IODEF, then the <content>
element of the Atom entry MUST contain an appropriate XML namespace element of the Atom entry MUST contain an appropriate XML namespace
declaration. declaration.
5.5. HTTP methods 5.7. HTTP methods
The following table defines the HTTP [RFC2616] uniform interface The following table defines the HTTP [RFC2616] uniform interface
methods supported by this specification: methods supported by this specification:
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| HTTP | Description | | HTTP | Description |
| method | | | method | |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| GET | Returns a representation of an individual member entry | | GET | Returns a representation of an individual member entry |
| | resource, or a feed collection. | | | resource, or a feed collection. |
skipping to change at page 31, line 39 skipping to change at page 32, line 30
| | feed collection, contained in HTTP response headers. | | | feed collection, contained in HTTP response headers. |
| PATCH | Support TBD. | | PATCH | Support TBD. |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
Table 1: Uniform Interface for Resource-Oriented Lightweight Table 1: Uniform Interface for Resource-Oriented Lightweight
Indicator Exchange Indicator Exchange
Clients MUST be capable of recognizing and prepared to process any Clients MUST be capable of recognizing and prepared to process any
standard HTTP status code, as defined in [RFC2616] standard HTTP status code, as defined in [RFC2616]
5.6. Service Discovery 5.8. Service Discovery
This specification requires that a CSIRT MUST publish an Atom Service This specification requires that a CSIRT MUST publish an Atom Service
Document that describes the set of cyber security information sharing Document that describes the set of cyber security information sharing
feeds that are provided. feeds that are provided.
The service document SHOULD be discoverable via the CSIRT The service document SHOULD be discoverable via the CSIRT
organization's Web home page or another well-known public resource. organization's Web home page or another well-known public resource.
5.6.1. Workspaces 5.8.1. Workspaces
The service document MAY include multiple workspaces. Any CSIRT The service document MAY include multiple workspaces. Any CSIRT
providing both public feeds and private consortium feeds MUST place providing both public feeds and private consortium feeds MUST place
these different classes of feeds into different workspaces, and these different classes of feeds into different workspaces, and
provide appropriate descriptions and naming conventions to indicate provide appropriate descriptions and naming conventions to indicate
the intended audience of each workspace. the intended audience of each workspace.
5.6.2. Collections 5.8.2. Collections
A CSIRT MAY provide any number of collections within a given A CSIRT MAY provide any number of collections within a given
Workspace. It is RECOMMENDED that each collection appear in only a Workspace. It is RECOMMENDED that each collection appear in only a
single Workspace. It is RECOMMENDED that at least one collection be single Workspace. It is RECOMMENDED that at least one collection be
provided that accepts new incident reports from users. At least one provided that accepts new incident reports from users. At least one
collection MUST provide a feed of incident information for which the collection MUST provide a feed of incident information for which the
content model for the entries uses the IODEF schema. The title of content model for the entries uses the IODEF schema. The title of
this collection SHOULD be "Incidents". this collection SHOULD be "Incidents".
5.6.3. Service Document Security 5.8.3. Service Document Security
Access to the service document MUST be protected via server- Access to the service document MUST be protected via server-
authenticated TLS and a server-side certificate. authenticated TLS and a server-side certificate.
When deploying a service document for use by a closed consortium, the When deploying a service document for use by a closed consortium, the
service document MAY also be digitally signed and/or encrypted, using service document MAY also be digitally signed and/or encrypted, using
XML DigSig and/or XML Encryption, respectively. XML DigSig and/or XML Encryption, respectively.
5.7. Category Mapping 5.9. Category Mapping
This section defines normative requirements for mapping IODEF This section defines normative requirements for mapping IODEF
metadata to corresponding Atom category elements. (todo: decide metadata to corresponding Atom category elements. (todo: decide
between IANA registration of scheme, or use a full URI). between IANA registration of scheme, or use a full URI).
5.7.1. Collection Category 5.9.1. Collection Category
An Atom collection MAY hold entries from one or more categories. The An Atom collection MAY hold entries from one or more categories. The
collection category set MUST contain at least the union of all the collection category set MUST contain at least the union of all the
member entry categories. A collection MAY have additional category member entry categories. A collection MAY have additional category
metadata that are unique to the collection, and not applicable to any metadata that are unique to the collection, and not applicable to any
individual member entry. A collection containing IODEF incident individual member entry. A collection containing IODEF incident
content MUST contain at least two <category> elements. One category content MUST contain at least two <category> elements. One category
MUST be specified with the value of the "scheme" attribute as MUST be specified with the value of the "scheme" attribute as
"restriction". One category MUST be specified with the value of the "restriction". One category MUST be specified with the value of the
"scheme" attribute as "purpose". The value of the "fixed" attribute "scheme" attribute as "purpose". The value of the "fixed" attribute
for both of these category elements MUST be "yes". When the category for both of these category elements MUST be "yes". When the category
scheme="restriction", the allowable values for the "term" attribute scheme="restriction", the allowable values for the "term" attribute
are constrained as per section 3.2 of IODEF, e.g. public, need-to- are constrained as per section 3.2 of IODEF, e.g. public, need-to-
know, private, default. When the category scheme="purpose", the know, private, default. When the category scheme="purpose", the
allowable values for the "term" attribute are constrained as per allowable values for the "term" attribute are constrained as per
section 3.2 of IODEF, e.g. traceback, mitigation, reporting, other. section 3.2 of IODEF, e.g. traceback, mitigation, reporting, other.
5.7.2. Entry Category 5.9.2. Entry Category
An Atom entry containing IODEF content MUST contain at least two An Atom entry containing IODEF content MUST contain at least two
<category> elements. One category MUST be specified with the value <category> elements. One category MUST be specified with the value
of the "scheme" attribute as "restriction". One category MUST be of the "scheme" attribute as "restriction". One category MUST be
specified with the value of the "scheme" attribute as "purpose". specified with the value of the "scheme" attribute as "purpose".
When the category scheme="restriction", the value of the "term" When the category scheme="restriction", the value of the "term"
attribute must be exactly one of ( public, need-to-know, private, attribute must be exactly one of ( public, need-to-know, private,
default). When the category scheme="purpose", the value of the default). When the category scheme="purpose", the value of the
"term" attribute must be exactly one of (traceback, mitigation, "term" attribute must be exactly one of (traceback, mitigation,
reporting, other). When the purpose is "other".... reporting, other). When the purpose is "other"....
Any member entry MAY have any number of additional categories. Any member entry MAY have any number of additional categories.
5.8. Entry ID 5.10. Entry ID
The ID element for an Atom entry SHOULD be established via the The ID element for an Atom entry SHOULD be established via the
concatenation of the value of the name attribute from the IODEF concatenation of the value of the name attribute from the IODEF
<IncidentID> element and the corresponding value of the <IncidentID> <IncidentID> element and the corresponding value of the <IncidentID>
element. This requirement ensures a simple and direct one-to-one element. This requirement ensures a simple and direct one-to-one
relationship between an IODEF incident ID and a corresponding Feed relationship between an IODEF incident ID and a corresponding Feed
entry ID and avoids the need for any system to maintain a persistent entry ID and avoids the need for any system to maintain a persistent
store of these identity mappings. store of these identity mappings.
(todo: Note that this implies a constraint on the IODEF document that (todo: Note that this implies a constraint on the IODEF document that
is more restrictive than the current IODEF schema. IODEF section 3.3 is more restrictive than the current IODEF schema. IODEF section 3.3
requires only that the name be a STRING type. Here we are stating requires only that the name be a STRING type. Here we are stating
that name must be an IRI. Possible request to update IODEF to that name must be an IRI. Possible request to update IODEF to
constrain, or to support a new element or attribute). constrain, or to support a new element or attribute).
5.9. Entry Content 5.11. Entry Content
The <content> element of an Atom <entry> SHOULD include an IODEF The <content> element of an Atom <entry> SHOULD include an IODEF
document. The <entry> element SHOULD include an appropriate XML document. The <entry> element SHOULD include an appropriate XML
namespace declaration for the IODEF schema. If the content model of namespace declaration for the IODEF schema. If the content model of
the <entry> element does not follow the IODEF schema, then the the <entry> element does not follow the IODEF schema, then the
<entry> element MUST include an appropriate XML namespace <entry> element MUST include an appropriate XML namespace
declaration. declaration.
A client MAY ignore content that is not using the IODEF schema. A client MAY ignore content that is not using the IODEF schema.
5.10. Link Relations 5.12. Link Relations
In addition to the standard Link Relations defined by the Atom In addition to the standard Link Relations defined by the Atom
specification, this specification defines the following additional specification, this specification defines the following additional
Link Relation terms, which are introduced specifically in support of Link Relation terms, which are introduced specifically in support of
the Resource-Oriented Lightweight Indicator Exchange protocol. the Resource-Oriented Lightweight Indicator Exchange protocol.
+-----------------------+-----------------------------+-------------+ +-----------------------+-----------------------------+-------------+
| Name | Description | Conformance | | Name | Description | Conformance |
+-----------------------+-----------------------------+-------------+ +-----------------------+-----------------------------+-------------+
| service | Provides a link to an atom | MUST | | service | Provides a link to an atom | MUST |
skipping to change at page 35, line 39 skipping to change at page 36, line 27
Exchange Exchange
Unless specifically registered with IANA these short names MUST be Unless specifically registered with IANA these short names MUST be
fully qualified via concatenation with a base-uri. An appropriate fully qualified via concatenation with a base-uri. An appropriate
base-uri could be established via agreement amongst the members of an base-uri could be established via agreement amongst the members of an
information sharing consortium. For example, the rel="indicators" information sharing consortium. For example, the rel="indicators"
relationship would become relationship would become
rel="http://www.example.org/csirt/incidents/relationships/ rel="http://www.example.org/csirt/incidents/relationships/
indicators." indicators."
5.10.1. Additional Link Relation Requirements 5.12.1. Additional Link Relation Requirements
An IODEF document that is carried in an Atom Entry SHOULD NOT contain An IODEF document that is carried in an Atom Entry SHOULD NOT contain
a <relatedActivity> element. Instead, the related activity SHOULD be a <relatedActivity> element. Instead, the related activity SHOULD be
available via a link rel=related. available via a link rel=related.
An IODEF document that is carried in an Atom Entry SHOULD NOT contain An IODEF document that is carried in an Atom Entry SHOULD NOT contain
a <history> element. Instead, the related history SHOULD be a <history> element. Instead, the related history SHOULD be
available via a link rel="history" (todo: or a fully qualified link available via a link rel="history" (todo: or a fully qualified link
rek name). The associated href MAY leverage OpenSearch to specify rek name). The associated href MAY leverage OpenSearch to specify
the required query. the required query.
An Atom Entry MAY include additional link relationships not specified An Atom Entry MAY include additional link relationships not specified
here. If a client encounters a link relationship of an unkown type here. If a client encounters a link relationship of an unkown type
the client MUST ignore the offending link and continue processing the the client MUST ignore the offending link and continue processing the
remaining resource representation as if the offending link element remaining resource representation as if the offending link element
did not appear. did not appear.
5.11. Member Entry Forward Security 5.13. Member Entry Forward Security
As described in Authorization Policy Enforcement As described in Authorization Policy Enforcement
(Authorization Policy Enforcement) a RESTful model for cyber security (Authorization Policy Enforcement) a RESTful model for cyber security
information sharing requires that all of the required security information sharing requires that all of the required security
enforcement for feeds and entries MUST be enforced at the source enforcement for feeds and entries MUST be enforced at the source
system, at the point the representation of the given resource(s) is system, at the point the representation of the given resource(s) is
created. A CSIRT provider SHALL NOT return any feed content or created. A CSIRT provider SHALL NOT return any feed content or
member entry content for which the client identity has not been member entry content for which the client identity has not been
specifically authenticated, authorized, and audited. specifically authenticated, authorized, and audited.
Sharing communities that have a requirement for forward message Sharing communities that have a requirement for forward message
security (such that client systems are required to participate in security (such that client systems are required to participate in
providing message level security and/or distributed authorization providing message level security and/or distributed authorization
policy enforcement), MUST use the RID schema as the content model for policy enforcement), MUST use the RID schema as the content model for
the member entry <content> element. the member entry <content> element.
5.12. Date Mapping 5.14. Date Mapping
The Atom feed <updated> element MUST be populated with the current The Atom feed <updated> element MUST be populated with the current
time at the instant the feed representation was generated. The Atom time at the instant the feed representation was generated. The Atom
entry <published> element MUST be populated with the same time value entry <published> element MUST be populated with the same time value
as the <reportTime> element from the IODEF document. as the <reportTime> element from the IODEF document.
5.13. Search 5.15. Search
Implementers MUST support OpenSearch 1.1 [opensearch] as the Implementers MUST support OpenSearch 1.1 [opensearch] as the
mechanism for describing how clients may form search requests. mechanism for describing how clients may form search requests.
Implementers MUST provide a link with a relationship type of Implementers MUST provide a link with a relationship type of
"search". This link SHALL return an Open Search Description Document "search". This link SHALL return an Open Search Description Document
as defined in OpenSearch 1.1. as defined in OpenSearch 1.1.
Implementers MUST support an OpenSearch 1.1 compliant search URL Implementers MUST support an OpenSearch 1.1 compliant search URL
template that enables a search query via Atom Category, including the template that enables a search query via Atom Category, including the
skipping to change at page 37, line 23 skipping to change at page 38, line 8
Collections that support use of the RID schema as a content model in Collections that support use of the RID schema as a content model in
the Atom member entry <content> element (e.g. in a report resource the Atom member entry <content> element (e.g. in a report resource
representation reachable via the "report" link relationship) MUST representation reachable via the "report" link relationship) MUST
support search operations that include the RID MessageType as a support search operations that include the RID MessageType as a
search parameter, in addition to the aforementioned IODEF schema search parameter, in addition to the aforementioned IODEF schema
elements, as contained within the <ReportSchema> element. elements, as contained within the <ReportSchema> element.
Implementers MUST fully qualify all OpenSearch URL template parameter Implementers MUST fully qualify all OpenSearch URL template parameter
names using the defined IODEF or RID XML namespaces, as appropriate. names using the defined IODEF or RID XML namespaces, as appropriate.
5.14. / (forward slash) Resource URL 5.16. / (forward slash) Resource URL
The "/" resource MAY be provided for compatibility with existing The "/" resource MAY be provided for compatibility with existing
deployments that are using Transport of Real-time Inter-network deployments that are using Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS [RFC6546]. Consistent with Defense (RID) Messages over HTTP/TLS [RFC6546]. Consistent with
RFC6546 errata, a client requesting a GET on "/" MUST receive an HTTP RFC6546 errata, a client requesting a GET on "/" MUST receive an HTTP
status code 405 Method Not Allowed. An implementation MAY provide status code 405 Method Not Allowed. An implementation MAY provide
full support for RFC6546 such that a POST to "/" containing a full support for RFC6546 such that a POST to "/" containing a
recognized RID message type just works. Alternatively, a client recognized RID message type just works. Alternatively, a client
requesting a POST to "/" MAY receive an HTTP status code 307 requesting a POST to "/" MAY receive an HTTP status code 307
Temporary Redirect. In this case, the location header in the HTTP Temporary Redirect. In this case, the location header in the HTTP
skipping to change at page 39, line 45 skipping to change at page 40, line 29
While it is a goal of this specification to enable more agile cyber While it is a goal of this specification to enable more agile cyber
security information sharing across a broader and varying security information sharing across a broader and varying
constituency, there is nothing in this specification that necessarily constituency, there is nothing in this specification that necessarily
requires this type of deployment. A cyber security information requires this type of deployment. A cyber security information
sharing consortium may chose to adopt this specification while sharing consortium may chose to adopt this specification while
continuing to operate as a gated community with strictly limited continuing to operate as a gated community with strictly limited
membership. membership.
7. IANA Considerations 7. IANA Considerations
If the values of the newly defined link relations are not fully This document does not require any actions from IANA.
qualified URIs then we need to register these link types with IANA
(e.g. rel="history") It is possible to adjust this document so that
it has no actions for IANA.
8. ToDo and Open Issues
The following is the "todo" and open issues list:
1. Need to make a decision on whether new IANA link registrations
are required, or whether fully qualified (private) link types are
sufficient.
2. Should we require Atom categories that correspond to IODEF
Expectation class and/or IODEF Impact class?
3. Should we include specific requirements for Archive and Paging?
Perhaps just reference RFC 5005?
4. We need more requirements input on use cases involving RID schema
in the Atom member entry content model for link rel=report.
5. An Atom service document will have categories, but this is still
coarse-grained, and not visible at the transport protocol level.
Should we include a MIME media type parameter to support
negotiation and better document the content model schema
contained in a collection, i.e.:
Accept: application/atom+xml;type=entry;content=iodef
Accept: application/atom+xml;type=entry;content=rid
Accept: application/atom+xml;type=entry;content=iodef+openioc
6. If so, I think these parameters may require media type
registration as per RFC4288?
9. Acknowledgements 8. Acknowledgements
The author gratefully acknowledges the valuable contributions of Tom The author gratefully acknowledges 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
many suggestions that have helped to improve this document . many suggestions that have helped to improve this document .
10. References 9. References
10.1. Normative References 9.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
Protocol", RFC 5023, October 2007. DOI 10.17487/RFC5005, September 2007,
<http://www.rfc-editor.org/info/rfc5005>.
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
October 2007, <http://www.rfc-editor.org/info/rfc5023>.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, December Object Description Exchange Format", RFC 5070,
2007. DOI 10.17487/RFC5070, December 2007,
<http://www.rfc-editor.org/info/rfc5070>.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
6545, April 2012. RFC 6545, DOI 10.17487/RFC6545, April 2012,
<http://www.rfc-editor.org/info/rfc6545>.
[opensearch] [opensearch]
Clinton, D., "OpenSearch 1.1 draft 5 specification", 2011, Clinton, D., "OpenSearch 1.1 draft 5 specification", 2011,
<http://www.opensearch.org/Specifications/OpenSearch/1.1>. <http://www.opensearch.org/Specifications/OpenSearch/1.1>.
[SAML-core] [SAML-core]
Cantor, S., Kemp, J., Philpott, R., and E. Mahler, Cantor, S., Kemp, J., Philpott, R., and E. Mahler,
"Assertions and Protocols for the OASIS Security Assertion "Assertions and Protocols for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard , March 2005, Markup Language (SAML) V2.0", OASIS Standard , March 2005,
<http://docs.oasis-open.org/security/saml/v2.0/ <http://docs.oasis-open.org/security/saml/v2.0/
skipping to change at page 41, line 47 skipping to change at page 42, line 5
Standard , March 2005, <http://docs.oasis- Standard , March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf>. open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf>.
[SAML-bind] [SAML-bind]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Mahler, "Bindings for the OASIS Security Assertion Markup Mahler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Standard , March 2005, Language (SAML) V2.0", OASIS Standard , March 2005,
<http://docs.oasis-open.org/security/saml/v2.0/ <http://docs.oasis-open.org/security/saml/v2.0/
saml-bindings-2.0-os.pdf>. saml-bindings-2.0-os.pdf>.
10.2. Informative References 9.2. Informative References
[XMLencrypt] [XMLencrypt]
Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
Syntax and Processing", W3C Recommendation , December Syntax and Processing", W3C Recommendation , December
2002, <http://www.w3.org/TR/xmlenc-core/>. 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
Simon, "XML-Signature Syntax and Processing", W3C Simon, "XML-Signature Syntax and Processing", W3C
Recommendation Second Edition, June 2008, Recommendation Second Edition, June 2008,
<http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/xmldsig-core/>.
skipping to change at page 42, line 21 skipping to change at page 42, line 28
(XACML) Version 3.0", August 2010, <http://docs.oasis- (XACML) Version 3.0", August 2010, <http://docs.oasis-
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>.
[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>.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. DOI 10.17487/RFC2396, August 1998,
<http://www.rfc-editor.org/info/rfc2396>.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
2001. DOI 10.17487/RFC2822, April 2001,
<http://www.rfc-editor.org/info/rfc2822>.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Internet: Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July Text on Security Considerations", BCP 72, RFC 3552,
2003. DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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, April Defense (RID) Messages over HTTP/TLS", RFC 6546,
2012. DOI 10.17487/RFC6546, April 2012,
<http://www.rfc-editor.org/info/rfc6546>.
10.3. URIs 9.3. URIs
[1] http://csrc.nist.gov/groups/SNS/rbac/ [1] http://csrc.nist.gov/groups/SNS/rbac/
Appendix A. Change Tracking Appendix A. Change Tracking
Changes since -00 version, September 5, 2012 to Feb 15, 2013: Changes since -02 version, August 15, 2013 to December 2, 2015:
o Fixed a small number of typographical errors and a few
misspellings throughout.
o Added a number of missing internal cross references to improve
readability.
o Updated the text in the Introduction section for improved brevity
and clarity of goal. See: Section 1
o Added new non-normative text describing the use of HTTP 4xx status
codes for authorization. See: Section 3.3.2
o Added a new non-normative example illustrating a persistent
repository use case. See: Section 4.2.4.4
o Added new normative text recommending use of SAML2 for o Added section specifying the use of RFC5005 for Archive and Paging
authentication of interactive end users who are members of a of feeds. See: Section 5.2
sharing consortium. See: Section 5.2
o Added new normative text describing requirements for user o Added section describing use of atom categories that correspond to
authorization. See: Section 5.3 IODEF expectation class and impact classes. See: Section 5.3
o Added non-normative appendix for change tracking. See: Appendix A o Dropped references to adoption of a MILE-specific HTTP media type
parameter.
o Added non-normative appendix describing a suggested approach to a o Updated IANA Considerations section to clarify that no IANA
XACML profile. See: Appendix B actions are required.
Appendix B. Resource Authorization Model Appendix B. Resource Authorization Model
As described in Section 3.3.2 above, ROLIE assumes that all As described in Section 3.3.2 above, ROLIE assumes that all
authorization policy enforcement is provided at the source server. authorization policy enforcement is provided at the source server.
The implementation details of the authorization scheme chosen by a The implementation details of the authorization scheme chosen by a
ROLIE-compliant provider are out of scope for this specification. ROLIE-compliant provider are out of scope for this specification.
Implementers are free to choose any suitable authorization mechanism Implementers are free to choose any suitable authorization mechanism
that is capable of fulfilling the policy enforcement requirements that is capable of fulfilling the policy enforcement requirements
relevant to their consortium and/or organization. relevant to their consortium and/or organization.
skipping to change at page 44, line 42 skipping to change at page 44, line 37
so on. One could also write policy to consider the CVSS score so on. One could also write policy to consider the CVSS score
associated with the resource, or the lifecycle phase of the resource associated with the resource, or the lifecycle phase of the resource
(vulnerability unverified, confirmed, patch available, etc.), and so (vulnerability unverified, confirmed, patch available, etc.), and so
on. on.
Having these policies expressed in a standards-compliant and machine- Having these policies expressed in a standards-compliant and machine-
readable format could improve the agility and effectiveness of a readable format could improve the agility and effectiveness of a
cyber security information sharing group or consortium, and enable cyber security information sharing group or consortium, and enable
better cyber defenses. better cyber defenses.
B.1. Example XACML Profile
Work-in-Progress. If this aproach finds support in the community
then this section (or a new draft, as a seperate document) could
provide a more complete XACML 3.0 compliant example.
Author's Address Author's Address
John P. Field John P. Field
EMC Corporation Pivotal Software, Inc.
1133 Westchester Avenue 625 Avenue of the Americas
White Plains, New York New York, New York
USA USA
Phone: 914-461-3522 Phone: (646)792-5770
Email: jfield@pivotal.io Email: jfield@pivotal.io
 End of changes. 55 change blocks. 
151 lines changed or deleted 152 lines changed or added

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