draft-ietf-mile-enum-reference-format-04.txt   draft-ietf-mile-enum-reference-format-05.txt 
INTERNET-DRAFT Adam W. Montville INTERNET-DRAFT Adam W. Montville
Intended Status: Standards Track (Tripwire)
Updates: 5070 (if approved) David Black
Expires: November 28, 2014 (EMC)
Expires: November 8, 2014 David Black May 27, 2014
(EMC)
May 7, 2014
IODEF Enumeration Reference Format IODEF Enumeration Reference Format
draft-ietf-mile-enum-reference-format-04 draft-ietf-mile-enum-reference-format-05
Abstract Abstract
The Incident Object Description Exchange Format [IODEF] provides a The Incident Object Description Exchange Format (IODEF) provides a
Reference class used to reference external entities (such as Reference class used to reference external entities (such as
enumeration identifiers). However, the method of external entity enumeration identifiers). However, the method of external entity
identification has been left unstructured. This document describes a identification has been left unstructured. This document describes a
method to provide structure for referencing external entities for the method to provide structure for referencing external entities for the
[IODEF] Reference class. IODEF Reference class and thus updates IODEF's ReferenceName.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Referencing External Enumerations . . . . . . . . . . . . . . 3 2. Referencing External Enumerations . . . . . . . . . . . . . . 3
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 IODEF XML Schema Changes . . . . . . . . . . . . . . . . . . . . 6
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8
6.2 Informative References . . . . . . . . . . . . . . . . . . 7 6.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Introduction 1 Introduction
There is an identified need to specify a format to include relevant There is an identified need to specify a format to include relevant
enumeration values in an IODEF document. It is anticipated that this enumeration values in an IODEF document. It is anticipated that this
requirement will exist in other standardization efforts within requirement will exist in other standardization efforts within
several IETF Working Groups, but the scope of this document pertains several IETF Working Groups, but the scope of this document pertains
solely to [IODEF]. solely to IODEF [IODEF].
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Referencing External Enumerations 2. Referencing External Enumerations
The need is to place enumeration identifiers and their references in The need is to place enumeration identifiers and their references in
[IODEF]'s Reference class. There are several ways to accomplish this IODEF [IODEF]'s Reference class. There are several ways to
goal, but the most appropriate at this point is to require a specific accomplish this goal, but the most appropriate at this point is to
format for the ReferenceName string of the [IODEF] Reference class, require a specific format for the ReferenceName string of the IODEF
and use an IANA registry to manage the resulting reference formats. [IODEF] Reference class, and use an IANA registry to manage the
resulting reference formats.
+------------------+ +------------------+
| Reference | | Reference |
+------------------+ +------------------+
| |<>----------[ ReferenceName ] | |<>----------[ ReferenceName ]
| |<>--{0..*}--[ URL ] | |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
+------------------+ +------------------+
FIGURE 1: [IODEF] Reference Class FIGURE 1: IODEF [IODEF] Reference Class
Per [IODEF] the ReferenceName is of type ML_STRING. This becomes Per IODEF [IODEF] the ReferenceName is of type ML_STRING. This
problematic when specific references, especially enumerations such as becomes problematic when specific references, especially enumerations
[CVE], [CCE], [CPE] and so on, are referenced - how is an implementer such as CVE [CVE], CCE [CCE], CPE [CPE] and so on, are referenced -
to know which type of reference this is, and thus how to parse it? how is an implementer to know which type of reference this is, and
One solution, presented here, is to require that ReferenceName follow thus how to parse it? One solution, presented here, is to require
a particular format. that ReferenceName follow a particular format.
Inclusion of such enumerations, especially those related to security Inclusion of such enumerations, especially those related to security
automation, is important to incident communication and investigation. automation, is important to incident communication and investigation.
Typically, an enumeration identifier is simply an identifier with a Typically, an enumeration identifier is simply an identifier with a
specific format as defined by an external party. specific format as defined by an external party.
2.1 Reference Name Format 2.1 Reference Name Format
The Reference Name Format uses XML to provide the structure for The Reference Name Format uses XML to provide the structure for
enumeration identification, and requires that a specific Abbreviation enumeration identification, and requires that a specific Index be
and RegistryVersion be associated with the ID. An implementer can associated with the ID. An implementer can look up the ID type (as
look up the ID type (as referenced by the logical tuple of referenced by the Index) in the IANA table (see Section 4) to
Abbreviation and Index) in the IANA table (see Section 4) to understand how the ID is structured. The Index field in the XML
understand how the ID is structured. Multiple registry entries may unambiguously indicates which IANA registry entry is to be used to
use the same abbreviation. The Index field in the XML unambiguously correctly reference the enumeration specification, which avoids
indicates which IANA registry entry is to be used to correctly interpretation of version strings that may have specification-
reference the enumeration specification, which avoids interpretation specific formats.
of version strings that may have specification-specific formats.
<Reference> <Reference>
<ReferenceName> <ReferenceName>
<EnumRef> <Index>1</Index>
<Abbreviation>CXI</Abbreviation> <ID>CXI-1234-XYZ</ID>
<Index>1</Index>
<ID>CXI-1234-XYZ</ID>
</EnumRef>
</ReferenceName> </ReferenceName>
<URL>http://cxi.example.com</URL> <URL>http://cxi.example.com</URL>
<Description>Foo</Description> <Description>Foo</Description>
</Reference> </Reference>
LISTING 1: Example Use of IODEF Enumeration Reference Format LISTING 1: Example Use of IODEF Enumeration Reference Format
Information in the IANA table (see Section 4) would include: Information in the IANA table (see Section 4) would include:
Full Name: Concept X Identifier Full Name: Concept X Identifier
Abbreviation: CXI
Index: 1 Index: 1
Version: any Version: any
Specification URI: http://cxi.example.com/spec_url Specification URI: http://cxi.example.com/spec_url
2.3 Reference Method Applicability 2.3 Reference Method Applicability
While the scope of this document pertains to [IODEF], it should be While the scope of this document pertains to IODEF [IODEF], it
readily apparent that any standard needing to reference an should be readily apparent that any standard needing to reference
enumeration identified by a specially formatted string can use an enumeration identified by a specially formatted string can use
this method of providing structure after the standard has been this method of providing structure after the standard has been
published. In effect, this method provides a standardized published. In effect, this method provides a standardized
interface for enumerations, thus allowing a loose coupling between interface for enumerations, thus allowing a loose coupling between
a given standard and the enumeration identifiers it needs to a given standard and the enumeration identifiers it needs to
reference now and in the future. reference now and in the future.
3 Security Considerations 3 Security Considerations
Producers of [IODEF] content SHOULD be careful to ensure a proper Producers of IODEF [IODEF] content SHOULD be careful to ensure a
mapping of EnumRef ID elements to the correct Index. Potential proper mapping of enumeration reference ID elements to the correct
consequences of not mapping correctly include inaccurate Index. Potential consequences of not mapping correctly include
information references and similar distribution of misinformation. inaccurate information references and similar distribution of
misinformation.
Use of EnumRef IDs from trusted sources SHOULD be preferred by Use of enumeration reference IDs from trusted sources SHOULD be
implementers to mitigate the risk of receiving and/or providing preferred by implementers to mitigate the risk of receiving and/or
misinformation. Trust decisions with respect to enumeration providing misinformation. Trust decisions with respect to
reference providers is beyond the scope of this document. enumeration reference providers is beyond the scope of this
document.
In some cases it might be possible for a third-party to host In some cases it might be possible for a third-party to host
content associated with an EnumRef ID. In such a circumstance, content associated with an enumeration reference ID. In such a
trust SHOULD extend from the origin of the EnumRef ID to the circumstance, trust SHOULD extend from the origin of the
third-party, effectively making the third-party a trusted third- enumeration reference ID to the third-party, effectively making
party in the context of providing a particular set of EnumRef IDs. the third-party a trusted third-party in the context of providing
a particular set of enumeration reference IDs.
4 IANA Considerations 4 IANA Considerations
This document specifies an identifier format for the [IODEF] This document specifies an identifier format for the IODEF [IODEF]
ReferenceName string of the Reference class. ReferenceName string of the Reference class.
This memo creates the following registry for IANA to manage: This memo creates the following registry for IANA to manage:
Name of the Registry: "Enumeration Reference Type Identifiers" Name of the Registry: "Enumeration Reference Type Identifiers"
Note that certain name requests should not be permitted as either
Full Name or Abbreviation entries for the requested IANA table.
Fields to record in the registry: Fields to record in the registry:
Full Name: The full name of the enumeration as a string from Full Name: The full name of the enumeration as a string from
the printable ASCII character set. the printable ASCII character set.
Abbreviation: An abbreviation may be an acronym - it consists Abbreviation: An abbreviation may be an acronym - it consists
of upper-case characters (at least two, upper-case is used to of upper-case characters (at least two, upper-case is used to
avoid mismatches due to case differences), as specified by this avoid mismatches due to case differences), as specified by this
ABNF [RFC5234] syntax: ABNF [RFC5234] syntax:
skipping to change at page 6, line 21 skipping to change at page 6, line 21
Specification URI: A list of one or more URIs [RFC3986] from Specification URI: A list of one or more URIs [RFC3986] from
which the registered specification can be obtained. The which the registered specification can be obtained. The
registered specification MUST be readily and publicly available registered specification MUST be readily and publicly available
from that URI. The URI SHOULD be a stable reference to a from that URI. The URI SHOULD be a stable reference to a
specific version of the specification. URIs that designate the specific version of the specification. URIs that designate the
latest version of a specification (which changes when a new latest version of a specification (which changes when a new
version appears) SHOULD NOT be used. version appears) SHOULD NOT be used.
Initial registry contents: None. Initial registry contents: None.
Allocation Policy: Expert Review [RFC5226] and Specification Allocation Policy: Specification Required [RFC5226] (which implies
Required [RFC5226] Expert Review [RFC5226]).
The Designated Expert is expected to consult with the MILE (Managed The Designated Expert is expected to consult with the MILE (Managed
Incident Lightweight Exchange) working group or its successor if any Incident Lightweight Exchange) working group or its successor if any
such WG exists (e.g., via email to the working group's mailing list). such WG exists (e.g., via email to the working group's mailing list).
The Designated Expert is expected to review the request and validate The Designated Expert is expected to review the request and validate
the appropriateness of the enumeration for the attribute. If a the appropriateness of the enumeration for the attribute. If a
specification is associated with the request, it MUST be reviewed by specification is associated with the request, it MUST be reviewed by
the Designated Expert. the Designated Expert.
The Designated Expert is expected to ensure that the Full Name, The Designated Expert is expected to ensure that the Full Name,
Abbreviation and Version are appropriate and that the information at Abbreviation and Version are appropriate and that the information at
the Specification URI is sufficient to unambiguously parse the Specification URI is sufficient to unambiguously parse
identifiers based on that specification. Additionally, the Designated identifiers based on that specification. Additionally, the Designated
Expert should prefer short Abbreviations over long ones. Expert should prefer short Abbreviations over long ones.
5 XML Schema 5 IODEF XML Schema Changes
<?xml version="1.0" encoding="UTF-8"?> The changes to the IODEF [IODEF] schema are detailed below. Note
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" that in addition to the element changes described below, certain
elementFormDefault="qualified"> attributes of the xs:schema element in the schema document should be
<xs:element name="EnumRef"> updated, as well as certain information in the document class.
<xs:complexType>
<xs:sequence>
<xs:element ref="Abbreviation"/>
<xs:element ref="Index"/>
<xs:element ref="ID"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Abbreviation" type="xs:NCName"/>
<xs:element name="Index" type="xs:integer"/>
<xs:element name="ID" type="xs:NCName"/>
</xs:schema>
LISTING 2: IODEF Enumeration Reference Format Schema The xs:schema attributes are updated as follows:
The root element of the XML schema listed here can be contained targetNamespace="urn:ietf:params:xml:ns:iodef-1.01"
within the IODEF XML as showin in Listing 1 of Section 2.1.
xmlns="urn:ietf:params:xml:ns:iodef-1.01"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.01"
The IODEF-Document element description is updated to have a fixed
version of "1.01" instead of "1.00", such that:
<xs:element name="IODEF-Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Incident" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" fixed="1.00"/>
<xs:attribute name="lang" type="xs:language" use="required"/>
<xs:attribute name="formatid" type="xs:string"/>
</xs:complexType>
</xs:element>
Is changed to:
<xs:element name="IODEF-Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Incident" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" fixed="1.01"/>
<xs:attribute name="lang" type="xs:language" use="required"/>
<xs:attribute name="formatid" type="xs:string"/>
</xs:complexType>
</xs:element>
The ReferenceName element is updated by replacing the following line
in the 1.00 schema:
<xs:element name="ReferenceName" type="iodef:MLStringType"/>
With:
<xs:element name="ReferenceName">
<xs:complexType>
<xs:sequence>
<xs:element name="Index" type="xs:integer"/>
<xs:element name="ID" type="xs:NCName"/>
</xs:sequence>
</xs:complexType>
</xs:element>
LISTING 2: IODEF Enumeration Reference Format Schema Changes
This change to the IODEF [IODEF] schema may cause interoperability
issues depending on tool implementation. If strict schema validation
is used by a 1.00 tool when parsing an incoming IODEF [IODEF] 1.01
document, the elements under ReferenceName may not be understood and
could cause errors. If strict schema validation is not used when
parsing an incoming IODEF [IODEF] 1.01 document with a 1.00 tool, the
elements under ReferenceName should simply be present in the object
model, but this may lead to unpredictable results.
Implementers are encouraged to update their code to handle the IODEF
[IODEF] 1.00 schema and the 1.01 schemas explicitly to avoid any
unhandled exceptions that may occur when a 1.00 implementation
attempts to parse a 1.01 document.
6 References 6 References
6.1 Normative References 6.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, December Object Description Exchange Format", RFC 5070, December
skipping to change at page 7, line 46 skipping to change at page 9, line 4
6.2 Informative References 6.2 Informative References
[CCE] http://cce.mitre.org [CCE] http://cce.mitre.org
[CPE] http://cpe.mitre.org [CPE] http://cpe.mitre.org
[CVE] http://cve.mitre.org [CVE] http://cve.mitre.org
Authors' Addresses Authors' Addresses
Adam W. Montville Adam W. Montville
EMail: adam@stoicsecurity.org
EMail: adam@stoicsecurity.com
David Black David Black
EMC Corporation EMC Corporation
EMail: david.black@emc.com EMail: david.black@emc.com
 End of changes. 27 change blocks. 
82 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/