idnits 2.17.1
draft-ietf-mile-implementreport-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (May 17, 2015) is 3265 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC5901' is defined on line 588, but no explicit
reference was found in the text
== Unused Reference: 'RFC5941' is defined on line 591, but no explicit
reference was found in the text
== Unused Reference: 'RFC6545' is defined on line 594, but no explicit
reference was found in the text
== Unused Reference: 'RFC6546' is defined on line 597, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 5070
(Obsoleted by RFC 7970)
Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MILE C. Inacio
3 Internet-Draft CMU
4 Intended status: Informational D. Miyamoto
5 Expires: November 18, 2015 UTokyo
6 May 17, 2015
8 MILE Implementation Report
9 draft-ietf-mile-implementreport-03
11 Abstract
13 This document is a collection of implementation reports from vendors,
14 consortiums, and researchers who have implemented one or more of the
15 standards published from the IETF INCident Handling (INCH) and
16 Management Incident Lightweight Exchange (MILE) working groups.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on November 18, 2015.
35 Copyright Notice
37 Copyright (c) 2015 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 2. Consortiums and Information Sharing and Analysis Centers
54 (ISACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2.1. Anti-Phishing Working Group . . . . . . . . . . . . . . . 3
56 2.2. Advanced Cyber Defence Centre (ACDC) . . . . . . . . . . 3
57 3. Open Source Implementations . . . . . . . . . . . . . . . . . 3
58 3.1. EMC/RSA RID Agent . . . . . . . . . . . . . . . . . . . . 3
59 3.2. NICT IODEF-SCI implementation . . . . . . . . . . . . . . 4
60 3.3. n6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Vendor Implementations . . . . . . . . . . . . . . . . . . . 5
62 4.1. Deep Secure . . . . . . . . . . . . . . . . . . . . . . . 5
63 4.2. IncMan Suite, DFLabs . . . . . . . . . . . . . . . . . . 5
64 4.3. Surevine Proof of Concept . . . . . . . . . . . . . . . . 7
65 4.4. MANTIS Cyber-Intelligence Management Framework . . . . . 7
66 5. Vendors with Planned Support . . . . . . . . . . . . . . . . 8
67 5.1. Threat Central, HP . . . . . . . . . . . . . . . . . . . 8
68 6. Other Implementations . . . . . . . . . . . . . . . . . . . . 8
69 6.1. Collaborative Incident Management System . . . . . . . . 8
70 6.2. Automated Incident Reporting - AirCERT . . . . . . . . . 9
71 6.3. US Department of Energy CyberFed . . . . . . . . . . . . 9
72 6.4. TrendMicro Sharing System . . . . . . . . . . . . . . . . 10
73 7. Implementation Guide . . . . . . . . . . . . . . . . . . . . 10
74 7.1. Code Generators . . . . . . . . . . . . . . . . . . . . . 10
75 7.2. iodeflib . . . . . . . . . . . . . . . . . . . . . . . . 11
76 7.3. iodefpm . . . . . . . . . . . . . . . . . . . . . . . . . 11
77 7.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 12
78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
81 11. Informative References . . . . . . . . . . . . . . . . . . . 13
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
84 1. Introduction
86 This document is a collection of implementation reports from vendors
87 and researchers who have implemented one or more of the standards
88 published from the INCH and MILE working groups. The standards
89 include:
91 o Incident Object Description Exchange Format (IODEF) v1, RFC5070,
93 o Incident Object Description Exchange Format (IODEF) v2,
94 RFC5070-bis,
96 o Extensions to the IODEF-Document Class for Reporting Phishing,
97 RFC5901
99 o Sharing Transaction Fraud Data, RFC5941
101 o IODEF-extension for Structured Cybersecurity Information, RFCXXXX
103 o Real-time Inter-network Defense (RID), RFC6545
105 o Transport of Real-time Inter-network Defense (RID) Messages over
106 HTTP/TLS, RFC6546.
108 o Incident Object Description Exchange Format (IODEF) Extension for
109 Structured Cybersecurity Information, RFC7203
111 The implementation reports included in this document have been
112 provided by the team or product responsible for the implementations
113 of the mentioned RFCs. Additional submissions are welcome and should
114 be sent to the draft editor. A more complete list of
115 implementations, including open source efforts and vendor products,
116 can also be found at the following location:
118 http://siis.realmv6.org/implementations/
120 2. Consortiums and Information Sharing and Analysis Centers (ISACs)
122 2.1. Anti-Phishing Working Group
124 Description of how IODEF is used will be provided in a future
125 revision.
127 2.2. Advanced Cyber Defence Centre (ACDC)
129 Description of how IODEF is used will be provided in a future
130 revision. http://www.botfree.eu/
132 3. Open Source Implementations
134 3.1. EMC/RSA RID Agent
136 The EMC/RSA RID agent is an open source implementation of the
137 Internet Engineering Task Force (IETF) standards for the exchange of
138 incident and indicator data. The code has been released under an MIT
139 license and development will continue with the open source community
140 at the Github site for RSA Intelligence Sharing:
142 https://github.com/RSAIntelShare/RID-Server.git
144 The code implements the RFC6545, Real-time Inter-network Defense
145 (RID) and RFC6546, Transport of RID over HTTP/TLS protocol. The code
146 supports the evolving RFC5070-bis Incident Object Description
147 Exchange Format (IODEF) data model from the work in the IETF working
148 group Managed Incident Lightweight Exchange (MILE).
150 3.2. NICT IODEF-SCI implementation
152 Japan's National Institute of Information and Communications
153 Technology (NICT) Network Security Research Institute implemented
154 open source tools for exchanging, accumulating, and locating IODEF-
155 SCI documents.
157 Three tools are available in GitHub. They assist the exchange of
158 IODEF-SCI documents between parties. IODEF-SCI is the IETF draft
159 that extends IODEF so that IODEF document can embed structured
160 cybersecurity information (SCI). For instance, it can embed MMDEF,
161 CEE, MAEC in XML and CVE identifiers.
163 The three tools are generator, exchanger, and parser. The generator
164 generates IODEF-SCI document or appends an XML to existing IODEF
165 document. The exchanger sends the IODEF document to its
166 correspondent node. The parser receives, parses, and stores the
167 IODEF-SCI document. It also equips the interface that enable users
168 to locate IODEF-SCI documents it has ever received. The code has
169 been released under an MIT license and development will continue
170 here.
172 Note that users can enjoy this software with their own
173 responsibility.
175 Available Online:
177 https://github.com/TakeshiTakahashi/IODEF-SCI
179 3.3. n6
181 n6 is a platform for processing security-related information,
182 developed by NASK, CERT Polska. Its API provides a common and
183 unified way of representing data across the different sources that
184 participate in knowledge management.
186 n6 exposes a REST-ful API over HTTPS with mandatory authentication
187 via TLS client certificates, to ensure confidential and trustworthy
188 communications. Moreover, it uses an event-based data model for
189 representation of all types of security information.
191 Each event is represented as a JSON object with a set of mandatory
192 and optional attributes. It also supports alternative output data
193 formats for keeping compatibility with existing systems - IODEF and
194 CSV - although they lack some of the attributes that may be present
195 in the native JSON format.
197 Available Online:
199 https://github.com/CERT-Polska/n6sdk
201 4. Vendor Implementations
203 4.1. Deep Secure
205 Deep-Secure Guards are built to protect a trusted domain from:
207 o releasing sensitive data that does not meet the organisational
208 security policy
210 o applications receiving badly constructed or malicious data which
211 could exploit a vulnerability (known or unknown)
213 Deep-Secure Guards support HTTPS and XMPP (optimised server to server
214 protocol) transports. The Deep-Secure Guards support transfer of XML
215 based business content by creating a schema to translate the known
216 good content to and from the intermediate format. This means that
217 the Deep-Secure Guards can be used to protect:
219 o IODEF/RID using the HTTPS transport binding (RFC 6546)
221 o IODEF/RID using an XMPP binding
223 o ROLIE using HTTPS transport binding (draft-field-mile-rolie-02)
225 o STIX/TAXII using the HTTPS transport binding
227 Deep-Secure Guards also support the SMTP transport and perform deep
228 content inspection of content including XML attachments. The Mail
229 Guard supports S/MIME and Deep Secure are working on support for the
230 upcoming PLASMA standard which enables information centric policy
231 enforcement of data.
233 4.2. IncMan Suite, DFLabs
235 The Incident Object Description Exchange Format, documented in the
236 RFC 5070, defines a data representation that provides a framework for
237 sharing information commonly exchanged by Computer Security Incident
238 Response Teams (CSIRTs) about computer security incidents. IncMan
239 Suite implements the IODEF standard for exchanging details about
240 incidents, either for exporting and importing activities. This has
241 been introduced to enhance the capabilities of the various CSIRT, to
242 facilitate collaboration and sharing of useful experiences, conveying
243 awareness on specific cases.
245 The IODEF implementation is specified as an XML schema, therefore all
246 data are stored in an xml file: in this file all data of an incident
247 are organized in a hierarchical structure to describe the various
248 objects and their relationships.
250 IncMan Suite relies on IODEF as a transport format, composed by
251 various classes for describing the entities which are part of the
252 incident description: for instance the various relevant timestamps
253 (detect time , start time, end time, report time), the techniques
254 used by the intruders to perpetrate the incident, the impact of the
255 incident, either technical and non-technical (time and monetary) and
256 obviously all systems involved in the incident.
258 4.2.1. Exporting Incidents
260 Each incident defined in IncMan Suite can be exported via a User
261 Interface feature and it will populate an xml document. Due to the
262 nature of the data processed, the IODEF extraction might be
263 considered privacy sensitive by the parties exchanging the
264 information or by those described by it. For this reason, specific
265 care needs to be taken in ensuring the distribution to an appropriate
266 audience or third party, either during the document exchange and
267 subsequent processing.
269 The xml document generated will include description and details of
270 the incident along with all the systems involved and the related
271 information. At this stage it can be distributed for import into a
272 remote system.
274 4.2.2. Importing Incidents
276 IncMan Suite provides a functionality to import incidents stored in
277 files and transported via IODEF-compliant xml documents. The
278 importing process comprises of two steps: firstly, the file is
279 inspected to validate if well formed, then all data are uploaded
280 inside the system.
282 If an incident is already existing in the system with the same
283 incident id, the new one being imported will be created under a new
284 id. This approach prevents from accidentally overwriting existing
285 info or merging inconsistent data.
287 IncMan Suite includes also a feature to upload incidents from emails.
289 The incident, described in xml format, can be stored directly into
290 the body of the email message or transported as an attachment of the
291 email. At regular intervals, customizable by the user, IncMan Suite
292 monitors for incoming emails, filtered by a configurable white-list
293 and black-list mechanism on the sender's email account, then a parser
294 processes the received email and a new incident is created
295 automatically, after having validated the email body or the
296 attachment to ensure it is a well formed format.
298 4.3. Surevine Proof of Concept
300 XMPP is enhanced and extended through the XMPP Extension Protocols
301 (or XEPs). XEP-0268 (http://xmpp.org/extensions/xep-0268.html)
302 describes incident management (using IODEF) of the XMPP network
303 itself, effectively supporting self-healing the XMPP network. In
304 order to more generically cover incident management of a network and
305 over a network, XEP-0268 requires some updates. We are working on
306 these changes together with a new XEP that supports "social
307 networking" over XMPP, enhancing the publish-and-subscribe XEP (XEP-
308 0060). This now allows nodes to publish any type of content and
309 subscribe to and therefore receive the content. XEP-0268 will be
310 used to describe IODEF content. We now have an alpha version of the
311 server-side software and client-side software required to demonstrate
312 the "social networking" capability and are currently enhancing this
313 to support Cyber Incident management in real-time.
315 4.4. MANTIS Cyber-Intelligence Management Framework
317 MANTIS provides an example implementation of a framework for managing
318 cyber threat intelligence expressed in standards such as STIX, CybOX,
319 IODEF, etc. The aims of providing such an example implementation
320 are:
322 o To aide discussions about emerging standards such as STIX, CybOX
323 et al. with respect to questions regarding tooling: how would a
324 certain aspect be implemented, how do changes affect an
325 implementation? Such discussions become much easier and have a
326 better basis if they can be lead in the context of example tooling
327 that is known to the community.
329 o To lower the entrance barrier for organizations and teams (esp.
330 CERT teams) in using emerging standards for cyber-threat
331 intelligence management and exchange.
333 o To provide a platform on the basis of which research and
334 community-driven development in the area of cyber-threat
335 intelligence management can occur.
337 5. Vendors with Planned Support
339 5.1. Threat Central, HP
341 HP has developed HP Threat Central, a security intelligence platform
342 that enables automated, real-time collaboration between organizations
343 to combat today's increasingly sophisticated cyber attacks. One way
344 automated sharing of threat indicators is achieved is through close
345 integration with the HP ArcSight SIEM for automated upload and
346 consumption of information from the Threat Central Server. In
347 addition HP Threat Central supports open standards for sharing threat
348 information so that participants who do not use HP Security Products
349 can participate in the sharing ecosystem. General availability of
350 Threat Central will be in 2014. It is planned that future versions
351 also support IODEF for the automated upload and download of threat
352 information.
354 6. Other Implementations
356 6.1. Collaborative Incident Management System
358 Collaborative Incident Management System (CIMS) is a proof-of-concept
359 system for collaborative incident handling and for the sharing of
360 cyber defence situational awareness information between the
361 participants, developed for the Cyber Coalition 2013 (CC13) exercise
362 organized by NATO. CIMS was implemented based on Request Tracker
363 (RT), an open source software widely used for handling incident
364 response by many CERTs and CSIRTs.
366 One of the functionality implemented in CIMS was the ability to
367 import and export IODEF messages in the body of emails. The intent
368 was to verify the suitability of IODEF to achieve the objective of
369 collaborative incident handling. The customized version of RT could
370 be configured to send an email message containing an IODEF message
371 whenever an incident ticket was created, modified or deleted. These
372 IODEF messages would then be imported into other incident handling
373 systems in order to allow participating CSIRTs to use their usual
374 means for incident handling, while still interacting with those using
375 the proof-of-concept CIMS. Having an IODEF message generated for
376 every change made to the incident information in RT (and for the
377 system to allow incoming IODEF email messages to be associated to an
378 existing incident) would in some way allow all participating CSIRTs
379 to actually work on a "common incident ticket", at least at the
380 conceptual level. Of particular importance was the ability for users
381 to exchange information between each other concerning actions taken
382 in the handling of a particular incident, thus creating a sort of
383 common action log, as well as requesting/tasking others to provide
384 information or perform specified action and correlating received
385 responses to the original request or tasking. As well, a specific
386 "profile" was developed to identify a subset of the IODEF classes
387 that would be used during the exercise, in an attempt to channel all
388 users into a common usage pattern of the otherwise flexible IODEF
389 standard.
391 6.2. Automated Incident Reporting - AirCERT
393 AirCERT was implemented by CERT/CC of Carnegie Mellon's Software
394 Engineering Institute CERT divison. AirCERT was designed to be an
395 Internet-scalable distributed system for sharing security event data.
396 The AirCERT system was designed to be an automated collector of flow
397 and IDS alerts. AirCERT would collect that information into a
398 relational database and be able to share reporting using IODEF and
399 IDMEF. AirCERT additionally used SNML to exchange information about
400 the network. AirCERT was implemented in a combination of C and perl
401 modules and included periodic graphing capabilities leveraging
402 RRDTool.
404 AirCERT was intended for large scale distributed deployment and
405 eventually the ability to sanitize data to be shared across
406 administrative domains. The architecture was desgined to allow
407 collection of data at a per site basis and to allow each site to
408 create data sharing based on its own particular trust relationships.
410 6.3. US Department of Energy CyberFed
412 The CyberFed system was implemented and deployed by Argonne National
413 Laboratory to automate the detection and response of attack activity
414 against Department of Energy (DoE) computer networks. CyberFed
415 automates the collection of network alerting activity from various
416 perimeter network defenses and logs those events into its database.
417 CyberFed then automatically converts that information into blocking
418 information transmitted to all participants. The original
419 implementation used IODef messages wrapped in an XML extension to
420 manage a large array of indicators. The CyberFed system was not
421 designed to describe a particular incident as much as to describe a
422 set of current network blocking indicators that can be generated and
423 deployed machine-to-machine.
425 CyberFed is primarily implemented in Perl. Included as part of the
426 CyberFed system are scripts which interact with a large number of
427 firewalls, IDS/IPS devices, DNS systems, and proxies which operate to
428 implement both the automated collection of events as well as the
429 automated deployment of blacking.
431 Currently CyberFed supports multiple exchange formats including IODef
432 and STIX. OpenIOC is also a potential exchange format that DoE is
433 considering.
435 6.4. TrendMicro Sharing System
437 More information to come.
439 7. Implementation Guide
441 The section aims at sharing the tips for development of IODEF-capable
442 systems.
444 7.1. Code Generators
446 For implementing IODEF-capable systems, it is feasible to employ code
447 generators for XML Schema Document (XSD). The generators are used to
448 save development costs since they automatically create useful
449 libraries for accessing XML attributes, composing messages, and/or
450 validating XML objects. The IODEF XSD was defined in section 8 of
451 RFC 5070, and is availabe at http://www.iana.org/assignments/xml-
452 registry/schema/iodef-1.0.xsd.
454 However, there still remains some problem. Due to the complexity of
455 IODEF XSD, some code generators could not generate from the XSD file.
456 The tested code generators were as follows.
458 o XML::Pastor [XSD:Perl] (Perl)
460 o RXSD [XSD:Ruby] (Ruby)
462 o PyXB [XSD:Python] (Python)
464 o JAXB [XSD:Java] (Java)
466 o CodeSynthesis XSD [XSD:Cxx] (C++)
468 o Xsd.exe [XSD:CS] (C#)
470 For instance, we have used XML::Pastor, but it could not properly
471 understand its schema due to the complexity of IODEF XSD. The same
472 applies to RXSD and JAXB. Only PyXB, CodeSynthesis XSD and Xsd.exe
473 were able to understand the schema.
475 There is no recommended workaround, however, a double conversion of
476 XSD file is one option to go through the situation; it means XSD is
477 serialized to XML, and it is again converted to XSD. The resultant
478 XSD was process-able by the all tools above.
480 It should be noted that IODEF uses '-' (hyphen) symbols in its
481 classes or attributes, listed as follows.
483 o IODEF-Document Class; it is the top level class in the IODEF data
484 model described in section 3.1 of [RFC5070].
486 o The vlan-name and vlan-num Attribute; according to section 3.16.2
487 of [RFC5070], they are the name and number of Virtual LAN and are
488 the attributes for Address class.
490 o Extending the Enumerated Values of Attribute; according to section
491 5.1 of [RFC5070], it is a extension techniques to add new
492 enumerated values to an attribute, and has a prefix of "ext-",
493 e.g., ext-value, ext-category, ext-type, and so on.
495 According to the language specification, many programing language
496 prohibit to contain '-' symbols in the name of class. The code
497 generators must replace or remove '-' when building the librarlies.
498 They should have the name space to restore '-' when outputting the
499 XML along with IODEF XSD.
501 7.2. iodeflib
503 iodeflib is an open source implementation written in Python. This
504 provides a simple but powerful APIs to create, parse and edit IODEF
505 documents. It was designed in order to keep its interface as simple
506 as possible, whereas generated libraries tend to inherit the
507 complexity of IODEF XSD. As well as the interface, iodeflib involves
508 functions of hiding some unnecessarily nested structures of the IODEF
509 schema, and adding more convenient shortcuts.
511 This tool is available through the following link:
513 http://www.decalage.info/python/iodeflib
515 7.3. iodefpm
517 IODEF.pm is an open source implementation written in Perl. This also
518 provides a simple interface for creating and parsing IODEF documents,
519 in order to facilitate the translation of the a key-value based
520 format to the IODEF representation. The module contains a generic
521 XML DTD parser and includes a simplified node based representation of
522 the IODEF DTD. It can hence easily be upgraded or extended to
523 support new XML nodes or other DTDs.
525 This tool is available through the following link:
527 http://search.cpan.org/~saxjazman/
529 7.4. Usability
531 Here notes some tips to avoid problems.
533 o IODEF has category attribute for NodeRole class. Though various
534 categories are described, they are not enough. For example, in
535 the case of web mail servers, you should choose either "www" or
536 "mail". One suggestion is selecting "mail" as the category
537 attribute and adding "www" for another attirbute.
539 o The numbering of Incident ID needs to be considered. Otherwise,
540 information, such as the number of incidents within certain period
541 could be observed by document receivers. For instance, we could
542 randomize the assignment of the numbers.
544 8. Acknowledgements
546 The MILE Implementation report has been compiled through the
547 submissions of implementers of INCH and MILE working group standards.
548 A special note of thanks to the following contributors:
550 John Atherton, Surevine
552 Humphrey Browning, Deep-Secure
554 Dario Forte, DFLabs
556 Tomas Sander, HP
558 Ulrich Seldeslachts, ACDC
560 Takeshi Takahashi, National Institute of Information and
561 Communications Technology Network Security Research Institute
563 Kathleen Moriarty, EMC
565 Bernd Grobauer, Siemens
567 Dandurand Luc, NATO
569 Pawel Pawlinski, NASK
571 9. IANA Considerations
573 This memo includes no request to IANA.
575 10. Security Considerations
577 This draft provides a summary of implementation reports from
578 researchers and vendors who have implemented RFCs and drafts from the
579 MILE and INCH working groups. There are no security considerations
580 added in this draft because of the nature of the document.
582 11. Informative References
584 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
585 Object Description Exchange Format", RFC 5070, December
586 2007.
588 [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
589 Class for Reporting Phishing", RFC 5901, July 2010.
591 [RFC5941] M'Raihi, D., Boeyen, S., Grandcolas, M., and S. Bajaj,
592 "Sharing Transaction Fraud Data", RFC 5941, August 2010.
594 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC
595 6545, April 2012.
597 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
598 Defense (RID) Messages over HTTP/TLS", RFC 6546, April
599 2012.
601 [XSD:CS] Microsoft, "XML Schema Definition Tool (Xsd.exe)",
602 .
604 [XSD:Cxx] CodeSynthesis, "XSD - XML Data Binding for C++",
605 .
607 [XSD:Java]
608 Project Kenai, "JAXB Reference Implementation",
609 .
611 [XSD:Perl]
612 Ulsoy, A., "XML::Pastor",
613 .
615 [XSD:Python]
616 Bigot, P., "PyXB: Python XML Schema Bindings",
617 .
619 [XSD:Ruby]
620 Morsi, M., "RXSD - XSD / Ruby Translator",
621 .
623 Authors' Addresses
625 Chris Inacio
626 Carnegie Mellon University
627 4500 5th Ave., SEI 4108
628 Pittsburgh, PA 15213
629 US
631 Email: inacio@andrew.cmu.edu
633 Daisuke Miyamoto
634 The Univerisity of Tokyo
635 2-11-16 Yayoi, Bunkyo
636 Tokyo 113-8658
637 JP
639 Email: daisu-mi@nc.u-tokyo.ac.jp