draft-ietf-mile-enum-reference-format-06.txt   draft-ietf-mile-enum-reference-format-07.txt 
INTERNET-DRAFT Adam W. Montville INTERNET-DRAFT Adam W. Montville
Intended Status: Standards Track (Tripwire) Intended Status: Standards Track (Tripwire)
Updates: 5070 (if approved) David Black Updates: 5070 (if approved) David Black
Expires: December 22, 2014 (EMC) Expires: January 24, 2015 (EMC)
June 20, 2014 July 23, 2014
IODEF Enumeration Reference Format IODEF Enumeration Reference Format
draft-ietf-mile-enum-reference-format-06 draft-ietf-mile-enum-reference-format-07
Abstract Abstract
The Incident Object Description Exchange Format (IODEF) provides a The Incident Object Description Exchange Format (IODEF) is an XML
Reference class used to reference external entities (such as data representation framework for sharing information about computer
enumeration identifiers). However, the method of external entity security incidents. In IODEF, the Reference class provides
identification has been left unstructured. This document describes a references to externally specified information such as a
method to provide structure for referencing external entities for the vulnerability, IDS alert, malware sample, advisory, or attack
IODEF Reference class and thus updates IODEF's ReferenceName technique. In practice, these references are based on external
(RFC5070). enumeration specifications that define both the enumeration format
and the specific enumeration values, but the IODEF Reference class
(as specified in RFC 5070) does not indicate how to include both of
these important pieces of information.
This memo updates RFC 5070 to include both the external specification
and specific enumeration value in the IODEF Reference class. This
memo also establishes an IANA registry to manage external enumeration
specifications for use by IODEF.
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 35 skipping to change at page 2, line 43
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 IODEF XML Schema Changes . . . . . . . . . . . . . . . . . . . . 6 5 IODEF XML Schema Changes . . . . . . . . . . . . . . . . . . . . 7
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8
6.2 Informative References . . . . . . . . . . . . . . . . . . 8 6.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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 from other data representation formats in an IODEF
requirement will exist in other standardization efforts within [IODEF] document. It is anticipated that this requirement will exist
several IETF Working Groups, but the scope of this document pertains in other standardization efforts within several IETF Working Groups,
solely to IODEF [IODEF]. but the scope of this document pertains 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 enumeration
IODEF [IODEF]'s Reference class. There are several ways to format references in IODEF's [IODEF] Reference class. There are
accomplish this goal, but the most appropriate at this point is to several ways to accomplish this goal, but the most appropriate at
require a specific format for the ReferenceName string of the IODEF this point is to require a specific structure for the ReferenceName
[IODEF] Reference class, and use an IANA registry to manage the string of the IODEF [IODEF] Reference class, and use an IANA registry
resulting reference formats. to manage references to specific enumeration reference formats.
+------------------+
| Reference |
+------------------+
| |<>----------[ ReferenceName ]
| |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ Description ]
+------------------+
FIGURE 1: IODEF [IODEF] Reference Class
Per IODEF [IODEF] the ReferenceName is of type ML_STRING. This Per IODEF [IODEF] the ReferenceName is of type ML_STRING. This
becomes problematic when specific references, especially enumerations becomes problematic when specific references, especially enumeration
such as CVE [CVE], CCE [CCE], CPE [CPE] and so on, are referenced - formats such as CVE [CVE], CCE [CCE], CPE [CPE] and so on, are
how is an implementer to know which type of reference this is, and referenced - how is an implementer to know which type of reference
thus how to parse it? One solution, presented here, is to require this is, and thus how to parse it? One solution, presented here, is
that ReferenceName follow a particular format. to require that ReferenceName follow a particular format.
Inclusion of such enumerations, especially those related to security Inclusion of such enumeration values, especially those related to
automation, is important to incident communication and investigation. security automation, is important to incident communication and
Typically, an enumeration identifier is simply an identifier with a investigation. Typically, an enumeration identifier is simply an
specific format as defined by an external party. identifier with a specific format as defined by an external party.
Further, that enumeration identifier is itself a reference to
specific information associated with the identifier. Thus, the
ReferenceName is an identifier that is formatted in a specific
manner, and which identifies some set of associated information.
For example, a vulnerability identifier following the CVE [CVE]
formatting specification may be: CVE-2014-0001. That identifier is
formatted in a specific manner and relates to information about a
specific vulnerability. Communicating the format for the identifier
is the subject of this document.
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 Index be enumeration identification, and requires that a SpecIndex be
associated with the ID. An implementer can look up the ID type (as associated with the ID. An implementer can look up the ID type (as
referenced by the Index) in the IANA table (see Section 4) to referenced by the SpecIndex) 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. The SpecIndex field in the XML
unambiguously indicates which IANA registry entry is to be used to unambiguously indicates which IANA registry entry is to be used to
correctly reference the enumeration specification, which avoids correctly reference the enumeration specification, which avoids
interpretation of version strings that may have specification- interpretation of version strings that may have specification-
specific formats. specific formats.
<Reference> <Reference>
<ReferenceName> <ReferenceName specIndex="1">
<Index>1</Index>
<ID>CXI-1234-XYZ</ID> <ID>CXI-1234-XYZ</ID>
</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
Index: 1 SpecIndex: 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 [IODEF], it While the scope of this document pertains to IODEF [IODEF], it
should be readily apparent that any standard needing to reference should be readily apparent that any standard needing to reference
an 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 enumeration formats, thus allowing a loose coupling
a given standard and the enumeration identifiers it needs to between a given standard and the enumeration identifiers it needs
reference now and in the future. to reference now and in the future.
3 Security Considerations 3 Security Considerations
Producers of IODEF [IODEF] content SHOULD be careful to ensure a Producers of IODEF [IODEF] content SHOULD be careful to ensure a
proper mapping of enumeration reference ID elements to the correct proper mapping of enumeration reference ID elements to the correct
Index. Potential consequences of not mapping correctly include SpecIndex. Potential consequences of not mapping correctly include
inaccurate information references and similar distribution of inaccurate information references and similar distribution of
misinformation. misinformation.
Use of enumeration reference IDs from trusted sources SHOULD be Use of enumeration reference IDs from trusted sources SHOULD be
preferred by implementers to mitigate the risk of receiving and/or preferred by implementers to mitigate the risk of receiving and/or
providing misinformation. Trust decisions with respect to providing misinformation. Trust decisions with respect to
enumeration reference providers is beyond the scope of this enumeration reference providers are beyond the scope of this
document. document. However, receiving an IODEF [IODEF] document containing
an unknown ReferenceName (i.e. the SpecIndex does not exist in the
IANA table) may indicate a misled or malicious source.
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 enumeration reference ID. In such a content associated with an enumeration reference ID. In such a
circumstance, trust SHOULD extend from the origin of the circumstance, trust SHOULD extend from the origin of the
enumeration reference ID to the third-party, effectively making enumeration reference ID to the third-party, effectively making
the third-party a trusted third-party in the context of providing the third-party a trusted third-party in the context of providing
a particular set of enumeration reference IDs. a particular set of enumeration reference IDs.
This document is establishing a container for publicly available
enumeration values to be included in an IODEF [IODEF] document,
and it is important to note the distinction between the
enumeration value's format and the information conveyed by the
value itself. While the enumeration value may hold information
deemed to be private by relying parties, the enumeration format is
likely not subject to privacy concerns.
However, if the Reference class includes an enumeration value in
combination with other data in an IODEF [IODEF] document, the
resulting combination could expose information. An example might
include attack vectors or system descriptions used in a privacy-
related incident. As such, the reader is referred to the IODEF
[IODEF] Security Considerations section, which explicitly covers
protecting IODEF [IODEF] documents in transit and at rest,
ensuring proper recipient authentication, data confidence levels,
underlying transport security characteristics, and proper use of
IODEF's restriction attribute.
4 IANA Considerations 4 IANA Considerations
This document specifies an identifier format for the IODEF [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"
Fields to record in the registry: Fields to record in the registry:
skipping to change at page 5, line 51 skipping to change at page 6, line 25
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:
ABBREVIATION = 2*UC-ALPHA ; At least two ABBREVIATION = 2*UC-ALPHA ; At least two
UC-ALPHA = %x41-5A ; A-Z UC-ALPHA = %x41-5A ; A-Z
Multiple registrations MAY use the same Abbreviation but Multiple registrations MAY use the same Abbreviation but
MUST have different Versions. MUST have different Versions.
Index: This is an IANA-assigned positive integer that SpecIndex: This is an IANA-assigned positive integer that
identifies the registration. The first entry added to this identifies the registration. The first entry added to this
registry uses the value 1, and this value is incremented for registry uses the value 1, and this value is incremented for
each subsequent entry added to the registry. each subsequent entry added to the registry.
Version: The version of the enumeration as a free-form string Version: The version of the enumeration as a free-form string
from the printable ASCII character set excepting white space. from the printable ASCII character set excepting white space.
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
skipping to change at page 7, line 40 skipping to change at page 8, line 13
</xs:element> </xs:element>
The ReferenceName element is updated by replacing the following line The ReferenceName element is updated by replacing the following line
in the 1.00 schema: in the 1.00 schema:
<xs:element name="ReferenceName" type="iodef:MLStringType"/> <xs:element name="ReferenceName" type="iodef:MLStringType"/>
With: With:
<xs:element name="ReferenceName"> <xs:element name="ReferenceName">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="Index" type="xs:integer"/> <xs:element name="ID" type="xs:NCName"/>
<xs:element name="ID" type="xs:NCName"/> </xs:sequence>
</xs:sequence> <xs:attribute name="specIndex" type="xs:integer" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
LISTING 2: IODEF Enumeration Reference Format Schema Changes LISTING 2: IODEF Enumeration Reference Format Schema Changes
This change to the IODEF [IODEF] schema may cause interoperability This change to the IODEF [IODEF] schema may cause interoperability
issues depending on tool implementation. If strict schema validation issues depending on tool implementation. If strict schema validation
is used by a 1.00 tool when parsing an incoming IODEF [IODEF] 1.01 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 document, the elements under ReferenceName may not be understood and
could cause errors. If strict schema validation is not used when 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 parsing an incoming IODEF [IODEF] 1.01 document with a 1.00 tool, the
skipping to change at page 9, line 4 skipping to change at page 9, line 20
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.com EMail: adam.w.montville@gmail.com
David Black David Black
EMC Corporation EMC Corporation
EMail: david.black@emc.com EMail: david.black@emc.com
 End of changes. 22 change blocks. 
62 lines changed or deleted 91 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/