idnits 2.17.1
draft-ietf-inch-rid-soap-02.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.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 742.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** 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
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 (June 15, 2006) is 6525 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 640, but no explicit
reference was found in the text
== Unused Reference: 'RFC2246' is defined on line 643, but no explicit
reference was found in the text
== Unused Reference: 'RFC2256' is defined on line 646, but no explicit
reference was found in the text
== Unused Reference: 'RFC2459' is defined on line 649, but no explicit
reference was found in the text
== Unused Reference: 'RFC2527' is defined on line 653, but no explicit
reference was found in the text
== Unused Reference: 'RFC2616' is defined on line 657, but no explicit
reference was found in the text
== Unused Reference: 'RFC3080' is defined on line 661, but no explicit
reference was found in the text
== Unused Reference: 'RFC3205' is defined on line 664, but no explicit
reference was found in the text
== Unused Reference: 'RFC3688' is defined on line 667, but no explicit
reference was found in the text
== Unused Reference: '1' is defined on line 692, but no explicit reference
was found in the text
== Unused Reference: '2' is defined on line 696, but no explicit reference
was found in the text
== Unused Reference: '3' is defined on line 699, 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 (~~), 17 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-ietf-inch-rid-soap-02.txt MIT Lincoln Laboratory
3 Expires: December 15, 2006 June 15, 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 ................................ 13
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 Attack
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 Attack
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
336 csirt-for-our-domain@ourdomain
337
338
339 Constituency-contact for 10.1.1.2
340
341 Constituency-contact@10.1.1.2
342
343
344
345
346 CSIRT-FOR-OUR-DOMAIN#207-1
347
348
349 Notification sent to next upstream NP closer to
350 10.1.1.2
351 2001-09-14T08:19:01+00:00
352
353
354
355
356
357
358 38765
359
360
361 10.1.1.2
362
363
364
365
366
367 80
368
369
370 192.168.1.2
371
372
373
374
376 Rate limit traffic close to source
377
378
379
380
381
382 450000522ad90000ff06c41fc0a801020a010102976d0050103e020810
383 d94a1350021000ad6700005468616e6b20796f7520666f722063617265
384 66756c6c792072656164696e672074686973205246432e0a
386
387 The IPv4 packet included
388 was used in the described attack
389
390
391
392
393
394
395
396
397
399 4.2 Example InvestigationRequest Message
401 This InvestigationRequest is identical to the InvestigationRequest
402 example in section 4.5.2.1 of the RID specification and would be
403 sent in a situation similar to that of example 4.1, when the source
404 of the attack is known.
406
408
409
412
413 Investigation
414 PeertoPeer
415 SourceOfIncident
416
417
418 172.25.1.33
419
420
421 Attack
422
423 CERT-FOR-OUR-DOMAIN#208-1
424
425
426
427
428
429
432
433 Investigation
434 PeertoPeer
435 SourceOfIncident
436
437
438 172.25.1.33
439
440
441 Attack
442
443 CERT-FOR-OUR-DOMAIN#208-1
444
445
446
447 CSIRT-FOR-OUR-DOMAIN
448 CSIRT123
449 csirt-for-our-domain@ourdomain
450
451 172.17.1.2
452
453
454
455
456 CSIRT-FOR-UPSTREAM-NP
457 CSIRT345
458 csirt-for-upstream-np@ourdomain
459
460 172.20.1.2
461
462
463
464
465
466
467
469 4.3 Example Report
471 This Report is identical to the Report example in section 4.5.3.1
472 of the RID specification.
474
476
477
480
481 Report
482 PeertoPeer
483 RIDSystem
484
485 172.17.1.2
486
487
488 Attack
489
490 CERT-FOR-OUR-DOMAIN#209-1
491
492
493
494
495
496
499
500 Report
501 PeertoPeer
502 RIDSystem
503
504 172.17.1.2
505
506
507 Attack
508
509 CERT-FOR-OUR-DOMAIN#209-1
510
511
512
513 CSIRT-FOR-OUR-DOMAIN
514 CSIRT123
515 csirt-for-our-domain@ourdomain
516
517 172.20.1.2
518
519
520
521
522 CSIRT-FOR-REQUESTING-NP
523 CSIRT345
524 csirt-for-requesting-np@ourdomain
525
526 172.17.1.2
527
528
529
530
531
532
533
535 4.4 Example IncidentQuery
537 This IncidentQuery is identical to the IncidentQuery example in
538 Section 4.5.4.1 of the RID specification.
540
542
543
546
547 IncidentQuery
548 PeertoPeer
549 RIDSystem
550
551 172.17.1.2
552
553
554 Attack
555
556 CERT-FOR-OUR-DOMAIN#209-1
557
558
559
560 CSIRT-FOR-OUR-DOMAIN
561 CSIRT123
562 csirt-for-our-domain@ourdomain
563
564 172.20.1.2
565
566
567
568
569 CSIRT-FOR-REQUESTING-NP
570 CSIRT345
571 csirt-for-requesting-np@ourdomain
572
573 172.17.1.2
574
575
576
577
578
579
580
582 5. Security Considerations
584 All security considerations of related documents MUST be
585 considered, including those in the following documents:
586 Requirements for the Format for INcident information Exchange
587 (FINE) [RFCXXXX], the Incident Data Exchange Format Data Model and
588 XML Implementation (IODEF), [RFCXXXX], and Incident Handling:
589 Real-time Inter-network Defense (RID) [RFCXXXX]. The SOAP wrappers
590 described herein are built upon the foundation of these documents;
591 the security considerations contained therein are incorporated by
592 reference.
594 5.1 Privacy and Confidentiality
596 For transport confidentiality, TLS (whether HTTP/TLS or the BEEP
597 TLS profile) MUST be supported and SHOULD be used.
599 Since multiple bindings for transport may be implemented, RID
600 implementations MUST support XML encryption [4] to encrypt the SOAP
601 body. Since XML encryption is performed at the IODEF document
602 level, not only is the transport encrypted when a document is
603 sensitive or contains sensitive elements, but the stored document
604 is also encrypted. Note that this encryption applies only to the
605 SOAP body; policy information in the SOAP header should remain
606 unencrypted if it is necessary for the intermediate node to
607 dispatch the message. XML encryption protects the IODEF document
608 in the SOAP body from being viewed by any involved SOAP
609 intermediary node.
611 5.2 Authentication and Identification
613 For transport authentication and identification, TLS (whether
614 HTTP/TLS or the BEEP TLS profile) MUST be supported and SHOULD be
615 used. Each RID consortium SHOULD use a trusted public key
616 infrastructure (PKI) to manage identities for TLS connections.
618 Since multiple bindings for transport may be implemented, RID
619 implementations MUST support XML digital signatures [5] to
620 sign the SOAP body; the rationale and implementation here is
621 parallel to that for XML Encryption discussed in section 5.1.
623 6. IANA Considerations
625 The IANA is requested to assign TCP ports for RID over SOAP over
626 HTTPS and for RID over SOAP over BEEP.
628 7. Summary
630 SOAP provides the wrapper to facilitate the exchange of RID
631 messages. The IETF and W3C standards provide detailed
632 implementation details for SOAP and SOAP protocol bindings. The
633 use of existing standards assists with development and
634 interoperability between RID systems exchanging IODEF documents for
635 incident-handling purposes. HTTPS is the mandatory transport
636 binding for SOAP to be implemented and BEEP is optional.
638 8. References
640 [RFC2119] "Key Words for Use in RFCs to Indicate Requirement
641 Levels," S. Bradner, March 1997.
643 [RFC2246] "The TLS Protocol Version 1.0," T. Dierks, C. Allen, W.
644 Treese, P. Karlton, A. Freier, P. Kocher, January 1999.
646 [RFC2256] "A Summary of the X.500(96) User Schema for use with
647 LDAPv3," M. Wahl, December 1997.
649 [RFC2459] "Internet Public Key Infrastructure: Part I: X.509
650 Certificate and CRL Profile," R. Housley, W. Ford, W. Polk, and
651 D. Solo, January 1999.
653 [RFC2527] "Internet X.509 Public Key Infrastructure: Certificate
654 Policy and Certification Practices Framework," S. Chokhani, W.
655 Ford, March 1999.
657 [RFC2616] "Hypertext Transfer Protocol - HTTP/1.1," R. Fielding, J.
658 Gettys, J. Mogul, H. Masinter, P. Leach, and T. Berners-Lee, June
659 1999.
661 [RFC3080] "The Blocks Extensible Exchange Protocol Core," M. Rose.
662 March 2001.
664 [RFC3205] "On the Use of HTTP as a Substrate," K. Moore, February
665 2002. (BCP56)
667 [RFC3688] "The IETF XML Registry," M. Mealling, January 2004.
669 [RFCXXXX] "The Incident Object Data Exchange Format Data Model and
670 XML Implementation," J. Meijer, R. Danyliw, and Y. Demchenko,
671 November 2005.
672 http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-05.txt
674 [RFCXXXX] "Requirements for the Format for INcident information
675 Exchange," Y. Demchenko, R. Danyliw, and G. Keeni, February 2006.
676 http://www.ietf.org/internet-drafts/draft-ietf-inch-requirements-
677 07.txt
679 [RFCXXXX] "Incident Handling: Real-time Inter-network Defense,"
680 K. Moriarty, April 2006.
681 http://www.ietf.org/internet-drafts/draft-ietf-inch-rid-06.txt
683 [RFCXXXX] "Using the Network Configuration Protocol (NETCONF) Over
684 the Simple Object Access Protocol (SOAP)," T. Goddard, March 2006.
685 http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-08.txt
687 [RFCXXXX] "Using the Simple Object Access Protocol (SOAP) in Blocks
688 Extensible Exchange Protocol (BEEP)," E. O'Tuathail, and M. Rose,
689 May 13, 2005.
690 http://www.ietf.org/internet-drafts/draft-mrose-rfc3288bis-02.txt
692 [1] "Security in a Web Services World: A Proposed Architecture
693 and Roadmap". IBM and Microsoft, April 2002.
694 http://www-106.ibm.com/developerworks/webservices/library/ws-secmap
696 [2] SOAP Version 1.2 Part 0: Primer, W3C Recommendation,
697 http://www.w3c.org/TR/REC-soap12-part0-20030624/, 24 June 2004.
699 [3] SOAP Version 1.2 Part 1:Messaging Framework. W3C
700 Recommendation, 24 June 2004.
701 http://www.w3c.org/TR/REC-soap12-part1-20030624/
703 [4] XML Encryption Syntax and Processing, W3C Recommendation.
704 T. Imamura, B. Dillaway, and E. Simon, December 2002.
706 [5] XML-Signature Syntax and Processing, W3C Recommendation,
707 M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon, February
708 2002. http://www.w3.org/TR/xmldsig-core/#sec-Design
710 6.1 Acknowledgments
712 Funding for the RFC Editor function is currently provided by the
713 Internet Society.
715 6.2 Author Information
717 Kathleen M. Moriarty
718 MIT Lincoln Laboratory
719 244 Wood Street
720 Lexington, MA 02420
721 Phone: 781-981-5500
722 Email: Moriarty@ll.mit.edu
724 Brian H. Trammell
725 CERT Network Situational Awareness
726 4500 Fifth Avenue
727 Pittsburgh, PA 15213
728 Email: bht@cert.org
730 Copyright (C) The Internet Society (2006). This document is
731 subject to the rights, licenses and restrictions contained in BCP
732 78, and except as set forth therein, the authors retain all their
733 rights.
735 This document and the information contained herein
736 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
737 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
738 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
739 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
740 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
741 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
742 OR FITNESS FOR A PARTICULAR PURPOSE.
744 This work was sponsored by the Air Force under Air Force
745 Contract FA8721-05-C-0002.
747 "Opinions, interpretations, conclusions, and recommendations
748 are those of the author and are not necessarily endorsed
749 by the United States Government."