Extended Incident Handling Working Group Kathleen M. Moriarty draft-moriarty-post-inch-rid-soap-00.txt MIT Lincoln Laboratory Brian H. Trammell CERT Network Situational Awareness Expires: May 14, 2007 November 14, 2006 IODEF/RID over SOAP Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Abstract Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an interoperable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. The transport protocols will be provided through existing standards and SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP. Internet-Draft November 14, 2006 TABLE OF CONTENTS Status of this Memo ................................................ 1 Abstract ........................................................... 1 1. Introduction .................................................... 3 2. SOAP Wrapper .................................................... 3 3. Transport Protocol Bindings ..................................... 4 3.1 SOAP over HTTP/TLS ......................................... 4 3.2 SOAP over BEEP ............................................. 5 4. Examples ........................................................ 6 4.1. Example TraceRequest message .......................... 6 4.2 RequestAuthorization Message Example ....................... 9 4.3 Result Message Example ..................................... 10 4.4 Example InvestigationRequest Message ....................... 12 4.5 Example Report ............................................. 14 4.6 Example IncidentQuery ...................................... 16 5. Security Considerations ......................................... 16 5.1 Privacy and Confidentiality ................................ 16 5.2 Authentication and Identification .......................... 17 6. IANA Considerations ............................................. 17 7. Summary ......................................................... 17 8. References ...................................................... 17 6.1 Acknowledgments ............................................ 19 6.2 Author Information ......................................... 19 Moriarty & Trammell Expires: May 14, 2007 [Page 2] Internet-Draft November 14, 2006 1. Introduction The Incident Object Description Exchange Format (IODEF) [RFCXXX] describes an XML document format for the purpose of exchanging data between CSIRTS or those responsible for security incident handling for network providers (NPs). The defined document format provides an easy way for CSIRTS to exchange data in a way which can be easily parsed. In order for the IODEF documents to be shared between entities, a uniform method for transport is necessary. SOAP will provide a layer of abstraction and enable the use of multiple transport protocol bindings. IODEF documents and extensions will be contained in an XML Real-time Inter-network Defense (RID) [RFCXXXX] envelope inside the body of a SOAP message. For some message types, the IODEF document or RID document may stand alone in the body of a SOAP message. The RIDPolicy class of RID (e.g., policy information that may affect message routing) will appear in the SOAP message header. HTTP/TLS has been selected as the REQUIRED SOAP binding for exchanging IODEF/RID messages. The primary reason for selecting HTTP/TLS is due to the existence of multiple successful implementations of SOAP over HTTP/TLS, and to its being widely understood, despite the additional overhead associated with this combination. Excellent tool support exists to ease the development of applications using SOAP over HTTP. BEEP may actually be better suited as a transport for RID messages containing IODEF documents, but does not yet have wide adoption. Standards exist for the HTTPS or HTTP/TLS binding for SOAP. A standard is in development for SOAP over BEEP, [RFC****]. Standards MUST be followed when implementing transport bindings for RID communications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 2. SOAP Wrapper IODEF/RID documents, including all supported extensions, intended to be shared between CSIRTS or NPs MUST use a SOAP wrapper, along with a supported transport protocol binding, for transport. The transport is independent of the wrapper. SOAP will be used to provide the messaging framework and can make distinctions as to how messages should be handled by each participating system. SOAP has been selected because of the flexibility it provides for binding with transport protocols, which can be independent of the IODEF/RID messaging system. As defined by the SOAP messaging specifications [18], the appropriate message contents for the RID message type, as defined in RID, will be in the SOAP body of the message. The SOAP header contains information pertinent to all participating systems that receive the message, including the ultimate destination, any Moriarty & Trammell Expires: May 14, 2007 [Page 3] Internet-Draft November 14, 2006 intermediate hosts, and message processing policy information and is provided through RIDPolicy in the RID schema. Depending on the message or document being transported, there may be a case, such as with RID messages, in which a host may only need to view the SOAP header and not the SOAP body and is, therefore, acting as a SOAP intermediary node. An example of this would be if one RID system was sending a communication to a RID system for which there was no direct trust relationship, an intermediate RID system may be used to provide the trusted path between the communicating systems. This intermediate system may not need to see the contents of the SOAP body. Therefore, the elements or classes needed by all participating systems MUST be in the SOAP header, specifically the RIDPolicy class. Each participating system receiving an incident handling IODEF/RID document is an ultimate destination and has to parse and view the entire IODEF/RID document to make necessary decisions. The SOAP specifications for intermediate and ultimate nodes MUST be Followed; for example, a message destined for an intermediate node would contain the attribute env:role with the value http://www.w3c.org/2003/05/soap-envelope/role/next. Also in accordance with the SOAP specifications, the attribute of env:mustUnderstand has a value of "true" to ensure each node processes the header blocks consistent with the specifications for IODEF/RID. SOAP messages are typically a one-way conversation. Transmittal of incident information to another RID host in the form of a Report message is the single case within RID where a one way communication is specified. The arrival of an IODEF Report document in a RID message is simply an assertion that a described incident occurred. In the case of other RID message types, two or more SOAP messages may be exchanged to enable bi-directional communication. Request/response pairs defined by RID include: TraceRequest/TraceAuthorization/Result, Investigation/Result, and IncidentQuery/Report. 3. Transport Protocol Bindings The SOAP binding will be used for message transport. One agreed- upon protocol, HTTP/TLS, MUST be implemented by all RID systems and other protocols are optional. The use of a single transport binding supported by all systems sending and receiving RID messages and will enable interoperability between participating CSIRTS and NPs. Other protocol bindings may be defined in separate documents. 3.1 SOAP over HTTP/TLS SOAP over HTTP/TLS is widely supported, as are ancillary tools such as the Web Services Description Language (WSDL), hence the selection of SOAP over HTTP/1.1 over TLS as Mandatory for transport Moriarty & Trammell Expires: May 14, 2007 [Page 4] Internet-Draft November 14, 2006 of RID communications. Security is provided through the RID specification and all REQUIRED RID security MUST be implemented. TLS offers additional security at the transport layer to ensure the integrity of the session. BCP 56 contains a number of important considerations when using HTTP for application protocols. These include the size of the payload for the application, whether the application will use a web browser, whether the protocol should be defined on a port other than 80, and if the security provided through HTTP/TLS suits the needs of the new application. It is acknowledged within the scope of these concerns that HTTP/TLS is not ideally suited for IODEF/RID transport, as the former is a client-server protocol and the latter a message-exchange protocol; however, the ease of implementation for services based on SOAP over HTTP outweighs these concerns. Consistent with BCP 56, IODEF/RID over SOAP over HTTP/TLS will require its own TCP port assignment from IANA. Every RID system participating in a consortium MUST listen for HTTP/TLS connections on the assigned port, as the requests and responses in a RID message exchange transaction may be significantly separated in time. If a RID message is answered immediately, or within a generally accepted HTTP client timeout (about thirty seconds), the listening system SHOULD return the reply message in the HTTP response body; otherwise, it must initiate a connection to the requesting system and send its reply in an HTTP request. If the HTTP response body sent in reply to a RID message does not contain a RID message itself, the response body SHOULD be empty, and RID clients MUST ignore any response body that is not an expected RID message. This provision applies ONLY to HTTP response bodies; unsolicited HTTP requests (such as Reports not preceded by an IncidentQuery) are handled according to the message exchange pattern described in RID. RID systems SHOULD use HTTP/1.1 persistent connections as described in RFC 2616 to minimize TCP connection setup overhead. RID systems SHOULD support chunked transfer encoding on the HTTP server side to allow the implementation of clients that do not need to precalculate message sizes before constructing HTTP headers. 3.2 SOAP over BEEP SOAP over BEEP is an optional transport binding for IODEF/RID. A RID system supporting BEEP MAY attempt to use SOAP over BEEP on first connection with a peer; if the peer does not support SOAP over BEEP, the initiating peer MUST fall back to SOAP over HTTPS, and SHOULD note that the peer does not support BEEP, to avoid attempting to use BEEP in future communications. Moriarty & Trammell Expires: May 14, 2007 [Page 5] Internet-Draft November 14, 2006 BEEP has certain implementation advantages over HTTP/TLS for this application; however, the protocol has not been widely implemented. Communication between participating RID systems is on a server-to- server basis, for which BEEP is better suited than HTTP. Incident handling may at times require immediate action; thus, a protocol with low overhead and minimum bandwidth requirements is desirable. To provide equivalent transport-layer security to HTTP/TLS, the BEEP TLS profile MUST be supported if BEEP is implemented and SHOULD be used. 4. Examples The examples below, parallel to the examples in section 4.5 of RID, demonstrate how the structure of RID messages fit into SOAP containers as outlined in this document for each message type. Of particular note in each is the use of the RID policy information in the SOAP header. The RID schema was designed to enable the use of RIDPolicy to stand alone in the SOAP header and to enable the use of the RID class, RequestStatus to stand alone in the SOAP body without the need for an IODEF document. When the RID class called IncidentSource is used, it is combined with an associated IODEF document in the SOAP body to provide all of the necessary information in response to an incident handling request. The first example includes the full IODEF/RID message and associated IODEF-Document; following examples omit the IODEF-Document and Refer to it in a comment. Where indicated, the IODEF-Document must be present, following the requirements listed in the IODEF and RID specifications. 4.1. Example TraceRequest message This TraceRequest is identical to the TraceRequest example in Section 4.5.1.1 of RID and would be sent from a CSIRT reporting a denial-of-service attack in progress to its upstream NP. This request asks the upstream to continue the trace and to rate-limit traffic closer to the source. 172.20.1.2 CERT-FOR-OUR-DOMAIN#207-1 Moriarty & Trammell Expires: May 14, 2007 [Page 6] Internet-Draft November 14, 2006 CERT-FOR-OUR-DOMAIN#207-1 2004-02-02T22:49:24+00:00 2004-02-02T22:19:24+00:00 2004-02-02T23:20:24+00:00 Host involved in DOS attack Constituency-contact for 10.1.1.2 Constituency-contact@10.1.1.2 10.1.1.2 38765 192.168.1.2 80 Rate limit traffic close to source The IPv4 packet included was used in the described attack Moriarty & Trammell Expires: May 14, 2007 [Page 7] Internet-Draft November 14, 2006 450000522ad9 0000ff06c41fc0a801020a010102976d0050103e020810d9 4a1350021000ad6700005468616e6b20796f7520666f7220 6361726566756c6c792072656164696e6720746869732052 46432e0a 2001-09-14T08:19:01+00:00 CSIRT-FOR-OUR-DOMAIN#207-1 Notification sent to next upstream NP closer to 10.1.1.2 450000522ad9 0000ff06c41fc0a801020a010102976d0050103e020810d9 4a1350021000ad6700005468616e6b20796f7520666f7220 6361726566756c6c792072656164696e6720746869732052 46432e0a Moriarty & Trammell Expires: May 14, 2007 [Page 8] Internet-Draft November 14, 2006 KiI5+6SnFAs429VNwsoJjHPplmo= VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg==

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

