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