idnits 2.17.1 draft-moriarty-post-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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 940. ** 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 == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 19) being 59 lines 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 207 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 10 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 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 (April 9, 2007) is 6226 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 80, but not defined == Missing Reference: '18' is mentioned on line 125, but not defined == Unused Reference: 'RFC2119' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'RFC2256' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'RFC2527' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'RFC3080' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC3205' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 870, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 890, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 894, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 897, 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: 14 errors (**), 0 flaws (~~), 19 warnings (==), 9 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-moriarty-post-inch-rid-soap-01.txt MIT Lincoln Laboratory 3 Brian H. Trammell 4 CERT Network Situational Awareness 5 Expires: October 9, 2007 April 9, 2007 7 IODEF/RID over SOAP 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Documents intended to be shared among multiple constituencies must 34 share a common format and transport mechanism. The Incident Object 35 Description Exchange Format (IODEF) defines a common XML format for 36 document exchange. This draft outlines the SOAP wrapper for all 37 IODEF documents and extensions to facilitate an interoperable and 38 secure communication of documents. The SOAP wrapper allows for 39 flexibility in the selection of a transport protocol. The 40 transport protocols will be provided through existing standards and 41 SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP. 43 TABLE OF CONTENTS 45 Status of this Memo ................................................ 1 47 Abstract ........................................................... 1 49 1. Introduction .................................................... 3 51 2. SOAP Wrapper .................................................... 3 53 3. Transport Protocol Bindings ..................................... 4 54 3.1 SOAP over HTTP/TLS ......................................... 4 55 3.2 SOAP over BEEP ............................................. 5 57 4. Examples ........................................................ 6 58 4.1. Example TraceRequest message .......................... 6 59 4.2 RequestAuthorization Message Example ....................... 9 60 4.3 Result Message Example ..................................... 10 61 4.4 Example InvestigationRequest Message ....................... 12 62 4.5 Example Report ............................................. 14 63 4.6 Example IncidentQuery ...................................... 16 65 5. Security Considerations ......................................... 16 66 5.1 Privacy and Confidentiality ................................ 16 67 5.2 Authentication and Identification .......................... 17 69 6. IANA Considerations ............................................. 17 71 7. Summary ......................................................... 17 73 8. References ...................................................... 17 75 6.1 Acknowledgments ............................................ 19 76 6.2 Author Information ......................................... 19 78 1. Introduction 80 The Incident Object Description Exchange Format (IODEF) [RFCXXX] 81 describes an XML document format for the purpose of exchanging data 82 between CSIRTS or those responsible for security incident handling 83 for network providers (NPs). The defined document format provides 84 an easy way for CSIRTS to exchange data in a way which can be easily 85 parsed. In order for the IODEF documents to be shared between 86 entities, a uniform method for transport is necessary. SOAP will 87 provide a layer of abstraction and enable the use of multiple 88 transport protocol bindings. IODEF documents and extensions will 89 be contained in an XML Real-time Inter-network Defense (RID) 90 [RFCXXXX] envelope inside the body of a SOAP message. For some 91 message types, the IODEF document or RID document may stand alone 92 in the body of a SOAP message. The RIDPolicy class of RID (e.g., 93 policy information that may affect message routing) will appear in 94 the SOAP message header. 96 HTTP/TLS has been selected as the REQUIRED SOAP binding for 97 exchanging IODEF/RID messages. The primary reason for selecting 98 HTTP/TLS is due to the existence of multiple successful 99 implementations of SOAP over HTTP/TLS, and to its being widely 100 understood, despite the additional overhead associated with this 101 combination. Excellent tool support exists to ease the development 102 of applications using SOAP over HTTP. BEEP may actually be better 103 suited as a transport for RID messages containing IODEF documents, 104 but does not yet have wide adoption. Standards exist for the HTTPS 105 or HTTP/TLS binding for SOAP. A standard is in development for 106 SOAP over BEEP, [RFC****]. Standards MUST be followed when 107 implementing transport bindings for RID communications. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in RFC2119. 113 2. SOAP Wrapper 115 IODEF/RID documents, including all supported extensions, intended 116 to be shared between CSIRTS or NPs MUST use a SOAP wrapper, along 117 with a supported transport protocol binding, for transport. The 118 transport is independent of the wrapper. SOAP will be used to 119 provide the messaging framework and can make distinctions as to how 120 messages should be handled by each participating system. SOAP has 121 been selected because of the flexibility it provides for binding 122 with transport protocols, which can be independent of the IODEF/RID 123 messaging system. 125 As defined by the SOAP messaging specifications [18], the 126 appropriate message contents for the RID message type, as defined 127 in RID, will be in the SOAP body of the message. The SOAP header 128 contains information pertinent to all participating systems that 129 receive the message, including the ultimate destination, any 130 intermediate hosts, and message processing policy information and 131 is provided through RIDPolicy in the RID schema. Depending on the 132 message or document being transported, there may be a case, such as 133 with RID messages, in which a host may only need to view the SOAP 134 header and not the SOAP body and is, therefore, acting as a SOAP 135 intermediary node. An example of this would be if one RID system 136 was sending a communication to a RID system for which there was no 137 direct trust relationship, an intermediate RID system may be used 138 to provide the trusted path between the communicating systems. 139 This intermediate system may not need to see the contents of the 140 SOAP body. Therefore, the elements or classes needed by all 141 participating systems MUST be in the SOAP header, specifically the 142 RIDPolicy class. Each participating system receiving an incident 143 handling IODEF/RID document is an ultimate destination and has to 144 parse and view the entire IODEF/RID document to make necessary 145 decisions. 147 The SOAP specifications for intermediate and ultimate nodes MUST be 148 Followed; for example, a message destined for an intermediate node 149 would contain the attribute env:role with the value 150 http://www.w3c.org/2003/05/soap-envelope/role/next. Also in 151 accordance with the SOAP specifications, the attribute of 152 env:mustUnderstand has a value of "true" to ensure each node 153 processes the header blocks consistent with the specifications for 154 IODEF/RID. 156 SOAP messages are typically a one-way conversation. Transmittal of 157 incident information to another RID host in the form of a Report 158 message is the single case within RID where a one way communication 159 is specified. The arrival of an IODEF Report document in a RID 160 message is simply an assertion that a described incident occurred. 161 In the case of other RID message types, two or more SOAP messages 162 may be exchanged to enable bi-directional communication. 163 Request/response pairs defined by RID include: 164 TraceRequest/TraceAuthorization/Result, 165 Investigation/Result, and 166 IncidentQuery/Report. 168 3. Transport Protocol Bindings 170 The SOAP binding will be used for message transport. One agreed- 171 upon protocol, HTTP/TLS, MUST be implemented by all RID systems and 172 other protocols are optional. The use of a single transport 173 binding supported by all systems sending and receiving RID messages 174 and will enable interoperability between participating CSIRTS and 175 NPs. Other protocol bindings may be defined in separate documents. 177 3.1 SOAP over HTTP/TLS 179 SOAP over HTTP/TLS is widely supported, as are ancillary tools such 180 as the Web Services Description Language (WSDL), hence the 181 selection of SOAP over HTTP/1.1 over TLS as Mandatory for transport 182 of RID communications. Security is provided through the RID 183 specification and all REQUIRED RID security MUST be implemented. 184 TLS offers additional security at the transport layer to ensure the 185 integrity of the session. 187 BCP 56 contains a number of important considerations when using 188 HTTP for application protocols. These include the size of the 189 payload for the application, whether the application will use a web 190 browser, whether the protocol should be defined on a port other 191 than 80, and if the security provided through HTTP/TLS suits the 192 needs of the new application. 194 It is acknowledged within the scope of these concerns that HTTP/TLS 195 is not ideally suited for IODEF/RID transport, as the former is a 196 client-server protocol and the latter a message-exchange protocol; 197 however, the ease of implementation for services based on SOAP over 198 HTTP outweighs these concerns. Consistent with BCP 56, IODEF/RID 199 over SOAP over HTTP/TLS will require its own TCP port assignment 200 from IANA. 202 Every RID system participating in a consortium MUST listen for 203 HTTP/TLS connections on the assigned port, as the requests and 204 responses in a RID message exchange transaction may be 205 significantly separated in time. If a RID message is answered 206 immediately, or within a generally accepted HTTP client timeout 207 (about thirty seconds), the listening system SHOULD return the 208 reply message in the HTTP response body; otherwise, it must 209 initiate a connection to the requesting system and send its reply 210 in an HTTP request. 212 If the HTTP response body sent in reply to a RID message does not 213 contain a RID message itself, the response body SHOULD be empty, 214 and RID clients MUST ignore any response body that is not an 215 expected RID message. This provision applies ONLY to HTTP response 216 bodies; unsolicited HTTP requests (such as Reports not preceded by 217 an IncidentQuery) are handled according to the message exchange 218 pattern described in RID. 220 RID systems SHOULD use HTTP/1.1 persistent connections as described 221 in RFC 2616 to minimize TCP connection setup overhead. RID systems 222 SHOULD support chunked transfer encoding on the HTTP server side to 223 allow the implementation of clients that do not need to 224 precalculate message sizes before constructing HTTP headers. 226 3.2 SOAP over BEEP 228 SOAP over BEEP is an optional transport binding for IODEF/RID. A 229 RID system supporting BEEP MAY attempt to use SOAP over BEEP on 230 first connection with a peer; if the peer does not support SOAP 231 over BEEP, the initiating peer MUST fall back to SOAP over HTTPS, 232 and SHOULD note that the peer does not support BEEP, to avoid 233 attempting to use BEEP in future communications. 235 BEEP has certain implementation advantages over HTTP/TLS for this 236 application; however, the protocol has not been widely implemented. 237 Communication between participating RID systems is on a server-to- 238 server basis, for which BEEP is better suited than HTTP. Incident 239 handling may at times require immediate action; thus, a protocol 240 with low overhead and minimum bandwidth requirements is desirable. 242 To provide equivalent transport-layer security to HTTP/TLS, the 243 BEEP TLS profile MUST be supported if BEEP is implemented and 244 SHOULD be used. 246 4. Examples 248 The examples below, parallel to the examples in section 4.5 of RID, 249 demonstrate how the structure of RID messages fit into SOAP 250 containers as outlined in this document for each message type. Of 251 particular note in each is the use of the RID policy information in 252 the SOAP header. The RID schema was designed to enable the use of 253 RIDPolicy to stand alone in the SOAP header and to enable the use of 254 the RID class, RequestStatus to stand alone in the SOAP body 255 without the need for an IODEF document. When the RID class called 256 IncidentSource is used, it is combined with an associated IODEF 257 document in the SOAP body to provide all of the necessary 258 information in response to an incident handling request. The first 259 example includes the full IODEF/RID message and associated 260 IODEF-Document; following examples omit the IODEF-Document and 261 Refer to it in a comment. Where indicated, the IODEF-Document must 262 be present, following the requirements listed in the IODEF and RID 263 specifications. 265 4.1. Example TraceRequest message 267 This TraceRequest is identical to the TraceRequest example in 268 Section 4.5.1.1 of RID and would be sent from a CSIRT 269 reporting a denial-of-service attack in progress to its upstream 270 NP. This request asks the upstream to continue the trace and to 271 rate-limit traffic closer to the source. 273 275 276 278 280 281 282 172.20.1.2 283 284 285 286 CERT-FOR-OUR-DOMAIN#207-1 287 288 289 290 291 292 294 295 296 CERT-FOR-OUR-DOMAIN#207-1 297 298 2004-02-02T22:49:24+00:00 299 2004-02-02T22:19:24+00:00 300 2004-02-02T23:20:24+00:00 301 Host involved in DOS attack 302 303 304 305 306 Constituency-contact for 10.1.1.2 307 308 Constituency-contact@10.1.1.2 309 310 311 312 313 314 10.1.1.2 315 316 317 38765 318 319 320 321 322 192.168.1.2 323 324 325 80 326 327 328 329 330 331 Rate limit traffic close to source 332 333 334 335 336 337 The IPv4 packet included was used in the described attack 338 339 450000522ad9 340 0000ff06c41fc0a801020a010102976d0050103e020810d9 341 4a1350021000ad6700005468616e6b20796f7520666f7220 342 6361726566756c6c792072656164696e6720746869732052 343 46432e0a 344 345 346 347 348 349 350 2001-09-14T08:19:01+00:00 351 352 CSIRT-FOR-OUR-DOMAIN#207-1 353 354 355 Notification sent to next upstream NP closer to 10.1.1.2 356 357 358 359 360 361 362 363 364 367 368 369 370 371 372 450000522ad9 373 0000ff06c41fc0a801020a010102976d0050103e020810d9 374 4a1350021000ad6700005468616e6b20796f7520666f7220 375 6361726566756c6c792072656164696e6720746869732052 376 46432e0a 377 378 379 380 381 382 383 384 385 388 390 391 392 394 395 397 KiI5+6SnFAs429VNwsoJjHPplmo= 398 399 400 401 VvyXqCzjoW0m2NdxNeToXQcqcSM80W+JMW+Kn01cS3z3KQwCPeswzg== 402 403 404 405 406

