RFC 7495

Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)

📅 published March 2015, from ietf

RFC 7495: Enumeration Reference Format for IODEF ✨

okay bestie, this one is from March 2015 and it's a Standards Track doc 🎀 (that means it's the real deal, not just an opinion piece). It's written by A. Montville from CIS and D. Black from EMC, and it has ISSN 2070-1721. The header doesn't list anything it obsoletes or updates. The abstract does say it doesn't update IODEF v1, though. It's giving "standalone and proud" 💅

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 points to outside information, like a vulnerability, an Intrusion Detection System (IDS) alert, a malware sample, an advisory, or an attack technique 🦋. In practice, those references are built on external enumeration specifications that define both the enumeration format and the specific enumeration values. The IODEF Reference class (as specified in IODEF v1 in RFC 5070) doesn't say how to include both of those important pieces, though 😭

So this document creates a stand-alone data format that carries both the external specification and the specific enumeration identification value 🧚. It also sets up an IANA registry to manage those external enumeration specifications 📋. This document doesn't update IODEF v1, but this enumeration reference format is used in IODEF v2, and it can work with other formats that support this kind of enumeration reference 🌈.

Status of This Memo

This is an Internet Standards Track document 💜.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚.

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7495 🔗.

Copyright (c) 2015 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) as they're in effect on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document 🫶. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. Referencing External Enumerations ...............................3
      2.1. Reference Name Format ......................................4
      2.2. Reference Method Applicability .............................5
   3. Security Considerations .........................................5
   4. IANA Considerations .............................................6
   5. The ReferenceName Schema ........................................8
   6. References ......................................................9
      6.1. Normative References .......................................9
      6.2. Informative References .....................................9
   Acknowledgements ..................................................10
   Authors' Addresses ................................................10

1. Introduction ✨

