draft-ietf-mile-enum-reference-format-07.txt   draft-ietf-mile-enum-reference-format-08.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: January 24, 2015 (EMC) Expires: March 10, 2015 (EMC)
July 23, 2014 September 6, 2014
IODEF Enumeration Reference Format IODEF Enumeration Reference Format
draft-ietf-mile-enum-reference-format-07 draft-ietf-mile-enum-reference-format-08
Abstract Abstract
The Incident Object Description Exchange Format (IODEF) is an XML The Incident Object Description Exchange Format (IODEF) is an XML
data representation framework for sharing information about computer data representation framework for sharing information about computer
security incidents. In IODEF, the Reference class provides security incidents. In IODEF, the Reference class provides
references to externally specified information such as a references to externally specified information such as a
vulnerability, IDS alert, malware sample, advisory, or attack vulnerability, IDS alert, malware sample, advisory, or attack
technique. In practice, these references are based on external technique. In practice, these references are based on external
enumeration specifications that define both the enumeration format enumeration specifications that define both the enumeration format
and the specific enumeration values, but the IODEF Reference class and the specific enumeration values, but the IODEF Reference class
(as specified in RFC 5070) does not indicate how to include both of (as specified in RFC 5070) does not indicate how to include both of
these important pieces of information. these important pieces of information.
This memo updates RFC 5070 to include both the external specification This memo provides an extension to RFC 5070 to include both the
and specific enumeration value in the IODEF Reference class. This external specification and specific enumeration value in the IODEF
memo also establishes an IANA registry to manage external enumeration Reference class. This memo also establishes an IANA registry to
specifications for use by IODEF. 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 41 skipping to change at page 2, line 41
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
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 . . . . . . . . . . . . . . . . . . . . 6
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5 IODEF XML Schema Changes . . . . . . . . . . . . . . . . . . . . 7 5 The ReferenceName Schema . . . . . . . . . . . . . . . . . . . . 8
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9
6.2 Informative References . . . . . . . . . . . . . . . . . . 9 6.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 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 from other data representation formats in an IODEF enumeration values from other data representation formats in an IODEF
[IODEF] document. It is anticipated that this requirement will exist [IODEF] document. It is anticipated that this requirement will exist
in other standardization efforts within several IETF Working Groups, in other standardization efforts within several IETF Working Groups,
but the scope of this document pertains solely to IODEF [IODEF]. but the scope of this document pertains solely to IODEF [IODEF].
skipping to change at page 4, line 4 skipping to change at page 4, line 4
ReferenceName is an identifier that is formatted in a specific ReferenceName is an identifier that is formatted in a specific
manner, and which identifies some set of associated information. manner, and which identifies some set of associated information.
For example, a vulnerability identifier following the CVE [CVE] For example, a vulnerability identifier following the CVE [CVE]
formatting specification may be: CVE-2014-0001. That identifier is formatting specification may be: CVE-2014-0001. That identifier is
formatted in a specific manner and relates to information about a formatted in a specific manner and relates to information about a
specific vulnerability. Communicating the format for the identifier specific vulnerability. Communicating the format for the identifier
is the subject of this document. 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 ReferenceName class provides the XML representation for
enumeration identification, and requires that a SpecIndex be identifying an enumeration and specifying a value from it. A given
associated with the ID. An implementer can look up the ID type (as enumeration is uniquely identified by the specIndex attribute. Each
referenced by the SpecIndex) in the IANA table (see Section 4) to specIndex value corresponds to an entry in the "Enumeration Reference
understand how the ID is structured. The SpecIndex field in the XML Type Identifiers" IANA registry (see Section 4). The child ID
unambiguously indicates which IANA registry entry is to be used to element represents a particular value from the corresponding
correctly reference the enumeration specification, which avoids enumeration identified by the specIndex attribute. The format of the
interpretation of version strings that may have specification- ID element is described in the IANA registry entry of the
specific formats. enumeration.
<Reference> +-------------------------+
<ReferenceName specIndex="1"> | ReferenceName |
<ID>CXI-1234-XYZ</ID> +-------------------------+
</ReferenceName> | INTEGER specIndex |<>----------[ ID ]
<URL>http://cxi.example.com</URL> +-------------------------+
<Description>Foo</Description>
</Reference>
LISTING 1: Example Use of IODEF Enumeration Reference Format Figure 1: The ReferenceName Class
The aggregate classes that constitute ReferenceName:
ID
One. ID. Name of the reference.
The ReferenceName class has one attribute.
specIndex
Required. INTEGER. Enumeration identifier. This value
corresponds to an entry in the "Enumeration Reference Type
Identifiers" IANA registry with an identical SpecIndex value.
An example of such a reference is as follows:
<iodef:Reference>
<iodef-enum:ReferenceName specIndex="1">
<iodef-enum:ID>CXI-1234-XYZ</iodef-enum:ID>
</iodef-enum:ReferenceName>
<iodef:URL>http://cxi.example.com</iodef:URL>
<iodef:Description>Foo</iodef:Description>
</iodef:Reference>
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
SpecIndex: 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
skipping to change at page 7, line 11 skipping to change at page 8, line 11
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 IODEF XML Schema Changes This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688].
The changes to the IODEF [IODEF] schema are detailed below. Note
that in addition to the element changes described below, certain
attributes of the xs:schema element in the schema document should be
updated, as well as certain information in the document class.
The xs:schema attributes are updated as follows:
targetNamespace="urn:ietf:params:xml:ns:iodef-1.01"
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 Registration request for the IODEF enumeration reference format
version of "1.01" instead of "1.00", such that: namespace:
<xs:element name="IODEF-Document"> URI : urn:ietf:params:xml:ns:iodef-enum-1.0
<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: Registrant Contact : See the "Authors' Addresses" section of this
document.
<xs:element name="IODEF-Document"> XML : None.
<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 Registration request for the IODEF enumeration reference format XML
in the 1.00 schema: schema:
<xs:element name="ReferenceName" type="iodef:MLStringType"/> URI : urn:ietf:params:xml:schema:iodef-enum-1.0
With: Registrant Contact See the "Authors' Addresses" section of this
document.
<xs:element name="ReferenceName"> XML : See Section 6, "XML Schema", of this document.
<xs:complexType>
<xs:sequence>
<xs:element name="ID" type="xs:NCName"/>
</xs:sequence>
<xs:attribute name="specIndex" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
LISTING 2: IODEF Enumeration Reference Format Schema Changes 5 The ReferenceName Schema
This change to the IODEF [IODEF] schema may cause interoperability <?xml version="1.0" encoding="UTF-8"?>
issues depending on tool implementation. If strict schema validation <xs:schema attributeFormDefault="unqualified"
is used by a 1.00 tool when parsing an incoming IODEF [IODEF] 1.01 elementFormDefault="qualified"
document, the elements under ReferenceName may not be understood and targetNamespace="urn:ietf:params:xml:ns:iodef-enum-1.0"
could cause errors. If strict schema validation is not used when xmlns:xs="http://www.w3.org/2001/XMLSchema"
parsing an incoming IODEF [IODEF] 1.01 document with a 1.00 tool, the xmlns:enum="urn:ietf:params:xml:ns:iodef-enum-1.0">
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 === ReferenceName ===
attempts to parse a 1.01 document. ==========================================================
-->
<xs:element name="ReferenceName">
<xs:complexType>
<xs:sequence>
<xs:element name="ID" type="xs:NCName"/>
</xs:sequence>
<xs:attribute name="specIndex"
type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
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 9, line 11 skipping to change at page 9, line 33
May 2008. May 2008.
[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, January 2005. RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008. 2008.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
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
 End of changes. 21 change blocks. 
91 lines changed or deleted 88 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/