--- 1/draft-ietf-mile-rolie-00.txt 2015-12-02 09:17:06.035670150 -0800 +++ 2/draft-ietf-mile-rolie-01.txt 2015-12-02 09:17:06.163673161 -0800 @@ -1,18 +1,18 @@ MILE Working Group J. Field -Internet-Draft EMC -Intended status: Informational December 5, 2014 -Expires: June 8, 2015 +Internet-Draft Pivotal +Intended status: Informational December 2, 2015 +Expires: June 4, 2016 Resource-Oriented Lightweight Indicator Exchange - draft-ietf-mile-rolie-00.txt + draft-ietf-mile-rolie-01 Abstract This document defines a resource-oriented approach to cyber security information sharing. Using this approach, a CSIRT or other stakeholder may share and exchange representations of cyber security incidents, indicators, and other related information as Web- addressable resources. The transport protocol binding is specified 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 @@ -31,25 +31,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 8, 2015. + This Internet-Draft will expire on June 4, 2016. 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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -67,52 +67,53 @@ 3.3. Authorization Policy Enforcement . . . . . . . . . . . . 7 3.3.1. Enforcement at Destination System . . . . . . . . . . 8 3.3.2. Enforcement at Source System . . . . . . . . . . . . 9 4. RESTful Usage Model . . . . . . . . . . . . . . . . . . . . . 9 4.1. Dynamic Service Discovery versus Static URL Template . . 10 4.2. Non-Normative Examples . . . . . . . . . . . . . . . . . 11 4.2.1. Service Discovery . . . . . . . . . . . . . . . . . . 11 4.2.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . 14 4.2.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . 16 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.2. User Authentication . . . . . . . . . . . . . . . . . . . 29 - 5.3. User Authorization . . . . . . . . . . . . . . . . . . . 30 - 5.4. Content Model . . . . . . . . . . . . . . . . . . . . . . 30 - 5.5. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 31 - 5.6. Service Discovery . . . . . . . . . . . . . . . . . . . . 31 - 5.6.1. Workspaces . . . . . . . . . . . . . . . . . . . . . 31 - 5.6.2. Collections . . . . . . . . . . . . . . . . . . . . . 32 - 5.6.3. Service Document Security . . . . . . . . . . . . . . 32 - 5.7. Category Mapping . . . . . . . . . . . . . . . . . . . . 32 - 5.7.1. Collection Category . . . . . . . . . . . . . . . . . 32 - 5.7.2. Entry Category . . . . . . . . . . . . . . . . . . . 33 - 5.8. Entry ID . . . . . . . . . . . . . . . . . . . . . . . . 33 - 5.9. Entry Content . . . . . . . . . . . . . . . . . . . . . . 33 - 5.10. Link Relations . . . . . . . . . . . . . . . . . . . . . 33 - 5.10.1. Additional Link Relation Requirements . . . . . . . 35 - 5.11. Member Entry Forward Security . . . . . . . . . . . . . . 36 - 5.12. Date Mapping . . . . . . . . . . . . . . . . . . . . . . 36 - 5.13. Search . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 5.14. / (forward slash) Resource URL . . . . . . . . . . . . . 37 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 - 8. ToDo and Open Issues . . . . . . . . . . . . . . . . . . . . 40 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 40 - 10.2. Informative References . . . . . . . . . . . . . . . . . 41 - 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 - Appendix A. Change Tracking . . . . . . . . . . . . . . . . . . 42 + 5.2. Archiving and Paging . . . . . . . . . . . . . . . . . . 29 + 5.3. Expectation and Impact Classes . . . . . . . . . . . . . 30 + 5.4. User Authentication . . . . . . . . . . . . . . . . . . . 30 + 5.5. User Authorization . . . . . . . . . . . . . . . . . . . 30 + 5.6. Content Model . . . . . . . . . . . . . . . . . . . . . . 31 + 5.7. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 31 + 5.8. Service Discovery . . . . . . . . . . . . . . . . . . . . 32 + 5.8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . 32 + 5.8.2. Collections . . . . . . . . . . . . . . . . . . . . . 32 + 5.8.3. Service Document Security . . . . . . . . . . . . . . 33 + 5.9. Category Mapping . . . . . . . . . . . . . . . . . . . . 33 + 5.9.1. Collection Category . . . . . . . . . . . . . . . . . 33 + 5.9.2. Entry Category . . . . . . . . . . . . . . . . . . . 33 + 5.10. Entry ID . . . . . . . . . . . . . . . . . . . . . . . . 34 + 5.11. Entry Content . . . . . . . . . . . . . . . . . . . . . . 34 + 5.12. Link Relations . . . . . . . . . . . . . . . . . . . . . 34 + 5.12.1. Additional Link Relation Requirements . . . . . . . 36 + + 5.13. Member Entry Forward Security . . . . . . . . . . . . . . 36 + 5.14. Date Mapping . . . . . . . . . . . . . . . . . . . . . . 37 + 5.15. Search . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 5.16. / (forward slash) Resource URL . . . . . . . . . . . . . 38 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 40 + 9.2. Informative References . . . . . . . . . . . . . . . . . 42 + 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43 + Appendix A. Change Tracking . . . . . . . . . . . . . . . . . . 43 Appendix B. Resource Authorization Model . . . . . . . . . . . . 43 - B.1. Example XACML Profile . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction This document defines a resource-oriented approach to cyber security information sharing that follows the REST (Architectural Styles and t he Design of Network-based Software Architectures) architectural style. The resource representations leverage the existing IODEF [RFC5070] and RID [RFC6545] specifications as appropriate. The transport protocol binding is specified as HTTP(S) with a media type @@ -1196,56 +1197,93 @@ format and Atom Pub as a RESTful binding for cyber security information sharing. 5.1. Transport Layer Security Servers implementing this specification MUST support server- 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 MAY support more than one client authentication method. Servers participating in an information sharing consotium and supporting interactive user logins by members of the consortium SHOULD support client authentication via a federated identity scheme as per SAML 2.0. 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 authorization mechanisms. However, service implementers SHOULD provide appropriate authorization checking for all resource accesses, including individual Atom Entries, Atom Feeds, and Atom Service Documents. Authorization for a resource MAY be adjudicated based on the value(s) of the associated Atom element(s). When the content model for the Atom element of an Atom Entry contains an , then authorization MUST be adjudicated based upon the Atom element(s), whose values - have been mapped as per Section 5.7. + have been mapped as per Section 5.9. Any use of the element(s) as an input to an authorization 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" attribute. -5.4. Content Model +5.6. Content Model Member entry resources providing a representation of an incident resource (e.g., as specified in the link relation type) MUST use the IODEF schema as the content model for the Atom Entry element. Member Entry resources providing a representation of an indicator resource (e.g., as specified in the link relation type) MUST use the IODEF schema as the content model for the Atom Entry element. @@ -1260,21 +1298,21 @@ RID schema as the content model for the Atom Entry element. Member Entry resources providing representation of other types, SHOULD use the IODEF schema as the content model for the Atom Entry element. If the member entry content model is not IODEF, then the element of the Atom entry MUST contain an appropriate XML namespace declaration. -5.5. HTTP methods +5.7. HTTP methods The following table defines the HTTP [RFC2616] uniform interface methods supported by this specification: +--------+----------------------------------------------------------+ | HTTP | Description | | method | | +--------+----------------------------------------------------------+ | GET | Returns a representation of an individual member entry | | | resource, or a feed collection. | @@ -1290,122 +1328,122 @@ | | feed collection, contained in HTTP response headers. | | PATCH | Support TBD. | +--------+----------------------------------------------------------+ Table 1: Uniform Interface for Resource-Oriented Lightweight Indicator Exchange Clients MUST be capable of recognizing and prepared to process any 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 Document that describes the set of cyber security information sharing feeds that are provided. The service document SHOULD be discoverable via the CSIRT 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 providing both public feeds and private consortium feeds MUST place these different classes of feeds into different workspaces, and provide appropriate descriptions and naming conventions to indicate 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 Workspace. It is RECOMMENDED that each collection appear in only a single Workspace. It is RECOMMENDED that at least one collection be provided that accepts new incident reports from users. At least one collection MUST provide a feed of incident information for which the content model for the entries uses the IODEF schema. The title of 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- authenticated TLS and a server-side certificate. When deploying a service document for use by a closed consortium, the service document MAY also be digitally signed and/or encrypted, using XML DigSig and/or XML Encryption, respectively. -5.7. Category Mapping +5.9. Category Mapping This section defines normative requirements for mapping IODEF metadata to corresponding Atom category elements. (todo: decide 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 collection category set MUST contain at least the union of all the member entry categories. A collection MAY have additional category metadata that are unique to the collection, and not applicable to any individual member entry. A collection containing IODEF incident content MUST contain at least two elements. One category MUST be specified with the value of the "scheme" attribute as "restriction". One category MUST be specified with the value of the "scheme" attribute as "purpose". The value of the "fixed" attribute for both of these category elements MUST be "yes". When the category scheme="restriction", the allowable values for the "term" attribute are constrained as per section 3.2 of IODEF, e.g. public, need-to- know, private, default. When the category scheme="purpose", the allowable values for the "term" attribute are constrained as per 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 elements. One category MUST be specified with the value of the "scheme" attribute as "restriction". One category MUST be specified with the value of the "scheme" attribute as "purpose". When the category scheme="restriction", the value of the "term" attribute must be exactly one of ( public, need-to-know, private, default). When the category scheme="purpose", the value of the "term" attribute must be exactly one of (traceback, mitigation, reporting, other). When the purpose is "other".... 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 concatenation of the value of the name attribute from the IODEF element and the corresponding value of the element. This requirement ensures a simple and direct one-to-one relationship between an IODEF incident ID and a corresponding Feed entry ID and avoids the need for any system to maintain a persistent store of these identity mappings. (todo: Note that this implies a constraint on the IODEF document that 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 that name must be an IRI. Possible request to update IODEF to constrain, or to support a new element or attribute). -5.9. Entry Content +5.11. Entry Content The element of an Atom SHOULD include an IODEF document. The element SHOULD include an appropriate XML namespace declaration for the IODEF schema. If the content model of the element does not follow the IODEF schema, then the element MUST include an appropriate XML namespace declaration. 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 specification, this specification defines the following additional Link Relation terms, which are introduced specifically in support of the Resource-Oriented Lightweight Indicator Exchange protocol. +-----------------------+-----------------------------+-------------+ | Name | Description | Conformance | +-----------------------+-----------------------------+-------------+ | service | Provides a link to an atom | MUST | @@ -1481,63 +1519,63 @@ Exchange Unless specifically registered with IANA these short names MUST be fully qualified via concatenation with a base-uri. An appropriate base-uri could be established via agreement amongst the members of an information sharing consortium. For example, the rel="indicators" relationship would become rel="http://www.example.org/csirt/incidents/relationships/ 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 a element. Instead, the related activity SHOULD be available via a link rel=related. An IODEF document that is carried in an Atom Entry SHOULD NOT contain a element. Instead, the related history SHOULD be available via a link rel="history" (todo: or a fully qualified link rek name). The associated href MAY leverage OpenSearch to specify the required query. An Atom Entry MAY include additional link relationships not specified here. If a client encounters a link relationship of an unkown type the client MUST ignore the offending link and continue processing the remaining resource representation as if the offending link element did not appear. -5.11. Member Entry Forward Security +5.13. Member Entry Forward Security As described in Authorization Policy Enforcement (Authorization Policy Enforcement) a RESTful model for cyber security information sharing requires that all of the required security enforcement for feeds and entries MUST be enforced at the source system, at the point the representation of the given resource(s) is created. A CSIRT provider SHALL NOT return any feed content or member entry content for which the client identity has not been specifically authenticated, authorized, and audited. Sharing communities that have a requirement for forward message security (such that client systems are required to participate in providing message level security and/or distributed authorization policy enforcement), MUST use the RID schema as the content model for the member entry element. -5.12. Date Mapping +5.14. Date Mapping The Atom feed element MUST be populated with the current time at the instant the feed representation was generated. The Atom entry element MUST be populated with the same time value as the element from the IODEF document. -5.13. Search +5.15. Search Implementers MUST support OpenSearch 1.1 [opensearch] as the mechanism for describing how clients may form search requests. Implementers MUST provide a link with a relationship type of "search". This link SHALL return an Open Search Description Document as defined in OpenSearch 1.1. Implementers MUST support an OpenSearch 1.1 compliant search URL template that enables a search query via Atom Category, including the @@ -1557,21 +1595,21 @@ Collections that support use of the RID schema as a content model in the Atom member entry element (e.g. in a report resource representation reachable via the "report" link relationship) MUST support search operations that include the RID MessageType as a search parameter, in addition to the aforementioned IODEF schema elements, as contained within the element. Implementers MUST fully qualify all OpenSearch URL template parameter 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 deployments that are using Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS [RFC6546]. Consistent with RFC6546 errata, a client requesting a GET on "/" MUST receive an HTTP status code 405 Method Not Allowed. An implementation MAY provide full support for RFC6546 such that a POST to "/" containing a recognized RID message type just works. Alternatively, a client requesting a POST to "/" MAY receive an HTTP status code 307 Temporary Redirect. In this case, the location header in the HTTP @@ -1674,87 +1712,64 @@ While it is a goal of this specification to enable more agile cyber security information sharing across a broader and varying constituency, there is nothing in this specification that necessarily requires this type of deployment. A cyber security information sharing consortium may chose to adopt this specification while continuing to operate as a gated community with strictly limited membership. 7. IANA Considerations - If the values of the newly defined link relations are not fully - 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? + This document does not require any actions from IANA. -9. Acknowledgements +8. Acknowledgements The author gratefully acknowledges the valuable contributions of Tom Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These individuals provided detailed review comments on earlier drafts, and many suggestions that have helped to improve this document . -10. References +9. References -10.1. Normative References +9.1. Normative References [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, + . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 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, + . [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, . - [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing - Protocol", RFC 5023, October 2007. + [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, + DOI 10.17487/RFC5005, September 2007, + . + + [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom + Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, + October 2007, . [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident - Object Description Exchange Format", RFC 5070, December - 2007. + Object Description Exchange Format", RFC 5070, + DOI 10.17487/RFC5070, December 2007, + . - [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC - 6545, April 2012. + [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", + RFC 6545, DOI 10.17487/RFC6545, April 2012, + . [opensearch] Clinton, D., "OpenSearch 1.1 draft 5 specification", 2011, . [SAML-core] Cantor, S., Kemp, J., Philpott, R., and E. Mahler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard , March 2005, . [SAML-bind] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Mahler, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard , March 2005, . -10.2. Informative References +9.2. Informative References [XMLencrypt] Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Syntax and Processing", W3C Recommendation , December 2002, . [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. Simon, "XML-Signature Syntax and Processing", W3C Recommendation Second Edition, June 2008, . @@ -1790,74 +1805,65 @@ (XACML) Version 3.0", August 2010, . [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000, . [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. + DOI 10.17487/RFC2396, August 1998, + . - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April - 2001. + [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, + DOI 10.17487/RFC2822, April 2001, + . - [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the - Internet: Timestamps", RFC 3339, July 2002. + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC - Text on Security Considerations", BCP 72, RFC 3552, July - 2003. + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, - May 2008. + DOI 10.17487/RFC5226, May 2008, + . [RFC6546] Trammell, B., "Transport of Real-time Inter-network - Defense (RID) Messages over HTTP/TLS", RFC 6546, April - 2012. + Defense (RID) Messages over HTTP/TLS", RFC 6546, + DOI 10.17487/RFC6546, April 2012, + . -10.3. URIs +9.3. URIs [1] http://csrc.nist.gov/groups/SNS/rbac/ Appendix A. Change Tracking - Changes since -00 version, September 5, 2012 to Feb 15, 2013: - - 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 + Changes since -02 version, August 15, 2013 to December 2, 2015: - o Added new normative text recommending use of SAML2 for - authentication of interactive end users who are members of a - sharing consortium. See: Section 5.2 + o Added section specifying the use of RFC5005 for Archive and Paging + of feeds. See: Section 5.2 - o Added new normative text describing requirements for user - authorization. See: Section 5.3 + o Added section describing use of atom categories that correspond to + 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 - XACML profile. See: Appendix B + o Updated IANA Considerations section to clarify that no IANA + actions are required. Appendix B. Resource Authorization Model As described in Section 3.3.2 above, ROLIE assumes that all authorization policy enforcement is provided at the source server. The implementation details of the authorization scheme chosen by a ROLIE-compliant provider are out of scope for this specification. Implementers are free to choose any suitable authorization mechanism that is capable of fulfilling the policy enforcement requirements relevant to their consortium and/or organization. @@ -1905,25 +1911,20 @@ so on. One could also write policy to consider the CVSS score associated with the resource, or the lifecycle phase of the resource (vulnerability unverified, confirmed, patch available, etc.), and so on. Having these policies expressed in a standards-compliant and machine- readable format could improve the agility and effectiveness of a cyber security information sharing group or consortium, and enable better cyber defenses. -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 + John P. Field - EMC Corporation - 1133 Westchester Avenue - White Plains, New York + Pivotal Software, Inc. + 625 Avenue of the Americas + New York, New York USA - Phone: 914-461-3522 + Phone: (646)792-5770 Email: jfield@pivotal.io