draft-ietf-mile-jsoniodef-09.txt   draft-ietf-mile-jsoniodef-10.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 9, 2020 CERT Expires: January 23, 2020 CERT
M. Suzuki M. Suzuki
NICT NICT
July 8, 2019 July 22, 2019
CBOR/JSON binding of IODEF JSON binding of IODEF
draft-ietf-mile-jsoniodef-09 draft-ietf-mile-jsoniodef-10
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
CBOR/JSON. JSON and its encoding in CBOR.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 9, 2020. This Internet-Draft will expire on January 23, 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 24 skipping to change at page 2, line 24
2.1. Abstract Data Type to JSON Data Type Mapping . . . . . . 3 2.1. Abstract Data Type to JSON Data Type Mapping . . . . . . 3
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 CBOR/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 . . . . . . . . . . . . . . . . . 41
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. IODEF Data Types 2. IODEF Data Types
The abstract IODEF JSON implements the abstract data types specified IODEF JSON implements the abstract data types specified in Section 2
in Section 2 of [RFC7970]. of [RFC7970].
2.1. Abstract Data Type to JSON Data Type Mapping 2.1. Abstract Data Type to JSON Data Type Mapping
IODEF JSON uses native and derived JSON data types. Figure 1 IODEF JSON uses native and derived JSON data types. Figure 1
describes the mapping between the abstract data types in Section 2 of describes the mapping between the abstract data types in Section 2 of
[RFC7970] and their corresponding implementations in IODEF JSON. [RFC7970] and their corresponding implementations in IODEF JSON.
+-----------------+-------------------+-------------------------------+ +-----------------+-------------------+-------------------------------+
| IODEF Data Type | [RFC7970] | JSON Data Type | | IODEF Data Type | [RFC7970] | JSON Data Type |
| | Reference | | | | Reference | |
skipping to change at page 6, line 47 skipping to change at page 6, line 47
"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", "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
skipping to change at page 10, line 33 skipping to change at page 10, line 33
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| Method | restriction? | | | Method | restriction? | |
| | ext-restriction? | | | | ext-restriction? | |
| | Reference* | | | | Reference* | |
| | Description* | | | | Description* | |
| | AttackPattern* | | | | AttackPattern* | |
| | Vulnerability* | | | | Vulnerability* | |
| | Weakness* | | | | Weakness* | |
| | AdditionalData* | 3.11 | | | AdditionalData* | 3.11 |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| Weakness (TBD) | restriction? | |
| | ext-restriction? | |
+-----------------------------+--------------------+---------------+
| Reference | observable-id? | | | Reference | observable-id? | |
| | ReferenceName? | | | | ReferenceName? | |
| | URL* | | | | URL* | |
| | Description* | 3.11.1 | | | Description* | 3.11.1 |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| Assessment | occurence? | | | Assessment | occurence? | |
| | restriction? | | | | restriction? | |
| | ext-restriction? | | | | ext-restriction? | |
| | observable-id? | | | | observable-id? | |
| | IncidentCategory* | | | | IncidentCategory* | |
skipping to change at page 17, line 30 skipping to change at page 17, line 33
| | version? | 3.29.7 | | | version? | 3.29.7 |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| AttackPhase | AttackPhaseID* | | | AttackPhase | AttackPhaseID* | |
| | URL* | | | | URL* | |
| | Description* | | | | Description* | |
| | AdditionalData* | 3.29.8 | | | AdditionalData* | 3.29.8 |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
Figure 3: IODEF Classes Figure 3: IODEF Classes
3.2. Mapping between CBOR/JSON and XML IODEF 3.2. Mapping between JSON and XML IODEF
o This document treats attributes and elements of each class defined o Attributes and elements of each class in XML IODEF document are
in [RFC7970] with no distinction and is agnostic on the order of both presented as JSON attributes in JSON IODEF document, and the
their appearances. order of their appearances is ignored.
o Flow class is deleted, and classes with its instances now directly o Flow class is deleted, and classes with its instances now directly
have instances of EventData class that used to belong to the Flow have instances of EventData class that used to belong to the Flow
class. class.
o ApplicationHeader class is deleted, and classes with its instances o ApplicationHeader class is deleted, and classes with its instances
now directly have instances of ApplicationHeaderField class that now directly have instances of ApplicationHeaderField class that
used to belong to the ApplicationHeader class. used to belong to the ApplicationHeader class.
o SignatureData class is deleted, and classes with its instances now o SignatureData class is deleted, and classes with its instances now
directly have instance of Signature class that used to belong to directly have instance of Signature class that used to belong to
the SignatureData class. the SignatureData class.
o IndicatorData class is deleted, and classes with its instances now o IndicatorData class is deleted, and classes with its instances now
directly have the instances of Indicator class that used to belong directly have the instances of Indicator class that used to belong
to the IndicatorData class. to the IndicatorData class.
o ObservableReference class is deleted, and classes with its o ObservableReference class is deleted, and classes with its
instances now directly have uid-ref as an element. instances now directly have uid-ref as an element.
o Record class is replaced by RecordData class, and RecordData class
is renamed to Record class.
o Record class is deleted, and classes with its instances now o Record class is deleted, and classes with its instances now
directly have the instances of RecordData class that used to directly have the instances of RecordData class that used to
belong to the Record class. belong to the Record class.
o The MLStringType were modified to support simple string by o The MLStringType were modified to support simple string by
allowing the type to have not only a predefined object type but allowing the type to have not only a predefined object type but
also text type, in order to allow simple descriptions of elements also text type, in order to allow simple descriptions of elements
of the type. of the type.
o The elements of ML_STRING type in XML IODEF document are presented o The elements of ML_STRING type in XML IODEF document are presented
as either STRING type or ML_STRING type in CBOR/JSON IODEF as either STRING type or ML_STRING type in JSON IODEF document.
document.
o Data models of the extension classes defined by [RFC7203] and o Data models of the extension classes defined by [RFC7203] and
referenced by [RFC7970] are represented by StructuredInfo class referenced by [RFC7970] are represented by StructuredInfo class
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 CBOR/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.
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
skipping to change at page 21, line 40 skipping to change at page 21, line 40
"Indicator": [{ "Indicator": [{
"IndicatorID": { "IndicatorID": {
"id": "G90823490", "id": "G90823490",
"name": "csirt.example.com", "name": "csirt.example.com",
"version": "1" "version": "1"
}, },
"Description": ["C2 domains"], "Description": ["C2 domains"],
"StartTime": "2014-12-02T11:18:00-05:00", "StartTime": "2014-12-02T11:18:00-05:00",
"Observable": { "Observable": {
"BulkObservable": { "BulkObservable": {
"type": "ipv6-addr", "type": "domain-name",
"BulkObservableList": "kj290023j09r34.example.com"} "BulkObservableList": "kj290023j09r34.example.com"}
} }
}] }]
}] }]
} }
Figure 6: Indicators from a Campaign in JSON Figure 6: Indicators from a Campaign in JSON
A3 # map(3) A3 # map(3)
67 # text(7) 67 # text(7)
skipping to change at page 25, line 22 skipping to change at page 25, line 22
323031342D31322D30325431313A31383A30302D30353A3030 323031342D31322D30325431313A31383A30302D30353A3030
# "2014-12-02T11:18:00-05:00" # "2014-12-02T11:18:00-05:00"
6A # text(10) 6A # text(10)
4F627365727661626C65 # "Observable" 4F627365727661626C65 # "Observable"
A1 # map(1) A1 # map(1)
6E # text(14) 6E # text(14)
42756C6B4F627365727661626C65 # "BulkObservable" 42756C6B4F627365727661626C65 # "BulkObservable"
A2 # map(2) A2 # map(2)
64 # text(4) 64 # text(4)
74797065 # "type" 74797065 # "type"
69 # text(9) 6B # text(11)
697076362D61646472 # "ipv6-addr" 646F6D61696E2D6E616D65 # "domain-name"
72 # text(18) 72 # text(18)
42756C6B4F627365727661626C654C697374 42756C6B4F627365727661626C654C697374
# "BulkObservableList" # "BulkObservableList"
78 1A # text(26) 78 1A # text(26)
6B6A3239303032336A30397233342E6578616D706C652E636F6D 6B6A3239303032336A30397233342E6578616D706C652E636F6D
# "kj290023j09r34.example.com" # "kj290023j09r34.example.com"
Figure 7: Indicators from a Campaign in CBOR Figure 7: Indicators from a Campaign in CBOR
5. The IODEF Data Model (CDDL) 5. The IODEF Data Model (CDDL)
 End of changes. 17 change blocks. 
24 lines changed or deleted 23 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/