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).
インシデントオブジェクトの説明交換フォーマット（IODEFは）（RID）文書交換のための共通のXMLフォーマットを定義し、リアルタイムの間のネットワーク防衛IODEFの拡張機能は、ネットワーク事業者や企業のコンソーシアム内のセキュリティインシデントの協力ハンドリングするためのものを定義します。このドキュメントでは、HTTP / TLS（Transport Layer Security）を超える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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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の）またはネットワーク・プロバイダ（NPS）のための取り扱いセキュリティインシデントの責任者との間でデータを交換する目的のために、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.
メッセージの共有がのCSIRTは、プロセスを扱う彼らの確立された事件に最も適した方法でメッセージを交換して格納することを可能にするために、範囲外であると想定されるIODEFは、メッセージ・フォーマットではなく、トランスポート・プロトコルを定義しています。しかし、リアルタイムの間のネットワーク防衛（RID）[RFC6045]はRIDコンソーシアムでメンバー間の相互運用性を確保するために、トランスポートプロトコルの仕様を必要としません。この文書では、トランスポート層セキュリティ（TLS）[RFC5246]（ここでは、HTTP / TLS）を介して伝送HTTP [RFC2616]リクエストとレスポンスメッセージ内RIDメッセージのトランスポートを指定します。任意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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
アプリケーションプロトコルのためにHTTPを使用する場合、BCP 56 [RFC3205]は重要な考慮事項の数を含んでいます。これらのアプリケーションは、プロトコルが80以外のポートで定義されるべきかどうか、Webブラウザを使用し、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のシステムは、コンソーシアムに参加するすべてのRIDシステムが割り当てられたポート上のHTTP / TLS接続をリッスンしなければならないポート4590.上のTCP接続をリッスンします。
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メッセージは、Request-URI「/」のでPOSTを使用して送らなければなりません。追加のRequest-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メッセージの種類を示しています。 RIDシステムは、対応するHTTPリクエストを送信するとき、所与のタイプのHTTPレスポンスを処理するために準備しなければなりません。 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システムは、202承認を返す接続を終了し、後で要求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
それはすぐにまたは一般的に受け入れられているHTTPクライアントのタイムアウト（約30秒）以内に利用可能な場合RIDシステムはHTTPレスポンスで応答を返すべきであるが、これは次のような必須ではありません、と
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システム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のシステムは、300の番台のリダイレクト応答コードを返すべきではありませんし、どんなの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メッセージを受信した場合、それは、要求RIDシステムに適切な4xxのクライアントエラー結果コードを返さなければなりません。 RIDシステムは、その自身の側のエラーにHTTP要求で受信RIDメッセージを処理できない場合は、要求元のRIDシステムに適切なの5xxサーバーエラー結果コードを返さなければなりません。
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.
輸送機密性、識別、および認証のために、相互認証を有するTLSは、[RFC2818]のようにHTTP接続を固定するために使用されなければなりません。セッションは、認証、完全性、機密性のために非NULL暗号スイートを使用する必要があります。セッションでは、これらの制約の範囲内で再交渉されるかもしれません。 TLSの実装は、一般的に古いのSecure Socket Layer（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発行者識別情報（「証明機関」）[RFC5280]直接に情報を交換する意思があるれるRIDシステムピアを認証するため、および/またはXの特定ホワイトリストのセットを信頼する必要がありますRIDシステムピアの509人の件名アイデンティティ。
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システムピアの身元の確認のために提供しなければなりません。ピア身元確認のベストプラクティスの詳細については、[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は、HTTP / TLS上でRIDサービス名を取り除くためにポート4590 / TCPが割り当てられています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、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.、マイヤー、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010.
[RFC6045]モリアーティ、K.、 "リアルタイムインターネットワーク防衛（RID）"、RFC 6045、2010年11月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
"基板としてのHTTPの使用について" [RFC3205]ムーア、K.、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]サンアンドレ、P.およびJ.ホッジス、「表現とドメインベースのアプリケーションサービスのアイデンティティの検証、インターネット公開鍵インフラストラクチャ内のトランスポート層セキュリティ（のコンテキストでX.509（PKIX）証明書を使用しましたTLS）」、進歩、2010年10月の作業。
Authors' Addresses
著者のアドレス
Kathleen M. Moriarty RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 US
キャスリーンM.モリアーティRSA、EMC 174ミドルターンパイクベッドフォードのセキュリティ部門、MA 01730米国
EMail: Moriarty_Kathleen@EMC.com
メールアドレス：Moriarty_Kathleen@EMC.com
Brian H. Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
テクノロジーのブライアンH.トラメルスイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13 EMail: trammell@tik.ee.ethz.ch
電話：+41 44 632 70 13 Eメール：trammell@tik.ee.ethz.ch