idnits 2.17.1 draft-moriarty-post-inch-rid-soap-03.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 987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 965. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 21) being 59 lines 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 14, 2008) is 5916 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) == Unused Reference: 'RFC2119' is defined on line 881, but no explicit reference was found in the text -- 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. '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: 5 errors (**), 0 flaws (~~), 5 warnings (==), 14 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 4 draft-moriarty-post-inch-rid-soap-03.txt Brian H. Trammell 5 Expires: August 14, 2008 CERT Network Situational Awareness 6 February 14, 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 RFC 2119. 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 CSIRTS or those responsible for security incident handling 96 for network providers (NPs). The defined document format provides 97 an easy way for CSIRTS to exchange data in a way which can be easily 98 parsed. In order for the IODEF documents to be shared between 99 entities, a uniform method for transport is necessary. SOAP [2] will 100 provide a layer of abstraction and enable the use of multiple 101 transport protocol bindings. IODEF documents and extensions will 102 be contained in an XML Real-time Inter-network Defense (RID) 103 [RFCYYYY] envelope inside the body of a SOAP message. For some 104 message types, the IODEF document or RID document may stand alone 105 in the body of a SOAP message. The RIDPolicy class of RID (e.g., 106 policy information that may affect message routing) will appear in 107 the SOAP message header. 109 HTTP/TLS [RFC4346] has been selected as the REQUIRED SOAP binding 110 for exchanging IODEF/RID messages. The primary reason for 111 selecting HTTP/TLS is due to the existence of multiple successful 112 implementations of SOAP over HTTP/TLS, and to its being widely 113 understood, despite the additional overhead associated with this 114 combination. Excellent tool support exists to ease the development 115 of applications using SOAP over HTTP. BEEP may actually be better 116 suited as a transport for RID messages containing IODEF documents, 117 but does not yet have wide adoption. Standards exist for the HTTPS 118 or HTTP/TLS binding for SOAP. A standard is in development for 119 SOAP over BEEP, [RFC4227]. Standards MUST be followed when 120 implementing transport bindings for RID communications. 122 2. SOAP Wrapper 124 IODEF/RID documents, including all supported extensions, intended 125 to be shared between CSIRTS or NPs MUST use a SOAP wrapper, along 126 with a supported transport protocol binding, for transport. The 127 transport is independent of the wrapper. SOAP will be used to 128 provide the messaging framework and can make distinctions as to how 129 messages should be handled by each participating system. SOAP has 130 been selected because of the flexibility it provides for binding 131 with transport protocols, which can be independent of the IODEF/RID 132 messaging system. 134 As defined by the SOAP messaging specifications [3], the 135 appropriate message contents for the RID message type, as defined 136 in RID, will be in the SOAP body of the message. The SOAP header 137 contains information pertinent to all participating systems that 138 receive the message, including the ultimate destination, any 139 intermediate hosts, and message processing policy information and 140 is provided through RIDPolicy in the RID schema. Depending on the 141 message or document being transported, there may be a case, such as 142 with RID messages, in which a host may only need to view the SOAP 143 header and not the SOAP body and is, therefore, acting as a SOAP 144 intermediary node. An example of this would be if one RID system 145 was sending a communication to a RID system for which there was no 146 direct trust relationship, an intermediate RID system may be used 147 to provide the trusted path between the communicating systems. 148 This intermediate system may not need to see the contents of the 149 SOAP body. Therefore, the elements or classes needed by all 150 participating systems MUST be in the SOAP header, specifically the 151 RIDPolicy class. Each participating system receiving an incident 152 handling IODEF/RID document is an ultimate destination and has to 153 parse and view the entire IODEF/RID document to make necessary 154 decisions. 156 The SOAP specifications for intermediate and ultimate nodes MUST be 157 Followed; for example, a message destined for an intermediate node 158 would contain the attribute env:role with the value 159 http://www.w3c.org/2003/05/soap-envelope/role/next. Also in 160 accordance with the SOAP specifications, the attribute of 161 env:mustUnderstand has a value of "true" to ensure each node 162 processes the header blocks consistent with the specifications for 163 IODEF/RID. 165 SOAP messages are typically a one-way conversation. Transmittal of 166 incident information to another RID host in the form of a Report 167 message is the single case within RID where a one way communication 168 is specified. The arrival of an IODEF Report document in a RID 169 message is simply an assertion that a described incident occurred. 170 In the case of other RID message types, two or more SOAP messages 171 may be exchanged to enable bi-directional communication. 172 Request/response pairs defined by RID include: 173 TraceRequest/TraceAuthorization/Result, 174 Investigation/Result, and 175 IncidentQuery/Report. 177 3. Transport Protocol Bindings 179 The SOAP binding will be used for message transport. One agreed- 180 upon protocol, HTTP/TLS, MUST be implemented by all RID systems and 181 other protocols are optional. The use of a single transport 182 binding supported by all systems sending and receiving RID messages 183 and will enable interoperability between participating CSIRTS and 184 NPs. Other protocol bindings may be defined in separate documents. 186 3.1 SOAP over HTTP/TLS 188 SOAP over HTTP/TLS is widely supported, as are ancillary tools such 189 as the Web Services Description Language (WSDL), hence the 190 selection of SOAP over HTTP/1.1 over TLS as Mandatory for transport 191 of RID communications. Security is provided through the RID 192 specification and all REQUIRED RID security MUST be implemented. 193 TLS offers additional security at the transport layer to ensure the 194 integrity of the session. 196 BCP 56 [RFC3205] contains a number of important considerations when 197 using HTTP for application protocols. These include the size of 198 the payload for the application, whether the application will use a 199 web browser, whether the protocol should be defined on a port other 200 than 80, and if the security provided through HTTP/TLS suits the 201 needs of the new application. 203 It is acknowledged within the scope of these concerns that HTTP/TLS 204 is not ideally suited for IODEF/RID transport, as the former is a 205 client-server protocol and the latter a message-exchange protocol; 206 however, the ease of implementation for services based on SOAP over 207 HTTP outweighs these concerns. Consistent with BCP 56, IODEF/RID 208 over SOAP over HTTP/TLS will require its own TCP port assignment 209 from IANA. 211 Every RID system participating in a consortium MUST listen for 212 HTTP/TLS connections on the assigned port, as the requests and 213 responses in a RID message exchange transaction may be 214 significantly separated in time. If a RID message is answered 215 immediately, or within a generally accepted HTTP client timeout 216 (about thirty seconds), the listening system SHOULD return the 217 reply message in the HTTP response body; otherwise, it must 218 initiate a connection to the requesting system and send its reply 219 in an HTTP request. 221 If the HTTP response body sent in reply to a RID message does not 222 contain a RID message itself, the response body SHOULD be empty, 223 and RID clients MUST ignore any response body that is not an 224 expected RID message. This provision applies ONLY to HTTP response 225 bodies; unsolicited HTTP requests (such as Reports not preceded by 226 an IncidentQuery) are handled according to the message exchange 227 pattern described in RID. 229 RID systems SHOULD use HTTP/1.1 persistent connections as described 230 in [RFC2616] to minimize TCP connection setup overhead. RID systems 231 SHOULD support chunked transfer encoding on the HTTP server side to 232 allow the implementation of clients that do not need to 233 precalculate message sizes before constructing HTTP headers. 235 3.2 SOAP over BEEP 237 SOAP over BEEP is an optional transport binding for IODEF/RID. A 238 RID system supporting BEEP [RFC3080] MAY attempt to use SOAP over 239 BEEP on first connection with a peer; if the peer does not support 240 SOAP over BEEP, the initiating peer MUST fall back to SOAP over 241 HTTPS, and SHOULD note that the peer does not support BEEP, to 242 avoid attempting to use BEEP in future communications. 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 294 295 296 192.0.2.3 297 298 299 300 CERT-FOR-OUR-DOMAIN#207-1 301 302 303 304 305 306 308 309 310 CERT-FOR-OUR-DOMAIN#207-1 311 312 2004-02-02T22:49:24+00:00 313 2004-02-02T22:19:24+00:00 314 2004-02-02T23:20:24+00:00 315 Host involved in DOS attack 316 317 318 319 320 Constituency-contact for 192.0.2.35 321 322 Constituency-contact@192.0.2.35 323 324 325 326 327 328 192.0.2.35 329 330 331 332 38765 333 334 335 336 337 192.0.2.67 338 339 340 341 80 342 343 344 345 346 347 Rate limit traffic close to source 348 349 350 351 352 353 The IPv4 packet included was used in the described attack 354 355 450000522ad9 356 0000ff06c41fc0a801020a010102976d0050103e020810d9 357 4a1350021000ad6700005468616e6b20796f7520666f7220 358 6361726566756c6c792072656164696e6720746869732052 359 46432e0a 360 361 362 363 364 365 366 2001-09-14T08:19:01+00:00 367 368 CSIRT-FOR-OUR-DOMAIN#207-1 369 370 371 Notification sent to next upstream NP closer to 192.0.2.35 372 373 374 375 376 377 378 379 380 383 384 385 386 387 388 450000522ad9 389 0000ff06c41fc0a801020a010102976d0050103e020810d9 390 4a1350021000ad6700005468616e6b20796f7520666f7220 391 6361726566756c6c792072656164696e6720746869732052 392 46432e0a 393 394 395 396 398 399 400 401 402 405 407 408 409 411 412 414 KiI5+6SnFAs429VNwsoJjHPplmo= 415 416 417 418 VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== 419 420 421 422 423

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j 424 QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

