INTERNET-DRAFT Adam W. Montville
Intended Status: Standards Track (Tripwire)
Updates: 5070 (if approved) David Black
Expires: March 10, 2015 (EMC)
September 6, 2014
IODEF Enumeration Reference Format
draft-ietf-mile-enum-reference-format-08
Abstract
The Incident Object Description Exchange Format (IODEF) is an XML
data representation framework for sharing information about computer
security incidents. In IODEF, the Reference class provides
references to externally specified information such as a
vulnerability, IDS alert, malware sample, advisory, or attack
technique. In practice, these references are based on external
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 provides an extension to 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
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
Adam W. Montville Expires March 10, 2015 [Page 1]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Referencing External Enumerations . . . . . . . . . . . . . . 3
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5 The ReferenceName Schema . . . . . . . . . . . . . . . . . . . . 8
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 9
6.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Adam W. Montville Expires March 10, 2015 [Page 2]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
1 Introduction
There is an identified need to specify a format to include relevant
enumeration values from other data representation formats in an IODEF
[IODEF] document. It is anticipated that this requirement will exist
in other standardization efforts within several IETF Working Groups,
but the scope of this document pertains solely to IODEF [IODEF].
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Referencing External Enumerations
The need is to place enumeration identifiers and their enumeration
format references in IODEF's [IODEF] Reference class. There are
several ways to accomplish this goal, but the most appropriate at
this point is to require a specific structure for the ReferenceName
string of the IODEF [IODEF] Reference class, and use an IANA registry
to manage references to specific enumeration reference formats.
Per IODEF [IODEF] the ReferenceName is of type ML_STRING. This
becomes problematic when specific references, especially enumeration
formats such as CVE [CVE], CCE [CCE], CPE [CPE] and so on, are
referenced - how is an implementer to know which type of reference
this is, and thus how to parse it? One solution, presented here, is
to require that ReferenceName follow a particular format.
Inclusion of such enumeration values, especially those related to
security automation, is important to incident communication and
investigation. Typically, an enumeration identifier is simply an
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
Adam W. Montville Expires March 10, 2015 [Page 3]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
The ReferenceName class provides the XML representation for
identifying an enumeration and specifying a value from it. A given
enumeration is uniquely identified by the specIndex attribute. Each
specIndex value corresponds to an entry in the "Enumeration Reference
Type Identifiers" IANA registry (see Section 4). The child ID
element represents a particular value from the corresponding
enumeration identified by the specIndex attribute. The format of the
ID element is described in the IANA registry entry of the
enumeration.
+-------------------------+
| ReferenceName |
+-------------------------+
| INTEGER specIndex |<>----------[ ID ]
+-------------------------+
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:
CXI-1234-XYZ
http://cxi.example.com
Foo
Information in the IANA table (see Section 4) would include:
Full Name: Concept X Identifier
SpecIndex: 1
Version: any
Specification URI: http://cxi.example.com/spec_url
Adam W. Montville Expires March 10, 2015 [Page 4]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
2.3 Reference Method Applicability
While the scope of this document pertains to IODEF [IODEF], it
should be readily apparent that any standard needing to reference
an enumeration identified by a specially formatted string can use
this method of providing structure after the standard has been
published. In effect, this method provides a standardized
interface for enumeration formats, thus allowing a loose coupling
between a given standard and the enumeration identifiers it needs
to reference now and in the future.
Adam W. Montville Expires March 10, 2015 [Page 5]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
3 Security Considerations
Producers of IODEF [IODEF] content SHOULD be careful to ensure a
proper mapping of enumeration reference ID elements to the correct
SpecIndex. Potential consequences of not mapping correctly include
inaccurate information references and similar distribution of
misinformation.
Use of enumeration reference IDs from trusted sources SHOULD be
preferred by implementers to mitigate the risk of receiving and/or
providing misinformation. Trust decisions with respect to
enumeration reference providers are beyond the scope of this
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
content associated with an enumeration reference ID. In such a
circumstance, trust SHOULD extend from the origin of the
enumeration reference ID to the third-party, effectively making
the third-party a trusted third-party in the context of providing
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
This document specifies an identifier format for the IODEF [IODEF]
ReferenceName string of the Reference class.
Adam W. Montville Expires March 10, 2015 [Page 6]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
This memo creates the following registry for IANA to manage:
Name of the Registry: "Enumeration Reference Type Identifiers"
Fields to record in the registry:
Full Name: The full name of the enumeration as a string from
the printable ASCII character set.
Abbreviation: An abbreviation may be an acronym - it consists
of upper-case characters (at least two, upper-case is used to
avoid mismatches due to case differences), as specified by this
ABNF [RFC5234] syntax:
ABBREVIATION = 2*UC-ALPHA ; At least two
UC-ALPHA = %x41-5A ; A-Z
Multiple registrations MAY use the same Abbreviation but
MUST have different Versions.
SpecIndex: This is an IANA-assigned positive integer that
identifies the registration. The first entry added to this
registry uses the value 1, and this value is incremented for
each subsequent entry added to the registry.
Version: The version of the enumeration as a free-form string
from the printable ASCII character set excepting white space.
Specification URI: A list of one or more URIs [RFC3986] from
which the registered specification can be obtained. The
registered specification MUST be readily and publicly available
from that URI. The URI SHOULD be a stable reference to a
specific version of the specification. URIs that designate the
latest version of a specification (which changes when a new
version appears) SHOULD NOT be used.
Initial registry contents: None.
Allocation Policy: Specification Required [RFC5226] (which implies
Expert Review [RFC5226]).
The Designated Expert is expected to consult with the MILE (Managed
Incident Lightweight Exchange) working group or its successor if any
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 appropriateness of the enumeration for the attribute. If a
specification is associated with the request, it MUST be reviewed by
the Designated Expert.
Adam W. Montville Expires March 10, 2015 [Page 7]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
The Designated Expert is expected to ensure that the Full Name,
Abbreviation and Version are appropriate and that the information at
the Specification URI is sufficient to unambiguously parse
identifiers based on that specification. Additionally, the Designated
Expert should prefer short Abbreviations over long ones.
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688].
Registration request for the IODEF enumeration reference format
namespace:
URI : urn:ietf:params:xml:ns:iodef-enum-1.0
Registrant Contact : See the "Authors' Addresses" section of this
document.
XML : None.
Registration request for the IODEF enumeration reference format XML
schema:
URI : urn:ietf:params:xml:schema:iodef-enum-1.0
Registrant Contact See the "Authors' Addresses" section of this
document.
XML : See Section 6, "XML Schema", of this document.
5 The ReferenceName Schema
Adam W. Montville Expires March 10, 2015 [Page 8]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
6 References
6.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, December
2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
6.2 Informative References
[CCE] http://cce.mitre.org
[CPE] http://cpe.mitre.org
[CVE] http://cve.mitre.org
Authors' Addresses
Adam W. Montville
Adam W. Montville Expires March 10, 2015 [Page 9]
INTERNET DRAFT IODEF Enumeration Reference Format September 6, 2014
EMail: adam.w.montville@gmail.com
David Black
EMC Corporation
EMail: david.black@emc.com
Adam W. Montville Expires March 10, 2015 [Page 10]