RFC 6046

Transport of Real-time Inter-network Defense (RID) Messages

📅 published November 2010, from ietf

RFC 6046 💖 Transport of Real-time Inter-network Defense (RID) Messages ✨

Okay bestie, this one is all about how RID messages actually get delivered 🚚💌 It's an IETF document, and the paper trail looks like this:

  • Authors: K. Moriarty (EMC) and B. Trammell (ETH Zurich) 🧚
  • Category: Informational, so it's published for info and isn't a Standards Track thing 🌸
  • ISSN: 2070-1721
  • Date: November 2010 📅
  • Obsoletes or updates: the header doesn't list any 🙈

Abstract 🦋

Okay so IODEF defines a common XML format for swapping incident documents 📄 and RID adds extensions on top of it so consortia of network operators and enterprises can handle security incidents together 🤝 This doc is the one that says how RID gets transported, and the answer is HTTP/TLS (Transport Layer Security) 🔐 It's giving "send it over the web but make it secure" energy 💅

Status of This Memo 🎀

Not an Internet Standards Track spec, just published for info 📚 It's a product of the IETF, it represents the consensus of the IETF community, it got public review, and the IESG approved it for publication. Not everything the IESG approves is a candidate for an Internet Standard, so check out Section 2 of RFC 5741 if you're curious 🧐

For the current status, errata, or to leave feedback, go to http://www.rfc-editor.org/info/rfc6046 🌈

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions 📜 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 💜

1. Introduction 🌸

So IODEF [RFC5070] describes an XML document format for trading data between Computer Security Incident Response Teams (CSIRTs), or the folks responsible for incident handling at network providers (NPs) 🛡️ The format makes it easy for CSIRTs to swap data in a way that's easy to parse 🫶

IODEF only defines a message format, not a transport protocol 🙅‍♀️ Sharing the messages is assumed to be out of scope, so each CSIRT can move and store them in whatever way fits its own incident handling processes 🗂️ Real-time Inter-network Defense (RID) [RFC6045] does need a transport spec though, so every member of a RID consortium can actually talk to each other 🤝 This doc is that spec: RID messages ride inside HTTP [RFC2616] Requests and Responses, which are carried over Transport Layer Security (TLS) [RFC5246]. Call it HTTP/TLS 💖 Also, any IODEF message can go over this same mechanism, as long as you send it as a RID Report message 🎁

2. Terminology 🧚

Okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way [RFC2119] describes 📖✨

3. Transmission of RID Messages over HTTP/TLS 🦋

This section gets into the nitty gritty of sending RID messages over HTTP/TLS 💅 The setup is that each RID server is both an HTTP/TLS server and an HTTP/TLS client 🔄 When a RID message needs to go out, the sending RID system connects to the receiving RID system, sends the message, and can optionally get a message back as a reply 📨

All RID systems MUST be prepared to accept HTTP/TLS connections from any RID peer they communicate with, so callbacks for delayed replies can work (more on that below) 🌈

BCP 56 [RFC3205] has a bunch of important considerations for using HTTP in application protocols 🧠 They cover 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 actually suits the new app 🔍

Within those concerns, it's acknowledged that HTTP/TLS isn't ideally suited for RID transport 😬 HTTP/TLS is client-server and RID is message-exchange, so they don't really match 🙃 But the ease of implementing RID over HTTP/TLS outweighs that, so here we are 💁‍♀️ Following BCP 56, RID systems will listen for TCP connections on port 4590 🔌 Every RID system participating in a consortium MUST listen for HTTP/TLS connections on the assigned port 🎯

All RID messages sent in HTTP Requests MUST be sent using the POST with a Request-URI of "/". Additional Request-URI paths are reserved for future use by RID 🗝️

Okay so the queries and replies in a RID exchange can be pretty far apart in time ⏳ That's why the receiving RID system MAY return 202 Accepted, terminate the connection, and then later connect back to the requesting RID system and send the RID reply in an HTTP Request 🔁 This is called "RID callback" 📞 When doing RID callback, a responding system MUST connect to the network- and transport-layer addresses the original request came from 📍 RID has no mechanism for redirected callbacks, so no detours 🚫

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    |
    +----------------------+----------+--------+----------------------+
    | TraceRequest         |          | 200    | RequestAuthorization |
    | TraceRequest         |          | 200    | Result               |
    | TraceRequest         |          | 202    | [empty]              |
    | RequestAuthorization |     X    | 202    | [empty]              |
    | Result               |     X    | 202    | [empty]              |
    | Investigation        |          | 200    | Result               |
    | Investigation        |          | 202    | [empty]              |
    | Report               |     X    | 202    | [empty]              |
    | IncidentQuery        |          | 200    | Report               |
    | IncidentQuery        |          | 202    | [empty]              |
    +----------------------+----------+--------+----------------------+