There's an identified need for a format that puts relevant enumeration values from other data representation formats into an IODEF document 🎀. It's expected that other standards work inside several IETF Working Groups will need this too, but this document only covers IODEF 💅. This format is used in IODEF v2 [IODEFv2], which will replace the original IODEF v1 [IODEF] specification. This document does not specify use of this format in IODEF v1 [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 goal is to put enumeration identifiers and their enumeration format references into IODEF's Reference class 🍓. There are several ways to do that, but the best option right now is to require a specific structure for the ReferenceName string in the IODEF Reference class, and use an IANA registry to manage references to specific enumeration reference formats 👑.

Per IODEF [IODEF], ReferenceName is of type ML_STRING. This gets messy with specific references, especially enumeration formats like Common Vulnerability Enumeration [CVE], Common Configuration Enumeration [CCE], Common Platform Enumeration [CPE], and so on. Like, how is an implementer supposed to know what kind of reference this is, and how to parse it? 🤔 One solution, which this document presents, is to require that ReferenceName follow a particular format ✨.

Including these enumeration values is a big deal for incident communication and investigation, especially the ones tied to security automation 🔐. Usually an enumeration identifier is just an identifier with a specific format that an outside party defined. That identifier is also a reference to specific information tied to it. So the ReferenceName is an identifier formatted in a specific way that points to some set of related information 💖.

For example, a vulnerability identifier following the CVE [CVE] formatting spec might be CVE-2014-0001. That identifier is formatted in a specific way and relates to info about one specific vulnerability 🌈. Communicating the format for the identifier is what this document is about 🫶.

2.1. Reference Name Format

The ReferenceName class gives the XML representation for identifying an enumeration and picking a value from it 🧚. A given enumeration is uniquely identified by the specIndex attribute. Each specIndex value matches an entry in the "Enumeration Reference Type Identifiers" IANA registry (see Section 4) 📋. The child ID element represents one particular value from the enumeration identified by the specIndex attribute. The format of the ID element is described in that enumeration's IANA registry entry 💜.

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

                   Figure 1: The ReferenceName Class

The aggregate class that makes up ReferenceName is:

  • ID: One. The identifier assigned to represent the particular enumeration object being referenced 🎀.

The ReferenceName class has one attribute:

  • specIndex: Required. INTEGER. Enumeration identifier. This value matches an entry in the "Enumeration Reference Type Identifiers" IANA registry with an identical SpecIndex value 🍓.

Here's an example of that kind of reference 👀:

   <iodef:Reference>
      <enum:ReferenceName specIndex="1">
         <enum:ID>CXI-1234-XYZ</enum:ID>
      </enum:ReferenceName>
      <iodef:URL>http://cxi.example.com</iodef:URL>
      <iodef:Description>Foo</iodef:Description>
   </iodef:Reference>

The info in the IANA table (see Section 4) would look like this 📋:

   Full Name: Concept X Identifier
   SpecIndex: 1
   Version: any
   Specification URI: http://cxi.example.com/spec_url

2.2. Reference Method Applicability

This document is about IODEF, but any standard that needs to reference an enumeration identified by a specially formatted string can use this method to add structure after the standard has been published 🌸. Basically, this method gives enumeration formats a standardized interface, which allows a loose coupling between a given standard and the enumeration identifiers it needs to reference now and in the future 💅.

3. Security Considerations 🚨

Getting each enumeration reference ID element mapped correctly to the right SpecIndex is super important 😭. If you don't map it correctly, you can end up with inaccurate information in references and the same kind of misinformation getting spread around 💀.

Using enumeration reference IDs from trusted sources is the preferred move to reduce the risk of receiving and/or providing misinformation 🫶. Trust decisions about enumeration reference providers are outside the scope of this document 🙈. Still, receiving an IODEF [IODEF] document with an unknown ReferenceName (meaning the SpecIndex isn't in the IANA table) might mean a misled or malicious source is involved 🔥.

This document creates a container for publicly available enumeration values to go into an IODEF [IODEF] document, and it's important to keep in mind the difference between an enumeration value's format and the information the value itself carries 🧚. The enumeration value might hold info that relying parties consider private, but the enumeration format probably doesn't raise privacy concerns 💜.

Heads up: if the Reference class puts an enumeration value together with other data in an IODEF [IODEF] document, the combination could expose information 😱. For example, attack vectors or system descriptions from a privacy-related incident could be exposed this way 🙈. So go check the IODEF [IODEF] Security Considerations section. It explicitly covers protecting IODEF [IODEF] documents in transit and at rest, making sure recipients are properly authenticated, data confidence levels, the security properties of the underlying transport, and proper use of IODEF's restriction attribute 🔐✨.
To be continued in part 2 with IANA Considerations, the ReferenceName Schema, References, Acknowledgements, and Authors' Addresses 💖🎀

4. IANA Considerations ✨

Okay bestie, time for the paperwork glow-up 💅 This document defines an enumeration reference identifier format, and every field is mandatory, abbreviation included 🫶

IANA created and maintains one registry for this, and it's giving official 📋

Here's what gets recorded in the registry 🌸

  • Full Name: The full name of the enumeration (aka the referenced specification) is a string from the printable ASCII character set [RFC20], with individual embedded spaces allowed. The ABNF [RFC5234] syntax for this field is:
FULL-NAME = 1*VCHAR *(SP 1*VCHAR)
  • Abbreviation: An abbreviation can be an acronym, made of uppercase characters (at least two of them). Uppercase keeps things from getting mixed up because of case differences 🔠 The ABNF [RFC5234] syntax is:
ABBREVIATION = 2*UC-ALPHA      ; At least two
UC-ALPHA = %x41-5A             ; A-Z

Multiple registrations MAY use the same Abbreviation, but they MUST have different Versions. Main character energy for the version field, honestly 🦋

  • SpecIndex: This is a positive integer that IANA assigns to identify each registration. The first entry added to the registry gets the value 1, and every new entry after that adds one more 🔢
  • Version: The version of the enumeration (aka the referenced specification) is a free-form string from the printable ASCII character set [RFC20], except white space. In other words, it's taken from VCHAR as defined in [RFC5234] 🧁 Some characters in the version string get escaped when it shows up in XML documents (for example, < becomes &lt;). The registered version string always holds the unescaped ASCII character in those cases 💜
  • Specification URI/Reference: This is one or more URIs [RFC3986] where the registered specification can be found. The registered specification MUST be readily and publicly available from that URI. The URI SHOULD be a stable reference to one specific version of the specification. URIs that point to the latest version of a specification (which changes whenever a new version comes out) SHOULD NOT be used 🙅‍♀️

The initial registry contents are giving CVE energy 🛡️

Full Name: Common Vulnerabilities and Exposures

Abbreviation: CVE

SpecIndex: 1

Version: 1.0

Specification URI/Reference:
https://nvd.nist.gov/download.cfm#CVE_FEED

The allocation policy is Specification Required [RFC5226], which implies Expert Review [RFC5226] ✨

The Designated Expert is expected to check in with the MILE (Managed Incident Lightweight Exchange) working group, or its successor if one exists, for example by emailing the working group's mailing list 📧 They're also expected to review the request and confirm the enumeration actually fits the attribute. That review includes the specification tied to the request 🔍

The Designated Expert is expected to make sure the Full Name, Abbreviation, and Version are all appropriate. They also need to confirm the information at the Specification URI is enough to unambiguously parse identifiers based on that specification 🧐 On top of that, the Designated Expert should prefer short Abbreviations over long ones 🫶

This document uses URNs to describe XML namespaces and XML schemas that follow a registry mechanism described in [RFC3688] 🎀

Registration 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 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 5, "The ReferenceName Schema", of this document.

5. The ReferenceName Schema

Here's the schema itself, the actual XML that makes the identifier work 🤓💕

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
      elementFormDefault="qualified"
      targetNamespace="urn:ietf:params:xml:ns:iodef-enum-1.0"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:enum="urn:ietf:params:xml:ns:iodef-enum-1.0">

 <!--
 ==========================================================
 ===  ReferenceName                                     ===
 ==========================================================
  -->
 <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.1. Normative References

These are the references you absolutely need to read to get the spec, no skipping 📚

6.2. Informative References

These are the background reads, the "why is it like this?" section 🌈

  • [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
  • [IODEFv2] Danyliw, R. and P. Stoecker, "The Incident Object Description Exchange Format v2", Work in Progress, draft-ietf-mile-rfc5070-bis-11, March 2015.
  • [CCE] The MITRE Corporation, "Common Configuration Enumeration (CCE): Unique Identifiers for Common System Configuration Issues", website in "Archive" status, <http://cce.mitre.org>.
  • [CPE] The MITRE Corporation, "CPE - Common Platform Enumeration", website in "Archive" status, <http://cpe.mitre.org>.
  • [CVE] The MITRE Corporation, "CVE - Common Vulnerabilities and Exposures", <http://cve.mitre.org>.

Acknowledgements

The authors gave a big thank-you to Eric Burger for the push to rely on XML, Roman D. Danyliw for his schema contribution and insight, and Tim Bray, Panos Kampanakis, Barry Leiba, Ted Lemon, Alexey Melnikov, Kathleen Moriarty, Takeshi Takahashi, Henry S. Thompson, and David Waltermire for their contributions and reviews 🫶🌸

Authors' Addresses

  • Adam W. Montville
  • EMail: adam.w.montville@gmail.com
  • David Black, EMC Corporation
  • EMail: david.black@emc.com

And that's the whole spec, bestie 🌈👑 Iconic, periodt ✨

📦 where this page comes from