diff options
Diffstat (limited to 'doc/rfc/rfc7495.txt')
| -rw-r--r-- | doc/rfc/rfc7495.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc7495.txt b/doc/rfc/rfc7495.txt new file mode 100644 index 0000000..568c004 --- /dev/null +++ b/doc/rfc/rfc7495.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Montville +Request for Comments: 7495 CIS +Category: Standards Track D. Black +ISSN: 2070-1721 EMC + March 2015 + + + Enumeration Reference Format + for the Incident Object Description Exchange Format (IODEF) + +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, Intrusion Detection System (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 document 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 document does not update + IODEF 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 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. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7495. + + + + + + +Montville & Black Standards Track [Page 1] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + +Copyright Notice + + 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) 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. + +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 + + + + + + + + + + + + + + + + + + + + + +Montville & Black Standards Track [Page 2] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + +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 [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 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 Common Vulnerability Enumeration [CVE], Common + Configuration Enumeration [CCE], Common Platform Enumeration [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 that identifies some set of associated information. + + + + + + + + +Montville & Black Standards Track [Page 3] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + + 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 + + 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 class that constitutes 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 + 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> + <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> + + + +Montville & Black Standards Track [Page 4] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + + 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 + +2.2. Reference Method Applicability + + While the scope of this document pertains to IODEF, 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. + +3. Security Considerations + + Ensuring a proper mapping of enumeration reference ID elements to the + correct SpecIndex is important. Potential consequences of not + mapping correctly include inaccurate information in references and + similar distribution of misinformation. + + Use of enumeration reference IDs from trusted sources is preferred 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. + + This document establishes 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 + + + + +Montville & Black Standards Track [Page 5] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + + 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. + + Per this document, IANA has created and maintains the following + registry: + + Name of the Registry: "Security External Enumeration Registry" + + Location of Registry: http://www.iana.org/assignments/sec-ext-enum + + Fields to record in the registry: + + Full Name: The full name of the enumeration (i.e., the + referenced specification) as 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 may be an acronym -- it consists + of uppercase characters (at least two). Uppercase is used to + avoid mismatches due to case differences. It is 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 [RFC20] excepting white space, i.e., from VCHAR + as defined in [RFC5234]. Some of the characters allowed in the + version string are escaped when that string is used in XML + + + + + +Montville & Black Standards Track [Page 6] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + + documents (e.g., '<' is represented as <); the registered + version string contains the unescaped ASCII character in all + such cases. + + 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: + + Full Name: Common Vulnerabilities and Exposures + + Abbreviation: CVE + + SpecIndex: 1 + + Version: 1.0 + + Specification URI/Reference: + https://nvd.nist.gov/download.cfm#CVE_FEED + + 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. This + review includes review of the specification associated with the + request. + + 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]. + + + + + + + +Montville & Black Standards Track [Page 7] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + + 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 + + <?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> + + + + + + + + + +Montville & Black Standards Track [Page 8] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + +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, + <http://www.rfc-editor.org/info/rfc2119>. + + [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident + Object Description Exchange Format", RFC 5070, December + 2007, <http://www.rfc-editor.org/info/rfc5070>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, <http://www.rfc-editor.org/info/rfc5226>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, January + 2008, <http://www.rfc-editor.org/info/rfc5234>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004, <http://www.rfc-editor.org/info/rfc3688>. + +6.2. Informative References + + [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>. + + + + + +Montville & Black Standards Track [Page 9] + +RFC 7495 IODEF Enumeration Reference Format March 2015 + + + [CVE] The MITRE Corporation, "CVE - Common Vulnerabilities and + Exposures", <http://cve.mitre.org>. + +Acknowledgements + + The authors would like to thank Eric Burger for the recommendation 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Montville & Black Standards Track [Page 10] + |