RFC 6546

RFC 6546: Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS 🎀

okay bestie, title block first 💅 This is RFC 6546, written by B. Trammell from ETH Zurich, dated April 2012. It's on the Standards Track (ISSN 2070-1721), and it obsoletes RFC 6046 🦋 There's no Updates line in its header, so the only thing it replaces is 6046 (more on that in Section 1.1 ✨).

Abstract ✨

okay so IODEF is this common XML format for swapping incident documents, and it's basically the shared language security teams use to describe what went wrong 🔥 Real-time Inter-network Defense (RID) is the extension on top of it that lets groups of network operators and enterprises handle security incidents together as a consortium 🫶 This doc is the piece that actually defines how RID messages travel over the wire, using HTTP/TLS as the transport. Application-layer protocol, bestie 💜

Status of This Memo 🌸

this one's an Internet Standards Track document 💖

It's a product of the Internet Engineering Task Force (IETF), so it reflects consensus from the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on what Internet Standards are, check out Section 2 of RFC 5741 🧚

Info about the current status, any errata, and how to give feedback lives 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), as they were in effect on the date this document was published. Please read those carefully, bestie, because they spell out your rights and restrictions for this document 💅 Any Code Components pulled out of this document have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License explains 🫶

1. Introduction ✨

okay so IODEF [RFC5070] is an XML document format for trading data between Computer Security Incident Response Teams (CSIRTs), or between the folks who handle security incidents for service providers (SPs) 🦋 The whole point is that it gives CSIRTs a simple way to swap data in a format that's easy to parse 💖

Here's the tea: IODEF only defines a message format, not a protocol. Sharing the messages is treated as out of scope, so each CSIRT can move and store them however fits their existing incident-handling processes 🌸 Real-time Inter-network Defense (RID) [RFC6545] is different. It does need a protocol spec so that everyone in a RID consortium can interoperate 🔥 That's what this doc gives you: it covers how RID messages get carried inside HTTP [RFC2616] Request and Response messages over TLS [RFC5246], which we're calling HTTP/TLS 💜 Also, any IODEF message can ride this same mechanism too, you just send it as a RID Report message 🎀

1.1. Changes from RFC 6046 🦋

so this is what's new compared to the older one, [RFC6046] 💅

• The status of the document is Standards Track. 🌈
• The document now refers to the updated RID specification, [RFC6545], wherever that makes sense. 🍓
• The language about using HTTP/1.1 and TCP ports for RID transport got clarified. ✨
• A new entity header field, RID-Callback-Token, got added. It lets you match RID replies during a callback, no matter what's inside the underlying RID message 🔥
• The minimum required TLS version went up to 1.1, and the minimum recommended version went up to 1.2 💖
• The language about PKI for RID over HTTPS got clarified, and it now refers to [RFC6125] 🧚

Lastly, this document obsoletes [RFC6046] and moves it to Historic status 👑

2. Terminology and Normative Sections 💜

okay, this part is the key-word section, so pay attention 🙈 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 💅

RID systems in a consortium are required to fully implement the protocol in Section 3 so they can interoperate within the consortium. Everything else in this document is informative, which means it's there to give you helpful background and explanations 🫶

3. Transmission of RID Messages over HTTP/TLS ✨

okay so this section is the big one, bestie 🎀 it spells out how RID messages (defined in [RFC6545]) get carried over HTTP/TLS. the vibe here is that every RID server is both an HTTP/TLS server AND an HTTP/TLS client, so it's giving double agent energy 🕵️‍♀️. when a RID message gets sent, the sending system connects to the receiving system and sends the message, and it can optionally get a message back in reply. every RID system MUST be ready to accept HTTP/TLS connections from any RID peer it talks to, because that's how callbacks for delayed replies work (more on that below) 💅

BCP 56 [RFC3205] has a bunch of important stuff to consider when you're using HTTP for an application protocol 📚. stuff like how big the payload is, whether the app will be used from a web browser, whether the protocol should live on a port other than 80, and whether the security HTTP/TLS gives you actually fits what the new app needs 🤔

