draft-ietf-mile-rfc6045-bis-06.txt   draft-ietf-mile-rfc6045-bis-07.txt 
MILE Working Group K. Moriarty MILE Working Group K. Moriarty
Internet-Draft EMC Internet-Draft EMC
Obsoletes: 6045 (if approved) January 16, 2012 Obsoletes: 6045 (if approved) January 20, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: July 19, 2012 Expires: July 23, 2012
Real-time Inter-network Defense (RID) Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-06.txt draft-ietf-mile-rfc6045-bis-07.txt
Abstract Abstract
Security incidents, such as system compromises, worms, viruses, Security incidents, such as system compromises, worms, viruses,
phishing incidents, and denial of service, typically result in the phishing incidents, and denial of service, typically result in the
loss of service, data, and resources both human and system. Service loss of service, data, and resources both human and system. Service
providers and Computer Security Incident Response Teams need to be providers and Computer Security Incident Response Teams need to be
equipped and ready to assist in communicating and tracing security equipped and ready to assist in communicating and tracing security
incidents with tools and procedures in place before the occurrence of incidents with tools and procedures in place before the occurrence of
an attack. Real-time Inter-network Defense (RID) outlines a an attack. Real-time Inter-network Defense (RID) outlines a
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2012. This Internet-Draft will expire on July 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Normative and Informative . . . . . . . . . . . . . . . . 7 1.1. Changes from RFC6045 . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Normative and Informative . . . . . . . . . . . . . . . . 7
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 7 2. Characteristics of Incidents . . . . . . . . . . . . . . . . . 7
3. Communication between CSIRTs and Service Providers . . . . . . 9 3. Communication between CSIRTs and Service Providers . . . . . . 9
3.1. Inter-service Provider RID Messaging . . . . . . . . . . . 11 3.1. Inter-service Provider RID Messaging . . . . . . . . . . . 11
3.2. RID Communication Topology . . . . . . . . . . . . . . . . 12 3.2. RID Communication Topology . . . . . . . . . . . . . . . . 13
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 14 4.1. RID Data Types . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 14 4.2. RID Message Types . . . . . . . . . . . . . . . . . . . . 14
5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15 5. IODEF-RID Schema . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17 5.1. RIDPolicy Class . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. ReportSchema . . . . . . . . . . . . . . . . . . . . . 23 5.1.1. ReportSchema . . . . . . . . . . . . . . . . . . . . . 23
5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 26 5.2. RequestStatus . . . . . . . . . . . . . . . . . . . . . . 26
5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 28 5.3. IncidentSource . . . . . . . . . . . . . . . . . . . . . . 28
5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 29 5.4. RID Name Spaces . . . . . . . . . . . . . . . . . . . . . 29
5.5. Including IODEF or other XML Documents . . . . . . . . . . 29 5.5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.1. Including XML Schema Documents in RID . . . . . . . . 30 5.6. Including IODEF or other XML Documents . . . . . . . . . . 29
6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.6.1. Including XML Documents in RID . . . . . . . . . . . . 30
6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 33 6.2. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 33
6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 38 7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 39
7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 39 7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 40
7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 42 7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 42
7.1.2. Acknowledgement Message Example . . . . . . . . . . . 45 7.1.2. Acknowledgement Message Example . . . . . . . . . . . 46
7.1.3. Result Message Example . . . . . . . . . . . . . . . . 46 7.1.3. Result Message Example . . . . . . . . . . . . . . . . 47
7.2. Investigation Request Communication Flow . . . . . . . . . 49 7.2. Investigation Request Communication Flow . . . . . . . . . 50
7.2.1. Investigation Request Example . . . . . . . . . . . . 50 7.2.1. Investigation Request Example . . . . . . . . . . . . 51
7.2.2. Acknowledgement Message Example . . . . . . . . . . . 52 7.2.2. Acknowledgement Message Example . . . . . . . . . . . 53
7.3. Report Communication Flow . . . . . . . . . . . . . . . . 54
7.3. Report Communication Flow . . . . . . . . . . . . . . . . 53 7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 54
7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 53 7.4. Query Communication Flow . . . . . . . . . . . . . . . . . 56
7.4. Query Communication Flow . . . . . . . . . . . . . . . . . 55 7.4.1. Query Example . . . . . . . . . . . . . . . . . . . . 57
7.4.1. Query Example . . . . . . . . . . . . . . . . . . . . 56 8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 58
8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 57 9. Security Requirements . . . . . . . . . . . . . . . . . . . . 62
9. Security Requirements . . . . . . . . . . . . . . . . . . . . 61 9.1. XML Digital Signatures and Encryption . . . . . . . . . . 62
9.1. XML Digital Signatures and Encryption . . . . . . . . . . 61 9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 66
9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 65 9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 67
9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 66 9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 68
9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 67 9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 69
9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 68 9.4. Consortiums and Public Key Infrastructures . . . . . . . . 70
9.4. Consortiums and Public Key Infrastructures . . . . . . . . 69 9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 71
9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 70 9.6. Sharing Profiles and Policies . . . . . . . . . . . . . . 76
10. Security Considerations . . . . . . . . . . . . . . . . . . . 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 76
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 11. Internationalization Issues . . . . . . . . . . . . . . . . . 77
12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.1. Normative References . . . . . . . . . . . . . . . . . . . 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.2. Informative References . . . . . . . . . . . . . . . . . . 79 14.1. Normative References . . . . . . . . . . . . . . . . . . . 80
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80 14.2. Informative References . . . . . . . . . . . . . . . . . . 82
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 83
1. Introduction 1. Introduction
Organizations require help from other parties to identify incidents, Organizations require help from other parties to identify incidents,
mitigate malicious activity targeting their computing resources, and mitigate malicious activity targeting their computing resources, and
to gain insight into potential threats through the sharing of to gain insight into potential threats through the sharing of
information. This coordination might entail working with a service information. This coordination might entail working with a service
provider (SP) to filter attack traffic, working with a SP to resolve provider (SP) to filter attack traffic, working with a SP to resolve
a configuration issue unintentionally causing problems, contacting a a configuration issue unintentionally causing problems, contacting a
remote site to take down a bot- network, or sharing watch-lists of remote site to take down a bot- network, or sharing watch-lists of
skipping to change at page 5, line 31 skipping to change at page 5, line 31
achieve a necessary level of security. achieve a necessary level of security.
Coordinating with other CSIRTs is not strictly a technical problem. Coordinating with other CSIRTs is not strictly a technical problem.
There are numerous procedural, trust, and legal considerations that There are numerous procedural, trust, and legal considerations that
might prevent an organization from sharing information. RID provides might prevent an organization from sharing information. RID provides
information and options that can be used by organizations who must information and options that can be used by organizations who must
then apply their own policies for sharing information. Organizations then apply their own policies for sharing information. Organizations
must develop policies and procedures for the use of the RID protocol must develop policies and procedures for the use of the RID protocol
and IODEF. and IODEF.
1.1. Changes from RFC6045
This document contains the following changes with respect to its This document contains the following changes with respect to its
predecessor [RFC6045]: predecessor [RFC6045]:
o This document is on standards track while [RFC6045] was o This document is on standards track while [RFC6045] was
informational, but now it is historic. informational, but now it is historic.
o This document, when published, obsoletes [RFC6045] and moves it to o This document, when published, obsoletes [RFC6045] and moves it to
Historic status. Historic status.
o This document refers to the updated RID transport specification o This document refers to the updated RID transport specification
skipping to change at page 6, line 21 skipping to change at page 6, line 23
* 3.2. Superset of Packet Information for Traces. * 3.2. Superset of Packet Information for Traces.
o An option for a star topology has been included in an o An option for a star topology has been included in an
informational section to meet current use case requirements of informational section to meet current use case requirements of
those who provide reports on incident information. those who provide reports on incident information.
o The schema version was incremented. The schema has changed to o The schema version was incremented. The schema has changed to
include IODEF [RFC5070] enveloped in RID in the RIDPolicy class include IODEF [RFC5070] enveloped in RID in the RIDPolicy class
using the new ReportSchema class, to include reported errata, to using the new ReportSchema class, to include reported errata, to
include an additional enumeration in the RIDPolicy class for include additional enumerations in the Justification attribute, to
'LawEnforcement', to include additional enumerations in the remove the AcrossNationalBoundaries region enumeration, to add the
Justification attribute, and to change the name of the DataWithHandingRequirements enumeration in TrafficTypes, and to
RequestAuthorization MsgType to Acknowledgement. Additional text change the name of the RequestAuthorization MsgType to
has been provided to clarify definitions of enumerated values for Acknowledgement. Additional text has been provided to clarify
some attributes. The RequestAuthorization name was replaced with definitions of enumerated values for some attributes. The
Acknowledgement to more accurately represent the function of that RequestAuthorization name was replaced with Acknowledgement to
message type. Text was clarified to note the possible use of this more accurately represent the function of that message type. Text
message in response to Query and Report messages. The attributes was clarified to note the possible use of this message in response
were fixed in the schema to add 'lang' at the RID class level for to Query and Report messages. The attributes were fixed in the
language support. schema to add 'lang' at the RID class level for language support.
o The TraceRequest and Investigation messages have been collapsed o The TraceRequest and Investigation messages have been collapsed
into a single message with the requirement to set the MsgType into a single message with the requirement to set the MsgType
according to the functionality required for automation. The according to the functionality required for automation. The
message descriptions were identical with with exception of the message descriptions were identical with with exception of the
MsgType, which remains an exception depending on the desired MsgType, which remains an exception depending on the desired
function. Since both of the enumerations for MsgType are each a function. Since both of the enumerations for MsgType are each a
Request, 'Investigation' is now 'InvestigationRequest'. Content Request, 'Investigation' is now 'InvestigationRequest'. Content
may vary within the IODEF document for the type of Request may vary within the IODEF document for the type of Request
specified. specified.
o The IncidentQuery message description name and MsgType enumeration o The IncidentQuery message description name and MsgType enumeration
value in the schema has been changed to the more generic name of value in the schema has been changed to the more generic name of
'Query'. 'Query'.
o Guidance has improved to ensure consistent implementations and use o Guidance has improved to ensure consistent implementations and use
of XML encryption to provide confidentiality based on data of XML encryption to provide confidentiality based on data
markers, specifically the iodef:restriction attribute in the IODEF markers, specifically the iodef:restriction attribute in the IODEF
and IODEF-RID schemas. The attribute may also be present in IODEF and IODEF-RID schemas. The attribute may also be present in IODEF
extension schemas, where the guidance also applies. extension schemas, where the guidance also applies. Additional
guidance and restrictions have been added for XML requirements.
o All of the normative text from the Security Considerations Section o All of the normative text from the Security Considerations Section
has been moved to a new Section, Security Requirements. has been moved to a new Section, Security Requirements.
o The order in which the RID Schema is presented in Section 5 has o The order in which the RID Schema is presented in Section 5 has
been changed to match the order in the IODEF-RID schema. been changed to match the order in the IODEF-RID schema.
o Additional text has been provided to explain the content and o Additional text has been provided to explain the content and
interactions between entities in the examples. interactions between entities in the examples.
o Additional references have been provided to improve o Additional references have been provided to improve
interoperability with stricter guidance on the use of XML digital interoperability with stricter guidance on the use of XML digital
signatures and encryption. signatures and encryption.
1.1. Normative and Informative 1.2. Normative and Informative
Section 1, 2, 3, and 12 provide helpful background information and Section 1, 2, 3, and 12 provide helpful background information and
considerations. RID systems participating in a consortium are considerations. RID systems participating in a consortium are
REQUIRED to fully implement sections 4, 5, 6, 7, 8, 9, 10, and 11 to REQUIRED to fully implement sections 4, 5, 6, 7, 8, 9, 10, and 11 to
prevent interoperability concerns. prevent interoperability concerns.
1.2. Terminology 1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Characteristics of Incidents 2. Characteristics of Incidents
An incident may be defined as a benign configuration issue, IT An incident may be defined as a benign configuration issue, IT
incident, an infraction to a service level agreement (SLA), system incident, an infraction to a service level agreement (SLA), system
compromise, a worm or Trojan infection, or a single- or multiple- compromise, a worm or Trojan infection, or a single- or multiple-
skipping to change at page 11, line 6 skipping to change at page 11, line 10
negotiated in a contract as part of a value-added service or through negotiated in a contract as part of a value-added service or through
a service level agreement (SLA). Further discussion is beyond the a service level agreement (SLA). Further discussion is beyond the
scope of this document and may be more appropriately handled in scope of this document and may be more appropriately handled in
peering or service level agreements. peering or service level agreements.
Procedures for incident handling need to be established and well Procedures for incident handling need to be established and well
known by anyone that may be involved in incident response. The known by anyone that may be involved in incident response. The
procedures should also contain contact information for internal procedures should also contain contact information for internal
escalation procedures, as well as for external assistance groups such escalation procedures, as well as for external assistance groups such
as a CSIRT, CERT Coordination Center (CERT/CC), Global Information as a CSIRT, CERT Coordination Center (CERT/CC), Global Information
Assurance Certification (GIAC), and the FBI or other assisting Assurance Certification (GIAC), and the U.S. Federal Bureau of
government organization in the country of the investigation. Investigations (FBI) or other assisting government organization in
the country of the investigation.
3.1. Inter-service Provider RID Messaging 3.1. Inter-service Provider RID Messaging
RID provides a protocol and format that ensures interoperability RID provides a protocol and format that ensures interoperability
between vendors for the implementation of an incident messaging between vendors for the implementation of an incident messaging
mechanism. The messages should meet several requirements in order to mechanism. The messages should meet several requirements in order to
be meaningful as they traverse multiple networks. RID provides the be meaningful as they traverse multiple networks. RID provides the
framework necessary for communication between networks involved in framework necessary for communication between networks involved in
the incident handling, possible traceback, and mitigation of a the incident handling, possible traceback, and mitigation of a
security incident. Several message types described in Section 4.2 security incident. Several message types described in Section 4.2
skipping to change at page 14, line 18 skipping to change at page 14, line 23
RID is derived from the IODEF data model and inherits all of the data RID is derived from the IODEF data model and inherits all of the data
types defined in the IODEF model. One data type is added by RID: types defined in the IODEF model. One data type is added by RID:
BOOLEAN. BOOLEAN.
4.1.1. Boolean 4.1.1. Boolean
A boolean value is represented by the BOOLEAN data type. A boolean value is represented by the BOOLEAN data type.
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
the schema. the schema. Note that there are two lexical representations for
boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false' or
FALSE.
4.2. RID Message Types 4.2. RID Message Types
The five RID message types described below MUST be implemented. RID The five RID message types described below MUST be implemented. RID
messages uses both the IODEF [RFC5070] and RID document, which MUST messages uses both the IODEF [RFC5070] and RID document, which MUST
be encapsulated for transport as specified in [RFC6046-bis]. The be encapsulated for transport as specified in [RFC6046-bis]. The
messages are generated and received on designated systems for RID messages are generated and received on designated systems for RID
communications. Each RID message type, along with an example, is communications. Each RID message type, along with an example, is
described in the following sections. The IODEF-RID schema is described in the following sections. The IODEF-RID schema is
introduced in Section 5 to support the described RID message types. introduced in Section 5 to support the described RID message types.
skipping to change at page 17, line 18 skipping to change at page 17, line 27
the transport protocol [RFC6046-bis], as that information should be the transport protocol [RFC6046-bis], as that information should be
as small as possible and may not be encrypted. The RequestStatus as small as possible and may not be encrypted. The RequestStatus
message MUST be able to stand alone without the need for an IODEF message MUST be able to stand alone without the need for an IODEF
document to facilitate the communication, limiting the data document to facilitate the communication, limiting the data
transported to the required elements per [RFC6046-bis]. transported to the required elements per [RFC6046-bis].
The RID class has one attribute: The RID class has one attribute:
lang lang
REQUIRED. ENUM. A valid language code per [RFC4646] One. REQUIRED. ENUM. A valid language code per [RFC5646]
constrained by the definition of "xs:language". The constrained by the definition of "xs:language" inherited from
interpretation of this code is described in IODEF [RFC5070], [XML1.0].
Section 6.
5.1. RIDPolicy Class 5.1. RIDPolicy Class
The RIDPolicy class facilitates the delivery of RID messages and is The RIDPolicy class facilitates the delivery of RID messages and is
also referenced for transport in the transport document [RFC6046- also referenced for transport in the transport document [RFC6046-
bis]. The RIDPolicy Class includes the ability to embed an IODEF or bis]. The RIDPolicy Class includes the ability to embed an IODEF or
other XML schema document in the ReportSchema element. other XML documents that conform to schemas other than IODEF in the
ReportSchema element.
+------------------------+ +------------------------+
| RIDPolicy | | RIDPolicy |
+------------------------+ +------------------------+
| | | |
| ENUM restriction |<>-------------[ Node ] | ENUM restriction |<>-------------[ Node ]
| ENUM MsgType | | ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ] | ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType | | ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ] | ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
skipping to change at page 18, line 4 skipping to change at page 18, line 26
| | | |
| |<>---{0..1}----[ ReportSchema ] | |<>---{0..1}----[ ReportSchema ]
+------------------------+ +------------------------+
Figure 4: The RIDPolicy Class Figure 4: The RIDPolicy Class
The aggregate elements that constitute the RIDPolicy class are as The aggregate elements that constitute the RIDPolicy class are as
follows: follows:
Node Node
One. The Node class is used to identify a host or network device, One. The Node class is used to identify a host or network device,
in this case to identify the system communicating RID messages. in this case to identify the system communicating RID messages.
The base definition of this class is reused from the IODEF The base definition of this class is reused from the IODEF
specification [RFC5070], Section 3.16. specification [RFC5070], Section 3.16. See Section 11 of this
document for Internationalization considerations.
IncidentID IncidentID
Zero or one. Global reference pointing back to the IncidentID Zero or one. Global reference pointing back to the IncidentID
defined in the IODEF data model. The IncidentID includes the name defined in the IODEF data model. The IncidentID includes the name
of the CSIRT, an incident number, and an instance of that of the CSIRT, an incident number, and an instance of that
incident. The instance number is appended with a dash separating incident. The instance number is appended with a dash separating
the values and is used in cases for which it may be desirable to the values and is used in cases for which it may be desirable to
group incidents. Examples of incidents that may be grouped group incidents. Examples of incidents that may be grouped
include botnets, polymorphic attacks, DDoS attacks, multiple hops include botnets, polymorphic attacks, DDoS attacks, multiple hops
of compromised systems found during an investigation, etc. of compromised systems found during an investigation, etc.
PolicyRegion PolicyRegion
One or more. REQUIRED. The values for the attribute "region" are One or many. REQUIRED. The values for the attribute "region" are
used to determine what policy area may require consideration used to determine what policy area may require consideration
before a trace can be approved. The PolicyRegion may include before a trace can be approved. The PolicyRegion may include
multiple selections from the attribute list in order to fit all multiple selections from the attribute list in order to fit all
possible policy considerations when crossing regions, consortiums, possible policy considerations when crossing regions, consortiums,
or networks. or networks.
region region
REQUIRED. ENUM. The attribute region is used to identify the One or many. REQUIRED. ENUM. The attribute region is used to
expected sharing range of the incident information. The region identify the expected sharing range of the incident information.
may be within a region or defined by existing relationships such The region may be within a region or defined by existing
as those of a consortium or client to service provider. relationships such as those of a consortium or client to service
provider.
1. ClientToSP. A client initiated the request to their service 1. ClientToSP. A client initiated the request to their service
provider (SP). A client may be an individual, enterprise, or provider (SP). A client may be an individual, enterprise, or
other type of entity (government, commercial, education, other type of entity (government, commercial, education,
etc.). An SP may be a network, telecommunications, etc.). An SP may be a network, telecommunications,
infrastructure, or other type of SP where a client to vendor infrastructure, or other type of SP where a client to vendor
relationship has been established. The client to vendor relationship has been established. The client to vendor
relationship will typically have established contracts or relationship will typically have established contracts or
agreements to define expectations and trust relationships. agreements to define expectations and trust relationships.
skipping to change at page 19, line 35 skipping to change at page 20, line 11
5. BetweenConsortiums. Incident information that should have no 5. BetweenConsortiums. Incident information that should have no
restrictions between consortiums that have established agreed- restrictions between consortiums that have established agreed-
upon use and abuse guidelines. BetweenConsortiums is used upon use and abuse guidelines. BetweenConsortiums is used
when two consortiums (as defined in IntraConsortium above) when two consortiums (as defined in IntraConsortium above)
share data. The types of data that can be shared share data. The types of data that can be shared
BetweenConsortiums should be identified in their agreements BetweenConsortiums should be identified in their agreements
and contracts along with expectations on how that data should and contracts along with expectations on how that data should
be handled and protected. be handled and protected.
6. AcrossNationalBoundaries. This selection must be set if the 6. ext-value. An escape value used to extend this attribute.
message type will cross national boundaries.
AcrossNationalBoundaries is used when data shared may have
additional restrictions for handling and protection based on
the type of data and where it resides. The IODEF document
included, as well as any extensions, with the RID message
should indicate the specific restrictions to be considered.
The national boundary may be defined by existing regulations
or other legal agreements specific to a defined region. The
use of this AcrossNationalBoundaries is not legally binding
unless contracts and agreements for entities who share data
have deemed it as such through additional definitions that may
include associated handling and protection requirements.
There could be instances of Request messages (set to
TraceRequest) where that may not be known in advance, but
should be known at the instance where boundaries are crossed
during the investigation. This must also be set if the
security requirements of the request is based upon regulations
of a specific nation that may not apply to all nations. The
stricter requirements should be upheld. This is different
from the "BetweenConsortiums" setting since it may be possible
to have multiple nations as members of the same consortium,
and this option must be selected if the traffic is of a type
that may have different restrictions in other nations.
7. LawEnforcement. This option is used when incident information
is exchanged with LawEnforcement, local government, or other
authorities assisting with an investigation. The usage of
this value is interpreted by the sender, and that
interpretation may vary in regions of the world. This value
is intentionally broad. More detailed information on the
receiving entity is maintained in the Contact class of the
IODEF document. If the law enforcement agency resides within
a different nation that the sending entity, the
"AcrossNationalBoundaries" enumeration MUST also be set.
8. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
TrafficType TrafficType
One or many. REQUIRED. The values for the attribute "type" are One or many. REQUIRED. The values for the attribute "type" are
meant to assist in determining if a trace is appropriate for the meant to assist in determining if a trace is appropriate for the
SP receiving the request to continue the trace. Multiple values SP receiving the request to continue the trace. Multiple values
may be selected for this element; however, where possible, it may be selected for this element; however, where possible, it
should be restricted to one value that most accurately describes should be restricted to one value that most accurately describes
the traffic type. the traffic type.
type type
REQUIRED. ENUM. The attribute type is used to identify the type One or many. REQUIRED. ENUM. The attribute type is used to
of information included in the RID message or the type of identify the type of information included in the RID message or
incident. the type of incident.
1. Attack. This option SHOULD only be selected if the traffic is 1. Attack. This option SHOULD only be selected if the traffic is
related to a information security incident or attack. The related to a information security incident or attack. The
type of attack MUST also be listed in more detail in the IODEF type of attack MUST also be listed in more detail in the IODEF
Method and Impact classes for further clarification to assist Method and Impact classes for further clarification to assist
in determining if the trace can be continued ([RFC5070], in determining if the trace can be continued ([RFC5070],
Sections 3.9 and 3.10.1). Sections 3.9 and 3.10.1).
2. Network. This option MUST only be selected when the trace is 2. Network. This option MUST only be selected when the trace is
related to network traffic or routing issues. related to network traffic or routing issues.
3. Content. This category MUST be used only in the case in which 3. Content. This category MUST be used only in the case in which
the request is related to the content and regional the request is related to the content and regional
restrictions on accessing that type of content exist. This is restrictions on accessing that type of content exist. This is
not malicious traffic but may include determining what sources not malicious traffic but may include determining what sources
or destinations accessed certain materials available on the or destinations accessed certain materials available on the
Internet, including, but not limited to, news, technology, or Internet, including, but not limited to, news, technology, or
inappropriate content. inappropriate content.
4. OfficialBusiness. This option MUST be used if the incident 4. DataWithHandingRequirements. This option is used when data
information is requested by or affiliated with any government shared may have additional restrictions for handling and
or other official business request. This could be used during protection based on the type of data and where it resides.
an investigation by government authorities or other government The IODEF document included, as well as any extensions, with
incident investigations to track suspected criminal or other the RID message should indicate the specific restrictions to
activities. be considered. The national boundary may be defined by
existing regulations or other legal agreements specific to a
defined region. The use of this enumeration flag is not
legally binding (out-of-scope for a technical protocol).
5. Other. If this option is selected, a description of the 5. AudienceRestriction. This option is used to indicate the
message contains data that should be viewed by a restricted
audience. Please note that this setting should not be used
for normal incidents or reporting as it could slow response
times. The content may be a business relevant notification or
request. This option MAY be used by a business partner to
report or request assistance if an incident has effected a
supply chain. This option may also be used if the content is
relevant to a regulatory obligations, legal (eDiscovery), or
other use cases that require management attention.
6. Other. If this option is selected, a description of the
traffic type MUST be provided so that policy decisions can be traffic type MUST be provided so that policy decisions can be
made to continue or stop the investigation. The information made to continue or stop the investigation. The information
should be provided in the IODEF message in the Expectation should be provided in the IODEF message in the Expectation
class or in the History class using a HistoryItem log. This class or in the History class using a HistoryItem log. This
may also be used for incident types other than information may also be used for incident types other than information
security related incidents. security related incidents.
6. ext-value. An escape value used to extend this attribute. 7. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
ReportSchema ReportSchema
Zero or One. The ReportSchema class is used by the message Zero or One. The ReportSchema class is used by the message
types that require the full IODEF schema to be included in the types that require the full IODEF schema to be included in the
RID envelope. Alternate schemas may be included if approved by RID envelope. Alternate schemas may be included if approved by
the Designated Reviewer and registered by IANA for use with the Designated Reviewer and registered by IANA for use with
RID. RID.
skipping to change at page 21, line 50 skipping to change at page 22, line 4
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
MsgType MsgType
One. REQUIRED. ENUM. The type of RID message sent. The five
REQUIRED. ENUM. The type of RID message sent. The five types types of messages are described in Section 4.2 and can be noted
of messages are described in Section 4.2 and can be noted as as one of the six selections below, where a Request is set to
one of the six selections below, where a Request is set to
either an InvestigationRequest or TraceRequest. either an InvestigationRequest or TraceRequest.
2. TraceRequest. This Request message may be used to initiate a 2. TraceRequest. This Request message may be used to initiate a
TraceRequest or to continue a TraceRequest to an upstream TraceRequest or to continue a TraceRequest to an upstream
network closer to the source address of the origin of the network closer to the source address of the origin of the
security incident. security incident.
3. Acknowledgement. This message is sent to the initiating RID 3. Acknowledgement. This message is sent to the initiating RID
system from each of the upstream RID systems to provide system from each of the upstream RID systems to provide
information on the request status in the current network. information on the request status in the current network.
skipping to change at page 22, line 44 skipping to change at page 22, line 46
trusted RID system about an incident or incident type. trusted RID system about an incident or incident type.
Additionally, there is an extension attribute to add new Additionally, there is an extension attribute to add new
enumerated values: enumerated values:
ext-value. An escape value used to extend this attribute. See ext-value. An escape value used to extend this attribute. See
IODEF [RFC5070], Section 5.1. IODEF [RFC5070], Section 5.1.
MsgDestination MsgDestination
REQUIRED. ENUM. The destination required at this level may One. REQUIRED. ENUM. The destination required at this level
either be the RID messaging system intended to receive the may either be the RID messaging system intended to receive the
request, or, in the case of a Request with MsgType set to request, or, in the case of a Request with MsgType set to
'InvestigationRequest', the source of the incident. In the 'InvestigationRequest', the source of the incident. In the
case of an InvestigationRequest, the RID system that can help case of an InvestigationRequest, the RID system that can help
stop or mitigate the traffic may not be known, and the message stop or mitigate the traffic may not be known, and the message
may have to traverse RID messaging systems by following the may have to traverse RID messaging systems by following the
routing path to the RID system closest to the source of the routing path to the RID system closest to the source of the
attack traffic. The Node element lists either the RID system attack traffic. The Node element lists either the RID system
or the IP address of the source, and the meaning of the value or the IP address of the source, and the meaning of the value
in the Node element is determined by the MsgDestination in the Node element is determined by the MsgDestination
element. element.
skipping to change at page 24, line 10 skipping to change at page 24, line 10
The ReportSchema class is an aggregate class in the RIDPolicy class. The ReportSchema class is an aggregate class in the RIDPolicy class.
The IODEF schema is the approved schema for inclusion in RID messages The IODEF schema is the approved schema for inclusion in RID messages
via the ReportSchema class. via the ReportSchema class.
+-------------------------+ +-------------------------+
| ReportSchema | | ReportSchema |
+-------------------------+ +-------------------------+
| | | |
| ENUM Version | | ENUM Version |
| STRING ext-Version |<>---{1}-------[ XMLDocumen ] | STRING ext-Version |<>---{1}-------[ XMLDocument ]
| ENUM XMLSchemaID | | ENUM XMLSchemaID |
| STRING ext-XMLSchemaID |<>---{0..1}----[ URL ] | STRING ext-XMLSchemaID |<>---{0..1}----[ URL ]
| | | |
| |<>---{0..*}----[ Signature ] | |<>---{0..*}----[ Signature ]
| | | |
+-------------------------+ +-------------------------+
Figure 5: The ReportSchema Class Figure 5: The ReportSchema Class
The elements that constitute the ReportSchema class are as follows: The elements that constitute the ReportSchema class are as follows:
XMLDocument XMLDocument
One. The XMLDocument is a complete XML document defined by the One. The XMLDocument is a complete XML document defined by the
iodef:ExtensionType class. This class follows the guidelines iodef:ExtensionType class. This class follows the guidelines
in [RFC5070] Section 5 where the data type is set to "xml" and in [RFC5070] Section 5 where the data type is set to "xml" and
meaning is set to "xml" to include an xml document. meaning is set to "xml" to include an xml document.
URL URL
Zero or One. URL. A reference to the XML schema included. The Zero or One. URL. A reference to the XML schema of the XML
URL data type is defined in [RFC5070] Section 2.15 as "xs: document included. The URL data type is defined in [RFC5070]
anyURI" in the schema. The schemaLocation for IODEF is already Section 2.15 as "xs:anyURI" in the schema. The schemaLocation
included in the RID schema, so this is not necessary to include for IODEF is already included in the RID schema, so this is not
a URL for IODEF documents. The list of registered schemas for necessary to include a URL for IODEF documents. The list of
inclusion will be maintained by IANA. registered schemas for inclusion will be maintained by IANA.
Signature Signature
Zero to many. The Signature uses the iodef:ExtensionType class Zero to many. The Signature uses the iodef:ExtensionType class
to enable this element to contain a detached or enveloped to enable this element to contain a detached or enveloped
signature. This class follows the guidelines in [RFC5070] signature. This class follows the guidelines in [RFC5070]
Section 5 where the data type is set to "xml" and meaning is Section 5 where the data type is set to "xml" and meaning is
set to "xml" to include an xml document. This element is used set to "xml" to include an xml document. This element is used
to encapsulate the detached signature based on the iodef: to encapsulate the detached signature based on the iodef:
RecordItem class within the IODEF document to verify the RecordItem class within the IODEF document to verify the
skipping to change at page 25, line 27 skipping to change at page 25, line 27
ext-Version ext-Version
OPTIONAL. One. The ext-Version attribute is the version number OPTIONAL. One. The ext-Version attribute is the version number
of the included XML schema. This attribute is used if a schema of the included XML schema. This attribute is used if a schema
other than IODEF or an IANA registered schema that has been other than IODEF or an IANA registered schema that has been
added to the enumerated list for Version is included. added to the enumerated list for Version is included.
XMLSchemaID XMLSchemaID
OPTIONAL. One. The XMLSchemaID attribute is the identifier OPTIONAL. One. The XMLSchemaID attribute is the identifier,
(defined namespace) of the XML schema included. The the defined namespace[XMLNames], of the XML schema of the XML
XMLSchemaID and Version specify the format of the XMLDocument document included. The XMLSchemaID and Version specify the
element. The only permitted values, include the namespace for format of the XMLDocument element. The only permitted values,
IODEF [RFC5070], "urn:ietf:params:xml:ns:iodef-1.0", any future include the namespace for IODEF [RFC5070],
IETF approved versions of IODEF, and any namespace included in "urn:ietf:params:xml:ns:iodef-1.0", any future IETF approved
the IANA managed list of registered schemas for use with RID. versions of IODEF, and any namespace included in the IANA
The IANA registry for managing schemas other than IODEF is managed list of registered schemas for use with RID. The IANA
specified in Section 11. registry for managing schemas other than IODEF is specified in
Section 11.
ext-value. An escape value used to extend this attribute. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
ext-XMLSchemaID ext-XMLSchemaID
OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier
(defined namespace) of the XML schema included. The ext- (defined namespace) of the XML schema of the XML document
XMLSchemaID and ext-Version specify the format of the included. The ext-XMLSchemaID and ext-Version specify the
XMLDocument element and are used if the included schema is not format of the XMLDocument element and are used if the included
IODEF version 1.0 or an IANA registered schema that has been schema is not IODEF version 1.0 or an IANA registered schema
added to the enumerated list for XMLSchemaID. that has been added to the enumerated list for XMLSchemaID.
5.2. RequestStatus 5.2. RequestStatus
The RequestStatus class is an aggregate class in the RID class. The RequestStatus class is an aggregate class in the RID class.
+--------------------------------+ +--------------------------------+
| RequestStatus | | RequestStatus |
+--------------------------------+ +--------------------------------+
| | | |
| ENUM restriction | | ENUM restriction |
skipping to change at page 26, line 35 skipping to change at page 26, line 35
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
AuthorizationStatus AuthorizationStatus
REQUIRED. ENUM. The listed values are used to provide a One. REQUIRED. ENUM. The listed values are used to provide a
response to the requesting CSIRT of the status of a Request, response to the requesting CSIRT of the status of a Request,
Report, or Query. Report, or Query.
1. Approved. The trace was approved and will begin in the 1. Approved. The trace was approved and will begin in the
current SP. current SP.
2. Denied. The trace was denied in the current SP. The next 2. Denied. The trace was denied in the current SP. The next
closest SP can use this message to filter traffic from the closest SP can use this message to filter traffic from the
upstream SP using the example packet to help mitigate the upstream SP using the example packet to help mitigate the
effects of the attack as close to the source as possible. effects of the attack as close to the source as possible.
skipping to change at page 27, line 31 skipping to change at page 27, line 31
the original requestor on the RecordItem entry failed to the original requestor on the RecordItem entry failed to
validate. validate.
5. Encryption. Unable to decrypt the request, report, or 5. Encryption. Unable to decrypt the request, report, or
query. query.
6. UnrecognizedFormat. The format of the provided document 6. UnrecognizedFormat. The format of the provided document
was unrecognized. was unrecognized.
7. CannotProcess. The document could not be processed. 7. CannotProcess. The document could not be processed.
Reasons may include legal or policy decisions. Reasons may include legal or policy decisions. Resolution
may require communication outside of this protocol to
resolve legal or policy issues. No further messages SHOULD
be sent until resolved.
8. Other. There were other reasons this request could not be 8. Other. There were other reasons this request could not be
processed. processed.
9. ext-value. An escape value used to extend this attribute. 9. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
AuthorizationStatus-ext AuthorizationStatus-ext
OPTIONAL. STRING. A means by which to extend the OPTIONAL. STRING. A means by which to extend the
skipping to change at page 28, line 36 skipping to change at page 28, line 36
One. BOOLEAN. The Source class indicates if a source was One. BOOLEAN. The Source class indicates if a source was
identified. If the source was identified, it is listed in the identified. If the source was identified, it is listed in the
Node element of this class. Node element of this class.
True. Source of incident was identified. True. Source of incident was identified.
False. Source of incident was not identified. False. Source of incident was not identified.
Node Node
One. The Node class is used to identify a host or network Zero or many. The Node class is used to identify a system
device, in this case to identify the system communicating RID identified as part of an incident. The base definition of this
messages. The base definition of this class is reused from the class from the IODEF [RFC5070] can be expanded to include other
IODEF specification [RFC5070], Section 3.16. identifiers, Section 3.16.
The IncidentSource class has one attribute: The IncidentSource class has one attribute:
restriction restriction
OPTIONAL. ENUM. This attribute indicates the disclosure OPTIONAL. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere. guidelines to which the sender expects the recipient to adhere.
This guideline provides no real security since it is the choice This guideline provides no real security since it is the choice
of the recipient of the document to honor it. This attribute of the recipient of the document to honor it. This attribute
follows the same guidelines as "restriction" used in IODEF. follows the same guidelines as "restriction" used in IODEF.
5.4. RID Name Spaces 5.4. RID Name Spaces
The RID schema declares a namespace of "iodef-rid-2.0" and registers The RID schema declares a namespace of
it per [XMLNames]. Each IODEF-RID document MUST use the "urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per
"iodef-rid-2.0" namespace in the top-level element RID-Document. It [RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0"
can be referenced as follows: namespace in the top-level element RID-Document. It can be
referenced as follows:
<RID-Document version="2.0" lang="en-US" <RID-Document version="2.0" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd"> xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">
5.5. Including IODEF or other XML Documents 5.5. Encoding
RID documents MUST begin with an XML declaration, MUST specify the
XML version used, and the use of UTF-8 encoding is REQUIRED [RFC3470]
Section 4.4. RID conforms to all XML data encoding conventions and
constraints.
The XML declaration with no character encoding will read as follows:
<?xml version="1.0" ?>
When a character encoding is specified, the XML declaration will read
as follows:
<?xml version="1.0" encoding="charset" ?>
Where "charset" is the name of the character encoding as registered
with the Internet Assigned Numbers Authority (IANA), see [RFC2978].
The following characters have special meaning in XML and MUST be
escaped with their entity reference equivalent: "&", "<", ">", "\""
(double quotation mark), and "'" (apostrophe). These entity
references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;"
respectively.
5.6. Including IODEF or other XML Documents
In order to support the changing activity of CSIRTS, the RID schema In order to support the changing activity of CSIRTS, the RID schema
can include an IODEF or other data model. The IODEF is also can include an IODEF or other data model. The IODEF is also
extensible, enabling the schemas to evolve along with the needs of extensible, enabling the schemas to evolve along with the needs of
CSIRTs. This section discusses how to include the IODEF XML document CSIRTs. This section discusses how to include the IODEF XML document
or other XML documents to leverage the security and trust or other XML documents to leverage the security and trust
relationships established through the use of RID. These techniques relationships established through the use of RID. These techniques
are designed so that adding new data will not require a change to the are designed so that adding new data will not require a change to the
RID schema. This approach also supports the exchange of private XML RID schema. This approach also supports the exchange of private XML
documents relevant only to a closed consortium. XML documents can be documents relevant only to a closed consortium. XML documents can be
skipping to change at page 30, line 15 skipping to change at page 30, line 40
Version: "1.0" Version: "1.0"
XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0" XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"
URL: "http://www.iana.org/assignments/xml-registry/schema/ URL: "http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd" iodef-1.0.xsd"
The URL is optionally included for IODEF since it is already in the The URL is optionally included for IODEF since it is already in the
RID schema and the schemaLocation is defined. RID schema and the schemaLocation is defined.
5.5.1. Including XML Schema Documents in RID 5.6.1. Including XML Documents in RID
The Common Vulnerability Reporting Format (CVRF) is an additional The Common Vulnerability Reporting Format (CVRF) is an additional
schema registered for inclusion in a RID message. The registered schema registered for inclusion in a RID message. The registered
IANA information for additional schemas MUST include the IANA information for additional schemas MUST include the
specification name, version, specification Uniform Resource specification name, version, specification Uniform Resource
Identifier (URI), and namespace. The following provides an example Identifier (URI), and namespace. The following provides an example
of the necessary information for additional schemas beyond IODEF and of the necessary information for additional schemas beyond IODEF and
CVRF. CVRF.
Common Vulnerability Reporting Format (CVRF) Common Vulnerability Reporting Format (CVRF)
skipping to change at page 31, line 6 skipping to change at page 31, line 31
6. RID Messages 6. RID Messages
The IODEF model is followed as specified in [RFC5070] for each of the The IODEF model is followed as specified in [RFC5070] for each of the
RID message types. The RID schema is used in combination with IODEF RID message types. The RID schema is used in combination with IODEF
documents to facilitate RID communications. Each message type varies documents to facilitate RID communications. Each message type varies
slightly in format and purpose; hence, the requirements vary and are slightly in format and purpose; hence, the requirements vary and are
specified for each. All classes, elements, attributes, etc., that specified for each. All classes, elements, attributes, etc., that
are defined in the IODEF-Document are valid in the context of a RID are defined in the IODEF-Document are valid in the context of a RID
message; however, some listed as optional in IODEF are mandatory for message; however, some listed as optional in IODEF are mandatory for
RID as listed for each message type. The IODEF model MUST be fully RID as listed for each message type. The IODEF model MUST be fully
implemented to ensure proper parsing of all RID messages. implemented for RID messages that include IODEF payloads to ensure
proper parsing of those messages.
Note: The implementation of RID may automate the ability to fill in Note: The implementation of RID may automate the ability to fill in
the content required for each message type from packet input, the content required for each message type from packet input,
incident data, situational awareness information, or default values incident data, situational awareness information, or default values
such as those used in the EventData class. such as those used in the EventData class.
6.1. Request 6.1. Request
Description: This message type is used to request assistance in a Description: This message type is used to request assistance in a
computer security investigation. The investigation Request may be computer security investigation. The investigation Request may be
skipping to change at page 34, line 15 skipping to change at page 34, line 43
the originator and sending peer (if they are not the same) MUST both the originator and sending peer (if they are not the same) MUST both
receive the message. This enables the sending peer the option to receive the message. This enables the sending peer the option to
take action to stop or mitigate the traffic as close to the source as take action to stop or mitigate the traffic as close to the source as
possible. possible.
6.3. Result 6.3. Result
Description: This message indicates that the trace or investigation Description: This message indicates that the trace or investigation
has been completed and provides the result. The Result message has been completed and provides the result. The Result message
includes information on whether or not a source was found and the includes information on whether or not a source was found and the
source information through the IncidentSource class. The Result source information is provided through the IncidentSource class. The
information MUST go back to the originating RID system that began the Result information MUST go back to the originating RID system that
investigation or trace. An provider may use any number of incident began the investigation or trace. An provider may use any number of
handling data sources to ascertain the true source of an attack. All incident handling data sources to ascertain the true source of an
of the possible information sources may or may not be readily tied attack. All of the possible information sources may or may not be
into the RID communications system. readily tied into the RID communications system.
The following information is REQUIRED for Result messages and will be The following information is REQUIRED for Result messages and will be
provided through: provided through:
RID Information: RID Information:
RIDPolicy RIDPolicy
RID message type, IncidentID, and destination policy RID message type, IncidentID, and destination policy
information information
Incident Source Incident Source
The IncidentSource class of the RID schema is used to note The IncidentSource class of the RID schema is used to note
if a source was identified and provide the source if a source was identified and provide the source
address(es). address(es) or other Node information.
IODEF Information: IODEF Information:
Time Stamps (DetectTime, StartTime, EndTime, ReportTime). Time Stamps (DetectTime, StartTime, EndTime, ReportTime).
Incident Identifier (Incident class, IncidentID). Incident Identifier (Incident class, IncidentID).
Trace number - used for multiple traces of a single Trace number - used for multiple traces of a single
incident; MUST be included if the response is specific to an incident; MUST be included if the response is specific to an
instance of an incident. instance of an incident.
skipping to change at page 39, line 42 skipping to change at page 40, line 22
o Report: Asynchronous information report, may be pushed to systems o Report: Asynchronous information report, may be pushed to systems
or a response from a Query or a response from a Query
MsgType set to Report MsgType set to Report
Possible responses: Possible responses:
+ Acknowledgement (OPTIONAL) + Acknowledgement (OPTIONAL)
Processing considerations for the IODEF document and any IODEF
included elements or attributes MUST follow the guidelines specified
in [RFC5070] Section 4. [RFC3023] and [RFC3470] specify requirements
and best practices for the use of XML in IETF application protocols.
RID and IODEF documents MUST be well-formed [RFC3470], see Section
4.1, and MUST be validated against the appropriate schema. Internal
or external DTD subsets are prohibited in RID, see [RFC3023] Section
3.
Comments can be ignored by conform ant processors for RID or IODEF
documents [RFC3470], see Section 4.6, and are included below for
informational purposes only. The first example demonstrates the use
of a detached digital signature. Subsequent examples do not include
the detached signature required for some message types. The
signature is applied after the message is created as demonstrated in
the first example.
Note: For each example listed below, [RFC5735] addresses were used. Note: For each example listed below, [RFC5735] addresses were used.
Assume that each IP address listed is actually a separate network Assume that each IP address listed is actually a separate network
range held by different SPs. Addresses were used from /27 network range held by different SPs. Addresses were used from /27 network
ranges. ranges.
7.1. Upstream Trace Communication Flow 7.1. Upstream Trace Communication Flow
The diagram below outlines the RID Request communication flow for a The diagram below outlines the RID Request communication flow for a
TraceRequest between RID systems on different networks tracing an TraceRequest between RID systems on different networks tracing an
attack. The Request message with MsgDst set to 'TraceRequest' is attack. The Request message with MsgDst set to 'TraceRequest' is
skipping to change at page 42, line 29 skipping to change at page 43, line 22
DOMAIN, and 'SP-2' is identified in the RID document for the Request DOMAIN, and 'SP-2' is identified in the RID document for the Request
as the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node as the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node
class. SP-3 is later used in the Result message and the class. SP-3 is later used in the Result message and the
administrator is identified as 'Admin-contact@10.1.1.2' as they administrator is identified as 'Admin-contact@10.1.1.2' as they
searched for 192.0.2.35, the administrator may be different than the searched for 192.0.2.35, the administrator may be different than the
constituency contact (an additional Request with MsgDst set to constituency contact (an additional Request with MsgDst set to
'TraceRequest' occurred between SP-2 to SP-3 that is not included). 'TraceRequest' occurred between SP-2 to SP-3 that is not included).
SP-3 is the service provider for 192.0.2.32/27 and was able to take SP-3 is the service provider for 192.0.2.32/27 and was able to take
the action to rate-limit their traffic. The SP-1, SP-2, and SP-3 the action to rate-limit their traffic. The SP-1, SP-2, and SP-3
information would be replaced with the appropriate (and valid) email information would be replaced with the appropriate (and valid) email
and other contact information in real usages. The Node class allows and other contact information in real usages. The Node class enables
for the use of a fully qualified domain or the IP address to be multiple methods to identify a system, such as a fully qualified
provided for the SP. Any mapping of existing relationships from the domain or the IP address to be provided for the SP. Any mapping of
SP Node information to the name, contact, digital signature existing relationships from the SP Node information to the name,
verification information and other identifying or trust information contact, digital signature verification information and other
is provided at the application layer to support end users of the identifying or trust information is provided at the application layer
incident management system. A packet is provided in this example to to support end users of the incident management system. A packet is
enable any traces to be performed by SP-2 and SP-3 to perform traces provided in this example to enable any traces to be performed by SP-2
to the attack source before taking the requested action to 'rate- and SP-3 to perform traces to the attack source before taking the
limit' the traffic. The subnet of 192.0.2.0uses a 27 bit mask in the requested action to 'rate-limit' the traffic. The subnet of
examples below. 192.0.2.0uses a 27 bit mask in the examples below.
In the following example, use of [XMLsig] to generate digital In the following example, use of [XMLsig] to generate digital
signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of
[XMLsig] supports additional digest algorithms. Reference [RFC4051] [XMLsig] supports additional digest algorithms. Reference [RFC4051]
for URIs intended for use with XML digital signatures, encryption, for URIs intended for use with XML digital signatures, encryption,
and canonicalization. SHA-1 SHOULD NOT be used, see [RFC6194] for and canonicalization. SHA-1 SHOULD NOT be used, see [RFC6194] for
further details. further details.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<iodef-rid:RID lang="en-US" <iodef-rid:RID lang="en-US"
skipping to change at page 44, line 44 skipping to change at page 45, line 38
Notification sent to next upstream SP closer to 192.0.2.35 Notification sent to next upstream SP closer to 192.0.2.35
</iodef:Description> </iodef:Description>
</iodef:HistoryItem> </iodef:HistoryItem>
</iodef:History> </iodef:History>
</iodef:Incident> </iodef:Incident>
</IODEF-Document> </IODEF-Document>
</iodef-rid:XMLDocument> </iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID --> <!-- End of IODEF-Document included in RID -->
<!-- Start of detached XML signature included in RID --> <!-- Start of detached XML signature included in RID -->
<iodef-rid:Signature dtype="xml" meaning="xml"> <iodef-rid:Signature dtype="xml" meaning="xml">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="dsig-123456"> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="dsig-123456">
<SignedInfo> <SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI=""> <Reference URI="">
<Transforms> <Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> <Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2" <XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2" xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
Filter="intersect"> Filter="intersect">
//dsig:Signature[@Id = 'dsig-123456']/ancestor::iodef-rid:ReportSchema/ //dsig:Signature[@Id = 'dsig-123456']/ancestor::iodef-rid:ReportSchema/
iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/ iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
skipping to change at page 57, line 14 skipping to change at page 58, line 14
8. RID Schema Definition 8. RID Schema Definition
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0" <xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-2.0" targetNamespace="urn:ietf:params:xml:ns:iodef-rid-2.0"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation="http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/> schemaLocation="http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!-- **************************************************************** <!-- ****************************************************************
********************************************************************* *********************************************************************
*** Real-time Inter-network Defense - RID XML Schema *** *** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, January 2012 *** *** Namespace - iodef-rid, January 2012 ***
*** The namespace is defined to support transport of IODEF *** *** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. *** *** documents for exchanging incident information. ***
********************************************************************* *********************************************************************
--> -->
<!--RID messages acts as an envelope for IODEF and RID documents <!--RID messages acts as an envelope for IODEF and RID documents
skipping to change at page 60, line 13 skipping to change at page 61, line 16
<xs:complexType> <xs:complexType>
<xs:attribute name="region" use="required"> <xs:attribute name="region" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/> <xs:whiteSpace value="collapse"/>
<xs:enumeration value="ClientToSP"/> <xs:enumeration value="ClientToSP"/>
<xs:enumeration value="SPToClient"/> <xs:enumeration value="SPToClient"/>
<xs:enumeration value="IntraConsortium"/> <xs:enumeration value="IntraConsortium"/>
<xs:enumeration value="PeerToPeer"/> <xs:enumeration value="PeerToPeer"/>
<xs:enumeration value="BetweenConsortiums"/> <xs:enumeration value="BetweenConsortiums"/>
<xs:enumeration value="AcrossNationalBoundaries"/>
<xs:enumeration value="LawEnforcement"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="ext-region" <xs:attribute name="ext-region"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="TrafficType"> <xs:element name="TrafficType">
<xs:complexType> <xs:complexType>
<xs:attribute name="type" use="required"> <xs:attribute name="type" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/> <xs:whiteSpace value="collapse"/>
<xs:enumeration value="Attack"/> <xs:enumeration value="Attack"/>
<xs:enumeration value="Network"/> <xs:enumeration value="Network"/>
<xs:enumeration value="Content"/> <xs:enumeration value="Content"/>
<xs:enumeration value="OfficialBusiness"/> <xs:enumeration value="DataWithHandingRequirements"/>
<xs:enumeration value="AudienceRestriction"/>
<xs:enumeration value="Other"/> <xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="ext-type" <xs:attribute name="ext-type"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<!--Used to include an enveloped XML document in RID--> <!--Used to include an enveloped XML document in RID-->
skipping to change at page 62, line 24 skipping to change at page 63, line 25
the trace or those involved in the investigation. All instances the trace or those involved in the investigation. All instances
of RecordItem provided by the originator may be individually of RecordItem provided by the originator may be individually
signed, and additional RecordItem entries by upstream peers in the signed, and additional RecordItem entries by upstream peers in the
trace or investigation may be signed by the peer adding the data, trace or investigation may be signed by the peer adding the data,
while maintaining the original RecordItem entry(s) and detached while maintaining the original RecordItem entry(s) and detached
signature(s) from the original requestor. It is important to note signature(s) from the original requestor. It is important to note
that the data is signed at the RecordItem level. Since multiple that the data is signed at the RecordItem level. Since multiple
RecordItems may exist within an IODEF document and may originate RecordItems may exist within an IODEF document and may originate
from different sources, the signature is applied at the RecordItem from different sources, the signature is applied at the RecordItem
level to enable the use of an XML detached signature. Exclusive level to enable the use of an XML detached signature. Exclusive
canonicalization [RFC3741] is REQUIRED for the detached signature canonicalization [XMLCanon] is REQUIRED for the detached signature
and not the references as the XML document generated is then and not the references as the XML document generated is then
included in the RID message within the Signature element of the included in the RID message within the Signature element of the
ReportSchema class. This signature MUST be passed to all ReportSchema class. This signature MUST be passed to all
recipients of the Request message. recipients of the Request message.
o If a Request does not include a RecordItem entry, a timestamp MUST o If a Request does not include a RecordItem entry, a timestamp MUST
be used to ensure there is data to be signed for the multi-hop be used to ensure there is data to be signed for the multi-hop
authentication use case. The DateTime element of the IODEF: authentication use case. The DateTime element of the IODEF:
RecordItem class, [RFC5070] Section3.19.1, is used for this RecordItem class, [RFC5070] Section3.19.1, is used for this
purpose. purpose.
skipping to change at page 63, line 9 skipping to change at page 64, line 11
o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to
specify the portion of the XML document to be signed. XPath is specify the portion of the XML document to be signed. XPath is
used to specify a location within an XML document. Best practice used to specify a location within an XML document. Best practice
recommendations for using XPath [XMLSigBP] SHOULD be referenced to recommendations for using XPath [XMLSigBP] SHOULD be referenced to
reduce the risk of denial of service attacks. The use of XSLT reduce the risk of denial of service attacks. The use of XSLT
transforms MUST be restricted according to security guidance in transforms MUST be restricted according to security guidance in
[XMLSigBP]. [XMLSigBP].
XML Encryption XML Encryption
o The IODEF/RID document may be encrypted to provide an extra layer o The IODEF/RID document MAY be encrypted to provide an extra layer
of security between peers so that the message is not only of security between peers so that the message is not only
encrypted for transport. This behavior would be agreed upon encrypted for transport. This behavior would be agreed upon
between peers or a consortium, or determined on a per-message between peers or a consortium, or determined on a per-message
basis, depending on security requirements. It should be noted basis, depending on security requirements. It should be noted
that there are cases for transport where the RIDPolicy class needs that there are cases for transport where the RIDPolicy class needs
to be presented in clear text, as detailed in the transport to be presented in clear text, as detailed in the transport
document [RFC6046-bis]. document [RFC6046-bis].
o A Request, or any other message type that may be relayed through o A Request, or any other message type that may be relayed through
RID systems other than the intended destination as a result of RID systems before reaching the intended destination as a result
trust relationships, may be encrypted for the intended recipient. of trust relationships, MAY be encrypted specifically for the
This may be necessary if the RID network is being used for message intended recipient. This may be necessary if the RID network is
transfer, the intermediate parties do not need to have knowledge being used for message transfer, the intermediate parties do not
of the request contents, and a direct communication path does not need to have knowledge of the request contents, and a direct
exist. In that case, the RIDPolicy class is used by intermediate communication path does not exist. In that case, the RIDPolicy
parties and is maintained in clear text. class is used by intermediate parties and as such, RIDPolicy is
maintained in clear text.
o The action taken in the Result message may be encrypted using the o The action taken in the Result message may be encrypted using the
key of the request originator. In that case, the intermediate key of the request originator. In that case, the intermediate
parties can view the RIDPolicy information and know the trace has parties can view the RIDPolicy information and know the trace has
been completed and do not need to see the action. If the use of been completed and do not need to see the action. If the use of
encryption were limited to sections of the message, the History encryption were limited to sections of the message, the History
class information would be encrypted. Otherwise, it is class information would be encrypted. Otherwise, it is
RECOMMENDED to encrypt the entire IODEF/RID document and use an RECOMMENDED to encrypt the entire IODEF/RID document and use an
enveloped signature, for the originator of the request. The enveloped signature, for the originator of the request. The
existence of the Result message for an incident would tell any existence of the Result message for an incident would tell any
skipping to change at page 64, line 11 skipping to change at page 65, line 14
contained in each of the RID classes and MUST be used in contained in each of the RID classes and MUST be used in
accordance with confidentiality expectations for either sections accordance with confidentiality expectations for either sections
of the IODEF document or the complete IODEF document. Consortiums of the IODEF document or the complete IODEF document. Consortiums
and organizations should consider this guidance when creating and organizations should consider this guidance when creating
exchange policies. exchange policies.
o Expectations based on restriction setting: o Expectations based on restriction setting:
* If restriction is set to "private", the class or document MUST * If restriction is set to "private", the class or document MUST
be encrypted for the recipient using XML encryption and the be encrypted for the recipient using XML encryption and the
public key of the recipient. See Section 9 for a discussion on public key of the recipient. See Section 9.3 for a discussion
public key infrastructure (PKI) and other security on public key infrastructure (PKI) and other security
requirements. requirements.
* If restriction is set to "need-to-know", the class or document * If restriction is set to "need-to-know", the class or document
MUST be encrypted to ensure only those with need-to-know access MUST be encrypted to ensure only those with need-to-know access
can decrypt the data. The document can either be encrypted for can decrypt the data. The document can either be encrypted for
each individual for which access is intended or a single group each individual for which access is intended or a single group
key may be used. The method used SHOULD adhere to any key may be used. The method used SHOULD adhere to any
certificate policy and practices agreements between entities certificate policy and practices agreements between entities
for the use of RID. A group key in this instance refers to a for the use of RID. A group key in this instance refers to a
single key (symmetric) that is used to encrypt the block of single key (symmetric) that is used to encrypt the block of
skipping to change at page 65, line 34 skipping to change at page 66, line 37
information listed in RIDPolicy. information listed in RIDPolicy.
RID is used to transfer or exchange XML documents in an IODEF format RID is used to transfer or exchange XML documents in an IODEF format
or using another IANA registered format. Implementations SHOULD NOT or using another IANA registered format. Implementations SHOULD NOT
download schemas at runtime due to the security implications, and download schemas at runtime due to the security implications, and
included documents MUST NOT be required to provide a resolvable included documents MUST NOT be required to provide a resolvable
location of their schema. location of their schema.
9.2. Message Transport 9.2. Message Transport
The transport specifications are fully defined in a separate document A transport specification is defined in a separate document [RFC6046-
[RFC6046-bis]. The specified transport protocols MUST use encryption bis]. The specified transport protocols MUST use encryption to
to provide an additional level of security and integrity, while provide an additional level of security and integrity, while
supporting mutual authentication through bi-directional certificate supporting mutual authentication through bi-directional certificate
usage. Any subsequent transport method defined should take advantage usage. Any subsequent transport method defined should take advantage
of existing standards for ease of implementation and integration of of existing standards for ease of implementation and integration of
RID systems. Session encryption for the transport of RID messages is RID systems. Session encryption for the transport of RID messages is
enforced in the transport specification. The privacy and security enforced in the transport specification. The privacy and security
considerations are addressed fully in RID to protect sensitive considerations are addressed fully in RID to protect sensitive
portions of documents and provide a method to authenticate the portions of documents and provide a method to authenticate the
messages. Therefore, RID messages do not rely on the security messages. Therefore, RID messages do not rely on the security
provided by the transport layer alone. The encryption requirements provided by the transport layer alone. The encryption requirements
and considerations for RID messages are discussed in Section 9.1 of and considerations for RID messages are discussed in Section 9.1 of
this document. this document.
The RID protocol must be able to guarantee delivery and meet the
necessary security requirements of a state-of-the-art protocol. In
order to guarantee delivery, TCP should be considered as the
underlying protocol within the current network standard practices.
Consortiums may vary their selected transport mechanisms and thus Consortiums may vary their selected transport mechanisms and thus
decide upon a mutual protocol to use for transport when communicating decide upon a mutual protocol to use for transport when communicating
with peers in a neighboring consortium using RID. RID systems MUST with peers in a neighboring consortium using RID. RID systems MUST
implement and deploy HTTPS as defined in the transport document implement and deploy HTTPS as defined in the transport document
[RFC6046-bis] and optionally support other protocols such as the [RFC6046-bis] and optionally support other protocols such as the
Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Bindings would
need to be defined to enable support for other transport protocols.
Systems used to send authenticated RID messages between networks MUST Systems used to send authenticated RID messages between networks MUST
use a secured system and interface to connect to a border network's use a secured system and interface to connect to a border network's
RID systems. Each connection to a RID system MUST meet the security RID systems. Each connection to a RID system MUST meet the security
requirements agreed upon through the consortium regulations, peering, requirements agreed upon through the consortium regulations, peering,
or SLAs. The RID system MUST only listen for and send RID messages or SLAs. The RID system MUST only listen for and send RID messages
on the designated port, which also MUST be over an encrypted tunnel on the designated port, which also MUST be over an encrypted tunnel
meeting the minimum requirement of algorithms and key lengths meeting the minimum requirement of algorithms and key lengths
established by the consortium, peering, or SLA. The selected established by the consortium, peering, or SLA. The selected
cryptographic algorithms for symmetric encryption, digital cryptographic algorithms for symmetric encryption, digital
skipping to change at page 70, line 31 skipping to change at page 71, line 28
A PKI can also provide the same level of security for communication A PKI can also provide the same level of security for communication
between an end entity (enterprise, educational, or government between an end entity (enterprise, educational, or government
customer network) and the SP. customer network) and the SP.
9.5. Privacy Concerns and System Use Guidelines 9.5. Privacy Concerns and System Use Guidelines
Privacy issues raise many concerns when information-sharing is Privacy issues raise many concerns when information-sharing is
required to achieve the goal of stopping or mitigating the effects of required to achieve the goal of stopping or mitigating the effects of
a security incident. The RIDPolicy class is used to automate the a security incident. The RIDPolicy class is used to automate the
enforcement of the privacy concerns listed within this document. The enforcement of the privacy concerns listed within this document. The
privacy and system use concerns that MUST be addressed in the RID privacy and system use concerns for the system communicating RID
system and other integrated components include the following: messages and other integrated components include the following:
Service Provider Concerns: Service Provider Concerns:
o Privacy of data monitored and/or stored on Intrusion Detection o Privacy of data monitored and/or stored on Intrusion Detection
Systems (IDSs) for attack detection. Systems (IDSs) for attack detection.
o Privacy of data monitored and stored on systems used to trace o Privacy of data monitored and stored on systems used to trace
traffic across a single network. traffic across a single network.
o Privacy of incident information stored on incident management o Privacy of incident information stored on incident management
systems participating in RID communications. systems participating in RID communications.
Customer Attached Networks Participating in RID with SP: Customer Attached Networks Participating in RID with SP:
o Customer networks may include an enterprise, educational, o Customer networks may include an enterprise, educational,
government, or other attached networks to an SP participating in government, or other attached networks to an SP participating in
RID and MUST be made fully aware of the security and privacy RID. Customers should review data handing policies to understand
considerations for using RID. how data will be protected by a service provider. This
information will enable customers to decide what types of data at
what sensitivity level can be shared with service providers. This
information could be used at the application layer to establish
sharing profiles for entities and groups, see Section 9.6.
o Customers MUST be informed of the security and privacy o Customers should request information on the security and privacy
considerations in place by their SP and the consortium of which considerations in place by their SP and the consortium of which
the SP is a member. the SP is a member. Customers should understand if their data
were to be forwarded, how might it be sanitized and how will it be
protected. Customers should also understand if limitations can be
placed on how any data they share with their SP will be used in
advance of sharing that data.
o Customers MUST be informed that their data can and will be sent to o Customers should be aware that their data can and will be sent to
other SPs in order to complete a trace unless an agreement stating other SPs in order to complete a trace unless an agreement stating
otherwise is made in the service level agreements between the otherwise is made in the service level agreements between the
customer and SP. customer and SP. Customers considering privacy options may limit
the use of this feature if they do not want the data forwarded.
Parties Involved in the Attack: Parties Involved in the Attack:
o Privacy of the identity of a host involved in an attack or any o Privacy of the identity of a host involved in an attack or any
indicators of compromise. indicators of compromise.
o Privacy of information such as the source and destination used for o Privacy of information such as the source and destination used for
communication purposes over the monitored or RID connected communication purposes over the monitored or RID connected
network(s). network(s).
o Protection of data from being viewed by intermediate parties in o Protection of data from being viewed by intermediate parties in
the path of an Request request MUST be considered. the path of an Request request should be considered.
Consortium Considerations: Consortium Considerations:
o System use restricted to security incident handling within the o System use restrictions for security incident handling within the
local region's definitions of appropriate traffic for the network local region's definitions of appropriate traffic. When
monitored and linked via RID in a single consortium also abiding participating in a consortium, appropriate use guidelines should
by the consortium's use guidelines. be agreed upon and entered into contracts.
o System use prohibiting the consortium's participating SPs from o System use prohibiting the consortium's participating SPs from
inappropriately tracing non-attack traffic to locate sources or inappropriately tracing traffic to locate sources or mitigate
mitigate traffic unlawfully within the jurisdiction or region. traffic unlawfully within the jurisdiction or region.
Inter-Consortium Considerations: Inter-Consortium Considerations:
o System use between peering consortiums MUST also adhere to any o System use between peering consortiums should consider any
government communication regulations that apply between those two government communication regulations that apply between those two
regions, such as encryption export and import restrictions. This regions, such as encryption export and import restrictions.
may include consortiums that are categorized as
"BetweenConsortiums" or "AcrossNationalBoundaries".
o System use between consortiums MUST NOT request traffic traces and o System use between consortiums SHOULD NOT request traffic traces
actions beyond the scope intended and permitted by law or inter- and actions beyond the scope intended and permitted by law or
consortium agreements. inter-consortium agreements.
o System use between consortiums classified as o System use between consortiums should consider national boundary
"AcrossNationalBoundaries" MUST respect national boundary issues issues and request limits in their appropriate system use
and limit requests to appropriate system use and not to achieve agreements. Appropriate use should include restrictions to
their own agenda to limit or restrict traffic that is otherwise prevent the use of the protocol to limit or restrict traffic that
permitted within the country in which the peering consortium is otherwise permitted within the country in which the peering
resides. consortium resides.
The security and privacy considerations listed above are for the The security and privacy considerations listed above are for the
consortiums, SPs, and enterprises to agree upon. The agreed-upon consortiums, SPs, and enterprises to agree upon. The agreed-upon
policies may be facilitated through use of the RIDPolicy class. Some policies may be facilitated through use of the RIDPolicy class and
privacy considerations are addressed through the RID guidelines for application layer options. Some privacy considerations are addressed
encryption and digital signatures as described in Section 9.1. through the RID guidelines for encryption and digital signatures as
described in Section 9.1.
RID is useful in determining the true source of an incident that RID is useful in determining the true source of an incident that
traverses multiple networks or to communicate security incidents and traverses multiple networks or to communicate security incidents and
automate the response. The information obtained from the automate the response. The information obtained from the
investigation may determine the identity of the source host or the SP investigation may determine the identity of the source host or the SP
used by the source of the traffic. It should be noted that the trace used by the source of the traffic. It should be noted that the trace
mechanism used across a single-SP may also raise privacy concerns for mechanism used across a single-SP may also raise privacy concerns for
the clients of the network. Methods that may raise concern include the clients of the network. Methods that may raise concern include
those that involve storing packets for some length of time in order those that involve storing packets for some length of time in order
to trace packets after the fact. Monitoring networks for intrusions to trace packets after the fact. Monitoring networks for intrusions
skipping to change at page 74, line 18 skipping to change at page 75, line 23
the system includes a request to block or rate-limit legitimate the system includes a request to block or rate-limit legitimate
traffic to prevent information from being shared between users on the traffic to prevent information from being shared between users on the
Internet (restricting access to online versions of papers) or Internet (restricting access to online versions of papers) or
restricting access from a competitor's product in order to sabotage a restricting access from a competitor's product in order to sabotage a
business. business.
Intra-consortium RID communications raise additional issues, Intra-consortium RID communications raise additional issues,
especially when the peering consortiums reside in different regions especially when the peering consortiums reside in different regions
or nations. Request messages and requested actions to mitigate or or nations. Request messages and requested actions to mitigate or
stop traffic must adhere to the appropriate use guidelines and yet stop traffic must adhere to the appropriate use guidelines and yet
prevent abuse of the system. First, the peering consortiums MUST prevent abuse of the system. First, the peering consortiums must
identify the types of traffic that can be traced between the borders identify the types of traffic that can be traced between the borders
of the participating SPs of each consortium. The traffic traced of the participating SPs of each consortium. The traffic traced
should be limited to security-incident-related traffic. Second, the should be limited to security-incident-related traffic. Second, the
traces permitted within one consortium if passed to a peering traces permitted within one consortium if passed to a peering
consortium may infringe upon the peering consortium's freedom of consortium may infringe upon the peering consortium's freedom of
information laws. An example would be a consortium in one country information laws. An example would be a consortium in one country
permitting a trace of traffic containing objectionable material, permitting a trace of traffic containing objectionable material,
outlawed within that country. The RID trace may be a valid use of outlawed within that country. The RID trace may be a valid use of
the system within the confines of that country's network border; the system within the confines of that country's network border;
however, it may not be permitted to continue across network however, it may not be permitted to continue across network
skipping to change at page 74, line 41 skipping to change at page 75, line 46
have the effect of improperly restricting access to data. A have the effect of improperly restricting access to data. A
continued trace into a second country may break the laws and continued trace into a second country may break the laws and
regulations of that nation. Any such traces MUST cease at the regulations of that nation. Any such traces MUST cease at the
country's border. country's border.
The privacy concerns listed in this section address issues among the The privacy concerns listed in this section address issues among the
trusted parties involved in a trace within an SP, a RID consortium, trusted parties involved in a trace within an SP, a RID consortium,
and peering RID consortiums. Data used for RID communications must and peering RID consortiums. Data used for RID communications must
also be protected from parties that are not trusted. This protection also be protected from parties that are not trusted. This protection
is provided through the authentication and encryption of documents as is provided through the authentication and encryption of documents as
they traverse the path of trusted servers. Each RID system MUST they traverse the path of trusted servers and the local security
perform a bi-directional authentication when sending a RID message controls in place for the incident management systems. Each RID
and use the public encryption key of the upstream or downstream peer system MUST perform a bi-directional authentication when sending a
to send a message or document over the network. This means that the RID message and use the public encryption key of the upstream or
document is decrypted and re-encrypted at each RID system via TLS downstream peer to send a message or document over the network. This
over the transport protocol [RFC6046-bis]. The RID messages may be means that the document is decrypted and re-encrypted at each RID
decrypted at each RID system in order to properly process the request system via TLS over a transport protocol such as [RFC6046-bis]. The
or relay the information. Today's processing power is more than RID messages may be decrypted at each RID system in order to properly
sufficient to handle the minimal burden of encrypting and decrypting process the request or relay the information. Today's processing
relatively small typical RID messages. power is more than sufficient to handle the minimal burden of
encrypting and decrypting relatively small typical RID messages.
9.6. Sharing Profiles and Policies
The application layer can be used to establish workflows and rulesets
specific to sharing profiles for entities or consortiums. The
profiles can leverage sharing agreements to restrict data types or
classifications of data that are shared. The level of information or
classification of data shared with any entity may be based on
protection levels offered by the receiving entity and periodic
validation of those controls. The profile may also indicate how far
information can be shared according to the entity and data type. The
profile can also support if requests to share data from an entity
must go directly to that entity.
In some cases, pre-defined sharing profiles will be possible. These
include any use case where an agreement is in place in advance of
sharing. Examples may be between clients and SPs, entities such as
partners, or consortiums. There may be other cases when sharing
profiles may not be established in advance, such as an organization
dealing with an incident who requires assistance from an entity that
have not worked with before. An organization may want to establish
sharing profiles specific to possible user groups to prepare for
possible incident scenarios. The user groups could include business
partners, industry peers, service providers, experts not part of a
service provider, law enforcement, or regulatory repotting bodies.
Workflows to approve transactions may be specific to sharing profiles
and data types. Application developers should include capabilities
to enable these decision points for users of the system.
Any expectations between entities to preserve the weight and
admissibility of evidence should be handled at the policy and
agreement level. A sharing profile may include notes or an indicator
for approvers in workflows to reflect if such agreements exist.
10. Security Considerations 10. Security Considerations
RID has many security requirements and considerations built into the RID has many security requirements and considerations built into the
design of the protocol, several of which are described in the design of the protocol, several of which are described in the
Security Requirements section. For a complete view of security, Security Requirements section. For a complete view of security,
considerations include the availability, confidentiality, and considerations include the availability, confidentiality, and
integrity concerns for the transport, storage, and exchange of integrity concerns for the transport, storage, and exchange of
information. information.
skipping to change at page 75, line 43 skipping to change at page 77, line 35
practices. practices.
The agreements between entities SHOULD also include a common The agreements between entities SHOULD also include a common
understanding of the usage of RID security, policy, and privacy understanding of the usage of RID security, policy, and privacy
options discussed in both the Security Requirements and Security options discussed in both the Security Requirements and Security
Considerations sections. The formality, requirements, and complexity Considerations sections. The formality, requirements, and complexity
of the agreements for the certificate policy, practices, supporting of the agreements for the certificate policy, practices, supporting
infrastructure, and the use of RID options SHOULD be decided by the infrastructure, and the use of RID options SHOULD be decided by the
entities or consortiums creating those agreements. entities or consortiums creating those agreements.
11. IANA Considerations 11. Internationalization Issues
The Node class identifies a host or network device. This document
re-uses the definition of Node from the IODEF specification
[RFC5070], Section 3.16. However, that document did not clearly
specify whether a NodeName could be an Internationalized Domain Name
(IDN). RID systems MUST treat the NodeName class as a domain name
slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName
class; if they do so, they MUST ensure that the domain name is
represented only using ASCII characters, i.e., all of its labels MUST
be either A-labels or NR-LDH labels [RFC5890] and internationalized
labels MUST be encoded as A-labels using the Punycode encoding
[RFC3492] as described in the protocol specification for
Internationalized Domain Names in Applications [RFC5891].
12. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
[XMLschema] conforming to a registry mechanism described in [XMLschema] conforming to a registry mechanism described in
[RFC3688]. [RFC3688].
Registration request for the iodef-rid namespace: Registration request for the iodef-rid namespace:
URI: urn:ietf:params:xml:ns:iodef-rid-2.0 URI: urn:ietf:params:xml:ns:iodef-rid-2.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: IESG.
document.
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the iodef-rid XML schema: Registration request for the iodef-rid XML schema:
URI: urn:ietf:params:xml:schema:iodef-rid-2.0 URI: urn:ietf:params:xml:schema:iodef-rid-2.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: IESG.
document.
XML: See Section 8, "RID Schema Definition", of this document. XML: See Section 8, "RID Schema Definition", of this document.
Request for the specified registry to be created and managed by IANA: Request for the specified registry to be created and managed by IANA:
Name of the registry:"XML Schemas Exchanged via RID" Name of the registry:"XML Schemas Exchanged via RID"
Namespace details: A registry entry for an XML Schema Transferred Namespace details: A registry entry for an XML Schema Transferred
via RID consists of: via RID consists of:
skipping to change at page 76, line 50 skipping to change at page 79, line 8
attribute as an enumerated value is represented by a URN or attribute as an enumerated value is represented by a URN or
URI. URI.
Specification URI: A URI [RFC3986] from which the registered Specification URI: A URI [RFC3986] from which the registered
specification can be obtained. The specification MUST be specification can be obtained. The specification MUST be
publicly available from this URI. publicly available from this URI.
Information that must be provided to assign a new value: The above Information that must be provided to assign a new value: The above
list of information. list of information.
Fields to record in the registry: Schema Name/Namespace/SchemaID/ Fields to record in the registry: Schema Name/Version/Namespace/
Specification URI Specification URI
Initial registry contents: See section 5.5.1. Initial registry contents: See section 5.5.1.
Allocation Policy: Expert Review [RFC5226] and Specification Allocation Policy: Expert Review [RFC5226] and Specification
Required [RFC5226]. Required [RFC5226].
The Designated Expert is expected to consult with the mile (Managed The Designated Expert is expected to consult with the mile (Managed
Incident Lightweight Exchange) working group or its successor if any Incident Lightweight Exchange) working group or its successor if any
such WG exists (e.g., via email to the working group's mailing list). such WG exists (e.g., via email to the working group's mailing list).
The Designated Expert is expected to retrieve the XML schema The Designated Expert is expected to retrieve the XML schema
specification from the provided URI in order to check the public specification from the provided URI in order to check the public
skipping to change at page 77, line 18 skipping to change at page 79, line 25
The Designated Expert is expected to consult with the mile (Managed The Designated Expert is expected to consult with the mile (Managed
Incident Lightweight Exchange) working group or its successor if any Incident Lightweight Exchange) working group or its successor if any
such WG exists (e.g., via email to the working group's mailing list). such WG exists (e.g., via email to the working group's mailing list).
The Designated Expert is expected to retrieve the XML schema The Designated Expert is expected to retrieve the XML schema
specification from the provided URI in order to check the public specification from the provided URI in order to check the public
availability of the specification and verify the correctness of the availability of the specification and verify the correctness of the
URI. An important responsibility of the Designated Expert is to URI. An important responsibility of the Designated Expert is to
ensure that the XML schema is appropriate for use in RID. ensure that the XML schema is appropriate for use in RID.
12. Summary Request for the specified registry to be created and managed by IANA:
Name of the registry:"RID Enumeration List"
The registry is intended to enable enumeration value additions to
attributes in the iodef-rid XML schema.
Fields to record in the registry: Attribute Name/Attribute Value/
Description
Initial registry content: none.
Allocation Policy: Expert Review [RFC5226]
The Designated Expert is expected to consult with the mile (Managed
Incident Lightweight Exchange) working group or its successor if any
such WG exists (e.g., via email to the working group's mailing list).
The Designated Expert is expected to review the request and validate
the appropriateness of the enumeration for the attribute. If a draft
specification is associated with the request, it MUST be reviewed by
the Designated Expert.
13. Summary
Security incidents have always been difficult to trace as a result of Security incidents have always been difficult to trace as a result of
the spoofed sources, resource limitations, and bandwidth utilization the spoofed sources, resource limitations, and bandwidth utilization
problems. Incident response is often slow even when the IP address problems. Incident response is often slow even when the IP address
is known to be valid because of the resources required to notify the is known to be valid because of the resources required to notify the
responsible party of the attack and then to stop or mitigate the responsible party of the attack and then to stop or mitigate the
attack traffic. Methods to identify and trace attacks near real time attack traffic. Methods to identify and trace attacks near real time
are essential to thwarting attack attempts. SPs need policies and are essential to thwarting attack attempts. SPs need policies and
automated methods to combat the hacker's efforts. SPs need automated automated methods to combat the hacker's efforts. SPs need automated
monitoring and response capabilities to identify and trace attacks monitoring and response capabilities to identify and trace attacks
skipping to change at page 77, line 45 skipping to change at page 80, line 26
is accomplished through the use of flexible IODEF XML-based documents is accomplished through the use of flexible IODEF XML-based documents
passed between IHSs or RID systems. A Request is communicated to an passed between IHSs or RID systems. A Request is communicated to an
upstream SP and may result in an upstream trace or in an action to upstream SP and may result in an upstream trace or in an action to
stop or mitigate the attack traffic. The messages are communicated stop or mitigate the attack traffic. The messages are communicated
among peers with security inherent to the RID messaging scheme among peers with security inherent to the RID messaging scheme
provided through existing standards such as XML encryption and provided through existing standards such as XML encryption and
digital signatures. Policy information is carried in the RID message digital signatures. Policy information is carried in the RID message
itself through the use of the RIDPolicy. RID provides the timely itself through the use of the RIDPolicy. RID provides the timely
communication among SPs, which is essential for incident handling. communication among SPs, which is essential for incident handling.
13. References 14. References
13.1. Normative References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002. March 2002.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
the Use of Extensible Markup Language (XML)
within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3741] Boyer, J., Eastlake, D., and J. Reagle, "Exclusive XML
Canonicalization, Version 1.0", RFC 3741, March 2004.
[RFC4051] Eastlake, D., "Additional XML Security Uniform Resource [RFC4051] Eastlake, D., "Additional XML Security Uniform Resource
Identifiers (URIs)", RFC 4051, April 2005. Identifiers (URIs)", RFC 4051, April 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, September 2006.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
December 2007. December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization", Attribute Certificate Profile for Authorization",
RFC 5755, January 2010. RFC 5755, January 2010.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6046-bis] [RFC6046-bis]
Trammell, B., "Transport of Real-time Inter-network Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages", January 2012, <http:// Defense (RID) Messages", January 2012, <http://
tools.ietf.org/html/draft-ietf-mile-rfc6046-bis-05>. tools.ietf.org/html/draft-ietf-mile-rfc6046-bis-07>.
[XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and
F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C
Recommendation XML 1.0, November 2008, Recommendation XML 1.0, November 2008,
<http://www.w3.org/TR/xml/>. <http://www.w3.org/TR/xml/>.
[XMLNames] [XMLCanon]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0,
Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C December 2001, <http://www.w3.org/TR/xml-c14n>.
Recommendation , December 2009,
<http://www.w3.org/TR/xml-names/>.
[XMLencrypt] [XMLencrypt]
Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Imaura, T., Dillaway, B., and E. Simon, "XML Encryption
Syntax and Processing", W3C Recommendation , Syntax and Processing", W3C Recommendation ,
December 2002, <http://www.w3.org/TR/xmlenc-core/>. December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., [XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1: Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1:
Structures", W3C Recommendation Second Edition, Structures", W3C Recommendation Second Edition,
December 2010, <http://www.w3.org/TR/xpath20/>. December 2010, <http://www.w3.org/TR/xpath20/>.
[XMLschema]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C Recommendation Second
Edition, October 2004,
<http://www.w3.org/TR/xmlschema-1/>.
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E.
Simon, "XML-Signature Syntax and Processing", W3C Simon, "XML-Signature Syntax and Processing", W3C
Recommendation Second Edition, June 2008, Recommendation Second Edition, June 2008,
<http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/xmldsig-core/>.
[XMLSigBP] [XMLSigBP]
Hirsch, F. and P. Datta, "XML-Signature Best Practices", Hirsch, F. and P. Datta, "XML-Signature Best Practices",
W3C Recommendation , August 2011, W3C Recommendation , August 2011,
<http://www.w3.org/TR/xmldsig-bestpractices/>. <http://www.w3.org/TR/xmldsig-bestpractices/>.
13.2. Informative References 14.2. Informative References
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996. BCP 6, RFC 1930, March 1996.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
November 2003. November 2003.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001. RFC 3080, March 2001.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6045, November 2010. RFC 6045, November 2010.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, March 2011. Algorithms", RFC 6194, March 2011.
[CVRF] Schiffman, M., "The Common Vulnerability Reporting [XMLNames]
Framework (CVRF)", The Industry Consortium for Advancement Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
of Security on the Internet (ICASI) v1.0, May 2011, Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C
<http://www.icasi.org/cvrf>. Recommendation , December 2009,
<http://www.w3.org/TR/xml-names/>.
Acknowledgements Acknowledgements
Many thanks to colleagues and the Internet community for reviewing Many thanks to colleagues and the Internet community for reviewing
and commenting on the document as well as providing recommendations and commenting on the document as well as providing recommendations
to simplify and secure the protocol: Robert K. Cunningham, Ph.D, to simplify and secure the protocol: Robert K. Cunningham, Ph.D,
Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve
Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt, Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt,
Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra
G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir
 End of changes. 89 change blocks. 
270 lines changed or deleted 411 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/