From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6546.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc6546.txt (limited to 'doc/rfc/rfc6546.txt') diff --git a/doc/rfc/rfc6546.txt b/doc/rfc/rfc6546.txt new file mode 100644 index 0000000..7464c47 --- /dev/null +++ b/doc/rfc/rfc6546.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Trammell +Request for Comments: 6546 ETH Zurich +Obsoletes: 6046 April 2012 +Category: Standards Track +ISSN: 2070-1721 + + + Transport of Real-time Inter-network Defense (RID) Messages + over HTTP/TLS + +Abstract + + The Incident Object Description Exchange Format (IODEF) defines a + common XML format for document exchange, and Real-time Inter-network + Defense (RID) defines extensions to IODEF intended for the + cooperative handling of security incidents within consortia of + network operators and enterprises. This document specifies an + application-layer protocol for RID based upon the passing of RID + messages over HTTP/TLS. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6546. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Trammell Standards Track [Page 1] + +RFC 6546 RID Transport April 2012 + + +1. Introduction + + The Incident Object Description Exchange Format (IODEF) [RFC5070] + describes an XML document format for the purpose of exchanging data + between Computer Security Incident Response Teams (CSIRTs) or those + responsible for security incident handling for service providers + (SPs). The defined document format provides a simple way for CSIRTs + to exchange data in a way which can be easily parsed. + + IODEF defines a message format, not a protocol, as the sharing of + messages is assumed to be out of scope in order to allow CSIRTs to + exchange and store messages in a way most suited to their established + incident-handling processes. However, Real-time Inter-network + Defense (RID) [RFC6545] does require a specification of a protocol to + ensure interoperability among members in a RID consortium. This + document specifies the transport of RID messages within HTTP + [RFC2616] Request and Response messages over TLS [RFC5246] (herein, + HTTP/TLS). Note that any IODEF message may also be transported using + this mechanism, by sending it as a RID Report message. + +1.1. Changes from RFC 6046 + + This document contains the following changes with respect to its + predecessor [RFC6046]: + + o The status of the document is Standards Track. + + o The document is updated to refer to the updated RID specification, + [RFC6545], where appropriate. + + o Language regarding the use of HTTP/1.1 and TCP ports for RID + transport is clarified. + + o The RID-Callback-Token entity header field is added to allow + matching of RID replies during callback, independent of the + content of the underlying RID message. + + o The minimum required version of TLS is upgraded to 1.1, and the + minimum recommended version to 1.2. + + o Language regarding PKI for RID over HTTPS is clarified, and + updated to refer to [RFC6125]. + + This document obsoletes [RFC6046] and moves it to Historic status. + + + + + + + +Trammell Standards Track [Page 2] + +RFC 6546 RID Transport April 2012 + + +2. Terminology and Normative Sections + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + RID systems participating in a consortium are required to fully + implement the protocol in Section 3 in order to interoperate within + the consortium; the remainder of this document is informative and + provides helpful background or explanatory information. + +3. Transmission of RID Messages over HTTP/TLS + + This section specifies the details of the transport of RID messages + [RFC6545] over HTTP/TLS. In this arrangement, each RID server is + both an HTTP/TLS server and an HTTP/TLS client. When a RID message + is sent, the sending RID system connects to the receiving RID system + and sends the message, optionally receiving a message in reply. Each + RID system MUST be prepared to accept HTTP/TLS connections from any + RID peer with which it communicates, in order to support callback for + delayed replies (see below). + + BCP 56 [RFC3205] contains a number of important considerations when + using HTTP for application protocols. These include the size of the + payload for the application, whether the application will use a web + browser, whether the protocol should be defined on a port other than + 80, and if the security provided through HTTP/TLS suits the needs of + the new application. + + It is acknowledged within the scope of these concerns that HTTP/TLS + is not ideally suited for RID transport, as the former is a client- + server protocol and the latter a message-exchange protocol; however, + the ease of implementation of RID systems over HTTP/TLS outweighs + these concerns. Consistent with BCP 56, RID systems listen for TCP + connections on port 4590 (see Section 5). Every RID system + participating in a consortium SHOULD listen for HTTP/TLS connections + on the assigned port. RID systems MAY be configurable to listen on + ports other than the well-known port; this configuration is out of + scope for this specification. RID systems SHOULD NOT use TCP port + 443 (the standard port for HTTP over TLS) for RID messages in order + to avoid confusing standard HTTP/TLS servers for RID systems. + + RID systems MUST implement all REQUIRED functionality for HTTP/1.1 + [RFC2616]. All RID messages sent in HTTP Requests MUST be sent using + the POST method with a Request-URI of '/'. As RID documents are XML, + the RID media type is 'text/xml'; i.e., the 'Content-type' Request + and Response headers MUST be 'text/xml'. As RID messages MUST be + sent using the POST method, the GET and HEAD methods have no + + + +Trammell Standards Track [Page 3] + +RFC 6546 RID Transport April 2012 + + + particular meaning on a RID system; a RID system SHOULD answer + 'GET /' or 'HEAD /' with 204 No Content. Other Request-URIs are + reserved for future use; any access to Request-URIs other than '/' by + any method on a RID system SHOULD return the appropriate HTTP error + (404 Not Found). + + Since the content of RID messages is essentially declarative, a RID + system interrupted during transport MAY simply repeat the + transaction; the sending of a RID message is idempotent. + + As the queries and replies in a RID message exchange may be + significantly separated in time, RID over HTTP/TLS supports a + callback mechanism. In this mechanism, the receiving RID system MAY + return a 202 Accepted response, called a RID callback, instead of a + RID message. The RID callback MUST contain a zero-length entity body + and a 'RID-Callback-Token' entity header field, itself containing a + unique token generated by the receiving RID system. + + The RID-Callback-Token is an opaque, whitespace-free string of up to + 255 printable ASCII characters that MUST uniquely identify the + callback among all callbacks from the receiving RID system to the + sending RID system. Due to the amount of time that may be required + to generate a RID Result or Report response, there is no upper bound + on the time period for this uniqueness requirement. The RID- + Callback-Token in ABNF [RFC5234] form is shown below: + + callback-token = 1*255(VCHAR) + + When performing RID callback, a responding system MUST connect to the + host at the network-layer address from which the original request was + sent; there is no mechanism in RID for redirected callback. This + callback SHOULD use TCP port 4590 unless configured to use a + different port. + + While a RID system SHOULD return the reply in an HTTP Response if it + is available immediately or within a generally accepted HTTP client + timeout (about thirty seconds), this is not mandatory, and as such + RID systems MUST be prepared for a query to be met with a 202 + Accepted, an empty Response body, a connection termination, and a + callback. Note that all RID messages require a response from the + receiving RID system, so a sending RID system can expect either an + immediate response or a callback. + + Table 1 lists the allowable RID message types in an HTTP Response for + a given RID message type in the Request. A RID system MUST be + prepared to handle an HTTP Response of the given type(s) when sending + + + + + +Trammell Standards Track [Page 4] + +RFC 6546 RID Transport April 2012 + + + the corresponding HTTP Request. A RID system MUST NOT send an HTTP + Response containing any RID message other than the one corresponding + to the one sent in the HTTP Request. + + +----------------------+----------+--------+-------------------+ + | Request RID type | Callback | Result | Response RID type | + +----------------------+----------+--------+-------------------+ + | InvestigationRequest | | 200 | Acknowledgement | + | InvestigationRequest | | 200 | Result | + | InvestigationRequest | | 200 | Report | + | InvestigationRequest | | 202 | [empty] | + | TraceRequest | | 200 | Acknowledgement | + | TraceRequest | | 200 | Result | + | TraceRequest | | 200 | Report | + | TraceRequest | | 202 | [empty] | + | Query | | 200 | Acknowledgement | + | Query | | 200 | Report | + | Query | | 202 | [empty] | + | Acknowledgement | X | 200 | [empty] | + | Result | X | 200 | [empty] | + | Report | | 200 | Acknowledgement | + | Report | | 200 | [empty] | + | Report | X | 200 | [empty] | + +----------------------+----------+--------+-------------------+ + + Table 1 + + The use of stable DNS names to address RID systems is RECOMMENDED; in + addition to facilitating connection to RID systems within a + consortium, these are to be used as reference identifiers for a RID + system's peers. For security purposes, RID systems SHOULD NOT return + 3xx Redirection response codes, and SHOULD NOT follow any 3xx + Redirection. The protocol provides no in-band method for handling a + change of address of a RID system. + + If a RID system receives an improper RID message in an HTTP Request, + it MUST return an appropriate 4xx Client Error result code to the + requesting RID system. If a RID system cannot process a RID message + received in an HTTP Request due to an error on its own side, it MUST + return an appropriate 5xx Server Error result code to the requesting + RID system. + + Note that HTTP provides no mechanism for signaling to a server that a + response body is not a valid RID message. If a RID system receives + an improper RID message in an HTTP Response, or cannot process a RID + message received in an HTTP Response due to an error on its own side, + + + + + +Trammell Standards Track [Page 5] + +RFC 6546 RID Transport April 2012 + + + it MUST log the error and present it to the RID system administrator + for handling; the error logging format is an implementation detail + and is considered out of scope for this specification. + + RID systems MUST support and SHOULD use HTTP/1.1 persistent + connections as described in [RFC2616]. RID systems MUST support + chunked transfer encoding on the HTTP server side to allow the + implementation of clients that do not need to pre-calculate message + sizes before constructing HTTP headers. + + RID systems MUST use TLS version 1.1 [RFC4346] or higher for + confidentiality, identification, and authentication, when sending RID + messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. + RID systems MUST use mutual authentication; that is, both RID systems + acting as HTTPS clients and RID systems acting as HTTPS servers MUST + be identified by an X.509 certificate [RFC5280]. Mutual + authentication requires full path validation on each certificate, as + defined in [RFC5280]. + + The TLS session MUST use non-NULL ciphersuites for authentication, + integrity, and confidentiality. Sessions MAY be renegotiated within + these constraints. + + All RID systems SHOULD be identified by a certificate containing + DNS-ID identifier as in Section 6.4 of [RFC6125]; the inclusion of + Common Names (CN-IDs) in certificates identifying RID systems is NOT + RECOMMENDED. RID systems MUST verify the reference identifiers of + their peers against those stored in the certificates presented using + one of the methods in the following paragraph. Wildcards MUST NOT + appear in the DNS-ID or CN-ID of a certificate identifying a RID + system. + + RID systems MUST support the verification of certificates against an + explicit whitelist of peer certificates. RID systems SHOULD support + the verification of reference identifiers by matching the DNS-ID or + CN-ID with a reverse DNS lookup of the connecting RID peer; this + support SHOULD allow the lookup to be cached and/or done in advance + in order to ensure verifiability during instability or compromise of + DNS itself. + + Additional general information on the use of PKI with RID systems is + detailed in Section 9.3 of [RFC6545]. + + RID systems MUST support TLS version 1.1 and SHOULD support TLS + version 1.2 [RFC5246]; RID systems MUST NOT request, offer, or use + any version of SSL, or any version of TLS prior to 1.1, due to known + security vulnerabilities in prior versions of the protocol; see + Appendix E of [RFC5246] for more information. + + + +Trammell Standards Track [Page 6] + +RFC 6546 RID Transport April 2012 + + +4. Security Considerations + + In addition to the final paragraphs in Section 3 on the use of TLS to + secure RID message transport, all security considerations of related + documents apply, especially the Incident Object Description Exchange + Format (IODEF) [RFC5070] and Real-time Inter-network Defense (RID) + [RFC6545]. The protocol described herein is built on the foundation + of those documents; the security considerations contained therein are + incorporated by reference. + +5. IANA Considerations + + Consistent with BCP 56 [RFC3205], since RID over HTTP/TLS is a + substantially new service, and should be controlled at the consortium + member network's border differently than HTTP/TLS, it requires a new + port number. IANA has assigned port 4590/tcp to RID with service + name "RID over HTTP/TLS". + +6. Acknowledgements + + The author would like to thank David Black for the review, and + Kathleen Moriarty for work on earlier revisions of this + specification. This work was partially supported by the European + Union Seventh Framework Program under grant agreement 257315 + (DEMONS). + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident + Object Description Exchange Format", RFC 5070, + December 2007. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + + + + + +Trammell Standards Track [Page 7] + +RFC 6546 RID Transport April 2012 + + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, March 2011. + + [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", + RFC 6545, April 2012. + +7.2. Informative References + + [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, + RFC 3205, February 2002. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time + Inter-network Defense (RID) Messages", RFC 6046, + November 2010. + +Author's Address + + Brian Trammell + Swiss Federal Institute of Technology Zurich + Gloriastrasse 35 + 8092 Zurich + Switzerland + + Phone: +41 44 632 70 13 + EMail: trammell@tik.ee.ethz.ch + + + + + + + + + + + + +Trammell Standards Track [Page 8] + -- cgit v1.2.3