summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6046.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6046.txt')
-rw-r--r--doc/rfc/rfc6046.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc6046.txt b/doc/rfc/rfc6046.txt
new file mode 100644
index 0000000..7618446
--- /dev/null
+++ b/doc/rfc/rfc6046.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Moriarty
+Request for Comments: 6046 EMC
+Category: Informational B. Trammell
+ISSN: 2070-1721 ETH Zurich
+ November 2010
+
+
+ Transport of Real-time Inter-network Defense (RID) Messages
+
+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 a
+ transport protocol for RID based upon the passing of RID messages
+ over HTTP/TLS (Transport Layer Security).
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ 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). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see 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/rfc6046.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Trammell Informational [Page 1]
+
+RFC 6046 RID Transport November 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 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.
+
+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 network providers
+ (NPs). The defined document format provides an easy way for CSIRTs
+ to exchange data in a way that can be easily parsed.
+
+ IODEF defines a message format, not a transport 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) [RFC6045] does require a specification of
+ a transport 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
+ transported over Transport Layer Security (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.
+
+2. Terminology
+
+ 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].
+
+3. Transmission of RID Messages over HTTP/TLS
+
+ This section specifies the details of the transport of RID messages
+ over HTTP/TLS. In this arrangement, each RID server is both an HTTP/
+ TLS server and an HTTP/TLS client. When a RID message must be sent,
+ the sending RID system connects to the receiving RID system and sends
+
+
+
+Moriarty & Trammell Informational [Page 2]
+
+RFC 6046 RID Transport November 2010
+
+
+ the message, optionally receiving a message in reply. All RID
+ systems 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 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.
+
+ 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
+ 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.
+
+ As the queries and replies in a RID message exchange may be
+ significantly separated in time, the receiving RID system MAY return
+ 202 Accepted, terminate the connection, and at a later time connect
+ to the requesting RID system and send the RID reply in an HTTP
+ Request. This mechanism is referred to in this document as "RID
+ callback". When performing RID callback, a responding system MUST
+ connect to the network- and transport-layer addresses from which the
+ original request was sent; there is no mechanism in RID for
+ redirected callback.
+
+ 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
+
+
+
+
+
+
+
+Moriarty & Trammell Informational [Page 3]
+
+RFC 6046 RID Transport November 2010
+
+
+ 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.
+
+ RID systems accepting a callback message in an HTTP Request MUST
+ return 202 Accepted.
+
+ Table 1 lists the allowable request/response pairs for RID.
+
+ +----------------------+----------+--------+----------------------+
+ | 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
+
+ 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, contact point information within the
+ consortium must be updated out of band.
+
+ 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,
+ 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.
+
+
+
+
+Moriarty & Trammell Informational [Page 4]
+
+RFC 6046 RID Transport November 2010
+
+
+ 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 precalculate message
+ sizes before constructing 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
+
+ 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]. The
+ transport described herein is built on the foundation of these
+ documents; the security considerations contained therein 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;
+ sessions MAY be renegotiated within these constraints. Although TLS
+ implementations typically support the older Secure Socket Layer (SSL)
+ protocol, a RID peer MUST NOT request, offer, or use SSL 2.0, due to
+ known security vulnerabilities in this protocol; see Appendix E of
+ [RFC5246] for more.
+
+ Each RID consortium SHOULD use a trusted public key infrastructure
+ (PKI) to manage identities for RID systems participating in TLS
+ connections. At minimum, each RID system MUST trust a set of X.509
+ Issuer identities ("Certificate Authorities") [RFC5280] to directly
+ authenticate RID system peers with which it is willing to exchange
+ information, and/or a specific white list of X.509 Subject identities
+ of RID system peers.
+
+ RID systems MUST provide for the verification of the identity of a
+ RID system peer presenting a valid and trusted certificate, by
+ verifying the fully qualified domain name or other network-layer
+ identifier against that stored in the certificate, if available.
+ More information on best practices in peer identity verification is
+ available in [TLS-SERVER-ID].
+
+
+
+
+
+
+
+
+Moriarty & Trammell Informational [Page 5]
+
+RFC 6046 RID Transport November 2010
+
+
+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 the service
+ name RID over HTTP/TLS.
+
+6. References
+
+6.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.
+
+ [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
+
+ [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.
+
+
+
+
+Moriarty & Trammell Informational [Page 6]
+
+RFC 6046 RID Transport November 2010
+
+
+Authors' Addresses
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Trammell Informational [Page 7]
+