idnits 2.17.1 draft-goodier-mile-data-markers-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6045], [RFC5901]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2011) is 4572 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) == Missing Reference: 'RFC 5901' is mentioned on line 25, but not defined == Missing Reference: 'RFC 6045' is mentioned on line 32, but not defined ** Obsolete undefined reference: RFC 6045 (Obsoleted by RFC 6545) == Unused Reference: 'RFC6045' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 482, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 6045 (Obsoleted by RFC 6545) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission K. Goodier 2 Internet-Draft L-3 Com 3 Intended status: Standards Track D. Rajnovic 4 Expires: March 25, 2012 Cisco 5 September 22, 2011 7 Guidelines for Extensions to IODEF for Managed Incident Lightweight 8 Exchange 9 draft-goodier-mile-data-markers-00.txt 11 Abstract 13 This document provides extensions to Managed Incident Lightweight 14 Exchange (MILE). MILE describes a subset of Incident Object 15 Description Exchange Format (IODEF) defined in RFC 5070. The Data 16 Markers extension is aimed at exchanging data tags or markers that 17 label categories of information that have significance in the 18 exchange of incident information. These data marker extension is 19 aimed at exchanging data tags or markers that label information 20 exchanged during incident handling. Data markers include sensitivity 21 and data handling requirements that can prevent possible criminal 22 errors in mismarking data. Both network and information security 23 incidents typically result in the loss of service, data, and 24 resources both human and system. Existing extensions to the IODEF- 25 Document Class for Reporting Phishing [RFC 5901] have already been 26 introduced for network security incidents. Data markers introduce 27 extensions for information security incidents so that network 28 providers and Computer Security Incident Response Teams (CSIRT) are 29 equipped and ready to assist in communicating and tracing security 30 incidents with tools and procedures in place before the occurrence of 31 an attack. Data Markers also support Real-time Inter-network Defense 32 (RID) [RFC 6045] that outlines a proactive inter-network 33 communication method to facilitate sharing incident handling data 34 while integrating existing detection, tracing, source identification, 35 and mitigation mechanisms for a complete incident handling solution. 36 Combining these capabilities in a communication system provides a way 37 to achieve higher security levels on networks. Policy guidelines for 38 handling incidents are recommended and can be agreed upon by a 39 consortium using the security recommendations and considerations. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on March 25, 2012. 58 Copyright Notice 60 Copyright (c) 2011 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Applicability of Data Marker Extensions to IODEF . . . . . . . 4 78 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 79 2.2. Extension Definition . . . . . . . . . . . . . . . . . . . 7 80 2.2.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 7 81 2.2.2. Example Enumerated Type Extension Definition: 82 E.164 Address . . . . . . . . . . . . . . . . . . . . 8 83 2.2.3. Example Element Definition: Test . . . . . . . . . . . 9 84 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 2.4. Security Considerations . . . . . . . . . . . . . . . . . 10 86 2.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 87 2.6. Appendix: XML Schema Definition for Extension . . . . . . 11 88 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 90 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 92 5.2. Informative References . . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 95 1. Introduction 97 Guidance has improved for the handling of privacy and other data 98 markers to ensure the consistent application of security controls in 99 profiled implementations. Organizations require help from data 100 marking parties to digitally define the related context and 101 semantics. Rapid incident detection and coordination requires 102 automation. Increases in internet engineering outsourcing via cloud 103 services requires tighter security and knowledge on how data is 104 protected and incidents that could affect that data. It is critical 105 to have automated means to both detect and mitigate/stop attack 106 traffic while augmenting the governance of any internet-based 107 enterprise. Enterprise data marking standards that secure cyberspace 108 particularly within private and hybrid networks require governance 109 methodologies that enable a workforce who has a responsibility to 110 locate and retrieve data in support of Lines of Businesses (LoBs) and 111 specific missions. Data markers provide additional semantic or 112 metadata labeling of IODEF Documents (e.g., for handling or 113 disposition instructions, or compliance with data protection and data 114 retention regulations). 116 1.1. Terminology 118 Data marker attributes containing enumerated values within IODEF 119 elements may be further extended. For a data marker attribute named 120 "foo", this is achieved by giving the value of "foo" as "ext-marker- 121 value", and adding a new attribute named "ext-marker-foo" containing 122 the extended value. The attributes which can be extended in this way 123 are defined in [RFC5070], and limited by these values. 125 2. Applicability of Data Marker Extensions to IODEF 127 Before deciding to extend IODEF, the first step is to determine 128 whether an IODEF extension is a good fit for a given problem. There 129 are two answers to this question for data markers: 131 1. Data markers are critical to the reporting or sharing of 132 information about an incident. 134 2. Without a data makers extension, IODEF can not adequately 135 represent information about an incident. 137 2.1. Applicability 139 The five standard use cases that apply to the data markers extension 140 follow: 142 1. Use Case 1:Information Sharing 144 2. Use Case 2:Incident Query 146 3. Use Case 3:Investigation Request-Results Sent 148 4. Use Case 4:Investigation Request-Request Sent 150 5. Use Case 5:Trace Back Request 152 Use Case 1: Information Sharing: An incident type is identified and 153 marked and CSIRTs would like to share that information with other 154 CSIRTs. The incident information may be a list of IP addresses known 155 to be malicious or a type of an attack described (for example) in 156 MAEC and embedded in an IODEF document. In this use case, a central 157 authority, US CERT, may have knowledge of several instances of an 158 attack type for which the supported community should be notified to 159 increase awareness and detection capabilities for the attack type or 160 sources. Information Sharing Flow: US CERT generates an IODEF 161 document, using the relevant SCAP and marked data information 162 sources, and sends a RID Report message out to all Agency CSIRTs with 163 one or more attack type descriptions or information about malicious 164 entities. No response is required for this communication type. 166 Use Case 2: Incident Query: An incident query communication is used 167 when one CSIRT would like to know if a type of attack has been 168 detected by other CSIRTs. The information provided back can be 169 limited to descriptions of the attack without providing source and 170 destination information if that data is marked as controlled or 171 classified. This use case is sending the request to US CERT because 172 they may have a broad knowledge set of attack types within the 173 government sector to share with Agency CSIRTs. Incident Query Flow: 174 An Agency CSIRT sends an appropriately marked IncidentQuery to US 175 CERT. US CERT responds with an appropriately marked Report message. 177 Use Case 3: Investigation Request-Results Sent: An incident is 178 detected by a CSIRT and further investigation is required to identify 179 and mitigate or stop the attack. In this use case instance, the 180 Agency CSIRT will detect and data mark the incident. It could be 181 identified by any CSIRT including US CERT or the Provider CSIRT in 182 other use cases. Investigation Request Flow: An Agency CSIRT detects 183 an incident. The source of the incident is identified using SCAP and 184 event information and an IODEF document with data markers with data 185 markers is generated. The IODEF document is sent to the Provider 186 CSIRT in a RID Investigation message using the appropriate transport 187 protocol and data markers. The Provider CSIRT decides to work on the 188 incident investigation, then sends the proper ly data marked Result 189 message when the investigation is complete. Note: The Result message 190 can contain the information deemed appropriate for sharing with the 191 Agency CSIRT. Data markers for policy and privacy considerations 192 relative to the incident are required. In this use case, the 193 Provider CSIRT sends the full investigation Report including the 194 source of the attack and the action taken to stop the attack, traffic 195 from the source address was blocked. 197 Use Case 4: Investigation Request-Request Sent: An incident is 198 detected by a CSIRT and further investigation is required to identify 199 and mitigate or stop the attack. In this use case instance, the 200 Agency CSIRT will detect the incident. It could be identified by any 201 CSIRT including US CERT or the Provider CSIRT in other use cases. 202 Investigation Request Flow: An Agency CSIRT detects an incident. The 203 source of the incident is identified using SCAP and event information 204 and an IODEF document with data markers is generated. The IODEF 205 document is sent to the Provider CSIRT in a RID Investigation message 206 using the appropriate transport protocol and data markers. The 207 Provider CSIRT is unable to work on the Investigation request, a 208 RequestAuthorization message is sent to the Agency CSIRT to notify 209 them of the inability to respond at this time. The Agency CSIRT 210 takes an action to block the source address from accessing the 211 application that was targeted using the tools available to them from 212 the Provider. 214 Use Case 5: Trace Back Request: In the case where the source of an 215 incident is unknown (possibly spoofed), the ability to iteratively 216 track an incident through providers or networks may be necessary. 217 This communication flow is similar to the Investigation request, but 218 could involve multiple CSIRTs until a source is found or a party does 219 not have the resources to participate. The actions taken in this 220 case may be close to the source of an attack or downstream Provider 221 depending on who cooperates and marks data. This use case just 222 describes one of the many possible flows that could occur in the 223 trace back request. Trace Back Request Flow: An Agency CSIRT detects 224 an incident using event information and the appropriate information 225 for that event (application server is targeted in a DDoS attack). 226 The Agency CSIRT generates an IODEF document and encapsulates it in a 227 RID wrapper with data markers for a TraceRequest. The TraceRequest 228 is sent to the upstream to their Provider's CSIRT. The Provider 229 CSIRT confirms receipt with a RequestAuthorization message indicating 230 that this can be looked at now by the Provider CSIRT. The 231 investigation begins at the Provider CSIRT, and the next upstream 232 provider has been found (where the traffic is originating), a 233 TraceRequest message is sent to the next Provider CSIRT. The next 234 Provider CSIRT sends a RequestAuthorization response to both the 235 Agency CSIRT (originator of request) and the Provider CSIRT who sent 236 the TraceRequest. The response provided in the AuthorizationRequest 237 is yes and the incident will be investigated. The investigation has 238 completed and a Result message is sent to the Agency CSIRT. The 239 information provided in the report must be marked according to the 240 policy of the CSIRT that sends the report. In this use case, the 241 information provided is limited to a description of the actions taken 242 with appropriate data markers, the traffic has been rate limited with 243 no information on the true source of the attack. 245 2.2. Extension Definition 247 This section defines the data markers extension. 249 Extensions to enumerated types are defined in one subsection for each 250 attribute to be extended, enumerating the new values with an 251 explanation of the meaning of the new value. An example enumeration 252 extension is shown in Section 2.2.2, below. 254 Element extensions are defined in one subsection for each element, in 255 top-down order, from the element contained within AdditionalData or 256 RecordItem; an example element extension is shown in Section 2.2.3, 257 below. Each element should be described by a UML diagram as in 258 Figure 1, followed by a description of each of the attributes, and a 259 short description of each of the child elements. Child elements 260 should then be defined in a subsequent subsection, if not already 261 defined in the IODEF document itself, or in another referenced MILE 262 extension document. 264 +---------------------+ 265 | Element | 266 +---------------------+ 267 | TYPE attribute0 |<>----------[ChildExactlyOne] 268 | TYPE attribute1 |<>--{0..1}--[ChildZeroOrOne] 269 | |<>--{0..*}--[ChildZeroOrMore] 270 | |<>--{1..*}--[ChildOneOrMore] 271 +---------------------+ 273 Figure 1: Example UML Element Diagram 275 Elements containing child elements should indicate the multiplicity 276 of those child elements, as shown in the figure above. Allowable 277 TYPEs are discussed in the following subsection. 279 2.2.1. IODEF Data Types 281 The allowable TYPEs for attributes within IODEF are enumerated in 282 section 2 of [RFC5070], and consist of: 284 o INTEGER 285 o REAL 287 o CHARACTER 289 o STRING 291 o ML_STRING (for strings in encodings other than that of the 292 enclosing document) 294 o BYTE for bytes or byte vectors in Base 64 encoding 296 o HEXBIN for bytes in ascii-hexadecimal encoding 298 o ENUM for enumerated types; allowable values of the enumeration 299 must be defined in the attribute definition 301 o DATETIME for ISO 8601:2000 [RFC3339] encoded timestamps 303 o TIMEZONE for timezones as encoded in section 2.9 of [RFC5070]. 305 o PORTLIST for port lists as encoded in section 2.10 of [RFC5070]. 307 o POSTAL for postal addresses as defined in section 2.23 of 308 [RFC4519]. 310 o NAME for names of natural or legal persons as defined in section 311 2.3 of [RFC4519]. 313 o PHONE for telephone numbers as defined in section 2.35 of 314 [RFC4519]. 316 o EMAIL for email addresses as defined in section 3.4.1. of 317 [RFC2822]. 319 o URL for URLs as in [RFC2396]. 321 In addition to these simple data types, IODEF provides a compound 322 data type for representing network address information. Addresses 323 included within an extension element should be represented by 324 containing an IODEF:Address element, which supports IPv4 and 325 [RFC2373] IPv6 addresses, as well as MAC, ATM, and BGP autonomous 326 system numbers. Application-layer addresses should be represented 327 with the URL simple attribute type, instead. 329 2.2.2. Example Enumerated Type Extension Definition: E.164 Address 331 This example extends the IODEF Address element to support the 332 encoding of ENUM-mapped telephone numbers [RFC6116]. 334 Attribute: Address@category 336 Extended value(s): enum-e164 338 Content format: An E.164 telephone number encoded as a domain name in 339 the e164.int space, e.g. "2.1.2.1.5.5.5.2.1.2.1.e164.int." for +1 212 340 555 1212, as per section 3.2 of [RFC6116]. 342 Additional considerations: none. 344 2.2.3. Example Element Definition: Test 346 This example defines the Test class for labeling IODEF test data. 348 The Test class is intended to be included within an AdditionalData 349 element in an IODEF Document. If a Test element is present, it 350 indicates that an IODEF Document contains test data, not a reference 351 to a real incident. 353 The Test class contains information about how the test data was 354 generated. 356 +---------------------+ 357 | Test | 358 +---------------------+ 359 | ENUM category | 360 | STRING generator | 361 | | 362 | | 363 +---------------------+ 365 Figure 2: The Test class 367 The Test class has two attributes: 369 category: Required. ENUM. The type of test data. The permitted 370 values for this attribute are shown below. The default value is 371 "unspecified". 373 1. unspecified. The document contains test data, but no further 374 information is available. 376 2. internal. The test data is intended for the internal use of 377 an implementor, and should not be distributed or used outside 378 the context in which it was generated. 380 3. unit. The test data is intended for unit testing of an 381 implementation, and may be included with the implementation to 382 support this as part of the build and deployment process. 384 4. interoperability. The test data is intended for 385 interoperability testing of an implementation, and may be 386 freely shared to support this purpose. 388 generator: Optional. STRING. A free-form string identifying the 389 person, entity, or program which generated the test data. 391 2.3. Examples 393 This section contains example IODEF-Documents illustrating the 394 extension. If example situations are outlined in the applicability 395 section, documents for those examples should be provided in the same 396 order as in the applicability section. Example documents should be 397 tested to validate against the schema given in the appendix. 399 2.4. Security Considerations 401 [SECDIR and RFC-EDITOR NOTE: Despite the title, this section is NOT a 402 Security Considerations section, rather a template Security 403 Considerations section for future extension documents to be built 404 from this template. See Section 3 for Security Considerations for 405 this document.] 407 Any security considerations [RFC3552] raised by this extension or its 408 deployment should be detailed in this section. Guidance should focus 409 on ensuring the users of this extension do so in a secure fashion, 410 with special attention to non-obvious implications of the 411 transmission or storage of the information represented by an 412 extension. 414 2.5. IANA Considerations 416 [IANA and RFC-EDITOR NOTE: Despite the title, this section is NOT an 417 IANA Considerations section, rather a template IANA Considerations 418 section for future extension documents to be built from this 419 template. See Section 4 for IANA Considerations for this document.] 421 Any IANA considerations [RFC5226] for the document should be detailed 422 in this section; if none, the section should exist and contain the 423 text "this document has no actions for IANA". 425 IODEF Extensions adding elements to the AdditionalData section of an 426 IODEF document should register their own namespaces and schemas for 427 extensions with IANA; therefore, this section should contain at least 428 a registration request for the namespace and the schema, as follows, 429 modified as appropriate for the extension: 431 Registration request for the IODEF My-Extension namespace: 433 URI: urn:ietf:params:xml:ns:iodef-myextension-1.0 435 Registrant Contact: Refer here to the authors' addresses section of 436 the document, or to an organizational contact in the case of an 437 extension supported by an external organization. 439 XML: None 441 Registration request for the IODEF My-Extension XML schema: 443 URI: urn:ietf:params:xml:schema:iodef-myextension-1.0 445 Registrant Contact: Refer here to the authors' addresses section of 446 the document, or to an organizational contact in the case of an 447 extension supported by an external organization. 449 XML: Refer here to the XML Schema in the appendix of the document, 450 or to a well-known external reference in the case of an extension 451 with an externally-defined schema. 453 2.6. Appendix: XML Schema Definition for Extension 455 The XML Schema describing the elements defined in the Extension 456 Defintion section is given here. Each of the examples in section 457 Section 2.3 should be verified to validate against this schema by 458 automated tools. 460 3. Security Considerations 462 This document defines a template for MILE extensions to the IODEF and 463 RID documents; as such, it has no security considerations on its own. 465 4. IANA Considerations 467 This section will be updated. 469 5. References 471 5.1. Normative References 473 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 474 Object Description Exchange Format", RFC 5070, 475 December 2007. 477 [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", 478 RFC 6045, November 2010. 480 5.2. Informative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 486 Architecture", RFC 2373, July 1998. 488 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 489 Resource Identifiers (URI): Generic Syntax", RFC 2396, 490 August 1998. 492 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 493 April 2001. 495 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 496 Internet: Timestamps", RFC 3339, July 2002. 498 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 499 Text on Security Considerations", BCP 72, RFC 3552, 500 July 2003. 502 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 503 (LDAP): Schema for User Applications", RFC 4519, 504 June 2006. 506 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 507 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 508 May 2008. 510 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 511 Uniform Resource Identifiers (URI) Dynamic Delegation 512 Discovery System (DDDS) Application (ENUM)", RFC 6116, 513 March 2011. 515 Authors' Addresses 517 Dr. Katherine S. Goodier 518 L-3 Communications" 519 2720 Technology Drive 520 Annapolis Junction 521 USA 523 Phone: +01 301 547 7043 524 Email: katherine.goodier@l-3com.com 526 Damir Rajnovic 527 Cisco 529 Email: gaus@cisco.com