RFC4767 日本語訳
4767 The Intrusion Detection Exchange Protocol (IDXP). B. Feinstein,G. Matthews. March 2007. (Format: TXT=56048 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Feinstein
Request for Comments: 4767 SecureWorks, Inc.
Category: Experimental G. Matthews
CSC/NASA Ames Research Center
March 2007
コメントを求めるワーキンググループB.ファインスティン要求をネットワークでつないでください: 4767年のSecureWorks Inc.カテゴリ: 2007年の実験的なG.マシューズCSC/米航空宇宙局エイムズ研究所行進
The Intrusion Detection Exchange Protocol (IDXP)
侵入検出交換プロトコル(IDXP)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF.
このメモは、侵入検出実体の間でデータを交換するためにIntrusion Detection Exchangeプロトコル(IDXP)、アプリケーションレベルプロトコルについて説明します。 IDXPは接続指向のプロトコルの上で互いの認証、保全、および秘密性をサポートします。 プロトコルはIDMEFメッセージ、不統一なテキスト、およびバイナリ・データの交換に備えます。 RFC4765、「侵入検出交換処理形式(IDMEF)」(IETFのIntrusion Detection Exchange Format作業部会(IDWG)の仲間ドキュメント)でIDMEFメッセージ要素は説明されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Purpose ....................................................3
1.2. Profiles ...................................................3
1.3. Terminology ................................................3
2. The Model .......................................................4
2.1. Connection Provisioning ....................................4
2.2. Data Transfer ..............................................6
2.3. Connection Teardown ........................................7
2.4. Trust Model ................................................8
3. The IDXP Profile ................................................8
3.1. IDXP Profile Overview ......................................8
3.2. IDXP Profile Identification and Initialization .............9
3.3. IDXP Profile Message Syntax ................................9
3.4. IDXP Profile Semantics .....................................9
1. 序論…3 1.1. 目的…3 1.2. プロフィール…3 1.3. 用語…3 2. モデル…4 2.1. 接続の食糧を供給すること…4 2.2. データ転送…6 2.3. 接続分解…7 2.4. 信頼はモデル化されます…8 3. IDXPプロフィール…8 3.1. IDXPは概要の輪郭を描きます…8 3.2. IDXPは識別と初期設定の輪郭を描きます…9 3.3. IDXPはメッセージ構文の輪郭を描きます…9 3.4. IDXPは意味論の輪郭を描きます…9
Feinstein & Matthews Experimental [Page 1] RFC 4767 IDXP March 2007
2007年の[1ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
3.4.1. The IDXP-Greeting Element ..........................10
3.4.2. The Option Element .................................11
3.4.3. The IDMEF-Message Element ..........................12
4. IDXP Options ...................................................12
4.1. The channelPriority Option ................................13
4.2. The streamType Option .....................................14
5. Fulfillment of IDWG Communications Protocol Requirements .......16
5.1. Reliable Message Transmission .............................16
5.2. Interaction with Firewalls ................................16
5.3. Mutual Authentication .....................................16
5.4. Message Confidentiality ...................................17
5.5. Message Integrity .........................................17
5.6. Per-Source Authentication .................................17
5.7. Denial of Service .........................................18
5.8. Message Duplication .......................................18
6. Extending IDXP .................................................18
7. IDXP Option Registration Template ..............................19
8. Initial Registrations ..........................................19
8.1. Registration: The IDXP Profile ............................19
8.2. Registration: The System (Well-Known) TCP Port
Number for IDXP ...........................................19
8.3. Registration: The channelPriority Option ..................20
8.4. Registration: The streamType Option .......................20
9. The DTDs .......................................................20
9.1. The IDXP DTD ..............................................20
9.2. The channelPriority Option DTD ............................22
9.3. The streamType DTD ........................................23
10. Reply Codes ...................................................24
11. Security Considerations .......................................25
11.1. Use of the TUNNEL Profile ................................25
11.2. Use of Underlying Security Profiles ......................25
12. IANA Considerations ...........................................25
13. References ....................................................26
13.1. Normative References .....................................26
13.2. Informative References ...................................26
14. Acknowledgements ..............................................26
3.4.1. IDXP-挨拶要素…10 3.4.2. オプション要素…11 3.4.3. IDMEF-メッセージ要素…12 4. IDXPオプション…12 4.1. channelPriorityオプション…13 4.2. streamTypeオプション…14 5. IDWG通信規約要件の遂行…16 5.1. 信頼できるメッセージ送信…16 5.2. ファイアウォールとの相互作用…16 5.3. 互いの認証…16 5.4. メッセージ秘密性…17 5.5. メッセージの保全…17 5.6. 1ソースあたりの認証…17 5.7. サービス妨害…18 5.8. メッセージ複製…18 6. IDXPを広げています…18 7. IDXPオプション登録テンプレート…19 8. 登録証明書に頭文字をつけてください…19 8.1. 登録: IDXPプロフィール…19 8.2. 登録: システムの(よく知られる)のTCPはIDXPの数を移植します…19 8.3. 登録: channelPriorityオプション…20 8.4. 登録: streamTypeオプション…20 9. DTD…20 9.1. IDXP DTD…20 9.2. channelPriorityオプションDTD…22 9.3. streamType DTD…23 10. 回答コード…24 11. セキュリティ問題…25 11.1. トンネルプロフィールの使用…25 11.2. 基本的なセキュリティプロフィールの使用…25 12. IANA問題…25 13. 参照…26 13.1. 標準の参照…26 13.2. 有益な参照…26 14. 承認…26
Feinstein & Matthews Experimental [Page 2] RFC 4767 IDXP March 2007
2007年の[2ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
1. Introduction
1. 序論
IDXP is specified, in part, as a Blocks Extensible Exchange Protocol (BEEP) [4] "profile". BEEP is a generic application protocol framework for connection-oriented, asynchronous interactions. Features such as authentication and confidentiality are provided through the use of other BEEP profiles. Accordingly, many aspects of IDXP (e.g., confidentiality) are provided within the BEEP framework.
IDXPはBlocks Extensible Exchangeプロトコル(BEEP)[4]「プロフィール」として一部指定されます。 BEEPは接続指向の、そして、非同期な相互作用のための一般的適用プロトコルフレームワークです。 他のBEEPプロフィールの使用で認証や秘密性などの特徴を提供します。 それに従って、BEEPフレームワークの中でIDXP(例えば、秘密性)の多くの局面を提供します。
1.1. Purpose
1.1. 目的
IDXP provides for the exchange of IDMEF [2] messages, unstructured text, and binary data between intrusion detection entities. Addressing the security-sensitive nature of exchanges between intrusion detection entities, underlying BEEP security profiles should be used to offer IDXP the required set of security properties. See Section 5 for a discussion of how IDXP fulfills the IDWG communications protocol requirements. See Section 11 for a discussion of security considerations.
IDXPは侵入検出実体の間のIDMEF[2]メッセージ、不統一なテキスト、およびバイナリ・データの交換に備えます。 侵入検出実体の間の交換のセキュリティ敏感な本質を扱って、基本的なBEEPセキュリティプロフィールは、必要なセキュリティ資産をIDXPに提供するのに使用されるべきです。 IDXPがIDWG通信規約要件をどう実現させるかに関する議論に関してセクション5を見てください。 セキュリティ問題の議論に関してセクション11を見てください。
IDXP is primarily intended for the exchange of data created by intrusion detection entities. IDMEF [2] messages should be used for the structured representation of this intrusion detection data, although IDXP may be used to exchange unstructured text and binary data.
IDXPは侵入検出実体によって作成されたデータの交換のために主として意図します。 IDMEF[2]メッセージはこの侵入検出データの構造化された表現に使用されるべきです、IDXPが不統一なテキストとバイナリ・データを交換するのに使用されるかもしれませんが。
1.2. Profiles
1.2. プロフィール
There are several BEEP profiles discussed, the first of which we define in this memo:
議論した数個のBEEPプロフィールがあります:私たちはこのメモでその1番目を定義します。
The IDXP Profile
IDXPプロフィール
The TUNNEL Profile [3]
トンネルプロフィール[3]
The Simple Authentication and Security Layer (SASL) Family of
Profiles (see Section 4.1 of [4])
プロフィールの簡易認証とセキュリティ層(SASL)のファミリー([4])のセクション4.1を見てください。
The TLS Profile (see Section 3.1 of [4])
TLSプロフィール([4])のセクション3.1を見てください。
1.3. Terminology
1.3. 用語
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 BCP 14, RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
Feinstein & Matthews Experimental [Page 3] RFC 4767 IDXP March 2007
2007年の[3ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
Throughout this memo, the terms "analyzer" and "manager" are used in the context of the Intrusion Detection Message Exchange Requirements [5]. In particular, Section 2.2 of [5] defines a collection of intrusion detection terms.
このメモ中では、用語「分析器」と「マネージャ」はIntrusion Detection Message Exchange Requirements[5]の文脈で使用されます。 特に、[5]のセクション2.2は侵入検出用語の収集を定義します。
The terms "peer", "initiator", "listener", "client", and "server", and the characters "I", "L", "C", and "S" are used in the context of BEEP [4]. In particular, Section 2.1 of BEEP discusses the roles that a BEEP peer may perform.
「同輩」という用語、「創始者」、「リスナー」、「クライアント」、「サーバ」、およびキャラクタ「私」、「L」、「C」、および「S」はビープ音[4]の文脈で使用されます。 特に、BEEPのセクション2.1はBEEP同輩が実行するかもしれない役割について議論します。
The term "Document Type Definition" is abbreviated as "DTD" and is defined in Section 2.8 of the Extensible Markup Language (XML) [7].
「ドキュメント型定義」という用語は、「DTD」が簡略化されていて、拡張マークアップ言語(XML)[7]のセクション2.8で定義されます。
Note that the term "proxy" is specific to IDXP and does not exist in the context of BEEP. The term "intrusion detection" is abbreviated as "ID".
「プロキシ」という用語がIDXPに特定であり、BEEPの文脈に存在しないことに注意してください。 「侵入検出」という用語は「ID」が簡略化されています。
2. The Model
2. モデル
2.1. Connection Provisioning
2.1. 接続の食糧を供給すること
Intrusion detection entities using IDXP to transfer data are termed IDXP peers. Peers can exist only in pairs, and these pairs communicate over a single BEEP session with one or more BEEP channels opened for transferring data. Peers are either managers or analyzers, as defined in Section 2.2 of [5].
データを移すのにIDXPを使用する侵入検出実体がIDXP同輩と呼ばれます。 同輩は組だけで存在できます、そして、これらの組はデータを移すために開けられる1個以上のBEEPチャンネルとのただ一つのBEEPセッションの間、交信します。 同輩は、[5]のセクション2.2で定義されるようにマネージャか分析器のどちらかです。
The relationship between analyzers and managers is potentially many- to-many. That is, an analyzer MAY communicate with many managers; similarly, a manager MAY communicate with many analyzers. Likewise, the relationship between different managers is potentially many-to- many, so that a manager MAY receive the alerts sent by a large number of analyzers by receiving them through intermediate managers. Analyzers MUST NOT establish IDXP exchanges with other analyzers.
分析器とマネージャとの関係が潜在的に多い、-、多く すなわち、分析器は多くのマネージャとコミュニケートするかもしれません。 同様に、マネージャは多くの分析器で交信するかもしれません。 同様に、異なったマネージャの間の関係が潜在的に多い、-、-多くので、そのaマネージャは中間的マネージャを通してそれらを受けることによって、多くの分析器によって送られた警戒を受けるかもしれません。 分析器は他の分析器によるIDXP交換を確立してはいけません。
An IDXP peer wishing to establish IDXP communications with another IDXP peer does so by opening a BEEP channel, which may entail initiating a BEEP session. A BEEP security profile offering the required security properties SHOULD initially be negotiated (see Section 11 for a discussion of security considerations). Following the successful negotiation of the BEEP security profile, IDXP greetings are exchanged and connection provisioning proceeds.
別のIDXP同輩とのIDXPコミュニケーションを確立したがっているIDXP同輩は、BEEPチャンネルを開けることによって、そうします。(チャンネルはBEEPセッションを開始するのを伴うかもしれません)。 BEEPセキュリティが輪郭を描く、初めは特性のSHOULDを必要なセキュリティに提供して、交渉されてください(セキュリティ問題のa議論に関してセクション11を見てください)。 BEEPセキュリティプロフィールのうまくいっている交渉に続いて、IDXP挨拶を交換します、そして、接続の食糧を供給しかけること。
In the following sequence, the peer 'Alice' initiates an IDXP exchange with the peer 'Bob'.
以下の系列で、同輩'アリス'は同輩'ボブ'とのIDXP交換を起こします。
Feinstein & Matthews Experimental [Page 4] RFC 4767 IDXP March 2007
2007年の[4ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
Alice Bob
---------------- xport connect(1) ------------------>
<-------------------- greeting ---------------------->
<-------------start security profile(2) ------------->
<-------------------- greeting ---------------------->
<------------------ start IDXP(3) ------------------->
アリス・ボブ---------------- xportは(1)を接続します。------------------><。-------------------- 挨拶----------------------><。-------------セキュリティプロフィール(2)を始動してください。-------------><。-------------------- 挨拶----------------------><。------------------ IDXP(3)を始動してください。------------------->。
Notes:
注意:
(1) 'Alice' initiates a transport connection to 'Bob', triggering the
exchange of BEEP greeting messages.
(1) BEEPあいさつメッセージの交換の引き金となって、'アリス'は'ボブ'に輸送接続を開始します。
(2) Both entities negotiate the use of a BEEP security profile.
(2) 両方の実体はBEEPセキュリティプロフィールの使用を交渉します。
(3) Both entities negotiate the use of the IDXP profile.
(3) 両方の実体はIDXPプロフィールの使用を交渉します。
In between a pair of IDXP peers may be an arbitrary number of proxies. A proxy may be necessary for administrative reasons, such as running on a firewall to allow restricted access. Another use might be one proxy per company department, which forwards data from the analyzer peers in the department onto a company-wide manager peer.
中間で、1組のIDXP同輩はプロキシの特殊活字の数字であるかもしれません。 プロキシが制限されたアクセサリーを許容しにファイアウォールで動くことなどの管理理由に必要であるかもしれません。 会社の部あたり別の使用は1つのプロキシであるかもしれません。(それは、データを部の分析器の同輩から会社の全体のマネージャの同輩に転送します)。
A BEEP tuning profile MAY be used to create an application-layer tunnel that transparently forwards data over a chain of proxies. The TUNNEL profile [3] SHOULD be used for this purpose; see [3] for more detail concerning the options available to set up an application- layer tunnel using TUNNEL, and see Section 11.1 for a discussion of TUNNEL-related security considerations. TUNNEL MUST be offered as a tuning profile for the creation of application-layer tunnels. The TUNNEL profile MUST offer the use of some form of SASL authentication (see Section 4.1 of [4]). Once a tunnel has been created, a BEEP security profile offering the required security properties SHOULD be negotiated, followed by negotiation of the IDXP profile.
BEEPチューニングプロフィールは、透過的にプロキシのチェーンの上にデータを転送する応用層トンネルを作成するのに使用されるかもしれません。 TUNNELは[3] SHOULDの輪郭を描きます。このために使用されてください。 アプリケーション層のトンネルを設立するために利用可能なオプションに関してTUNNELを使用することでその他の詳細のための[3]を見てください、そして、TUNNEL関連のセキュリティ問題の議論に関してセクション11.1を見てください。 TUNNEL MUST、応用層の作成のためのチューニングプロフィールがトンネルを堀るので、提供してください。 TUNNELプロフィールは何らかの形式のSASL認証の使用を提供しなければなりません。([4])のセクション4.1を見てください。 トンネルがいったん作成されると、IDXPプロフィールの交渉で、特性のSHOULDを必要なセキュリティに提供するBEEPセキュリティプロフィールは、交渉されて、従いました。
The following sequence shows how TUNNEL might be used to create an application-layer tunnel through which IDXP would operate. A peer 'Alice' initiates the creation of a BEEP session using the IDXP profile with the entity 'Bob' by first contacting 'proxy1'. In the greeting exchange between 'Alice' and 'proxy1', the TUNNEL profile is selected, and subsequently the use of the TUNNEL profile is extended to reach through 'proxy2' to 'Bob'.
以下の系列はTUNNELがIDXPが作動する応用層トンネルを作成するのにどう使用されるかもしれないかを示しています。 同輩'アリス'は、'proxy1'に連絡しながら最初にで実体'ボブ'があるIDXPプロフィールを使用することでBEEPセッションの作成を開始します。 'アリス'と'proxy1'の間の挨拶交換では、TUNNELプロフィールは選択されます、そして、次にTUNNELプロフィールの使用は、'proxy2'を通して'ボブ'に達するように広げられます。
Feinstein & Matthews Experimental [Page 5] RFC 4767 IDXP March 2007
2007年の[5ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
Alice proxy1 proxy2 Bob
-- xport connect -->
<---- greeting ----->
-- start TUNNEL --->
- xport connect(1) ->
<----- greeting ----->
--- start TUNNEL --->
--- xport connect -->
<----- greeting ----->
--- start TUNNEL --->
<----- <ok>(2) ------
<------- <ok> -------
<------ <ok> -------
<------------------------- greeting -------------------------->
<------------------ start security profile ------------------->
<------------------------- greeting -------------------------->
<------------------------ start IDXP ------------------------->
アリス・proxy1 proxy2ボブ--xportに接続してください--、><。---- 挨拶----->--TUNNELを始動してください。--->--xportは(1) -><を接続します。----- 挨拶----->。--- TUNNELを始動してください。--->。--- xportに接続してください--、><。----- 挨拶----->。--- TUNNELを始動してください。---><。----- <の間違いない>(2)------ <、-、-、-、-、-、-- <の間違いない>。------- <、-、-、-、-、-- <の間違いない>。------- <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 挨拶--------------------------><。------------------ スタートセキュリティプロフィール-------------------><。------------------------- 挨拶--------------------------><。------------------------ IDXPを始動してください。------------------------->。
Notes:
注意:
(1) Instead of immediately acknowledging the request from 'Alice' to
start TUNNEL, 'proxy1' attempts to establish use of TUNNEL with
'proxy2'. 'proxy2' also delays its acknowledgment to 'proxy1'.
(1) すぐにTUNNELを始動するために'アリス'からの要求を承諾することの代わりに、'proxy1'は、'proxy2'とのTUNNELの使用を確立するのを試みます。 また、'proxy2'は'proxy1'に承認を遅らせます。
(2) 'Bob' acknowledges the request from 'proxy2' to start TUNNEL, and
this acknowledgment propagates back to 'Alice' so that a TUNNEL
application-layer tunnel is established from 'Alice' to 'Bob'.
(2) 'ボブ'がTUNNELを始動するために'proxy2'からの要求を承諾して、この承認が'アリス'に伝播して戻られるので、TUNNEL応用層トンネルは'アリス'から'ボブ'まで確立されます。
2.2. Data Transfer
2.2. データ転送
Between a pair of ID entities communicating over a BEEP session, one or more BEEP channels MAY be opened using the IDXP profile. If desired, additional BEEP sessions MAY be established to offer additional channels using the IDXP profile. However, in most situations additional channels using the IDXP profile SHOULD be opened within an existing BEEP session, as opposed to provisioning a new BEEP session containing the additional channels using the IDXP profile.
BEEPチャンネルがそうするBEEPセッションの間に交信する1組のID実体、1つまたは以上の間では、IDXPプロフィールを使用することで開かれてください。 望まれているなら、追加BEEPセッションは、IDXPプロフィールを使用することで追加チャンネルを提供するために確立されるかもしれません。 しかしながら、ほとんどの状況で、IDXPを使用している追加チャンネルがSHOULDの輪郭を描きます。既存のBEEPセッション以内に開かれてください、IDXPプロフィールを使用することで追加チャンネルを含んでいて、新しいBEEPセッションに食糧を供給することと対照的に。
Peers assume the role of client or server on a per-channel basis, with one acting as the client and the other as the server. A peer's role of client or server is determined independent of whether the peer assumed the role of initiator or listener during the BEEP session establishment. Clients and servers act as sources and sinks, respectively, for exchanging data.
同輩は1チャンネルあたり1個のベースでクライアントかサーバの役割を引き受けます、1つがサーバとしてのクライアントともう片方として機能して。同輩がBEEPセッション設立の間、創始者かリスナーの役割を引き受けたかどうかの如何にかかわらず同輩のクライアントかサーバの役割は決定しています。 クライアントとサーバは、データを交換するためにソースと流し台としてそれぞれ演じられます。
Feinstein & Matthews Experimental [Page 6] RFC 4767 IDXP March 2007
2007年の[6ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
In a simple case, an analyzer peer sends data to a manager peer. For example,
簡単な場合では、分析器の同輩はマネージャの同輩にデータを送ります。 例えば
+----------+ +----------+ | | | | | |****** BEEP session ******| | | | | | | Analyzer | ----- IDXP profile ----> | Manager | | (Client) | | (Server) | | | | | | |**************************| | | | | | +----------+ +----------+
+----------+ +----------+ | | | | | |****** BEEPセッション******| | | | | | | 分析器| ----- IDXPプロフィール---->| マネージャ| | (クライアント) | | (サーバ) | | | | | | |**************************| | | | | | +----------+ +----------+
Use of multiple BEEP channels in a BEEP session facilitates categorization and prioritization of data sent between IDXP peers. For example, a manager 'M1', sending alert data to another manager, 'M2', may choose to open a separate channel to exchange different categories of alerts. 'M1' would act as the client on each of these channels, and manager 'M2' can then process and act on the incoming alerts based on their respective channel categorizations. See Section 4 for more detail on how to incorporate categorization and/or prioritization into channel creation.
BEEPセッションにおける複数のBEEPチャンネルの使用はIDXP同輩の間に送られたデータの分類と優先順位づけを容易にします。 例えば、マネージャ'M1'(別のマネージャに注意を喚起するデータを送る'M2')は、警戒の異なったカテゴリを交換するために別々のチャンネルを開けるのを選ぶかもしれません。 'M1'がクライアントとしてこれらのチャンネル各人に機能して、次に、マネージャ'M2'は、彼らのそれぞれのチャンネル分類に基づく入って来る警戒を、処理して、影響できます。 どう分類、そして/または、優先順位づけをチャンネル作成に組み入れるかに関するその他の詳細に関してセクション4を見てください。
+----------+ +----------+ | | | | | |*************** BEEP session ***************| | | | | | | | -- IDXP profile, network-based alerts ---> | | | Manager | | Manager | | M1 | ---- IDXP profile, host-based alerts ----> | M2 | | (Client) | | (Server) | | | ------ IDXP profile, other alerts -------> | | | | | | | |********************************************| | | | | | +----------+ +----------+
+----------+ +----------+ | | | | | |*************** BEEPセッション***************| | | | | | | | -- IDXPプロフィール、ネットワークベースの警戒--->|、|、| マネージャ| | マネージャ| | M1| ---- IDXPプロフィール、ホストベースの警戒---->| M2| | (クライアント) | | (サーバ) | | | ------ IDXPプロフィール、他の警戒------->|、|、|、|、|、|、| |********************************************| | | | | | +----------+ +----------+
2.3. Connection Teardown
2.3. 接続分解
An IDXP peer may choose to close an IDXP channel under many different circumstances (e.g., an error in processing has occurred). To close a channel, the peer sends a "close" element (see Section 2.3.1.3 of [4]) on channel zero indicating which channel is being closed. An IDXP peer may also choose to close an entire BEEP session by sending a "close" element indicating that channel zero is to be closed.
IDXP同輩は、多くの異なった状況でIDXPチャンネルを閉じるのを選ぶかもしれません(例えば処理における誤りは発生しました)。 セクション2.3を見てください。チャンネルを閉じるために、同輩が「近い」要素を送る、(.1 .3 チャンネルの[4])では、どれが精神を集中するかを示し終えられていません。 また、IDXP同輩は、「近い」要素にチャンネルゼロが閉店していることになっているのを示させることによって全体のBEEPセッションを終えるのを選ぶかもしれません。
Feinstein & Matthews Experimental [Page 7] RFC 4767 IDXP March 2007
2007年の[7ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
Section 2.3.1.3 of [4] offers a more complete discussion of the circumstances under which a BEEP peer is permitted to close a channel and the mechanisms for doing so.
セクション2.3 .1 .3 [4] 申し出では、BEEPがじっと見る事情の、より完全な議論がそうするためにチャンネルとメカニズムを閉じることが許可されています。
It is anticipated that due to the overhead of provisioning an application-layer tunnel and/or a BEEP security profile, BEEP sessions containing IDXP channels will be long-lived. In addition, the repeated overhead of IDXP channel provisioning (i.e., the exchange of IDXP greetings) may be avoided by keeping IDXP channels open even while data is not actively being exchanged on them. These are recommendations and, as such, IDXP peers may choose to close and re-provision BEEP sessions and/or IDXP channels as they see fit.
IDXPチャンネルを含むのが長命であると応用層トンネル、そして/または、BEEPセキュリティプロフィール、BEEPに食糧を供給するオーバーヘッドによるそのセッションに予期されます。 さらに、IDXPチャンネルの食糧を供給すること(すなわち、IDXP挨拶の交換)の繰り返されたオーバーヘッドは、データがそれらで活発に交換されてさえいない間、IDXPチャンネルを開くように保つことによって、避けられるかもしれません。 これらは推薦です、そして、そういうものとして、彼らが適していると決めるようにIDXP同輩は閉鎖と再支給BEEPセッション、そして/または、IDXPチャンネルに選ぶかもしれません。
2.4. Trust Model
2.4. 信頼モデル
In our model, trust is placed exclusively in the IDXP peers. Proxies are always assumed to be untrustworthy. A BEEP security profile is used to establish end-to-end security between pairs of IDXP peers, doing away with the need to place trust in any intervening proxies. Only after successful negotiation of the underlying security profile are IDXP peers to be trusted. Only BEEP security profiles offering at least the protections required by Section 5 of [5] should be used to secure a BEEP session containing channels using the IDXP profile. See Section 3 of [4] for the registration of the TLS profile, an example of a BEEP security profile meeting the requirements of Section 5 of [5]. See Section 5 for a discussion of how IDXP fulfills the IDWG communications protocol requirements.
私たちのモデルでは、信頼は排他的にIDXP同輩に置かれます。 いつもプロキシが信頼できないと思われます。 BEEPセキュリティプロフィールはIDXP同輩の組の間の終わりから終わりへのセキュリティを証明するのに使用されます、どんな介入しているプロキシでも信頼する必要性を無くならせて。 基本的なセキュリティプロフィールのうまくいっている交渉の後にだけIDXP同輩は信じられることになっています。 少なくとも[5]のセクション5によって必要とされた保護を提供するBEEPセキュリティプロフィールだけがIDXPプロフィールを使用することでチャンネルを含んでいて、BEEPセッションを保証するのにおいて使用されているべきです。 TLSプロフィール([5]のセクション5に関する必要条件を満たすBEEPセキュリティプロフィールに関する例)の登録のための[4]のセクション3を見てください。 IDXPがIDWG通信規約要件をどう実現させるかに関する議論に関してセクション5を見てください。
3. The IDXP Profile
3. IDXPプロフィール
3.1. IDXP Profile Overview
3.1. IDXPプロフィール概要
The IDXP profile provides a mechanism for exchanging information between intrusion detection entities. A BEEP tuning profile MAY be used to create an application-layer tunnel that transparently forwards data over a chain of proxies. The TUNNEL profile [3] SHOULD be used for this purpose; see [3] for more detail concerning the options available to set up an application-layer tunnel using TUNNEL, and see Section 11.1 for a discussion of TUNNEL-related security considerations. TUNNEL MUST be offered as a tuning profile for the creation of application-layer tunnels. The TUNNEL profile MUST offer the use of some form of SASL authentication (see Section 4.1 of [4]). The TLS profile SHOULD be used to provide the required combination of mutual-authentication, integrity, and confidentiality for the IDXP profile. For further discussion of application-layer tunnel and security issues, see Sections 2.1 and 11.
IDXPプロフィールは侵入検出実体の間で情報交換するのにメカニズムを提供します。 BEEPチューニングプロフィールは、透過的にプロキシのチェーンの上にデータを転送する応用層トンネルを作成するのに使用されるかもしれません。 TUNNELは[3] SHOULDの輪郭を描きます。このために使用されてください。 応用層トンネルを設立するために利用可能なオプションに関してTUNNELを使用することでその他の詳細のための[3]を見てください、そして、TUNNEL関連のセキュリティ問題の議論に関してセクション11.1を見てください。 TUNNEL MUST、応用層の作成のためのチューニングプロフィールがトンネルを堀るので、提供してください。 TUNNELプロフィールは何らかの形式のSASL認証の使用を提供しなければなりません。([4])のセクション4.1を見てください。 TLSはSHOULDの輪郭を描きます。使用されて、互いの認証、保全、および秘密性の必要な組み合わせをIDXPプロフィールに供給してください。 応用層トンネルと安全保障問題のさらなる議論に関しては、セクション2.1と11を見てください。
Feinstein & Matthews Experimental [Page 8] RFC 4767 IDXP March 2007
2007年の[8ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
The IDXP profile supports several elements of interest:
IDXPプロフィールは興味がある数個の要素を支えます:
o The "IDXP-Greeting" element identifies an analyzer or manager at
one end of a BEEP channel to the analyzer or manager at the other
end of the channel.
o 「IDXP-挨拶」要素はチャンネルのもう一方の端の分析器かマネージャのBEEPチャンネルの片端で分析器かマネージャを特定します。
o The "Option" element is used to convey optional channel parameters
between peers during the exchange of "IDXP-Greeting" elements.
This element is OPTIONAL.
o 「オプション」要素は、「IDXP-挨拶」要素の交換の間、同輩の間の任意のチャンネルパラメタを伝えるのに使用されます。 この要素はOPTIONALです。
o The "IDMEF-Message" element carries the structured information to
be exchanged between the peers.
o 「IDMEF-メッセージ」要素は、同輩の間で交換するために構造化された情報を運びます。
3.2. IDXP Profile Identification and Initialization
3.2. IDXPプロフィール識別と初期設定
The IDXP profile is identified as
プロフィールが特定されるIDXP
http://idxp.org/beep/profile
http://idxp.org/beep/profile
in the BEEP "profile" element during channel creation.
チャンネル作成の間のBEEP「プロフィール」要素で。
During channel creation, "IDXP-Greeting" elements MUST be mutually exchanged between the peers. An "IDXP-Greeting" element MAY be contained within the corresponding "profile" element in the BEEP "start" element. Including an "IDXP-Greeting" element in the initial "start" element has exactly the same semantics as passing it as the first "MSG" message on the channel. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "IDXP-Greeting" element and includes the resulting response in the reply. This response will be an "ok" element or an "error" element. The choice of which element is returned is dependent on local provisioning of the peer.
チャンネル作成の間、同輩の間で互いに「IDXP-挨拶」要素を交換しなければなりません。 「IDXP-挨拶」要素はBEEP「始め」要素に対応する「プロフィール」要素の中に含まれるかもしれません。 初期の「始め」要素の「IDXP-挨拶」要素を含むのにおいて、まさにチャンネルに関する最初の「エムエスジー」メッセージとしてそれを通過するのと同じ意味論があります。 チャンネル作成がうまくいくなら、対応する回答を送る前に、BEEP同輩は、「IDXP-挨拶」要素を処理して、回答における結果として起こる応答を入れます。 この応答は、「間違いありません、な」要素か「誤り」要素になるでしょう。 選択はどの要素が返されるかを同輩の地方の食糧を供給することに依存しています。
3.3. IDXP Profile Message Syntax
3.3. IDXPプロフィールメッセージ構文
BEEP messages in the profile MUST have a MIME Content-Type [8] of "text/xml", "text/plain", or "application/octet-stream". The syntax of the individual elements is specified in Section 9.1 of this document and Section 4 of [2].
プロフィールのBEEPメッセージには、「テキスト/xml」、「テキスト/平野」、または「八重奏アプリケーション/ストリーム」のMIMEコンテントタイプ[8]がなければなりません。 個々の要素の構文はこのドキュメントのセクション9.1と[2]のセクション4で指定されます。
3.4. IDXP Profile Semantics
3.4. IDXPプロフィール意味論
Each BEEP peer issues the "IDXP-Greeting" element using "MSG" messages. The "IDXP-Greeting" element MAY contain one or more "Option" sub-elements, conveying optional channel parameters. Each BEEP peer then issues "ok" in "RPY" messages or "error" in "ERR" messages. (See Section 2.3.1 of [4] for the definitions of the "error" and "ok" elements.) An "error" element MAY be issued within
それぞれのBEEP同輩は、「エムエスジー」メッセージを使用することで「IDXP-挨拶」要素を発行します。 任意のチャンネルパラメタを伝えて、「IDXP-挨拶」要素は1つ以上の「オプション」下位要素を含むかもしれません。 そして、それぞれのBEEP同輩は「間違えてください」で"RPY"メッセージか「誤り」で「OKに」メッセージを発行します。 (「誤り」と「間違いありません、な」要素の定義のための[4]についてセクション2.3.1を見てください。) 中で「誤り」要素を発行するかもしれません。
Feinstein & Matthews Experimental [Page 9] RFC 4767 IDXP March 2007
2007年の[9ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
a "RPY" message when piggy-backed within a BEEP "profile" element. See Section 3.4.1 for an example of an "error" element being issued within a "RPY" message. Based on the respective client/server roles negotiated during the exchange of "IDXP-Greeting" elements, the client sends data using "MSG" messages. Depending on the MIME Content-Type, this data may be an "IDMEF-Message" element, plain text, or binary. The server then issues "ok" in "RPY" messages or "error" in "ERR" messages.
ビープ音の中で背負われると、"RPY"メッセージは要素の「輪郭を描きます」。 "RPY"メッセージの中で発行される「誤り」要素の例に関してセクション3.4.1を見てください。 「IDXP-挨拶」要素の交換の間に交渉されたそれぞれのクライアント/サーバーの役割に基づいて、クライアントは、「エムエスジー」メッセージを使用することでデータを送ります。 MIMEコンテントタイプによって、このデータは、「IDMEF-メッセージ」要素、プレーンテキスト、またはバイナリーであるかもしれません。 そして、サーバは「間違えてください」で"RPY"メッセージか「誤り」で「OKに」メッセージを発行します。
3.4.1. The IDXP-Greeting Element
3.4.1. IDXP-挨拶要素
The "IDXP-Greeting" element serves to identify the analyzer or manager at one end of the BEEP channel to the analyzer or manager at the other end of the channel. The "IDXP-Greeting" element MUST include the role of the peer on the channel (client or server) and the Uniform Resource Identifier (URI) [6] of the peer. In addition, the "IDXP-Greeting" element MAY include the fully qualified domain name (see [9]) of the peer. One or more "Option" sub-elements MAY be present.
「IDXP-挨拶」要素は、チャンネルのもう一方の端の分析器かマネージャのBEEPチャンネルの片端で分析器かマネージャを特定するのに役立ちます。 「IDXP-挨拶」要素はチャンネル(クライアントかサーバ)の上の同輩の役割と同輩のUniform Resource Identifier(URI)[6]を含まなければなりません。 さらに、「IDXP-挨拶」要素は完全修飾ドメイン名を含むかもしれません。(同輩の[9])を見てください。 1つ以上の「オプション」下位要素が存在しているかもしれません。
An "IDXP-Greeting" element MAY be sent by either peer at any time. The peer receiving the "IDXP-Greeting" MUST respond with an "ok" (indicating acceptance), or an "error" (indicating rejection). A peer's identity and role on a channel and any optional channel parameters are, in effect, specified by the most recent "IDXP- Greeting" it sent that was answered with an "ok".
「IDXP-挨拶」要素はいつでも、どちらの同輩によっても送られるかもしれません。 「IDXP-挨拶」を受ける同輩は「OK」(承認を示す)、または「誤り」で応じなければなりません(拒絶を示して)。 事実上、チャンネルとどんな任意のチャンネルパラメタに関する同輩のアイデンティティと役割もそれが送った「OK」で答えられた最新の「IDXP挨拶」で指定されます。
An "IDXP-Greeting" may be rejected (with an "error" element) under many circumstances. These include, but are not limited to, authentication failure, lack of authorization to connect under the specified role, the negotiation of an inadequate cipher suite, or the presence of a channel option that must be understood but was unrecognized.
「IDXP-挨拶」は多くの状況で拒絶されるかもしれません(「誤り」要素で)。 これらが含んでいる、認証失敗、有限であることで、指定された役割、不十分な暗号スイートの交渉、またはチャンネルオプションの存在の下でその必須を接続する承認の不足が理解されていますが、認識されていなかったということではありません。
For example, a successful creation with an embedded "IDXP-Greeting" might look like this:
例えば、埋め込まれた「IDXP-挨拶」があるうまくいっている作成はこれに似るかもしれません:
I: MSG 0 10 . 1592 187 I: Content-Type: text/xml I: I: <start number='1'> I: <profile uri='http://idxp.org/beep/profile'> I: <![CDATA[ <IDXP-Greeting uri='http://example.com/alice' I: role='client' /> ]]> I: </profile> I: </start> I: END L: RPY 0 10 . 1865 91
私: エムエスジー0 10、.1592187、私: コンテントタイプ: テキスト/xml I: 私: <スタート番号は'1'>Iと等しいです:、' ' http://idxp.org/beep/profile '<プロフィールuri=>I:、' <[CDATA[<IDXP-挨拶uri=' http://example.com/alice 'I: 役割='クライアント'/>]]!>I: </プロフィール>I: </スタート>I: 終わりL: RPY0 10、.1865 91
Feinstein & Matthews Experimental [Page 10] RFC 4767 IDXP March 2007
2007年の[10ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
L: Content-Type: text/xml L: L: <profile uri='http://idxp.org/beep/profile'> L: <![CDATA[ <ok /> ]]> L: </profile> L: END L: MSG 0 11 . 1956 61 L: Content-Type: text/xml L: L: <IDXP-Greeting uri='http://example.com/bob' role='server' /> L: END I: RPY 0 11 . 1779 7 I: Content-Type: text/xml I: I: <ok /> I: END
L: コンテントタイプ: テキスト/xml L: L: ' http://idxp.org/beep/profile '<プロフィールuri=>L:、' <[CDATA[<OK/>]]!>L: </プロフィール>L: 終わりL: エムエスジー0 11、.1956 61、L: コンテントタイプ: テキスト/xml L: L: <IDXP-挨拶uriは' http://example.com/bob '役割='サーバ'/>Lと等しいです: 終わりI: RPY0 11、.17797、私: コンテントタイプ: テキスト/xml I: 私: <OK/>I: 終わり
A creation with an embedded "IDXP-Greeting" that fails might look like this:
失敗する埋め込まれた「IDXP-挨拶」がある作成はこれに似るかもしれません:
I: MSG 0 10 . 1776 185 I: Content-Type: text/xml I: I: <start number='1'> I: <profile uri='http://idxp.org/beep/profile'> I: <![CDATA[ <IDXP-Greeting uri='http://example.com/eve' I: role='client' /> ]]> I: </profile> I: </start> I: END L: RPY 0 10 . 1592 182 L: Content-Type: text/xml L: L: <profile uri='http://idxp.org/beep/profile'> L: <![CDATA[ L: <error code='530'>'http://example.com/eve' must first L: negotiate the TLS profile</error> ]]> L: </profile> L: END
私: エムエスジー0 10、.1776185、私: コンテントタイプ: テキスト/xml I: 私: <スタート番号は'1'>Iと等しいです:、' ' http://idxp.org/beep/profile '<プロフィールuri=>I:、' <[CDATA[<IDXP-挨拶uri=' http://example.com/eve 'I: 役割='クライアント'/>]]!>I: </プロフィール>I: </スタート>I: 終わりL: RPY0 10、.1592182、L: コンテントタイプ: テキスト/xml L: L: ' http://idxp.org/beep/profile '<プロフィールuri=>L:、' <[CDATA[L: <エラーコードは'530'>' http://example.com/eve '必須1L番目と等しいです: TLSプロフィール</誤り>を交渉する]]!>L:、' </プロフィール>L: 終わり
3.4.2. The Option Element
3.4.2. オプション要素
If present, the "Option" element MUST be contained within an "IDXP- Greeting" element. An individual "IDXP-Greeting" element MAY contain one or more "Option" sub-elements. Each "Option" element within an "IDXP-Greeting" element represents a request to enable an IDXP option on the channel being negotiated. See Section 4 for a complete description of IDXP options and the "Option" element.
存在しているなら、「IDXP挨拶」要素の中に「オプション」要素を含まなければなりません。 個々の「IDXP-挨拶」要素は1つ以上の「オプション」下位要素を含むかもしれません。 「IDXP-挨拶」要素の中のそれぞれの「オプション」要素は交渉されるチャンネルでIDXPオプションを可能にするという要求を表します。 IDXPオプションの完全な記述と「オプション」要素に関してセクション4を見てください。
Feinstein & Matthews Experimental [Page 11] RFC 4767 IDXP March 2007
2007年の[11ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
3.4.3. The IDMEF-Message Element
3.4.3. IDMEF-メッセージ要素
The "IDMEF-Message" element carries the information to be exchanged between the peers. See Section 4 of [2] for the definition of this element.
「IDMEF-メッセージ」要素は、同輩の間で交換するために情報を運びます。 この要素の定義のための[2]のセクション4を見てください。
4. IDXP Options
4. IDXPオプション
IDXP provides a service for the reliable exchange of data between intrusion detection entities. Options are used to alter the semantics of the service.
IDXPはデータの信頼できる交換のためのサービスを侵入検出実体の間に提供します。 オプションは、サービスの意味論を変更するのに使用されます。
The specification of an IDXP option MUST define
IDXPオプションの仕様は定義されなければなりません。
o the identity of the option;
o オプションのアイデンティティ。
o what content, if any, is contained within the option; and
o もしあればどんな内容がオプションの中に含まれているか。 そして
o the processing rules for the option.
o 処理はオプションのために統治されます。
An option registration template (see Section 7) organizes this information.
オプション登録テンプレート(セクション7を見る)はこの情報を組織化します。
An "Option" element is contained within an "IDXP-Greeting" element. The "IDXP-Greeting" element itself MAY contain one or more "Option" elements. The "Option" element has several attributes and contains arbitrary content:
「オプション」要素は「IDXP-挨拶」要素の中に含まれています。 「IDXP-挨拶」要素自体は1つ以上の「オプション」要素を含むかもしれません。 「オプション」要素は、いくつかの属性を持っていて、任意の内容を含んでいます:
o the "internal" and the "external" attributes, exactly one of which
MUST be present, uniquely identify the option;
o 「内部」の属性と「外部」の属性(ちょうどそれの1つは存在していなければならない)は唯一オプションを特定します。
o the "mustUnderstand" attribute, whose presence is OPTIONAL and
whose default value is "false", specifies whether the option, if
unrecognized, MUST cause an error in processing to occur; and
o "mustUnderstand"属性(存在がOPTIONALであり、デフォルト値は「誤っている」)は、認識されていないなら処理における誤りがオプションで発生しなければならないかどうか指定します。 そして
o the "localize" attribute, whose presence is OPTIONAL, specifies
one or more language tokens, each identifying a desirable language
tag to be used if textual diagnostics are returned to the
originator.
o 「ローカライズしてください」という属性(存在はOPTIONALである)は1つ以上の言語トークンを指定します、原文の病気の特徴を創始者に返すなら使用されるためにそれぞれ望ましい言語タグを特定して。
The value of the "internal" attribute is the IANA-registered name for the option. If the "internal" attribute is not present, then the value of the "external" attribute is a URI or URI with a fragment- identifier. Note that a relative-URI value is not allowed.
「内部」の属性の値はオプションのためのIANA-登録名です。 「内部」の属性が存在していないなら、「外部」の属性の値は、断片識別子があるURIかURIです。 相対的なURI値が許容されていないことに注意してください。
The "mustUnderstand" attribute specifies whether the peer may ignore the option if it is unrecognized. If the value of the "mustUnderstand" attribute is "true", and if the peer does not
"mustUnderstand"属性は、それが認識されていないなら同輩がオプションを無視するかもしれないかどうか指定します。 「本当に」、同輩がそうしないなら"mustUnderstand"属性の値がそうなら
Feinstein & Matthews Experimental [Page 12] RFC 4767 IDXP March 2007
2007年の[12ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
recognize the option, then an error in processing has occurred. When absent, the value of the "mustUnderstand" attribute is defined to be "false".
オプションを認識してください、そして、次に、処理における誤りは発生しました。 休むとき、"mustUnderstand"属性の値は、「誤る」ために定義されます。
4.1. The channelPriority Option
4.1. channelPriorityオプション
Section 8.3 contains the IDXP option registration for the "channelPriority" option. This option contains a "channelPriority" element (see Section 9.2).
セクション8.3は"channelPriority"オプションのためのIDXPオプション登録を含みます。 このオプションは"channelPriority"要素を含んでいます(セクション9.2を見てください)。
By default, IDXP does not place any requirements on how peers should manage multiple IDXP channels. The "channelPriority" option provides a way for peers using multiple IDXP channels to request relative priorities for each channel. When sending an "IDXP-Greeting" element during the provisioning of an IDXP channel, the originating peer MAY request that the remote peer assign a priority to the channel by including an "Option" element containing a "channelPriority" element.
デフォルトで、IDXPは同輩がどう複数のIDXPチャンネルを管理するべきであるかに関するどんな要件も置きません。 "channelPriority"オプションは、各チャンネルのために相対的なプライオリティを要求するのに複数のIDXPチャンネルを使用することで道を同輩に提供します。 IDXPチャンネルの食糧を供給する間「IDXP-挨拶」要素を送るとき、起因している同輩は、リモート同輩が"channelPriority"要素を含む「オプション」要素を含んでいることによってチャンネルの優先を割り当てるよう要求するかもしれません。
The "channelPriority" element has one attribute named "priority", of range 0..2147483647. This attribute is REQUIRED. Not coincidentally, this is the maximum range of possible BEEP channel numbers. 0 is defined to represent the highest priority, with relative priority decreasing as the "priority" value ascends.
"channelPriority"要素には、範囲0の「優先権」という1つの属性があります。2147483647. この属性はREQUIREDです。 これは一致してない、可能なBEEP論理機番の最大範囲です。 0 「優先権」値が昇るのに従って相対的な優先権が減少している状態で最優先を表すために、定義されます。
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, an analyzer successfully requests that a manager assign a priority to the channel:
例えば、チャンネルの食糧を供給する間の「IDXP-挨拶」要素の交換の間、分析器は、マネージャがチャンネルの優先を割り当てるよう首尾よく要求します:
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
分析器のマネージャ--------------- オプションによる挨拶-----------------><。---------------------- <の間違いない>。------------------------
C: MSG 1 17 . 1984 165 C: Content-Type: text/xml C: C: <IDXP-Greeting uri='http://example.com/alice' role='client'> C: <Option internal='channelPriority'> C: <channelPriority priority='0' /> C: </Option> C: </IDXP-Greeting> C: END S: RPY 1 17 . 2001 7 S: Content-Type: text/xml S: S: <ok /> S: END
C: エムエスジー、1 17 .1984165C: コンテントタイプ: テキスト/xml C: C: <IDXP-挨拶uri=' http://example.com/alice の'の役割は'クライアント'>Cと等しいです'。 <オプション内部の='channelPriority'>C:、' <channelPriority優先権は'0'/>Cと等しいです: </オプション>C: IDXP</挨拶>C: 終わりS: RPY、1 17 .2001 7秒間: コンテントタイプ: テキスト/xml S: S: <OK/>S: 終わり
Feinstein & Matthews Experimental [Page 13] RFC 4767 IDXP March 2007
2007年の[13ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, a manager unsuccessfully requests that an analyzer assign a priority to the channel:
例えば、チャンネルの食糧を供給する間の「IDXP-挨拶」要素の交換の間、マネージャは、分析器がチャンネルの優先を割り当てるよう要求して失敗した:
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
分析器のマネージャ<。---------------- オプションによる挨拶---------------- --------------------- <誤り>。---------------------->。
S: MSG 1 17 . 1312 194 S: Content-Type: text/xml S: S: <IDXP-Greeting uri='http://example.com/bob' role='server'> S: <Option internal='channelPriority' mustUnderstand='true'> S: <channelPriority priority='2147483647' /> S: </Option> S: </IDXP-Greeting> S: END C: ERR 1 17 . 451 68 C: Content-Type: text/xml C: C: <error code='504'>'channelPriority' option was unrecognized</error> C: END
S: エムエスジー、1 17 .1312 194秒間: コンテントタイプ: テキスト/xml S: S: <IDXP-挨拶uri=' http://example.com/bob の'の役割は'サーバ'>Sと等しいです'。 <オプションインターナル='channelPriority'mustUnderstandは'本当'の>Sと等しいです'。 <channelPriority優先権は'2147483647'/>Sと等しいです: </オプション>S: IDXP</挨拶>S: 終わりC: 間違え、1 17 .45168C: コンテントタイプ: テキスト/xml C: C: <エラーコード='504'>'channelPriority'オプションは認識されていない</誤り>Cでした'。 終わり
4.2. The streamType Option
4.2. streamTypeオプション
Section 8.4 contains the IDXP option registration for the "streamType" option. This option contains a "streamType" element (see Section 9.3).
セクション8.4は"streamType"オプションのためのIDXPオプション登録を含みます。 このオプションは"streamType"要素を含んでいます(セクション9.3を見てください)。
By default, IDXP provides no explicit method for categorizing channels. The "streamType" option provides a way for peers to request that a channel be categorized as a particular stream type. When sending an "IDXP-Greeting" element during the provisioning of an IDXP channel, the originating peer MAY request that the remote peer assign a stream type to the channel by including an "Option" element containing a "streamType" element.
デフォルトで、IDXPはチャンネルを分類するためのイクスプリシット法を全く提供しません。 "streamType"オプションは同輩が、チャンネルが特定のストリーム型として分類されるよう要求する方法を提供します。 IDXPチャンネルの食糧を供給する間「IDXP-挨拶」要素を送るとき、起因している同輩は、リモート同輩が"streamType"要素を含む「オプション」要素を含んでいることによってチャンネルにストリーム型を選任するよう要求するかもしれません。
The "streamType" element has one attribute named "type", with the possible values of "alert", "heartbeat", or "config". This attribute is REQUIRED. A value of "alert" indicates that the channel should be categorized as being used for the exchange of ID alerts. A value of "heartbeat" indicates that the channel should be categorized as being used for the exchange of heartbeat messages such as the "Heartbeat" element (see Section 4 of [2]). A value of "config" indicates that the channel should be categorized as being used for the exchange of configuration messages.
"streamType"要素には、「タイプ」という1つの属性が「警戒」、「鼓動」、または「コンフィグ」の可能な値と共にあります。 この属性はREQUIREDです。 「警戒」の値は、チャンネルがID警戒の交換に使用されるとして分類されるべきであるのを示します。 「鼓動」の値は、チャンネルが「鼓動」要素などの鼓動メッセージの交換に使用されるとして分類されるべきであるのを示します。([2])のセクション4を見てください。 「コンフィグ」の値は、チャンネルが構成メッセージの交換に使用されるとして分類されるべきであるのを示します。
Feinstein & Matthews Experimental [Page 14] RFC 4767 IDXP March 2007
2007年の[14ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, an analyzer successfully requests that a manager assign a stream type to the channel:
例えば、チャンネルの食糧を供給する間の「IDXP-挨拶」要素の交換の間、分析器は、マネージャがチャンネルにストリーム型を選任するよう首尾よく要求します:
analyzer manager
--------------- greeting w/ option ----------------->
<---------------------- <ok> ------------------------
分析器のマネージャ--------------- オプションによる挨拶-----------------><。---------------------- <の間違いない>。------------------------
C: MSG 1 21 . 1963 155 C: Content-Type: text/xml C: C: <IDXP-Greeting uri='http://example.com/alice' role='client'> C: <Option internal='streamType'> C: <streamType type='alert' /> C: </Option> C: </IDXP-Greeting> C: END S: RPY 1 21 . 1117 7 S: Content-Type: text/xml S: S: <ok /> S: END
C: エムエスジー、1 21 .1963155C: コンテントタイプ: テキスト/xml C: C: <IDXP-挨拶uri=' http://example.com/alice の'の役割は'クライアント'>Cと等しいです'。 <オプション内部の='streamType'>C:、' <streamTypeは='警戒'/>Cをタイプします: </オプション>C: IDXP</挨拶>C: 終わりS: RPY、1 21 .1117 7秒間: コンテントタイプ: テキスト/xml S: S: <OK/>S: 終わり
For example, during the exchange of "IDXP-Greeting" elements during channel provisioning, a manager unsuccessfully requests that an analyzer assign a stream type to the channel:
例えば、チャンネルの食糧を供給する間の「IDXP-挨拶」要素の交換の間、マネージャは、分析器がチャンネルにストリーム型を選任するよう要求して失敗した:
analyzer manager
<---------------- greeting w/ option ----------------
--------------------- <error> ---------------------->
分析器のマネージャ<。---------------- オプションによる挨拶---------------- --------------------- <誤り>。---------------------->。
S: MSG 1 21 . 1969 176 S: Content-Type: text/xml S: S: <IDXP-Greeting uri='http://example.com/bob' role='server'> S: <Option internal='streamType' mustUnderstand='true'> S: <streamType type='config' /> S: </Option> S: </IDXP-Greeting> S: END C: ERR 1 21 . 1292 63 C: Content-Type: text/xml C: C: <error code='504'>'streamType' option was unrecognized</error> C: END
S: エムエスジー、1 21 .1969 176秒間: コンテントタイプ: テキスト/xml S: S: <IDXP-挨拶uri=' http://example.com/bob の'の役割は'サーバ'>Sと等しいです'。 <オプションインターナル='streamType'mustUnderstandは'本当'の>Sと等しいです'。 <streamTypeは='コンフィグ'/>Sをタイプします: </オプション>S: IDXP</挨拶>S: 終わりC: 間違え、1 21 .1292 63C: コンテントタイプ: テキスト/xml C: C: <エラーコード='504'>'streamType'オプションは認識されていない</誤り>Cでした'。 終わり
Feinstein & Matthews Experimental [Page 15] RFC 4767 IDXP March 2007
2007年の[15ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
5. Fulfillment of IDWG Communications Protocol Requirements
5. IDWG通信規約要件の遂行
The following lists each of the communications protocol requirements established in Section 5 of [5] and, for each requirement, describes the manner in which it is fulfilled. IDXP itself does not fulfill each of the communications protocol requirements, but instead relies on the underlying BEEP protocol and a variety of BEEP profiles.
各要件のために、それぞれコミュニケーションの以下のリストは、[5]のセクション5に確立された要件について議定書の中で述べて、それが実現している方法を説明します。 IDXP自身はそれぞれの通信規約要件を実現させませんが、代わりに基本的なBEEPプロトコルとさまざまなBEEPプロフィールを当てにします。
5.1. Reliable Message Transmission
5.1. 信頼できるメッセージ送信
"The [protocol] MUST support reliable transmission of messages." See Section 5.1 of [5].
「[プロトコル]はメッセージの信頼できる伝達をサポートしなければなりません。」 [5]のセクション5.1を見てください。
IDXP operates over BEEP, which operates only over reliable
connection-oriented transport protocols (e.g., TCP). In addition,
BEEP peers communicate using a simple request-response protocol,
which provides end-to-end reliability between peers.
IDXPはBEEPの上で作動します。BEEPは信頼できる接続指向のトランスポート・プロトコル(例えば、TCP)だけの上で作動します。 さらに、BEEP同輩は、簡単な要求応答プロトコル(同輩の間の終わりから終わりへの信頼性を提供する)を使用することで交信します。
5.2. Interaction with Firewalls
5.2. ファイアウォールとの相互作用
"The [protocol] MUST support transmission of messages between ID components across firewall boundaries without compromising security." See Section 5.2 of [5].
「セキュリティに感染しないで、[プロトコル]はファイアウォール限界の向こう側にIDコンポーネントの間のメッセージの伝達をサポートしなければなりません。」 [5]のセクション5.2を見てください。
The TUNNEL profile [3] MUST be offered as an option for creation
of application-layer tunnels to allow operation across firewalls.
The TUNNEL profile SHOULD be used to provide an application-layer
tunnel. The ability to authenticate hosts during the creation of
an application-layer tunnel MUST be provided by the mechanism
chosen to create such tunnels. A firewall may therefore be
configured to authenticate all hosts attempting to tunnel into the
protected network. If the TUNNEL profile is used, SASL (see
Section 4.1 of [4]) MUST be offered as a mechanism by which hosts
can be authenticated.
応用層トンネルの作成がファイアウォールの向こう側に操作を許すように、オプションとしてTUNNELプロフィール[3]を提供しなければなりません。 TUNNELはSHOULDの輪郭を描きます。使用されて、応用層トンネルを提供してください。 そのようなトンネルを作成するために選ばれて、メカニズムは応用層トンネルの作成の間にホストを認証する能力を提供しなければなりません。 したがって、ファイアウォールは、保護されたネットワークにトンネルを堀るのを試みるすべてのホストを認証するために構成されるかもしれません。 プロフィールはTUNNELであるなら使用されています、SASL。(ホストを認証できるメカニズムとして[4])のセクション4.1を提供しなければならないのを確実にしてください。
5.3. Mutual Authentication
5.3. 互いの認証
"The [protocol] MUST support mutual authentication of the analyzer and the manager to each other." See Section 5.3 of [5].
「[プロトコル]は分析器とマネージャの互いの認証を互いにサポートしなければなりません。」 [5]のセクション5.3を見てください。
IDXP supports mutual authentication of the peers through the use
of an appropriate underlying BEEP security profile. The TLS
profile and members of the SASL family of profiles (see Section
4.1 of [4]) are examples of security profiles that may be used to
authenticate the identity of communicating ID components. TLS
MUST be offered as a mechanism to provide mutual authentication,
and TLS SHOULD be used to provide mutual authentication.
IDXPは適切な基本的なBEEPセキュリティプロフィールの使用による同輩の互いの認証をサポートします。 プロフィールのSASLファミリーのTLSプロフィールとメンバー、([4])のセクション4.1が交信しているIDコンポーネントのアイデンティティを認証するのに使用されるかもしれないセキュリティプロフィールに関する例であることを確実にしてください。 互いの認証、およびTLS SHOULDを提供するメカニズムとして提供してください。TLS MUST、互いの認証を提供するために、使用されます。
Feinstein & Matthews Experimental [Page 16] RFC 4767 IDXP March 2007
2007年の[16ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
5.4. Message Confidentiality
5.4. メッセージ秘密性
"The [protocol] MUST support confidentiality of the message content during message exchange. The selected design MUST be capable of supporting a variety of encryption algorithms and MUST be adaptable to a wide variety of environments." See Section 5.4 of [5].
「[プロトコル]は交換処理の間、メッセージ内容の秘密性をサポートしなければなりません。」 「選択されたデザインは、さまざまな暗号化がアルゴリズムであるとサポートすることができなければならなくて、さまざまな環境に融通がきくに違いありません。」 [5]のセクション5.4を見てください。
IDXP supports confidentiality through the use of an appropriate
underlying BEEP security profile. The TLS profile is an example
of a security profile that offers confidentiality. The TLS
profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite
MUST be offered as a mechanism to provide confidentiality, and TLS
with this cipher suite SHOULD be used to provide confidentiality.
The TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses ephemeral
Diffie-Hellman (DHE) with DSS signatures for key exchange and
triple DES (Data Encryption Standard) (3DES) and cipher-block
chaining (CBC) for encryption. Stronger cipher suites are
optional.
IDXPは適切な基本的なBEEPセキュリティプロフィールの使用で秘密性をサポートします。 TLSプロフィールは秘密性を提供するセキュリティプロフィールに関する例です。 秘密性を提供するのに使用されるこの暗号スイートSHOULDに秘密性、およびTLSを供給するためにメカニズムとしてTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートがあるTLSプロフィールを提供しなければなりません。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは主要な交換と三重のDES(データ暗号化規格)(3DES)のためのDSS署名と暗号化のための暗号ブロック連鎖(CBC)と共にはかないディフィー-ヘルマン(DHE)を使用します。 より堅固な暗号スイートは任意です。
5.5. Message Integrity
5.5. メッセージの保全
"The [protocol] MUST ensure the integrity of the message content. The selected design MUST be capable of supporting a variety of integrity mechanisms and MUST be adaptable to a wide variety of environments." See Section 5.5 of [5].
「[プロトコル]はメッセージ内容の保全を確実にしなければなりません。」 「選択されたデザインは、さまざまな保全がメカニズムであるとサポートすることができなければならなくて、さまざまな環境に融通がきくに違いありません。」 [5]のセクション5.5を見てください。
IDXP supports message integrity through the use of an appropriate
underlying BEEP security profile. The TLS profile and members of
the SASL family of profiles (see Section 4.1 of [4]) are examples
of security profiles that offer message integrity. The TLS
profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite
MUST be offered as a mechanism to provide integrity, and TLS with
this cipher suite SHOULD be used to provide integrity. The
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses the Secure
Hash Algorithm (SHA) for integrity protection using a keyed
message authentication code. Stronger cipher suites are optional.
IDXPは適切な基本的なBEEPセキュリティプロフィールの使用でメッセージの保全をサポートします。 プロフィールのSASLファミリーのTLSプロフィールとメンバー、([4])のセクション4.1がメッセージの保全を提供するセキュリティプロフィールに関する例であることを確実にしてください。 保全を提供するのに使用されるこの暗号スイートSHOULDに保全、およびTLSを供給するためにメカニズムとしてTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートがあるTLSプロフィールを提供しなければなりません。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは、保全保護に、合わせられたメッセージ確認コードを使用することでSecure Hash Algorithm(SHA)を使用します。 より堅固な暗号スイートは任意です。
5.6. Per-Source Authentication
5.6. 1ソースあたりの認証
"The [protocol] MUST support separate authentication keys for each sender." See Section 5.6 of [5].
「[プロトコル]は、各送付者のために別々の認証がキーであるとサポートしなければなりません。」 [5]のセクション5.6を見てください。
IDXP supports separate authentication keys for each sender (i.e.,
per-source authentication) through the use of an appropriate
underlying BEEP security profile. The TLS profile is an example
of a security profile that supports per-source authentication
through the mutual authentication of public-key certificates. TLS
MUST be offered as a mechanism to provide per-source
IDXPは、各送付者(すなわち、ソース認証あたりの)のために別々の認証がキーであると適切な基本的なBEEPセキュリティプロフィールの使用でサポートします。 TLSプロフィールは公開鍵証明書の互いの認証による1ソースあたりの認証をサポートするセキュリティプロフィールに関する例です。 TLS MUST、メカニズムとして提供して、ソースを提供してください。
Feinstein & Matthews Experimental [Page 17] RFC 4767 IDXP March 2007
2007年の[17ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
authentication, and TLS SHOULD be used to provide per-source
authentication.
認証、およびTLS SHOULD、使用されて、認証をソースに提供してください。
5.7. Denial of Service
5.7. サービス妨害
"The [protocol] SHOULD resist protocol denial-of-service attacks." See Section 5.7 of [5].
「[プロトコル]SHOULDはプロトコルサービス不能攻撃に抵抗します。」 [5]のセクション5.7を見てください。
IDXP supports resistance to denial of service (DoS) attacks
through the use of an appropriate underlying BEEP security
profile. BEEP peers offering the IDXP profile MUST offer the use
of TLS with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite,
and SHOULD use TLS with that cipher suite. To resist DoS attacks
it is helpful to discard traffic arising from a non-authenticated
source. BEEP peers MUST support the use of authentication in
conjunction with any mechanism used to create application-layer
tunnels. In particular, the use of some form of SASL
authentication (see Section 4.1 of [4]) MUST be offered to provide
authentication in the use of the TUNNEL profile. See Section 7 of
[3] for a discussion of security considerations in the use of the
TUNNEL profile.
IDXPは適切な基本的なBEEPセキュリティプロフィールの使用によるサービス(DoS)攻撃の否定への抵抗をサポートします。 IDXPプロフィールを提供するBEEP同輩はTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートによるTLSの使用を提供しなければなりません、そして、SHOULDはその暗号スイートがあるTLSを使用します。 DoS攻撃に抵抗するために、非認証されたソースから起こるトラフィックを捨てるのは役立っています。 BEEP同輩は応用層トンネルを作成するのに使用されるどんなメカニズムに関連して認証の使用をサポートしなければなりません。 特に、いくつかの使用はSASL認証を形成します。(TUNNELプロフィールの使用における認証を提供するために[4])のセクション4.1を提供しなければならないのを確実にしてください。 TUNNELプロフィールの使用における、セキュリティ問題の議論のための[3]のセクション7を見てください。
5.8. Message Duplication
5.8. メッセージ複製
"The [protocol] SHOULD resist malicious duplication of messages." See Section 5.8 of [5].
「[プロトコル]SHOULDはメッセージの悪意がある複製に抵抗します。」 [5]のセクション5.8を見てください。
IDXP supports resistance to malicious duplication of messages
(i.e., replay attacks) through the use of an appropriate
underlying BEEP security profile. The TLS profile is an example
of a security profile offering resistance to replay attacks. The
TLS profile with the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher
suite MUST be offered as a mechanism to provide resistance against
replay attacks, and TLS with this cipher suite SHOULD be used to
provide resistance against replay attacks. The
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite uses cipher-block
chaining (CBC) to ensure that even if a message is duplicated the
cipher-text duplicate will produce a very different plain-text
result. Stronger cipher suites are optional.
IDXPは適切な基本的なBEEPセキュリティプロフィールの使用によるメッセージ(すなわち、反射攻撃)の悪意がある複製への抵抗をサポートします。 TLSプロフィールは反射攻撃への抵抗を示すセキュリティプロフィールに関する例です。 反射攻撃に対して抵抗を提供して、この暗号スイートSHOULDが反射攻撃に対する抵抗を提供するのに使用されている状態でTLSを提供するためにメカニズムとしてTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートがあるTLSプロフィールを提供しなければなりません。 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは、メッセージがコピーされても暗号文写しが非常に異なったプレーンテキスト結果を生むのを保証するのに、暗号ブロック連鎖(CBC)を使用します。 より堅固な暗号スイートは任意です。
6. Extending IDXP
6. IDXPを広げています。
The specification of IDXP options (see Section 4) is the preferred method of extending IDXP. In order to extend IDXP, an IDXP option SHOULD be documented in an RFC and MUST be registered with the IANA (see Section 7). IDXP extensions that cannot be expressed as IDXP options MUST be documented in an RFC.
IDXPオプション(セクション4を見る)の仕様はIDXPを広げる適した方法です。 IDXPを広げるために、IDXPオプションSHOULDをRFCに記録されて、IANAに登録しなければなりません(セクション7を見てください)。 IDXPオプションとして言い表すことができないIDXP拡張子をRFCに記録しなければなりません。
Feinstein & Matthews Experimental [Page 18] RFC 4767 IDXP March 2007
2007年の[18ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
7. IDXP Option Registration Template
7. IDXPオプション登録テンプレート
When an IDXP option is registered, the following information is supplied:
IDXPオプションが登録しているとき、以下の情報を提供します:
Option Identification: specify the NMTOKEN or the URI that authoritatively identifies this option.
オプション識別: 厳然とこのオプションを特定するNMTOKENかURIを指定してください。
Contains: specify the XML content that is contained within the "Option" element.
含んでいます: 「オプション」要素の中に含まれているXML内容を指定してください。
Processing Rules: specify the processing rules associated with the option.
処理は統治されます: オプションに関連している処理規則を指定してください。
Contact Information: specify the postal and electronic contact information for the author(s) of the option.
問い合わせ先: 郵便の、そして、電子の問い合わせ先をオプションの作者に指定してください。
8. Initial Registrations
8. 初期の登録証明書
8.1. Registration: The IDXP Profile
8.1. 登録: IDXPプロフィール
Profile identification: http://idxp.org/beep/profile
識別の輪郭を描いてください: http://idxp.org/beep/profile
Messages exchanged during channel creation: "IDXP-Greeting"
メッセージはチャンネル作成の間、交換しました: 「IDXP-挨拶」
Messages starting one-to-one exchanges: "IDXP-Greeting", "IDMEF- Message"
始めが1〜1に以下を交換するというメッセージ 「IDXP-挨拶」、「IDMEFメッセージ」
Messages in positive replies: "ok"
積極的な返事におけるメッセージ: 「OK」
Messages in negative replies: "error"
否定的な返事におけるメッセージ: 「誤り」
Messages in one-to-many exchanges: none
多くへの1回の交換におけるメッセージ: なし
Message syntax: see Section 3.3
メッセージ構文: セクション3.3を見てください。
Message semantics: see Section 3.4
メッセージ意味論: セクション3.4を見てください。
Contact information: see the "Authors' Addresses" section of this memo
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
8.2. Registration: The System (Well-Known) TCP Port Number for IDXP
8.2. 登録: IDXPのためのシステムの(よく知られる)のTCPポートナンバー
Protocol Number: 603
数について議定書の中で述べてください: 603
Message Formats, Types, Opcodes, and Sequences: see Section 3.3
メッセージ・フォーマット、タイプ、Opcodes、および系列: セクション3.3を見てください。
Functions: see Section 3.4
機能: セクション3.4を見てください。
Feinstein & Matthews Experimental [Page 19] RFC 4767 IDXP March 2007
2007年の[19ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
Use of Broadcast/Multicast: none
放送/マルチキャストの使用: なし
Proposed Name: Intrusion Detection Exchange Protocol
提案された名前: 侵入検出交換プロトコル
Short name: idxp
省略名: idxp
Contact Information: see the "Authors' Addresses" section of this memo
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
8.3. Registration: The channelPriority Option
8.3. 登録: channelPriorityオプション
Option Identification: channelPriority
オプション識別: channelPriority
Contains: channelPriority (see Section 9.2)
含んでいます: channelPriority(セクション9.2を見ます)
Processing Rules: see Section 4.1
処理は統治されます: セクション4.1を見てください。
Contact Information: see the "Authors' Addresses" section of this memo
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
8.4. Registration: The streamType Option
8.4. 登録: streamTypeオプション
Option Identification: streamType
オプション識別: streamType
Contains: streamType (see Section 9.3)
含んでいます: streamType(セクション9.3を見ます)
Processing Rules: see Section 4.2
処理は統治されます: セクション4.2を見てください。
Contact Information: see the "Authors' Addresses" section of this memo
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
9. The DTDs
9. DTD
9.1. The IDXP DTD
9.1. IDXP DTD
The following is the DTD defining the valid elements for the IDXP profile.
↓これはIDXPプロフィールのために有効な要素を定義するDTDです。
<!--
DTD for the IDXP Profile
<!--IDXPプロフィールのためのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % IDXP PUBLIC "-//IETF//DTD RFC 4767 IDXP v1.0//EN">
<!実体%IDXP公共である、「-//IETF//DTD RFC4767IDXP v1.0//アン">"
%IDXP;
-->
%IDXP。 -->。
Feinstein & Matthews Experimental [Page 20] RFC 4767 IDXP March 2007
2007年の[20ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
<!-- Includes -->
<!--インクルード-->。
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN">
<!実体%が公衆を鳴らす、「-//IETF//DTDビープ音//アン">"
%BEEP;
%は鳴ります。
<!ENTITY % IDMEF-Message PUBLIC
"-//IETF//DTD RFC 4765 IDMEF v1.0//EN">
<!実体%が公衆をIDMEF通信させる、「-//IETF//DTD RFC4765IDMEF v1.0//アン">"
%IDMEF;
%IDMEF。
<!--
Profile Summary
<!--プロフィール概要
BEEP profile http://idxp.org/beep/profile
BEEPプロフィール http://idxp.org/beep/profile
role MSG RPY ERR
==== === === ===
I or L IDXP-Greeting ok error
C IDMEF-Message ok error
-->
役割のMSG RPY ERR==== === === === 私かL間違いない誤りC IDMEF-メッセージ間違いないIDXP-挨拶誤り-->。
<!--
Entity Definitions
<!--実体定義
entity syntax/reference example
====== ================ =======
an authoritative identification
URI see RFC 3986 [6] http://example.com
実体構文/参照の例====== ================ ======= 正式の識別URIはRFC3986[6] http://example.com を見ます。
a fully qualified domain name
FQDN see RFC 1034 [9] www.example.com
-->
a完全修飾ドメイン名FQDNはRFC1034[9]www.example.comを見ます--、>。
<!ENTITY % URI "CDATA">
<!ENTITY % FQDN "CDATA">
<!実体%ユリ、「CDATA「><!実体%FQDN」CDATA">"
<!--
The IDXP-Greeting element declares the role and identity of
the peer issuing it, on a per-channel basis. The
IDXP-Greeting element may contain one or more Option
sub-elements.
-->
<!--IDXP-挨拶要素は1チャンネルあたり1個のベースでそれを発行する同輩の役割とアイデンティティを宣言します。 IDXP-挨拶要素は1つ以上のOption下位要素を含むかもしれません。 -->。
Feinstein & Matthews Experimental [Page 21] RFC 4767 IDXP March 2007
2007年の[21ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
<!ELEMENT IDXP-Greeting (Option*)>
<!ATTLIST IDXP-Greeting
uri %URI; #REQUIRED
role (client|server) #REQUIRED
fqdn %FQDN; #IMPLIED>
<!ELEMENT IDXP-挨拶(オプション*)><!ATTLIST IDXP-挨拶uri%URI。 #REQUIREDの役割(クライアント| サーバ)の#REQUIRED fqdn%FQDN。 #暗示している>。
<!--
The Option element conveys an IDXP channel option.
Note that the %LOCS entity is imported from the BEEP Channel
Management DTD.
-->
<!--Option要素はIDXPチャンネルオプションを伝えます。 それに注意してください。実体がBEEP Channel Management DTDからインポートされる%LOCS。 -->。
<!ELEMENT Option (ANY)>
<!ATTLIST Option
internal NMTOKEN ""
external %URI; ""
mustUnderstand (true|false) "false"
localize %LOCS; "i-default">
<!ELEMENT Option(少しも)の>の<!のATTLIST Optionの内部のNMTOKEN、「「外部の%ユリ」 「「mustUnderstand、(本当に、| 偽) 「偽」は、%がLOCSであるとローカライズします;、」 「i-デフォルト">"
<!--
The IDMEF-Message element conveys the intrusion detection
information that is exchanged. This element is defined in the
idmef-message.dtd
-->
<!--IDMEF-メッセージ要素は交換される侵入検出情報を伝えます。 この要素はidmef-message.dtdで定義されます--、>。
<!-- End of DTD -->
<!--DTDの終わり-->。
9.2. The channelPriority Option DTD
9.2. channelPriorityオプションDTD
The following is the DTD defining the valid elements for the channelPriority option.
↓これはchannelPriorityオプションのために有効な要素を定義するDTDです。
<!--
DTD for the channelPriority IDXP option, as of 2002-01-08
<!--2002年1月8日付けでchannelPriority IDXPオプションのためのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % IDXP-channelPriority PUBLIC
"-//IETF//DTD RFC 4767 IDXP-channelPriority v1.0//EN">
<!実体%IDXP-channelPriority公共である、「-//IETF//DTD RFC4767IDXP-channelPriority v1.0//アン">"
%IDXP-channelPriority;
-->
%IDXP-channelPriority。 -->。
<!--
Entity Definitions
<!--実体定義
entity syntax/reference example
====== ================ =======
実体構文/参照の例====== ================ =======
Feinstein & Matthews Experimental [Page 22] RFC 4767 IDXP March 2007
2007年の[22ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
a priority number
PRIORITY 0..2147483647 1
-->
優先No.PRIORITY0。2147483647 1-->。
<!ENTITY % PRIORITY "CDATA">
<!実体%優先権、「CDATA">"
<!ELEMENT channelPriority EMPTY>
<!ATTLIST channelPriority
priority %PRIORITY #REQUIRED>
<!ELEMENT channelPriority EMPTY><!ATTLIST channelPriority優先権%PRIORITY#REQUIRED>。
<!-- End of DTD -->
<!--DTDの終わり-->。
9.3. The streamType DTD
9.3. streamType DTD
The following is the DTD defining the valid elements for the streamType option.
↓これはstreamTypeオプションのために有効な要素を定義するDTDです。
<!--
DTD for the streamType IDXP option, as of 2002-01-08
<!--2002年1月8日付けでstreamType IDXPオプションのためのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % IDXP-streamType PUBLIC
"-//IETF//DTD RFC 4767 IDXP-streamType v1.0//EN">
<!実体%IDXP-streamType公共である、「-//IETF//DTD RFC4767IDXP-streamType v1.0//アン">"
%IDXP-streamType;
-->
%IDXP-streamType。 -->。
<!--
Entity Definitions
<!--実体定義
entity syntax/reference example
====== ================ =======
a stream type
STYPE (alert | heartbeat | config) "alert"
-->
実体構文/参照の例====== ================ ======= ストリーム型STYPE(警戒|鼓動|コンフィグ)「警戒」-->。
<!ENTITY % STYPE (alert|heartbeat|config)>
<!実体%STYPE(警戒|鼓動|コンフィグ)>。
<!ELEMENT streamType EMPTY>
<!ATTLIST streamType
type %STYPE #REQUIRED>
<!ELEMENT streamType EMPTY><!ATTLIST streamTypeは%STYPE#REQUIRED>をタイプします。
<!-- End of DTD -->
<!--DTDの終わり-->。
Feinstein & Matthews Experimental [Page 23] RFC 4767 IDXP March 2007
2007年の[23ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
10. Reply Codes
10. 回答コード
This section lists the three-digit error codes the IDXP profile may generate.
このセクションはIDXPプロフィールが生成するかもしれない3ケタのエラーコードを記載します。
code meaning
==== =======
421 Service not available
(e.g., the peer does not have sufficient resources)
コード意味==== ======= 利用可能でない421サービス(例えば、同輩には、十分なリソースがありません)
450 Requested action not taken
(e.g., DNS lookup failed or connection could not
be established. See also 550.)
450 取られなかった要求された行動(例えばDNSルックアップは失敗できませんでしたか、接続を確立できませんでした。 また、550を見てください。)
454 Temporary authentication failure
454 一時的な認証失敗
500 General syntax error
(e.g., poorly-formed XML)
500の一般構文エラー(例えば、不十分に形成されたXML)
501 Syntax error in parameters
(e.g., non-valid XML)
パラメタの501構文エラー(例えば、有効な非XML)
504 Parameter not implemented
実装されなかった504パラメタ
530 Authentication required
530 認証が必要です。
534 Authentication mechanism insufficient
(e.g., cipher suite too weak, sequence exhausted)
534認証機構不十分です。(例えば、弱過ぎて、系列疲れ果てた状態でスイートを解きます)
535 Authentication failure
535 認証失敗
537 Action not authorized for user
537 ユーザのために認可されなかった動作
550 Requested action not taken
(e.g., peer could be contacted, but
malformed greeting or no IDXP profile advertised)
550 取られなかった要求された行動(例えば同輩に連絡できましたが、奇形の挨拶の広告を出しましたが、どんなIDXPプロフィールも広告を出しませんでした)
553 Parameter invalid
553パラメタ病人
554 Transaction failed
(e.g., policy violation)
554トランザクションは失敗しました。(例えば、方針違反)
Feinstein & Matthews Experimental [Page 24] RFC 4767 IDXP March 2007
2007年の[24ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
11. Security Considerations
11. セキュリティ問題
The IDXP profile is a profile of BEEP. In BEEP, transport security, user authentication, and data exchange are orthogonal. Refer to Section 9 of [4] for a discussion of this. It is strongly recommended that those wanting to use the IDXP profile initially negotiate a BEEP security profile between the peers that offers the required security properties. The TLS profile SHOULD be used to provide for transport security. See Section 5 for a discussion of how IDXP fulfills the IDWG communications protocol requirements.
IDXPプロフィールはBEEPのプロフィールです。 BEEPでは、輸送セキュリティ、ユーザー認証、およびデータ交換は直交しています。 この議論のための[4]のセクション9を参照してください。 初めはIDXPプロフィールを使用したがっている人が同輩の間の必要なセキュリティ資産を提供するBEEPセキュリティプロフィールを交渉することが強く勧められます。 TLSはSHOULDの輪郭を描きます。使用されて、輸送セキュリティに備えてください。 IDXPがIDWG通信規約要件をどう実現させるかに関する議論に関してセクション5を見てください。
See Section 2.4 for a discussion of the trust model.
信頼モデルの議論に関してセクション2.4を見てください。
11.1. Use of the TUNNEL Profile
11.1. トンネルプロフィールの使用
See Section 5 for IDXP's requirements on application-layer tunneling and the TUNNEL profile specifically. See Section 7 of [3] for a discussion of the security considerations inherent in the use of the TUNNEL profile.
応用層トンネリングとTUNNELプロフィールに関するIDXPの要件に関して明確にセクション5を見てください。 セキュリティ問題の議論のための[3]のセクション7がTUNNELプロフィールの使用に固有であることを見てください。
11.2. Use of Underlying Security Profiles
11.2. 基本的なセキュリティプロフィールの使用
At present, the TLS profile is the only BEEP security profile known to meet all of the requirements set forth in Section 5 of [5]. When securing a BEEP session with the TLS profile, the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite offers an acceptable level of security. See Section 5 for a discussion of how IDXP fulfills the IDWG communications requirements through the use of an underlying security profile.
現在のところ、TLSプロフィールは[5]のセクション5に詳しく説明された要件のすべてに会うのが知られている唯一のBEEPセキュリティプロフィールです。 TLSプロフィールとのBEEPセッションを保証するとき、TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは合格水準のセキュリティを提供します。 IDXPが基本的なセキュリティプロフィールの使用でIDWGコミュニケーション要件をどう実現させるかに関する議論に関してセクション5を見てください。
12. IANA Considerations
12. IANA問題
The IANA registered "idxp" as a TCP port number as specified in Section 8.2.
IANAはセクション8.2における指定されるとしてのTCPポートナンバーとして"idxp"を登録しました。
The IANA maintains a list of:
IANAは以下のリストを維持します。
IDXP options, see Section 7.
IDXPオプション、セクション7を見てください。
For this list, the IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. As a courtesy to developers of non-standards track IDXP options, the mailing list idxp-discuss@lists.idxp.org may be used to solicit commentary.
このリストにおいて、IESGは課題をしながらIANAの前で仕様を再検討するために指定された専門家を選任するのに責任があります。 非標準化過程IDXPオプションの開発者への礼儀として、メーリングリスト idxp-discuss@lists.idxp.org は、論評に請求するのに使用されるかもしれません。
IANA made the registrations specified in Sections 8.3 and 8.4.
IANAはセクション8.3と8.4で指定された登録証明書をしました。
Feinstein & Matthews Experimental [Page 25] RFC 4767 IDXP March 2007
2007年の[25ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Debar, H., Curry, D., and B. Feinstein, "The Intrusion Detection
Message Exchange Format (IDMEF)", RFC 4765, March 2007.
[2] 締め出してください、そして、H.、カレー、D.、およびB.ファインスティン、「侵入検出交換処理形式(IDMEF)」RFC4765は2007を行進させます。
[3] New, D., "The TUNNEL Profile", RFC 3620, October 2003.
[3] 2003年10月、新しいD.、「トンネルプロフィール」RFC3620。
[4] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[4] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[5] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange
Requirements", RFC 4766, March 2007.
[5] 木とM.とM.Erlinger、「侵入検出交換処理要件」、RFC4766、2007年3月。
13.2. Informative References
13.2. 有益な参照
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[6]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[7] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, <http://www.w3.org/TR/REC-xml>.
[7]ロバの鳴き声、T.、パオリ、J.、Sperberg-マックィーン、C.、およびE.Maler、「拡張マークアップ言語(XML)1.0(2番目の教育)」、W3C REC-xml、2000年10月、<http://www.w3.org/TR/REC-xml>。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[8]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[9] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[9]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
14. Acknowledgements
14. 承認
The authors gratefully acknowledge the contributions of Darren New, Marshall T. Rose, Roy Pollock, Tim Buchheim, Mike Erlinger, John C. C. White, and Paul Osterwald.
作者は感謝してダーレンNew、マーシャル・T.ローズ、ロイ・ポロック、ティムBuchheim、マイクErlinger、ジョン・C.C.ホワイト、およびポールOsterwaldの貢献を承諾します。
Feinstein & Matthews Experimental [Page 26] RFC 4767 IDXP March 2007
2007年の[26ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
Authors' Addresses
作者のアドレス
Benjamin S. Feinstein SecureWorks, Inc. PO Box 95007 Atlanta, GA 30347 US
ベンジャミンS.ファインスティンSecureWorks Inc.PO Box95007GA30347アトランタ(米国)
Phone: +1 404 327-6339 Email: bfeinstein@acm.org URI: http://www.secureworks.com/
以下に電話をしてください。 +1 404 327-6339 メールしてください: bfeinstein@acm.org ユリ: http://www.secureworks.com/
Gregory A. Matthews CSC/NASA Ames Research Center
グレゴリーA.マシューズCSC/米航空宇宙局エイムズ研究所
EMail: gmatthew@nas.nasa.gov URI: http://www.nas.nasa.gov/
メール: gmatthew@nas.nasa.gov ユリ: http://www.nas.nasa.gov/
Feinstein & Matthews Experimental [Page 27] RFC 4767 IDXP March 2007
2007年の[27ページ]RFC4767IDXP行進のときに実験的なファインスティンとマシューズ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Feinstein & Matthews Experimental [Page 28]
ファインスティンとマシューズExperimentalです。[28ページ]
一覧
スポンサーリンク
