idnits 2.17.1
draft-ietf-mile-enum-reference-format-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 30, 2015) is 3371 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 5070 (ref. 'IODEF') (Obsoleted by RFC
7970)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
== Outdated reference: A later version (-26) exists of
draft-ietf-mile-rfc5070-bis-10
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT Adam W. Montville
3 Intended Status: Standards Track (CIS)
4 Expires: August 3, 2015 David Black
5 (EMC)
7 January 30, 2015
9 IODEF Enumeration Reference Format
10 draft-ietf-mile-enum-reference-format-14
12 Abstract
14 The Incident Object Description Exchange Format (IODEF) is an XML
15 data representation framework for sharing information about computer
16 security incidents. In IODEF, the Reference class provides
17 references to externally specified information such as a
18 vulnerability, Intrusion Detection System (IDS) alert, malware
19 sample, advisory, or attack technique. In practice, these references
20 are based on external enumeration specifications that define both the
21 enumeration format and the specific enumeration values, but the IODEF
22 Reference class (as specified in IODEF v1 in RFC 5070) does not
23 indicate how to include both of these important pieces of
24 information.
26 This document establishes a stand-alone data format to include both
27 the external specification and specific enumeration identification
28 value, and establishes an IANA registry to manage external
29 enumeration specifications. While this document does not update
30 IODEF v1, this enumeration reference format is used in IODEF v2 and
31 is applicable to other formats that support this class of enumeration
32 references.
34 Status of this Memo
36 This Internet-Draft is submitted to IETF in full conformance with the
37 provisions of BCP 78 and BCP 79.
39 Internet-Drafts are working documents of the Internet Engineering
40 Task Force (IETF), its areas, and its working groups. Note that
41 other groups may also distribute working documents as
42 Internet-Drafts.
44 Internet-Drafts are draft documents valid for a maximum of six months
45 and may be updated, replaced, or obsoleted by other documents at any
46 time. It is inappropriate to use Internet-Drafts as reference
47 material or to cite them other than as "work in progress."
49 The list of current Internet-Drafts can be accessed at
50 http://www.ietf.org/1id-abstracts.html
52 The list of Internet-Draft Shadow Directories can be accessed at
53 http://www.ietf.org/shadow.html
55 Copyright and License Notice
57 Copyright (c) 2015 IETF Trust and the persons identified as the
58 document authors. All rights reserved.
60 This document is subject to BCP 78 and the IETF Trust's Legal
61 Provisions Relating to IETF Documents
62 (http://trustee.ietf.org/license-info) in effect on the date of
63 publication of this document. Please review these documents
64 carefully, as they describe your rights and restrictions with respect
65 to this document. Code Components extracted from this document must
66 include Simplified BSD License text as described in Section 4.e of
67 the Trust Legal Provisions and are provided without warranty as
68 described in the Simplified BSD License.
70 Table of Contents
72 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
73 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
74 2. Referencing External Enumerations . . . . . . . . . . . . . . 3
75 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
76 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
77 5 The ReferenceName Schema . . . . . . . . . . . . . . . . . . . . 8
78 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
79 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
80 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
81 7.2 Informative References . . . . . . . . . . . . . . . . . . 10
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
84 1 Introduction
86 There is an identified need to specify a format to include relevant
87 enumeration values from other data representation formats in an IODEF
88 document. It is anticipated that this requirement will exist in other
89 standardization efforts within several IETF Working Groups, but the
90 scope of this document pertains solely to IODEF. This format is used
91 in IODEF v2 [I-D.draft-ietf-mile-rfc5070-bis] which replaces the
92 original IODEF v1 [IODEF] specification; this document does not
93 specify use of this format in IODEF v1 [IODEF].
95 1.1 Terminology
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
99 document are to be interpreted as described in RFC 2119 [RFC2119].
101 2. Referencing External Enumerations
103 The need is to place enumeration identifiers and their enumeration
104 format references in IODEF's Reference class. There are several ways
105 to accomplish this goal, but the most appropriate at this point is to
106 require a specific structure for the ReferenceName string of the
107 IODEF Reference class, and use an IANA registry to manage references
108 to specific enumeration reference formats.
110 Per IODEF [IODEF] the ReferenceName is of type ML_STRING. This
111 becomes problematic when specific references, especially enumeration
112 formats such as Common Vulnerability Enumeration [CVE], Common
113 Configuration Enumeration [CCE], Common Platform Enumeration [CPE]
114 and so on, are referenced - how is an implementer to know which type
115 of reference this is, and thus how to parse it? One solution,
116 presented here, is to require that ReferenceName follow a particular
117 format.
119 Inclusion of such enumeration values, especially those related to
120 security automation, is important to incident communication and
121 investigation. Typically, an enumeration identifier is simply an
122 identifier with a specific format as defined by an external party.
123 Further, that enumeration identifier is itself a reference to
124 specific information associated with the identifier. Thus, the
125 ReferenceName is an identifier that is formatted in a specific
126 manner, and which identifies some set of associated information.
128 For example, a vulnerability identifier following the CVE [CVE]
129 formatting specification may be: CVE-2014-0001. That identifier is
130 formatted in a specific manner and relates to information about a
131 specific vulnerability. Communicating the format for the identifier
132 is the subject of this document.
134 2.1 Reference Name Format
136 The ReferenceName class provides the XML representation for
137 identifying an enumeration and specifying a value from it. A given
138 enumeration is uniquely identified by the specIndex attribute. Each
139 specIndex value corresponds to an entry in the "Enumeration Reference
140 Type Identifiers" IANA registry (see Section 4). The child ID
141 element represents a particular value from the corresponding
142 enumeration identified by the specIndex attribute. The format of the
143 ID element is described in the IANA registry entry of the
144 enumeration.
146 +-------------------------+
147 | ReferenceName |
148 +-------------------------+
149 | INTEGER specIndex |<>----------[ ID ]
150 +-------------------------+
152 Figure 1: The ReferenceName Class
154 The aggregate classes that constitute ReferenceName:
156 ID
157 One. The identifier assigned to represent the particular
158 enumeration object being referenced.
160 The ReferenceName class has one attribute.
162 specIndex
163 Required. INTEGER. Enumeration identifier. This value
164 corresponds to an entry in the "Enumeration Reference Type
165 Identifiers" IANA registry with an identical SpecIndex value.
167 An example of such a reference is as follows:
169
170
171 CXI-1234-XYZ
172
173 http://cxi.example.com
174 Foo
175
177 Information in the IANA table (see Section 4) would include:
179 Full Name: Concept X Identifier
180 SpecIndex: 1
181 Version: any
182 Specification URI: http://cxi.example.com/spec_url
184 2.2 Reference Method Applicability
186 While the scope of this document pertains to IODEF, any standard
187 needing to reference an enumeration identified by a specially
188 formatted string can use this method of providing structure after
189 the standard has been published. In effect, this method provides
190 a standardized interface for enumeration formats, thus allowing a
191 loose coupling between a given standard and the enumeration
192 identifiers it needs to reference now and in the future.
194 3 Security Considerations
196 Ensuring a proper mapping of enumeration reference ID elements to
197 the correct SpecIndex is important. Potential consequences of not
198 mapping correctly include inaccurate information references and
199 similar distribution of misinformation.
201 Use of enumeration reference IDs from trusted sources are
202 preferred to mitigate the risk of receiving and/or providing
203 misinformation. Trust decisions with respect to enumeration
204 reference providers are beyond the scope of this document.
205 However, receiving an IODEF [IODEF] document containing an unknown
206 ReferenceName (i.e. the SpecIndex does not exist in the IANA
207 table) may indicate a misled or malicious source.
209 This document is establishing a container for publicly available
210 enumeration values to be included in an IODEF [IODEF] document,
211 and it is important to note the distinction between the
212 enumeration value's format and the information conveyed by the
213 value itself. While the enumeration value may hold information
214 deemed to be private by relying parties, the enumeration format is
215 likely not subject to privacy concerns.
217 However, if the Reference class includes an enumeration value in
218 combination with other data in an IODEF [IODEF] document, the
219 resulting combination could expose information. An example might
220 include attack vectors or system descriptions used in a privacy-
221 related incident. As such, the reader is referred to the IODEF
222 [IODEF] Security Considerations section, which explicitly covers
223 protecting IODEF [IODEF] documents in transit and at rest,
224 ensuring proper recipient authentication, data confidence levels,
225 underlying transport security characteristics, and proper use of
226 IODEF's restriction attribute.
228 4 IANA Considerations
230 This document specifies an enumeration reference identifier
231 format. All fields, including abbreviation, are mandatory.
233 This document creates the following registry for IANA to manage:
235 Name of the Registry: "Security External Enumeration Registry"
237 Location of Registry: https://www.iana.org/assignments/sec-ext-
238 enum
240 Fields to record in the registry:
242 Full Name: The full name of the enumeration (i.e. the
243 referenced specification) as a string from the printable ASCII
244 character set [RFC0020] with individual embedded spaces
245 allowed. The ABNF [RFC5234] syntax for this field is:
247 1*VCHAR *(SP 1*VCHAR)
249 Abbreviation: An abbreviation may be an acronym - it consists
250 of upper-case characters (at least two, upper-case is used to
251 avoid mismatches due to case differences), as specified by this
252 ABNF [RFC5234] syntax:
254 ABBREVIATION = 2*UC-ALPHA ; At least two
255 UC-ALPHA = %x41-5A ; A-Z
257 Multiple registrations MAY use the same Abbreviation but
258 MUST have different Versions.
260 SpecIndex: This is an IANA-assigned positive integer that
261 identifies the registration. The first entry added to this
262 registry uses the value 1, and this value is incremented for
263 each subsequent entry added to the registry.
265 Version: The version of the enumeration (i.e. the referenced
266 specification) as a free-form string from the printable ASCII
267 character set [RFC0020] excepting white space, i.e., from VCHAR
268 as defined in [RFC5234]. Some of the characters allowed in the
269 version string are escaped when that string is used in XML
270 documents (e.g., '<' is represented as <); the registered
271 version string contains the unescaped ASCII character in all
272 such cases.
274 Specification URI/Reference: A list of one or more URIs
275 [RFC3986] from which the registered specification can be
276 obtained. The registered specification MUST be readily and
277 publicly available from that URI. The URI SHOULD be a stable
278 reference to a specific version of the specification. URIs
279 that designate the latest version of a specification (which
280 changes when a new version appears) SHOULD NOT be used.
282 Initial registry contents:
284 Full Name: Common Vulnerabilities and Exposures
286 Abbreviation: CVE
288 SpecIndex: 1
289 Version: 1.0
291 Specification URI/Reference:
292 https://nvd.nist.gov/download.cfm#CVE_FEED
294 Allocation Policy: Specification Required [RFC5226] (which implies
295 Expert Review [RFC5226]).
297 The Designated Expert is expected to consult with the MILE (Managed
298 Incident Lightweight Exchange) working group or its successor if any
299 such WG exists (e.g., via email to the working group's mailing list).
300 The Designated Expert is expected to review the request and validate
301 the appropriateness of the enumeration for the attribute. This
302 review includes review of the specification associated with the
303 request.
305 The Designated Expert is expected to ensure that the Full Name,
306 Abbreviation and Version are appropriate and that the information at
307 the Specification URI is sufficient to unambiguously parse
308 identifiers based on that specification. Additionally, the Designated
309 Expert should prefer short Abbreviations over long ones.
311 This document uses URNs to describe XML namespaces and XML schemas
312 conforming to a registry mechanism described in [RFC3688].
314 Registration request for the IODEF enumeration reference format
315 namespace:
317 URI : urn:ietf:params:xml:ns:iodef-enum-1.0
319 Registrant Contact : See the "Authors' Addresses" section of this
320 document.
322 XML : None.
324 Registration request for the IODEF enumeration reference format XML
325 schema:
327 URI : urn:ietf:params:xml:schema:iodef-enum-1.0
329 Registrant Contact See the "Authors' Addresses" section of this
330 document.
332 XML : See Section 5, "The ReferenceName Schema", of this document.
334 5 The ReferenceName Schema
335
336
342
347
348
349
350
351
352
354
355
356
358 6 Acknowledgements
360 The authors would like to thank Eric Burger for the recommendation
361 to rely on XML, Roman D. Danyliw for his schema contribution and
362 insight, and Tim Bray, Panos Kampanakis, Barry Leiba, Ted Lemon,
363 Alexey Melnikov, Kathleen Moriarty, Takeshi Takahashi, Henry S.
364 Thompson, and David Waltermire for their contributions and
365 reviews.
367 7 References
369 7.1 Normative References
371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
372 Requirement Levels", BCP 14, RFC 2119, March 1997.
374 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
375 Object Description Exchange Format", RFC 5070, December
376 2007.
378 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
379 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
380 May 2008.
382 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
383 Resource Identifier (URI): Generic Syntax", STD 66,
384 RFC 3986, January 2005.
386 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
387 Syntax Specifications: ABNF", STD 68, RFC 5234, January
388 2008.
390 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
391 January 2004.
393 7.2 Informative References
395 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
396 October 1969.
398 [I-D.draft-ietf-mile-rfc5070-bis] Danyliw, R., and Stoecker, P., "The
399 Incident Object Description Exchange Format v2", draft-
400 ietf-mile-rfc5070-bis-10 (work in progress), November
401 2014.
403 [CCE] http://cce.mitre.org
405 [CPE] http://cpe.mitre.org
407 [CVE] http://cve.mitre.org
409 Authors' Addresses
411 Adam W. Montville
413 EMail: adam.w.montville@gmail.com
415 David Black
416 EMC Corporation
418 EMail: david.black@emc.com