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/