draft-ietf-mile-rfc6045-bis-08.txt   draft-ietf-mile-rfc6045-bis-09.txt 
MILE Working Group K. Moriarty MILE Working Group K. Moriarty
Internet-Draft EMC Internet-Draft EMC
Obsoletes: 6045 (if approved) January 23, 2012 Obsoletes: 6045 (if approved) January 25, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: July 26, 2012 Expires: July 28, 2012
Real-time Inter-network Defense (RID) Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-08.txt draft-ietf-mile-rfc6045-bis-09.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 26, 2012. This Internet-Draft will expire on July 28, 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . 24
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. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6. Including IODEF or other XML Documents . . . . . . . . . . 29 5.6. Including IODEF or other XML Documents . . . . . . . . . . 30
5.6.1. Including XML Documents in RID . . . . . . . . . . . . 30 5.6.1. Including XML Documents in RID . . . . . . . . . . . . 31
6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. RID Messages . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 33 6.2. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 34
6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4. Report . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 39 7. RID Communication Exchanges . . . . . . . . . . . . . . . . . 39
7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 40 7.1. Upstream Trace Communication Flow . . . . . . . . . . . . 41
7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 42 7.1.1. RID TraceRequest Example . . . . . . . . . . . . . . . 43
7.1.2. Acknowledgement Message Example . . . . . . . . . . . 46 7.1.2. Acknowledgement Message Example . . . . . . . . . . . 47
7.1.3. Result Message Example . . . . . . . . . . . . . . . . 47 7.1.3. Result Message Example . . . . . . . . . . . . . . . . 48
7.2. Investigation Request Communication Flow . . . . . . . . . 50 7.2. Investigation Request Communication Flow . . . . . . . . . 51
7.2.1. Investigation Request Example . . . . . . . . . . . . 51 7.2.1. Investigation Request Example . . . . . . . . . . . . 52
7.2.2. Acknowledgement Message Example . . . . . . . . . . . 53 7.2.2. Acknowledgement Message Example . . . . . . . . . . . 54
7.3. Report Communication Flow . . . . . . . . . . . . . . . . 54 7.3. Report Communication Flow . . . . . . . . . . . . . . . . 55
7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 54 7.3.1. Report Example . . . . . . . . . . . . . . . . . . . . 55
7.4. Query Communication Flow . . . . . . . . . . . . . . . . . 56 7.4. Query Communication Flow . . . . . . . . . . . . . . . . . 57
7.4.1. Query Example . . . . . . . . . . . . . . . . . . . . 57 7.4.1. Query Example . . . . . . . . . . . . . . . . . . . . 58
8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 58 8. RID Schema Definition . . . . . . . . . . . . . . . . . . . . 59
9. Security Requirements . . . . . . . . . . . . . . . . . . . . 62 9. Security Requirements . . . . . . . . . . . . . . . . . . . . 63
9.1. XML Digital Signatures and Encryption . . . . . . . . . . 62 9.1. XML Digital Signatures and Encryption . . . . . . . . . . 63
9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 66 9.2. Message Transport . . . . . . . . . . . . . . . . . . . . 67
9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 67 9.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 68
9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 68 9.3.1. Authentication . . . . . . . . . . . . . . . . . . . . 69
9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 69 9.3.2. Multi-Hop Request Authentication . . . . . . . . . . . 70
9.4. Consortiums and Public Key Infrastructures . . . . . . . . 70 9.4. Consortiums and Public Key Infrastructures . . . . . . . . 71
9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 71 9.5. Privacy Concerns and System Use Guidelines . . . . . . . . 72
9.6. Sharing Profiles and Policies . . . . . . . . . . . . . . 76 9.6. Sharing Profiles and Policies . . . . . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77
11. Internationalization Issues . . . . . . . . . . . . . . . . . 77 11. Internationalization Issues . . . . . . . . . . . . . . . . . 78
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
14.1. Normative References . . . . . . . . . . . . . . . . . . . 80 14.1. Normative References . . . . . . . . . . . . . . . . . . . 81
14.2. Informative References . . . . . . . . . . . . . . . . . . 82 14.2. Informative References . . . . . . . . . . . . . . . . . . 83
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84
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 18, line 28 skipping to change at page 18, line 28
+------------------------+ +------------------------+
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 and
The base definition of this class is reused from the IODEF the usage is determined by the MsgDestination attribute. The base
specification [RFC5070], Section 3.16. See Section 11 of this definition of this class is reused from the IODEF specification
document for Internationalization considerations. [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
skipping to change at page 22, line 12 skipping to change at page 22, line 12
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 One. REQUIRED. ENUM. The type of RID message sent. The five
types of messages are described in Section 4.2 and can be noted types of messages are described in Section 4.2 and can be noted
as one of the six selections below, where a Request is set to as 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 1. TraceRequest. This Request message may be used to initiate
TraceRequest or to continue a TraceRequest to an upstream a 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 2. Acknowledgement. This message is sent to the initiating
system from each of the upstream RID systems to provide RID 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.
4. Result. This message indicates that the source of the attack 3. Result. This message indicates that the source of the
was located and the message is sent to the initiating RID attack was located and the message is sent to the
system through the RID systems in the path of the trace. initiating RID system through the RID systems in the path
of the trace.
5. InvestigationRequest. This Request message type is used when 4. InvestigationRequest. This Request message type is used
the source of the traffic is believed to be valid. The when the source of the traffic is believed to be valid.
purpose of the InvestigationRequest is to leverage the The purpose of the InvestigationRequest is to leverage the
existing peer or consortium relationships in order to notify existing peer or consortium relationships in order to
the SP closest to the source of the valid traffic that some notify the SP closest to the source of the valid traffic
event occurred, which may be a security-related incident. that some event occurred, which may be a security-related
incident.
6. Report. This message is used to report a security incident, 5. Report. This message is used to report a security
for which no action is requested in the IODEF Expectation incident, for which no action is requested in the IODEF
class. This may be used for the purpose of correlating attack Expectation class. This may be used for the purpose of
information by CSIRTs, statistics and trending information, correlating attack information by CSIRTs, statistics and
etc. trending information, etc.
7. Query. This message is used to request information from a 6. Query. This message is used to request information from a
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
One. REQUIRED. ENUM. The destination required at this level One. REQUIRED. ENUM. The destination required at this level
skipping to change at page 23, line 15 skipping to change at page 23, line 17
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.
1. RIDSystem. The address listed in the Node element of the 1. RIDSystem. The address listed in the Node element of the
RIDPolicy class is the next upstream RID system that will RIDPolicy class is the next upstream RID system that will
receive the RID message. receive the RID message. If NodeName element of the Node
class is used, it contains a DNS domain name. The
originating RID system is required to check that this
domain name resolves to the IP address to which the RID
message is sent. This check may be performed in advance of
sending the message and the result saved for future use
with additional RID messages.
2. SourceOfIncident. The address listed in the Node element 2. SourceOfIncident. The Address element of the Node element
of the RIDPolicy class is the incident source. The IP contains the IP address of the incident source, and the
NodeName element of the Node class is not used. The IP
address is used to determine the path of systems accepting address is used to determine the path of systems accepting
RID communications that will be used to find the closest RID communications that will be used to find the closest
RID system to the source of an attack in which the IP RID system to the source of an attack in which the IP
address used by the source is believed to be valid and a address used by the source is believed to be valid and a
Request message with MsgDst set to InvestigationRequest is Request message with MsgDst set to InvestigationRequest is
used. This is not to be confused with the IncidentSource used. This is not to be confused with the IncidentSource
class, as the defined value here is from an initial trace class, as the defined value here is from an initial trace
or investigation Request, not the source used in a Result or investigation Request, not the source used in a Result
message. message.
3. ext-value. An escape value used to extend this attribute. 3. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. All extensions shall specify the contents and meaning of
the Node element of RIDPolicy. If the NodeName element of
Node is used by an extension, NodeName may contain an
Internationalized Domain Name (IDN) and that IDN is
required to satisfy the requirements in [RFC5890]. It is
strongly recommended that RID Systems satisfy those IDN
requirements via appropriate use of the DNS as opposed to
implementing their own checks for these requirements. For
example, an extension could use both a NodeName and an IP
address to which the NodeName resolves. See IODEF
[RFC5070], Section 5.1 on extensibility.
MsgType-ext MsgType-ext
OPTIONAL. STRING. A means by which to extend the MsgType OPTIONAL. STRING. A means by which to extend the MsgType
attribute. See IODEF [RFC5070], Section 5.1. attribute. See IODEF [RFC5070], Section 5.1.
MsgDestination-ext MsgDestination-ext
OPTIONAL. STRING. A means by which to extend the OPTIONAL. STRING. A means by which to extend the
MsgDestination attribute. See IODEF [RFC5070], Section 5.1 MsgDestination attribute. See IODEF [RFC5070], Section 5.1
skipping to change at page 27, line 14 skipping to change at page 27, line 26
Acknowledgement message being generated. Acknowledgement message being generated.
4. ext-value. An escape value used to extend this attribute. 4. ext-value. An escape value used to extend this attribute.
See IODEF [RFC5070], Section 5.1. See IODEF [RFC5070], Section 5.1.
Justification Justification
OPTIONAL. ENUM. Provides a reason for a Denied or Pending OPTIONAL. ENUM. Provides a reason for a Denied or Pending
message. message.
2. SystemResource. A resource issue exists on the systems 1. SystemResource. A resource issue exists on the systems
that would be involved in the request. that would be involved in the request.
3. Authentication. The enveloped digital signature [RFC3275] 2. Authentication. The enveloped digital signature
failed to validate. [RFC3275] failed to validate.
4. AuthenticationOrigin. The detached digital signature for 3. AuthenticationOrigin. The detached digital signature
the original requestor on the RecordItem entry failed to for the original requestor on the RecordItem entry
validate. failed to validate.
5. Encryption. Unable to decrypt the request, report, or 4. Encryption. Unable to decrypt the request, report, or
query. query.
6. UnrecognizedFormat. The format of the provided document 5. UnrecognizedFormat. The format of the provided document
was unrecognized. was unrecognized.
7. CannotProcess. The document could not be processed. 6. CannotProcess. The document could not be processed.
Reasons may include legal or policy decisions. Resolution Reasons may include legal or policy decisions.
may require communication outside of this protocol to Resolution may require communication outside of this
resolve legal or policy issues. No further messages SHOULD protocol to resolve legal or policy issues. No further
be sent until resolved. messages SHOULD be sent until resolved.
8. Other. There were other reasons this request could not be 7. Other. There were other reasons this request could not
processed. be processed.
9. ext-value. An escape value used to extend this attribute. 8. ext-value. An escape value used to extend this
See IODEF [RFC5070], Section 5.1. attribute. 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
AuthorizationStatus attribute. See IODEF [RFC5070], Section AuthorizationStatus attribute. See IODEF [RFC5070], Section
5.1. 5.1.
Justification-ext Justification-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 37 skipping to change at page 28, line 48
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
Zero or many. The Node class is used to identify a system Zero or many. The Node class is used to identify a system
identified as part of an incident. The base definition of this identified as part of an incident. The Address element of the
class from the IODEF [RFC5070] can be expanded to include other Node element contains the IP address of the system. If the
identifiers, Section 3.16. NodeName element of the Node class is used, it contains a DNS
domain name that has been checked to ensure that it resolved to
that IP address when the check was performed. The base
definition of this class from the IODEF [RFC5070] can be
expanded to include other 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.
skipping to change at page 77, line 43 skipping to change at page 78, line 43
entities or consortiums creating those agreements. entities or consortiums creating those agreements.
11. Internationalization Issues 11. Internationalization Issues
The Node class identifies a host or network device. This document The Node class identifies a host or network device. This document
re-uses the definition of Node from the IODEF specification re-uses the definition of Node from the IODEF specification
[RFC5070], Section 3.16. However, that document did not clearly [RFC5070], Section 3.16. However, that document did not clearly
specify whether a NodeName could be an Internationalized Domain Name specify whether a NodeName could be an Internationalized Domain Name
(IDN). RID systems MUST treat the NodeName class as a domain name (IDN). RID systems MUST treat the NodeName class as a domain name
slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName
class; if they do so, they MUST ensure that the domain name is class; if they do so, the UTF-8 representation of the domain name
represented only using ASCII characters, i.e., all of its labels MUST MUST be used, i.e., all of the domain name's labels MUST be U-labels
be either A-labels or NR-LDH labels [RFC5890] and internationalized expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
labels MUST be encoded as A-labels using the Punycode encoding used. A RID system can convert between A-labels and U-labels by
[RFC3492] as described in the protocol specification for using the Punycode encoding [RFC3492] for A-labels as described in
Internationalized Domain Names in Applications [RFC5891]. the protocol specification for Internationalized Domain Names in
Applications [RFC5891].
12. IANA Considerations 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
skipping to change at page 80, line 37 skipping to change at page 81, line 37
14.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 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. 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 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003. (IDNA)", RFC 3492, March 2003.
skipping to change at page 83, line 27 skipping to change at page 84, line 23
[XMLNames] [XMLNames]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C
Recommendation , December 2009, Recommendation , December 2009,
<http://www.w3.org/TR/xml-names/>. <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 improve, simplify, and secure the protocol: Steve Bellovin, David
Cynthia D. McLain, Dr. William Streilein, Iljitsch van Beijnum, Steve Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman
Bellovin, Yuri Demchenko, Jean-Francois Morfin, Stephen Northcutt, Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine
Jeffrey Schiller, Brian Trammell, Roman Danyliw, Tony Tauber, Sandra Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin,
G. Dykes, Ph.D., Katherine Goodier, Ph.D., Tony Rutkowski, Damir Stephen Northcutt, William Streilein, Damir Rajnovic, Tony Rutkowski,
Rajnovic, David Black, Paul Cichonski, David Waltermire, Richard Peter Saint-Andre Jeffrey Schiller, Robert Sparks, Richard Struse,
Struse, Thomas Millar, and Harold Booth. Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and
David Waltermire.
Author's Address Author's Address
Kathleen M. Moriarty Kathleen M. Moriarty
EMC Corporation EMC Corporation
176 South Street 176 South Street
Hopkinton, MA Hopkinton, MA
United States United States
Phone: Phone:
 End of changes. 30 change blocks. 
110 lines changed or deleted 133 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/