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/