draft-ietf-mile-jsoniodef-11.txt   draft-ietf-mile-jsoniodef-12.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: May 21, 2020 CERT Expires: June 26, 2020 CERT
M. Suzuki M. Suzuki
NICT NICT
November 18, 2019 December 24, 2019
JSON binding of IODEF JSON binding of IODEF
draft-ietf-mile-jsoniodef-11 draft-ietf-mile-jsoniodef-12
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 May 21, 2020. This Internet-Draft will expire on June 26, 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 25 skipping to change at page 2, line 25
2.2. Complex JSON Types . . . . . . . . . . . . . . . . . . . 5 2.2. Complex JSON Types . . . . . . . . . . . . . . . . . . . 5
2.2.1. Integer . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Integer . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Multilingual Strings . . . . . . . . . . . . . . . . 5 2.2.2. Multilingual Strings . . . . . . . . . . . . . . . . 5
2.2.3. Enum . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Enum . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4. Software and Software Reference . . . . . . . . . . . 6 2.2.4. Software and Software Reference . . . . . . . . . . . 6
2.2.5. Structured Information . . . . . . . . . . . . . . . 6 2.2.5. Structured Information . . . . . . . . . . . . . . . 6
2.2.6. EXTENSION . . . . . . . . . . . . . . . . . . . . . . 7 2.2.6. EXTENSION . . . . . . . . . . . . . . . . . . . . . . 7
3. IODEF JSON Data Model . . . . . . . . . . . . . . . . . . . . 7 3. IODEF JSON Data Model . . . . . . . . . . . . . . . . . . . . 7
3.1. Classes and Elements . . . . . . . . . . . . . . . . . . 7 3.1. Classes and Elements . . . . . . . . . . . . . . . . . . 7
3.2. Mapping between JSON and XML IODEF . . . . . . . . . . . 17 3.2. Mapping between JSON and XML IODEF . . . . . . . . . . . 17
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 18 4.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 19
4.2. Indicators from a Campaign . . . . . . . . . . . . . . . 20 4.2. Indicators from a Campaign . . . . . . . . . . . . . . . 21
5. The IODEF Data Model (CDDL) . . . . . . . . . . . . . . . . . 25 5. The IODEF Data Model (CDDL) . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . 41 9.1. Normative References . . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . 42 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 . . . . . . . . . . . . . . . . . . . . . . . 71
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 JavaScript Object Notation (JSON) [RFC8259]. To processing is JavaScript Object Notation (JSON) [RFC8259]. To
facilitate the automation of incident response operations, IODEF facilitate the automation of incident response operations, IODEF
documents should support JSON representation and it encoding in documents and implementations should support JSON representation and
Concise Binary Object Representation (CBOR) [RFC7049]. 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 Concise Data Definition Language (CDDL) [RFC8610] data model using Concise Data Definition Language (CDDL) [RFC8610]
and JSON Schema [jsonschema]. This JSON data model is referred to as and JSON Schema [jsonschema]. This JSON data model is referred to as
IODEF JSON in this document. IODEF JSON provides all of the IODEF JSON in this document. IODEF JSON provides all of the
expressivity of IODEF XML. It gives implementers and operators an expressivity of IODEF XML. It gives implementers and operators an
alternative format to exchange the same 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
skipping to change at page 5, line 51 skipping to change at page 5, line 51
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 [RFC8259] 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. An example is 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 Note that in figures throughout this document, some supplementary
folloedb by "#" in figures throughout this document, but these are information follows "#", but these are not valid syntax in JSON, but
not a valid syntax in JSON. are intended to facilitate reader understanding.
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
skipping to change at page 6, line 49 skipping to change at page 6, line 49
"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 Section 4.4 of [RFC7203] as a basic
type is implemented as an object with "SpecID", "ext-SpecID", structure of its extension classes. The STRUCTUREDINFO data type is
"ContentID", "RawData", and "Reference" elements. An example for implemented as an object with "SpecID", "ext-SpecID", "ContentID",
embedding a structured ID is shown below. "RawData", and "Reference" elements. An example for 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
} }
Note that the structure of this information is not interpreted in the
IODEF JSON, and the word 'structured' indicates that the data item
has internal structure that is intended to be processed outside of
the IODEF framework.
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.
skipping to change at page 18, line 41 skipping to change at page 18, line 49
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 o The "ipv6-net-mask" type attribute of BulkObservable class remains
available for the backward compatibility purpose, but the use of available for the backward compatibility purpose, but the use of
this attribute is not recommended because IPV6 does not use this attribute is not recommended because IPV6 does not use
netmask any more. netmask any more.
o ENUM values in this document is extensible and is managed by IANA,
as with [RFC7970].
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 26, line 4 skipping to change at page 26, line 15
? format-id: text ? format-id: text
? private-enum-name: text ? private-enum-name: text
? private-enum-id: text ? private-enum-id: text
Incident: [+ Incident] Incident: [+ Incident]
? AdditionalData: [+ ExtensionType] ? AdditionalData: [+ ExtensionType]
} }
duration = "second" / "minute" / "hour" / "day" / "month" / "quarter" / duration = "second" / "minute" / "hour" / "day" / "month" / "quarter" /
"year" / "ext-value" "year" / "ext-value"
lang = "" / text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*" lang = "" / text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"
restriction = "public" / "partner" / "need-to-know" / "private" / restriction = "public" / "partner" / "need-to-know" / "private" /
"default" / "white" / "green" / "amber" / "red" / "default" / "white" / "green" / "amber" / "red" /
"ext-value" "ext-value"
SpecID = "urn:ietf:params:xml:ns:mile:mmdef:1.2" / "private" SpecID = "urn:ietf:params:xml:ns:mile:mmdef:1.2" / "private"
IDtype = text .regexp "[a-zA-Z_][a-zA-Z0-9_.-]*" IDtype = text .regexp "[a-zA-Z_][a-zA-Z0-9_.-]*"
IDREFType = IDtype IDREFType = IDtype
URLtype = uri URLtype = uri
TimeZonetype = text .regexp "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]" TimeZonetype = text .regexp "Z|[\\+\\-](0[0-9]|1[0-4]):[0-5][0-9]"
PortlistType = text .regexp "\\d+(\\-\\d+)?(,\\d+(\\-\\d+)?)*" PortlistType = text .regexp "[0-9]+(\\-[0-9]+)?(,[0-9]+(\\-[0-9]+)?)*"
action = "nothing" / "contact-source-site" / "contact-target-site" / action = "nothing" / "contact-source-site" / "contact-target-site" /
"contact-sender" / "investigate" / "block-host" / "contact-sender" / "investigate" / "block-host" /
"block-network" / "block-port" / "rate-limit-host" / "block-network" / "block-port" / "rate-limit-host" /
"rate-limit-network" / "rate-limit-port" / "redirect-traffic" / "rate-limit-network" / "rate-limit-port" / "redirect-traffic" /
"honeypot" / "upgrade-software" / "rebuild-asset" / "honeypot" / "upgrade-software" / "rebuild-asset" /
"harden-asset" / "remediate-other" / "status-triage" / "harden-asset" / "remediate-other" / "status-triage" /
"status-new-info" / "watch-and-report" / "training" / "status-new-info" / "watch-and-report" / "training" /
"defined-coa" / "other" / "ext-value" "defined-coa" / "other" / "ext-value"
DATETIME = tdate DATETIME = tdate
skipping to change at page 42, line 32 skipping to change at page 42, line 47
| integer | n/a | number | integer | | integer | n/a | number | integer |
| eb64legacy | n/a | string | tool available | | eb64legacy | n/a | string | tool available |
| uri | n/a | string | 7.3.6 uri | | uri | n/a | string | 7.3.6 uri |
| float32 | float32 | number | unnecessary | | float32 | float32 | number | unnecessary |
+-----------------+-------------------+----------------------------+ +-----------------+-------------------+----------------------------+
Figure 9: CDDL Prelude mapping in JSON Figure 9: CDDL Prelude mapping in JSON
Appendix B. The IODEF Data Model (JSON Schema) Appendix B. The IODEF Data Model (JSON Schema)
This section provides a JSON schema that defines the IODEF Data Model This section provides a JSON schema [jsonschema] that defines the
defined in this draft. Note that this section is Informative. IODEF Data Model defined in this draft. Note that this section is
Informative.
{ "$schema": "http://json-schema.org/draft-04/schema#", { "$schema": "http://json-schema.org/draft-04/schema#",
"definitions": { "definitions": {
"action": {"enum": ["nothing","contact-source-site", "action": {"enum": ["nothing","contact-source-site",
"contact-target-site","contact-sender","investigate", "contact-target-site","contact-sender","investigate",
"block-host","block-network","block-port","rate-limit-host", "block-host","block-network","block-port","rate-limit-host",
"rate-limit-network","rate-limit-port","redirect-traffic", "rate-limit-network","rate-limit-port","redirect-traffic",
"honeypot","upgrade-software","rebuild-asset","harden-asset", "honeypot","upgrade-software","rebuild-asset","harden-asset",
"remediate-other","status-triage","status-new-info", "remediate-other","status-triage","status-new-info",
"watch-and-report","training","defined-coa","other", "watch-and-report","training","defined-coa","other",
skipping to change at page 43, line 4 skipping to change at page 43, line 20
"watch-and-report","training","defined-coa","other", "watch-and-report","training","defined-coa","other",
"ext-value"]}, "ext-value"]},
"duration":{"enum":["second","minute","hour","day","month", "duration":{"enum":["second","minute","hour","day","month",
"quarter","year","ext-value"]}, "quarter","year","ext-value"]},
"SpecID":{ "SpecID":{
"enum":["urn:ietf:params:xml:ns:mile:mmdef:1.2","private"]}, "enum":["urn:ietf:params:xml:ns:mile:mmdef:1.2","private"]},
"lang": { "lang": {
"type":"string","pattern":"^$|[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"}, "type":"string","pattern":"^$|[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"},
"purpose": {"enum": ["traceback","mitigation","reporting","watch", "purpose": {"enum": ["traceback","mitigation","reporting","watch",
"other","ext-value"]}, "other","ext-value"]},
"restriction":{"enum":["public","partner","need-to-know","private", "restriction":{"enum":["public","partner","need-to-know","private",
"default","white","green","amber","red","ext-value"]}, "default","white","green","amber","red","ext-value"]},
"status": {"enum": ["new","in-progress","forwarded","resolved", "status": {"enum": ["new","in-progress","forwarded","resolved",
"future","ext-value"]}, "future","ext-value"]},
"DATETIME": {"type": "string","format": "date-time"}, "DATETIME": {"type": "string","format": "date-time"},
"BYTE": {"type": "string"}, "BYTE": {"type": "string"},
"PortlistType": { "PortlistType": {
"type": "string","pattern": "\\d+(\\-\\d+)?(,\\d+(\\-\\d+)?)*"}, "type": "string","pattern": "[0-9]+(\\-[0-9]+)?(,[0-9]+(\\-[0-9]+)?)*"},
"TimeZonetype": { "TimeZonetype": {
"type":"string","pattern":"Z|[\\+\\-](0[0-9]|1[0-4]):[0-5][0-9]"}, "type":"string","pattern":"Z|[\\+\\-](0[0-9]|1[0-4]):[0-5][0-9]"},
"URLtype": { "URLtype": {
"type": "string", "type": "string",
"pattern": "pattern":
"^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?"}, "^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?"},
"IDtype": {"type": "string","pattern": "[a-zA-Z_][a-zA-Z0-9_.-]*"}, "IDtype": {"type": "string","pattern": "[a-zA-Z_][a-zA-Z0-9_.-]*"},
"IDREFType": {"$ref": "#/definitions/IDtype"}, "IDREFType": {"$ref": "#/definitions/IDtype"},
"MLStringType": { "MLStringType": {
"oneOf": [{"type": "string"}, "oneOf": [{"type": "string"},
 End of changes. 18 change blocks. 
27 lines changed or deleted 37 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/