draft-ietf-mile-enum-reference-format-10.txt   draft-ietf-mile-enum-reference-format-11.txt 
INTERNET-DRAFT Adam W. Montville INTERNET-DRAFT Adam W. Montville
Intended Status: Standards Track (CIS) Intended Status: Standards Track (CIS)
Expires: May 29, 2015 David Black Expires: June 22, 2015 David Black
(EMC) (EMC)
November 25, 2014 December 19, 2014
IODEF Enumeration Reference Format IODEF Enumeration Reference Format
draft-ietf-mile-enum-reference-format-10 draft-ietf-mile-enum-reference-format-11
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 IODEF v1 in RFC 5070) does not indicate how to
these important pieces of information. include both of these important pieces of information.
This memo establishes a stand-alone data format to include both the This memo establishes a stand-alone data format to include both the
external specification and specific enumeration value, and external specification and specific enumeration identification value,
establishes an IANA registry to manage external enumeration and establishes an IANA registry to manage external enumeration
specifications. While this memo does not update IODEF, it provides specifications. While this memo does not update IODEV v1, this
the ability for future revisions of IODEF to leverage the enumeration reference format is used in IODEF v2 and is applicable to
ReferenceName class herein described. other formats that support this class of enumeration references.
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 48 skipping to change at page 2, line 48
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 . . . . . . . . . . . . . . . . . . . . 6 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5 The ReferenceName Schema . . . . . . . . . . . . . . . . . . . . 8 5 The ReferenceName Schema . . . . . . . . . . . . . . . . . . . . 8
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9
6.2 Informative References . . . . . . . . . . . . . . . . . . 9 6.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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 document. It is anticipated that this requirement will exist in other
in other standardization efforts within several IETF Working Groups, standardization efforts within several IETF Working Groups, but the
but the scope of this document pertains solely to IODEF [IODEF]. scope of this document pertains solely to IODEF. This format is used
in IODEF v2 [I-D.draft-ietf-mile-rfc5070-bis] which replaces the
original IODEF v1 [IODEF] specification.
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 enumeration The need is to place enumeration identifiers and their enumeration
format references in IODEF's [IODEF] Reference class. There are format references in IODEF's Reference class. There are several ways
several ways to accomplish this goal, but the most appropriate at to accomplish this goal, but the most appropriate at this point is to
this point is to require a specific structure for the ReferenceName require a specific structure for the ReferenceName string of the
string of the IODEF [IODEF] Reference class, and use an IANA registry IODEF Reference class, and use an IANA registry to manage references
to manage references to specific enumeration reference formats. to specific enumeration reference formats.
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 enumeration becomes problematic when specific references, especially enumeration
formats such as CVE [CVE], CCE [CCE], CPE [CPE] and so on, are formats such as CVE [CVE], CCE [CCE], CPE [CPE] and so on, are
referenced - how is an implementer to know which type of reference referenced - how is an implementer to know which type of reference
this is, and thus how to parse it? One solution, presented here, is this is, and thus how to parse it? One solution, presented here, is
to require that ReferenceName follow a particular format. to require that ReferenceName follow a particular format.
Inclusion of such enumeration values, especially those related to Inclusion of such enumeration values, especially those related to
security automation, is important to incident communication and security automation, is important to incident communication and
skipping to change at page 5, line 5 skipping to change at page 5, line 6
<iodef:Description>Foo</iodef:Description> <iodef:Description>Foo</iodef:Description>
</iodef:Reference> </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.2 Reference Method Applicability
While the scope of this document pertains to IODEF [IODEF], it While the scope of this document pertains to IODEF, it should be
should be readily apparent that any standard needing to reference readily apparent that any standard needing to reference an
an enumeration identified by a specially formatted string can use 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 enumeration formats, thus allowing a loose coupling interface for enumeration formats, thus allowing a loose coupling
between a given standard and the enumeration identifiers it needs between a given standard and the enumeration identifiers it needs
to 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
skipping to change at page 6, line 49 skipping to change at page 6, line 49
include attack vectors or system descriptions used in a privacy- include attack vectors or system descriptions used in a privacy-
related incident. As such, the reader is referred to the IODEF related incident. As such, the reader is referred to the IODEF
[IODEF] Security Considerations section, which explicitly covers [IODEF] Security Considerations section, which explicitly covers
protecting IODEF [IODEF] documents in transit and at rest, protecting IODEF [IODEF] documents in transit and at rest,
ensuring proper recipient authentication, data confidence levels, ensuring proper recipient authentication, data confidence levels,
underlying transport security characteristics, and proper use of underlying transport security characteristics, and proper use of
IODEF's restriction attribute. IODEF's restriction attribute.
4 IANA Considerations 4 IANA Considerations
This document specifies an identifier format for the IODEF [IODEF] This document specifies an enumeration reference identifier
ReferenceName string of the Reference class. All fields, format. All fields, including abbreviation, are mandatory.
including abbreviation, are mandatory.
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: "Security External Enumeration Registry"
Location of Registry: https://www.iana.org/assignments/sec-ext-
enum
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 7, line 34 skipping to change at page 7, line 37
SpecIndex: 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 (i.e. the referenced Version: The version of the enumeration (i.e. the referenced
specification) as a free-form string from the printable ASCII specification) as a free-form string from the printable ASCII
character set excepting white space. character set excepting white space.
Specification URI: A list of one or more URIs [RFC3986] from Specification URI/Reference: A list of one or more URIs
which the registered specification can be obtained. The [RFC3986] from which the registered specification can be
registered specification MUST be readily and publicly available obtained. The registered specification MUST be readily and
from that URI. The URI SHOULD be a stable reference to a publicly available from that URI. The URI SHOULD be a stable
specific version of the specification. URIs that designate the reference to a specific version of the specification. URIs
latest version of a specification (which changes when a new that designate the latest version of a specification (which
version appears) SHOULD NOT be used. changes when a new version appears) SHOULD NOT be used.
Initial registry contents: None. Initial registry contents: None.
Allocation Policy: Specification Required [RFC5226] (which implies Allocation Policy: Specification Required [RFC5226] (which implies
Expert Review [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.
skipping to change at page 9, line 40 skipping to change at page 9, line 44
[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, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
6.2 Informative References 6.2 Informative References
[I-D.draft-ietf-mile-rfc5070-bis] Danyliw, R., and Stoecker, P., "The
Incident Object Description Exchange Format v2", draft-
ietf-mile-rfc5070-bis-10 (work in progress), November
2014.
[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.w.montville@gmail.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. 16 change blocks. 
34 lines changed or deleted 45 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/