Table 1 🌸

While a RID system SHOULD return the reply in an HTTP Response if it's available right away or within a generally accepted HTTP client timeout (about thirty seconds) 🕰️ This isn't mandatory though, so RID systems MUST be prepared for a query to get a 202 Accepted, an empty Response body, a connection termination, and a callback 🫠 Note that every RID message needs a response from the receiving RID system, so the sender can expect either an immediate response or a callback 📬

RID systems accepting a callback message in an HTTP Request MUST return 202 Accepted 💫

For security purposes, RID systems SHOULD NOT return 3xx Redirection response codes, and MUST NOT follow any 3xx Redirection 🚧 When a RID system's address changes, the contact point info within the consortium must be updated out of band 📞

Heads up: 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 it can't process a RID message from 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 way to tell 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 one 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 don't have to precalculate message sizes before building their HTTP headers 🧮

RID systems MUST use TLS for confidentiality, identification, and strong mutual authentication as in [RFC2818]. See Section 4 below for details 🔐✨

4. Security Considerations 💜

Okay this part is SERIOUS, bestie 😭 All security considerations of related documents MUST be considered, especially the Incident Object Description Exchange Format (IODEF) [RFC5070] and Real-time Inter-network Defense (RID) [RFC6045]. This transport is built on the foundation of those docs, so their security considerations are incorporated by reference 🧱

For transport confidentiality, identification, and authentication, TLS with mutual authentication MUST be used to secure the HTTP connection, as in [RFC2818] 🛡️ The session MUST use non-NULL ciphersuites for authentication, integrity, and confidentiality, and sessions MAY be renegotiated within those constraints 🔄

Big warning: TLS implementations usually support the older Secure Socket Layer (SSL) protocol, but a RID peer MUST NOT request, offer, or use SSL 2.0, because of known security vulnerabilities in that protocol. See Appendix E of [RFC5246] for more 💀

Each RID consortium SHOULD use a trusted public key infrastructure (PKI) to manage the identities of RID systems in TLS connections 🪪 At minimum, each RID system MUST trust a set of X.509 Issuer identities ("Certificate Authorities") [RFC5280] to directly authenticate the RID system peers it's willing to exchange information with, and/or a specific white list of X.509 Subject identities of RID system peers 📝

RID systems MUST provide for verifying the identity of a RID system peer that presents a valid and trusted certificate 🕵️‍♀️ They do this by checking the fully qualified domain name or other network-layer identifier against what's stored in the certificate, if it's there 🔎 More info on best practices for peer identity verification is in [TLS-SERVER-ID] 🌟

5. IANA Considerations 🎀

Consistent with BCP 56 [RFC3205], RID over HTTP/TLS is a substantially new service. It should be controlled at the consortium member network's border differently than plain HTTP/TLS, so it needs its own port number 🚪 IANA has assigned port 4590/tcp to RID, with the service name RID over HTTP/TLS 🥳

6. References 📚

6.1. Normative References 💅

okay bestie, these are the must-read docs this spec leans on 📚 every entry stays exactly as written:

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

[RFC6045]   Moriarty, K., "Real-time Inter-network Defense (RID)",
            RFC 6045, November 2010.

6.2. Informative References 🌸

these ones are more like bonus reading, but they're still giving context 🧚

[RFC3205]   Moore, K., "On the use of HTTP as a Substrate", BCP 56,
            RFC 3205, February 2002.

[TLS-SERVER-ID]
            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)", Work in Progress, October 2010.

Authors' Addresses 💌

meet the people who wrote it 🎀

Kathleen M. Moriarty
RSA, The Security Division of EMC
174 Middlesex Turnpike
Bedford, MA  01730
US

EMail: Moriarty_Kathleen@EMC.com


Brian H. Trammell
Swiss Federal Institute of Technology Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
📦 where this page comes from