Network Working Group Kohei OHTA INTERNET-DRAFT Cyber Solutions Inc. Expires: August 9, 2004 February 9 2004 XML Schema definition for IDMEF message Status of this Memo Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026[1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 9, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The purpose of this document is to define a message format of IDMEF in XML Schema. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Expires: August 9, 2004 [Page 1] Internet Draft February 9, 2004 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. IDMEF message is defined in Internet-draft of IDWG working group. And this document is based on the draft [3] Table of Contents 1. Introduction...................................................3 2. Namespace......................................................3 3. White space and language support...............................3 4. Data type mapping..............................................4 4.1 IDMEF INTEGER..............................................4 4.2 IDMEF REAL.................................................4 4.3 IDMEF CAHRACTER and STRINGS................................4 4.4 IDMEF BYTES................................................4 4.5 IDMEF Enumeration..........................................4 4.6 IDMEF DATETIME.............................................5 4.7 IDMEF NTPSTAMP.............................................5 4.8 PORTLIST...................................................6 5. Definition.....................................................6 6. Issues.........................................................30 6. Intellectual Property..........................................31 References........................................................32 Security Considerations...........................................32 Author's Addresses................................................32 Full Copyright Statement .........................................32 Expires: August 9, 2004 [Page 2] Internet Draft February 9, 2004 1. Introduction This document is definition of IDMEF message in XML Schema, which is currently defined by DTD. All data model and basic definitions are according to the original definition in DTD. 2. Namespace In the original definition in DTD, "urn:iana:xml:ns:idmef" is used as the namespace and defined as attribute. In this definition in XML Schema uses "urn:ietf:params:xml:ns:idmef" as the namespace according to the document "The IETF XML Registry" [4] 3. White space and language support As same as original DTD definition, XML Schema support following two types of global attribute. In this definition, one group attribute id defined for both of these, and applied for string type data. mespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3g.org/XML/2001/xml.xsd"/> 4. Data type mapping In original definition, some types of data are defined. But, those are not reflected into actual DTD definition due to the limitation of DTD itself. In this document, those are defined with data types in XML Schema. Expires: August 9, 2004 [Page 3] Internet Draft February 9, 2004 4.1. IDMEF INTEGER Integer attributes are represented by the INTEGER data type. Integer data MUST be encoded in Base 10 or Base 16. So, it is defined as union of built-in integer and hexBinary of XML Schema. 4.2. IDMEF REAL Real (floating-point) attributes are represented by the REAL data type. Real data MUST be encoded in Base 10. This type can be supported by built-in float type of XML Schema. 4.3. IDMEF CAHRACTER and STRINGS Single-character attributes are represented by the CHARACTER data type. Multi-character attributes of known length are represented by the STRING data type. STRINGS is defined with built-in string type of XML, which in extended with global attribute for space and language support. 4.4. IDMEF BYTES BYTES can be defined by built-in data type hexBinary. Expires: August 9, 2004 [Page 4] Internet Draft February 9, 2004 4.5. IDMEF Enumeration Enumeration can be defined with enumeration facet with occurrence constraints of XML Schema Only one minOccurs=1 maxOccurs=1 Zero or one minOccurs=0 maxOccurs=1 Zero or more minOccurs=0 maxOccurs=unbounded One or more minOccurs=1 maxOccurs=unbounded 4.6. IDMEF DATETIME Date-time strings are represented by the DATETIME data type. Each date-time string identifies a particular instant in time; ranges are not supported. It can be defined as union of built-in data types, date, time, and dateTime of XML Schema 4.7. IDMEF NTPTIMESTAMP Within IDMEF messages, NTP timestamps MUST be encoded as two 32-bit hexadecimal values, separated by a period ('.') For example, "0x12345678.0x87654321". This can be defined as built-in string type with constraint by regular expression. This DATETIME definition include an attribute ntptimestamp. Expires: August 9, 2004 [Page 5] Internet Draft February 9, 2004 4.8. IDMEF PORTLIST Port lists are represented by the PORTLIST data type, and consist of a comma-separated list of numbers (individual integers) and ranges (N-M means ports N through M, inclusive). Any combination of numbers and ranges may be used in a single list. For example, "5- 25,37,42,43,53,69-119,123-514". It can be defined by union and constraint with regular expression of XML Schema. Expires: August 9, 2004 [Page 6] Internet Draft February 9, 2004 5. Definition Expires: August 9, 2004 [Page 7] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 8] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 9] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 10] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 11] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 12] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 13] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 14] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 15] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 16] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 17] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 18] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 19] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 20] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 21] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 22] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 23] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 24] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 25] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 26] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 27] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 28] Internet Draft February 9, 2004 Expires: August 9, 2004 [Page 29] Internet Draft February 9, 2004 6. Issues Requirements of more detailed or strict definition of message described as NOTE, like below. Note that , , and must be given together, and the and must be given together. Some common data type definition. It is possible those are defined as common element in another common namespace. Potential elements are like below, IP address, Netmask, Port number, Timestamp, and so on. Expires: August 9, 2004 [Page 30] Internet Draft February 9, 2004 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires: August 9, 2004 [Page 31] Internet Draft February 9, 2004 References [Normative References] 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 D.Curry, H.Debar, B. Fleinstein, "The Intrusion Detection Message Exchange Format", Work in progress, draft-ietf-idwg-idmef-xml- 11.txt 4 M. Mealling, "The IETF XML Registry", Work in progress, draft- mealling-iana-xmlns-registry-05.txt Security Considerations This Internet-Draft describes a data representation for exchanging security-related information between intrusion detection system implementations. Although there are no security concerns directly applicable to the format of this data, the data itself may contain security-sensitive information whose confidentiality, integrity, and/ or availability may need to be protected. This suggests that the systems used to collect, transmit, process, and store this data should be protected against unauthorized use, and that the data itself should be protected against unauthorized access. The means for achieving this protection are outside the scope of this document. Authors' Addresses Kohei OHTA Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: kohei@cysols.com Full Copyright statement "Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and Expires: August 9, 2004 [Page 32] Internet Draft February 9, 2004 furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expires: August 9, 2004 [Page 33]