draft-ietf-mile-jsoniodef-10.txt		draft-ietf-mile-jsoniodef-11.txt
	MILE T. Takahashi		MILE T. Takahashi
	Internet-Draft NICT		Internet-Draft NICT
	Intended status: Standards Track R. Danyliw		Intended status: Standards Track R. Danyliw
	Expires: January 23, 2020 CERT		Expires: May 21, 2020 CERT
	M. Suzuki		M. Suzuki
	NICT		NICT
	July 22, 2019		November 18, 2019
	JSON binding of IODEF		JSON binding of IODEF
	draft-ietf-mile-jsoniodef-10		draft-ietf-mile-jsoniodef-11
	Abstract		Abstract
	The Incident Object Description Exchange Format defined in RFC 7970		The Incident Object Description Exchange Format defined in RFC 7970
	provides an information model and a corresponding XML data model for		provides an information model and a corresponding XML data model for
	exchanging incident and indicator information. This draft gives		exchanging incident and indicator information. This draft gives
	implementers and operators an alternative format to exchange the same		implementers and operators an alternative format to exchange the same
	information by defining an alternative data model implementation in		information by defining an alternative data model implementation in
	JSON and its encoding in CBOR.		JSON and its encoding in CBOR.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 January 23, 2020.		This Internet-Draft will expire on May 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	3.2. Mapping between JSON and XML IODEF . . . . . . . . . . . 17		3.2. Mapping between JSON and XML IODEF . . . . . . . . . . . 17
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 18		4.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 18
	4.2. Indicators from a Campaign . . . . . . . . . . . . . . . 20		4.2. Indicators from a Campaign . . . . . . . . . . . . . . . 20
	5. The IODEF Data Model (CDDL) . . . . . . . . . . . . . . . . . 25		5. The IODEF Data Model (CDDL) . . . . . . . . . . . . . . . . . 25
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 40		7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
	9.1. Normative References . . . . . . . . . . . . . . . . . . 41		9.1. Normative References . . . . . . . . . . . . . . . . . . 41
	9.2. Informative References . . . . . . . . . . . . . . . . . 41		9.2. Informative References . . . . . . . . . . . . . . . . . 42
	Appendix A. Data Types used in this document . . . . . . . . . . 42		Appendix A. Data Types used in this document . . . . . . . . . . 42
	Appendix B. The IODEF Data Model (JSON Schema) . . . . . . . . . 42		Appendix B. The IODEF Data Model (JSON Schema) . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
	1. Introduction		1. Introduction
	The Incident Object Description Exchange Format (IODEF) [RFC7970]		The Incident Object Description Exchange Format (IODEF) [RFC7970]
	defines a data representation for security incident reports and		defines a data representation for security incident reports and
	indicators commonly exchanged by operational security teams. It		indicators commonly exchanged by operational security teams. It
	facilitates the automated exchange of this information to enable		facilitates the automated exchange of this information to enable
	mitigation and watch-and-warning. Section 3 of [RFC7970] defined an		mitigation and watch-and-warning. Section 3 of [RFC7970] defined an
	information model using Unified Modeling Language (UML) and a		information model using Unified Modeling Language (UML) and a
	corresponding Extensible Markup Language (XML) schema data model in		corresponding Extensible Markup Language (XML) schema data model in
	Section 8. This UML-based information model and XML-based data model		Section 8. This UML-based information model and XML-based data model
	are referred to as IODEF UML and IODEF XML, respectively in this		are referred to as IODEF UML and IODEF XML, respectively in this
	document.		document.
	IODEF documents are structured and thus suitable for machine		IODEF documents are structured and thus suitable for machine
	processing. They will streamline incident response operations.		processing. They will streamline incident response operations.
	Another well-used and structured format that is suitable for machine		Another well-used and structured format that is suitable for machine
	processing is JSON. To facilitate the automation of incident		processing is JavaScript Object Notation (JSON) [RFC8259]. To
	response operations, IODEF documents should support JSON		facilitate the automation of incident response operations, IODEF
	representation.		documents should support JSON representation and it encoding in
			Concise Binary Object Representation (CBOR) [RFC7049].
	This document defines an alternate implementation of the IODEF UML		This document defines an alternate implementation of the IODEF UML
	information model by specifying a JavaScript Object Notation (JSON)		information model by specifying a JavaScript Object Notation (JSON)
	data model using CDDL [RFC8610] and JSON Schema [jsonschema]. This		data model using Concise Data Definition Language (CDDL) [RFC8610]
	JSON data model is referred to as IODEF JSON in this document. IODEF		and JSON Schema [jsonschema]. This JSON data model is referred to as
	JSON provides all of the expressivity of IODEF XML. It gives		IODEF JSON in this document. IODEF JSON provides all of the
	implementers and operators an alternative format to exchange the same		expressivity of IODEF XML. It gives implementers and operators an
	information.		alternative format to exchange the same information.
	The normative IODEF JSON data model is found in Section 5. Section 2		The normative IODEF JSON data model is found in Section 5. Section 2
	and Section 3 describe the data types and elements of this data		and Section 3 describe the data types and elements of this data
	model. Section 4 provides examples.		model. Section 4 provides examples.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 42 ¶
	+-----------------+------------------+---------------------------------+		+-----------------+------------------+---------------------------------+
	Figure 2: CBOR Data Types		Figure 2: CBOR Data Types
	2.2. Complex JSON Types		2.2. Complex JSON Types
	2.2.1. Integer		2.2.1. Integer
	An integer is a subset of "number" type of JSON, which represents		An integer is a subset of "number" type of JSON, which represents
	signed digits encoded in Base 10. The definition of this integer is		signed digits encoded in Base 10. The definition of this integer is
	"[ minus ] int" in [RFC7159] Section 6 manner.		"[ minus ] int" in [RFC8259] Section 6 manner.
	2.2.2. Multilingual Strings		2.2.2. Multilingual Strings
	A string that needs to be represented in a human-readable language		A string that needs to be represented in a human-readable language
	different from the default encoding of the document is represented in		different from the default encoding of the document is represented in
	the information model by the ML_STRING data type. This data type is		the information model by the ML_STRING data type. This data type is
	implemented as either an object with "value", "lang", and		implemented as either an object with "value", "lang", and
	"translation-id" elements or a text string as defined in Section 5.		"translation-id" elements or a text string as defined in Section 5.
	Examples are shown below.		Examples are shown below.
	"MLStringType": {		"MLStringType": {
	"value": "free-form text", //STRING		"value": "free-form text", # STRING
	"lang": "en", //ENUM		"lang": "en", # ENUM
	"translation-id": "jp2en0023" //STRING		"translation-id": "jp2en0023" # STRING
	}		}
			Note that some pieces of supplementary information are provided
			folloedb by "#" in figures throughout this document, but these are
			not a valid syntax in JSON.
	2.2.3. Enum		2.2.3. Enum
	Enum is an ordered list of acceptable string values. Each value has		Enum is an ordered list of acceptable string values. Each value has
	a representative keyword. Within the data model, the enumerated type		a representative keyword. Within the data model, the enumerated type
	keywords are used as attribute values.		keywords are used as attribute values.
	2.2.4. Software and Software Reference		2.2.4. Software and Software Reference
	A particular version of software is represented in the information		A particular version of software is represented in the information
	model by the SOFTWARE data type. This software can be described by		model by the SOFTWARE data type. This software can be described by
	using a reference, a Uniform Resource Locator (URL) [RFC3986], or		using a reference, a Uniform Resource Locator (URL) [RFC3986], or
	with free-form text. The SOFTWARE data type is implemented as an		with free-form text. The SOFTWARE data type is implemented as an
	object with "SoftwareReference", "URL", and "Description" elements as		object with "SoftwareReference", "URL", and "Description" elements as
	defined in Section 5. Examples are shown below.		defined in Section 5. Examples are shown below.
	"SoftwareType": {		"SoftwareType": {
	"SoftwareReference": {...}, //SoftwareReference		"SoftwareReference": {...}, # SoftwareReference
	"Description": ["MS Windows"] //STRING		"Description": ["MS Windows"] # STRING
	}		}
	SoftwareReference class is a reference to a particular version of		SoftwareReference class is a reference to a particular version of
	software. Examples are shown below.		software. Examples are shown below.
	"SoftwareReference": {		"SoftwareReference": {
	"value": "cpe:/a:google:chrome:59.0.3071.115", //STRING		"value": "cpe:/a:google:chrome:59.0.3071.115", # STRING
	"spec-name": "cpe", //ENUM		"spec-name": "cpe", # ENUM
	"dtype": "string" //ENUM		"dtype": "string" # ENUM
	}		}
	2.2.5. Structured Information		2.2.5. Structured Information
	Information provided in a form of structured string, such as ID, or		Information provided in a form of structured string, such as ID, or
	structured information, such as XML documents, is represented in the		structured information, such as XML documents, is represented in the
	information model by the STRUCTUREDINFO data type. Note that this		information model by the STRUCTUREDINFO data type. Note that this
	type was originally specified in [RFC7203]. The STRUCTUREDINFO data		type was originally specified in [RFC7203]. The STRUCTUREDINFO data
	type is implemented as an object with "SpecID", "ext-SpecID",		type is implemented as an object with "SpecID", "ext-SpecID",
	"ContentID", "RawData", and "Reference" elements. An example for		"ContentID", "RawData", and "Reference" elements. An example for
	embedding a structured ID is shown below.		embedding a structured ID is shown below.
	"StructuredInfo": {		"StructuredInfo": {
	"SpecID": "urn:ietf:params:xml:ns:mile:cwe:3.3", //ENUM		"SpecID": "urn:ietf:params:xml:ns:mile:cwe:3.3", # ENUM
	"ContentID": "CWE-89" //STRING		"ContentID": "CWE-89" # STRING
	}		}
	When embedding the raw data, base64 encoding defined in Section 4 of		When embedding the raw data, base64 encoding defined in Section 4 of
	[RFC4648] SHOULD be used for encoding the data, as shown below.		[RFC4648] SHOULD be used for encoding the data, as shown below.
	"StructuredInfo": {		"StructuredInfo": {
	"SpecID": "urn:ietf:params:xml:ns:mile:mmdef:1.2", //ENUM		"SpecID": "urn:ietf:params:xml:ns:mile:mmdef:1.2", # ENUM
	"RawData": "<<<strings encoded with base64>>>" //BYTE		"RawData": "<<<strings encoded with base64>>>" # BYTE
	}		}
	2.2.6. EXTENSION		2.2.6. EXTENSION
	Information not otherwise represented in the IODEF can be added using		Information not otherwise represented in the IODEF can be added using
	the EXTENSION data type. This data type is a generic extension		the EXTENSION data type. This data type is a generic extension
	mechanism. The EXTENSION data type is implemented as an		mechanism. The EXTENSION data type is implemented as an
	ExtensionType object with "value", "name", "dtype", "ext-dtype",		ExtensionType object with "value", "name", "dtype", "ext-dtype",
	"meaning", "formatid", "restriction", "ext-restriction", and		"meaning", "formatid", "restriction", "ext-restriction", and
	"observable-id" elements. An example for embedding a structured ID		"observable-id" elements. An example for embedding a structured ID
	is shown below.		is shown below.
	"ExtensionType": {		"ExtensionType": {
	"value": "xxxxxxx", //STRING		"value": "xxxxxxx", # STRING
	"name": "Syslog", //STRING		"name": "Syslog", # STRING
	"dtype": "string", //ENUM		"dtype": "string", # ENUM
	"meaning": "Syslog from the security appliance X" //STRING		"meaning": "Syslog from the security appliance X" # STRING
	}		}
	3. IODEF JSON Data Model		3. IODEF JSON Data Model
	3.1. Classes and Elements		3.1. Classes and Elements
	The following table shows the list of IODEF Classes, their elements,		The following table shows the list of IODEF Classes, their elements,
	and the corresponding section in [RFC7970]. Note that the complete		and the corresponding section in [RFC7970]. Note that the complete
	JSON schema is defined in Section 5 using CDDL.		JSON schema is defined in Section 5 using CDDL.
	skipping to change at page 18, line 36 ¶		skipping to change at page 18, line 36 ¶
	defined in this document.		defined in this document.
	o Signature, X509Data, and RawData are encoded with base64 and are		o Signature, X509Data, and RawData are encoded with base64 and are
	represented as string (BYTE type) in JSON IODEF documents.		represented as string (BYTE type) in JSON IODEF documents.
	o EmailBody represents an whole message body including MIME		o EmailBody represents an whole message body including MIME
	structure in the same manner defined in [RFC7970]. In case of an		structure in the same manner defined in [RFC7970]. In case of an
	email composed of MIME multipart, the EmailBody contains multiple		email composed of MIME multipart, the EmailBody contains multiple
	body parts separated by boundary strings.		body parts separated by boundary strings.
			o The "ipv6-net-mask" type attribute of BulkObservable class remains
			available for the backward compatibility purpose, but the use of
			this attribute is not recommended because IPV6 does not use
			netmask any more.
	4. Examples		4. Examples
	This section provides examples of IODEF documents. These examples do		This section provides examples of IODEF documents. These examples do
	not represent the full capabilities of the data model or the only way		not represent the full capabilities of the data model or the only way
	to encode particular information.		to encode particular information.
	4.1. Minimal Example		4.1. Minimal Example
	A document containing only the mandatory elements and attributes is		A document containing only the mandatory elements and attributes is
	shown below in JSON and CBOR, respectively.		shown below in JSON and CBOR, respectively.
	skipping to change at page 41, line 23 ¶		skipping to change at page 41, line 23 ¶
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
			[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
			October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An		[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
	Incident Object Description Exchange Format (IODEF)		Incident Object Description Exchange Format (IODEF)
	Extension for Structured Cybersecurity Information",		Extension for Structured Cybersecurity Information",
	RFC 7203, DOI 10.17487/RFC7203, April 2014,		RFC 7203, DOI 10.17487/RFC7203, April 2014,
	<https://www.rfc-editor.org/info/rfc7203>.		<https://www.rfc-editor.org/info/rfc7203>.
	[RFC7970] Danyliw, R., "The Incident Object Description Exchange		[RFC7970] Danyliw, R., "The Incident Object Description Exchange
	Format Version 2", RFC 7970, DOI 10.17487/RFC7970,		Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
	November 2016, <https://www.rfc-editor.org/info/rfc7970>.		November 2016, <https://www.rfc-editor.org/info/rfc7970>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", STD 90, RFC 8259,
			DOI 10.17487/RFC8259, December 2017,
			<https://www.rfc-editor.org/info/rfc8259>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	9.2. Informative References		9.2. Informative References
	[jsonschema]		[jsonschema]
	Francis Galiegue, Kris Zyp, and Gary Court, "JSON Schema:		Francis Galiegue, Kris Zyp, and Gary Court, "JSON Schema:
End of changes. 18 change blocks.
	30 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/