idnits 2.17.1 draft-moriarty-post-inch-rid-transport-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2010) is 5048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-12) exists of draft-moriarty-post-inch-rid-11 -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) == Outdated reference: A later version (-14) exists of draft-saintandre-tls-server-id-check-06 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INCH Working Group K. Moriarty 3 Internet-Draft RSA 4 Intended status: Informational B. Trammell 5 Expires: January 1, 2011 ETH Zurich 6 June 30, 2010 8 Transport of Real-time Inter-network Defense (RID) Messages 9 draft-moriarty-post-inch-rid-transport-03.txt 11 Abstract 13 The Incident Object Description Exchange Format (IODEF) defines a 14 common XML format for document exchange, and Realtime Internetwork 15 Defense (RID) defines extensions to IODEF intended for the 16 cooperative handling of security incidents within consortia of 17 network operators and enterprises. This document specifies a 18 transport protocol for RID based upon the passing of RID messages 19 over HTTP/TLS. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 1, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 The Incident Object Description Exchange Format (IODEF) [RFC5070] 56 describes an XML document format for the purpose of exchanging data 57 between Computer Security Incident Response Teams (CSIRTs) or those 58 responsible for security incident handling for network providers 59 (NPs). The defined document format provides an easy way for CSIRTs 60 to exchange data in a way which can be easily parsed. 62 IODEF defines a message format, not a transport protocol, as the 63 sharing of messages is assumed to be out of scope in order to allow 64 CSIRTs to exchange and store messages in a way most suited to their 65 established incident handling processes. However, Real-time Inter- 66 network Defense (RID) [I-D.moriarty-post-inch-rid] do require a 67 specification of a transport protocol to ensure interoperability 68 among members in a RID consortium. This document specifies the 69 transport of RID messages within HTTP [RFC2616] Request and Response 70 messages transported over TLS [RFC5246] (herein, HTTP/TLS). Note 71 that any IODEF message may also be transported using this mechanism, 72 by sending it as a RID Report message. 74 2. Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 3. Transmission of RID Messages over HTTP/TLS 82 This section specifies the details of the transport of RID messages 83 over HTTP/TLS. In this arrangement, each RID server is both an HTTP/ 84 TLS server and an HTTP/TLS Client. When a RID message must be sent, 85 the sending RID system connects to the receiving RID system and sends 86 the message, optionally receiving a message in reply. All RID 87 systems MUST be prepared to accept HTTP/TLS connections from any RID 88 peer with which it communicates, in order to support callback for 89 delayed replies (see below). 91 BCP 56 [RFC3205] contains a number of important considerations when 92 using HTTP for application protocols. These include the size of the 93 payload for the application, whether the application will use a web 94 browser, whether the protocol should be defined on a port other than 95 80, and if the security provided through HTTP/TLS suits the needs of 96 the new application. 98 It is acknowledged within the scope of these concerns that HTTP/TLS 99 is not ideally suited for RID transport, as the former is a client- 100 server protocol and the latter a message-exchange protocol; however, 101 the ease of implementation of RID systems over HTTP/TLS outweighs 102 these concerns. Consistent with BCP 56, RID systems will listen for 103 TCP connections on port [IANA NOTE: assigned port goes here]. Every 104 RID system participating in a consortium MUST listen for HTTP/TLS 105 connections on the assigned port. 107 All RID messages sent in HTTP Requests MUST be sent using the POST 108 with a Request-URI of /; additional Request-URI paths are reserved 109 for future use by RID. 111 Table 1 lists the allowable RID message types in an HTTP Response for 112 a given RID message type in the Request. A RID system MUST be 113 prepared to handle an HTTP Response of the given type(s) when sending 114 the corresponding HTTP Request. A RID system MUST NOT send an HTTP 115 Response containing any RID message other than the one corresponding 116 to the one sent in the HTTP Request. 118 As the queries and replies in a RID message exchange may be 119 significantly separated in time, the receiving RID system MAY return 120 202 Accepted, terminate the connection, and connect to the requesting 121 RID system and sending the RID reply in an HTTP Request at a later 122 time. This mechanism is referred to in this document as "RID 123 callback". When performing RID callback, a responding system MUST 124 connect to the network- and transport-layer addresses from which the 125 original request was sent; there is no mechanism in RID for 126 redirected callback. 128 While a RID system SHOULD return the reply in an HTTP Response if it 129 is available immediately or within a generally accepted HTTP client 130 time out (about thirty seconds), this is not mandatory, and as such 131 RID systems MUST be prepared for a query to be met with a 202 132 Accepted, an empty Response body, a connection termination and a 133 callback. Note that all RID messages require a response from the 134 receiving RID system, so a sending RID system can expect either an 135 immediate response or a callback. 137 RID systems accepting a callback message in an HTTP Request MUST 138 return 202 Accepted. 140 Table 1 lists the allowable request/response pairs for RID. 142 +----------------------+----------+--------+----------------------+ 143 | Request RID type | Callback | Result | Response RID type | 144 +----------------------+----------+--------+----------------------+ 145 | TraceRequest | | 200 | RequestAuthorization | 146 | TraceRequest | | 200 | Result | 147 | TraceRequest | | 202 | [empty] | 148 | RequestAuthorization | X | 202 | [empty] | 149 | Result | X | 202 | [empty] | 150 | Investigation | | 200 | Result | 151 | Investigation | | 202 | [empty] | 152 | Report | X | 202 | [empty] | 153 | IncidentQuery | | 200 | Report | 154 | IncidentQuery | | 202 | [empty] | 155 +----------------------+----------+--------+----------------------+ 157 Table 1 159 For security purposes, RID systems SHOULD NOT return 3xx Redirect 160 response codes, and MUST NOT follow any 3xx Redirect. When a RID 161 System's address changes, contact point information within the 162 consortium must be updated out of band. 164 If a RID system receives an improper RID message in an HTTP Request, 165 it MUST return an appropriate 4xx Client Error result code to the 166 requesting RID system. If a RID system cannot process a RID message 167 received in an HTTP Request due to an error on its own side, it MUST 168 return an appropriate 5xx Server Error result code to the requesting 169 RID system. 171 Note that HTTP provides no mechanism for signaling to a server that a 172 response body is not a valid RID message. If an RID system receives 173 and improper RID message in an HTTP Response, or cannot process a RID 174 message received in an HTTP Response due to an error on its own side, 175 it MUST log the error and present it to the RID system administrator 176 for handling; the error logging format is an implementation detail 177 and is considered out of scope for this specification. 179 RID systems MUST support and SHOULD use HTTP/1.1 persistent 180 connections as described in [RFC2616]. RID systems MUST support 181 chunked transfer encoding on the HTTP server side to allow the 182 implementation of clients that do not need to precalculate message 183 sizes before constructing HTTP headers. 185 RID systems MUST use TLS for confidentiality, identification, and 186 strong mutual authentication as in [RFC2818]; see Section 4 below for 187 details. 189 4. Security Considerations 191 All security considerations of related documents MUST be considered, 192 especially the Incident Object Description Exchange Format (IODEF) 193 [RFC5070] and Real-time Inter-network Defense (RID) 194 [I-D.moriarty-post-inch-rid]. The transport described herein is 195 built on the foundation of these documents; the security 196 considerations contained therein are incorporated by reference. 198 For transport confidentiality, identification, and authentication, 199 TLS with mutual authentication MUST be used to secure the HTTP 200 connection as in [RFC2818]. The session MUST use non-NULL cypher 201 suites for authentication, integrity, and confidentiality; sessions 202 MAY be renegotiated within these constraints. Although TLS 203 implementations typically support the older SSL protocol, a RID peer 204 MUST NOT request, offer, or use SSL 2.0 , due to known security 205 vulnerabilities in this protocol; see Appendix E of [RFC5246] for 206 more. 208 Each RID consortium SHOULD use a trusted public key infrastructure 209 (PKI) to manage identities for RID systems participating in TLS 210 connections. At minimum, each RID system MUST trust a set of X.509 211 Issuer identities ("Certificate Authorities") to authenticate RID 212 system peers with which it is willing to exchange information, and/or 213 a specific white list of X.509 Subject identities of RID system peers 214 directly. 216 RID systems MUST provide for the verification of the identity of a 217 RID system peer presenting a valid and trusted certificate, by 218 verifying the fully qualified domain name or other network-layer 219 identifier against that stored in the certificate, if available. 220 More information on best practices in peer identity verification is 221 available in [I-D.saintandre-tls-server-id-check]. 223 5. IANA Considerations 225 Consistent with BCP 56 [RFC3205], since RID over HTTP/TLS is a 226 substantially new service, and should be controlled at the consortium 227 member network's border differently than HTTP/TLS, it requires a new 228 port number. IANA has assigned port [IANA NOTE: assign port number 229 here]/tcp to RID with service name [IANA NOTE: assign service name 230 here; request 'rid'] over HTTP/TLS. 232 6. References 233 6.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 239 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 240 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 242 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 244 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 245 Object Description Exchange Format", RFC 5070, 246 December 2007. 248 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 249 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 251 [I-D.moriarty-post-inch-rid] 252 Moriarty, K., "Real-time Inter-network Defense", 253 draft-moriarty-post-inch-rid-11 (work in progress), 254 April 2010. 256 6.2. Informative References 258 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 259 RFC 3205, February 2002. 261 [I-D.saintandre-tls-server-id-check] 262 Saint-Andre, P. and J. Hodges, "Representation and 263 Verification of Domain-Based Application Server Identity 264 in Certificates Used with Transport Layer Security", 265 draft-saintandre-tls-server-id-check-06 (work in 266 progress), June 2010. 268 Authors' Addresses 270 Kathleen M. Moriarty 271 RSA, The Security Division of EMC 272 174 Middlesex Turnpike 273 Bedford MA 01730 274 United States 276 Email: Moriarty_Kathleen@EMC.com 277 Brian H. Trammell 278 Swiss Federal Institute of Technology Zurich 279 Gloriastrasse 35 280 8092 Zurich 281 Switzerland 283 Phone: +41 44 632 70 13 284 Email: trammell@tik.ee.ethz.ch