idnits 2.17.1 draft-moriarty-post-inch-rid-soap-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 973. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (February 25, 2008) is 5905 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) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) ** 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 4346 (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX' == Outdated reference: A later version (-12) exists of draft-moriarty-post-inch-rid-02 ** Downref: Normative reference to an Informational draft: draft-moriarty-post-inch-rid (ref. 'RFCYYYY') -- 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: 5 errors (**), 0 flaws (~~), 3 warnings (==), 13 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 Internet-draft RSA, The Security Division of EMC 3 Intended status: Standards Track Brian H. Trammell 4 draft-moriarty-post-inch-rid-soap-04.txt CERT Network Situational 5 Expires: August 25, 2008 Awareness 6 February 25, 2008 8 IODEF/RID over SOAP 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Documents intended to be shared among multiple constituencies must 35 share a common format and transport mechanism. The Incident Object 36 Description Exchange Format (IODEF) defines a common XML format for 37 document exchange. This draft outlines the SOAP wrapper for all 38 IODEF documents and extensions to facilitate an interoperable and 39 secure communication of documents. The SOAP wrapper allows for 40 flexibility in the selection of a transport protocol. The 41 transport protocols will be provided through existing standards and 42 SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP. 44 TABLE OF CONTENTS 46 Status of this Memo ................................................ 1 48 Abstract ........................................................... 1 50 1. Terminology ..................................................... 3 51 1.1 Introduction ............................................... 3 53 2. SOAP Wrapper .................................................... 3 55 3. Transport Protocol Bindings ..................................... 4 56 3.1 SOAP over HTTP/TLS ......................................... 4 57 3.2 SOAP over BEEP ............................................. 5 59 4. Examples ........................................................ 6 60 4.1. Example TraceRequest message .......................... 6 61 4.2 RequestAuthorization Message Example ....................... 9 62 4.3 Result Message Example ..................................... 10 63 4.4 Example InvestigationRequest Message ....................... 13 64 4.5 Example Report ............................................. 14 65 4.6 Example IncidentQuery ...................................... 17 67 5. Security Considerations ......................................... 17 68 5.1 Privacy and Confidentiality ................................ 17 69 5.2 Authentication and Identification .......................... 18 71 6. IANA Considerations ............................................. 18 73 7. Summary ......................................................... 18 75 8. Informative References .......................................... 18 76 8.1 Normative References ....................................... 18 77 8.2 Acknowledgments ............................................ 19 78 8.3 Author Information ......................................... 19 80 Intellectual Property Statement .................................... 20 82 Full Copyright Statement ........................................... 20 84 Sponsor Information ................................................ 21 85 1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 1.1 Introduction 93 The Incident Object Description Exchange Format (IODEF) [RFCXXXX] 94 describes an XML document format for the purpose of exchanging data 95 between Computer Security Incident Response Teams (CSIRTs) or those 96 responsible for security incident handling for network providers 97 (NPs). The defined document format provides an easy way for CSIRTs 98 to exchange data in a way which can be easily parsed. In order for 99 the IODEF documents to be shared between entities, a uniform method 100 for transport is necessary. SOAP [3] will provide a layer of 101 abstraction and enable the use of multiple transport protocol 102 bindings. IODEF documents and extensions will be contained in an 103 XML Real-time Inter-network Defense (RID) [RFCYYYY] envelope 104 inside the body of a SOAP message. 106 HTTP/TLS [RFC4346] has been selected as the REQUIRED SOAP binding 107 for exchanging IODEF/RID messages. The primary reason for 108 selecting HTTP/TLS is due to the existence of multiple successful 109 implementations of SOAP over HTTP/TLS, and to its being widely 110 understood, despite the additional overhead associated with this 111 combination. The Transport Layer Security (TLS) Protocol 112 [RFC4346] MUST be followed for the implementation and deployment 113 of this protocol. Excellent tool support exists to ease the 114 development of applications using SOAP over HTTP. BEEP may 115 optionally be supported following the SOAP over BEEP standard 116 [RFC4227]. 118 2. SOAP Wrapper 120 IODEF/RID documents, including all supported extensions, intended 121 to be shared between CSIRTS or NPs MUST use a SOAP wrapper, along 122 with a supported transport protocol binding, for transport. The 123 transport is independent of the wrapper. SOAP will be used to 124 provide the messaging framework and can make distinctions as to how 125 messages should be handled by each participating system. SOAP has 126 been selected because of the flexibility it provides for binding 127 with transport protocols, which can be independent of the IODEF/RID 128 messaging system. 130 The SOAP body of the message will contain the appropriate contents 131 for the respective RID message type and will be structured 132 according to the SOAP messaging specifications [4]. The SOAP 133 header contains information pertinent to all participating systems 134 that receive the message, including the ultimate destination, any 135 intermediate hosts, and message processing policy information and 136 is provided through RIDPolicy in the RID schema [RFCYYYY]. 138 Depending on the message or document being transported, there may 139 be a case, such as with RID messages, in which a host may only 140 need to view the SOAP header and not the SOAP body and is, 141 therefore, acting as a SOAP intermediary node. An example of this 142 would be if one RID system was sending a communication to a RID 143 system for which there was no direct trust relationship, an 144 intermediate RID system may be used to provide the trusted path 145 between the communicating systems. This intermediate system may 146 not need to see the contents of the SOAP body. Therefore, the 147 elements or classes needed by all participating systems MUST be in 148 the SOAP header, specifically the RIDPolicy class. Each 149 participating system receiving an incident handling IODEF/RID 150 document is an ultimate destination and has to parse and view the 151 entire IODEF/RID document to make necessary decisions. 153 The SOAP specifications for intermediate and ultimate nodes MUST be 154 Followed; for example, a message destined for an intermediate node 155 would contain the attribute env:role with the value 156 http://www.w3c.org/2003/05/soap-envelope/role/next. Also in 157 accordance with the SOAP specifications, the attribute of 158 env:mustUnderstand has a value of "true" to ensure each node 159 processes the header blocks consistent with the specifications for 160 IODEF/RID. 162 SOAP messages are typically a one-way conversation. Transmittal of 163 incident information to another RID host in the form of a Report 164 message is the single case within RID where a one way communication 165 is specified. The arrival of an IODEF Report document in a RID 166 message is simply an assertion that a described incident occurred. 167 In the case of other RID message types, two or more SOAP messages 168 may be exchanged to enable bi-directional communication. 169 Request/response pairs defined by RID include: 170 TraceRequest/TraceAuthorization/Result, 171 Investigation/Result, and 172 IncidentQuery/Report. 174 3. Transport Protocol Bindings 176 The SOAP binding will be used for message transport. One agreed- 177 upon protocol, HTTP/TLS, MUST be implemented by all RID systems and 178 other protocols are optional. The use of a single transport 179 binding supported by all systems sending and receiving RID messages 180 and will enable interoperability between participating CSIRTS and 181 NPs. Other protocol bindings may be defined in separate documents. 183 3.1 SOAP over HTTP/TLS 185 SOAP over HTTP/TLS is widely supported, as are ancillary tools such 186 as the Web Services Description Language (WSDL), hence the 187 selection of SOAP over HTTP/1.1 over TLS as Mandatory for transport 188 of RID communications. Security is provided through the RID 189 specification. TLS offers additional security at the transport 190 layer to ensure the integrity of the session. 192 BCP 56 [RFC3205] contains a number of important considerations when 193 using HTTP for application protocols. These include the size of 194 the payload for the application, whether the application will use a 195 web browser, whether the protocol should be defined on a port other 196 than 80, and if the security provided through HTTP/TLS suits the 197 needs of the new application. 199 It is acknowledged within the scope of these concerns that HTTP/TLS 200 is not ideally suited for IODEF/RID transport, as the former is a 201 client-server protocol and the latter a message-exchange protocol; 202 however, the ease of implementation for services based on SOAP over 203 HTTP outweighs these concerns. Consistent with BCP 56, IODEF/RID 204 over SOAP over HTTP/TLS will require its own TCP port assignment 205 from IANA. 207 Every RID system participating in a consortium MUST listen for 208 HTTP/TLS connections on the assigned port, as the requests and 209 responses in a RID message exchange transaction may be 210 significantly separated in time. If a RID message is answered 211 immediately, or within a generally accepted HTTP client timeout 212 (about thirty seconds), the listening system SHOULD return the 213 reply message in the HTTP response body; otherwise, it must 214 initiate a connection to the requesting system and send its reply 215 in an HTTP request. 217 If the HTTP response body sent in reply to a RID message does not 218 contain a RID message itself, the response body SHOULD be empty, 219 and RID clients MUST ignore any response body that is not an 220 expected RID message. This provision applies ONLY to HTTP response 221 bodies; unsolicited HTTP requests (such as Reports not preceded by 222 an IncidentQuery) are handled according to the message exchange 223 pattern described in RID. 225 RID systems SHOULD use HTTP/1.1 persistent connections as described 226 in [RFC2616] to minimize TCP connection setup overhead. RID systems 227 SHOULD support chunked transfer encoding on the HTTP server side to 228 allow the implementation of clients that do not need to 229 precalculate message sizes before constructing HTTP headers. 231 3.2 SOAP over BEEP 233 SOAP over BEEP is an optional transport binding for IODEF/RID. A 234 RID system supporting BEEP [RFC3080] MAY attempt to use SOAP over 235 BEEP on first connection with a peer; if the peer does not support 236 SOAP over BEEP, the initiating peer MUST fall back to SOAP over 237 HTTPS, and SHOULD note that the peer does not support BEEP, to 238 avoid attempting to use BEEP in future communications. The state 239 table for the support of alternate protocols may be maintained for 240 a period of one week or less depending on system resources. The 241 duration and size of the state table should be a configurable 242 option. 244 BEEP has certain implementation advantages over HTTP/TLS for this 245 application; however, the protocol has not been widely implemented. 246 Communication between participating RID systems is on a server-to- 247 server basis, for which BEEP is better suited than HTTP. Incident 248 handling may at times require immediate action; thus, a protocol 249 with low overhead and minimum bandwidth requirements is desirable. 251 To provide equivalent transport-layer security to HTTP/TLS, the 252 BEEP TLS profile MUST be supported if BEEP is implemented and 253 SHOULD be used. 255 4. Examples 257 The examples below, parallel to the examples in section 4.5 of RID, 258 demonstrate how the structure of RID messages fit into SOAP 259 containers as outlined in this document for each message type. Of 260 particular note in each is the use of the RID policy information in 261 the SOAP header. The RID schema was designed to enable the use of 262 RIDPolicy to stand alone in the SOAP header and to enable the use of 263 the RID class, RequestStatus to stand alone in the SOAP body 264 without the need for an IODEF document. When the RID class called 265 IncidentSource is used, it is combined with an associated IODEF 266 document in the SOAP body to provide all of the necessary 267 information in response to an incident handling request. The first 268 example includes the full IODEF/RID message and associated 269 IODEF-Document; following examples omit the IODEF-Document and 270 Refer to it in a comment. Where indicated, the IODEF-Document must 271 be present, following the requirements listed in the IODEF and RID 272 specifications. 274 Note: for each example listed below, [RFC3330] addresses were used. 275 Assume each IP address listed is actually a separate network range 276 held by different NPs. Addresses were used from /27 network 277 ranges. 279 4.1. Example TraceRequest message 281 This TraceRequest is identical to the TraceRequest example in 282 Section 4.5.1.1 of RID and would be sent from a CSIRT 283 reporting a denial-of-service attack in progress to its upstream 284 NP. This request asks the upstream to continue the trace and to 285 rate-limit traffic closer to the source. 287 289 290 292 295 296 297 192.0.2.3 298 299 300 301 CERT-FOR-OUR-DOMAIN#207-1 302 303 304 305 306 307 309 310 311 CERT-FOR-OUR-DOMAIN#207-1 312 313 2004-02-02T22:49:24+00:00 314 2004-02-02T22:19:24+00:00 315 2004-02-02T23:20:24+00:00 316 Host involved in DOS attack 317 318 319 320 321 Constituency-contact for 192.0.2.35 322 323 Constituency-contact@192.0.2.35 324 325 326 327 328 329 192.0.2.35 330 331 332 333 38765 334 335 336 337 338 192.0.2.67 339 340 341 342 80 343 344 345 346 347 348 Rate limit traffic close to source 349 350 351 352 353 354 The IPv4 packet included was used in the described attack 355 356 450000522ad9 357 0000ff06c41fc0a801020a010102976d0050103e020810d9 358 4a1350021000ad6700005468616e6b20796f7520666f7220 359 6361726566756c6c792072656164696e6720746869732052 360 46432e0a 361 362 363 364 365 366 367 2001-09-14T08:19:01+00:00 368 369 CSIRT-FOR-OUR-DOMAIN#207-1 370 371 372 Notification sent to next upstream NP closer to 192.0.2.35 373 374 375 376 377 378 379 380 381 384 385 386 387 388 389 450000522ad9 390 0000ff06c41fc0a801020a010102976d0050103e020810d9 391 4a1350021000ad6700005468616e6b20796f7520666f7220 392 6361726566756c6c792072656164696e6720746869732052 393 46432e0a 394 395 396 397 398 400 401 402 403 406 408 409 410 412 413 415 KiI5+6SnFAs429VNwsoJjHPplmo= 416 417 418 419 VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== 420 421 422 423 424

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j 425 QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

426 li7dzDacuo67Jg7mtqEm2TRuOMU= 427 Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 428 Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA== 429 VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs 430 HifTyYdnj+roGzy4o09YntYD8zneQ7lw== 431 432 433 434 435 437 4.2 RequestAuthorization Message Example 439 This RequestAuthorization is identical to the RequestAuthorization 440 example in section 4.5.1.2 of the RID specification and is 441 sent in response to the TraceRequest to approve the request. 443 445 446 448 450 451 452 192.0.2.67 453 454 455 456 CERT-FOR-OUR-DOMAIN#207-1 457 458 459 460 461 462 464 4.3 Result Message Example 466 This Result message is identical to the Result example in section 467 4.5.1.3 of the RID. This message is the final response from the 468 TraceRequest that has completed to notify the requestor of the 469 results and actions taken from the request. 471 473 474 476 478 479 480 192.0.2.67 481 482 483 484 CERT-FOR-OUR-DOMAIN#207-1 485 486 487 488 true 489 490 192.0.2.37 491 492 493 494 495 496 498 499 500 CERT-FOR-OUR-DOMAIN#207-1 501 502 2004-02-02T22:49:24+00:00 503 2004-02-02T22:19:24+00:00 504 2004-02-02T23:20:24+00:00 505 Host involved in DOS attack 506 507 508 509 510 511 Constituency-contact for 192.0.2.35 512 513 Constituency-contact@192.0.2.35 514 515 516 517 Admin-contact for 192.0.2.35 518 519 Admin-contact@192.0.2.35 520 521 522 523 524 192.0.2.35 525 526 527 528 529 530 531 Admin-contact for 192.0.2.3 532 533 Admin-contact@192.0.2.3 534 535 536 537 538 192.0.2.3 539 540 541 542 543 544 545 546 547 548 549 192.0.2.35 550 551 552 553 38765 554 555 556 557 558 192.0.2.67 559 560 561 562 80 563 564 565 566 567 568 Rate limit traffic close to source 569 570 571 572 573 574 The IPv4 packet included was used in the described attack 575 576 450000522ad9 577 0000ff06c41fc0a801020a010102976d0050103e020810d9 578 4a1350021000ad6700005468616e6b20796f7520666f7220 579 6361726566756c6c792072656164696e6720746869732052 580 46432e0a 581 582 583 584 585 586 587 2004-02-02T22:53:01+00:00 588 589 CSIRT-FOR-OUR-DOMAIN#207-1 590 591 592 Notification sent to next upstream NP closer to 192.0.2.35 593 594 595 596 2004-02-02T23:07:21+00:00 597 598 CSIRT-FOR-NP3#3291-1 599 600 601 Host rate limited for 24 hours 602 603 604 605 606 607 609 611 4.4 Example InvestigationRequest Message 613 This InvestigationRequest is identical to the InvestigationRequest 614 example in section 4.5.2.1 of the RID specification and would be 615 sent in a situation similar to that of example 4.1, when the source 616 of the attack is known. 618 620 621 623 625 626 627 192.0.2.98 628 629 630 631 CERT-FOR-OUR-DOMAIN#208-1 632 633 634 635 636 637 639 640 641 CERT-FOR-OUR-DOMAIN#208-1 642 643 2004-02-05T08:13:33+00:00 644 2004-02-05T08:13:31+00:00 645 2004-02-05T08:13:33+00:00 646 2004-02-05T08:13:35+00:00 647 Host involved in DOS attack 648 649 650 651 652 653 Constituency-contact for 192.0.2.35 654 655 Constituency-contact@192.0.2.35 656 657 658 659 660 661 192.0.2.35 662 663 664 665 41421 666 667 668 669 670 192.0.2.67 671 672 673 674 80 675 676 677 678 679 680 Investigate whether source has been compromised 681 682 683 684 685 686 2004-02-05T08:19:01+00:00 687 688 CSIRT-FOR-OUR-DOMAIN#208-1 689 690 691 Investigation request sent to NP for 192.0.2.35 692 693 694 695 696 697 698 700 4.5 Example Report 702 This Report is identical to the Report example in section 4.5.3.1 703 of the RID specification. 705 707 708 710 711 712 713 192.0.2.3 714 715 716 717 CERT-FOR-OUR-DOMAIN#209-1 718 719 720 721 722 723 725 726 727 CERT-FOR-OUR-DOMAIN#209-1 728 729 2004-02-05T10:21:08+00:00 730 2004-02-05T10:21:05+00:00 731 2004-02-05T10:35:00+00:00 732 2004-02-05T10:27:38+00:00 733 Host illicitly accessed admin account 734 735 736 738 739 740 741 Constituency-contact for 192.0.2.35 742 743 Constituency-contact@192.0.2.35 744 745 746 747 748 749 192.0.2.35 750 751 752 753 32821 754 755 756 757 758 192.0.2.67 759 760 761 762 22 763 764 766 767 768 769 770 2004-02-05T10:28:00+00:00 771 772 CSIRT-FOR-OUR-DOMAIN#209-1 773 774 775 Incident report sent to NP for 192.0.2.35 776 777 778 779 780 781 782 783 4.6 Example IncidentQuery 785 This IncidentQuery is identical to the IncidentQuery example in 786 Section 4.5.4.1 of the RID specification. 788 790 791 793 795 796 797 192.0.2.3 798 799 800 801 CERT-FOR-OUR-DOMAIN#210-1 802 803 804 805 806 808 5. Security Considerations 810 All security considerations of related documents MUST be 811 considered, including those in the following documents: 812 the Incident Object Description Exchange (IODEF), [RFCXXXX] 813 and Real-time Inter-network Defense (RID) [RFCYYYY]. 814 The SOAP wrappers described herein are built upon the 815 foundation of these documents; the security considerations 816 contained therein are incorporated by reference. 818 Security guidelines such as those described in, "Security 819 in a Web Services World: A Proposed Architecture and Roadmap", 820 [1] should be considered. 822 5.1 Privacy and Confidentiality 824 For transport confidentiality, TLS (whether HTTP/TLS or the BEEP 825 TLS profile) MUST be supported and SHOULD be used. 827 Since multiple bindings for transport may be implemented, RID 828 implementations MUST support XML encryption [5] to encrypt the SOAP 829 body. Since XML encryption is performed at the IODEF document 830 level, not only is the transport encrypted when a document is 831 sensitive or contains sensitive elements, but the stored document 832 is also encrypted. Note that this encryption applies only to the 833 SOAP body; policy information in the SOAP header should remain 834 unencrypted if it is necessary for the intermediate node to 835 dispatch the message. XML encryption protects the IODEF/RID 836 document in the SOAP body from being viewed by any involved SOAP 837 intermediary node. 839 5.2 Authentication and Identification 841 For transport authentication and identification, TLS (whether 842 HTTP/TLS or the BEEP TLS profile) with mutual authentication 843 MUST be supported and SHOULD be used. Each RID consortium SHOULD 844 use a trusted public key infrastructure (PKI) to manage 845 identities for TLS connections. The public/private key pairs 846 used for XML encryption and digital signatures provide 847 authentication for the RID message [RFC3275], [2]. The session 848 encryption keys are also used to identify the communicating 849 hosts and provide integrity for the session. 851 Since multiple bindings for transport may be implemented, RID 852 implementations MUST support XML digital signatures [RFC3275] to 853 sign the SOAP body; the rationale and implementation here is 854 parallel to that for XML encryption discussed in section 5.1. 856 6. IANA Considerations 858 The IANA is requested to assign TCP ports in the Registered Port 859 Numbers set for RID over SOAP over HTTPS and for RID over SOAP 860 over BEEP. 862 7. Summary 864 SOAP provides the wrapper to facilitate the exchange of RID 865 messages. The IETF and W3C standards provide detailed 866 implementation details for SOAP and SOAP protocol bindings. The 867 use of existing standards assists with development and 868 interoperability between RID systems exchanging IODEF documents for 869 incident handling purposes. HTTP/TLS is the mandatory transport 870 binding for SOAP to be implemented and BEEP with a TLS profile is 871 optional. 873 8. Informative References 875 [RFC3330] "Special-Use IPv4 Addresses." IANA. September 2002. 877 [1] "Security in a Web Services World: A Proposed Architecture 878 and Roadmap". IBM and Microsoft, April 2002. 879 http://www-106.ibm.com/developerworks/webservices/library/ws-secmap 881 [2] XML-Signature Syntax and Processing, W3C Recommendation, 882 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, February 883 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design 885 8.1 Normative References 887 [RFC2119] "Key Words for Use in RFCs to Indicate Requirement 888 Levels," S. Bradner, March 1997. 890 [RFC2616] "Hypertext Transfer Protocol - HTTP/1.1," R. Fielding, J. 891 Gettys, J. Mogul, H. Masinter, P. Leach, and T. Berners-Lee, June 892 1999. 894 [RFC3080] "The Blocks Extensible Exchange Protocol Core," M. Rose. 895 March 2001. 897 [RFC3205] "On the Use of HTTP as a Substrate," K. Moore, February 898 2002. (BCP56) 900 [RFC3275] "(Extensible Markup Language) XML-Signature Syntax and 901 Processing", D. Eastlake 3rd, J. Reagle, D. Solo. March 2002. 903 [RFC4227] "Using the Simple Object Access Protocol (SOAP) in Blocks 904 Extensible Exchange Protocol (BEEP)," E. O'Tuathail, and M. Rose, 905 January 2006. http://www.faqs.org/rfcs/rfc4227.html 907 [RFC4346] "The Transport Layer Security (TLS) Protocol Version 908 1.1," T. Dierks, E. Rescorla. April 2006. 910 [RFCXXXX] "The Incident Object Data Exchange Format Data Model and 911 XML Implementation," J. Meijer, R. Danyliw, and Y. Demchenko, 912 August 2006. 913 http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-14.txt 915 [RFCYYYY] "Real-time Inter-network Defense," K. Moriarty, 916 December 2007. http://www.ietf.org/internet-drafts/ 917 draft-moriarty-post-inch-rid-02.txt 919 [3] SOAP Version 1.2 Part 0: Primer, W3C Recommendation, 920 http://www.w3c.org/TR/REC-soap12-part0-20030624/, 24 June 2004. 922 [4] SOAP Version 1.2 Part 1:Messaging Framework. W3C 923 Recommendation, 24 June 2004. 924 http://www.w3c.org/TR/REC-soap12-part1-20030624/ 926 [5] XML Encryption Syntax and Processing, W3C Recommendation. 927 T. Imamura, B. Dillaway, and E. Simon, December 2002. 929 [5] XML-Signature Syntax and Processing, W3C Recommendation, 930 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, February 931 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design 933 8.2 Acknowledgments 935 Funding for the RFC Editor function is currently provided by the 936 Internet Society. 938 8.3 Author Information 939 Kathleen M. Moriarty 940 RSA, The Security Division of EMC 941 174 Middlesex Turnpike 942 Bedford, MA 01730 943 Email: Kathleen.Moriarty@RSA.com 945 Brian H. Trammell 946 CERT Network Situational Awareness 947 4500 Fifth Avenue 948 Pittsburgh, PA 15213 949 Email: bht@cert.org 951 Intellectual Property Statement 953 The IETF takes no position regarding the validity or scope of any 954 Intellectual Property Rights or other rights that might be claimed 955 to pertain to the implementation or use of the technology described 956 in this document or the extent to which any license under such 957 rights might or might not be available; nor does it represent that 958 it has made any independent effort to identify any such rights. 959 Information on the procedures with respect to rights in RFC 960 documents can be found in BCP 78 and BCP 79. 962 Copies of IPR disclosures made to the IETF Secretariat and any 963 assurances of licenses to be made available, or the result of an 964 attempt made to obtain a general license or permission for the use 965 of such proprietary rights by implementers or users of this 966 specification can be obtained from the IETF on-line IPR repository 967 at http://www.ietf.org/ipr. 969 The IETF invites any interested party to bring to its attention any 970 copyrights, patents or patent applications, or other proprietary 971 rights that may cover technology that may be required to implement 972 this standard. Please address the information to the IETF at 973 ietf-ipr@ietf.org. 975 The IETF has been notified of intellectual property rights claimed 976 in regard to some or all of the specification contained in this 977 document. For more information consult the online list of claimed 978 rights. 980 Full Copyright Statement 982 Copyright (C) The IETF Trust (2007). 984 This document is subject to the rights, licenses and restrictions 985 contained in BCP 78, and except as set forth therein, the authors 986 retain all their rights. 988 This document and the information contained herein are provided on an 989 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 990 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 991 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 992 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 993 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 994 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 995 FOR A PARTICULAR PURPOSE. 997 Sponsor Information 999 This work was sponsored by the Air Force under Air Force 1000 Contract FA8721-05-C-0002 while Kathleen worked at MIT Lincoln 1001 Laboratory. 1003 "Opinions, interpretations, conclusions, and recommendations 1004 are those of the author and are not necessarily endorsed 1005 by the United States Government."