[要約] RFC 6046は、リアルタイムのインターネット防御（RID）メッセージの転送に関する標準仕様です。このRFCの目的は、RIDメッセージの効率的な転送と相互運用性の向上を実現することです。
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
リアルタイムのネットワーク間防衛（RID）メッセージの輸送
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).
インシデントオブジェクト説明交換形式（IODEF）は、ドキュメント交換用の一般的なXML形式を定義し、ネットワークオペレーターと企業のコンソーシアム内でのセキュリティインシデントの協力処理を目的としたIODEFへの拡張を定義します。このドキュメントは、HTTP/TLS（輸送層のセキュリティ）を介したRIDメッセージの渡されに基づいて、RID用のトランスポートプロトコルを指定します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6046で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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）[RFC5070]は、コンピューターセキュリティインシデント対応チーム（CSIRT）またはネットワークプロバイダーのセキュリティインシデント処理（NP）の責任者との間でデータを交換する目的でXMLドキュメント形式を説明します。定義されたドキュメント形式は、CSIRTが簡単に解析できる方法でデータを交換できる簡単な方法を提供します。
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.
IODEFは、CSIRTが確立されたインシデント処理プロセスに最も適した方法でメッセージを交換および保存できるようにするために、メッセージの共有が範囲外であると想定されるため、トランスポートプロトコルではなくメッセージ形式を定義します。ただし、リアルタイム間のネットワーク間防御（RID）[RFC6045]では、RIDコンソーシアムのメンバー間の相互運用性を確保するために、輸送プロトコルの仕様が必要です。このドキュメントは、HTTP [RFC2616]リクエストと輸送層セキュリティ（TLS）[RFC5246]を介して輸送された応答メッセージ内のRIDメッセージの輸送を指定します（ここでは、HTTP/TLS）。IODEFメッセージは、RIDレポートメッセージとして送信することにより、このメカニズムを使用して輸送される場合があることに注意してください。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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 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).
このセクションでは、HTTP/TLSを介したRIDメッセージの輸送の詳細を指定します。この配置では、各RIDサーバーはHTTP/ TLSサーバーとHTTP/ TLSクライアントの両方です。RIDメッセージを送信する必要がある場合、送信RIDシステムは受信RIDシステムに接続し、メッセージを送信し、オプションでメッセージを受信します。すべてのRIDシステムは、遅延返信のコールバックをサポートするために、通信するRIDピアからHTTP/TLS接続を受け入れるように準備する必要があります（以下を参照）。
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.
BCP 56 [RFC3205]には、アプリケーションプロトコルにHTTPを使用する場合、多くの重要な考慮事項が含まれています。これらには、アプリケーションのペイロードのサイズ、アプリケーションがWebブラウザーを使用するかどうか、プロトコルを80以外のポートで定義する必要があるかどうか、HTTP/TLSを介して提供されるセキュリティが新しいアプリケーションのニーズに合っているかどうかが含まれます。
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.
前者はクライアントサーバープロトコルであり、後者はメッセージ交換プロトコルであるため、HTTP/TLSはRID輸送に理想的ではないことがこれらの懸念の範囲内で認められています。ただし、HTTP/TLSよりもRIDシステムの実装の容易さは、これらの懸念を上回ります。BCP 56と一致して、RIDシステムはポート4590でTCP接続をリッスンします。コンソーシアムに参加するすべてのRIDシステムは、割り当てられたポートのHTTP/TLS接続をリッスンする必要があります。
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.
HTTPリクエストで送信されたすべてのRIDメッセージは、 "/"のリクエスト-uriを使用して投稿を使用して送信する必要があります。追加のリクエスト-URIパスは、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.
表1に、リクエストの特定のRIDメッセージタイプのHTTP応答の許容RIDメッセージタイプを示します。対応するHTTP要求を送信するときに、指定されたタイプのHTTP応答を処理するために、RIDシステムを準備する必要があります。RIDシステムは、HTTPリクエストで送信されたものに対応するもの以外のRIDメッセージを含むHTTP応答を送信してはなりません。
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.
RIDメッセージ交換でのクエリと返信が時間内に大幅に分離される可能性があるため、受信RIDシステムは受け入れられ、接続を終了し、後で接続してリクエストRIDシステムに接続し、HTTPリクエストでRID返信を送信する場合があります。このメカニズムは、このドキュメントでは「RIDコールバック」と呼ばれます。RIDコールバックを実行する場合、応答システムは、元のリクエストが送信されたネットワークおよびトランスポートレイヤーアドレスに接続する必要があります。リダイレクトされたコールバックのRIDにメカニズムはありません。
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.
RIDシステムは、http応答がすぐに利用可能である場合、または一般的に受け入れられているHTTPクライアントタイムアウト（約30秒）内で使用可能な場合、返信を返す必要がありますが、これは必須ではないため、coeryを満たすためにRIDシステムを準備する必要があります。202が受け入れられている、空の応答本体、接続終了、コールバック。すべてのRIDメッセージには、受信RIDシステムからの応答が必要であるため、送信RIDシステムは即時の応答またはコールバックのいずれかを期待できることに注意してください。
RID systems accepting a callback message in an HTTP Request MUST return 202 Accepted.
HTTP要求でコールバックメッセージを受け入れるRIDシステムは、受け入れられた202を返す必要があります。
Table 1 lists the allowable request/response pairs for RID.
表1に、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
表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.
セキュリティ目的で、RIDシステムは3xxリダイレクト応答コードを返してはならず、3xxリダイレクトに従ってはなりません。RIDシステムのアドレスが変更された場合、コンソーシアム内のコンタクトポイント情報をバンドから更新する必要があります。
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.
RIDシステムがHTTP要求で不適切なRIDメッセージを受信した場合、Requireming RIDシステムに適切な4XXクライアントエラー結果コードを返す必要があります。RIDシステムがHTTP要求で受信したRIDメッセージをHTTP要求で処理できない場合、独自のエラーがあるため、適切な5XXサーバーエラー結果コードをリクエストRIDシステムに返す必要があります。
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.
HTTPは、応答本体が有効なRIDメッセージではないことをサーバーに信号するメカニズムを提供しないことに注意してください。RIDシステムがHTTP応答で不適切なRIDメッセージを受信したり、独自のエラーがあるためにHTTP応答で受信したRIDメッセージを処理できない場合、エラーをログにして、ハンドリングのためにRIDシステム管理者に提示する必要があります。エラーログ形式は実装の詳細であり、この仕様の範囲外であると見なされます。
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システムは、[RFC2616]で説明されているように、HTTP/1.1永続的な接続をサポートする必要があり、使用する必要があります。RIDシステムは、HTTPサーバー側でのチャンク転送エンコードをサポートして、HTTPヘッダーを構築する前にメッセージサイズを事前に計算する必要のないクライアントの実装を可能にする必要があります。
RID systems MUST use TLS for confidentiality, identification, and strong mutual authentication as in [RFC2818]; see Section 4 below for details.
RIDシステムは、[RFC2818]のように、機密性、識別、および強力な相互認証にTLSを使用する必要があります。詳細については、以下のセクション4を参照してください。
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.
関連するドキュメントのすべてのセキュリティ上の考慮事項、特にインシデントオブジェクト説明交換形式（IODEF）[RFC5070]およびリアルタイムのネットワーク間防御（RID）[RFC6045]を考慮する必要があります。本明細書に記載されている輸送は、これらの文書の基礎の上に構築されています。そこに含まれるセキュリティ上の考慮事項は、参照により組み込まれています。
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.
輸送の機密性、識別、および認証のために、[RFC2818]のようにHTTP接続を保護するために、相互認証のTLSを使用する必要があります。セッションでは、認証、完全性、および機密性のために、非ヌルの暗号着を使用する必要があります。セッションは、これらの制約内で再交渉される場合があります。TLS実装は通常、古いセキュアソケットレイヤー（SSL）プロトコルをサポートしていますが、このプロトコルのセキュリティ脆弱性が既知のため、RIDピアはSSL 2.0を要求、提供、または使用してはなりません。詳細については、[RFC5246]の付録Eを参照してください。
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コンソーシアムは、TLS接続に参加するRIDシステムのIDを管理するために、信頼できる公開キーインフラストラクチャ（PKI）を使用する必要があります。少なくとも、各RIDシステムは、X.509発行者IDのセット（「証明書当局」）[RFC5280]を信頼して、情報を交換することをいとわないRIDシステムのピアを直接認証する必要があります。509 RIDシステムピアの件名ID。
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].
RIDシステムは、利用可能な場合は、証明書に保存されているものに対して完全に適格なドメイン名またはその他のネットワーク層識別子を確認することにより、有効で信頼できる証明書を提示するRIDシステムのIDの確認を提供する必要があります。ピアアイデンティティの検証におけるベストプラクティスの詳細については、[TLS-Server-ID]をご覧ください。
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.
BCP 56 [RFC3205]と一致して、HTTP/TLSを介してRidが実質的に新しいサービスであり、HTTP/TLSとは異なるコンソーシアムメンバーネットワークの境界線で制御する必要があるため、新しいポート番号が必要です。IANAはポート4590/TCPを割り当てて、HTTP/TLSを介してサービス名を削除しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5070] Danyliw、R.、Meijer、J。、およびY. Demchenko、「インシデントオブジェクト説明交換形式」、RFC 5070、2007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[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.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010.
[RFC6045] Moriarty、K。、「リアルタイム間のネットワーク間防衛（RID）」、RFC 6045、2010年11月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[RFC3205]ムーア、K。、「基質としてのHTTPの使用について」、BCP 56、RFC 3205、2002年2月。
[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.
[TLS-Server-ID] Saint-Andre、P。and J. Hodges、「輸送層のセキュリティのコンテキストでX.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証（PKIX）TLS） "、2010年10月の作業。
Authors' Addresses
著者のアドレス
Kathleen M. Moriarty RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 US
Kathleen M. Moriarty RSA、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
ブライアン・H・トラメル・スイス連邦技術研究所チューリッヒ・グロリア・ストラス35 8092チューリッヒ・スイス
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch