idnits 2.17.1 draft-wierzbicki-cidss-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1527. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 4, 2008) is 5707 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '10' is defined on line 1329, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1333, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1341, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-idwg-idmef-xml-11 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Common Intrusion Detection Signatures A. Wierzbicki 2 Standard (CIDSS) J. Kalinski 3 T. Kruszona 4 Internet Draft Polish-Japanese Institute 5 of Information Technology 6 Intended status: Informational September 4, 2008 7 Expires: March 2009 9 Common Intrusion Detection Signatures Standard 10 draft-wierzbicki-cidss-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on March 4, 2009. 38 Abstract 40 The purpose of the Common Intrusion Detection Signatures Standard 41 (CIDSS) is to define a common data format for storing signatures from 42 different intrusion detection systems. 44 This Internet-Draft describes a common data format to represent 45 information contained in signatures of intrusion detection systems, 46 and explains the rationale for using this common format. The proposed 47 format is a dialect of the Extensible Markup Language (XML). An XML 48 Document Type Definition is developed, and examples are provided. 50 Table of Contents 52 1. Introduction..................................................2 53 1.1. About CIDSS..............................................2 54 1.2. Potential Applications of CIDSS..........................3 55 2. XML CIDSS Signatures..........................................4 56 2.1. Structure of a CIDSS document............................5 57 2.2. Structure of a CIDSS signature...........................5 58 2.3. Data types used by the Pattern_Content element...........6 59 2.4. Logical expressions used in CIDSS signature definitions..6 60 2.5. XML elements and attributes used in CIDSS................7 61 2.5.1. Signatures..........................................7 62 2.5.2. Signature...........................................8 63 2.5.3. Protocols...........................................9 64 2.5.4. Sources............................................15 65 2.5.5. Destinations.......................................17 66 2.5.6. Patterns...........................................18 67 2.5.7. Session............................................22 68 3. Conventions used in this document............................29 69 4. Security Considerations......................................29 70 5. IANA Considerations..........................................29 71 6. Acknowledgments..............................................29 72 7. References...................................................30 73 7.1. Normative References....................................30 74 7.2. Informative References..................................30 75 APPENDIX A: XML CIDSS Document Example..........................32 76 APPENDIX B: The schema of CIDSS - common.xsd....................35 78 1. Introduction 80 1.1. About CIDSS 82 Common Intrusion Detection Signatures Standard is intended to be a 83 standard format of signatures used widely in Network Intrusion 84 Detection Systems (NIDS). An IDS is controlled by a set of decision 85 rules. A decision rule of an IDS is composed of two components: a 86 description of specific characteristics of an intrusion attempt (a 87 signature) and an action that has to be carried out when the data 88 provided by IDS sensors matches the signature. This document focuses 89 on the remaining part of an IDS decision rule: the IDS signature. 91 Currently, every IDS uses a different format of signatures. CIDSS 92 defines a common format of signatures that attempts to express all 93 information contained in signatures of various IDS. The CIDSS 94 signature format is based on XML to facilitate the adaptation and 95 applications of the proposed standard. The CIDSS signature format is 96 designed to be extensible, and therefore it SHOULD be simple to 97 incorporate features of future and current IDS systems that have not 98 been taken into account in the first design. 100 The main goal of CIDSS is to enable administrators of IDS systems to 101 share, compare, evaluate and criticize signatures used to detect 102 intrusion events. The increasingly dynamic, global, and frequent 103 nature of intrusion attempts is a trend that forces administrators to 104 greater efforts to protect increasingly valuable information. The 105 possibility to disseminate knowledge and experience about IDS 106 systems' operation would be enhanced by the introduction of a common 107 signature format. Therefore the use of a common IDS signature format 108 SHOULD lead to a greater security of information. Other possible 109 applications of CIDSS will be discussed in the next section. 111 CIDSS Homepage: http://cidss.sourceforge.net 113 1.2. Potential Applications of CIDSS 115 One of the main applications of CIDSS is the translation of 116 signatures between various IDS. The ability to translate a signature 117 of an IDS into the common data format and to carry out a reverse 118 translation implies that it SHOULD be possible to translate 119 signatures of different IDS using the common data format as an 120 intermediate form. The development of this standard has been carried 121 out in parallel with the development of an IDS signature translator. 122 Currently, the translator is able to translate signatures of Snort 123 [4] and Dragon [6] IDS into the common format, and among the three 124 systems. It's also partially tested with: Shoki [7], ISS 125 RealSecure(TM) [8], and Cisco NetRanger(TM) [9]. 127 The IDS translator is developed under the GNU General Public License 128 and is available from http://sigtranslator.sourceforge.net. 130 Another possible application of CIDSS would be the creation and 131 maintenance of signature databases by independent providers of IDS 132 signatures. The use of XML as a base for the common signature format 133 enables a simple integration of collections of signatures into a 134 database. This SHOULD improve the searching and management of a 135 signature collection. The business model of an independent signature 136 provider could be the delivery of up-to-date, comprehensive signature 137 collections to increase security of specific services, systems and 138 platforms. 140 +-----------------------------------+ 141 | First part of a signature | 142 | ... |<----|--| 143 | ... |<----|--| 144 | ... |<----|--| 145 | ... |<----|--| 146 +-----------------------------------+ | | 147 +-----------------------------------------+ | | 148 | Second part of a signature | | | 149 | | | | 150 | ... | | | 151 | ... | | | 152 | | | | 153 | ... | | | 154 | | | | 155 | ...|-- | 156 | | | 157 | ... |------ 158 | | 159 | | 160 +-----------------------------------------+ 161 Figure 1 The main components and logical structure of a CIDSS 162 signature 164 2. XML CIDSS Signatures 166 This section describes the logical and structural rules for creating 167 signatures in CIDSS format. Each XML element and attribute used in 168 the CIDSS format are described and explained on examples. In appendix 169 A, a full CIDSS signature is provided that has been used to provide 170 the examples used in this section. 172 CIDSS meets XML ver. 1.0 requirements [2]. CIDSS is defined as a 173 dialect of XML using the XML Schema Definition (XSD). The schema of 174 CIDSS is an appendix to this document (see appendix B: CIDSS XSD 175 schema. cidss.xsd) 177 2.1. Structure of a CIDSS document 179 A CIDSS document is a collection of signatures. Each signature is 180 independent, and can be stored in a separate CIDSS document or 181 together with other signatures. The main XML element of a CIDS 182 document is the "Signatures" element. 184 2.2. Structure of a CIDSS signature 186 A CIDSS signature is composed of several XML elements, contained in a 187 common "Signature" element. A signature can be divided into two 188 basic, logical parts. The first part, that includes (among others) 189 the elements "Sources", "Destinations", "Protocols" and "Patterns", 190 is used to define building blocks of a signature definition. These 191 blocks are combined in the second part of a signature, and are kept 192 separate in order to shorten the signature definition and avoid 193 redundancy. For instance, the definition of relevant information 194 about the TCP protocol might be kept inside the "Protocols" element 195 and might be later combined with several patterns (defined inside the 196 "Patterns" element). Rather than repeat the definition of the TCP 197 protocol each time a new pattern is used, the signature definition 198 will refer to the information kept inside the "Protocols" element. 200 The second part of a signature contains information on how to use the 201 building blocks defined in the first part. The main XML element of 202 the second part of a signature is the "Session" element. A "Session" 203 element defines the main signature behavior. A signature MAY use 204 state managed by the IDS for a certain flow of packets (or session). 205 However, it is possible to create stateless signatures, by omitting 206 information REQUIRED for the state mechanisms to work. Then, the 207 information contained in a "Session" element defines the conditions 208 that MUST be fulfilled by sensor data in order to trigger the 209 signature. 211 In the second part of a signature, the information contained in the 212 first part is combined using logical expressions. Each element in the 213 first part of a signature that contains a "building block" for the 214 signature definition MUST have an identifier that is unique in the 215 signature (not necessarily in the CIDSS document that contains the 216 signature). This identifier can be used in the second part of a 217 signature to refer to the "building block" defined by this element. 218 The building blocks MAY be combined using logical expressions that 219 are constructed by the "AND" and "OR" operators. The logical 220 expressions are contained in special tags, and are treated as strings 221 by the XML parser. CIDSS logical expressions are described in section 222 2.4. 224 When the content of element contain "<" (less then), ">" (greater 225 then), "&" (ampersand), "'" (apostrophe) or """ (quotation mark) 226 signs, it MUST be put into CDATA section. A CDATA section starts with 227 "". 229 Only the characters "<" and "&" are strictly illegal in XML. 230 Apostrophes, quotation marks and greater than signs are legal, but it 231 is a good habit to replace them. 233 Note: A CDATA section cannot contain the string "]]>" 235 2.3. Data types used by the Pattern_Content element 237 The data types used in CIDSS signatures are compatible with the XML 238 [2] and XML Schema (XSD) [3] specification. The following data types 239 are supported: 240 - String value 242 You MUST use encoding defined by "encoding" attribute (e.g. ). UTF-8 RECOMMENDED. Refer to 244 Appendix A and Appendix B 245 - Hexadecimal values 246 - Decimal values 248 2.4. Logical expressions used in CIDSS signature definitions 250 Some elements in the CIDSS signature contain information that 251 describes how other elements MUST be combined in the signature 252 definitions. The content of these elements is a String value that 253 contains a logical expression. A translating software MUST be able to 254 process these expressions. 256 CIDSS logical expressions MUST use operators "AND", "OR", and "NOT" 257 (uppercase). The operators are interpreted as follows: 258 - AND - logical conjunction 259 - OR - logical alternative 260 - NOT - logical negation 262 The operator precedence in CIDSS logical expressions MUST be 263 interpreted as follows: NOT precedes AND precedes OR. 265 CIDSS logical expressions MAY contain ordinary braces "(" or ")" that 266 are interpreted as in logical expressions. 268 Apart from braces and operators, CIDSS logical expressions MUST 269 contain unique identifiers of other XML elements in the CIDSS 270 signature definition that MAY be used in logical expressions. 272 2.5. XML elements and attributes used in CIDSS 274 In this section, all XML elements defined by the CIDSS standard SHALL 275 be introduced. Each element will be defined using a common template 276 to simplify a presentation. This template is explained below: 278 Element name 279 Element description. 280 Presence: [mandatory | optional, single | multiple] 281 Location: element name 282 Attributes: attribute name [type [, unique]] 283 Contained elements: element names 285 mandatory - means that the element MUST exist in the signature 287 optional - the element MAY exist in the signature 289 single - if the element exists in the signature, then this element 290 MUST exist in exactly one instance 292 multiple - if the element exists in the signature, then this element 293 MAY exist many instances 295 unique - value of the element MUST NOT be repeated as value of the 296 same element in other place 298 2.5.1. Signatures 300 A root element of a CIDSS XML document. 302 Presence: mandatory, single 303 Location: root element 304 Contained elements: Signature [multiple, mandatory] 306 Example: 308 311 where "" SHOULD be replaced by the filename of the 312 XSD schema file (e.g. cidss.xsd) 314 2.5.2. Signature 316 This element contains all information about a signature. Describes 317 conditions required to identify traffic as suspicious and to take an 318 action. 320 Presence: mandatory 321 Location: element Signatures 322 Attributes: SID [type: integer, single, mandatory, unique] 323 Contained elements: Enabled [single, mandatory], Sig_Source [single, 324 optional], Description [single, optional], Action [single, optional], 325 Protocols [single, mandatory], Sources [single, mandatory], 326 Destinations [single, mandatory], Patterns [single, mandatory], 327 Logged_Packets [single, optional], Message [single, mandatory], 328 Comment [multiple, optional], Session [single, mandatory] 329 Example: See Appendix A 331 Enabled 333 Defines a current signature state. Setting this to true, the 334 signature will be analyzed by the IDS. Otherwise the signature SHOULD 335 be skipped. 337 Presence: mandatory 338 Type: Boolean 339 Default value: true 340 Location: element Signature 341 Example: true 343 Sig_Source 344 Optional element for use in translators. Specifies the IDS from which 345 the signature was translated or ported. This element SHOULD contain 346 string that identifies a signature source. 348 Presence: optional, single 349 Type: String 350 Location: element Signature 351 Example: Snort 353 Description 355 This element MAY contain a simple description of the signature. 357 Presence: optional 358 Type: String 359 Location: element Signature 360 Example: Try to get passwd file using ftp 362 Action 364 This MAY define actions performed by an IDS after intrusion 365 detection. 366 Suggested values: drop, allow, alert, and warning 368 Presence: optional, single 369 Type: String 370 Location: element Signature 371 Example: alert 373 2.5.3. Protocols 375 This element contains description of multiple protocols used in 376 potential attack. 378 Location: Signature 379 Presence: mandatory, multiple 380 Attributes: ID[integer,unique] 382 Protocol 384 The element used to describe the network protocol. Options of the 385 protocol used in this element depend on a protocol type. 387 The Proto_ID attribute is used for identification in the Proto_Logic 388 element - it is REQUIRED only when there is more than one Protocol in 389 the Protocols element. 391 Presence: mandatory, multiple. 392 Type: String 393 Attributes: Proto_ID [integer, unique], Type [enum: tcp, udp, ip, 394 icmp, application] 395 Location: element Signature 396 Contained elements: TCP_Ack [single, optional], TCP_State [single, 397 optional], TCP_Seq [single, optional], TCP_Dsize [single, optional], 398 TCP_Flags [single, optional], TCP_Window [single, optional], 399 UDP_Dsize [single, optional], ICMP_Dsize [single, optional], 400 ICMP_Icmp_Id [single, optional], ICMP_Icmp_Seq [single, optional], 401 ICMP_Icode [single, optional], ICMP_Itype [single, optional], IP_Ttl 402 [single, optional], IP_Tos [single, optional], IP_Ipopts [single, 403 optional], IP_Fragbits [single, optional], IP_Id [single, optional], 404 IP_Ip_Proto [single, optional], IP_Dsize [single, optional], Isdataat 405 [single, optional], Rpc [single, optional] 407 Isdataat 409 Checks that the data fields in the packet are in the specified 410 offset. When the content of this element contain "<" and ">" signs, 411 it MUST be put into section. In other way it MAY 412 contain CDATA section, but it is not REQUIRED. 414 Allowed values: Integer or integer (more than a given value) 416 Location: Protocol 417 Presence: single, optional 418 Example: 420 Rpc 422 This element specifies the RPC application, version, and procedure 423 numbers in SUNRCP call requests. It MUST contain a string in the 424 following format: 426 Allowed format: , [|*], 427 [|*]> 428 Location: Protocol, Type=="Application" 429 Presence: single, optional 430 Type: String 431 Example: 100000,*,3 433 TCP_Ack 434 Checks the specific TCP ack number 436 Location: Protocol, Type=="TCP" 437 Presence: single, optional 438 Type: integer 439 Example: 0 441 TCP_Seq 443 Checks the specific TCP seq number 445 Location: Protocol, Type=="TCP" 446 Presence: single, optional 447 Type: integer 448 Example: TCP_Seq>0 450 TCP_State 452 Describes current protocol state e.g. established, stateless 454 Location: Protocol, Type=="TCP" 455 Allowed values: [established|stateless] 456 Presence: single, optional 457 Type: string 458 Example: established 460 TCP_Flags 462 Check if the specific TCP Flags are present 464 Location: Protocol, Type=="TCP" 465 Allowed values: [!|*|+][FSRPAU120,] 467 Values description: F-FIN, S-SYN, R-RST, P-PSH, A-ACK, U-URG, 1- 468 Reserved bit 1, 2-Reserved bit 2, 0-No Flags set. 469 Modifiers description: + - match on the specific bits, plus any 470 others, * - match if any of the specified bits are set, ! - match if 471 specified bits are not set 473 Presence: single, optional 474 Type: String 475 Example: +SA 477 TCP_Window 479 Checks value of the TCP window size 480 Location: Protocol, Type=="TCP" 481 Presence: single, optional 482 Type: integer 483 Example: 34000 485 TCP_Dsize 487 Checks the packet data field size in TCP protocol. When the content 488 of this element contain "<" and ">" signs, it MUST be put into 489 section. In other way it MAY contain CDATA section, 490 but it is not REQUIRED. 492 Allowed signs: <, >, <=, >=, number 493 Location: Protocol, Type=="TCP" 494 Presence: single, optional 495 Type: String 496 Example: 498 UDP_Dsize 500 Checks packet data field size in UDP protocol. When the content of 501 this element contain "<" and ">" signs, it MUST be put into 502 section. In other way it MAY contain CDATA section, 503 but it is not REQUIRED. 505 Allowed signs: <, >, <=, >=, number 506 Location: Protocol, Type=="UDP" 507 Presence: single, optional 508 Type: String 509 Example: 511 ICMP_Dsize 513 Checks the packet data field size in ICMP protocol. When the content 514 of this element contain "<" and ">" signs, it MUST be put into 515 section. In other way it MAY contain CDATA section, 516 but it is not REQUIRED. 518 Allowed signs: <, >, <=, >=, number 519 Location: Protocol, Type=="ICMP" 520 Presence: single, optional 521 Type: String 522 Example: =64]]> 524 ICMP_Icmp_Id 526 Checks the value of specific ICMP ID 527 Location: Protocol, Type=="ICMP" 528 Presence: single, optional 529 Type: integer 530 Example: 0 532 ICMP_Icmp_Seq 534 Checks the value of ICMP sequence 536 Location: Protocol, Type=="ICMP" 537 Presence: single, optional 538 Type: integer 539 Example: 0 541 ICMP_Icode 543 Checks the value of specific ICMP code. When the content of this 544 element contain "<" and ">" signs, it MUST be put into 545 section. In other way it MAY contain CDATA section, 546 but it is not REQUIRED. 548 Allowed signs: <, >, number 549 Location: Protocol, Type=="ICMP" 550 Presence: single, optional 551 Type: String 552 Example: 25]]> 554 ICMP_Itype 556 Checks the value of specified ICMP type. When the content of this 557 element contain "<" and ">" signs, it MUST be put into 558 section. In other way it MAY contain CDATA section, 559 but it is not REQUIRED. 561 Allowed signs: <, >, number 562 Location: Protocol, Type=="ICMP" 563 Presence: single, optional 564 Type: String 565 Example: 25]]> 567 IP_Ttl 569 Specifies IP time-to-live value. When the content of this element 570 contain "<" and ">" signs, it MUST be put into 571 section. In other way it MAY contain CDATA section, but it is not 572 REQUIRED. 574 Allowed signs: <, >, <=, >=,-, number 575 Location: Protocol, Type=="IP" 576 Presence: single, optional 577 Type: string 578 Example: 6-8 - values between 6 and 8 580 IP_Tos 582 Check the IP ToS field for specified value 584 Location: Protocol, Type=="IP" 585 Presence: single, optional 586 Type: integer 587 Example: 2 589 IP_Fragbits 591 Checks fragmentations bits for the specified value 593 Location: Protocol, Type=="IP" 594 Presence: single, optional 595 Type: String 596 Example: DM+ 598 IP_Id 600 Checks ID field in IP protocol for the specified value 602 Location: Protocol, Type=="IP" 603 Presence: single, optional 604 Type: integer 605 Example: 34222 607 IP_Ipopts 609 This element checks if the specified IP option is present. 611 Allowed values: rr - Record route, eol - end of list, nop - no op, ts 612 - Time Stamp, sec - IP security option, lsrr - Loose source routing, 613 ssrr - Strict source routing, satid - Stream identifier, any - any IP 614 options are set 616 Location: Protocol, Type=="IP" 617 Presence: single, optional 618 Type: String 619 Example: lsrr 620 IP_Dsize 622 Checks size of packet data field. When the content of this element 623 contain "<" and ">" signs, it MUST be put into 624 section. In other way it MAY contain CDATA section, but it is not 625 REQUIRED. 627 Allowed signs: <, >, <=, >=, number 628 Location: Protocol, Type=="IP" 629 Presence: single, optional 630 Type: String 631 Example: 34000 633 IP_Ip_Proto 635 Checks IP protocol header for the specified value. When the content 636 of this element contain "<" and ">" signs, it MUST be put into 637 section. In other way it MAY contain CDATA section, 638 but it is not REQUIRED. 640 Allowed signs: <, >, <=, >=, number, name 641 Location: Protocol, Type=="IP" 642 Presence: single, optional 643 Type: String 644 Example: igmp 646 Proto_Logic 648 This element describes logical rules to combine the information in 649 Protocol elements contained in one Protocols element. Logical 650 operators in Proto Logic element are described in section 2.4. 652 Presence: optional, single 653 Location: element Protocols 654 Example: 1 OR (2 AND 3) 656 2.5.4. Sources 658 This element contains information that describes properties of a 659 source of network communications. If Sources occurs more then once, 660 then every Sources MUST have an unique id (attribute) used in 661 Src_Logic that defines logical dependences between each of them. 663 Presence: mandatory, single 664 Location: element Signature 665 Attributes: ID 666 Contained elements: Source[multiple, mandatory], Src_Logic [single, 667 optional] 668 Example: See Appendix A 670 Source 672 This element contains descriptions of source hosts. Src_ID attribute 673 is local (in one Sources element) id for use with the Src_Logic 674 element. 676 Presence: mandatory, multiple 677 Location: element Sources 678 Attributes: Src_ID [presence: mandatory if more than one Source_ in 679 one Sources element, type: integer, unique] 680 Contained elements: Source_IP[single, mandatory], Source_Port[single, 681 optional] 682 Example: See Appendix A 684 Source_IP 686 This element MUST contain an IPv4 or IPv6 network address in any 687 notation. The value "any" means that all addresses will be considered 688 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 689 value of Neg attribute is "true", then the values specified in the 690 Source_IP element are interpreted as addresses that MUST NOT match 691 the source address in order for the signature to apply. Mask 692 attribute defines IPv4 or IPv6 mask for the specified IP address. 694 Allowed values: Any string 695 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 696 true|false, default: false], Mask [presence: mandatory, type: string, 697 allowed values: mask in octet or bit notation] 698 Presence: mandatory, single 699 Type: String 700 Location: element Source 701 Example: $EXTERNAL_NET 702 Variable $EXTERNAL_NET is defined in an IDS. (e.g. 703 $EXTERNAL_NET=1.2.3.4) 705 Source_Port 707 The value of this element is a port number or range of ports 708 expressed by two port numbers divided with a ":" sign. The "135:139" 709 expression means that all ports between 135 and 139 will be 710 considered, accounting ports 135 and 139. The value "any" means that 711 all ports will be considered. 713 Attributes: Neg [presence: optional, type: boolean, allowed values: 714 true|false, default: false] 715 Presence: If Protocol Type is set to tcp, udp or ip then mandatory, 716 if Protocol Type value is icmp then MUST NOT be set. 717 Type: String 718 Location: element Source 719 Example: any 721 Src_Logic 723 Defines logical dependences between each Source description. Logical 724 operators: (, ), AND, OR 726 Location: Sources 727 Example: 2 OR (1 AND 3) 729 2.5.5. Destinations 731 This element contains information that describes properties of a 732 destination of network communications. If Destinations occurs more 733 then once, then every Destination MUST have an unique id (attribute) 734 used in Dst_Logic to define logical dependences between each of them. 736 Presence: mandatory, single 737 Location: element Signature 738 Contained elements: Destination [multiple, mandatory] 739 Example: See Appendix A 741 Destination 743 This element contains descriptions of destination hosts. Dst_ID 744 attribute is local (in one Destinations element) id for use with the 745 Dst_Logic element. 747 Presence: mandatory, multiple 748 Location: element Destinations 749 Attributes: Dst_ID [presence: mandatory if more than one Destination_ 750 in one Destinations element, type: integer, unique] 751 Contained elements: Destination_IP [single, mandatory], 752 Destination_Port [single, optional] 753 Example: See Appendix A 755 Destination_IP 756 This element MUST contain an IPv4 or IPv6 network address in any 757 notation. The value "any" means that all addresses will be considered 758 and is an alias for 0.0.0.0 IPv4 address and ::0 for IPv6. If the 759 value of Neg attribute is "true", then the values specified in the 760 Destination_IP element are interpreted as addresses that MUST NOT 761 match the destination address in order for the signature to apply. 762 Mask attribute defines IPv4 or IPv6 mask for the specified IP 763 address. 765 Allowed values: Any string 766 Attributes: Neg [presence: mandatory, type: boolean, allowed values: 767 true|false, default: false], Mask [presence: mandatory, type: string, 768 allowed values: mask in octet or bit notation] 769 Presence: mandatory, single 770 Type: String 771 Location: element Destination 772 Example: Similar as in Source_IP element 774 Destination_Port 776 The value of this element is a port number or range of ports 777 expressed by two port numbers divided with a ":" sign. The "135:139" 778 expression means that all ports between 135 and 139 will be 779 considered, accounting ports 135 and 139. The value "any" means that 780 all ports will be considered. 782 Attributes: Neg [presence: optional, type: boolean, allowed values: 783 true|false, default: false] 784 Presence: If Protocol Type value is set to tcp, udp or ip then 785 mandatory, if Protocol Type value is icmp then MUST NOT be set. 786 Type: String 787 Location: element Destination 788 Example: 445 790 Dst_Logic 792 Defines logical dependences between each Destination description. 793 Logical operators: (, ), AND, OR 795 Location: Destinations 796 Example: 1 AND 2 798 2.5.6. Patterns 800 This element contains multiple Pattern elements. 802 Presence: single, mandatory (if Protocol is to tcp, udp, ip or 803 application than element is present) 804 Location: element Signature 805 Contained elements: Pattern [multiple, optional] 806 Attributes: ID[integer, unique] 807 Example: See Appendix A 809 Pattern 811 This element contains information about the content of a packet that 812 is considered as potentially dangerous. Attribute Pat_ID is used in 813 Pat_Logic element to define logical expressions using multiple 814 Pattern elements 816 Presence: mandatory, multiple 817 Location: element Patterns 818 Contained elements: Pattern_Type [single, mandatory], Pattern_Content 819 [single, optional], Pattern_Depth [single, optional], 820 Pattern_Uricontent [single, optional], Pattern_Offset [single, 821 optional], Pattern_Within [single, optional], Pattern_Distance 822 [single, optional] 823 Attributes: Pat_ID [integer, unique] 824 Example: See Appendix A 826 Pattern_Type 828 Using CIDSS you can specify patterns in hexadecimal, decimal, string, 829 or using PCRE [5] expressions. 831 Presence: mandatory 832 Type: String 833 Location: element Pattern 834 Permitted values: "hex", "dec", "string", "pcre" 835 Default value: "string" 836 Example: string 838 Pattern_Content 840 Defines packet content that is interpreted as an intrusion and 841 considered dangerous. To define the content, regular expressions can 842 be used in the Pattern_Content element. Regular expression MUST be in 843 the PCRE format (Perl Compatible Regular Expressions) [5]. If 844 Rawbytes attribute value is "true" it means pattern is searched in 845 raw packets ignoring decoding that was done by preprocessors. If Neg 846 attribute is true, it means pattern MUST NOT contain specified value. 848 If the content of this element contain "<" and ">" signs, it MUST be 849 put into section. In other way it MAY contain CDATA 850 section, but it is not REQUIRED. 852 Presence: mandatory, single 853 Attributes: CaseSensitive [allowed values: true|false, default value: 854 true], Rawbytes [allowed values: true|false, default value: false], 855 Neg [allowed values: true|false, default: false] 856 Type: Same as value of Pattern_Type 857 Location: element Pattern 858 Example: RETR 859 passwd 861 Pattern_Pcre_Flags 863 Contains standard Perl Compatible_Regular_Expressions modifiers and 864 Perl compatible modifiers or Snort modifiers (used for Snort 865 compatibility) 867 Presence: optional, single 868 Location: element Pattern 869 Type: string 870 Example: iRm 872 Pattern_Depth 874 Defines how many bytes of the packet MUST be searched in order to 875 find the content defined in the Pattern_Content element that is 876 contained by the same Pattern element as this element. 878 Presence: optional, single 879 Location: element Pattern 880 Type: Integer 881 Example: 10 883 Pattern_Uricontent 885 This element describes content of packet in URI format. If this 886 element contains restricted characters (as described in section 2.2) 887 it MUST be put into section. In other way it MAY 888 contain CDATA section, but it is not REQUIRED. 890 Type: string 891 Location: Pattern 892 Presence: optional, single 893 Example: 895 898 Pattern_Offset 900 Specifies offset in bytes from beginning of packet to search for the 901 pattern. 903 Type: integer 904 Location: Pattern 905 Presence: optional, single 906 Example: 5 908 Pattern_Within 910 Used to describe how many packets MUST be at most between two 911 patterns. 913 Type: integer 914 Location: Pattern 915 Presence: optional, single 916 Example: 4 918 Pattern_Distance 920 Defines how far the IDS SHOULD look into a packet for the specified 921 pattern relative to last match. 923 Type: integer 924 Location: Pattern 925 Presence: optional, single 926 Example: 3 928 Pat_Logic 930 This element describes logical rules to combine the information in 931 Pattern elements contained in one Patterns element. Logical operators 932 in Pat_Logic expressions SHOULD be: OR, AND, NOT (as described in 933 section 2.4). 935 Presence: optional, single 936 Location: element Patterns 937 Example: (NOT 1 AND 2) OR 3 939 Logged_Packets 941 Number of packets logged when the system detects an intrusion 942 Presence: optional, single 943 Location: element Signature 944 Type: Integer 945 Example: 0 947 Message 949 Contains the message generated by the IDS when a packet described by 950 this signature was detected. If the content of this element contain 951 "<" and ">" signs, it MUST be put into section. In 952 other way it MAY contain CDATA section, but it is not REQUIRED. 954 Presence: mandatory, single 955 Location: element Signature 956 Type: String 957 Example: FTP password file GET request 959 Comment 961 This element MAY be used for additional comments and information 962 about the signature. The element MAY contain additional information 963 about signature vendor, vulnerability description, http links etc. If 964 the content of this element contains "<" and ">" signs, it MUST be 965 put into section. In other way it MAY contain CDATA 966 section, but it is not REQUIRED. 968 Presence: optional, multiple 969 Location: element Signature 970 Type: String 971 Example: Vendor: Arachnids 973 2.5.7. Session 975 Defines a session that could be identified by the signature if the 976 state mechanisms of an IDS could be used. Otherwise, the information 977 contained in this element describes the conditions that MUST be 978 satisfied by the sensor data in order to trigger the signature. 980 Location: Signature 981 Presence: single, mandatory 982 Contained elements: Session_Filter [single, optional], Session_Start 983 [single, optional], Session_End [single, optional], 984 Session_Identification [single, optional], Session_Instructions 985 [single, optional] 986 Session_Filter 988 Contains IDs of Source, Destination, Protocol and Pattern elements, 989 combined using logical expressions in the format described in section 990 2.4. The information contained in this element specifies the 991 conditions that MUST be met by sensor data so that the packet will be 992 included in this session. 994 Location: Session 995 Presence: single, optional 996 Allowed values: CIDSS logical expressions. 998 Session_Start 1000 Contains IDs of Source, Destination, Protocol or Pattern elements, 1001 combined using logical expressions in the format described in section 1002 2.4. The information contained in this element specifies the 1003 conditions that MUST be met by sensor data so that the packet will 1004 define the beginning of a new session. All session state MUST be 1005 reset by the IDS when a new session begins. 1007 Location: Session 1008 Presence: single, optional 1009 Allowed values: CIDSS logical expressions. 1011 Session_End 1013 Contains IDs of Source, Destination, Protocol or Pattern elements, 1014 combined using logical expressions in the format described in section 1015 2.4. The information contained in this element specifies the 1016 conditions that MUST be met by sensor data so that the packet will 1017 define the beginning of a new session. 1019 Instead of or in addition to conditions for sensor data, this element 1020 MAY include the element Session_Timeout, that specifies a timeout for 1021 the session or MAY include Session_Pckt_Count, that defines maximum 1022 number of packets considered in current session. When both conditions 1023 are specified, then the one that is fulfilled first will terminate 1024 the session. 1026 Location: Session 1027 Presence: single, mandatory if the Session_Start element is present 1028 Contained elements: Session_Timeout [single, optional], 1029 Session_Pckt_Count [single, optional] 1031 Session_Pckt_Count 1032 Defines maximum number of packets that are considered during session. 1034 Presence: single, optional 1035 Location: Session_End 1036 Type: Integer 1037 Example: 5 1039 Session_Timeout 1041 Defines a timeout for the session. The time MUST be specified in the 1042 format: an integer and a single character (the character MUST be one 1043 of: ms,s,m,h - milliseconds, seconds, minutes, hours). 1045 Presence: optional, single 1046 Type: String 1047 Location: Session_End 1048 Example: 10s 1049 Example description: The timeout for the session is 10 seconds. 1051 Session_Identification 1053 Defines additional conditions that MUST be met by sensor data so that 1054 a packet will be included in this session. These conditions apply 1055 after a session has started. For instance, a TCP session will include 1056 only the packets that have the same source and destination as the 1057 source and destination of packets that started the session. The 1058 conditions are specified by including special elements in this 1059 element. 1061 Location: Session 1062 Presence: single, mandatory if the Session_Start attribute is present 1063 Contained elements: Same_Source_IP [single, optional], 1064 Same_Source_Port [single, optional], Same_Destination_IP [single, 1065 optional], Same_Destination_Port [single, optional], Same_Protocol 1066 [single, optional], Same_Direction [single, optional] 1068 Same_Source_IP 1070 If this element is present in Session_Identification, packets that 1071 will be included in the session MUST have the same source IP address 1072 as the starting packet. 1074 Type: Boolean 1075 Presence: single, optional 1076 Location: Session_Identification 1078 Same_Source_Port 1079 If this element is present in Session_Identification, packets that 1080 will be included in the session MUST have the same source port as the 1081 starting packet. 1083 Type: Boolean 1084 Presence: single, optional 1085 Location: Session_Identification 1087 Same_Destination_IP 1089 If this element is present in Session_Identification, packets that 1090 will be included in the session MUST have the same destination IP 1091 address as the starting packet. 1093 Type: Boolean 1094 Presence: single, optional 1095 Location: Session_Identification 1097 Same_Destination_Port 1099 If this element is present in Session_Identification, packets that 1100 will be included in the session MUST have the same destination port 1101 as the starting packet. 1103 Type: Boolean 1104 Presence: single, optional 1105 Location: Session_Identification 1107 Same_Protocol 1109 If this element is present in Session_Identification, packets that 1110 will be included in the session MUST be of the same protocol as the 1111 starting packet. 1113 Type: Boolean 1114 Presence: single, optional 1115 Location: Session_Identification 1117 Same_Direction 1119 If this element is present in Session_Identification, packets that 1120 will be included in the session MUST have been sent in the same 1121 direction as the starting packet. 1123 Type: Boolean 1124 Presence: single, optional 1125 Location: Session_Identification 1126 Session_Instructions 1128 This element works like a switch statement for the state mechanism of 1129 an IDS. The information contained in this element defines the 1130 statefull behavior of an IDS for this session. The element contains 1131 several Session_Case elements that include conditions for the case to 1132 apply, as well as instructions to be carried out if the case applies. 1133 For efficiency reasons, it is assumed that all conditions for state 1134 instructions will be brought down into a conjunctive normal form (a 1135 logical expression that includes alternatives only at the highest 1136 level). That means that in every case element, all case conditions 1137 are treated as a logical conjunction (logical AND). This ought to 1138 simplify the processing of these instructions. 1140 Location: Session 1141 Presence: single, optional 1142 Contained elements: Session_Case [multiple] 1144 Session_Case 1146 This element contains the conditions and instructions of a case in 1147 the switch statement that is defined by the containing 1148 Session_Instructions element. For readability, the conditions are 1149 split up into three groups: additional conditions for sensor data 1150 that MUST be satisfied so that the packet will apply to this case, 1151 the direction of the packet, and the conditions that MUST be 1152 satisfied by the state variables of a session in order for the case 1153 to apply. The instructions of a case are contained in the mandatory 1154 Case_State_Instructions element. 1156 Location: Session_Instructions 1157 Presence: multiple 1158 Contained elements: Case_Filter [single, optional], Direction 1159 [single, optional], Case_State_Condition [single, optional], 1160 Case_State_Instructions [single, mandatory] 1162 Case_Filter 1164 Contains IDs of Source, Destination, Protocol or Pattern elements, 1165 combined using logical expressions in the format described in section 1166 2.4. The information contained in this element specifies the 1167 conditions that MUST be met by sensor data so that the packet will 1168 apply to this case. 1170 Location: Session_Case 1171 Presence: single, optional 1172 Allowed values: CIDSS logical expressions. 1174 Direction 1176 Defines a direction of network traffic, once a source and destination 1177 of traffic are specified (e.g. after the start of a session). Allowed 1178 values are: "sd" and "ds". If direction value is "sd" it means that 1179 the packet has been sent from source to destination. If the value of 1180 this element is "ds" it means that traffic goes from destination to 1181 source. 1183 Allowed values: sd|ds 1184 Default value: sd 1185 Location: Session_Case 1186 Presence: single, optional 1188 Case_State_Condition 1190 This element contains conditional state expressions that MUST all be 1191 satisfied (evaluate to a boolean value of "true") in order for the 1192 case to apply. These instructions MAY check the values of state 1193 variables stored by the IDS for this session. 1195 Location: Session_Case 1196 Presence: single, optional 1197 Contained elements: Isset_Var, Compare_Var 1199 Case_State_Instructions 1201 This element contains state instructions that MUST all be 1202 sequentially carried out by the IDS if the case applies. These 1203 instructions MAY set, unset or modify the values of state variables 1204 stored by the IDS for this session. 1206 Location: Session_Case 1207 Presence: single, optional 1208 Contained elements: Set_Var, Unset_Var, Isset_Var, Isnotset_Var, 1209 Compare_Var, Toggle_Var 1211 Isset_Var 1213 A conditional state expression that evaluates to a boolean value of 1214 "true" if the variable of a name that is specified in the "var" 1215 attribute is set in the state of this session. 1217 Location: Case_State_Condition 1218 Presence: multiple, optional 1219 Attributes: var [type: string; single, mandatory] 1220 Isnotset_Var 1222 A conditional state expression that evaluates to a boolean value of 1223 "true" if the variable of a name that is specified in the "var" 1224 attribute is not set in the state of this session. 1226 Location: Case_State_Condition 1227 Presence: multiple, optional 1228 Attributes: var [type: string; single, mandatory] 1230 Compare_Var 1232 Location: Case_State_Condition 1233 Presence: multiple, optional 1234 Attributes: var [type: string; single, mandatory], value [type: 1235 string; single, mandatory] 1237 Set_Var 1239 Sets value of "var" attribute in state of particular session. 1241 Location: Case_State_Instructions 1242 Presence: multiple, optional 1243 Attributes: var [type: string; single, mandatory], value [type: 1244 string; single, mandatory] 1246 Unset_Var 1248 Nullifies value of "var" used in this session. 1250 Location: Case_State_Instructions 1251 Presence: multiple, optional 1252 Attributes: var [type: string; single, mandatory] 1254 Toggle_Var 1256 Toggle value of "var" attribute in state of particular session. Set 1257 the specified state if the state is unset, otherwise unsets the state 1258 if the state is set. 1260 Location: Case_State_Instructions 1261 Presence: multiple, optional 1262 Attributes: var [type: string; single, mandatory], value [type: 1263 string; single, mandatory] 1265 3. Conventions used in this document 1267 In examples, "C:" and "S:" indicate lines sent by the client and 1268 server respectively. 1270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1272 document are to be interpreted as described in RFC-2119 [1]. 1274 4. Security Considerations 1276 This Internet Draft describes the CIDSS format for storing 1277 information about IDS signatures. The applications of this standard 1278 can raise security concerns, but there is no security concerns 1279 related strictly to the document format. 1281 It is RECOMMENDED that a system for storing CIDSS data SHOULD be 1282 protected against unauthorized access and unauthorized use. The means 1283 for achieving this protection are outside the scope of this document. 1285 5. IANA Considerations 1287 There are no IANA issues in this document. 1289 The RFC Editor may remove this section prior to publication. 1291 6. Acknowledgments 1293 This document was prepared using 2-Word-v2.0.template.dot. 1295 7. References 1297 7.1. Normative References 1299 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1300 Levels", BCP 14, RFC 2119, March 1997. 1302 [2] Markup Language (XML) 1.0, Third Edition, 1303 http://www.w3.org/TR/2004/REC-xml-20040204/ 1305 [3] XML Schema - Specifications and Development, 1306 http://www.w3.org/XML/Schema#dev 1308 [4] Roesch Martin, Green Chris, "Snort Users Manual", 2.3.0, 1309 January 2005, http://www.snort.org 1311 [5] PCRE - Perl Compatible Regular Expressions, 1312 http://www.pcre.org/ 1314 7.2. Informative References 1316 [6] Dragon. Intrusion Detection System. Topics on Writing 1317 Signatures" Enterasys Networks, 2002, 1318 http://dragon.enterasys.com 1320 [7] Shoki, "Shoki User's Guide", Release 0.3.0, 1321 http://shoki.sourceforge.net/ 1323 [8] ISS - Internet Security Systems, Documentation, 1324 http://www.iss.net/support/documentation/ 1326 [9] Cisco - NetRanger, Documentation, 1327 http://www.cisco.com/univercd/cc/td/doc/product/iaabu/netrangr/ 1329 [10] Curry D., Lynch Merrill, Debar H., "The Intrusion Detection 1330 Message Exchange Format", Internet Draft draft-ietf-idwg-idmef- 1331 xml-11, January 2004, expires July 2004 1333 [11] McLaughlin Brett, Java & XML, 2nd Edition, 1334 ISBN: 0-596-00197-5 1336 [12] K. Miakisz, "Translator i wspolny jezyk sygnatur systemow 1337 wykrywania wlaman (Translator and Common Intrusion Detection 1338 Systems Language)", Bachelor thesis, Polish-Japanese Institute 1339 of Information Technology, 2003 1341 [13] arachNIDS - Whitehats Network Security Resource, 1342 http://whitehats.com/ids/ 1344 APPENDIX A: XML CIDSS Document Example 1346 Here we present a sample signature in CIDSS format. Elements of this 1347 signature have been used as examples in the previous sections. 1349 1350 1352 1353 true 1354 snort 1355 alert 1356 NETBIOS SMB-DS DCERPC Remote Activation bind attempt; 1357 sid=2252 1358 NETBIOS SMB-DS DCERPC Remote Activation bind 1359 attempt 1360 reference: cve,CAN-2003-0528 1361 reference: cve,CAN-2003-0605 1362 reference: cve,CAN-2003-0715 1363 reference: 1364 url,www.microsoft.com/technet/security/bulletin/MS03- 1365 039.mspx 1366 1367 1368 any 1369 any 1370 1371 1372 10.0.0.0 1373 any 1374 1375 1376 192.168.1.0 1377 any 1378 1379 1 AND 2 AND 3 1380 1381 1382 1383 any 1384 445 1385 1386 1387 192.168.1.0 1389 445 1390 1391 1392 10.0.0.0 1394 445 1395 1396 1 AND 2 AND 3 1397 1398 1399 1400 established 1401 1402 1 1403 1404 1405 1406 string 1407 1409 5 1410 4 1411 1412 1413 string 1414 1416 2 1417 56 1418 1419 1420 string 1421 |5C 1422 00|P|00|I|00|P|00|E|00 5C 00| 1423 12 1424 5 1425 1426 1427 hex 1428 05 1429 1 1430 1431 1432 hex 1433 0B 1434 1 1435 1 1436 1437 1438 string 1439 |B8|J|9F|M|1C|}|CF 11 1440 86 1E 00| |AF|n|7C|W 1441 16 1442 29 1443 1444 1 AND 2 AND 3 AND 4 AND 5 AND 6 1445 1446 1447 (SRC_1 AND SRC_2 AND SRC_3) AND (DST_1 AND 1448 DST_2 AND DST_3) AND PROTO_1 AND (PAT_1 AND PAT_2 AND PAT_3 AND PAT_4 1449 AND PAT_5 AND PAT_6) 1450 1451 5 1452 1453 1454 1455 1457 APPENDIX B: The schema of CIDSS - common.xsd 1459 Available at http://cidss.sourceforge.net/down/common_v2.3.xsd 1461 Author's Addresses 1463 dr Adam Wierzbicki 1464 Polish-Japanese Institute of Information Technology 1465 Koszykowa 86 1466 02-008 Warsaw, Poland 1467 Email: adamw@pjwstk.edu.pl 1469 Jacek Kalinski 1470 Rechniewskiego 6/24 1471 03-980 Warsaw, Poland 1472 Email: jacek@dyski.one.pl 1474 Tomasz Kruszona 1475 Garwolinska 9/83 1476 04-348 Warsaw, Poland 1477 Email: t.kruszona@b59.net 1479 Full Copyright Statement 1481 Copyright (C) The IETF Trust (2008). 1483 This document is subject to the rights, licenses and restrictions 1484 contained in BCP 78, and except as set forth therein, the authors 1485 retain all their rights. 1487 This document and the information contained herein are provided on an 1488 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1489 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1490 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1491 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1492 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1493 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1495 Disclaimer of Validity 1497 This document and the information contained herein are provided on an 1498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1499 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1500 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1501 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1502 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1505 Intellectual Property Statement 1507 The IETF takes no position regarding the validity or scope of any 1508 Intellectual Property Rights or other rights that might be claimed to 1509 pertain to the implementation or use of the technology described in 1510 this document or the extent to which any license under such rights 1511 might or might not be available; nor does it represent that it has 1512 made any independent effort to identify any such rights. Information 1513 on the procedures with respect to rights in RFC documents can be 1514 found in BCP 78 and BCP 79. 1516 Copies of IPR disclosures made to the IETF Secretariat and any 1517 assurances of licenses to be made available, or the result of an 1518 attempt made to obtain a general license or permission for the use of 1519 such proprietary rights by implementers or users of this 1520 specification can be obtained from the IETF on-line IPR repository at 1521 http://www.ietf.org/ipr. 1523 The IETF invites any interested party to bring to its attention any 1524 copyrights, patents or patent applications, or other proprietary 1525 rights that may cover technology that may be required to implement 1526 this standard. Please address the information to the IETF at 1527 ietf-ipr@ietf.org.