idnits 2.17.1 draft-ietf-inch-rid-soap-01.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 12. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (April 20, 2006) is 6552 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXX' is mentioned on line 76, but not defined == Missing Reference: '18' is mentioned on line 118, but not defined == Unused Reference: 'RFC2119' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC2256' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC2527' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'RFC3080' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC3205' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 665, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 690, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 694, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 697, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2527 (Obsoleted by RFC 3647) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3205 (Obsoleted by RFC 9205) ** Obsolete normative reference: RFC 3288 (ref. 'RFCXXXX') (Obsoleted by RFC 4227) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 15 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Extended Incident Handling Working Group Kathleen M. Moriarty 2 draft-ietf-inch-rid-soap-01.txt MIT Lincoln Laboratory 3 Expires: October 20, 2006 April 20, 2006 5 IODEF/RID over SOAP 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Documents intended to be shared among multiple constituencies must 32 share a common format and transport mechanism. The Incident Object 33 Description Exchange Format (IODEF) defines a common XML format for 34 document exchange. This draft outlines the SOAP wrapper for all 35 IODEF documents and extensions to facilitate an interoperable and 36 secure communication of documents. The SOAP wrapper allows for 37 flexibility in the selection of a transport protocol. The 38 transport protocols will be provided through existing standards and 39 SOAP binding, such as SOAP over HTTP(S) and SOAP over BEEP. 41 TABLE OF CONTENTS 43 Status of this Memo ................................................ 1 45 Abstract ........................................................... 1 47 1. Introduction .................................................... 3 49 2. SOAP Wrapper .................................................... 3 51 3. Transport Protocol Bindings ..................................... 4 52 3.1 SOAP over HTTP/TLS ......................................... 4 53 3.2 SOAP over BEEP ............................................. 5 55 4. Examples ........................................................ 6 56 4.1. Example TraceRequest message .......................... 6 57 4.2 Example InvestigationRequest Message ....................... 9 58 4.3 Example Report ............................................. 10 59 4.4 Example IncidentQuery ...................................... 11 61 5. Security Considerations ......................................... 12 62 5.1 Privacy and Confidentiality ................................ 12 63 5.2 Authentication and Identification .......................... 13 65 6. IANA Considerations ............................................. 13 67 7. Summary ......................................................... 13 69 8. References ...................................................... 13 71 6.1 Acknowledgments ............................................ 15 72 6.2 Author Information ......................................... 15 74 1. Introduction 76 The Incident Object Description Exchange Format (IODEF) [RFCXXX] 77 describes an XML document format for the purpose of exchanging data 78 between CSIRTS or those responsible for security incident handling 79 for network providers. The defined document format provides an 80 easy way for CSIRTS to exchange data in a way which can be easily 81 parsed. In order for the IODEF documents to be shared between 82 entities, a uniform method for transport is necessary. SOAP will 83 provide a layer of abstraction and enable the use of multiple 84 transport protocol bindings. IODEF documents and extensions will 85 be contained in an XML Real-time Inter-network Defense (RID) 86 [RFCXXXX] envelope inside the body of a SOAP message.� The 87 RIDPolicy class of RID (e.g., policy information that may affect 88 message routing) will appear in the SOAP message header. 90 HTTPS or HTTP/TLS has been selected as the REQUIRED SOAP binding 91 for exchanging IODEF/RID messages. The primary reason for 92 selecting HTTPS is due to the existence of multiple successful 93 implementations of SOAP over HTTP, and to its being widely 94 understood. Excellent tool support exists to ease the development 95 of applications using SOAP over HTTP. BEEP may actually be better 96 suited as a transport for RID messages containing IODEF documents, 97 but does not yet have wide adoption. Standards exist for the HTTPS 98 or HTTP/TLS binding for SOAP. A standard is in development for 99 SOAP over BEEP, [RFC****]. Standards MUST be followed when 100 implementing transport bindings for RID communications. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in RFC2119. 106 2. SOAP Wrapper 108 IODEF/RID documents, including all supported extensions, intended 109 to be shared between CSIRTS or NPs MUST use a SOAP wrapper, along 110 with a supported transport protocol binding, for transport. The 111 transport is independent of the wrapper. SOAP will be used to 112 provide the messaging framework and can make distinctions as to how 113 messages should be handled by each participating system. SOAP has 114 been selected because of the flexibility it provides for binding 115 with transport protocols, which can be independent of the IODEF/RID 116 messaging system. 118 As defined by the SOAP messaging specifications [18], the IODEF 119 document plus any extensions will be in the SOAP body of the 120 message. The SOAP header contains information pertinent to all 121 participating systems that receive the message, including the 122 ultimate destination, any intermediate hosts, and message 123 processing policy information. Depending on the message or 124 document being transported, there may be a case, such as with RID 125 messages, in which a host may only need to view the SOAP header and 126 not the SOAP body and is, therefore, acting as a SOAP intermediary 127 node. An example of this would be if one RID system was sending a 128 communication to a RID system for which there was no direct trust 129 relationship, an intermediate RID system may be used to provide the 130 trusted patch between the communicating systems. This intermediate 131 system may not need to see the contents of the SOAP body. 132 Therefore, the elements or classes needed by all participating 133 systems MUST be in the SOAP header, specifically the RIDPolicy 134 class. Each participating system receiving an incident handling 135 IODEF document is an ultimate destination and has to parse and view 136 the entire IODEF document to make necessary decisions. 138 The SOAP specifications for intermediate and ultimate nodes MUST be 139 Followed; for example, a message destined for an intermediate node 140 would contain the attribute env:role with the value 141 http://www.w3c.org/2003/05/soap-envelope/role/next. Also in 142 accordance with the SOAP specifications, the attribute of 143 env:mustUnderstand has a value of "true" to ensure each node 144 processes the header blocks consistent with the specifications for 145 IODEF. 147 SOAP messages are typically a one-way conversation. Transmittal of 148 Incident information to another RID host in the form of a Report 149 message is the single case within RID where a one way communication 150 is specified. The arrival of an IODEF/RID Report document in a 151 SOAP message is simply an assertion that a described incident 152 occurred. In the case of other RID message types to support 153 incident handling, two SOAP messages may be exchanged to enable 154 bi-directional communication. Request/response pairs defined by RID 155 include TraceRequest/TraceAuthorization/Result, 156 Investigation/Result, and IncidentQuery/Report. 158 3. Transport Protocol Bindings 160 The SOAP binding will be used for message transport. One agreed- 161 upon protocol, HTTPS, MUST be implemented by all RID systems and 162 other protocols may be used. The use of a single transport binding 163 supported by all systems sending and receiving RID messages and 164 extensions of IODEF will enable interoperability between 165 participating CSIRTS and NPs. Other protocol bindings may be 166 defined in separate documents. 168 3.1 SOAP over HTTP/TLS 170 SOAP over HTTP/TLS is widely supported, as are ancillary tools such 171 as the Web Services Description Language (WSDL), hence the 172 selection of SOAP over HTTP/1.1 over TLS as Mandatory for transport 173 of RID communications. Security is provided through the RID 174 specification and all REQUIRED RID security MUST be implemented. 175 TLS offers additional security at the transport layer; this 176 security SHOULD be used. 178 BCP 56 contains a number of important considerations when using 179 HTTP for application protocols. These include the size of the 180 payload for the application, whether the application will use a web 181 browser, whether the protocol should be defined on a port other 182 than 80, and if the security provided through HTTPS suits the needs 183 of the new application. 185 It is acknowledged within the scope of these concerns that HTTPS is 186 not ideally suited for IODEF/RID transport, as the former is a 187 client-server protocol and the latter a message-exchange protocol; 188 however, the ease of implementation for services based on SOAP over 189 HTTP outweighs these concerns. Consistent with BCP 56, IODEF over 190 SOAP over HTTP/TLS will require its own TCP port assignment from 191 IANA. 193 Every RID system participating in a consortium MUST listen for 194 HTTPS connections on the assigned port, as the requests and 195 responses in a RID message exchange transaction may be 196 significantly separated in time. If a RID message is answered 197 immediately, or within a generally accepted HTTP client timeout 198 (about thirty seconds), the listening system SHOULD return the 199 reply message in the HTTP response body; otherwise, it must 200 initiate a connection to the requesting system and send its reply 201 in an HTTP request. 203 If the HTTP response body sent in reply to a RID message does not 204 contain a RID message itself, the response body SHOULD be empty, 205 and RID clients MUST ignore any response body that is not an 206 expected RID message. This provision applies ONLY to HTTP response 207 bodies; unsolicited HTTP requests (such as Reports not preceded by 208 an IncidentQuery) are handled according to the message exchange 209 pattern described in RID. 211 RID systems SHOULD use HTTP/1.1 persistent connections as described 212 in RFC 2616 to minimize TCP connection setup overhead. RID systems 213 SHOULD support chunked transfer encoding on the HTTP server side to 214 allow the implementation of clients that do not need to 215 precalculate message sizes before constructing HTTP headers. 217 3.2 SOAP over BEEP 219 SOAP over BEEP is an optional transport binding for IODEF/RID. A 220 RID system supporting BEEP MAY attempt to use SOAP over BEEP on 221 first connection with a peer; if the peer does not support SOAP 222 over BEEP, the initiating peer MUST fall back to SOAP over HTTPS, 223 and SHOULD note that the peer does not support BEEP, to avoid 224 attempting to use BEEP in future communications. 226 BEEP has certain implementation advantages over HTTP/TLS for this 227 application; however, the protocol has not been widely implemented. 229 Communication between participating RID systems is on a server-to- 230 server basis, for which BEEP is better suited than HTTP. Incident 231 handling may at times require immediate action; thus, a protocol 232 with low overhead and minimum bandwidth requirements is desirable. 234 To provide equivalent transport-layer security to HTTP/TLS, the 235 BEEP TLS profile MUST be supported and SHOULD be used. 237 4. Examples 239 The examples below, parallel to the examples in section 4.5 of the 240 RID document, demonstrate how the structure of RID messages 241 fits into SOAP containers as outlined in this document for each 242 message type. Of particular note in each is the duplication of the 243 RID policy information in both the SOAP header and SOAP body. The 244 first example includes the full RID message and associated 245 IODEF-Document; following examples omit the IODEF-Document and refer 246 to it in a comment. The IODEF-Document must be present, and the 247 elements required are outlined in the RID specification. 249 4.1. Example TraceRequest message 251 This TraceRequest is identical to the TraceRequest example in 252 Section 4.5.1.1 of RID and would be sent from a CSIRT 253 reporting a denial-of-service attack in progress to its upstream 254 NP. This request asks the upstream to continue the trace and to 255 rate-limit traffic closer to the source. 257 259 260 263 264 TraceRequest 265 Inter-Consortium 266 267 RIDSystem 268 269 172.20.1.2 270 271 272 RIDSystem 273 274 CERT-FOR-OUR-DOMAIN#207-1 275 276 277 278 279 280 283 284 TraceRequest 285 Inter-Consortium 286 287 RIDSystem 288 289 172.20.1.2 290 291 292 RIDSystem 293 294 CERT-FOR-OUR-DOMAIN#207-1 295 296 297 298 CSIRT-FOR-OUR-DOMAIN 299 CSIRT123 300 csirt-for-our-domain@ourdomain 301 302 172.17.1.2 303 304 305 306 307 CSIRT-FOR-UPSTREAM-NP 308 CSIRT345 309 csirt-for-upstream-np@ourdomain 310 311 172.20.1.2 312 313 314 315 316 317 318 319 CERT-FOR-OUR-DOMAIN#207-1 320 321 322 Host involved in DOS attack 323 324 2004-02-02T22:19:24+00:00 325 2004-02-02T22:49:24+00:00 326 327 2004-02-02T23:20:24+00:00 328 329 330 332 333 334 CSIRT-FOR-OUR-DOMAIN 335 csirt-for-our-domain@ourdomain 336 337 338 Constituency-contact for 10.1.1.2 339 Constituency-contact@10.1.1.2 340 341 342 343 344 CSIRT-FOR-OUR-DOMAIN#207-1 345 346 347 Notification sent to next upstream NP closer to 348 10.1.1.2 349 2001-09-14T08:19:01+00:00 350 351 352 353 354 355 356 38765 357 358 359 10.1.1.2 360 361 362 363 364 365 80 366 367 368 192.168.1.2 369 370 371 372 374 Rate limit traffic close to source 375 376 377 378 379 380 450000522ad90000ff06c41fc0a801020a010102976d0050103e020810 381 d94a1350021000ad6700005468616e6b20796f7520666f722063617265 382 66756c6c792072656164696e672074686973205246432e0a 383 384 "The IPv4 packet included 385 was used in the described attack" 386 387 388 389 390 391 392 393 394 396 4.2 Example InvestigationRequest Message 398 This InvestigationRequest is identical to the InvestigationRequest 399 example in section 4.5.2.1 of the RID specification and would be 400 sent in a situation similar to that of example 4.1, when the source 401 of the attack is known. 403 405 406 409 410 Investigation 411 PeertoPeer 412 SourceOfIncident 413 414 415 172.25.1.33 416 417 418 RIDSystem 419 420 CERT-FOR-OUR-DOMAIN#208-1 421 422 423 424 425 426 429 430 Investigation 431 PeertoPeer 432 SourceOfIncident 433 434 435 172.25.1.33 436 438 439 RIDSystem 440 441 CERT-FOR-OUR-DOMAIN#208-1 442 443 444 445 CSIRT-FOR-OUR-DOMAIN 446 CSIRT123 447 csirt-for-our-domain@ourdomain 448 449 172.17.1.2 450 451 452 453 454 CSIRT-FOR-UPSTREAM-NP 455 CSIRT345 456 csirt-for-upstream-np@ourdomain 457 458 172.20.1.2 459 460 461 462 463 464 465 467 4.3 Example Report 469 This Report is identical to the Report example in section 4.5.3.1 470 of the RID specification. 472 474 475 478 479 Report 480 PeertoPeer 481 RIDSystem 482 483 172.17.1.2 484 485 486 RIDSystem 487 488 CERT-FOR-OUR-DOMAIN#209-1 489 491 492 493 494 495 498 499 Report 500 PeertoPeer 501 RIDSystem 502 503 172.17.1.2 504 505 506 RIDSystem 507 508 CERT-FOR-OUR-DOMAIN#209-1 509 510 511 512 CSIRT-FOR-OUR-DOMAIN 513 CSIRT123 514 csirt-for-our-domain@ourdomain 515 516 172.20.1.2 517 518 519 520 521 CSIRT-FOR-REQUESTING-NP 522 CSIRT345 523 csirt-for-requesting-np@ourdomain 524 525 172.17.1.2 526 527 528 529 530 531 532 534 4.4 Example IncidentQuery 536 This IncidentQuery is identical to the IncidentQuery example in 537 Section 4.5.4.1 of the RID specification. 539 541 542 545 546 Report 547 PeertoPeer 548 RIDSystem 549 550 172.17.1.2 551 552 553 RIDSystem 554 555 CERT-FOR-OUR-DOMAIN#209-1 556 557 558 559 CSIRT-FOR-OUR-DOMAIN 560 CSIRT123 561 csirt-for-our-domain@ourdomain 562 563 172.20.1.2 564 565 566 567 568 CSIRT-FOR-REQUESTING-NP 569 CSIRT345 570 csirt-for-requesting-np@ourdomain 571 572 172.17.1.2 573 574 575 576 577 578 579 581 5. Security Considerations 583 All security considerations of related documents MUST be 584 considered, including those in the following documents: 585 Requirements for the Format for INcident information Exchange 586 (FINE) [RFCXXXX], the Incident Data Exchange Format Data Model and 587 XML Implementation (IODEF), [RFCXXXX], and Incident Handling: 588 Real-time Inter-network Defense (RID) [RFCXXXX]. The SOAP wrappers 589 described herein are built upon the foundation of these documents; 590 the security considerations contained therein are incorporated by 591 reference. 593 5.1 Privacy and Confidentiality 594 For transport confidentiality, TLS (whether HTTP/TLS or the BEEP 595 TLS profile) MUST be supported and SHOULD be used. 597 Since multiple bindings for transport may be implemented, RID 598 implementations MUST support XML encryption [4] to encrypt the SOAP 599 body. Since XML encryption is performed at the IODEF document 600 level, not only is the transport encrypted when a document is 601 sensitive or contains sensitive elements, but the stored document 602 is also encrypted. Note that this encryption applies only to the 603 SOAP body; policy information in the SOAP header should remain 604 unencrypted if it is necessary for the intermediate node to 605 dispatch the message. XML encryption protects the IODEF document 606 in the SOAP body from being viewed by any involved SOAP 607 intermediary node. 609 5.2 Authentication and Identification 611 For transport authentication and identification, TLS (whether 612 HTTP/TLS or the BEEP TLS profile) MUST be supported and SHOULD be 613 used. Each RID consortium SHOULD use a trusted public key 614 infrastructure (PKI) to manage identities for TLS connections. 616 Since multiple bindings for transport may be implemented, RID 617 implementations MUST support XML digital signatures [5] to 618 sign the SOAP body; the rationale and implementation here is 619 parallel to that for XML Encryption discussed in section 5.1. 621 6. IANA Considerations 623 The IANA is requested to assign TCP ports for RID over SOAP over 624 HTTPS and for RID over SOAP over BEEP. 626 7. Summary 628 SOAP provides the wrapper to facilitate the exchange of RID 629 messages. The IETF and W3C standards provide detailed 630 implementation details for SOAP and SOAP protocol bindings. The 631 use of existing standards assists with development and 632 interoperability between RID systems exchanging IODEF documents for 633 incident-handling purposes. HTTPS is the mandatory transport 634 binding for SOAP to be implemented and BEEP is optional. 636 8. References 638 [RFC2119] "Key Words for Use in RFCs to Indicate Requirement 639 Levels," S. Bradner, March 1997. 641 [RFC2246] "The TLS Protocol Version 1.0," T. Dierks, C. Allen, W. 642 Treese, P. Karlton, A. Freier, P. Kocher, January 1999. 644 [RFC2256] "A Summary of the X.500(96) User Schema for use with 645 LDAPv3," M. Wahl, December 1997. 647 [RFC2459] "Internet Public Key Infrastructure: Part I: X.509 648 Certificate and CRL Profile," R. Housley, W. Ford, W. Polk, and 649 D. Solo, January 1999. 651 [RFC2527] "Internet X.509 Public Key Infrastructure: Certificate 652 Policy and Certification Practices Framework," S. Chokhani, W. 653 Ford, March 1999. 655 [RFC2616] "Hypertext Transfer Protocol - HTTP/1.1," R. Fielding, J. 656 Gettys, J. Mogul, H. Masinter, P. Leach, and T. Berners-Lee, June 657 1999. 659 [RFC3080] "The Blocks Extensible Exchange Protocol Core," M. Rose. 660 March 2001. 662 [RFC3205] "On the Use of HTTP as a Substrate," K. Moore, February 663 2002. (BCP56) 665 [RFC3688] "The IETF XML Registry," M. Mealling, January 2004. 667 [RFCXXXX] "The Incident Object Data Exchange Format Data Model and 668 XML Implementation," J. Meijer, R. Danyliw, and Y. Demchenko, 669 November 2005. 670 http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-05.txt 672 [RFCXXXX] "Requirements for the Format for INcident information 673 Exchange," Y. Demchenko, R. Danyliw, and G. Keeni, February 2006. 674 http://www.ietf.org/internet-drafts/draft-ietf-inch-requirements- 675 07.txt 677 [RFCXXXX] "Incident Handling: Real-time Inter-network Defense," 678 K. Moriarty, April 2006. 679 http://www.ietf.org/internet-drafts/draft-ietf-inch-rid-06.txt 681 [RFCXXXX] "Using the Network Configuration Protocol (NETCONF) Over 682 the Simple Object Access Protocol (SOAP)," T. Goddard, March 2006. 683 http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-08.txt 685 [RFCXXXX] "Using the Simple Object Access Protocol (SOAP) in Blocks 686 Extensible Exchange Protocol (BEEP)," E. O'Tuathail, and M. Rose, 687 May 13, 2005. 688 http://www.ietf.org/internet-drafts/draft-mrose-rfc3288bis-02.txt 690 [1] "Security in a Web Services World: A Proposed Architecture 691 and Roadmap". IBM and Microsoft, April 2002. 692 http://www-106.ibm.com/developerworks/webservices/library/ws-secmap 694 [2] SOAP Version 1.2 Part 0: Primer, W3C Recommendation, 695 http://www.w3c.org/TR/REC-soap12-part0-20030624/, 24 June 2004. 697 [3] SOAP Version 1.2 Part 1:Messaging Framework. W3C 698 Recommendation, 24 June 2004. 700 http://www.w3c.org/TR/REC-soap12-part1-20030624/ 702 [4] XML Encryption Syntax and Processing, W3C Recommendation. 703 T. Imamura, B. Dillaway, and E. Simon, December 2002. 705 [5] XML-Signature Syntax and Processing, W3C Recommendation, 706 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, February 707 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design 709 6.1 Acknowledgments 711 Funding for the RFC Editor function is currently provided by the 712 Internet Society. 714 6.2 Author Information 716 Kathleen M. Moriarty 717 MIT Lincoln Laboratory 718 244 Wood Street 719 Lexington, MA 02420 720 Phone: 781-981-5500 721 Email: Moriarty@ll.mit.edu 723 Brian H. Trammell 724 CERT Network Situational Awareness 725 4500 Fifth Avenue 726 Pittsburgh, PA 15213 727 Email: bht@cert.org 729 Copyright (C) The Internet Society (2006). This document is 730 subject to the rights, licenses and restrictions contained in BCP 731 78, and except as set forth therein, the authors retain all their 732 rights. 734 This document and the information contained herein are provided 735 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 736 REPRESENTS IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 737 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 738 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 739 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 740 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 741 PARTICULAR PURPOSE. 743 This work was sponsored by the Air Force under Air Force 744 Contract FA8721-05-C-0002. 746 "Opinions, interpretations, conclusions, and recommendations 747 are those of the author and are not necessarily endorsed 748 by the United States Government."