/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9j 407 QTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==

408 li7dzDacuo67Jg7mtqEm2TRuOMU= 409 Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5 410 Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA== 411 VFWTD4I/aKni4YhDyYxAJozmj1iAzPLw9Wwd5B+Z9J5E7lHjcAJ+bs 412 HifTyYdnj+roGzy4o09YntYD8zneQ7lw== 413 414 415 416 417 419 4.2 RequestAuthorization Message Example 421 This RequestAuthorization is identical to the RequestAuthorization 422 example in section 4.5.1.2 of the RID specification and Is 423 sent in response to the TraceRequest to approve the request. 425 427 428 430 432 433 434 192.168.1.2 435 436 437 438 CERT-FOR-OUR-DOMAIN#207-1 439 440 441 442 444 445 447 4.3 Result Message Example 449 This Result message is identical to the Result example in section 450 4.5.1.3 of the RID. This message is the final response from the 451 TraceRequest that has completed to notify the requestor of the 452 results and actions taken from the request. 454 456 457 459 461 462 463 192.168.1.2 464 465 466 467 CERT-FOR-OUR-DOMAIN#207-1 468 469 470 471 true 472 473 10.1.1.15 474 475 476 477 478 479 481 482 483 CERT-FOR-OUR-DOMAIN#207-1 484 485 2004-02-02T22:49:24+00:00 486 2004-02-02T22:19:24+00:00 487 2004-02-02T23:20:24+00:00 488 Host involved in DOS attack 489 490 491 492 493 Constituency-contact for 10.1.1.2 494 495 Constituency-contact@10.1.1.2 496 497 498 499 Admin-contact for 10.1.1.2 500 501 Admin-contact@10.1.1.2 502 503 504 505 506 10.1.1.2 507 508 509 510 511 512 513 Admin-contact for 172.20.1.2 514 515 Admin-contact@172.20.1.2 516 517 518 519 520 172.20.1.2 521 522 523 524 525 526 527 528 529 530 10.1.1.2 531 532 533 38765 534 535 536 537 538 192.168.1.2 539 540 541 80 542 543 544 545 546 547 Rate limit traffic close to source 549 550 551 552 553 554 The IPv4 packet included was used in the described attack 555 556 450000522ad9 557 0000ff06c41fc0a801020a010102976d0050103e020810d9 558 4a1350021000ad6700005468616e6b20796f7520666f7220 559 6361726566756c6c792072656164696e6720746869732052 560 46432e0a 561 562 563 564 565 566 567 2004-02-02T22:53:01+00:00 568 569 CSIRT-FOR-OUR-DOMAIN#207-1 570 571 572 Notification sent to next upstream NP closer to 10.1.1.2 573 574 575 576 2004-02-02T23:07:21+00:00 577 578 CSIRT-FOR-NP3#3291-1 579 580 581 Host rate limited for 24 hours 582 583 584 585 586 587 588 590 4.4 Example InvestigationRequest Message 592 This InvestigationRequest is identical to the InvestigationRequest 593 example in section 4.5.2.1 of the RID specification and would be 594 sent in a situation similar to that of example 4.1, when the source 595 of the attack is known. 597 599 600 603 605 606 607 172.25.1.33 608 609 610 611 CERT-FOR-OUR-DOMAIN#208-1 612 613 614 615 616 617 619 620 621 CERT-FOR-OUR-DOMAIN#208-1 622 623 2004-02-05T08:13:33+00:00 624 2004-02-05T08:13:31+00:00 625 2004-02-05T08:13:33+00:00 626 2004-02-05T08:13:35+00:00 627 Host involved in DOS attack 628 629 630 631 632 Constituency-contact for 10.1.1.2 633 634 Constituency-contact@10.1.1.2 635 636 637 638 639 640 10.1.1.2 641 642 643 41421 644 645 646 647 648 192.168.1.2 649 650 651 80 652 653 655 656 657 658 Investigate whether source has been compromised 659 660 661 662 663 664 2004-02-05T08:19:01+00:00 665 666 CSIRT-FOR-OUR-DOMAIN#208-1 667 668 669 Investigation request sent to NP for 10.1.1.2 670 671 672 673 674 675 676 678 4.5 Example Report 680 This Report is identical to the Report example in section 4.5.3.1 681 of the RID specification. 683 685 686 688 689 690 691 172.17.1.2 692 693 694 695 CERT-FOR-OUR-DOMAIN#209-1 696 697 698 699 700 701 703 704 705 CERT-FOR-OUR-DOMAIN#209-1 706 707 2004-02-05T10:21:08+00:00 708 2004-02-05T10:21:05+00:00 709 2004-02-05T10:35:00+00:00 710 2004-02-05T10:27:38+00:00 711 Host illicitly accessed admin account 712 713 714 715 716 717 718 Constituency-contact for 10.1.1.2 719 720 Constituency-contact@10.1.1.2 721 722 723 724 725 726 10.1.1.2 727 728 729 32821 730 731 732 733 734 192.168.1.2 735 736 737 22 738 739 740 741 742 743 744 2004-02-05T10:28:00+00:00 745 746 CSIRT-FOR-OUR-DOMAIN#209-1 747 748 749 Incident report sent to NP for 10.1.1.2 750 751 752 753 754 755 756 757 4.6 Example IncidentQuery 759 This IncidentQuery is identical to the IncidentQuery example in 760 Section 4.5.4.1 of the RID specification. 762 764 765 767 769 770 771 172.20.1.2 772 773 774 775 CERT-FOR-OUR-DOMAIN#210-1 776 777 778 779 780 782 5. Security Considerations 784 All security considerations of related documents MUST be 785 considered, including those in the following documents: 786 the Incident Object Description Exchange (IODEF), [RFCXXXX], 787 and Real-time Inter-network Defense (RID) [RFCXXXX]. The 788 SOAP wrappers described herein are built upon the foundation of 789 of these documents; the security considerations contained 790 therein are incorporated by reference. 792 5.1 Privacy and Confidentiality 794 For transport confidentiality, TLS (whether HTTP/TLS or the BEEP 795 TLS profile) MUST be supported and SHOULD be used. 797 Since multiple bindings for transport may be implemented, RID 798 implementations MUST support XML encryption [4] to encrypt the SOAP 799 body. Since XML encryption is performed at the IODEF document 800 level, not only is the transport encrypted when a document is 801 sensitive or contains sensitive elements, but the stored document 802 is also encrypted. Note that this encryption applies only to the 803 SOAP body; policy information in the SOAP header should remain 804 unencrypted if it is necessary for the intermediate node to 805 dispatch the message. XML encryption protects the IODEF/RID 806 document in the SOAP body from being viewed by any involved SOAP 807 intermediary node. 809 5.2 Authentication and Identification 811 For transport authentication and identification, TLS (whether 812 HTTP/TLS or the BEEP TLS profile) MUST be supported and SHOULD be 813 used. Each RID consortium SHOULD use a trusted public key 814 infrastructure (PKI) to manage identities for TLS connections. 815 The public/private key pairs used for XML encryption and digital 816 signatures provide authentication for the RID message. The session 817 encryption keys are also used to identify the communicating hosts 818 and provide integrity for the session. 820 Since multiple bindings for transport may be implemented, RID 821 implementations MUST support XML digital signatures [5] to 822 sign the SOAP body; the rationale and implementation here is 823 parallel to that for XML encryption discussed in section 5.1. 825 6. IANA Considerations 827 The IANA is requested to assign TCP ports for RID over SOAP over 828 HTTPS and for RID over SOAP over BEEP. 830 7. Summary 832 SOAP provides the wrapper to facilitate the exchange of RID 833 messages. The IETF and W3C standards provide detailed 834 implementation details for SOAP and SOAP protocol bindings. The 835 use of existing standards assists with development and 836 interoperability between RID systems exchanging IODEF documents for 837 incident handling purposes. HTTP/TLS is the mandatory transport 838 binding for SOAP to be implemented and BEEP with a TLS profile is 839 optional. 841 8. References 843 [RFC2119] "Key Words for Use in RFCs to Indicate Requirement 844 Levels," S. Bradner, March 1997. 846 [RFC2246] "The TLS Protocol Version 1.0," T. Dierks, C. Allen, W. 847 Treese, P. Karlton, A. Freier, P. Kocher, January 1999. 849 [RFC2256] "A Summary of the X.500(96) User Schema for use with 850 LDAPv3," M. Wahl, December 1997. 852 [RFC2459] "Internet Public Key Infrastructure: Part I: X.509 853 Certificate and CRL Profile," R. Housley, W. Ford, W. Polk, and 854 D. Solo, January 1999. 856 [RFC2527] "Internet X.509 Public Key Infrastructure: Certificate 857 Policy and Certification Practices Framework," S. Chokhani, W. 858 Ford, March 1999. 860 [RFC2616] "Hypertext Transfer Protocol - HTTP/1.1," R. Fielding, J. 861 Gettys, J. Mogul, H. Masinter, P. Leach, and T. Berners-Lee, June 862 1999. 864 [RFC3080] "The Blocks Extensible Exchange Protocol Core," M. Rose. 865 March 2001. 867 [RFC3205] "On the Use of HTTP as a Substrate," K. Moore, February 868 2002. (BCP56) 870 [RFC3688] "The IETF XML Registry," M. Mealling, January 2004. 872 [RFCXXXX] "The Incident Object Data Exchange Format Data Model and 873 XML Implementation," J. Meijer, R. Danyliw, and Y. Demchenko, 874 August 2006. 875 http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-08.txt 877 [RFCXXXX] "Incident Handling: Real-time Inter-network Defense," 878 K. Moriarty, August 2006. 879 http://www.ietf.org/internet-drafts/draft-ietf-inch-rid-08.txt 881 [RFCXXXX] "Using the Network Configuration Protocol (NETCONF) Over 882 the Simple Object Access Protocol (SOAP)," T. Goddard, March 2006. 883 http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-08.txt 885 [RFCXXXX] "Using the Simple Object Access Protocol (SOAP) in Blocks 886 Extensible Exchange Protocol (BEEP)," E. O'Tuathail, and M. Rose, 887 May 13, 2005. 888 http://www.ietf.org/internet-drafts/draft-mrose-rfc3288bis-02.txt 890 [1] "Security in a Web Services World: A Proposed Architecture 891 and Roadmap". IBM and Microsoft, April 2002. 892 http://www-106.ibm.com/developerworks/webservices/library/ws-secmap 894 [2] SOAP Version 1.2 Part 0: Primer, W3C Recommendation, 895 http://www.w3c.org/TR/REC-soap12-part0-20030624/, 24 June 2004. 897 [3] SOAP Version 1.2 Part 1:Messaging Framework. W3C 898 Recommendation, 24 June 2004. 899 http://www.w3c.org/TR/REC-soap12-part1-20030624/ 901 [4] XML Encryption Syntax and Processing, W3C Recommendation. 902 T. Imamura, B. Dillaway, and E. Simon, December 2002. 904 [5] XML-Signature Syntax and Processing, W3C Recommendation, 905 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, February 906 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design 908 6.1 Acknowledgments 910 Funding for the RFC Editor function is currently provided by the 911 Internet Society. 913 6.2 Author Information 915 Kathleen M. Moriarty 916 MIT Lincoln Laboratory 917 244 Wood Street 918 Lexington, MA 02420 919 Email: Moriarty@ll.mit.edu 921 Brian H. Trammell 922 CERT Network Situational Awareness 923 4500 Fifth Avenue 924 Pittsburgh, PA 15213 925 Email: bht@cert.org 927 Copyright (C) The IETF Trust (2007). This document is 928 subject to the rights, licenses and restrictions contained in BCP 929 78, and except as set forth therein, the authors retain all their 930 rights. 932 This document and the information contained herein 933 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 934 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 935 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING 936 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 937 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 938 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 939 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 940 PURPOSE. 942 This work was sponsored by the Air Force under Air Force 943 Contract FA8721-05-C-0002. 945 "Opinions, interpretations, conclusions, and recommendations 946 are those of the author and are not necessarily endorsed 947 by the United States Government."