425 li7dzDacuo67Jg7mtqEm2TRuOMU= 426 Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 427 Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA== 428 VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs 429 HifTyYdnj+roGzy4o09YntYD8zneQ7lw== 430 431 432 433 434 436 4.2 RequestAuthorization Message Example 438 This RequestAuthorization is identical to the RequestAuthorization 439 example in section 4.5.1.2 of the RID specification and Is 440 sent in response to the TraceRequest to approve the request. 442 444 445 447 449 450 451 192.0.2.67 452 453 454 455 CERT-FOR-OUR-DOMAIN#207-1 456 457 458 459 460 461 463 4.3 Result Message Example 465 This Result message is identical to the Result example in section 466 4.5.1.3 of the RID. This message is the final response from the 467 TraceRequest that has completed to notify the requestor of the 468 results and actions taken from the request. 470 472 473 475 477 478 479 192.0.2.67 480 481 482 483 CERT-FOR-OUR-DOMAIN#207-1 484 485 486 487 true 488 489 192.0.2.37 490 491 492 493 494 495 497 498 499 CERT-FOR-OUR-DOMAIN#207-1 500 501 2004-02-02T22:49:24+00:00 502 2004-02-02T22:19:24+00:00 503 2004-02-02T23:20:24+00:00 504 Host involved in DOS attack 505 506 507 508 509 510 Constituency-contact for 192.0.2.35 511 512 Constituency-contact@192.0.2.35 513 514 515 516 Admin-contact for 192.0.2.35 517 518 Admin-contact@192.0.2.35 519 520 521 522 523 192.0.2.35 524 525 526 527 528 529 530 Admin-contact for 192.0.2.3 531 532 Admin-contact@192.0.2.3 533 534 535 536 537 192.0.2.3 538 539 540 541 542 543 544 545 546 547 548 192.0.2.35 549 550 551 552 38765 553 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 608 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 765 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 [4] 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) MUST be supported and SHOULD be 843 used. Each RID consortium SHOULD use a trusted public key 844 infrastructure (PKI) to manage identities for TLS connections. 845 The public/private key pairs used for XML encryption and digital 846 signatures provide authentication for the RID message. The session 847 encryption keys are also used to identify the communicating hosts 848 and provide integrity for the session. 850 Since multiple bindings for transport may be implemented, RID 851 implementations MUST support XML digital signatures [5] to 852 sign the SOAP body; the rationale and implementation here is 853 parallel to that for XML encryption discussed in section 5.1. 855 6. IANA Considerations 857 The IANA is requested to assign TCP ports for RID over SOAP over 858 HTTPS and for RID over SOAP over BEEP. 860 7. Summary 862 SOAP provides the wrapper to facilitate the exchange of RID 863 messages. The IETF and W3C standards provide detailed 864 implementation details for SOAP and SOAP protocol bindings. The 865 use of existing standards assists with development and 866 interoperability between RID systems exchanging IODEF documents for 867 incident handling purposes. HTTP/TLS is the mandatory transport 868 binding for SOAP to be implemented and BEEP with a TLS profile is 869 optional. 871 8. Informative References 873 [RFC3330] "Special-Use IPv4 Addresses." IANA. September 2002. 875 [1] "Security in a Web Services World: A Proposed Architecture 876 and Roadmap". IBM and Microsoft, April 2002. 877 http://www-106.ibm.com/developerworks/webservices/library/ws-secmap 879 8.1 Normative References 881 [RFC2119] "Key Words for Use in RFCs to Indicate Requirement 882 Levels," S. Bradner, March 1997. 884 [RFC2616] "Hypertext Transfer Protocol - HTTP/1.1," R. Fielding, J. 885 Gettys, J. Mogul, H. Masinter, P. Leach, and T. Berners-Lee, June 886 1999. 888 [RFC3080] "The Blocks Extensible Exchange Protocol Core," M. Rose. 889 March 2001. 891 [RFC3205] "On the Use of HTTP as a Substrate," K. Moore, February 892 2002. (BCP56) 894 [RFC4227] "Using the Simple Object Access Protocol (SOAP) in Blocks 895 Extensible Exchange Protocol (BEEP)," E. O'Tuathail, and M. Rose, 896 January 2006. http://www.faqs.org/rfcs/rfc4227.html 898 [RFC4346] "The Transport Layer Security (TLS) Protocol Version 899 1.1," T. Dierks, E. Rescorla. April 2006. 901 [RFCXXXX] "The Incident Object Data Exchange Format Data Model and 902 XML Implementation," J. Meijer, R. Danyliw, and Y. Demchenko, 903 August 2006. 904 http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-14.txt 906 [RFCYYYY] "Real-time Inter-network Defense," K. Moriarty, 907 February 2008. http://www.ietf.org/internet-drafts/ 908 draft-moriarty-post-inch-rid-02.txt 910 [2] SOAP Version 1.2 Part 0: Primer, W3C Recommendation, 911 http://www.w3c.org/TR/REC-soap12-part0-20030624/, 24 June 2004. 913 [3] SOAP Version 1.2 Part 1:Messaging Framework. W3C 914 Recommendation, 24 June 2004. 915 http://www.w3c.org/TR/REC-soap12-part1-20030624/ 917 [4] XML Encryption Syntax and Processing, W3C Recommendation. 918 T. Imamura, B. Dillaway, and E. Simon, December 2002. 920 [5] XML-Signature Syntax and Processing, W3C Recommendation, 921 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, February 922 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design 924 8.2 Acknowledgments 926 Funding for the RFC Editor function is currently provided by the 927 Internet Society. 929 8.3 Author Information 931 Kathleen M. Moriarty 932 RSA, The Security Division of EMC 933 174 Middlesex Turnpike 934 Bedford, MA 01730 935 Email: Kathleen.Moriarty@rsa.com 937 Brian H. Trammell 938 CERT Network Situational Awareness 939 4500 Fifth Avenue 940 Pittsburgh, PA 15213 941 Email: bht@cert.org 943 Intellectual Property Statement 945 The IETF takes no position regarding the validity or scope of any 946 Intellectual Property Rights or other rights that might be claimed 947 to pertain to the implementation or use of the technology described 948 in this document or the extent to which any license under such 949 rights might or might not be available; nor does it represent that 950 it has made any independent effort to identify any such rights. 951 Information on the procedures with respect to rights in RFC 952 documents can be found in BCP 78 and BCP 79. 954 Copies of IPR disclosures made to the IETF Secretariat and any 955 assurances of licenses to be made available, or the result of an 956 attempt made to obtain a general license or permission for the use 957 of such proprietary rights by implementers or users of this 958 specification can be obtained from the IETF on-line IPR repository 959 at http://www.ietf.org/ipr. 961 The IETF invites any interested party to bring to its attention any 962 copyrights, patents or patent applications, or other proprietary 963 rights that may cover technology that may be required to implement 964 this standard. Please address the information to the IETF at 965 ietf-ipr@ietf.org. 967 The IETF has been notified of intellectual property rights claimed 968 in regard to some or all of the specification contained in this 969 document. For more information consult the online list of claimed 970 rights. 972 Full Copyright Statement 974 Copyright (C) The IETF Trust (2008). 976 This document is subject to the rights, licenses and restrictions 977 contained in BCP 78, and except as set forth therein, the authors 978 retain all their rights. 980 This document and the information contained herein are provided on an 981 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 982 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 983 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 984 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 985 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 986 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 987 FOR A PARTICULAR PURPOSE. 989 Sponsor Information 991 This work was sponsored by the Air Force under Air Force 992 Contract FA8721-05-C-0002, while Kathleen was working at MIT 993 Lincoln Laboratory. 995 "Opinions, interpretations, conclusions, and recommendations 996 are those of the author and are not necessarily endorsed 997 by the United States Government."