idnits 2.17.1 draft-ietf-mile-rolie-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 28, 2017) is 2402 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1658 -- Looks like a reference, but probably isn't: '2' on line 1661 -- Looks like a reference, but probably isn't: '3' on line 1664 -- Looks like a reference, but probably isn't: '4' on line 1667 ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group J. Field 3 Internet-Draft Pivotal 4 Intended status: Standards Track S. Banghart 5 Expires: April 1, 2018 D. Waltermire 6 NIST 7 September 28, 2017 9 Resource-Oriented Lightweight Information Exchange 10 draft-ietf-mile-rolie-10 12 Abstract 14 This document defines a resource-oriented approach for security 15 automation information publication, discovery, and sharing. Using 16 this approach, producers may publish, share, and exchange 17 representations of software descriptors, security incidents, attack 18 indicators, software vulnerabilities, configuration checklists, and 19 other security automation information as web-addressable resources. 20 Furthermore, consumers and other stakeholders may access and search 21 this security information as needed, establishing a rapid and on- 22 demand information exchange network for restricted internal use or 23 public access repositories. This specification extends the Atom 24 Publishing Protocol and Atom Syndication Format to transport and 25 share security automation resource representations. 27 Contributing to this document 29 The source for this draft is being maintained on GitHub. Suggested 30 changes should be submitted as pull requests at 31 . Instructions are on that page 32 as well. Editorial changes can be managed in GitHub, but any 33 substantial issues need to be discussed on the MILE mailing list. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 1, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 4 71 3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5 73 4. Background and Motivation . . . . . . . . . . . . . . . . . . 5 74 5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 6 75 5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7 76 5.1.1. Use of the "app:workspace" Element . . . . . . . . . 7 77 5.1.2. Use of the "app:collection" Element . . . . . . . . . 8 78 5.1.3. Service Discovery . . . . . . . . . . . . . . . . . . 9 79 5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 9 80 5.3. Transport Layer Security . . . . . . . . . . . . . . . . 10 81 5.4. User Authentication and Authorization . . . . . . . . . . 11 82 5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 11 83 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 12 84 6. ROLIE Requirements for the Atom Syndication Format . . . . . 12 85 6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 12 86 6.1.1. Use of the "atom:category" Element . . . . . . . . . 13 87 6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 14 88 6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 15 89 6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 15 90 6.2.1. Use of the "atom:content" Element . . . . . . . . . . 16 91 6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 17 92 6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 17 93 6.2.4. Use of the rolie:property Element . . . . . . . . . . 18 94 6.2.5. Requirements for a Standalone Entry . . . . . . . . . 19 95 7. Available Extension Points Provided by ROLIE . . . . . . . . 20 96 7.1. The Category Extension Point . . . . . . . . . . . . . . 20 97 7.1.1. General Use of the "atom:category" Element . . . . . 21 98 7.1.2. Identification of Security Automation Information 99 Types . . . . . . . . . . . . . . . . . . . . . . . . 21 100 7.2. The "rolie:format" Extension Point . . . . . . . . . . . 22 101 7.3. The Link Relation Extension Point . . . . . . . . . . . . 23 102 7.4. The "rolie:property" Extension Point . . . . . . . . . . 23 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 104 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24 105 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25 106 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25 107 8.4. ROLIE Security Resource Information Type Sub-Registry . . 28 108 8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 110 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 114 12.2. Informative References . . . . . . . . . . . . . . . . . 34 115 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 116 Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 36 117 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 37 118 B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 37 119 B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 40 120 B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 42 121 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 43 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 124 1. Introduction 126 This document defines a resource-oriented approach to security 127 automation information sharing that follows the Representational 128 State Transfer (REST) architectural style [REST]. In this approach, 129 computer security resources are maintained in web-accessible 130 repositories structured as Atom Syndication Format [RFC4287] Feeds. 131 Within a given Feed, which may be requested by the consumer, 132 representations of specific types of security automation information 133 are organized, categorized, and described. Furthermore, all 134 collections available to a given user are discoverable, allowing the 135 consumer to search all available content they are authorized to view, 136 and to locate and request the desired information resources. Through 137 use of granular authentication and access controls, only authorized 138 consumers may be permitted the ability to read or write to a given 139 Feed. 141 The goal of this approach is to increase the communication and 142 sharing of security information between providers and consumers that 143 can be used to automate security processes (e.g., incident reports, 144 vulnerability assessments, configuration checklists, and other 145 security automation information). Such sharing allows human 146 operators and computer systems to leverage this standardized 147 communication system to gather information that supports the 148 automation of security processes. 150 To support new types of security automation information being used as 151 time goes on, this specification defines a number of extension points 152 that can be used either privately or globally. These global 153 extensions are IANA registered by ROLIE extension specifications, and 154 provide enhanced interoperability for new use cases and domains. 155 Sections 5 and 6 of this document define the core requirements of all 156 implementations of this specification, and is resource representation 157 agnostic. An overview of the extension system is provided in 158 Section 7. Implementers seeking to provide support for specific 159 security automation information types should refer to the 160 specification for that domain described by the IANA registry found in 161 section 8.4. 163 2. Terminology 165 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 166 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 The previous key words are used in this document to define the 170 conformance requirements for implementations of this specification. 171 This document does not give any recommendations for the use of ROLIE, 172 it only provides conformance requirements for implementations of this 173 specification. 175 Definitions for some of the common computer security-related 176 terminology used in this document can be found in Section 2 of 177 [RFC7970]. 179 The following terms are unique to this specification: 181 Information Type A class of security automation information having 182 one or more associated data models. Often such security 183 automation information is used in the automation of a security 184 process. See section 7.1.2 for more information. 186 3. XML-related Conventions 188 3.1. XML Namespaces 190 This specification uses XML Namespaces [W3C.REC-xml-names-20091208] 191 to uniquely identify XML element names. It uses the following 192 namespace prefix mappings for the indicated namespace URI: 194 "app" is used for the "http://www.w3.org/2007/app" namespace 195 defined in [RFC5023]. 197 "atom" is used for the "http://www.w3.org/2005/Atom" namespace 198 defined in [RFC4287]. 200 "rolie" is used for the "urn:ietf:params:xml:ns:rolie:1.0" 201 namespace defined in section 8.1 of this specification. 203 3.2. RELAX NG Compact Schema 205 Some sections of this specification are illustrated with fragments of 206 a non-normative RELAX NG Compact schema [relax-NG]. The text of this 207 specification provides the definition of conformance. Schema for the 208 "http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom" 209 namespaces appear in RFC5023 appendix B [RFC5023] and RFC4287 210 appendix B [RFC4287] respectively. 212 A complete informative RELAX NG Compact Schema for the new elements 213 introduced by ROLIE is provided in Appendix A. 215 4. Background and Motivation 217 In order to automate security process, tools need access to 218 sufficient sources of structured, security information that can be 219 used to drive security processes. Thus, security information sharing 220 is one of the core components of automating security processes. 221 Vulnerabilities, configurations, software identification, security 222 incidents, and patch data are just a few of the classes of 223 information that are shared today to enable effective security on a 224 wide scale. However, as the scale of defense broadens as networks 225 become larger and more complex, and the volume of information to 226 process makes humans-in-the-loop difficult to scale, the need for 227 automation and machine-to-machine communication becomes increasingly 228 critical. 230 ROLIE seeks to address this need by providing four major information 231 sharing benefits: 233 Extensible information type categories and format agnosticism: ROLIE 234 is not bound to any given data format or category of information. 235 Instead, information categories are extensible, and entries 236 declare the format of the referenced data. In cases where several 237 formats or serializations are available, ROLIE can use link 238 relations to communicate how a consumer can access these formats. 239 For example, clients may request that a given resource 240 representation be returned as XML, JSON, or in some other format 241 or serialization. This approach allows the provider to support 242 multiple, compatible formats allowing the consumer to select the 243 most suitable version. 245 Open and distributed information sharing: Using the Atom Publishing 246 Protocol, ROLIE feeds can easily aggregate feeds and accept 247 information POSTed to them from other sources. Webs of 248 communicating ROLIE servers form ad-hoc sharing communities, 249 increasing data availability and the ability to correlate linked 250 data across sources for participating consumers. ROLIE servers 251 needn't be distributed however, as large ROLIE repositories can 252 function as a central or federated collections. 254 Stateless communication model: ROLIE, as a RESTful system, is 255 stateless. That is, the server doesn't keep track of client 256 sessions, but rather uses link relations for state transitions. 257 In practice, this means that any consumer can find and share 258 information at any organizational level and at any time without 259 needing to execute a long series of requests. 261 Information discovery and navigation: ROLIE provides a number of 262 mechanisms to allow clients to programmatically discover and 263 navigate collections of information in order to dynamically 264 discover new or revised content. Extensible information types and 265 other categories provide one way of determining content that is 266 desirable. Link elements, each with a target URI and an 267 established relationship type, provide a means for ROLIE providers 268 to link other information that is relevant to the current entry or 269 feed. 271 These benefits result in an information sharing protocol that is 272 lightweight, interactive, open, and most importantly, machine 273 readable. 275 The requirements in this specification are broken into two major 276 sections, extensions to the Atom Publishing Protocol (AtomPub) 277 [RFC5023], and extensions to the Atom Syndication Format [RFC4287]. 278 All normative requirements in AtomPub and Atom Syndication are 279 inherited from their respective specifications, and apply here unless 280 the requirement is explicitly overridden in this document. In this 281 way, this document may upgrade the requirement (e.g., make a SHOULD a 282 MUST), but will never downgrade a given requirement (e.g., make a 283 MUST a SHOULD). 285 5. ROLIE Requirements for the Atom Publishing Protocol 287 This section describes a number of restrictions of and extensions to 288 the Atom Publishing Protocol (AtomPub) [RFC5023] that define the use 289 of that protocol in the context of a ROLIE-based solution. The 290 normative requirements in this section are generally oriented towards 291 client and server implementations. An understanding of the Atom 292 Publishing Protocol specification [RFC5023] is helpful to understand 293 the requirements in this section. 295 5.1. AtomPub Service Documents 297 As described in RFC5023 section 8 [RFC5023], a Service Document is an 298 XML-based document format that allows a client to dynamically 299 discover the Collections provided by a publisher. A Service Document 300 consists of one or more app:workspace elements that may each contain 301 a number of app:collection elements. 303 The general structure of a service document is as follows (from 304 RFC5023 section 4.2 [RFC5023]): 306 Service 307 o- Workspace 308 | | 309 | o- Collection 310 | | | 311 | | o- IRI, categories, media types 312 | | 313 | o- ... 314 | 315 o- Workspace 316 | | 317 | o- Collection 318 | | | 319 | | o- IRI, categories, media types 320 | | 321 | o- ... 322 | 323 o- ... 325 5.1.1. Use of the "app:workspace" Element 327 In AtomPub, a Workspace, represented by the "app:workspace" element, 328 describes a group of one or more Collections. Building on the 329 AtomPub concept of a Workspace, in ROLIE a Workspace represents an 330 aggregation of Collections pertaining to security automation 331 information resources. This specification does not restrict the 332 number of Workspaces that may be in a Service Document or the 333 specific Collections to be provided within a given Workspace. 335 A ROLIE implementation can host Collections containing both public 336 and private information entries. It is RECOMMENDED that 337 implementations segregate public and private Collections into 338 different app:workspace elements. By doing this, Workspaces that 339 contain private information can be ignored by clients or can be 340 omitted from the Service Document provided to a client that lacks the 341 appropriate privilege to access the set of Collections associated 342 with the Workspace. 344 5.1.2. Use of the "app:collection" Element 346 In AtomPub, a Collection in a Service Document, represented by the 347 "app:collection" element, provides metadata that can be used to point 348 to a specific Atom Feed that contains information Entries that may be 349 of interest to a client. The association between a Collection and a 350 Feed is provided by the "href" attribute of the app:collection 351 element. Building on the AtomPub concept of a Collection, in ROLIE a 352 Collection represents a pointer to a group of security automation 353 information resources pertaining to a given type of security 354 automation information. Collections are represented as Atom Feeds as 355 per RFC 5023. Atom Feed specific requirements are defined in section 356 6.1. 358 ROLIE defines specialized data requirements for Collections, Feeds, 359 and Entries containing security automation related data. The 360 difference between a ROLIE and a non-ROLIE Collection defined in a 361 Service Document can be determined as follows: 363 ROLIE Collection: For an app:collection to be considered a ROLIE 364 Collection, the app:collection MUST contain an app:categories 365 element that contains only one atom:category element with the 366 "scheme" attribute value of 367 "urn:ietf:params:rolie:category:information-type". This category 368 MUST have an appropriate "term" attribute value as defined in 369 section 7.1.1. This ensures that a given Collection corresponds 370 to a specific type of security automation information. 372 Non-ROLIE Collection: For an app:collection to be considered a non- 373 ROLIE Collection, the app:collection MUST NOT contain an 374 atom:category element with a "scheme" attribute value of 375 "urn:ietf:params:rolie:category:information-type". 377 By distinguishing between ROLIE and non-ROLIE Collections in this 378 way, implementations supporting ROLIE can host Collections pertaining 379 to security automation information alongside Collections of other 380 non-ROLIE information within the same AtomPub instance. 382 The following are additional requirements on the use of the 383 app:collection element for a ROLIE Collection: 385 o The child atom:category elements contained in the app:categories 386 element MUST be the same set of atom:category elements used in the 387 Atom Feed resource referenced by the app:collection "href" 388 attribute value. This ensures that the category metadata 389 associated with the Collection and the associated Feed is 390 discoverable in both of these resources. 392 o The app:categories element in an app:collection MAY include 393 additional atom:category elements using a scheme other than 394 "urn:ietf:params:rolie:category:information-type". This allows 395 other category metadata to be included. 397 5.1.3. Service Discovery 399 This specification requires that an implementation MUST publish an 400 Atom Service Document that describes the set of security information 401 Collections provided by the service. The Service Document MUST be 402 retrievable using the standardized URI template 403 "https://{host:port}/.well-known/rolie/servicedocument", where 404 {host:port} is the authority portion of the URI. Dereferencing this 405 URI MAY result in a redirect based on an appropriate HTTP 3xx status 406 code to direct the client to the actual Service Document. This 407 allows clients to have a well-known location to find a ROLIE service 408 document, while giving implementations flexibility over how the 409 service is deployed. 411 This document registers the "rolie/servicedocument" well-known URI as 412 per [RFC5785] in Section 8.5. 414 A mechanism to determine which host and port to use is not specified 415 in this document. Use of a mechanism such as DNS SRV Records 416 [RFC2782] can provide a secure and reliable discovery mechanism for 417 determining a specific host and port to use for retrieving a Service 418 Document for a given DNS domain. 420 5.2. AtomPub Category Documents 422 As described in RFC5023 section 7 [RFC5023], a Category Document is 423 an XML-based document format that allows a client to dynamically 424 discover the Categories used within AtomPub Service Documents, and 425 Atom Syndication Feed and Entry documents provided by a publisher. A 426 Category Document consists of one app:categories element that 427 contains a number of inline atom:category elements, or a URI 428 referencing a Category Document. 430 A ROLIE implementation MUST publish a Category Document that 431 describes the set of atom:category elements and associated terms 432 currently used by the service. 434 The Category Document MUST be retrievable using the standardized URI 435 template "https://{host:port}/.well-known/rolie/categorydocument", 436 where {host:port} is the authority portion of the URI. Dereferencing 437 this URI MAY result in a redirect based on an appropriate HTTP 3xx 438 status code to direct the client to the actual Category Document. 439 This allows clients to have a well-known location to find a ROLIE 440 category document, while giving implementations flexibility over how 441 the service is deployed. 443 This document registers the "rolie/categorydocument" well-known URI 444 as per [RFC5785] in Section 8.5. 446 5.3. Transport Layer Security 448 ROLIE is intended to be handled with TLS. The following requirements 449 have been in part derived from [RFC7589]. 451 TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented 452 according to all recommendations and best practices present in 453 [RFC7525]. 455 It is RECOMMENDED that the most recent published version of TLS is 456 supported. If this version is TLS 1.3 [I-D.ietf-tls-tls13], it is 457 recommended that 0-RTT (Zero Round Trip Time Resumption) is not used, 458 as there is a replay attack that is possible with that option. 460 The server MUST support certificate-based client authentication. An 461 implementation MUST support the set of TLS cipher suites that are 462 REQUIRED by the latest published version of the TLS specification. 463 An implementation MUST also support the TLS cipher suites that 464 provide support for mutual authentication of clients and servers. 466 During the TLS negotiation, the client MUST carefully examine the 467 certificate presented by the server to determine if it meets the 468 client's expectations. Particularly, the client MUST check its 469 understanding of the server hostname against the server's identity as 470 presented in the server Certificate message, in order to prevent man- 471 in-the-middle attacks. Matching is performed according to the rules 472 laid out in the Security Considerations section of [RFC4642]. If the 473 match fails, the client MUST either ask for explicit user 474 confirmation or terminate the connection and indicate the server's 475 identity is suspect. If the client has external information as to 476 the expected identity of the server, the hostname check MAY be 477 omitted. 479 Clients MUST verify the binding between the identity of the servers 480 to which they connect and the public keys presented by those servers. 482 Client implementations SHOULD support a certificate validation 483 approach based on section 6 of [RFC5280]. 485 The server MUST be capable of verifying the identity of the client 486 with certificate-based authentication according to local policy to 487 ensure that the incoming client request is legitimate before any 488 configuration or state data is sent to or received from the client. 490 5.4. User Authentication and Authorization 492 Implementations MUST support user authentication. However, a given 493 implementation MAY allow user authentication to be disabled on a feed 494 by feed basis. 496 Servers participating in an information sharing consortium and 497 supporting interactive user logins by members of the consortium 498 SHOULD support client authentication via a federated identity scheme. 500 This document does not mandate the use of any specific user 501 authorization mechanisms. However, service implementers SHOULD 502 provide appropriate authorization checking for all resource accesses, 503 including individual Atom Entries, Atom Feeds, and Atom Service 504 Documents. 506 5.5. / (forward slash) Resource URL 508 The "/" resource MAY be supported for compatibility with existing 509 deployments that are using Transport of Real-time Inter-network 510 Defense (RID) Messages over HTTP/TLS [RFC6546]. 512 The following additional requirements apply for implementations 513 supporting handling of the "/" resource:: 515 o Consistent with RFC6546 errata, a client requesting a GET on the 516 "/" resource SHOULD receive an HTTP status code 405 Method Not 517 Allowed. 519 o An implementation MAY provide full support for [RFC6546] such that 520 a POST to the "/" resource containing a recognized RID message is 521 handled correctly as a RID request. Alternatively, a client 522 requesting a POST to "/" MAY receive an HTTP status code 307 523 Temporary Redirect. In this case, the location header in the HTTP 524 response will provide the URL of the appropriate RID endpoint, and 525 the client may repeat the POST method at the indicated location. 527 If the "/" resource is unsupported, then a request for this resource 528 MUST provide a 404 HTTP status code. 530 5.6. HTTP methods 532 Servers MAY accept request methods beyond those specified in this 533 document. 535 Clients MUST be capable of recognizing and processing any standard 536 HTTP status code, as defined in [RFC5023] Section 5. 538 6. ROLIE Requirements for the Atom Syndication Format 540 This section describes a number of restrictions of and extensions to 541 the Atom Syndication Format [RFC4287] that define the use of that 542 format in the context of a ROLIE-based solution. The normative 543 requirements in this section are generally oriented towards any 544 content to be published to a ROLIE server. An understanding of the 545 Atom Syndication Format specification [RFC4287] is helpful to 546 understand the requirements in this section. 548 6.1. Use of the "atom:feed" element 550 As described in RFC4287 section 4.1.1 [RFC4287], an Atom Feed is an 551 XML-based document format that describes a list of related 552 information items. The list of Atom Feeds provided by a ROLIE 553 service are listed in the service's Service Document through one or 554 more app:collection elements. Each Feed document, represented using 555 the atom:feed element, contains a listing of zero or more Entries. 557 When applied to the problem domain of security automation information 558 sharing, an Atom Feed may be used to represent any meaningful 559 collection of security automation information resources. Each Entry 560 in an atom:feed represents an individual resource (e.g., a specific 561 checklist, a software vulnerability record). Additional Feeds can be 562 used to represent other collections of security automation resources. 564 As discussed in section 5.1.2, ROLIE defines specialized data 565 requirements for Feeds containing security automation related data. 566 The difference between a ROLIE and a non-ROLIE Feed can be determined 567 as follows: 569 ROLIE Feed: For an atom:feed to be considered a ROLIE Feed, the 570 atom:feed MUST contain only one child atom:category element with 571 the "scheme" attribute value of 572 "urn:ietf:params:rolie:category:information-type". This category 573 MUST have an appropriate "term" attribute value as defined in 574 section 7.1.1. This ensures that a given Feed corresponds to a 575 specific type of security automation information. 577 Non-ROLIE Feed: For an atom:feed to be considered a non-ROLIE Feed, 578 the atom:feed MUST NOT contain an atom:category element with a 579 "scheme" attribute value of 580 "urn:ietf:params:rolie:category:information-type". 582 By distinguishing between ROLIE and non-ROLIE Feeds in this way, 583 implementations supporting ROLIE can host Feeds pertaining to 584 security automation information alongside Feeds of other non-ROLIE 585 information within the same AtomPub instance. This is parallel to 586 the handling of collections ealier in this specification in section 587 5.1.2. 589 The following Atom Feed definition represents a stricter definition 590 of the atom:feed element defined in RFC 4287 when used as a ROLIE 591 Feed. Any element not specified here inherits its definition and 592 requirements from [RFC4287]. 594 atomFeed = 595 element atom:feed { 596 atomCommonAttributes, 597 (atomAuthor* 598 & atomCategory+ 599 & atomContributor* 600 & atomGenerator? 601 & atomIcon? 602 & atomId 603 & atomLink+ 604 & atomLogo? 605 & atomRights? 606 & atomSubtitle? 607 & atomTitle 608 & atomUpdated 609 & extensionElement*), 610 atomEntry* 611 } 613 The following subsections contain requirements for a ROLIE Feed. 615 6.1.1. Use of the "atom:category" Element 617 An atom:feed can contain zero or more atom:category elements. In 618 Atom the naming scheme and the semantic meaning of the terms used to 619 identify an Atom category are application-defined. 621 The following are additional requirements on the use of the 622 atom:category element when used in a ROLIE Feed: 624 o All member Entries in the Feed MUST represent security automation 625 information records of the provided information type category. 627 o An atom:feed MAY include additional atom:category elements using a 628 scheme other than "urn:ietf:params:rolie:category:information- 629 type". This allows other category metadata to be included. 631 6.1.2. Use of the "atom:link" Element 633 Link relations defined by the atom:link element are used to represent 634 state transitions using a stateless approach. In Atom a type of link 635 relationship can be defined using the "rel" attribute. 637 A ROLIE atom:feed MUST contain one or more atom:link elements with 638 rel="service" and href attribute whose value is a IRI that points to 639 an Atom Service Document associated with the atom:feed. If a client 640 accesses a Feed without first accessing the service's service 641 document, a link with the "service" relationship provides a means to 642 discover additional security automation information. The "service" 643 link relationship is defined in the IANA Link Relations Registry [1]. 645 An atom:feed can contain an arbitrary number of Entries. In some 646 cases, a complete Feed may consist of a large number of Entries. 647 Additionally, as new and updated Entries are ordered at the beginning 648 of a Feed, a client may only be interested in retrieving the first N 649 entries in a Feed to process only the Entries that have changed since 650 the last retrieval of the Feed. As a practical matter, a large set 651 of Entries will likely need to be divided into more manageable 652 portions, or pages. Based on RFC5005 section 3 [RFC5005], link 653 elements SHOULD be included in all Feeds to support paging using the 654 following link relation types: 656 o "first" - Indicates that the href attribute value of the link 657 identifies a resource IRI for the furthest preceding page of the 658 Feed. 660 o "last" - Indicates that the href attribute value of the link 661 identifies a resource IRI for the furthest following page of the 662 Feed. 664 o "previous" - Indicates that the href attribute value of the link 665 identifies a resource IRI for the immediately preceding page of 666 the Feed. 668 o "next" - Indicates that the href attribute value of the link 669 identifies a resource IRI for the immediately following page of 670 the Feed. 672 For example: 674 675 676 b7f65304-b63b-4246-88e2-c104049c5fd7 677 Paged Feed 678 679 680 681 682 683 2012-05-04T18:13:51.0Z 685 686 688 Example Paged Feed 690 A reference to a historical Feed may need to be stable, and/or a Feed 691 may need to be divided into a series of defined epochs. 692 Implementations SHOULD support the mechanisms described in RFC5005 693 section 4 [RFC5005] to provide link-based state transitions for 694 maintaining archiving of Feeds. 696 An atom:feed MAY include additional link relationships not specified 697 in this document. If a client encounters an unknown link 698 relationship type, the client MUST ignore the unrecognized link and 699 continue processing as if the unrecognized link element did not 700 appear. The definition of new Link relations that provide additional 701 state transition extensions is discussed in section 7.3. 703 6.1.3. Use of the "atom:updated" Element 705 The atom:updated element identifies the date and time that an Entry 706 was last updated. 708 The atom:updated element MUST be populated with the current time at 709 the instant the Feed representation was last updated by adding, 710 updating, or deleting an Entry; or changing any metadata for the 711 Feed. 713 6.2. Use of the "atom:entry" Element 715 Each Entry in an Atom Feed, represented by the atom:entry element, 716 describes a single referenced information record, along with 717 descriptive information about its format, media type, and other 718 publication metadata. The following atom:entry schema definition 719 represents a stricter representation of the atom:entry element 720 defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in 721 section 6.1.1. 723 atomEntry = 724 element atom:entry { 725 atomCommonAttributes, 726 (atomAuthor* 727 & atomCategory* 728 & atomContent 729 & atomContributor* 730 & atomId 731 & atomLink* 732 & atomPublished? 733 & atomRights? 734 & atomSource? 735 & atomSummary? 736 & atomTitle 737 & atomUpdated 738 & rolieFormat 739 & rolieProperty* 740 & extensionElement*) 741 } 743 The following subsections contain requirements for Entries in a ROLIE 744 Feed. 746 6.2.1. Use of the "atom:content" Element 748 An atom:content element associates its containing Entry with a 749 content resource identified by the src attribute. 751 There MUST be exactly one atom:content element in the Entry. The 752 content element MUST adhere to this definition, which is a stricter 753 representation of the atom:content element defined in [RFC4287]: 755 atomContent = 756 element atom:content { 757 atomCommonAttributes, 758 attribute type { atomMediaType }, 759 attribute src { atomUri }, 760 empty 761 } 763 The type attribute MUST identify the serialization type of the 764 content, for example, application/xml or application/json. A 765 prefixed media type MAY be used to reflect a specific model used with 766 a given serialization approach (e.g., application/rdf+xml). The src 767 attribute MUST be an IRI that can be dereferenced to retrieve the 768 related content data. 770 6.2.2. Use of the "atom:link" Element 772 Link relations can be included in an atom:entry to represent state 773 transitions for the Entry. 775 If there is a need to provide the same information in different data 776 models and/or serialization formats, separate Entry instances can be 777 included in the same or a different Feed. Such an alternate content 778 representation can be indicated using an atom:link having a rel 779 attribute with the value "alternate". 781 An atom:feed MAY include additional link relationships not specified 782 in this document. If a client encounters an unknown link 783 relationship type, the client MUST ignore the unrecognized link and 784 continue processing as if the unrecognized link element did not 785 appear. The definition of new Link relations that provide additional 786 state transition extensions is discussed in section 7.3. 788 6.2.3. Use of the "rolie:format" Element 790 As mentioned earlier, a key goal of this specification is to allow a 791 consumer to review a set of published security automation information 792 resources, and then identify and retrieve any resources of interest. 793 The format of the data is a key criteria to consider when deciding 794 what information to retrieve. For a given type of security 795 automation information, it is expected that a number of different 796 formats may be used to represent this information. To support this 797 use case, both the serialization format and the specific data model 798 expressed in that format must be known by the consumer. 800 The rolie:format element is used to describe the data model used to 801 express the information referenced in the atom:content element of an 802 atom:entry. It also allows a schema to be identified that can be 803 used when parsing the content to verify or better understand the 804 structure of the content. 806 There MUST be exactly one rolie:format element in an atom:entry. The 807 element MUST adhere to this definition: 809 rolieFormat = 810 element rolie:format { 811 appCommonAttributes, 812 attribute ns { atomURI }, 813 attribute version { text } ?, 814 attribute schema-location { atomURI } ?, 815 attribute schema-type { atomMediaType } ?, 816 empty 817 } 819 The rolie:format element MUST provide a "ns" attribute that 820 identifies the data model of the resource referenced by the 821 atom:content element. For example, the namespace used may be an XML 822 namespace URI, or an identifier that represents a serialized JSON 823 model. The URI used for the "ns" attribute value MUST be an absolute 824 or opaque URI. The resource identified by the URI need not be 825 resolvable. 827 The rolie:format element MAY provide a "version" attribute that 828 identifies the version of the format used for the related 829 atom:content. 831 The rolie:format element MAY provide a "schema-location" attribute 832 that is a URI that identifies a schema resource that can be used to 833 validate the related atom:content. 835 The rolie:format element MAY provide a "schema-type" attribute, which 836 is a mime type identifying the format of the schema resource 837 identified by the "schema-location" attribute. 839 The following nominal example shows how these attributes describe the 840 format of the content: 842 848 The previous element provides an indication that the content of the 849 given entry is using the IODEF v2 format. 851 6.2.4. Use of the rolie:property Element 853 An atom:category element provides a way to associate a name/value 854 pair of categorical information using the scheme and term attributes 855 to represent the name, and the label attribute to represent the 856 value. When used in this way an atom:category allows a specific 857 label to be selected from a finite set of possible label values that 858 can be used to further classify a given atom:entry or atom:feed. 859 Within ROLIE, there may be a need to associate additional metadata 860 with an atom:entry. In such a case, use of an atom:category is not 861 practical to represent name/value data for which the allowed values 862 are unbounded. Instead, ROLIE has introduced a new rolie:property 863 element that can represent non-categorical metadata as name/value 864 pairs. Examples include content-specific identifiers, naming data, 865 and other properties that allow for unbounded values. 867 There MAY be zero or more rolie:property elements in an atom:entry. 869 The element MUST adhere to this definition: 871 rolieProperty = 872 element rolie:property { 873 app:appCommonAttributes, 874 attribute name { atom:atomURI }, 875 attribute value { text } 876 empty 877 } 879 The name attribute provides a URI that identifies the namespace and 880 name of the property as a URI. 882 The value attribute is text that provides a value for the property 883 identified by the name attribute. 885 For example, the nominal element 887 would expose an IODEF ID value contained in a given entry's content. 888 The name used in the example also demonstrates the use of a 889 registered ROLIE property extension, which is described in 890 Section 7.4. 892 Implementations MAY use locally defined and namespaced elements in an 893 Entry in order to provide additional information. Clients that do 894 not recognize a property with an unregistered name attribute MAY 895 ignore the rolie:property. 897 6.2.5. Requirements for a Standalone Entry 899 If an Entry is ever shared as a standalone resource, separate from 900 its containing Feed, then the following additional requirements 901 apply: 903 o The Entry MUST have an atom:link element with rel="collection" and 904 href="[IRI of the containing Collection]". This allows the Feed 905 or Feeds for which the Entry is a member to be discovered, along 906 with the related information the Feed may contain. In the case of 907 the Entry have multiple containing Feeds, the Entry MUST have one 908 atom:link for each related Feed. 910 o The Entry MUST declare the information type of the content 911 resource referenced by the Entry (see Section 7.1.2). 913 7. Available Extension Points Provided by ROLIE 915 This specification does not require particular information types or 916 data formats; rather, ROLIE is intended to be extended by additional 917 specifications that define the use of new categories and link 918 relations. The primary point of extension is through the definition 919 of new information type category terms. Additional specifications 920 can register new information type category terms with IANA that serve 921 as the main characterizing feature of a ROLIE Collection/Feed or 922 Resource/Entry. These additional specifications defining new 923 information type terms, can describe additional requirements for 924 including specific categories, link relations, as well as, use of 925 specific data formats supporting a given information type term. 927 7.1. The Category Extension Point 929 The atom:category element, defined in RFC 4287 section 4.2.2 930 [RFC4287], provides a mechanism to provide additional categorization 931 information for a content resource in ROLIE. The ability to define 932 new categories is one of the core extension points provided by Atom. 933 A Category Document, defined in RFC 5023 section 7 [RFC5023], 934 provides a mechanism for an Atom implementation to make discoverable 935 the atom:category terms and associated allowed values. 937 ROLIE further defines the use of the existing Atom extension category 938 mechanism by allowing ROLIE specific category extensions to be 939 registered with IANA, and additionally has assigned the 940 "urn:ietf:params:rolie:category:information-type" category scheme 941 that has special meaning for implementations of ROLIE. This allows 942 category scheme namespaces to be managed in a more consistent way, 943 allowing for greater interoperability between content producers and 944 consumers. 946 The namespace "urn:ietf:params:rolie:category:local" has been 947 reserved in the IANA ROLIE Parameters table for private use as 948 defined in [RFC8126]. Any category whose "scheme" attribute uses 949 this as a prefix MUST be considered private use. Implementations 950 encountering such a category MUST parse the content without error, 951 but MAY otherwise ignore the element. 953 Use of the "atom:category" element is discussed in the following 954 subsections. 956 7.1.1. General Use of the "atom:category" Element 958 The atom:category element can be used for characterizing a ROLIE 959 Resource. As discussed earlier in this document, an atom:category 960 element has a "term" attribute that indicates the assigned category 961 value, and a "scheme" attribute that provides an identifier for the 962 category type. The "scheme" provides a means to describe how a set 963 of category terms should be used and provides a namespace that can be 964 used to differentiate terms provided by multiple organizations with 965 different semantic meaning. 967 To further differentiate category types used in ROLIE, an IANA sub- 968 registry has been established for ROLIE protocol parameters to 969 support the registration of new category "scheme" attribute values by 970 ROLIE extension specifications. Use of this extension point is 971 discussed in section 8.3 using the name field with a type parameter 972 of "category" to indicate a category extension. 974 7.1.2. Identification of Security Automation Information Types 976 A ROLIE specific extension point is provided through the 977 atom:category "scheme" value 978 "urn:ietf:params:rolie:category:information-type". This value is a 979 Uniform Resource Name (URN) [RFC8141] that is registered with IANA as 980 described in section 8.3. When used as the "scheme" attribute in 981 this way, the "term" attribute is expected to be a registered value 982 as defined in section Section 8.4. Through this mechanism a given 983 security automation information type can be used to: 985 1. identify that an "app:collection" element in a Service Document 986 points to an Atom Feed that contains Entries pertaining to a 987 specific type of security automation information (see section 988 5.1.2), or 990 2. identify that an "atom:feed" element in an Atom Feed contains 991 Entries pertaining to a specific type of security automation 992 information (see section 6.1.1). 994 3. identify the information type of a standalone Resource (see 995 section 6.2.5). 997 For example, the notional security automation information type 998 "incident" would be identified as follows: 1000 1004 A security automation information type represents a class of 1005 information that represents the same or similar information model 1006 [RFC3444]. Notional examples of information types include: 1008 indicator: Computing device- or network-related "observable features 1009 and phenomenon that aid in the forensic or proactive detection of 1010 malicious activity; and associated meta-data" (from [RFC7970]). 1012 incident: Information pertaining to and "derived analysis from 1013 security incidents" (from [RFC7970]). 1015 vulnerability reports: Information identifying and describing a 1016 vulnerability in hardware or software. 1018 configuration checklists: Content that can be used to assess the 1019 configuration settings related to installed software. 1021 software tags: Metadata used to identify and characterize 1022 installable software. 1024 This is a short list to inspire new engineering of information type 1025 extensions that support the automation of security processes. 1027 This document does not specify any information types. Instead, 1028 information types in ROLIE are expected to be registered in extension 1029 documents that describe one or more new information types. This 1030 allows the information types used by ROLIE implementations to grow 1031 over time to support new security automation use cases. These 1032 extension documents may also enhance ROLIE Service, Category, Feed, 1033 and Entry documents by defining link relations, other categories, and 1034 Format data model extensions to address the representational needs of 1035 these specific information types. New information types are added to 1036 ROLIE through registrations to the IANA ROLIE Security Resource 1037 Information Type registry defined in section 8.4. 1039 7.2. The "rolie:format" Extension Point 1041 Security automation data pertaining to a given information type may 1042 be expressed using a number of supported formats. As described in 1043 section 6.2.3, the rolie:format element is used to describe the 1044 specific data model used to represent the resource referenced by a 1045 given "atom:entry". The structure provided by the rolie:format 1046 element, provides a mechanism for extension within the atom:entry 1047 model. ROLIE extensions MAY further restrict which data models are 1048 allowed to be used for a given information type. 1050 By declaring the data model used for a given Resource, a consumer can 1051 choose to download or ignore the Resource, or look for alternate 1052 formats. This saves the consumer from downloading and parsing 1053 resources that the consumer is not interested in or resources 1054 expressed in formats that are not supported by the consumer. 1056 7.3. The Link Relation Extension Point 1058 This document uses several link relations defined in the IANA Link 1059 Relation Types registry [2]. Additional link relations can be 1060 registered in this registry to allow new relationships to be 1061 represented in ROLIE according to RFC 4287 section 4.2.7.2 [RFC4287]. 1062 Based on the preceding reference, if the link relation is too 1063 specific or limited in the intended use, an absolute IRI can be used 1064 in lieu of registering a new simple name with IANA. 1066 7.4. The "rolie:property" Extension Point 1068 As discussed previously in Section 6.2.4, many formats contain unique 1069 identifying and characterizing properties that are vital for sharing 1070 information. In order to provide a global reference for these 1071 properties, this document establishes an IANA registry in Section 8.3 1072 that allows ROLIE extensions to register named properties using the 1073 name field with a type parameter of "property" to indicate a property 1074 extension. Implementations SHOULD prefer the use of registered 1075 properties over implementation specific properties when possible. 1077 ROLIE extensions are expected to register new and use existing 1078 properties to provide valuable identifying and characterizing 1079 information for a given information type and/or format. 1081 The namespace "urn:ietf:params:rolie:property:local" has been 1082 reserved in the IANA ROLIE Parameters table for private use as 1083 defined in [RFC8126]. Any property whose "name" attribute uses this 1084 as a prefix MUST be considered private use. Implementations 1085 encountering such a property MUST parse the content without error, 1086 but MAY otherwise ignore the element. 1088 This document also registers a number of general use properties that 1089 can be used to expose content information in any ROLIE use case. The 1090 following are descriptions of how to use these registered properties: 1092 urn:ietf:params:rolie:property:content-author-name The "value" 1093 attribute of this property is a text representation indicating the 1094 individual or organization that authored the content referenced by 1095 the "src" attribute of the entry's atom:content element. 1097 urn:ietf:params:rolie:property:content-id The "value" attribute of 1098 this property is a text representation of an identifier pertaining 1099 to or extracted from the content referenced by the "src" attribute 1100 of the entry's atom:content element. 1102 urn:ietf:params:rolie:property:content-published-date The "value" 1103 attribute of this property is a text representation indicating the 1104 original publication date of the content referenced by the "src" 1105 attribute of the entry's atom:content element. This date may 1106 differ from the published date of the ROLIE Entry because 1107 publication of the content and the ROLIE Entry represent different 1108 events. The date MUST be formatted as specified in [RFC3339]. 1110 urn:ietf:params:rolie:property:content-updated-date The "value" 1111 attribute of this property is a text representation indicating the 1112 date that the content, referenced by the "src" attribute of the 1113 entry's atom:content element, was last updated. This date may 1114 differ from the updated date of the ROLIE Entry because updates 1115 made to the content and to the ROLIE Entry are different events. 1116 The date MUST be formatted as specified in [RFC3339]. 1118 8. IANA Considerations 1120 This document has a number of IANA considerations described in the 1121 following subsections. 1123 8.1. XML Namespaces and Schema URNs 1125 This document uses URNs to describe XML namespaces and XML schemas 1126 conforming to a registry mechanism described in [RFC3688]. 1128 ROLIE XML Namespace The ROLIE namespace (rolie-1.0) has been 1129 registered in the "ns" registry. 1131 URI: urn:ietf:params:xml:ns:rolie-1.0 1133 Registrant Contact: IESG 1135 XML: None. Namespace URIs do not represent an XML specification. 1137 ROLIE XML Schema The ROLIE schema (rolie-1.0) has been registered in 1138 the "schema" registry. 1140 URI: urn:ietf:params:xml:schema:rolie-1.0 1141 Registrant Contact: IESG 1143 XML: See section A of this document. 1145 8.2. ROLIE URN Sub-namespace 1147 IANA has added an entry to the "IETF URN Sub-namespace for Registered 1148 Protocol Parameter Identifiers" registry located at 1149 as per 1150 RFC3553 [RFC3553]. 1152 The entry is as follows: 1154 Registry name: rolie 1156 Specification: This document 1158 Repository: ROLIE URN Parameters. See Section 8.3 [TO BE REMOVED: 1159 This registration should take place at the following location: 1160 https://www.iana.org/assignments/rolie] 1162 Index value: See Section 8.3 1164 8.3. ROLIE URN Parameters 1166 A new top-level registry has been created, entitled "Resource 1167 Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO 1168 BE REMOVED: This registration should take place at the following 1169 location: https://www.iana.org/assignments/rolie] 1171 In this top-level registry, a sub-registry entitled "ROLIE URN 1172 Parameters" has been created. Registration in this repository is via 1173 the Specification Required policy [RFC8126]. Designated Expert 1174 reviews should be routed through the MILE WG mailing list. Failing 1175 this, the Designated Expert will be assigned by the IESG. 1177 Each entry in this sub-registry must record the following fields: 1179 Name: A URN segment that adheres to the pattern {type}:{label}. 1180 The keywords are defined as follows: 1182 {type}: The parameter type. The allowed values are "category" 1183 or "property". "category" denotes a category extension as 1184 discussed in Section 7.1. "property" denotes a property 1185 extension as discussed in Section 7.4. 1187 {label}: A required US-ASCII string that conforms to the URN 1188 syntax requirements (see [RFC8141]). This string must be 1189 unique within the namespace defined by the {type} keyword. The 1190 "local" label for both the "category" and "property" types has 1191 been reserved for private use. 1193 Extension IRI: The identifier to use within ROLIE, which is the 1194 full URN using the form: urn:ietf:params:rolie:{name}, where 1195 {name} is the "name" field of this registration. 1197 Reference: A static link to the specification and section that the 1198 definition of the parameter can be found. 1200 Sub-registry: An optional field that links to an IANA sub-registry 1201 for this parameter. If the {type} is "category", the sub-registry 1202 must contain a "name" field whose registered values MUST be US- 1203 ASCII. The list of names are the allowed values of the "term" 1204 attribute in the atom:category element. (See Section 7.1.2). 1206 This repository has the following initial values: 1208 +------------+--------------------+-------+-------------------------+ 1209 | Name | Extension IRI | Refer | Sub-Registry | 1210 | | | ence | | 1211 +------------+--------------------+-------+-------------------------+ 1212 | category:i | urn:ietf:params:ro | This | [TO BE REMOVED: This | 1213 | nformation | lie:category | docum | registration should | 1214 | -type | :information-type | ent, | take place at the | 1215 | | | Secti | following location: htt | 1216 | | | on | ps://www.iana.org/assig | 1217 | | | 8.4 | nments/rolie/category | 1218 | | | | /information-type] | 1219 | property:l | urn:ietf:params:ro | This | None | 1220 | ocal | lie:property:local | docum | | 1221 | | | ent, | | 1222 | | | Secti | | 1223 | | | on | | 1224 | | | 7.4 | | 1225 | category:l | urn:ietf:params:ro | This | None | 1226 | ocal | lie:category:local | docum | | 1227 | | | ent, | | 1228 | | | Secti | | 1229 | | | on | | 1230 | | | 7.1 | | 1231 | property | urn:ietf:params:ro | This | None | 1232 | :content- | lie:property | docum | | 1233 | author- | :content-author- | ent, | | 1234 | name | name | Secti | | 1235 | | | on | | 1236 | | | 7.4 | | 1237 | property | urn:ietf:params:ro | This | None | 1238 | :content- | lie:property | docum | | 1239 | id | :content-id | ent, | | 1240 | | | Secti | | 1241 | | | on | | 1242 | | | 7.4 | | 1243 | property | urn:ietf:params:ro | This | None | 1244 | :content- | lie:property | docum | | 1245 | published- | :content- | ent, | | 1246 | date | published-date | Secti | | 1247 | | | on | | 1248 | | | 7.4 | | 1249 | property | urn:ietf:params:ro | This | None | 1250 | :content- | lie:property | docum | | 1251 | updated- | :content-updated- | ent, | | 1252 | date | date | Secti | | 1253 | | | on | | 1254 | | | 7.4 | | 1255 +------------+--------------------+-------+-------------------------+ 1257 8.4. ROLIE Security Resource Information Type Sub-Registry 1259 A new sub-registry has been created to store ROLIE information type 1260 values. 1262 Name of Registry: "ROLIE Information Types" 1264 Location of Registry: 1265 https://www.iana.org/assignments/rolie/category/information-type 1267 Fields to record in the registry: 1269 name: The full name of the security resource information type 1270 as a string from the printable ASCII character set [RFC0020] 1271 with individual embedded spaces allowed. The ABNF [RFC5234] 1272 syntax for this field is: 1274 1*VCHAR *(SP 1*VCHAR) 1276 index: This is an IANA-assigned positive integer that 1277 identifies the registration. The first entry added to this 1278 registry uses the value 1, and this value is incremented for 1279 each subsequent entry added to the registry. 1281 reference: A list of one or more URIs [RFC3986] from which the 1282 registered specification can be obtained. The registered 1283 specification MUST be readily and publicly available from that 1284 URI. The URI SHOULD be a stable reference. 1286 Allocation Policy: Specification required as per [RFC8126] 1288 8.5. Well-Known URI Registrations 1290 This document makes the follow two registrations to the Well-Known 1291 URI Registry at https://www.iana.org/assignments/well-known-uris/ 1292 well-known-uris.xhtml. 1294 Service Document registration: 1296 URI suffix: rolie/servicedocument 1298 Change controller: IETF 1300 Specification document: This document, Section 5.1.3 1302 Related information: None 1304 Category Document registration: 1306 URI suffix: rolie/categorydocument 1308 Change controller: IETF 1310 Specification document: This document, Section 5.2 1312 Related information: None 1314 9. Security Considerations 1316 This document defines a resource-oriented approach for lightweight 1317 information exchange using HTTP over TLS, the Atom Syndication 1318 Format, and the Atom Publishing Protocol. As such, implementers must 1319 understand the security considerations described in those 1320 specifications. All that follows is guidance, more specific 1321 instruction is out of scope for this document. 1323 To protect the confidentiality of a given resource provided by a 1324 ROLIE implementation, requests for retrieval of the resource need to 1325 be authenticated to prevent unauthorized users from accessing the 1326 resource (see section 5.4). It can also be useful to log and audit 1327 access to sensitive resources to verify that proper access controls 1328 remain in place over time. 1330 The approach described herein is based upon all policy enforcements 1331 being implemented at the point when a resource representation is 1332 created. As such, producers sharing cyber security information using 1333 this specification must take care to authenticate their HTTP clients 1334 using a suitably strong user authentication mechanism. Sharing 1335 communities that are exchanging information on well-known indicators 1336 and incidents for purposes of public education may choose to rely 1337 upon HTTP Authentication or similar. A number of authentication 1338 schemes are defined in the HTTP Authentication Schemes Registry [3]. 1339 Of these, HOBA [RFC7486] and SCRAM-SHA-256 [RFC7804] provide improved 1340 security properties over HTTP Basic [RFC7617]and Digest [RFC7616] 1341 Authentication Schemes. However, sharing communities that are 1342 engaged in sensitive collaborative analysis and/or operational 1343 response for indicators and incidents targeting high value 1344 information systems should adopt a suitably stronger user 1345 authentication solution, such as a risk-based or multi-factor 1346 approach. In general, trust in the sharing consortium will depend 1347 upon the members maintaining adequate user authentication mechanisms. 1349 Collaborating consortiums may benefit from the adoption of a 1350 federated identity solution, such as those based upon OAuth [RFC6749] 1351 with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind], 1352 and SAML-prof [SAML-prof] for Web-based authentication and cross- 1353 organizational single sign-on. Dependency on a trusted third party 1354 identity provider implies that appropriate care must be exercised to 1355 sufficiently secure the Identity provider. Any attacks on the 1356 federated identity system would present a risk to the consortium, as 1357 a relying party. Potential mitigations include deployment of a 1358 federation-aware identity provider that is under the control of the 1359 information sharing consortium, with suitably stringent technical and 1360 management controls. 1362 Authorization of resource representations is the responsibility of 1363 the source system, i.e. based on the authenticated user identity 1364 associated with an HTTP(S) request. The required authorization 1365 policies that are to be enforced must therefore be managed by the 1366 security administrators of the source system. Various authorization 1367 architectures would be suitable for this purpose, such as RBAC [4] 1368 and/or ABAC, as embodied in XACML [XACML]. In particular, 1369 implementers adopting XACML may benefit from the capability to 1370 represent their authorization policies in a standardized, 1371 interoperable format. Note that implementers are free to choose any 1372 suitable authorization mechanism that is capable of fulfilling the 1373 policy enforcement requirements relevant to their consortium and/or 1374 organization. 1376 Additional security requirements such as enforcing message-level 1377 security at the destination system could supplement the security 1378 enforcements performed at the source system, however these 1379 destination-provided policy enforcements are out of scope for this 1380 specification. Implementers requiring this capability should 1381 consider leveraging, e.g. the element in the RID schema. 1382 Refer to RFC6545 section 9 for more information. Additionally, the 1383 underlying serialization approach used in the message (e.g., XML, 1384 JSON) can offer encryption and message authentication capabilities. 1385 For example, XMLDSig [RFC3275] for XML, and JSON Web Encryption 1386 [RFC7516] and JSON Web Signature[RFC7515] for JSON can provide such 1387 mechanisms. 1389 When security policies relevant to the source system are to be 1390 enforced at both the source and destination systems, implementers 1391 must take care to avoid unintended interactions of the separately 1392 enforced policies. Potential risks will include unintended denial of 1393 service and/or unintended information leakage. These problems may be 1394 mitigated by avoiding any dependence upon enforcements performed at 1395 the destination system. When distributed enforcement is unavoidable, 1396 the usage of a standard language (e.g. XACML) for the expression of 1397 authorization policies will enable the source and destination systems 1398 to better coordinate and align their respective policy expressions. 1400 A service discovery mechanism is not explicitly specified in this 1401 document, and there are several approaches available for 1402 implementers. When selecting this mechanism, implementations need to 1403 ensure that their choice provides a means for authenticating the 1404 server. As described in the discovery section, DNS SRV Records are a 1405 possible secure solution to discovery. 1407 10. Privacy Considerations 1409 The optional author field may provide an identification privacy issue 1410 if populated without the author's consent. This information may 1411 become public if posted to a public feed. Special care should be 1412 taken when aggregating or sharing entries from other feeds, or when 1413 programmatically generating ROLIE entries from some data source that 1414 the author's personal info is not shared without their consent. 1416 When using the Atom Publishing Protocol to POST entries to a feed, 1417 attackers may use correlating techniques to profile the user. The 1418 request time can be compared to the generated "updated" field of the 1419 entry in order to build out information about a given user. This 1420 correlation attempt can be mitigated by not using HTTP requests to 1421 POST entries when profiling is a risk, and rather use backend control 1422 of the feeds. 1424 Adoption of the information sharing approach described in this 1425 document will enable users to more easily perform correlations across 1426 separate, and potentially unrelated, cyber security information 1427 providers. A client may succeed in assembling a data set that would 1428 not have been permitted within the context of the authorization 1429 policies of either provider when considered individually. Thus, 1430 providers may face a risk of an attacker obtaining an access that 1431 constitutes an undetected separation of duties (SOD) violation. It 1432 is important to note that this risk is not unique to this 1433 specification, and a similar potential for abuse exists with any 1434 other cyber security information sharing protocol. However, the wide 1435 availability of tools for HTTP clients and Atom Feed handling implies 1436 that the resources and technical skills required for a successful 1437 exploit may be less than it was previously. This risk can be best 1438 mitigated through appropriate vetting of the client at account 1439 provisioning time. In addition, any increase in the risk of this 1440 type of abuse should be offset by the corresponding increase in 1441 effectiveness that this specification affords to the defenders. 1443 Proper usage of TLS as described in Section 5.3 will in many cases 1444 aid in the mitigation of these issues. 1446 Overall, ROLIE introduces few privacy concerns above and beyond those 1447 present in any other HTTP protocol. Those that exist can be 1448 mitigated by following security considerations and carefully using 1449 the optional identifying elements. 1451 11. Acknowledgements 1453 The authors gratefully acknowledge the valuable contributions of Tom 1454 Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These 1455 individuals provided detailed review comments on earlier drafts, and 1456 made many suggestions that have helped to improve this document. 1458 The authors would also like to thank the MILE Working Group, the SACM 1459 Working Group, and countless other people from both within the IETF 1460 community and outside of it for their excellent review and effort 1461 towards constructing this draft. 1463 12. References 1465 12.1. Normative References 1467 [relax-NG] 1468 Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002, 1469 . 1472 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 1473 RFC 20, DOI 10.17487/RFC0020, October 1969, 1474 . 1476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1477 Requirement Levels", BCP 14, RFC 2119, 1478 DOI 10.17487/RFC2119, March 1997, 1479 . 1481 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1482 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1483 . 1485 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1486 IETF URN Sub-namespace for Registered Protocol 1487 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1488 2003, . 1490 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1491 DOI 10.17487/RFC3688, January 2004, 1492 . 1494 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1495 Resource Identifier (URI): Generic Syntax", STD 66, 1496 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1497 . 1499 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1500 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 1501 December 2005, . 1503 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 1504 Transport Layer Security (TLS) with Network News Transfer 1505 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 1506 2006, . 1508 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 1509 DOI 10.17487/RFC5005, September 2007, 1510 . 1512 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 1513 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 1514 October 2007, . 1516 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1517 Housley, R., and W. Polk, "Internet X.509 Public Key 1518 Infrastructure Certificate and Certificate Revocation List 1519 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1520 . 1522 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1523 Uniform Resource Identifiers (URIs)", RFC 5785, 1524 DOI 10.17487/RFC5785, April 2010, 1525 . 1527 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 1528 Defense (RID) Messages over HTTP/TLS", RFC 6546, 1529 DOI 10.17487/RFC6546, April 2012, 1530 . 1532 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1533 "Recommendations for Secure Use of Transport Layer 1534 Security (TLS) and Datagram Transport Layer Security 1535 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1536 2015, . 1538 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1539 NETCONF Protocol over Transport Layer Security (TLS) with 1540 Mutual X.509 Authentication", RFC 7589, 1541 DOI 10.17487/RFC7589, June 2015, 1542 . 1544 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 1545 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 1546 November 2016, . 1548 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1549 Writing an IANA Considerations Section in RFCs", BCP 26, 1550 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1551 . 1553 [W3C.REC-xml-names-20091208] 1554 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1555 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 1556 Wide Web Consortium Recommendation REC-xml-names-20091208, 1557 December 2009, 1558 . 1560 12.2. Informative References 1562 [I-D.ietf-tls-tls13] 1563 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1564 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1565 July 2017. 1567 [REST] Fielding, R., "Architectural Styles and the Design of 1568 Network-based Software Architectures", 2000, 1569 . 1572 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1573 specifying the location of services (DNS SRV)", RFC 2782, 1574 DOI 10.17487/RFC2782, February 2000, 1575 . 1577 [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible 1578 Markup Language) XML-Signature Syntax and Processing", 1579 RFC 3275, DOI 10.17487/RFC3275, March 2002, 1580 . 1582 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1583 Information Models and Data Models", RFC 3444, 1584 DOI 10.17487/RFC3444, January 2003, 1585 . 1587 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1588 Specifications: ABNF", STD 68, RFC 5234, 1589 DOI 10.17487/RFC5234, January 2008, 1590 . 1592 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1593 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1594 . 1596 [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- 1597 Bound Authentication (HOBA)", RFC 7486, 1598 DOI 10.17487/RFC7486, March 2015, 1599 . 1601 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1602 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1603 2015, . 1605 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1606 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1607 . 1609 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1610 Digest Access Authentication", RFC 7616, 1611 DOI 10.17487/RFC7616, September 2015, 1612 . 1614 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1615 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1616 . 1618 [RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload 1619 Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, 1620 . 1622 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 1623 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 1624 March 2016, . 1626 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 1627 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 1628 . 1630 [SAML-bind] 1631 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1632 Maler, "Bindings for the OASIS Security Assertion Markup 1633 Language (SAML) V2.0", OASIS Standard saml-bindings- 1634 2.0-os, March 2005, . 1637 [SAML-core] 1638 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1639 "Assertions and Protocol for the OASIS Security Assertion 1640 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1641 2.0-os, March 2005, . 1644 [SAML-prof] 1645 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1646 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1647 Security Assertion Markup Language (SAML) V2.0", OASIS 1648 Standard OASIS.saml-profiles-2.0-os, March 2005, 1649 . 1652 [XACML] Rissanen, E., "eXtensible Access Control Markup Language 1653 (XACML) Version 3.0", August 2010, . 1656 12.3. URIs 1658 [1] https://www.iana.org/assignments/link-relations/link- 1659 relations.xhtml 1661 [2] https://www.iana.org/assignments/link-relations/link- 1662 relations.xhtml 1664 [3] https://www.iana.org/assignments/http-authschemes/http- 1665 authschemes.xhtml 1667 [4] http://csrc.nist.gov/groups/SNS/rbac/ 1669 Appendix A. Relax NG Compact Schema for ROLIE 1671 This appendix is informative. 1673 The Relax NG schema below defines the rolie:format element. 1675 # -*- rnc -*- 1676 # RELAX NG Compact Syntax Grammar for the rolie ns 1678 namespace rolie = "urn:ietf:params:xml:ns:rolie-1.0" 1679 namespace atom = "http://www.w3.org/2005/Atom" 1680 namespace app = "http://www.w3.org/2007/app" 1682 # rolie:format 1684 rolieFormat = 1685 element rolie:format { 1686 app:appCommonAttributes, 1687 attribute ns { atom:atomURI }, 1688 attribute version { text } ?, 1689 attribute schema-location { atom:atomURI } ?, 1690 attribute schema-type { atom:atomMediaType } ?, 1691 empty 1692 } 1694 # rolie:property 1696 rolieProperty = 1697 element rolie:property { 1698 app:appCommonAttributes, 1699 attribute name { atom:atomURI }, 1700 attribute value { text } 1701 empty 1702 } 1704 Appendix B. Examples of Use 1706 B.1. Service Discovery 1708 This section provides a non-normative example of a client doing 1709 service discovery. 1711 An Atom Service Document enables a client to dynamically discover 1712 what Feeds a particular publisher makes available. Thus, a provider 1713 uses an Atom Service Document to enable authorized clients to 1714 determine what specific information the provider makes available to 1715 the community. While the Service Document is accessible at a pre- 1716 determined location, the Service Document can also be made accessible 1717 from any well known location, such as via a link from the producer's 1718 home page. 1720 A client may format an HTTP GET request to retrieve the service 1721 document from the specified location: 1723 GET /.well-known/rolie/servicedocument 1724 Host: www.example.org 1725 Accept: application/atomsvc+xml 1727 Notice the use of the HTTP Accept: request header, indicating the 1728 MIME type for Atom service discovery. The response to this GET 1729 request will be an XML document that contains information on the 1730 specific Collections that are provided. 1732 Example HTTP GET response: 1734 HTTP/1.1 200 OK 1735 Date: Fri, 24 Aug 2016 17:09:11 GMT 1736 Content-Length: 570 1737 Content-Type: application/atomsvc+xml;charset="utf-8" 1739 1740 1742 1743 Vulnerabilities 1744 1745 Vulnerabilities Feed 1746 1747 1750 1751 1752 1753 1755 This simple Service Document example shows that the server provides 1756 one workspace, named "Vunerabilities". Within that workspace, the 1757 server makes one Collection available. 1759 A server may also offer a number of different Collections, each 1760 containing different types of security automation information. In 1761 the following example, a number of different Collections are 1762 provided, each with its own category and authorization scope. This 1763 categorization will help the clients to decide which Collections will 1764 meet their needs. 1766 HTTP/1.1 200 OK 1767 Date: Fri, 24 Aug 2016 17:10:11 GMT 1768 Content-Length: 1912 1769 Content-Type: application/atomsvc+xml;charset="utf-8" 1771 1772 1774 1775 Public Security Information Sharing 1776 1778 Public Vulnerabilities 1779 1781 1782 1785 1786 1787 1788 1789 Private Consortium Sharing 1790 1792 Incidents 1793 1795 1796 1799 1800 1801 1802 1804 In this example, the provider is making available a total of two 1805 Collections, organized into two different workspaces. The first 1806 workspace contains a Collection consisting of publicly available 1807 software vulnerabilities. The second workspace provides an incident 1808 Collection for use by a private sharing consortium. An appropriately 1809 authenticated and authorized client may then proceed to make HTTP 1810 requests for these Collections. The publicly provided vulnerability 1811 information may be accessible with or without authentication. 1812 However, users accessing the Collection restricted to authorized 1813 members of a private sharing consortium are expected to authenticate 1814 before access is allowed. 1816 B.2. Feed Retrieval 1818 This section provides a non-normative example of a client retrieving 1819 an vulnerability Feed. 1821 Having discovered the available security information sharing 1822 Collections, a client who is a member of the general public may be 1823 interested in receiving the Collection of public vulnerabilities. 1824 The client may retrieve the Feed for this Collection by performing an 1825 HTTP GET operation on the URL indicated by the Collection's "href" 1826 attribute. 1828 Example HTTP GET request for a Feed: 1830 GET /provider/public/vulns 1831 Host: www.example.org 1832 Accept: application/atom+xml 1834 The corresponding HTTP response would be an XML document containing 1835 the vulnerability Feed: 1837 Example HTTP GET response for a Feed: 1839 HTTP/1.1 200 OK 1840 Date: Fri, 24 Aug 2016 17:20:11 GMT 1841 Content-Length: 2882 1842 Content-Type: application/atom+xml;charset="utf-8" 1844 1845 1848 2a7e265a-39bc-43f2-b711-b8fd9264b5c9 1849 1850 Atom formatted representation of 1851 a feed of XML vulnerability documents 1852 1853 1856 2016-05-04T18:13:51.0Z 1857 1859 1861 1862 1863 dd786dba-88e6-440b-9158-b8fae67ef67c 1864 Sample Vulnerability 1865 2015-08-04T18:13:51.0Z 1866 2015-08-05T18:13:51.0Z 1867 A vulnerability issue identified by CVE-... 1868 1870 1872 1873 1874 1876 1878 This Feed document has two Atom Entries, one of which has been 1879 elided. The first Entry illustrates an atom:entry element that 1880 provides a summary of essential details about one particular 1881 vulnerability. Based upon this summary information and the provided 1882 category information, a client may choose to do an HTTP GET request, 1883 on the content "src" attribute, to retrieve the full details of the 1884 vulnerability. 1886 B.3. Entry Retrieval 1888 This section provides a non-normative example of a client retrieving 1889 an vulnerability as an Atom Entry. 1891 Having retrieved the Feed of interest, the client may then decide, 1892 based on the description and/or category information, that one of the 1893 entries in the Feed is of further interest. The client may retrieve 1894 this vulnerability Entry by performing an HTTP GET operation on the 1895 URL indicated by the "src" attribute of the atom:content element. 1897 Example HTTP GET request for an Entry: 1899 GET /provider/public/vulns/123456 1900 Host: www.example.org 1901 Accept: application/atom+xml;type=entry 1903 The corresponding HTTP response would be an XML document containing 1904 the Atom Entry for the vulnerability record: 1906 Example HTTP GET response for an Entry: 1908 HTTP/1.1 200 OK 1909 Date: Fri, 24 Aug 2016 17:30:11 GMT 1910 Content-Length: 713 1911 Content-Type: application/atom+xml;type=entry;charset="utf-8" 1913 1914 1917 f63aafa9-4082-48a3-9ce6-97a2d69d4a9b 1918 Sample Vulnerability 1919 2015-08-04T18:13:51.0Z 1920 2015-08-05T18:13:51.0Z 1921 1924 A vulnerability issue identified by CVE-... 1925 1926 1928 1929 1931 The example response above shows an XML document referenced by the 1932 "src" attribute of the atom:content element. The client may retrieve 1933 the document using this URL. 1935 Appendix C. Change History 1937 Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08 1938 revision: 1940 TLS requirements changed to clarify TLS versioning and 1941 recommendations 1943 Informative references and textual discussion added to Security 1944 Considerations around HTTP Authentication and content Signing/ 1945 Encryption. 1947 IANA Expert review clarified. 1949 Editorial changes from AD review/WGLC. 1951 Changes in draft-ietf-mile-rolie-08 since draft-ietf-mile-rolie-07 1952 revision: 1954 Reworked "usage of app:collection" and "usage of atom:feed" 1955 sections to clarify ROLIE vs non-ROLIE collections/feeds 1957 Removed requirement from Security Considerations that was a 1958 duplicate of text earlier in the document 1960 TLS requirement clarifications around mutal authentication 1962 Clarified requirements around support for the "/" resource 1964 Added IANA property registrations for content-id, content- 1965 published-date, and content-updated-date that can be used across 1966 all ROLIE extensions to increase consistency/interop 1968 Assorted editorial changes 1970 Changes in draft-ietf-mile-rolie-07 since draft-ietf-mile-rolie-06 1971 revision: 1973 Condensed and re-focused Sections 1 and 4 to be more concise. 1975 Added /.well-known/ registration and requirement for service 1976 discovery. 1978 Added local category, property namespace, and additional property 1979 registrations 1981 Added privacy considerations section. 1983 Made a number of editorial changes as per WGLC review. 1985 Changes in draft-ietf-mile-rolie-06 since draft-ietf-mile-rolie-05 1986 revision: 1988 Changed to standards track 1990 Added the rolie:property element 1992 Fixed references (Normative vs Informative) 1994 Set Service and Category document URL template requirements 1996 Fixed XML snippets in examples 1998 Changes in draft-ietf-mile-rolie-05 since draft-ietf-mile-rolie-04 1999 revision: 2001 Added ROLIE specific terminology to section 2 2003 Added AtomPub Category Document in section 5.2 2005 Edited document, improving consistency in terminology usage and 2006 capitalization of key terms, as well as enhancing clarity. 2008 Removed unused format parameter type in section 8.3 2010 Schema removed, the normative schema consists of the snippets in 2011 the requirements sections. 2013 Changes in draft-ietf-mile-rolie-04 since draft-ietf-mile-rolie-03 2014 revision: 2016 o Further specification and clarification of requirements 2018 o IANA Considerations and extension system fleshed out and 2019 described. 2021 o Examples and References updated. 2023 o Schema created. 2025 o Fixed both internal section and external document referencing. 2027 o Removed XACML Guidance Appendix. This will be added to a future 2028 draft on ROLIE Authentication and Access Control. 2030 Changes made in draft-ietf-mile-rolie-03 since draft-ietf-mile- 2031 rolie-02 revision: 2033 o Atom Syndication and Atom Pub requirements split and greatly 2034 expanded for increased justification and technical specification. 2036 o Reintroduction and reformatting of some use case examples in order 2037 to provide some guidance on use. 2039 o Established rough version of IANA table extension system along 2040 with explanations of said system. 2042 o Re-organized document to put non-vital information in appendices. 2044 Changes made in draft-ietf-mile-rolie-02 since draft-field-mile- 2045 rolie-01 revision: 2047 o All CSIRT and IODEF/RID material moved to companion CSIRT document 2049 o Recast document into a more general use perspective. The 2050 implication of CSIRTs as the defacto end-user has been removed 2051 where ever possible. All of the original CSIRT based use cases 2052 remain completely supported by this document, it has been opened 2053 up to support many other use cases. 2055 o Changed the content model to broaden support of representation 2057 o Edited and rewrote much of sections 1,2 and 3 in order to 2058 accomplish a broader scope and greater readability 2060 o Removed any requirements from the Background section and, if not 2061 already stated, placed them in the requirements section 2063 o Re-formatted the requirements section to make it clearer that it 2064 contains the lions-share of the requirements of the specification 2066 Changes made in draft-ietf-mile-rolie-01 since draft-field-mile- 2067 rolie-02 revision: 2069 o Added section specifying the use of RFC5005 for Archive and Paging 2070 of Feeds. 2072 o Added section describing use of atom categories that correspond to 2073 IODEF expectation class and impact classes. See: normative- 2074 expectation-impact 2076 o Dropped references to adoption of a MILE-specific HTTP media type 2077 parameter. 2079 o Updated IANA Considerations section to clarify that no IANA 2080 actions are required. 2082 Authors' Addresses 2084 John P. Field 2085 Pivotal Software, Inc. 2086 625 Avenue of the Americas 2087 New York, New York 2088 USA 2090 Phone: (646)792-5770 2091 Email: jfield@pivotal.io 2093 Stephen A. Banghart 2094 National Institute of Standards and Technology 2095 100 Bureau Drive 2096 Gaithersburg, Maryland 2097 USA 2099 Phone: (301)975-4288 2100 Email: stephen.banghart@nist.gov 2102 David Waltermire 2103 National Institute of Standards and Technology 2104 100 Bureau Drive 2105 Gaithersburg, Maryland 20877 2106 USA 2108 Email: david.waltermire@nist.gov