draft-ietf-mile-rolie-09.txt   draft-ietf-mile-rolie-10.txt 
MILE Working Group J. Field MILE Working Group J. Field
Internet-Draft Pivotal Internet-Draft Pivotal
Intended status: Standards Track S. Banghart Intended status: Standards Track S. Banghart
Expires: March 30, 2018 D. Waltermire Expires: April 1, 2018 D. Waltermire
NIST NIST
September 26, 2017 September 28, 2017
Resource-Oriented Lightweight Information Exchange Resource-Oriented Lightweight Information Exchange
draft-ietf-mile-rolie-09 draft-ietf-mile-rolie-10
Abstract Abstract
This document defines a resource-oriented approach for security This document defines a resource-oriented approach for security
automation information publication, discovery, and sharing. Using automation information publication, discovery, and sharing. Using
this approach, producers may publish, share, and exchange this approach, producers may publish, share, and exchange
representations of software descriptors, security incidents, attack representations of software descriptors, security incidents, attack
indicators, software vulnerabilities, configuration checklists, and indicators, software vulnerabilities, configuration checklists, and
other security automation information as web-addressable resources. other security automation information as web-addressable resources.
Furthermore, consumers and other stakeholders may access and search Furthermore, consumers and other stakeholders may access and search
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2018. This Internet-Draft will expire on April 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 41 skipping to change at page 5, line 41
is one of the core components of automating security processes. is one of the core components of automating security processes.
Vulnerabilities, configurations, software identification, security Vulnerabilities, configurations, software identification, security
incidents, and patch data are just a few of the classes of incidents, and patch data are just a few of the classes of
information that are shared today to enable effective security on a information that are shared today to enable effective security on a
wide scale. However, as the scale of defense broadens as networks wide scale. However, as the scale of defense broadens as networks
become larger and more complex, and the volume of information to become larger and more complex, and the volume of information to
process makes humans-in-the-loop difficult to scale, the need for process makes humans-in-the-loop difficult to scale, the need for
automation and machine-to-machine communication becomes increasingly automation and machine-to-machine communication becomes increasingly
critical. critical.
ROLIE seeks to address this need by providing three major information ROLIE seeks to address this need by providing four major information
sharing benefits: sharing benefits:
Extensible information type categories and format agnosticism: ROLIE Extensible information type categories and format agnosticism: ROLIE
is not bound to any given data format or category of information. is not bound to any given data format or category of information.
Instead, information categories are extensible, and entries Instead, information categories are extensible, and entries
declare the format of the referenced data. In cases where several declare the format of the referenced data. In cases where several
formats or serializations are available, ROLIE can use link formats or serializations are available, ROLIE can use link
relations to communicate how a consumer can access these formats. relations to communicate how a consumer can access these formats.
For example, clients may request that a given resource For example, clients may request that a given resource
representation be returned as XML, JSON, or in some other format representation be returned as XML, JSON, or in some other format
skipping to change at page 6, line 24 skipping to change at page 6, line 24
function as a central or federated collections. function as a central or federated collections.
Stateless communication model: ROLIE, as a RESTful system, is Stateless communication model: ROLIE, as a RESTful system, is
stateless. That is, the server doesn't keep track of client stateless. That is, the server doesn't keep track of client
sessions, but rather uses link relations for state transitions. sessions, but rather uses link relations for state transitions.
In practice, this means that any consumer can find and share In practice, this means that any consumer can find and share
information at any organizational level and at any time without information at any organizational level and at any time without
needing to execute a long series of requests. needing to execute a long series of requests.
Information discovery and navigation: ROLIE provides a number of Information discovery and navigation: ROLIE provides a number of
mechanisms to allow clients to programmtically discover and mechanisms to allow clients to programmatically discover and
navigate collections of information in order to dynamically navigate collections of information in order to dynamically
discover new or revised content. Extensible information types and discover new or revised content. Extensible information types and
other categories provide one way of determining content that is other categories provide one way of determining content that is
desirable. Link elements, each with a target URI and an desirable. Link elements, each with a target URI and an
established relationship type, provide a means for ROLIE providers established relationship type, provide a means for ROLIE providers
to link other information that is relevant to the current entry or to link other information that is relevant to the current entry or
feed. feed.
These benefits result in an information sharing protocol that is These benefits result in an information sharing protocol that is
lightweight, interactive, open, and most importantly, machine lightweight, interactive, open, and most importantly, machine
skipping to change at page 10, line 27 skipping to change at page 10, line 27
5.3. Transport Layer Security 5.3. Transport Layer Security
ROLIE is intended to be handled with TLS. The following requirements ROLIE is intended to be handled with TLS. The following requirements
have been in part derived from [RFC7589]. have been in part derived from [RFC7589].
TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented
according to all recommendations and best practices present in according to all recommendations and best practices present in
[RFC7525]. [RFC7525].
It is RECOMMENDED that the most recent published version of TLS is It is RECOMMENDED that the most recent published version of TLS is
supported. If this version is TLS 1.3, it is recommended that 0-RTT supported. If this version is TLS 1.3 [I-D.ietf-tls-tls13], it is
(Zero Round Trip Time Resumption) is not used, as there is a replay recommended that 0-RTT (Zero Round Trip Time Resumption) is not used,
attack that is possible with that option. as there is a replay attack that is possible with that option.
The server MUST support certificate-based client authentication. An The server MUST support certificate-based client authentication. An
implementation MUST support the set of TLS cipher suites that are implementation MUST support the set of TLS cipher suites that are
REQUIRED by the latest published version of the TLS specification. REQUIRED by the latest published version of the TLS specification.
An implementation MUST also support the TLS cipher suites that An implementation MUST also support the TLS cipher suites that
provide support for mutual authentication of clients and servers. provide support for mutual authentication of clients and servers.
During the TLS negotiation, the client MUST carefully examine the During the TLS negotiation, the client MUST carefully examine the
certificate presented by the server to determine if it meets the certificate presented by the server to determine if it meets the
client's expectations. Particularly, the client MUST check its client's expectations. Particularly, the client MUST check its
skipping to change at page 25, line 38 skipping to change at page 25, line 38
A new top-level registry has been created, entitled "Resource A new top-level registry has been created, entitled "Resource
Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO
BE REMOVED: This registration should take place at the following BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/rolie] location: https://www.iana.org/assignments/rolie]
In this top-level registry, a sub-registry entitled "ROLIE URN In this top-level registry, a sub-registry entitled "ROLIE URN
Parameters" has been created. Registration in this repository is via Parameters" has been created. Registration in this repository is via
the Specification Required policy [RFC8126]. Designated Expert the Specification Required policy [RFC8126]. Designated Expert
reviews should be routed through the MILE WG mailing list. Failing reviews should be routed through the MILE WG mailing list. Failing
this, the Designated Expert will be assigned by the IESG. The this, the Designated Expert will be assigned by the IESG.
authors recommend the following individuals be assigned by the IESG
as Designated Experts:
Stephen Banghart <stephen.banghart@nist.gov>
David Waltermire <david.waltermire@nist.gov>
Each entry in this sub-registry must record the following fields: Each entry in this sub-registry must record the following fields:
Name: A URN segment that adheres to the pattern {type}:{label}. Name: A URN segment that adheres to the pattern {type}:{label}.
The keywords are defined as follows: The keywords are defined as follows:
{type}: The parameter type. The allowed values are "category" {type}: The parameter type. The allowed values are "category"
or "property". "category" denotes a category extension as or "property". "category" denotes a category extension as
discussed in Section 7.1. "property" denotes a property discussed in Section 7.1. "property" denotes a property
extension as discussed in Section 7.4. extension as discussed in Section 7.4.
skipping to change at page 29, line 49 skipping to change at page 29, line 49
security properties over HTTP Basic [RFC7617]and Digest [RFC7616] security properties over HTTP Basic [RFC7617]and Digest [RFC7616]
Authentication Schemes. However, sharing communities that are Authentication Schemes. However, sharing communities that are
engaged in sensitive collaborative analysis and/or operational engaged in sensitive collaborative analysis and/or operational
response for indicators and incidents targeting high value response for indicators and incidents targeting high value
information systems should adopt a suitably stronger user information systems should adopt a suitably stronger user
authentication solution, such as a risk-based or multi-factor authentication solution, such as a risk-based or multi-factor
approach. In general, trust in the sharing consortium will depend approach. In general, trust in the sharing consortium will depend
upon the members maintaining adequate user authentication mechanisms. upon the members maintaining adequate user authentication mechanisms.
Collaborating consortiums may benefit from the adoption of a Collaborating consortiums may benefit from the adoption of a
federated identity solution, such as those based upon [RFC6749], or federated identity solution, such as those based upon OAuth [RFC6749]
SAML-core [SAML-core], SAML-bind [SAML-bind], and SAML-prof with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind],
[SAML-prof] for Web-based authentication and cross-organizational and SAML-prof [SAML-prof] for Web-based authentication and cross-
single sign-on. Dependency on a trusted third party identity organizational single sign-on. Dependency on a trusted third party
provider implies that appropriate care must be exercised to identity provider implies that appropriate care must be exercised to
sufficiently secure the Identity provider. Any attacks on the sufficiently secure the Identity provider. Any attacks on the
federated identity system would present a risk to the consortium, as federated identity system would present a risk to the consortium, as
a relying party. Potential mitigations include deployment of a a relying party. Potential mitigations include deployment of a
federation-aware identity provider that is under the control of the federation-aware identity provider that is under the control of the
information sharing consortium, with suitably stringent technical and information sharing consortium, with suitably stringent technical and
management controls. management controls.
Authorization of resource representations is the responsibility of Authorization of resource representations is the responsibility of
the source system, i.e. based on the authenticated user identity the source system, i.e. based on the authenticated user identity
associated with an HTTP(S) request. The required authorization associated with an HTTP(S) request. The required authorization
skipping to change at page 32, line 12 skipping to change at page 32, line 12
mitigated by following security considerations and carefully using mitigated by following security considerations and carefully using
the optional identifying elements. the optional identifying elements.
11. Acknowledgements 11. Acknowledgements
The authors gratefully acknowledge the valuable contributions of Tom The authors gratefully acknowledge the valuable contributions of Tom
Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These
individuals provided detailed review comments on earlier drafts, and individuals provided detailed review comments on earlier drafts, and
made many suggestions that have helped to improve this document. made many suggestions that have helped to improve this document.
The authors would also like to thank the MILE Working Group, the SACM
Working Group, and countless other people from both within the IETF
community and outside of it for their excellent review and effort
towards constructing this draft.
12. References 12. References
12.1. Normative References 12.1. Normative References
[relax-NG] [relax-NG]
Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002, Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002,
<https://www.oasis-open.org/committees/relax-ng/ <https://www.oasis-open.org/committees/relax-ng/
compact-20021121.html>. compact-20021121.html>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
skipping to change at page 34, line 19 skipping to change at page 34, line 19
[W3C.REC-xml-names-20091208] [W3C.REC-xml-names-20091208]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208, Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>. top.htm>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>. <https://www.rfc-editor.org/info/rfc2782>.
skipping to change at page 35, line 22 skipping to change at page 35, line 27
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/info/rfc7616>. <https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload
Option", RFC 7797, DOI 10.17487/RFC7797, February 2016,
<https://www.rfc-editor.org/info/rfc7797>.
[RFC7804] Melnikov, A., "Salted Challenge Response HTTP [RFC7804] Melnikov, A., "Salted Challenge Response HTTP
Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
March 2016, <https://www.rfc-editor.org/info/rfc7804>. March 2016, <https://www.rfc-editor.org/info/rfc7804>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>. <https://www.rfc-editor.org/info/rfc8141>.
[SAML-bind] [SAML-bind]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
 End of changes. 12 change blocks. 
21 lines changed or deleted 29 lines changed or added

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