li7dzDacuo67Jg7mtqEm2TRuOMU= Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA== VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs HifTyYdnj+roGzy4o09YntYD8zneQ7lw== 4.2 RequestAuthorization Message Example This RequestAuthorization is identical to the RequestAuthorization example in section 4.5.1.2 of the RID specification and Is sent in response to the TraceRequest to approve the request. 192.168.1.2 CERT-FOR-OUR-DOMAIN#207-1 Moriarty & Trammell Expires: May 14, 2007 [Page 9] Internet-Draft November 14, 2006 4.3 Result Message Example This Result message is identical to the Result example in section 4.5.1.3 of the RID. This message is the final response from the TraceRequest that has completed to notify the requestor of the results and actions taken from the request. 192.168.1.2 CERT-FOR-OUR-DOMAIN#207-1 true 10.1.1.15 CERT-FOR-OUR-DOMAIN#207-1 2004-02-02T22:49:24+00:00 2004-02-02T22:19:24+00:00 2004-02-02T23:20:24+00:00 Host involved in DOS attack Constituency-contact for 10.1.1.2 Constituency-contact@10.1.1.2 Moriarty & Trammell Expires: May 14, 2007 [Page 10] Internet-Draft November 14, 2006 Admin-contact for 10.1.1.2 Admin-contact@10.1.1.2 10.1.1.2 Admin-contact for 172.20.1.2 Admin-contact@172.20.1.2 172.20.1.2 10.1.1.2 38765 192.168.1.2 80 Rate limit traffic close to source Moriarty & Trammell Expires: May 14, 2007 [Page 11] Internet-Draft November 14, 2006 The IPv4 packet included was used in the described attack 450000522ad9 0000ff06c41fc0a801020a010102976d0050103e020810d9 4a1350021000ad6700005468616e6b20796f7520666f7220 6361726566756c6c792072656164696e6720746869732052 46432e0a 2004-02-02T22:53:01+00:00 CSIRT-FOR-OUR-DOMAIN#207-1 Notification sent to next upstream NP closer to 10.1.1.2 2004-02-02T23:07:21+00:00 CSIRT-FOR-NP3#3291-1 Host rate limited for 24 hours 4.4 Example InvestigationRequest Message This InvestigationRequest is identical to the InvestigationRequest example in section 4.5.2.1 of the RID specification and would be sent in a situation similar to that of example 4.1, when the source of the attack is known. 172.25.1.33 CERT-FOR-OUR-DOMAIN#208-1 CERT-FOR-OUR-DOMAIN#208-1 2004-02-05T08:13:33+00:00 2004-02-05T08:13:31+00:00 2004-02-05T08:13:33+00:00 2004-02-05T08:13:35+00:00 Host involved in DOS attack Constituency-contact for 10.1.1.2 Constituency-contact@10.1.1.2 10.1.1.2 41421 192.168.1.2 80 Moriarty & Trammell Expires: May 14, 2007 [Page 13] Internet-Draft November 14, 2006 Investigate whether source has been compromised 2004-02-05T08:19:01+00:00 CSIRT-FOR-OUR-DOMAIN#208-1 Investigation request sent to NP for 10.1.1.2 4.5 Example Report This Report is identical to the Report example in section 4.5.3.1 of the RID specification. 172.17.1.2 CERT-FOR-OUR-DOMAIN#209-1 CERT-FOR-OUR-DOMAIN#209-1 Moriarty & Trammell Expires: May 14, 2007 [Page 14] Internet-Draft November 14, 2006 2004-02-05T10:21:08+00:00 2004-02-05T10:21:05+00:00 2004-02-05T10:35:00+00:00 2004-02-05T10:27:38+00:00 Host illicitly accessed admin account Constituency-contact for 10.1.1.2 Constituency-contact@10.1.1.2 10.1.1.2 32821 192.168.1.2 22 2004-02-05T10:28:00+00:00 CSIRT-FOR-OUR-DOMAIN#209-1 Incident report sent to NP for 10.1.1.2 Moriarty & Trammell Expires: May 14, 2007 [Page 15] Internet-Draft November 14, 2006 4.6 Example IncidentQuery This IncidentQuery is identical to the IncidentQuery example in Section 4.5.4.1 of the RID specification. 172.20.1.2 CERT-FOR-OUR-DOMAIN#210-1 5. Security Considerations All security considerations of related documents MUST be considered, including those in the following documents: Requirements for the Format for INcident information Exchange (FINE) [RFCXXXX], the Incident Object Description Exchange (IODEF), [RFCXXXX], and Real-time Inter-network Defense (RID) [RFCXXXX]. The SOAP wrappers described herein are built upon the foundation of these documents; the security considerations contained therein are incorporated by reference. 5.1 Privacy and Confidentiality For transport confidentiality, TLS (whether HTTP/TLS or the BEEP TLS profile) MUST be supported and SHOULD be used. Since multiple bindings for transport may be implemented, RID implementations MUST support XML encryption [4] to encrypt the SOAP body. Since XML encryption is performed at the IODEF document level, not only is the transport encrypted when a document is sensitive or contains sensitive elements, but the stored document is also encrypted. Note that this encryption applies only to the SOAP body; policy information in the SOAP header should remain unencrypted if it is necessary for the intermediate node to dispatch the message. XML encryption protects the IODEF/RID document in the SOAP body from being viewed by any involved SOAP Moriarty & Trammell Expires: May 14, 2007 [Page 16] Internet-Draft November 14, 2006 intermediary node. 5.2 Authentication and Identification For transport authentication and identification, TLS (whether HTTP/TLS or the BEEP TLS profile) MUST be supported and SHOULD be used. Each RID consortium SHOULD use a trusted public key infrastructure (PKI) to manage identities for TLS connections. The public/private key pairs used for XML encryption and digital signatures provide authentication for the RID message. The session encryption keys are also used to identify the communicating hosts and provide integrity for the session. Since multiple bindings for transport may be implemented, RID implementations MUST support XML digital signatures [5] to sign the SOAP body; the rationale and implementation here is parallel to that for XML encryption discussed in section 5.1. 6. IANA Considerations The IANA is requested to assign TCP ports for RID over SOAP over HTTPS and for RID over SOAP over BEEP. 7. Summary SOAP provides the wrapper to facilitate the exchange of RID messages. The IETF and W3C standards provide detailed implementation details for SOAP and SOAP protocol bindings. The use of existing standards assists with development and interoperability between RID systems exchanging IODEF documents for incident handling purposes. HTTP/TLS is the mandatory transport binding for SOAP to be implemented and BEEP with a TLS profile is optional. 8. References [RFC2119] "Key Words for Use in RFCs to Indicate Requirement Levels," S. Bradner, March 1997. [RFC2246] "The TLS Protocol Version 1.0," T. Dierks, C. Allen, W. Treese, P. Karlton, A. Freier, P. Kocher, January 1999. [RFC2256] "A Summary of the X.500(96) User Schema for use with LDAPv3," M. Wahl, December 1997. [RFC2459] "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile," R. Housley, W. Ford, W. Polk, and D. Solo, January 1999. [RFC2527] "Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework," S. Chokhani, W. Ford, March 1999. Moriarty & Trammell Expires: May 14, 2007 [Page 17] Internet-Draft November 14, 2006 [RFC2616] "Hypertext Transfer Protocol - HTTP/1.1," R. Fielding, J. Gettys, J. Mogul, H. Masinter, P. Leach, and T. Berners-Lee, June 1999. [RFC3080] "The Blocks Extensible Exchange Protocol Core," M. Rose. March 2001. [RFC3205] "On the Use of HTTP as a Substrate," K. Moore, February 2002. (BCP56) [RFC3688] "The IETF XML Registry," M. Mealling, January 2004. [RFCXXXX] "The Incident Object Data Exchange Format Data Model and XML Implementation," J. Meijer, R. Danyliw, and Y. Demchenko, August 2006. http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-08.txt [RFCXXXX] "Requirements for the Format for INcident information Exchange," Y. Demchenko, R. Danyliw, and G. Keeni, June 2006. http://www.ietf.org/internet-drafts/draft-ietf-inch-requirements- 08.txt [RFCXXXX] "Incident Handling: Real-time Inter-network Defense," K. Moriarty, August 2006. http://www.ietf.org/internet-drafts/draft-ietf-inch-rid-08.txt [RFCXXXX] "Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)," T. Goddard, March 2006. http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-08.txt [RFCXXXX] "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)," E. O'Tuathail, and M. Rose, May 13, 2005. http://www.ietf.org/internet-drafts/draft-mrose-rfc3288bis-02.txt [1] "Security in a Web Services World: A Proposed Architecture and Roadmap". IBM and Microsoft, April 2002. http://www-106.ibm.com/developerworks/webservices/library/ws-secmap [2] SOAP Version 1.2 Part 0: Primer, W3C Recommendation, http://www.w3c.org/TR/REC-soap12-part0-20030624/, 24 June 2004. [3] SOAP Version 1.2 Part 1:Messaging Framework. W3C Recommendation, 24 June 2004. http://www.w3c.org/TR/REC-soap12-part1-20030624/ [4] XML Encryption Syntax and Processing, W3C Recommendation. T. Imamura, B. Dillaway, and E. Simon, December 2002. [5] XML-Signature Syntax and Processing, W3C Recommendation, M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, February 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design Moriarty & Trammell Expires: May 14, 2007 [Page 18] Internet-Draft November 14, 2006 6.1 Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. 6.2 Author Information Kathleen M. Moriarty MIT Lincoln Laboratory 244 Wood Street Lexington, MA 02420 Email: Moriarty@ll.mit.edu Brian H. Trammell CERT Network Situational Awareness 4500 Fifth Avenue Pittsburgh, PA 15213 Email: bht@cert.org Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. This work was sponsored by the Air Force under Air Force Contract FA8721-05-C-0002. "Opinions, interpretations, conclusions, and recommendations are those of the author and are not necessarily endorsed by the United States Government." Moriarty & Trammell Expires: May 14, 2007 [Page 19]