[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-montville-mile-enum-reference-format) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 7495

INTERNET-DRAFT                                         Adam W. Montville
Intended Status: Standards Track                                   (CIS)
Expires: June 22, 2015                                       David Black

                                                       December 19, 2014

                  IODEF Enumeration Reference Format


   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 IODEF v1 in RFC 5070) does not indicate how to
   include both of these important pieces of information.

   This memo establishes a stand-alone data format to include both the
   external specification and specific enumeration identification value,
   and establishes an IANA registry to manage external enumeration
   specifications.  While this memo does not update IODEV v1, this
   enumeration reference format is used in IODEF v2 and is applicable to
   other formats that support this class of enumeration references.

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 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."

Adam W. Montville        Expires June 22, 2015                  [Page 1]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 2014

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

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 . . . . . . . . . . . . . . . . . . . . . . . . 10

Adam W. Montville        Expires June 22, 2015                  [Page 2]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 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
   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. 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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 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 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.

Adam W. Montville        Expires June 22, 2015                  [Page 3]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 2014

 2.1 Reference Name Format

   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

         | ReferenceName           |
         | INTEGER specIndex       |<>----------[ ID    ]

                   Figure 1: The ReferenceName Class

   The aggregate classes that constitute ReferenceName:

        One. ID. Name of the reference.

   The ReferenceName class has one attribute.

        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-enum:ReferenceName specIndex="1">

   Information in the IANA table (see Section 4) would include:

      Full Name: Concept X Identifier
      SpecIndex: 1
      Version: any

Adam W. Montville        Expires June 22, 2015                  [Page 4]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 2014

      Specification URI: http://cxi.example.com/spec_url

 2.2 Reference Method Applicability

      While the scope of this document pertains to 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 June 22, 2015                  [Page 5]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 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

      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 enumeration reference identifier
      format.  All fields, including abbreviation, are mandatory.

Adam W. Montville        Expires June 22, 2015                  [Page 6]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 2014

      This memo creates the following registry for IANA to manage:

      Name of the Registry: "Security External Enumeration Registry"

      Location of Registry: https://www.iana.org/assignments/sec-ext-

      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 (i.e. the referenced
         specification) as a free-form string from the printable ASCII
         character set excepting white space.

         Specification URI/Reference: 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).

Adam W. Montville        Expires June 22, 2015                  [Page 7]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 2014

   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.

   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

   URI  : urn:ietf:params:xml:ns:iodef-enum-1.0

   Registrant Contact  : See the "Authors' Addresses" section of this

   XML  : None.

   Registration request for the IODEF enumeration reference format XML

   URI  : urn:ietf:params:xml:schema:iodef-enum-1.0

   Registrant Contact  See the "Authors' Addresses" section of this

   XML  : See Section 6, "XML Schema", of this document.

5 The ReferenceName Schema

      <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema attributeFormDefault="unqualified"

       ===  ReferenceName                                     ===

Adam W. Montville        Expires June 22, 2015                  [Page 8]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 2014

       <xs:element name="ReferenceName">
             <xs:element name="ID" type="xs:NCName"/>
           <xs:attribute name="specIndex"
                         type="xs:integer" use="required"/>

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

   [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

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

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

   [CCE] http://cce.mitre.org

   [CPE] http://cpe.mitre.org

Adam W. Montville        Expires June 22, 2015                  [Page 9]

INTERNET DRAFT     IODEF Enumeration Reference Format  December 19, 2014

   [CVE] http://cve.mitre.org

Authors' Addresses

   Adam W. Montville

   EMail: adam.w.montville@gmail.com

   David Black
   EMC Corporation

   EMail: david.black@emc.com

Adam W. Montville        Expires June 22, 2015                 [Page 10]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/