ngl, it's acknowledged that HTTP/TLS isn't ideally suited for RID transport 😭. HTTP is a client-server protocol and RID is a message-exchange protocol, so they don't totally vibe. BUT the ease of implementing RID over HTTP/TLS outweighs those concerns, so it's a worthy trade-off 🫶. 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, but that configuration is out of scope for this spec 🌸. RID systems SHOULD NOT use TCP port 443 (the standard port for HTTP over TLS) for RID messages, so they don't confuse regular 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 /. Since RID documents are XML, the RID media type is text/xml, so the Content-type Request and Response headers MUST be text/xml 🧚. Because RID messages MUST be sent using POST, GET and HEAD don't really mean anything on a RID system. A RID system SHOULD answer GET / or HEAD / with 204 No Content 🍓. Other Request-URIs are reserved for future use, so any access to a Request-URI 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 basically declarative, a RID system that gets interrupted during transport MAY just repeat the transaction. Sending a RID message is idempotent, which means repeating it is totally safe ✨.

Because the queries and replies in a RID message exchange might be pretty far apart in time, RID over HTTP/TLS has 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. That header field contains 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. It MUST uniquely identify the callback among all callbacks from the receiving RID system to the sending RID system 🌈. Because generating a RID Result or Report response can take a looong time, there's no upper bound on how long this uniqueness requirement lasts ⭐. The RID-Callback-Token in ABNF [RFC5234] form looks like this:

callback-token = 1*255(VCHAR)

When performing a RID callback, the responding system MUST connect to the host at the network-layer address the original request came from. RID has no mechanism for redirected callbacks, so no detours 🙅‍♀️. This callback SHOULD use TCP port 4590 unless it's configured to use a different port 🎀.

A RID system SHOULD return the reply in an HTTP Response if it's available immediately or within a generally accepted HTTP client timeout (about thirty seconds) 🕐. BUT this isn't mandatory, so RID systems MUST be prepared for a query to get back a 202 Accepted, an empty Response body, a connection termination, or 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 each RID message type in the Request. A RID system MUST be prepared to handle an HTTP Response of the given type(s) when it sends the matching HTTP Request. A RID system MUST NOT send an HTTP Response containing any RID message other than the one that corresponds 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 🌟. Besides making it easier to connect to RID systems within a consortium, these names are also 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 has no in-band way to handle a change of address for a RID system 🙃.

If a RID system gets 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 can't process a RID message it received in an HTTP Request because of an error on its own side, it MUST return an appropriate 5xx Server Error result code to the requesting RID system 😬.

Note that HTTP has no mechanism for telling a server that a response body isn't a valid RID message. If a RID system gets an improper RID message in an HTTP Response, or can't process a RID message it received in an HTTP Response because of an error on its own side, 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 out of scope for this spec 🗂️.

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, so clients that don't need to pre-calculate message sizes before building HTTP headers can still work 🧩.

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, which means 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 a DNS-ID identifier, as in Section 6.4 of [RFC6125]. Including Common Names (CN-IDs) in certificates that identify 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 verifying certificates against an explicit whitelist of peer certificates. RID systems SHOULD support verifying 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, so verification still works during instability or compromise of DNS itself 🧠.

More general info on using PKI with RID systems is 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, because of known security vulnerabilities in older versions of the protocol. See Appendix E of [RFC5246] for more info 🚫💀.

4. Security Considerations 🔒

okay this part is SERIOUS, bestie 😤. Besides the final paragraphs in Section 3 about using TLS to secure RID message transport, all security considerations of related documents apply. That especially includes the Incident Object Description Exchange Format (IODEF) [RFC5070] and Real-time Inter-network Defense (RID) [RFC6545] 🛡️. RID over HTTP/TLS is built on the foundation of those documents, so their security considerations are incorporated by reference. Read them, obsessed 📚🫶.

5. IANA Considerations 🗂️

Consistent with BCP 56 [RFC3205], RID over HTTP/TLS is a substantially new service and should be controlled differently at the consortium member network's border than plain HTTP/TLS. So it needs a new port number 🎀. IANA has assigned port 4590/tcp to RID with the 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 🎀

okay so these are the big ones the spec leans on, bestie 💅 they're the must-reads for the rest of the doc 🫶

• [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.
• [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 ✨

these ones are more like the background reading 🦋 handy to have, but the spec isn't leaning on them the same way, lowkey

• [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