idnits 2.17.1 draft-ietf-mile-rfc6046-bis-09.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6046, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 25, 2012) is 4437 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-11) exists of draft-ietf-mile-rfc6045-bis-08 -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 6046 (Obsoleted by RFC 6546) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Obsoletes: 6046 (if approved) January 25, 2012 5 Intended status: Standards Track 6 Expires: July 28, 2012 8 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ 9 TLS 10 draft-ietf-mile-rfc6046-bis-09.txt 12 Abstract 14 The Incident Object Description Exchange Format (IODEF) defines a 15 common XML format for document exchange, and Realtime Internetwork 16 Defense (RID) defines extensions to IODEF intended for the 17 cooperative handling of security incidents within consortia of 18 network operators and enterprises. This document specifies a 19 application-layer protocol for RID based upon the passing of RID 20 messages over HTTP/TLS. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 28, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 The Incident Object Description Exchange Format (IODEF) [RFC5070] 57 describes an XML document format for the purpose of exchanging data 58 between Computer Security Incident Response Teams (CSIRTs) or those 59 responsible for security incident handling for service providers 60 (SPs). The defined document format provides an easy way for CSIRTs 61 to exchange data in a way which can be easily parsed. 63 IODEF defines a message format, not a protocol, as the sharing of 64 messages is assumed to be out of scope in order to allow CSIRTs to 65 exchange and store messages in a way most suited to their established 66 incident handling processes. However, Real-time Inter-network 67 Defense (RID) [I-D.ietf-mile-rfc6045-bis] do require a specification 68 of a protocol to ensure interoperability among members in a RID 69 consortium. This document specifies the transport of RID messages 70 within HTTP [RFC2616] Request and Response messages over TLS 71 [RFC5246] (herein, HTTP/TLS). Note that any IODEF message may also 72 be transported using this mechanism, by sending it as a RID Report 73 message. 75 1.1. Changes from RFC6046 77 This document contains the following changes with respect to its 78 predecessor [RFC6046]: 80 o The intended status of the document is now Standards Track. 81 o The document is updated to refer to the updated RID specification, 82 [I-D.ietf-mile-rfc6045-bis], where appropriate. 83 o Language regarding the use of HTTP/1.1 and TCP ports for RID 84 transport is clarified. 85 o The RID-Callback-Token entity header field is added to allow 86 matching of RID replies during callback, independent of the 87 content of the underlying RID message. 88 o The minimum required version of TLS is upgraded to 1.1, and the 89 minimum recommend version to 1.2. 90 o Language regarding PKI for RID over HTTPS is clarified, and 91 updated to refer to [RFC6125]. 93 This document, when published, obsoletes [RFC6046] and moves it to 94 Historic status. 96 2. Terminology and Normative Sections 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 RID systems participating in a consortium are required to fully 103 implement the protocol in Section 3 in order to interoperate within 104 the consortium; the remainder of this document is informative, and 105 provides helpful background or explanatory information. 107 3. Transmission of RID Messages over HTTP/TLS 109 This section specifies the details of the transport of RID messages 110 [I-D.ietf-mile-rfc6045-bis] over HTTP/TLS. In this arrangement, each 111 RID server is both an HTTP/TLS server and an HTTP/TLS client. When a 112 RID message is sent, the sending RID system connects to the receiving 113 RID system and sends the message, optionally receiving a message in 114 reply. All RID systems MUST be prepared to accept HTTP/TLS 115 connections from any RID peer with which it communicates, in order to 116 support callback for delayed replies (see below). 118 BCP 56 [RFC3205] contains a number of important considerations when 119 using HTTP for application protocols. These include the size of the 120 payload for the application, whether the application will use a web 121 browser, whether the protocol should be defined on a port other than 122 80, and if the security provided through HTTP/TLS suits the needs of 123 the new application. 125 It is acknowledged within the scope of these concerns that HTTP/TLS 126 is not ideally suited for RID transport, as the former is a client- 127 server protocol and the latter a message-exchange protocol; however, 128 the ease of implementation of RID systems over HTTP/TLS outweighs 129 these concerns. Consistent with BCP 56, RID systems listen for TCP 130 connections on port 4590 (see Section 5). Every RID system 131 participating in a consortium SHOULD listen for HTTP/TLS connections 132 on the assigned port. RID systems MAY be configurable to listen on 133 ports other than the well-known port; this configuration is out of 134 scope for this specification. RID systems SHOULD NOT use TCP port 135 443 (the standard port for HTTP over TLS) for RID messages, to avoid 136 confusing standard HTTP/TLS servers for RID systems. 138 RID systems MUST implement all REQUIRED functionality for HTTP/1.1 139 [RFC2616]. All RID messages sent in HTTP Requests MUST be sent using 140 the POST method with a Request-URI of '/'. As RID documents are XML, 141 the RID media type is 'text/xml'; i.e., the 'Content-type' Request 142 and Response headers MUST be 'text/xml'. As RID messages MUST be 143 sent using the POST method, the GET and HEAD methods have no 144 particular meaning on a RID system; a RID system SHOULD answer 'GET 145 /' or 'HEAD /' with 204 No Content. Other Request-URIs are reserved 146 for future use; any access to Request-URIs other than '/' by any 147 method on a RID system SHOULD return the appropriate HTTP error (404 148 Not Found). 150 Since the content of RID messages is essentially declarative, a RID 151 system interrupted during transport MAY simply repeat the 152 transaction; the sending of a RID message is idempotent. 154 As the queries and replies in a RID message exchange may be 155 significantly separated in time, RID over HTTP/TLS supports a 156 callback mechanism. In this mechanism, the receiving RID system MAY 157 return a 202 Accepted response, called a RID callback, instead of a 158 RID message. The RID callback MUST contain a zero-length entity body 159 and a 'RID-Callback-Token' entity header field, itself containing an 160 unique token generated by the receiving RID system. 162 The RID-Callback-Token is an opaque, whitespace-free string of up to 163 255 printable ASCII characters that MUST uniquely identify the 164 callback among all callbacks from the receiving RID system to the 165 sending RID system. Due to the amount of time that may be required 166 to generate a RID Result or Report response, there is no upper bound 167 on the time period for this uniqueness requirement. The RID- 168 Callback-Token in ABNF [RFC5234] form is shown below: 170 callback-token = 1*255(VCHAR) 172 When performing RID callback, a responding system MUST connect to the 173 host at the network-layer address from which the original request was 174 sent; there is no mechanism in RID for redirected callback. This 175 callback SHOULD use TCP port 4590 unless configured to use a 176 different port. 178 While a RID system SHOULD return the reply in an HTTP Response if it 179 is available immediately or within a generally accepted HTTP client 180 timeout (about thirty seconds), this is not mandatory, and as such 181 RID systems MUST be prepared for a query to be met with a 202 182 Accepted, an empty Response body, a connection termination and a 183 callback. Note that all RID messages require a response from the 184 receiving RID system, so a sending RID system can expect either an 185 immediate response or a callback. 187 Table 1 lists the allowable RID message types in an HTTP Response for 188 a given RID message type in the Request. A RID system MUST be 189 prepared to handle an HTTP Response of the given type(s) when sending 190 the corresponding HTTP Request. A RID system MUST NOT send an HTTP 191 Response containing any RID message other than the one corresponding 192 to the one sent in the HTTP Request. 194 +----------------------+----------+--------+-------------------+ 195 | Request RID type | Callback | Result | Response RID type | 196 +----------------------+----------+--------+-------------------+ 197 | InvestigationRequest | | 200 | Acknowledgment | 198 | InvestigationRequest | | 200 | Result | 199 | InvestigationRequest | | 200 | Report | 200 | InvestigationRequest | | 202 | [empty] | 201 | TraceRequest | | 200 | Acknowledgment | 202 | TraceRequest | | 200 | Result | 203 | TraceRequest | | 200 | Report | 204 | TraceRequest | | 202 | [empty] | 205 | Query | | 200 | Acknowledgment | 206 | Query | | 200 | Report | 207 | Query | | 202 | [empty] | 208 | Acknowledgment | X | 200 | [empty] | 209 | Result | X | 200 | [empty] | 210 | Report | | 200 | Acknowledgment | 211 | Report | | 200 | [empty] | 212 | Report | X | 200 | [empty] | 213 +----------------------+----------+--------+-------------------+ 215 Table 1 217 The use of stable DNS names to address RID systems is RECOMMENDED; in 218 addition to facilitating connection to RID systems within a 219 consortium, these are to be used as reference identifiers for a RID 220 system's peers. For security purposes, RID systems SHOULD NOT return 221 3xx Redirection response codes, and SHOULD NOT follow any 3xx 222 Redirection. The protocol provides no in-band method for handling a 223 change of address of a RID system. 225 If a RID system receives an improper RID message in an HTTP Request, 226 it MUST return an appropriate 4xx Client Error result code to the 227 requesting RID system. If a RID system cannot process a RID message 228 received in an HTTP Request due to an error on its own side, it MUST 229 return an appropriate 5xx Server Error result code to the requesting 230 RID system. 232 Note that HTTP provides no mechanism for signaling to a server that a 233 response body is not a valid RID message. If an RID system receives 234 an improper RID message in an HTTP Response, or cannot process a RID 235 message received in an HTTP Response due to an error on its own side, 236 it MUST log the error and present it to the RID system administrator 237 for handling; the error logging format is an implementation detail 238 and is considered out of scope for this specification. 240 RID systems MUST support and SHOULD use HTTP/1.1 persistent 241 connections as described in [RFC2616]. RID systems MUST support 242 chunked transfer encoding on the HTTP server side to allow the 243 implementation of clients that do not need to pre-calculate message 244 sizes before constructing HTTP headers. 246 RID systems MUST use TLS version 1.1 [RFC4346] or higher for 247 confidentiality, identification, and authentication, when sending RID 248 messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. 249 RID systems MUST use mutual authentication; that is, both RID systems 250 acting as HTTPS clients and RID systems acting as HTTPS servers MUST 251 be identified by an X.509 certificate [RFC5280]. Mutual 252 authentication requires full path validation on each certificate, as 253 defined in [RFC5280]. 255 The TLS session MUST use non-NULL ciphersuites for authentication, 256 integrity, and confidentiality. Sessions MAY be renegotiated within 257 these constraints. 259 All RID systems MUST be identified by a certificate containing a 260 DNS-ID identifier [RFC5280] as in section 6.4 of [RFC6125]; RID 261 systems MUST verify the reference identifiers of their peers against 262 those stored in the certificates presented. The inclusion of Common 263 Names (CN-IDs) in certificates identifying RID systems is NOT 264 RECOMMENDED. Wildcards MUST NOT appear in the DNS-ID or CN-ID of a 265 certificate identifying a RID system. Additional general information 266 on the use of PKI with RID systems is detailed in Section 9.3 of 267 [I-D.ietf-mile-rfc6045-bis]. 269 RID systems MUST support TLS version 1.1 and SHOULD support TLS 270 version 1.2 [RFC5246]; RID systems MUST NOT request, offer, or use 271 any version of SSL, or any version of TLS prior to 1.1, due to known 272 security vulnerabilities in prior versions of the protocol; see 273 Appendix E of [RFC5246] for more. 275 4. Security Considerations 277 In addition to the final paragraphs in Section 3 on the use of TLS to 278 secure RID message transport, all security considerations of related 279 documents apply, especially the Incident Object Description Exchange 280 Format (IODEF) [RFC5070] and Real-time Inter-network Defense (RID) 281 [I-D.ietf-mile-rfc6045-bis]. The protocol described herein is built 282 on the foundation of these documents; the security considerations 283 contained therein are incorporated by reference. 285 5. IANA Considerations 287 Consistent with BCP 56 [RFC3205], since RID over HTTP/TLS is a 288 substantially new service, and should be controlled at the consortium 289 member network's border differently than HTTP/TLS, it requires a new 290 port number. IANA has assigned port 4590/tcp to RID with service 291 name RID over HTTP/TLS. 293 [NOTE to IANA: Since this document obsoletes RFC 6046, please update 294 the reference in the Port Numbers registry for 4590/tcp to point to 295 this document.] 297 6. Acknowledgments 299 The author would like to thank David Black for the review, and 300 Kathleen Moriarty for work on earlier revisions of this 301 specification. 303 7. References 305 7.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 311 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 312 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 314 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 316 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 317 Object Description Exchange Format", RFC 5070, 318 December 2007. 320 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 321 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 323 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 324 Housley, R., and W. Polk, "Internet X.509 Public Key 325 Infrastructure Certificate and Certificate Revocation List 326 (CRL) Profile", RFC 5280, May 2008. 328 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 329 Verification of Domain-Based Application Service Identity 330 within Internet Public Key Infrastructure Using X.509 331 (PKIX) Certificates in the Context of Transport Layer 332 Security (TLS)", RFC 6125, March 2011. 334 [I-D.ietf-mile-rfc6045-bis] 335 Moriarty, K., "Real-time Inter-network Defense (RID)", 336 draft-ietf-mile-rfc6045-bis-08 (work in progress), 337 January 2012. 339 7.2. Informative References 341 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 342 Specifications: ABNF", STD 68, RFC 5234, January 2008. 344 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 345 RFC 3205, February 2002. 347 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 348 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 350 [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time 351 Inter-network Defense (RID) Messages", RFC 6046, 352 November 2010. 354 Author's Address 356 Brian Trammell 357 Swiss Federal Institute of Technology Zurich 358 Gloriastrasse 35 359 8092 Zurich 360 Switzerland 362 Phone: +41 44 632 70 13 363 Email: trammell@tik.ee.ethz.ch