RFC1910 日本語訳
1910 User-based Security Model for SNMPv2. G. Waters, Ed.. February 1996. (Format: TXT=98252 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Waters, Editor Request for Comments: 1910 Bell-Northern Research Ltd. Category: Experimental February 1996
ワーキンググループG.水域、コメントを求めるエディタ要求をネットワークでつないでください: 1910年のベル-北研究株式会社カテゴリ: 実験的な1996年2月
User-based Security Model for SNMPv2
SNMPv2のユーザベースの機密保護モデル
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ................................................ 2 1.1 Threats .................................................... 3 1.2 Goals and Constraints ...................................... 4 1.3 Security Services .......................................... 5 1.4 Mechanisms ................................................. 5 1.4.1 Digest Authentication Protocol ........................... 7 1.4.2 Symmetric Encryption Protocol ............................ 8 2. Elements of the Model ....................................... 10 2.1 SNMPv2 Users ............................................... 10 2.2 Contexts and Context Selectors ............................. 11 2.3 Quality of Service (qoS) ................................... 13 2.4 Access Policy .............................................. 13 2.5 Replay Protection .......................................... 13 2.5.1 agentID .................................................. 14 2.5.2 agentBoots and agentTime ................................. 14 2.5.3 Time Window .............................................. 15 2.6 Error Reporting ............................................ 15 2.7 Time Synchronization ....................................... 16 2.8 Proxy Error Propagation .................................... 16 2.9 SNMPv2 Messages Using this Model ........................... 16 2.10 Local Configuration Datastore (LCD) ....................... 18 3. Elements of Procedure ....................................... 19 3.1 Generating a Request or Notification ....................... 19 3.2 Processing a Received Communication ........................ 20 3.2.1 Additional Details ....................................... 28 3.2.1.1 ASN.1 Parsing Errors ................................... 28 3.2.1.2 Incorrectly Encoded Parameters ......................... 29 3.2.1.3 Generation of a Report PDU ............................. 29 3.2.1.4 Cache Timeout .......................................... 29 3.3 Generating a Response ...................................... 30 4. Discovery ................................................... 30 5. Definitions ................................................. 31
1. 序論… 2 1.1の脅威… 3 1.2の目標と規制… 4 1.3 セキュリティサービス… 5 1.4のメカニズム… 5 1.4 .1 認証プロトコルを読みこなしてください… 7 1.4 .2 左右対称の暗号化プロトコル… 8 2. モデルのElements… 10 2.1 SNMPv2ユーザ… 10 2.2の文脈と文脈セレクタ… 11 2.3 サービスの質(qoS)… 13 2.4 方針にアクセスしてください… 13 2.5 保護を再演してください… 13 2.5 .1agentID… 14 2.5 .2のagentBootsとagentTime… 14 2.5 .3時間ウィンドウ… 15 2.6 誤り報告… 15 2.7時間同期化… 16 2.8 プロキシ誤り伝播… 16 2.9 SNMPv2 Messages Using、このModel… 16 2.10 地方の構成Datastore(LCD)… 18 3. 手順のElements… 19 3.1 要求か通知を生成します… 19 3.2 受信されたコミュニケーションを処理します… 20 3.2 .1 追加詳細… 28 3.2 .1 .1 ASN.1構文解析誤り… 28 3.2 .1 .2は不当にパラメタをコード化しました… 29 3.2 .1 レポートPDUの.3世代… 29 3.2 .1 .4 タイムアウトをキャッシュしてください… 29 3.3 応答を生成します… 30 4. 発見… 30 5. 定義… 31
Waters Experimental [Page 1] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[1ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
4.1 The USEC Basic Group ....................................... 32 4.2 Conformance Information .................................... 35 4.2.1 Compliance Statements .................................... 35 4.2.2 Units of Conformance ..................................... 35 6. Security Considerations ..................................... 36 6.1 Recommended Practices ...................................... 36 6.2 Defining Users ............................................. 37 6.3 Conformance ................................................ 38 7. Editor's Address ............................................ 38 8. Acknowledgements ............................................ 39 9. References .................................................. 39 Appendix A Installation ........................................ 41 Appendix A.1 Agent Installation Parameters ..................... 41 Appendix A.2 Password to Key Algorithm ......................... 43 Appendix A.3 Password to Key Sample ............................ 44
4.1 USECの基本的なグループ… 32 4.2 順応情報… 35 4.2 .1 承諾声明… 35 4.2 .2回の順応… 35 6. セキュリティ問題… 36 6.1 お勧めの習慣… 36 6.2 ユーザを定義します… 37 6.3順応… 38 7. エディタのアドレス… 38 8. 承認… 39 9. 参照… 39 付録Aインストール… 41 付録A.1エージェントインストールパラメタ… 主要なアルゴリズムへの41付録A.2パスワード… 主要なサンプルへの43付録A.3パスワード… 44
1. Introduction
1. 序論
A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies.
マネージメントシステムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証、承認、アクセスコントロール、およびプライバシーに関する方針を定義する管理フレームワークの下で行われます。
Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.
管理局は管理された要素をモニターして、制御する管理アプリケーションを作成します。 管理された要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。
The Administrative Infrastructure for SNMPv2 document [1] defines an administrative framework which realizes effective management in a variety of configurations and environments.
SNMPv2ドキュメント[1]のためのAdministrative Infrastructureはさまざまな構成と環境で効果的な管理がわかる管理フレームワークを定義します。
In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User- based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework.
この管理フレームワークでは、機密保護モデルはプロトコル相互作用のために行政上定義されたレベルのセキュリティを達成するのに使用されるメカニズムを定義します。 多くのそのような機密保護モデルが定義されるかもしれませんが、それはこのドキュメントの目的です、そして、Userは1番目を定義するためにSNMPv2のためのSecurity Modelを基礎づけました、そして、この書くこと現在、セキュリティはこの管理フレームワークのためにモデル化されるだけです。
This administrative framework includes the provision of an access control model. The enforcement of access rights requires the means to identify the entity on whose behalf a request is generated. This SNMPv2 security model identifies an entity on whose behalf an SNMPv2 message is generated as a "user".
この管理フレームワークはアクセス制御モデルに関する条項を含んでいます。 アクセス権の実施は要求がに代わって発生している実体を特定する手段を必要とします。 SNMPv2メッセージが「ユーザ」としてだれの代理に生成されるかに関してこのSNMPv2機密保護モデルは実体を特定します。
Waters Experimental [Page 2] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[2ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
1.1. Threats
1.1. 脅威
Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any SNMPv2 security model. Other threats are not applicable to the network management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance.
ネットワーク・プロトコルへのいくつかの古典的な脅威が、ネットワーク管理問題に適切であり、したがって、どんなSNMPv2機密保護モデルにも適切でしょう。 他の脅威はネットワーク管理問題に適切ではありません。 このセクションは、より少なく重要な主要な脅威、セカンダリ脅威、および脅威について論じます。
The principal threats against which this SNMPv2 security model should provide protection are:
このSNMPv2機密保護モデルが保護を提供するべきである主要な脅威は以下の通りです。
Modification of Information
The modification threat is the danger that some unauthorized entity
may alter in-transit SNMPv2 messages generated on behalf of an
authorized user in such a way as to effect unauthorized management
operations, including falsifying the value of an object.
変更、情報では、変更の脅威は何らかの権限のない実体がトランジットにおけるそのような方法で認定ユーザを代表して権限のない管理操作に作用するほど生成されたSNMPv2メッセージを変更するかもしれないという危険です、オブジェクトの値を改竄するのを含んでいて。
Masquerade
The masquerade threat is the danger that management operations not
authorized for some user may be attempted by assuming the identity
of another user that has the appropriate authorizations.
仮装してください。仮面舞踏会の脅威はユーザのために認可されなかった管理操作が適切な承認を持っている別のユーザのアイデンティティを仮定することによって試みられるかもしれないという危険です。
Two secondary threats are also identified. The security protocols defined in this memo do provide protection against:
また、2つのセカンダリ脅威が特定されます。 このメモで定義されたセキュリティプロトコルは以下に対して保護を提供します。
Message Stream Modification
The SNMPv2 protocol is typically based upon a connectionless
transport service which may operate over any subnetwork service.
The re-ordering, delay or replay of messages can and does occur
through the natural operation of many such subnetwork services.
The message stream modification threat is the danger that messages
may be maliciously re-ordered, delayed or replayed to an extent
which is greater than can occur through the natural operation of a
subnetwork service, in order to effect unauthorized management
operations.
SNMPv2が議定書の中で述べるメッセージStream Modificationはどんなサブネットワークサービスの上でも作動するかもしれないコネクションレスな輸送サービスに通常基づいています。 メッセージの再注文、遅れまたは再生が、起こって、そのような多くのサブネットワークサービスの自然な操作で起こることができます。 メッセージストリーム変更の脅威はメッセージが自然なサブネットワークサービスの操作で起こることができるより大きい程度まで陰湿に再命令されるか、遅らせられるか、または再演されるかもしれないという危険です、権限のない管理操作に作用するように。
Disclosure
The disclosure threat is the danger of eavesdropping on the
exchanges between managed agents and a management station.
Protecting against this threat may be required as a matter of local
policy.
公開、公開の脅威は管理されたエージェントと管理局の間の交換を立ち聞きするという危険です。 この脅威から守るのがローカルの方針の問題として必要であるかもしれません。
There are at least two threats that an SNMPv2 security protocol need not protect against. The security protocols defined in this memo do not provide protection against:
SNMPv2セキュリティプロトコルが守る必要はない少なくとも2つの脅威があります。 このメモで定義されたセキュリティプロトコルは以下に対して保護を提供しません。
Waters Experimental [Page 3] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[3ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
Denial of Service
An SNMPv2 security protocol need not attempt to address the broad
range of attacks by which service on behalf of authorized users is
denied. Indeed, such denial-of-service attacks are in many cases
indistinguishable from the type of network failures with which any
viable network management protocol must cope as a matter of course.
サービス妨害An SNMPv2セキュリティプロトコルは、認定ユーザを代表したサービスが否定される攻撃の広い声域を扱うのを試みる必要はありません。 本当に、どんな実行可能なネットワーク管理プロトコルも当然のこととして対処されなければならないネットワーク失敗のタイプから区別できない多くの場合にはそのようなサービス不能攻撃があります。
Traffic Analysis
In addition, an SNMPv2 security protocol need not attempt to
address traffic analysis attacks. Indeed, many traffic patterns
are predictable - agents may be managed on a regular basis by a
relatively small number of management stations - and therefore
there is no significant advantage afforded by protecting against
traffic analysis.
トラフィックAnalysis In追加、SNMPv2セキュリティプロトコルは、トラヒック分析が攻撃であると扱うのを試みる必要はありません。 本当に、多くのトラフィック・パターンが予測できます、そして、(エージェントは定期的に比較的少ない数の管理局によって管理されるかもしれません)したがって、トラヒック分析から守ることによって提供されたどんな重要な利点もありません。
1.2. Goals and Constraints
1.2. 目標と規制
Based on the foregoing account of threats in the SNMP network management environment, the goals of this SNMPv2 security model are as follows.
SNMPネットワークマネージメント環境における脅威の以上の話に基づいて、このSNMPv2機密保護モデルの目標は以下の通りです。
(1) The protocol should provide for verification that each received
SNMPv2 message has not been modified during its transmission
through the network in such a way that an unauthorized management
operation might result.
(1) プロトコルは、それぞれの受信されたSNMPv2メッセージがネットワークを通したトランスミッションの間権限のない管理操作が結果として生じるかもしれないような方法で変更されていないのを検証に前提とするべきです。
(2) The protocol should provide for verification of the identity of the
user on whose behalf a received SNMPv2 message claims to have been
generated.
(2) プロトコルはだれの代理が生成されたかの受信されたSNMPv2メッセージが、主張するかにおけるユーザのアイデンティティの検証に備えるべきです。
(3) The protocol should provide for detection of received SNMPv2
messages, which request or contain management information, whose
time of generation was not recent.
(3) プロトコルは受信されたSNMPv2メッセージの検出に備えるべきです。(世代の時間が最近でなかった経営情報を要求するか、またはメッセージは含みます)。
(4) The protocol should provide, when necessary, that the contents of
each received SNMPv2 message are protected from disclosure.
(4) 必要であるときに、プロトコルは、それぞれの受信されたSNMPv2メッセージの内容が公開から保護されるのを前提とするべきです。
In addition to the principal goal of supporting secure network management, the design of this SNMPv2 security model is also influenced by the following constraints:
また、安全なネットワークが管理であるとサポートするという主な目的に加えて、以下の規制でこのSNMPv2機密保護モデルのデザインは影響を及ぼされます:
(1) When the requirements of effective management in times of network
stress are inconsistent with those of security, the design should
prefer the former.
(1) ネットワーク圧力の時代による効果的な管理の要件がセキュリティのものに矛盾しているとき、デザインは前者を好むべきです。
(2) Neither the security protocol nor its underlying security
mechanisms should depend upon the ready availability of other
network services (e.g., Network Time Protocol (NTP) or key
(2) セキュリティプロトコルもその基本的なセキュリティー対策を他のネットワーク・サービスの持ち合わせの有用性に依存するはずがない、(例えば、Network Timeプロトコル(NTP)かキー
Waters Experimental [Page 4] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[4ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
management protocols).
管理プロトコル)
(3) A security mechanism should entail no changes to the basic SNMP
network management philosophy.
(3) セキュリティー対策は基本的なSNMPネットワークマネージメント哲学への変化を全く伴うはずがありません。
1.3. Security Services
1.3. セキュリティー・サービス
The security services necessary to support the goals of an SNMPv2 security model are as follows.
SNMPv2機密保護モデルの目標をサポートするのに必要なセキュリティー・サービスは以下の通りです。
Data Integrity
is the provision of the property that data has not been altered or
destroyed in an unauthorized manner, nor have data sequences been
altered to an extent greater than can occur non-maliciously.
データの保全はデータが権限のない方法で変更されるか、または破壊されて、程度まで変更されたデータ系列を非陰湿に起こることができるよりすばらしくしないのをさせる特性の設備です。
Data Origin Authentication
is the provision of the property that the claimed identity of the
user on whose behalf received data was originated is corroborated.
データOrigin Authenticationは特性の設備です。だれの利益受信データが溯源されたかのユーザの要求されたアイデンティティは確証されます。
Data Confidentiality
is the provision of the property that information is not made
available or disclosed to unauthorized individuals, entities, or
processes.
権限のない個人、実体、またはプロセスに利用可能に作られているか、または明らかにされて、データConfidentialityは情報がない特性の設備です。
For the protocols specified in this memo, it is not possible to assure the specific originator of a received SNMPv2 message; rather, it is the user on whose behalf the message was originated that is authenticated.
このメモで指定されたプロトコルには、受信されたSNMPv2メッセージを特定の創始者に保証するのは可能ではありません。 むしろ、認証されるのは、メッセージがに代わって溯源されたユーザです。
For these protocols, it not possible to obtain data integrity without data origin authentication, nor is it possible to obtain data origin authentication without data integrity. Further, there is no provision for data confidentiality without both data integrity and data origin authentication.
これらのプロトコルのためにそれ、データ発生源認証なしでデータ保全を得るのにおいて可能でないことで、または、それはデータ保全なしでデータ発生源認証を得るのにおいて可能ではありません。 さらに、データの機密性への支給が全くデータ保全とデータ発生源認証の両方なしでありません。
The security protocols used in this memo are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises.
このメモで使用されるセキュリティプロトコルは書くこと時点で、許容できて安全であると考えられます。 しかしながら、必要性が起こるなら、手順は新しい認証と将来の時間に指定されるべきプライバシーメソッドを考慮します。
1.4. Mechanisms
1.4. メカニズム
The security protocols defined in this memo employ several types of mechanisms in order to realize the goals and security services described above:
セキュリティプロトコルは、以下の上で説明された目標とセキュリティー・サービスがわかるためにこのメモ雇用でいくつかのタイプのメカニズムを定義しました。
Waters Experimental [Page 5] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[5ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
- In support of data integrity, a message digest algorithm is
required. A digest is calculated over an appropriate portion of an
SNMPv2 message and included as part of the message sent to the
recipient.
- データ保全を支持して、メッセージダイジェストアルゴリズムが必要です。 メッセージの一部が受取人に発信したので、ダイジェストは、SNMPv2メッセージの適切な部分に関して計算されて、含まれています。
- In support of data origin authentication and data integrity, a
secret value is both inserted into, and appended to, the SNMPv2
message prior to computing the digest; the inserted value
overwritten prior to transmission, and the appended value is not
transmitted. The secret value is shared by all SNMPv2 entities
authorized to originate messages on behalf of the appropriate user.
- 発生源認証とデータ保全、秘密の値が挿入されて、追加されるデータを支持してSNMPv2が通信する、ダイジェストを計算する前に。 挿入は伝えられませんトランスミッションの前に上書きされた値、および追加が、評価する。 秘密の値は適切なユーザを代表してメッセージを溯源するのが認可されたすべてのSNMPv2実体によって共有されます。
- To protect against the threat of message delay or replay (to an
extent greater than can occur through normal operation), a set of
time (at the agent) indicators and a request-id are included in
each message generated. An SNMPv2 agent evaluates the time
indicators to determine if a received message is recent. An SNMPv2
manager evaluates the time indicators to ensure that a received
message is at least as recent as the last message it received from
the same source. An SNMPv2 manager uses received authentic
messages to advance its notion of time (at the agent). An SNMPv2
manager also evaluates the request-id in received Response messages
and discards messages which do not correspond to outstanding
requests.
- メッセージ遅延の脅威から守るか、または再演する(通常の操作で起こることができるより大きい程度まで)ために、1セットの時間(エージェントの)インディケータと要求イドは生成された各メッセージに含まれています。 SNMPv2エージェントは、受信されたメッセージが最近かどうか決定するために期間表示を評価します。 SNMPv2マネージャは、受信されたメッセージが確実にそれが同じソースから受け取った最後のメッセージと少なくとも同じくらい最近になるようにするために期間表示を評価します。 SNMPv2マネージャは時間(エージェントの)の概念を進める受信された正統のメッセージを使用します。 SNMPv2マネージャは、また、受信されたResponseメッセージの要求イドを評価して、傑出している要求と食い違っているメッセージを捨てます。
These mechanisms provide for the detection of messages whose time
of generation was not recent in all but one circumstance; this
circumstance is the delay or replay of a Report message (sent to a
manager) when the manager has has not recently communicated with
the source of the Report message. In this circumstance, the
detection guarantees only that the Report message is more recent
than the last communication between source and destination of the
Report message. However, Report messages do not request or contain
management information, and thus, goal #3 in Section 1.2 above is
met; further, Report messages can at most cause the manager to
advance its notion of time (at the agent) by less than the proper
amount.
これらのメカニズムは世代の時間が全部で最近でなかったメッセージにもかかわらず、1つの状況の検出に備えます。 マネージャが最近Reportメッセージの源とコミュニケートしていないとき、この状況は、Reportメッセージ(マネージャに発信する)の遅れか再生です。 この状況では、検出は、ReportメッセージがReportメッセージのソースと目的地との最後のコミュニケーションより最近であるだけであるのを保証します。 しかしながら、Reportメッセージは、経営情報を要求もしませんし、含んでもいません、そして、その結果、上のセクション1.2における目標#3は会われます。 さらに、Reportメッセージで、マネージャは適切な量以下で時間(エージェントの)の概念を高々進めることができます。
This protection against the threat of message delay or replay does
not imply nor provide any protection against unauthorized deletion
or suppression of messages. Other mechanisms defined independently
of the security protocol can also be used to detect the re-
ordering, replay, deletion, or suppression of messages containing
set operations (e.g., the MIB variable snmpSetSerialNo [15]).
メッセージ遅延か再生の脅威に対するこの保護は、メッセージの権限のない削除か秘匿に対する少しの保護も含意して、提供しません。 また、集合演算を含んでいて、メッセージの再注文、再生、削除、または秘匿を検出するのにセキュリティプロトコルの如何にかかわらず定義された他のメカニズムは使用できます。(例えば、MIBの可変snmpSetSerialNo[15])。
- In support of data confidentiality, an encryption algorithm is
required. An appropriate portion of the message is encrypted prior
to being transmitted.
- データの機密性を支持して、暗号化アルゴリズムが必要です。 メッセージの適切な部分は伝えられる前に、暗号化されます。
Waters Experimental [Page 6] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[6ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
1.4.1. Digest Authentication Protocol
1.4.1. ダイジェスト認証プロトコル
The Digest Authentication Protocol defined in this memo provides for:
このメモで定義されたDigest Authenticationプロトコルは以下に提供されます。
- verifying the integrity of a received message (i.e., the message
received is the message sent).
- 受信されたメッセージ(すなわち、受け取られたメッセージは送られたメッセージである)の保全について確かめます。
The integrity of the message is protected by computing a digest
over an appropriate portion of a message. The digest is computed
by the originator of the message, transmitted with the message, and
verified by the recipient of the message.
メッセージの保全は、メッセージの適切な部分に関してダイジェストを計算することによって、保護されます。 ダイジェストは、メッセージで送られたメッセージの創始者によって計算されて、メッセージの受取人によって確かめられます。
- verifying the user on whose behalf the message was generated.
- に代わってユーザについて確かめて、メッセージは生成されました。
A secret value known only to SNMPv2 entities authorized to generate
messages on behalf of this user is both inserted into, and appended
to, the message prior to the digest computation. Thus, the
verification of the user is implicit with the verification of the
digest. (Note that the use of two copies of the secret, one near
the start and one at the end, is recommended by [14].)
このユーザを代表してメッセージを生成するのが認可されたSNMPv2実体だけに知られている秘密の値がともに挿入される、追加する、ダイジェスト計算の前のメッセージ。 したがって、ユーザの検証はダイジェストの検証に暗黙です。 (秘密のコピー2部の使用(始めの近くの1と終わりの1)が[14]によって推薦されることに注意してください。)
- verifying that a message sent to/from one SNMPv2 entity cannot be
replayed to/as-if-from another SNMPv2 entity.
- メッセージが、あるSNMPv2実体からの/に発信したことを確かめるのを/に再演できない、別のSNMPv2実体。
Included in each message is an identifier unique to the SNMPv2
agent associated with the sender or intended recipient of the
message. Also, each message containing a Response PDU contains a
request-id which associates the message to a recently generated
request.
各メッセージに含まれているのは、メッセージの送付者か意図している受取人に関連づけられたSNMPv2エージェントにユニークな識別子です。 また、Response PDUを含む各メッセージが最近発生している要求にメッセージを関連づける要求イドを含んでいます。
A Report message sent by one SNMPv2 agent to one SNMPv2 manager can
potentially be replayed to another SNMPv2 manager. However, Report
messages do not request or contain management information, and
thus, goal #3 in Section 1.2 above is met; further, Report messages
can at most cause the manager to advance its notion of time (at the
agent) by less than the correct amount.
潜在的に1人のSNMPv2エージェントによって1人のSNMPv2マネージャに送られたReportメッセージは別のSNMPv2マネージャに再演できます。 しかしながら、Reportメッセージは、経営情報を要求もしませんし、含んでもいません、そして、その結果、上のセクション1.2における目標#3は会われます。 さらに、Reportメッセージで、マネージャは正しい量以下で時間(エージェントの)の概念を高々進めることができます。
- detecting messages which were not recently generated.
- 最近生成されなかったメッセージを検出します。
A set of time indicators are included in the message, indicating
the time of generation. Messages (other than those containing
Report PDUs) without recent time indicators are not considered
authentic. In addition, messages containing Response PDUs have a
request-id; if the request-id does not match that of a recently
generated request, then the message is not considered to be
authentic.
世代の時間を示して、1セットの期間表示はメッセージに含まれています。 最近の期間表示のないメッセージ(Report PDUsを含むものを除いた)は正統であると考えられません。 さらに、Response PDUsを含むメッセージが要求イドを持っています。 要求イドが最近発生している要求のものに合っていないなら、メッセージが正統であると考えられません。
Waters Experimental [Page 7] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[7ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
A Report message sent by an SNMPv2 agent can potentially be
replayed at a later time to an SNMPv2 manager which has not
recently communicated with that agent. However, Report messages do
not request or contain management information, and thus, goal #3 in
Section 1.2 above is met; further, Report messages can at most
cause the manager to advance its notion of time (at the agent) by
less than the correct amount.
後で潜在的にSNMPv2エージェントによって送られたReportメッセージはSNMPv2マネージャに再演できます(最近、そのエージェントとコミュニケートしていません)。 しかしながら、Reportメッセージは、経営情報を要求もしませんし、含んでもいません、そして、その結果、上のセクション1.2における目標#3は会われます。 さらに、Reportメッセージで、マネージャは正しい量以下で時間(エージェントの)の概念を高々進めることができます。
This protocol uses the MD5 [3] message digest algorithm. A 128-bit digest is calculated over the designated portion of an SNMPv2 message and included as part of the message sent to the recipient. The size of both the digest carried in a message and the private authentication key is 16 octets.
このプロトコルはMD5[3]メッセージダイジェストアルゴリズムを使用します。 メッセージの一部が受取人に発信したので、128ビットのダイジェストは、SNMPv2メッセージの指定された部分に関して計算されて、含まれています。 メッセージで運ばれたダイジェストと個人的な認証キーの両方のサイズは16の八重奏です。
This memo allows the same user to be defined on multiple SNMPv2 agents and managers. Each SNMPv2 agent maintains a value, agentID, which uniquely identifies the agent. This value is included in each message sent to/from that agent. Messages sent from a SNMPv2 dual- role entity [1] to a SNMPv2 manager include the agentID value maintained by the dual-role entity's agent. On receipt of a message, an agent checks the value to ensure it is the intended recipient, and a manager uses the value to ensure that the message is processed using the correct state information.
このメモは、同じユーザが複数のSNMPv2エージェントとマネージャの上で定義されるのを許容します。 それぞれのSNMPv2エージェントは値、唯一エージェントを特定するagentIDを維持します。 この値はそのエージェントからの/に送られた各メッセージに含まれています。 SNMPv2の二元的な役割の実体[1]からSNMPv2マネージャに送られたメッセージはニ重の役割実体のエージェントによって維持されたagentID値を含んでいます。 メッセージを受け取り次第、エージェントはそれが意図している受取人であることを保証するために値をチェックします、そして、マネージャはメッセージが正しい州の情報を使用することで処理されるのを保証するのに値を使用します。
Each SNMPv2 agent maintains two values, agentBoots and agentTime, which taken together provide an indication of time at that agent. Both of these values are included in an authenticated message sent to/received from that agent. Authenticated messages sent from a SNMPv2 dual-role entity to a SNMPv2 manager include the agentBoots and agentTime values maintained by the dual-role entity's agent. On receipt, the values are checked to ensure that the indicated time is within a time window of the current time. The time window represents an administrative upper bound on acceptable delivery delay for protocol messages.
それぞれのSNMPv2エージェントは2つの値、agentBoots、およびagentTimeを維持します。(一緒に取って、agentTimeはそのエージェントで時間のしるしを供給します)。 そのエージェントからこれらの値の両方を発信する認証されたメッセージに含んでいるか、または受け取ります。 SNMPv2ニ重の役割実体からSNMPv2マネージャに送られた認証されたメッセージは値がニ重の役割実体のエージェントで維持したagentBootsとagentTimeを含んでいます。 領収書の上では、値は、現在の時間のタイムウィンドウの中に示された時間があるのを保証するためにチェックされます。 タイムウィンドウはプロトコルメッセージのために許容できる配送遅れに管理上限を表します。
For an SNMPv2 manager to generate a message which an agent will accept as authentic, and to verify that a message received from that agent is authentic, that manager must first achieve time synchronization with that agent. Similarly, for a manger to verify that a message received from an SNMPv2 dual-role entity is authentic, that manager must first achieve time synchronization with the dual- role entity's agent.
SNMPv2マネージャが、エージェントが正統であるとして認めるメッセージを生成して、そのエージェントから受け取られたメッセージが正統であることを確かめるように、そのマネージャは最初に、そのエージェントと共に時間同期化を達成しなければなりません。 同様に、飼葉桶が、SNMPv2ニ重の役割実体から受け取られたメッセージが正統であることを確かめるように、そのマネージャは最初に、二元的な役割の実体のエージェントと共に時間同期化を達成しなければなりません。
1.4.2. Symmetric Encryption Protocol
1.4.2. 左右対称の暗号化プロトコル
The Symmetric Encryption Protocol defined in this memo provides support for data confidentiality through the use of the Data Encryption Standard (DES) in the Cipher Block Chaining mode of
Symmetric EncryptionプロトコルはこのメモがCipher Block Chainingモードにおけるデータ暗号化規格(DES)の使用によるデータの機密性のサポートを提供するコネを定義しました。
Waters Experimental [Page 8] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[8ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
operation. The designated portion of an SNMPv2 message is encrypted and included as part of the message sent to the recipient.
操作。 メッセージの一部が受取人に発信したので、SNMPv2メッセージの指定された部分は、暗号化されて、含まれています。
Two organizations have published specifications defining the DES: the National Institute of Standards and Technology (NIST) [5] and the American National Standards Institute [6]. There is a companion Modes of Operation specification for each definition (see [7] and [8], respectively).
2つの組織がDESを定義する仕様を発表しました: 米国商務省標準技術局(NIST)[5]とAmerican National Standards Institut[6]。 各定義のためのOperation仕様の仲間Modesがあります(それぞれ[7]と[8]を見てください)。
The NIST has published three additional documents that implementors may find useful.
NISTは作成者が役に立つのがわかるかもしれない3通の追加ドキュメントを発表しました。
- There is a document with guidelines for implementing and using the
DES, including functional specifications for the DES and its modes
of operation [9].
- DESを実装して、使用するためのガイドラインがあるドキュメントがあります、DESのための機能的な仕様とその操作[9]のモードを含んでいて。
- There is a specification of a validation test suite for the DES
[10]. The suite is designed to test all aspects of the DES and is
useful for pinpointing specific problems.
- DES[10]のための合法化テストスイートの仕様があります。 スイートは、DESの全面をテストするように設計されていて、特定の問題を正確に指摘することの役に立ちます。
- There is a specification of a maintenance test for the DES [11].
The test utilizes a minimal amount of data and processing to test
all components of the DES. It provides a simple yes-or-no
indication of correct operation and is useful to run as part of an
initialization step, e.g., when a computer reboots.
- DES[11]のためのメインテナンステストの仕様があります。 テストは、DESのすべての部品をテストするのに最小量のデータ量と処理を利用します。 初期化ステップの一部として稼働するのは、正しい操作の簡単な諾否しるしを供給して、役に立ちます、例えば、コンピュータがリブートされるとき。
This Symmetric Encryption Protocol specifies that the size of the privacy key is 16 octets, of which the first 8 octets are a DES key and the second 8 octets are a DES Initialization Vector. The 64-bit DES key in the first 8 octets of the private key is a 56 bit quantity used directly by the algorithm plus 8 parity bits - arranged so that one parity bit is the least significant bit of each octet. The setting of the parity bits is ignored by this protocol.
このSymmetric Encryptionプロトコルは、プライバシーキーのサイズが16の八重奏であると指定します。(そこでは、最初の8つの八重奏がDESキーであり、2番目の8つの八重奏がDES初期設定Vectorです)。 秘密鍵の最初の8つの八重奏における64ビットのDESキーは直接アルゴリズムと8つのパリティビットで使用される56ビットの量です--手配するので、1つのパリティビットがそれぞれの八重奏の最下位ビットです。 パリティビットの設定はこのプロトコルによって無視されます。
The length of an octet sequence to be encrypted by the DES must be an integral multiple of 8. When encrypting, the data is padded at the end as necessary; the actual pad value is irrelevant.
DESによって暗号化されるべき八重奏系列の長さは8の不可欠の倍数であるに違いありません。 終わりに暗号化するとき、データは必要に応じて水増しされます。 実際のパッド値は無関係です。
If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, the processing of the octet sequence is halted and an appropriate exception noted. When decrypting, the padding is ignored.
解読される八重奏系列の長さは8つの八重奏の不可欠の倍数、八重奏系列の処理が止められるということでないかどうか、そして、注意された適切な例外。 解読するとき、詰め物は無視されます。
Waters Experimental [Page 9] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[9ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
2. Elements of the Model
2. モデルのElements
This section contains definitions required to realize the security model defined by this memo.
このセクションはこのメモで定義された機密保護モデルがわかるのに必要である定義を含みます。
2.1. SNMPv2 Users
2.1. SNMPv2ユーザ
Management operations using this security model make use of a defined set of user identities. For any SNMPv2 user on whose behalf management operations are authorized at a particular SNMPv2 agent, that agent must have knowledge of that user. A SNMPv2 manager that wishes to communicate with a particular agent must also have knowledge of a user known to that agent, including knowledge of the applicable attributes of that user. Similarly, a SNMPv2 manager that wishes to receive messages from a SNMPv2 dual-role entity must have knowledge of the user on whose behalf the dual-role entity sends the message.
この機密保護モデルを使用する管理操作が定義されたセットのユーザアイデンティティを利用します。 だれの利益管理操作が特定のSNMPv2エージェントで認可されるかのどんなSNMPv2ユーザに関してはも、そのエージェントには、そのユーザに関する知識がなければなりません。 また、特定代理人とコミュニケートしたがっているSNMPv2マネージャはそのエージェントにとってユーザに関する知識を知らせなければなりません、そのユーザの適切な属性に関する知識を含んでいて。 同様に、SNMPv2ニ重の役割実体からメッセージを受け取りたがっているSNMPv2マネージャはユーザに関する知識をニ重の役割実体がだれの代理にメッセージを送るかに関して持たなければなりません。
A user and its attributes are defined as follows:
ユーザとその属性は以下の通り定義されます:
<userName>
An octet string representing the name of the user.
ユーザの名前を表す<userName>An八重奏ストリング。
<authProtocol>
An indication of whether messages sent on behalf of this user can
be authenticated, and if so, the type of authentication protocol
which is used. One such protocol is defined in this memo: the
Digest Authentication Protocol.
メッセージがこのユーザを代表して発信したかどうか<authProtocol>Anしるしを認証できます、そして、そうだとすれば、認証のタイプは議定書を作ります(使用されています)。 そのようなプロトコルの1つはこのメモで定義されます: ダイジェスト認証プロトコル。
<authPrivateKey>
If messages sent on behalf of this user can be authenticated, the
(private) authentication key for use with the authentication
protocol. Note that a user's authentication key will normally be
different at different agents.
このユーザを代表して送られた<authPrivateKey>Ifメッセージは認証できます、使用に、認証プロトコルによって主要な(個人的)の認証。 通常、ユーザの認証キーが異なったエージェントで異なることに注意してください。
<privProtocol>
An indication of whether messages sent on behalf of this user can
be protected from disclosure, and if so, the type of privacy
protocol which is used. One such protocol is defined in this memo:
the Symmetric Encryption Protocol.
公開からメッセージがこのユーザを代表して発信したかどうか<privProtocol>Anしるしを保護できます、そして、そうだとすれば、プライバシーのタイプは議定書を作ります(使用されています)。 そのようなプロトコルの1つはこのメモで定義されます: 左右対称の暗号化プロトコル。
<privPrivateKey>
If messages sent on behalf of this user can be protected from
disclosure, the (private) privacy key for use with the privacy
protocol. Note that a user's privacy key will normally be
different at different agents.
公開(使用に、プライバシープロトコルによって主要な(個人的)のプライバシー)からこのユーザを代表して送られた<privPrivateKey>Ifメッセージは保護できます。 通常、ユーザのプライバシーキーが異なったエージェントで異なることに注意してください。
Waters Experimental [Page 10] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[10ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
2.2. Contexts and Context Selectors
2.2. 文脈と文脈セレクタ
An SNMPv2 context is a collection of management information accessible (locally or via proxy) by an SNMPv2 agent. An item of management information may exist in more than one context. An SNMPv2 agent potentially has access to many contexts. Each SNMPv2 message contains a context selector which unambiguously identifies an SNMPv2 context accessible by the SNMPv2 agent to which the message is directed or by the SNMPv2 agent associated with the sender of the message.
SNMPv2文脈はSNMPv2エージェントで経営情報の理解できる収集(局所的かプロキシを通した)です。 経営情報の項目は1つ以上の文脈に存在するかもしれません。 SNMPv2エージェントは潜在的に多くの文脈に近づく手段を持っています。 それぞれのSNMPv2メッセージは明白にメッセージが指示されているSNMPv2エージェントかメッセージ送信者に関連づけられたSNMPv2エージェントがアクセス可能なSNMPv2関係を特定する文脈セレクタを含んでいます。
For a local SNMPv2 context which is realized by an SNMPv2 entity, that SNMPv2 entity uses locally-defined mechanisms to access the management information identified by the SNMPv2 context.
SNMPv2実体によって実現されるローカルのSNMPv2関係に関しては、そのSNMPv2実体は、SNMPv2文脈によって特定された経営情報にアクセスするのに局所的に定義されたメカニズムを使用します。
For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context.
プロキシSNMPv2文脈に関しては、SNMPv2実体は、SNMPv2文脈によって特定された経営情報にアクセスするためにプロキシSNMPv2エージェントとして務めます。
The term remote SNMPv2 context is used at an SNMPv2 manager to indicate a SNMPv2 context (either local or proxy) which is not realized by the local SNMPv2 entity (i.e., the local SNMPv2 entity uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context).
用語のリモートSNMPv2文脈は、地方のSNMPv2実体によって実現されないSNMPv2文脈(ローカルかプロキシのどちらか)を示すのにSNMPv2マネージャで使用されます(すなわち、地方のSNMPv2実体はSNMPv2文脈によって特定された経営情報にアクセスするのにプロキシSNMPv2エージェントとして局所的に定義されたメカニズムも行為も使用しません)。
Proxy SNMPv2 contexts are further categorized as either local-proxy contexts or remote-proxy contexts. A proxy SNMPv2 agent receives Get/GetNext/GetBulk/Set operations for a local-proxy context, and forwards them with a remote-proxy context; it receives SNMPv2-Trap and Inform operations for a remote-proxy context, and forwards them with a local-proxy context; for Response operations, a proxy SNMPv2 agent receives them with either a local-proxy or remote-proxy context, and forwards them with a remote-proxy or local-proxy context, respectively.
プロキシSNMPv2文脈は地元のプロキシ文脈かリモートプロキシ文脈のどちらかとしてさらに分類されます。 プロキシSNMPv2エージェントは、地元のプロキシ文脈のためにGet/GetNext/GetBulk/集合演算を受けて、リモートプロキシ文脈と共にそれらを進めます。 それは、リモートプロキシ文脈のためにSNMPv2-罠とInform操作を受けて、地元のプロキシ文脈と共にそれらを進めます。 Response操作のために、プロキシSNMPv2エージェントは、ローカルのプロキシかリモートプロキシ関係のどちらかでそれらを受けて、リモートプロキシか地元のプロキシ文脈と共にそれらをそれぞれ進めます。
Waters Experimental [Page 11] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[11ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
For the non-proxy situation:
非プロキシ状況のために:
context-A
Manager <----------------> Agent
文脈Aマネージャ<。---------------->エージェント
the type of context is:
文脈のタイプは以下の通りです。
+-----------------+
| context-A |
+-----------------+-----------------+
| Manager | remote |
+-----------------+-----------------+
| Agent | local |
+-----------------+-----------------+
| agentID | of Agent |
+-----------------+-----------------+
| contextSelector | locally unique |
+-----------------+-----------------+
+-----------------+ | 文脈A| +-----------------+-----------------+ | マネージャ| リモート| +-----------------+-----------------+ | エージェント| ローカル| +-----------------+-----------------+ | agentID| エージェントについて| +-----------------+-----------------+ | contextSelector| 局所的にユニークです。| +-----------------+-----------------+
For proxy:
プロキシのために:
context-B context-C
Manager <----------------> Proxy <----------------> Agent
Agent
文脈B文脈Cマネージャ<。---------------->プロキシ<。---------------->エージェントのエージェント
the type and identity of the contexts are:
文脈のタイプとアイデンティティは以下の通りです。
+-----------------+-----------------+
| context-B | context-C |
+-----------------+-----------------+-----------------+
| Manager | remote | -- |
+-----------------+-----------------+-----------------+
| Proxy-Agent | local-proxy | remote-proxy |
+-----------------+-----------------+-----------------+
| Agent | -- | local |
+-----------------+-----------------+-----------------+
| agentID | of Proxy agent | of Agent |
+-----------------+-----------------+-----------------+
| contextSelector | locally unique | locally unique |
+-----------------+-----------------+-----------------+
+-----------------+-----------------+ | 文脈B| 文脈C| +-----------------+-----------------+-----------------+ | マネージャ| リモート| -- | +-----------------+-----------------+-----------------+ | プロキシ兼エージェント| 地元のプロキシ| リモートプロキシ| +-----------------+-----------------+-----------------+ | エージェント| -- | ローカル| +-----------------+-----------------+-----------------+ | agentID| Proxyエージェントについて| エージェントについて| +-----------------+-----------------+-----------------+ | contextSelector| 局所的にユニークです。| 局所的にユニークです。| +-----------------+-----------------+-----------------+
The combination of an agentID value and a context selector provides a globally-unique identification of a context. When a context is accessible by multiple agents (e.g., including by proxy SNMPv2 agents), it has multiple such globally-unique identifications, one associated with each agent which can access it. In the example above, "context-B" and "context-C" are different names for the same context.
agentID値と文脈セレクタの組み合わせは文脈のグローバルにユニークな識別を提供します。 関係が複数のエージェント(例えば、代理人を通して、SNMPv2エージェントを含んでいます)がアクセスしやすいときに、それには、複数のあれほどグローバルにユニークな識別(それの缶がそれにアクセスする各エージェントに関連づけられたもの)があります。 例では、「文脈B」と「文脈C」は同じ文脈のための上では、異なった名前です。
Waters Experimental [Page 12] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[12ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
2.3. Quality of Service (qoS)
2.3. サービスの質(qoS)
Messages are generated with a particular Quality of Service (qoS), either:
メッセージはService(qoS)の特定のQualityと共に生成されます:
- without authentication and privacy,
- 認証とプライバシーなしで
- with authentication but not privacy,
- プライバシーではなく、認証で
- with authentication and privacy.
- 認証とプライバシーで。
All users are capable of having messages without authentication and privacy generated on their behalf. Users having an authentication protocol and an authentication key can have messages with authentication but not privacy generated on their behalf. Users having an authentication protocol, an authentication key, a privacy protocol and a privacy key can have messages with authentication and privacy generated on their behalf.
すべてのユーザがそれらに代わって生成された認証とプライバシーなしでメッセージを持つことができます。 認証プロトコルと認証キーを持っているユーザはプライバシーではなく、認証がそれらに代わって生成されているメッセージを持つことができます。 認証プロトコル、認証キー、プライバシープロトコル、およびプライバシーキーを持っているユーザは認証とプライバシーがそれらに代わって生成されているメッセージを持つことができます。
In addition to its indications of authentication and privacy, the qoS may also indicate that the message contains an operation that may result in a report PDU being generated (see Section 2.6 below).
また、認証とプライバシーのしるしに加えて、qoSは、メッセージが生成されるレポートPDUをもたらすかもしれない操作を含むのを示すかもしれません(以下のセクション2.6を見てください)。
2.4. Access Policy
2.4. アクセス方針
An administration's access policy determines the access rights of users. For a particular SNMPv2 context to which a user has access using a particular qoS, that user's access rights are given by a list of authorized operations, and for a local context, a read-view and a write-view. The read-view is the set of object instances authorized for the user when reading objects. Reading objects occurs when processing a retrieval (get, get-next, get-bulk) operation and when sending a notification. The write-view is the set of object instances authorized for the user when writing objects. Writing objects occurs when processing a set operation. A user's access rights may be different at different agents.
管理のアクセス方針はユーザのアクセス権を決定します。 ユーザが特定のqoSを使用することでアクセスを持っている特定のSNMPv2文脈に関しては、認可された操作のリスト、ローカルの関係、読書視点、およびaのために視点を書いてそのユーザのアクセス権を与えます。 視点を読むのは、オブジェクトを読むときユーザのために認可されたオブジェクトインスタンスのセットです。 通知書を送りながら検索(気付いて、嵩を得るのに得る)操作といつを処理するかとき、オブジェクトを読むのは起こります。 視点を書くのは、オブジェクトを書くときユーザのために認可されたオブジェクトインスタンスのセットです。 集合演算を処理するとき、オブジェクトを書くのは起こります。 ユーザのアクセス権は異なったエージェントで異なっているかもしれません。
2.5. Replay Protection
2.5. 反復操作による保護
Each SNMPv2 agent (or dual-role entity) maintains three objects:
それぞれのSNMPv2エージェント(または、ニ重の役割実体)は3個のオブジェクトを維持します:
- agentID, which is an identifier unique among all agents in (at
least) an administrative domain;
- agentID、(少なくとも)管理ドメインのすべてのエージェントの中でユニークな識別子はどれです。
- agentBoots, which is a count of the number of times the agent has
rebooted/re-initialized since agentID was last configured; and,
- agentBoots、agentIDが最後に構成されて以来、エージェントがリブートするか、または再初期化している回数のカウントはどれです。 そして
Waters Experimental [Page 13] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[13ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
- agentTime, which is the number of seconds since agentBoots was last
incremented.
- agentTime。(agentBootsが最後に増加されたので、そのagentTimeは秒数です)。
An SNMPv2 agent is always authoritative with respect to these variables. It is the responsibility of an SNMPv2 manager to synchronize with the agent, as appropriate. In the case of an SNMPv2 dual-role entity sending an Inform-Request, it is that entity acting in an agent role which is authoritative with respect to these variables for the Inform-Request.
SNMPv2エージェントはいつもこれらの変数に関して正式です。 エージェントに連動するのは、適宜SNMPv2マネージャの責任です。 Inform-要求を送るSNMPv2ニ重の役割実体の場合では、これらの変数に関してInform-要求に正式であるのは、エージェントの役割で行動するその実体です。
An agent is required to maintain the values of agentID and agentBoots in non-volatile storage.
エージェントが、非揮発性記憶装置でagentIDとagentBootsの値を維持するのに必要です。
2.5.1. agentID
2.5.1. agentID
The agentID value contained in an authenticated message is used to defeat attacks in which messages from a manager are replayed to a different agent and/or messages from one agent (or dual-role entity) are replayed as if from a different agent (or dual-role entity).
認証されたメッセージに含まれたagentID値は、マネージャからのメッセージが異なったエージェントに再演されて、1人のエージェント(または、ニ重の役割実体)からのメッセージが再演される攻撃を破るのにまるで異なったエージェント(または、ニ重の役割実体)から使用するかのように使用されます。
When an agent (or dual-role entity) is first installed, it sets its local value of agentID according to a enterprise-specific algorithm (see the definition of agentID in Section 4.1).
エージェント(または、ニ重の役割実体)が最初にインストールされるとき、企業特有のアルゴリズムによると、それはagentIDの地方の値を設定します(セクション4.1とのagentIDの定義を見てください)。
2.5.2. agentBoots and agentTime
2.5.2. agentBootsとagentTime
The agentBoots and agentTime values contained in an authenticated message are used to defeat attacks in which messages are replayed when they are no longer valid. Through use of agentBoots and agentTime, there is no requirement for an SNMPv2 agent to have a non-volatile clock which ticks (i.e., increases with the passage of time) even when the agent is powered off. Rather, each time an SNMPv2 agent reboots, it retrieves, increments, and then stores agentBoots in non-volatile storage, and resets agentTime to zero.
値が認証されたメッセージに含んだagentBootsとagentTimeは、それらがもう有効でないときにメッセージが再演される攻撃を破るのに使用されます。 agentBootsとagentTimeの使用で、SNMPv2エージェントが離れてエージェントが動力付きであるときにさえカチカチする(すなわち、時がたつにつれて、増加します)非揮発性の時計を持っているという要件が全くありません。 むしろ、それは、非揮発性記憶装置でagentBootsを検索して、増加して、次に、保存して、SNMPv2エージェントがリブートするたびにゼロにagentTimeをリセットします。
When an agent (or dual-role entity) is first installed, it sets its local values of agentBoots and agentTime to zero. If agentTime ever reaches its maximum value (2147483647), then agentBoots is incremented as if the agent has rebooted and agentTime is reset to zero and starts incrementing again.
エージェント(または、ニ重の役割実体)が最初にインストールされるとき、それはagentBootsとagentTimeの地方の値をゼロに設定します。 agentTimeが最大値(2147483647)に達するならまるでエージェントがリブートしたかのようにagentBootsが増加されていて、agentTimeはゼロにリセットされて、再び増加し始めます。
Each time an agent (or dual-role entity) reboots, any SNMPv2 managers holding that agent's values of agentBoots and agentTime need to re- synchronize prior to sending correctly authenticated messages to that agent (see Section 2.7 for re-synchronization procedures). Note, however, that the procedures do provide for a notification to be accepted as authentic by a manager, when sent by an agent which has rebooted since the manager last re-synchronized.
エージェント(または、ニ重の役割実体)がリブートする各回、そのエージェントのagentBootsとagentTimeの値を保持しているどんなSNMPv2マネージャも正しく認証されたメッセージをそのエージェントに送る前に再連動する必要があります(再同期手順に関してセクション2.7を見てください)。 しかしながら、手順がマネージャが最後に再連動して以来の正統であるとマネージャによって受け入れられるべき通知にリブートされて、エージェントによって送られると備えることに注意してください。
Waters Experimental [Page 14] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[14ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
If an agent (or dual-role entity) is ever unable to determine its latest agentBoots value, then it must set its agentBoots value to 0xffffffff.
エージェント(または、ニ重の役割実体)が最新のagentBoots値を決定できないなら、それはagentBoots値を0xffffffffに設定しなければなりません。
Whenever the local value of agentBoots has the value 0xffffffff, it latches at that value and an authenticated message always causes an usecStatsNotInWindows authentication failure.
agentBootsの地方の値に値の0xffffffffがあるときはいつも、その値で掛け金をおろします、そして、認証されたメッセージはいつもusecStatsNotInWindows認証の故障を引き起こします。
In order to reset an agent whose agentBoots value has reached the value 0xffffffff, manual intervention is required. The agent must be physically visited and re-configured, either with a new agentID value, or with new secret values for the authentication and privacy keys of all users known to that agent.
agentBoots値が値の0xffffffffに達したエージェントをリセットするために、手動の介入が必要です。 新しいagentID値、またはそのエージェントにとって知られているすべてのユーザの認証とプライバシーキーのための新しい秘密の値でエージェントを物理的に訪問されて、再構成しなければなりません。
2.5.3. Time Window
2.5.3. タイム・ウィンドウ
The Time Window is a value that specifies the window of time in which a message generated on behalf of any user is valid. This memo specifies that the same value of the Time Window, 150 seconds, is used for all users.
タイム・ウィンドウはどんなユーザを代表して生成されたメッセージが有効である時間の窓を指定する値です。 このメモは、タイム・ウィンドウの同じ値(150秒)がすべてのユーザに使用されると指定します。
2.6. Error Reporting
2.6. 誤り報告
While processing a received communication, an SNMPv2 entity may determine that the message is unacceptable (see Section 3.2). In this case, the appropriate counter from the snmpGroup [15] or usecStatsGroup object groups is incremented and the received message is discarded without further processing.
受信されたコミュニケーションを処理している間、SNMPv2実体は、メッセージが容認できないことを決定するかもしれません(セクション3.2を見てください)。 この場合、snmpGroup[15]かusecStatsGroupオブジェクトグループからの適切なカウンタは増加されています、そして、受信されたメッセージはさらなる処理なしで捨てられます。
If an SNMPv2 entity acting in the agent role makes such a determination and the qoS indicates that a report may be generated, then after incrementing the appropriate counter, it is required to generate a message containing a report PDU, with the same user and context as the received message, and to send it to the transport address which originated the received message. For all report PDUs, except those generated due to incrementing the usecStatsNotInWindows counter, the report PDU is unauthenticated. For those generated due to incrementing usecStatsNotInWindows, the report PDU is authenticated only if the received message was authenticated.
エージェントの役割で行動するのがそのような決断とqoSをするSNMPv2実体が、レポートが作られるかもしれないのを示すなら、適切なカウンタを増加した後に、それが、受信されたメッセージとして同じユーザと文脈でレポートPDUを含むメッセージを生成して、受信されたメッセージを溯源した輸送アドレスにそれを送るのに必要です。 usecStatsNotInWindowsカウンタを増加するため生成されたもの以外のすべてのレポートPDUsに関しては、レポートPDUは非認証されます。 増加しているusecStatsNotInWindowsのため生成されたものに関しては、受信されたメッセージが認証された場合にだけ、レポートPDUは認証されます。
The report flag in the qoS may only be set if the message contains a Get, GetNext, GetBulk, Set operation. The report flag should never be set for a message that contains a Response, Inform, SNMPv2-Trap or Report operation. Furthermore, a report PDU is never sent by an SNMPv2 entity acting in a manager role.
メッセージがGet、GetNext、GetBulk、Set操作を含んでいる場合にだけ、qoSのレポート旗は設定されるかもしれません。 レポート旗はResponse、Inform、SNMPv2-罠またはReport操作を含むメッセージに決して設定されるべきではありません。 その上、マネージャの役割で行動するSNMPv2実体でレポートPDUを決して送りません。
Waters Experimental [Page 15] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[15ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
2.7. Time Synchronization
2.7. 時間同期化
Time synchronization, required by a management entity in order to proceed with authentic communications, has occurred when the management entity has obtained local values of agentBoots and agentTime from the agent that are within the agent's time window. To remain synchronized, the local values must remain within the agent's time window and thus must be kept loosely synchronized with the values stored at the agent. In addition to keeping a local version of agentBoots and agentTime, a manager must also keep one other local variable, latestReceivedAgentTime. This value records the highest value of agentTime that was received by the manager from the agent and is used to eliminate the possibility of replaying messages that would prevent the manager's notion of the agentTime from advancing.
経営体がエージェントからのエージェントのタイムウィンドウの中にあるagentBootsとagentTimeの地方の値を得たとき、正統のコミュニケーションを続けるために経営体によって必要とされた時間同期化は起こりました。 連動したままで残るために、地方の値にエージェントのタイムウィンドウに残らなければならなくて、その結果、緩くエージェントに保存される値に連動しているように保たなければなりません。 また、agentBootsとagentTimeのローカルのバージョンを保つことに加えて、マネージャは他の1つの局所変数(latestReceivedAgentTime)を保たなければなりません。 この値はマネージャによってエージェントから受け取られて、agentTimeに関するマネージャの概念が進むのを防ぐメッセージを再演する可能性を排除するのに使用されるagentTimeの最も高い値を記録します。
Time synchronization occurs as part of the procedures of receiving a message (Section 3.2, step 9d). As such, no explicit time synchronization procedure is required by a management entity. Note, that whenever the local value of agentID is changed (e.g., through discovery) or when a new secret is configured, the local values of agentBoots and latestReceivedAgentTime should be set to zero. This will cause the time synchronization to occur when the next authentic message is received.
時間同期化はメッセージ(セクション3.2、ステップ9d)を受け取る手順の一部として起こります。 そういうものとして、どんな明白な時間同期化手順も経営体によって必要とされません。 agentIDの地方の値を変える(例えば、発見で)ときはいつも、新しい秘密が構成されるとき、agentBootsとlatestReceivedAgentTimeの地方の値がゼロに設定されるべきであるというメモ。 次の正統のメッセージが受信されているとき、これで、時間同期化は起こるでしょう。
2.8. Proxy Error Propagation
2.8. プロキシ誤り伝播
When a proxy SNMPv2 agent receives a report PDU from a proxied agent and it is determined that a proxy-forwarded request cannot be delivered to the proxied agent, then the snmpProxyDrops counter [15] is incremented and a report PDU is generated and transmitted to the transport address from which the original request was received. (Note that the receipt of a report PDU containing snmpProxyDrops as a VarBind, is included among the reasons why a proxy-forwarded request cannot be delivered.)
プロキシSNMPv2エージェントがproxiedエージェントからレポートPDUを受け取って、プロキシによって転送された要求をproxiedエージェントに提供できないのが決定していると、snmpProxyDropsカウンタ[15]が増加されていて、レポートPDUはオリジナルの要求が受け取られた輸送アドレスに生成されて、伝えられます。 (プロキシによって転送された要求を提供できない理由の中でVarBindとしてsnmpProxyDropsを含むレポートPDUの領収書が含まれていることに注意してください。)
2.9. SNMPv2 Messages Using this Model
2.9. SNMPv2 Messages UsingはこのModelです。
The syntax of an SNMPv2 message using this security model differs from that of an SNMPv1 [2] message as follows:
この機密保護モデルを使用するSNMPv2メッセージの構文は以下の通りSNMPv1[2]メッセージのものと異なっています:
- The version component is changed to 2.
- バージョンコンポーネントは2に変わります。
- The data component contains either a PDU or an OCTET STRING
containing an encrypted PDU.
- データ構成要素は暗号化されたPDUを含むPDUかOCTET STRINGのどちらかを含んでいます。
The SNMPv1 community string is now termed the "parameters" component and contains a set of administrative information for the message.
SNMPv1共同体ストリングは、現在、「パラメタ」コンポーネントと呼ばれて、メッセージのための1セットの管理情報を含んでいます。
Waters Experimental [Page 16] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[16ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
Only the PDU is protected from disclosure by the privacy protocol. This exposes the administrative information to eavesdroppers. However, malicious use of this information is considered to be a Traffic Analysis attack against which protection is not provided.
PDUだけがプライバシープロトコルによって公開から保護されます。 これは立ち聞きする者に管理情報を暴露します。 しかしながら、この情報の悪意がある使用は保護が提供されないTraffic Analysis攻撃であると考えられます。
For an authenticated SNMPv2 message, the message digest is applied to the entire message given to the transport service. As such, message generation first privatizes the PDU, then adds the message wrapper, and then authenticates the message.
認証されたSNMPv2メッセージに関しては、メッセージダイジェストは輸送サービスに与えられた全体のメッセージに適用されます。 そういうものとして、メッセージ世代は、最初にPDUを民営化して、次に、メッセージラッパーを加えて、次に、メッセージを認証します。
An SNMPv2 message is an ASN.1 value with the following syntax:
SNMPv2メッセージは以下の構文があるASN.1値です:
Message ::=
SEQUENCE {
version
INTEGER { v2 (2) },
以下を通信させてください:= SEQUENCE、バージョンINTEGER v2(2)
parameters
OCTET STRING,
-- <model=1>
-- <qoS><agentID><agentBoots><agentTime><maxSize>
-- <userLen><userName><authLen><authDigest>
-- <contextSelector>
パラメタOCTET STRING--<モデル=1>--<qoS><agentID><agentBoots><agentTime><maxSize>--<userLen><userName><authLen><authDigest>--<contextSelector>。
data
CHOICE {
plaintext
PDUs,
encrypted
OCTET STRING
}
}
データCHOICE、平文PDUs、暗号化されたOCTET STRING
where:
どこ:
parameters
a concatenation of the following values in network-byte order. If
the first octet (<model>) is one, then
以下の連結がネットワークバイトオーダーで評価するパラメタ。 次に、最初の八重奏(<モデル>)が1であるなら
<qoS> = 8-bits of quality-of-service
サービスの質の8<qoS>=ビット
bitnumber
7654 3210 meaning
---- ---- --------------------------------
.... ..00 no authentication nor privacy
.... ..01 authentication, no privacy
.... ..1. authentication and privacy
.... .1.. generation of report PDU allowed
bitnumber7654 3210意味---- ---- -------------------------------- .... ..または、00、認証がない、プライバシー… ..01 認証、プライバシーがありません… ..1. 認証とプライバシー… .1 PDUが許した世代のレポート
Waters Experimental [Page 17] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[17ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
where bit 7 is the most significant bit.
噛み付かれるところでは、7が最も重要なビットです。
<agentID> = 12 octets
a unique identifier for the agent (or dual-role entity).
<agentID>は12の八重奏と等しいです。エージェント(または、ニ重の役割実体)にとって、ユニークな識別子。
<agentBoots> = 32-bits
an unsigned quantity (0..4294967295) in network-byte order.
<agentBoots>は32ビット等しいです。ネットワークバイトオーダーにおける未署名の量(0 .4294967295)。
<agentTime> = 32-bits
an unsigned quantity (0..2147483647) in network-byte order.
<agentTime>は32ビット等しいです。ネットワークバイトオーダーにおける未署名の量(0 .2147483647)。
<maxSize> = 16-bits
an unsigned quantity (484..65507) in network-byte order, which
identifies the maximum message size which the sender of this
message can receive using the same transport domain as used
for this message.
<は16>=ビットをmaxSizeします。ネットワークバイトオーダーにおける未署名の量(484 .65507)。(それは、このメッセージに使用されるように同じ輸送ドメインを使用することでこのメッセージの送付者が受けることができる最大のメッセージサイズを特定します)。
<userLen> = 1 octet
the length of following <userName> field.
<userLen>は<userName>に続く長さがさばく1つの八重奏と等しいです。
<userName> = 1..16 arbitrary octets
the user on whose behalf this message is sent.
<ユーザ名>=1。16 これがだれの代理を通信させるかのユーザが送られる任意の八重奏。
<authLen> = 1 octet
the length of following <authDigest> field.
<authLen>は<authDigest>に続く長さがさばく1つの八重奏と等しいです。
<authDigest> = 0..255 octets
for authenticated messages, the authentication digest.
Otherwise, the value has zero-length on transmission and is
ignored on receipt.
<の最もauthDigestな>=0。認証されたメッセージ、認証ダイジェストのための255の八重奏。 さもなければ、値は、トランスミッションにゼロ・レングスを持って、領収書の上で無視されます。
<contextSelector> = 0..40 arbitrary octets
the context selector which in combination with agentID
identifies the SNMPv2 context containing the management
information referenced by the SNMPv2 message.
<contextSelector>=0。40の任意の八重奏、agentIDと組み合わせてSNMPv2メッセージによって参照をつけられる経営情報を含むSNMPv2文脈を特定する文脈セレクタ。
plaintext
an SNMPv2 PDU as defined in [12].
平文、[12]で定義されるSNMPv2 PDU。
encrypted
the encrypted form of an SNMPv2 PDU.
SNMPv2 PDUの暗号化されたフォームを暗号化しました。
2.10. Local Configuration Datastore (LCD)
2.10. 地方の構成Datastore(LCD)
Each SNMPv2 entity maintains a local conceptually database, called the Local Configuration Datastore (LCD), which holds its known set of information about SNMPv2 users and other associated (e.g., access control) information. An LCD may potentially be required to hold
それぞれのSNMPv2実体は概念的にローカルを維持します。知られているセットのSNMPv2の情報がユーザであることを保持するLocal Configuration Datastore(LCD)と呼ばれるデータベースと他の関連している(例えば、アクセスコントロール)情報。 LCDが、成立するのに潜在的に必要であるかもしれません。
Waters Experimental [Page 18] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[18ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
information about multiple SNMPv2 agent entities. As such, the <agentID> should be used to identify a particular agent entity in the LCD.
複数のSNMPv2エージェント実体の情報。 そういうものとして、<agentID>は、LCDで特定代理人実体を特定するのに使用されるべきです。
It is a local implementation issue as to whether information in the LCD is stored information or whether it is obtained dynamically (e.g., as a part of an SNMPv2 manager's API) on an as-needed basis.
それ、LCDの情報が記憶された情報であるかどうかかそれともそれが記憶された情報であるかどうかに関してダイナミック(例えば、SNMPv2マネージャのAPIの一部として)に得られたローカルの導入問題がオンである、必要に応じて、基礎
3. Elements of Procedure
3. 手順のElements
This section describes the procedures followed by an SNMPv2 entity in processing SNMPv2 messages.
このセクションは手順について説明します、続いて、処理SNMPv2メッセージのSNMPv2実体について説明します。
3.1. Generating a Request or Notification
3.1. 要求か通知を生成します。
This section describes the procedure followed by an SNMPv2 entity whenever it generates a message containing a management operation (either a request or a notification) on behalf of a user, for a particular context and with a particular qoS value.
このセクションは手順について説明します、続いて、特定の文脈と特定のqoS値でユーザを代表して管理操作(要求か通知のどちらか)を含むメッセージを生成するときはいつも、SNMPv2実体について説明します。
(1) Information concerning the user is extracted from the LCD. The
transport domain and transport address to which the operation is to
be sent is determined. The context is resolved into an agentID
value and a contextSelector value.
(1) ユーザに関する情報はLCDから抜粋されます。 送られる操作がことである輸送ドメインと輸送アドレスは決定しています。 文脈はagentID値とcontextSelector値に変えられます。
(2) If the qoS specifies that the message is to be protected from
disclosure, but the user does not support both an authentication
and a privacy protocol, or does not have configured authentication
and privacy keys, then the operation cannot be sent.
(2) qoSが、メッセージが公開から保護されることであると指定しますが、ユーザが両方が認証とプライバシープロトコルであることを支えないか、または構成された認証とプライバシーキーを持っていないなら、操作を送ることができません。
(3) If the qoS specifies that the message is to be authenticated, but
the user does not support an authentication protocol, or does not
have a configured authentication key, then the operation cannot be
sent.
(3) qoSが、メッセージが認証されることであると指定しますが、ユーザが認証プロトコルをサポートしないか、または構成された認証キーを持っていないなら、操作を送ることができません。
(4) The operation is serialized (i.e., encoded) according to the
conventions of [13] and [12] into a PDUs value.
(4) [13]と[12]のコンベンションによると、操作はPDUs値に連載されます(すなわち、コード化されます)。
(5) If the operation is a Get, GetNext, GetBulk, or Set then the report
flag in the qoS is set to the value 1.
(5) 操作がGet、GetNext、GetBulk、またはSetであるなら、qoSのレポート旗は値1に設定されます。
(6) An SNMPv2 message is constructed using the ASN.1 Message syntax:
(6) SNMPv2メッセージはASN.1Message構文を使用することで構成されます:
- the version component is set to the value 2.
- バージョンコンポーネントは値2に設定されます。
- if the qoS specifies that the message is to be protected from
disclosure, then the octet sequence representing the serialized
PDUs value is encrypted according to the user's privacy protocol
- qoSが、メッセージが公開から保護されることであると指定するなら、ユーザのプライバシープロトコルによると、連載されたPDUs値を表す八重奏系列は暗号化されます。
Waters Experimental [Page 19] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[19ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
and privacy key, and the encrypted data is encoded as an octet
string and is used as the data component of the message.
プライバシーキー、暗号化されたデータは、八重奏ストリングとしてコード化されて、メッセージのデータ構成要素として使用されます。
- if the qoS specifies that the message is not to be protected from
disclosure, then the serialized PDUs value is used directly as
the value of the data component.
- qoSが、メッセージが公開から保護されないことであると指定するなら、連載されたPDUs値は直接データ構成要素の値として使用されます。
- the parameters component is constructed using:
- パラメタコンポーネントは組み立てられた使用です:
- the requested qoS, userName, agentID and context selector,
- 要求されたqoS、userName、agentID、および文脈セレクタ
- if the qoS specifies that the message is to be authenticated or
the management operation is a notification, then the current
values of agentBoots, and agentTime corresponding to agentID
from the LCD are used. Otherwise, the <agentBoots> and
<agentTime> fields are set to zero-filled octets.
- qoSが、メッセージが認証されることであると指定するか、そして、管理操作が通知です、電流が評価するagentBootsのその時、そして、LCDからのagentIDに対応するagentTimeは使用されています。 さもなければ、<agentBoots>と<agentTime>分野は無いっぱいにされた八重奏に用意ができています。
- the <maxSize> field is set to the maximum message size which
the local SNMPv2 entity can receive using the transport domain
which will be used to send this message.
- <maxSize>分野はこのメッセージを送るのに使用される輸送ドメインを使用する地方のSNMPv2実体が受けることができる最大のメッセージサイズに設定されます。
- if the qoS specifies that the message is to be authenticated,
then the <authDigest> field is temporarily set to the user's
authentication key. Otherwise, the <authDigest> field is set
to the zero-length string.
- qoSが、メッセージが認証されることであると指定するなら、<authDigest>分野は一時ユーザの認証キーに設定されます。 さもなければ、<authDigest>分野はゼロ長ストリングに設定されます。
(7) The constructed Message value is serialized (i.e., encoded)
according to the conventions of [13] and [12].
(7) [13]と[12]のコンベンションによると、組み立てられたMessage値は連載されます(すなわち、コード化されます)。
(8) If the qoS specifies that the message is to be authenticated, then
an MD5 digest value is computed over the octet sequence
representing the concatenation of the serialized Message value and
the user's authentication key. The <authDigest> field is then set
to the computed digest value.
(8) qoSが、メッセージが認証されることであると指定するなら、MD5ダイジェスト価値は連載されたMessage値とユーザの認証キーの連結を表す八重奏系列に関して計算されます。 そして、<authDigest>分野は計算されたダイジェスト値に設定されます。
(9) The serialized Message value is transmitted to the determined
transport address.
(9) 連載されたMessage値は決定している輸送アドレスに送られます。
3.2. Processing a Received Communication
3.2. 受信されたコミュニケーションを処理します。
This section describes the procedure followed by an SNMPv2 entity whenever it receives an SNMPv2 message. This procedure is independent of the transport service address at which the message was received. For clarity, some of the details of this procedure are left out and are described in Section 3.2.1 and its sub-sections.
このセクションは手順について説明します、続いて、SNMPv2メッセージを受け取るときはいつも、SNMPv2実体について説明します。 この手順はメッセージが受け取られた輸送サービスアドレスから独立しています。 明快において、この手順の詳細のいくつかが、省かれて、セクション3.2.1とその小区分で説明されます。
(1) The snmpInPkts counter [15] is incremented. If the received
message is not the serialization (according to the conventions of
(1) snmpInPktsカウンタ[15]は増加されています。 受信されたメッセージが連載でない、(コンベンション
Waters Experimental [Page 20] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[20ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
[13]) of a Message value, then the snmpInASNParseErrs counter [15]
is incremented, and the message is discarded without further
processing.
[13]) 次に、Message価値では、snmpInASNParseErrsカウンタ[15]は増加されています、そして、メッセージはさらなる処理なしで捨てられます。
(2) If the value of the version component has a value other than 2,
then the message is either processed according to some other
version of this protocol, or the snmpInBadVersions counter [15] is
incremented, and the message is discarded without further
processing.
(2) snmpInBadVersionsカウンタ[15]は増加されています、そして、バージョンコンポーネントの値に2以外の値があるなら、このプロトコルのある他のバージョンによると、メッセージが処理されるか、またはメッセージはさらなる処理なしで捨てられます。
(3) The value of the <model> field is extracted from the parameters
component of the Message value. If the value of the <model> field
is not 1, then either the message is processed according to some
other security model, or the usecStatsBadParameters counter is
incremented, and the message is discarded without further
processing.
(3) <モデル>分野の値はMessage価値のパラメタコンポーネントから抽出されます。 usecStatsBadParametersカウンタは増加されています、そして、<モデル>分野の値が1でないなら、ある他の機密保護モデルによると、メッセージが処理されるか、またはメッセージはさらなる処理なしで捨てられます。
(4) The values of the rest of the fields are extracted from the
parameters component of the Message value.
(4) 分野の残りの値はMessage価値のパラメタコンポーネントから抽出されます。
(5) If the <agentID> field contained in the parameters is unknown then:
(5) パラメタに含まれた<agentID>分野がその時未知であるなら:
- a manager that performs discovery may optionally create a new LCD
entry and continue processing; or
- 発見を実行するマネージャは、任意に新しいLCDエントリーを作成して、処理し続けるかもしれません。 または
- the usecStatsUnknownContexts counter is incremented, a report PDU
is generated, and the received message is discarded without
further processing.
- usecStatsUnknownContextsカウンタは増加されています、そして、レポートPDUは発生しています、そして、受信されたメッセージはさらなる処理なしで捨てられます。
(6) The LCD is consulted for information about the SNMPv2 context
identified by the combination of the <agentID> and
<contextSelector> fields. If information about this SNMPv2 context
is absent from the LCD, then the usecStatsUnknownContexts counter
is incremented, a report PDU is generated, and the received message
is discarded without further processing.
(6) LCDは<agentID>と<contextSelector>分野の組み合わせで特定されたSNMPv2文脈の情報のために相談されます。 このSNMPv2文脈の情報がLCDから欠けるなら、usecStatsUnknownContextsカウンタは増加されています、そして、レポートPDUは発生しています、そして、受信されたメッセージはさらなる処理なしで捨てられます。
(7) Information about the value of the <userName> field is extracted
from the LCD. If no information is available, then the
usecStatsUnknownUserNames counter is incremented, a report PDU [1]
is generated, and the received message is discarded without further
processing.
(7) <userName>分野の値に関する情報はLCDから抜粋されます。 どんな情報も利用可能でないなら、usecStatsUnknownUserNamesカウンタは増加されています、そして、レポートPDU[1]は発生します、そして、受信されたメッセージはさらなる処理なしで捨てられます。
(8) If the information about the user indicates that it does not
support the quality of service indicated by the <qoS> field, then
the usecStatsUnsupportedQoS counter is incremented, a report PDU is
generated, and the received message is discarded without further
processing.
(8) ユーザの情報が、<qoS>分野によって示されたサービスの質を支持しないのを示すなら、usecStatsUnsupportedQoSカウンタは増加されています、そして、レポートPDUは発生します、そして、受信されたメッセージはさらなる処理なしで捨てられます。
Waters Experimental [Page 21] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[21ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
(9) If the <qoS> field indicates an authenticated message and the
user's authentication protocol is the Digest Authentication
Protocol described in this memo, then:
<qoS>分野が認証されたメッセージとユーザの認証プロトコルを示すなら、(9)はこのメモで説明されたDigest Authenticationプロトコルです、そして:
a) the local values of agentBoots and agentTime corresponding to
the value of the <agentID> field are extracted from the LCD.
a) <agentID>分野の値に対応するagentBootsとagentTimeの地方の値はLCDから抽出されます。
b) the value of <authDigest> field is temporarily saved. A new
serialized Message is constructed which differs from that
received in exactly one respect: that the <authDigest> field
within it has the value of the user's authentication key. An
MD5 digest value is computed over the octet sequence
representing the concatenation of the new serialized Message and
the user's authentication key.
b) <authDigest>分野の値は一時節約されます。 まさに1つの点で受け取られたそれと異なっている新しい連載されたMessageは組み立てられます: それの中の<authDigest>分野には、ユーザの認証キーの値があります。 MD5ダイジェスト価値は新しい連載されたMessageとユーザの認証キーの連結を表す八重奏系列に関して計算されます。
c) if the LCD information indicates the SNMPv2 context is of type
local (i.e., an agent), then:
次に、LCD情報がSNMPv2文脈を示すなら、c)はタイプ地方(すなわち、エージェント)のものです:
- if the computed digest differs from the saved authDigest
value, then the usecStatsWrongDigestValues counter is
incremented, a report PDU is generated, and the received
message is discarded without further processing. However, if
the snmpEnableAuthenTraps object [15] is enabled, then the
SNMPv2 entity sends authenticationFailure traps [15] according
to its configuration.
- 計算されたダイジェストが救われたauthDigest値と異なっているなら、usecStatsWrongDigestValuesカウンタは増加されています、そして、レポートPDUは発生します、そして、受信されたメッセージはさらなる処理なしで捨てられます。 しかしながら、snmpEnableAuthenTraps物[15]が可能にされるなら、構成に応じて、SNMPv2実体は罠[15]をauthenticationFailureに送ります。
- if any of the following conditions is true, then the message
is considered to be outside of the Time Window:
- 以下の条件のどれかが本当であるなら、メッセージがタイム・ウィンドウの外にあると考えられます:
- the local value of agentBoots is 0xffffffff;
- agentBootsの地方の値は0xffffffffです。
- the <agentBoots> field differs from the local value of
agentBoots; or,
- <agentBoots>分野はagentBootsの地方の値と異なっています。 または
- the value of the <agentTime> field differs from the local
notion of agentTime by more than +/- 150 seconds.
- <agentTime>分野の値は+/-以上でagentTimeのローカルの概念と150秒異なっています。
- if the message is considered to be outside of the Time Window
then the usecStatsNotInWindows counter is incremented, an
authenticated report PDU is generated (see section 2.7), and
the received message is discarded without further processing.
- メッセージがタイム・ウィンドウの外にあると考えられるなら、usecStatsNotInWindowsカウンタは増加されています、そして、認証されたレポートPDUは発生します、そして、(セクション2.7を見てください)受信されたメッセージはさらなる処理なしで捨てられます。
d) if the LCD information indicates the SNMPv2 context is not
realized by the local SNMPv2 entity (i.e., a manager), then:
LCD情報がSNMPv2文脈を示すなら、地方のSNMPv2実体(すなわち、マネージャ)によってd)は実感されません、そして:
- if the computed digest differs from the saved authDigest
value, then the usecStatsWrongDigestValues counter is
incremented and the received message is discarded without
- 計算されたダイジェストが救われたauthDigest値と異なっているなら、usecStatsWrongDigestValuesカウンタは増加されています、そして、受信されたメッセージなしで捨てられます。
Waters Experimental [Page 22] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[22ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
further processing.
さらなる処理。
- if all of the following conditions are true:
- 以下の条件のすべてが本当であるなら:
- if the <qoS> field indicates that privacy is not in use;
- <qoS>分野が、プライバシーが使用中でないことを示すなら。
- the SNMPv2 operation type determined from the ASN.1 tag
value associated with the PDU's component is a Report;
- PDUのコンポーネントに関連しているASN.1タグ価値から決定するSNMPv2操作タイプはReportです。
- the Report was generated due to a usecStatsNotInWindows
error condition; and,
- ReportはusecStatsNotInWindowsエラー条件のため発生しました。 そして
- the <agentBoots> field is greater than the local value of
agentBoots, or the <agentBoots> field is equal to the
local value of agentBoots and the <agentTime> field is
greater than the value of latestReceivedAgentTime,
- <agentBoots>分野がagentBootsの地方の値より大きいか、<agentBoots>分野がagentBootsの地方の値と等しく、または<agentTime>分野はlatestReceivedAgentTimeの値より大きいです。
then the LCD entry corresponding to the value of the <agentID>
field is updated, by setting the local value of agentBoots
from the <agentBoots> field, the value latestReceivedAgentTime
from the <agentTime> field, and the local value of agentTime
from the <agentTime> field.
次に、<agentID>分野の値に対応するLCDエントリーをアップデートします、<agentTime>分野から<agentBoots>分野からのagentBootsの地方の値、<agentTime>分野からの値のlatestReceivedAgentTime、およびagentTimeの地方の値を設定することによって。
- if any of the following conditions is true, then the message
is considered to be outside of the Time Window:
- 以下の条件のどれかが本当であるなら、メッセージがタイム・ウィンドウの外にあると考えられます:
- the local value of agentBoots is 0xffffffff;
- agentBootsの地方の値は0xffffffffです。
- the <agentBoots> field is less than the local value of
agentBoots; or,
- <agentBoots>分野はagentBootsの地方の値以下です。 または
- the <agentBoots> field is equal to the local value of
agentBoots and the <agentTime> field is more than 150
seconds less than the local notion of agentTime.
- <agentBoots>分野がagentBootsの地方の値と等しく、<agentTime>分野はagentTimeのローカルの概念より150秒以上少ないです。
- if the message is considered to be outside of the Time Window
then the usecStatsNotInWindows counter is incremented, and the
received message is discarded without further processing;
however, time synchronization procedures may be invoked. Note
that this procedure allows for <agentBoots> to be greater than
the local value of agentBoots to allow for received messages
to be accepted as authentic when received from an agent that
has rebooted since the manager last re-synchronized.
- メッセージがタイム・ウィンドウの外にあると考えられるなら、usecStatsNotInWindowsカウンタは増加されています、そして、受信されたメッセージはさらなる処理なしで捨てられます。 しかしながら、時間同期化手順は呼び出されるかもしれません。 この手順が、<agentBoots>がマネージャが最後に再連動して以来リブートしているエージェントから受け取ると考慮するagentBootsの地方の値が正統であるとして認められるべきメッセージを受け取ったよりすばらしいのを許容することに注意してください。
- if at least one of the following conditions is true:
- 少なくとも以下の条件の1つが本当であるなら:
- the <agentBoots> field is greater than the local value of
agentBoots; or,
- <agentBoots>分野はagentBootsの地方の値より大きいです。 または
Waters Experimental [Page 23] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[23ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
- the <agentBoots> field is equal to the local value of
agentBoots and the <agentTime> field is greater than the
value of latestReceivedAgentTime,
- <agentBoots>分野がagentBootsの地方の値と等しく、<agentTime>分野はlatestReceivedAgentTimeの値より大きいです。
then the LCD entry corresponding to the value of the <agentID>
field is updated, by setting the local value of agentBoots
from the <agentBoots> field, the local value
latestReceivedAgentTime from the <agentTime> field, and the
local value of agentTime from the <agentTime> field.
次に、<agentID>分野の値に対応するLCDエントリーをアップデートします、<agentTime>分野から<agentBoots>分野からのagentBootsの地方の値、<agentTime>分野からの地方の値のlatestReceivedAgentTime、およびagentTimeの地方の値を設定することによって。
(10) If the <qoS> field indicates use of a privacy protocol, then the
octet sequence representing the data component is decrypted
according to the user's privacy protocol to obtain a serialized
PDUs value. Otherwise the data component is assumed to directly
contain the PDUs value.
(10) <qoS>分野がプライバシープロトコルの使用を示すなら、ユーザのプライバシープロトコルによると、データ構成要素を表す八重奏系列は、連載されたPDUs値を得るために解読されます。 さもなければ、データ構成要素が直接PDUs値を含むと思われます。
(11) The SNMPv2 operation type is determined from the ASN.1 tag value
associated with the PDUs component.
(11) SNMPv2操作タイプはPDUsの部品に関連しているASN.1タグ価値から決定しています。
(12) If the SNMPv2 operation type is a Report, then the request-id in
the PDU is correlated to an outstanding request, and if the
correlation is successful, the appropriate action is taken (e.g.,
time synchronization, proxy error propagation, etc.); in
particular, if the report PDU indicates a usecStatsNotInWindows
condition, then the outstanding request may be retransmitted (since
the procedure in Step 9d above should have resulted in time
synchronization).
(12) SNMPv2操作タイプがReportであるなら、PDUの要求イドを傑出している要求に関連させます、そして、相関関係がうまくいくなら、適切な行動を取ります(例えば、時間同期化、プロキシ誤り伝播など)。 レポートPDUがusecStatsNotInWindows状態を示すなら、特に、傑出している要求は再送されるかもしれません(Step 9dの上の手順が時間同期化をもたらすべきであったので)。
(13) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or
Set operation, then:
(13) 次に、SNMPv2操作タイプがGet、GetNext、GetBulk、またはSet操作であるなら:
a) if the LCD information indicates that the SNMPv2 context is of
type remote or remote-proxy, then the
usecStatsUnauthorizedOperations counter is incremented, a report
PDU is generated, and the received message is discarded without
further processing.
a) LCD情報が、タイプにはSNMPv2文脈がリモートであるかリモートプロキシであることであるのを示すなら、usecStatsUnauthorizedOperationsカウンタは増加されていて、レポートPDUは発生して、受信されたメッセージはさらなる処理なしで捨てられます。
b) the LCD is consulted for access rights authorized for
communications using the indicated qoS, on behalf of the
indicated user, and concerning management information in the
indicated SNMPv2 context for the particular SNMPv2 operation
type.
b) 特定のSNMPv2操作タイプに示されたSNMPv2文脈で示されたユーザを代表した経営情報に関する示されたqoSを使用することでLCDはコミュニケーションのために認可されたアクセス権のために相談されます。
c) if the SNMPv2 operation type is not among the authorized access
rights, then the usecStatsUnauthorizedOperations counter is
incremented, a report PDU is generated, and the received message
is discarded without further processing.
c) 認可されたアクセス権の中にSNMPv2操作タイプがないなら、usecStatsUnauthorizedOperationsカウンタは増加されていて、レポートPDUは発生して、受信されたメッセージはさらなる処理なしで捨てられます。
Waters Experimental [Page 24] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[24ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
d) The information extracted from the LCD concerning the user and
the SNMPv2 context, together with the sending transport address
of the received message is cached for later use in generating a
response message.
d) ユーザとSNMPv2文脈に関してLCDから抜粋された情報、送付輸送と共に、受信されたメッセージのアドレスは応答メッセージを発生させることにおける後の使用のためにキャッシュされます。
e) if the LCD information indicates the SNMPv2 context is of type
local, then the management operation represented by the PDUs
value is performed by the receiving SNMPv2 entity with respect
to the relevant MIB view within the SNMPv2 context according to
the procedures set forth in [12], where the relevant MIB view is
determined according to the user, the agentID, the
contextSelector, the qoS values and the type of operation
requested.
e) LCD情報が、SNMPv2文脈がタイプ地方のものであることを示すなら、ユーザによると、関連MIB視点が決定している[12]に詳しく説明された手順によると、PDUs値によって表された管理操作はSNMPv2文脈の中で受信SNMPv2実体によって関連MIB視点に関して実行されます、とagentID、contextSelector、qoS値、および操作のタイプは要求しました。
f) if the LCD information indicates the SNMPv2 context is of type
local-proxy, then:
次に、LCD情報がSNMPv2文脈を示すなら、タイプの地元のプロキシにはf)があります:
i. the user, qoS, agentID, contextSelector and transport address
to be used to forward the request are extracted from the LCD.
If insufficient information concerning the user is currently
available, then snmpProxyDrops counter [15] is incremented, a
report PDU is generated, and the received message is
discarded.
i. 要求を転送するのに使用されるべきユーザ、qoS、agentID、contextSelector、および輸送アドレスはLCDから抜粋されます。 ユーザに関する不十分な情報が現在利用可能であるなら、snmpProxyDropsカウンタ[15]は増加されています、そして、レポートPDUは発生します、そして、受信されたメッセージは捨てられます。
ii. if an administrative flag in the LCD indicates that the
message is to be forwarded using the SNMPv1 administrative
framework, then the procedures described in [4] are invoked.
Otherwise, a new SNMPv2 message is constructed: its PDUs
component is copied from that in the received message except
that the contained request-id is replaced by a unique value
(this value will enable a subsequent response message to be
correlated with this request); the <userName>, <qoS>,
<agentID> and <contextSelector> fields are set to the values
extracted from the LCD; the <maxSize> field is set to the
minimum of the value in the received message and the local
system's maximum message size for the transport domain which
will be used to forward the message; and finally, the message
is authenticated and/or protected from disclosure according
to the qoS value.
ii LCDの管理旗が、メッセージがSNMPv1の管理枠組みを使用することで進められることであることを示すなら、[4]で説明された手順は呼び出されます。 さもなければ、新しいSNMPv2メッセージは構成されます: 含まれた要求イドをユニークな値に取り替えるのを除いて(この値は、その後の応答メッセージがこの要求で関連するのを可能にするでしょう)、PDUsの部品は受信されたメッセージにそれからコピーされます。 <userName>、<qoS>、<agentID>、および<contextSelector>分野はLCDから抽出された値に用意ができています。 <maxSize>分野は受信されたメッセージの価値の最小限に設定されます、そして、ローカルのシステムはメッセージを転送するのに使用される輸送ドメインへの最大のメッセージサイズです。 そして、qoS値に従って、メッセージは、公開から最終的に、認証される、そして/または、保護されます。
iii. the information cached in Step 13d above is augmented with
the request-id of the received message as well as the
request-id, agentID and contextSelector of the constructed
message.
iii上のStep 13dでキャッシュされた情報は組み立てられたメッセージの要求イドと同様に受信されたメッセージの要求イド、agentID、およびcontextSelectorと共に増大します。
iv. the constructed message is forwarded to the extracted
transport address.
iv抽出された輸送アドレスに組み立てられたメッセージを転送します。
Waters Experimental [Page 25] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[25ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
(14) If the SNMPv2 operation type is an Inform, then:
(14) 次に、SNMPv2操作タイプがInformであるなら:
a) if the LCD information indicates the SNMPv2 context is of type
local or local-proxy then the usecStatsUnauthorizedOperations
counter is incremented, a report PDU is generated, and the
received message is discarded without further processing.
a) LCD情報が、ローカルの、または、次に、地元のプロキシのタイプにはSNMPv2文脈があるのを示すなら、usecStatsUnauthorizedOperationsカウンタは増加されていて、レポートPDUは発生して、受信されたメッセージはさらなる処理なしで捨てられます。
b) if the LCD information indicates the SNMPv2 context is of type
remote, then the Inform operation represented by the PDUs value
is performed by the receiving SNMPv2 entity according to the
procedures set forth in [12].
b) LCD情報が、SNMPv2文脈がタイプリモートであることを示すなら、[12]に詳しく説明された手順によると、PDUs値によって表されたInform操作は受信SNMPv2実体によって実行されます。
c) if the LCD information indicates the SNMPv2 context is of type
remote-proxy, then:
次に、LCD情報がSNMPv2文脈を示すなら、タイプのリモートプロキシにはc)があります:
i. a single unique request-id is selected for use by all
forwarded copies of this request. This value will enable the
first response message to be correlated with this request;
other responses are not required and should be discarded when
received, since the agent that originated the Inform only
requires one response to its Inform.
i. ただ一つのユニークな要求イドは使用のためにこの要求のすべての進められたコピーによって選択されます。 この値は、最初の応答メッセージがこの要求で関連するのを可能にするでしょう。 他の応答を必要でなく、受け取ると、捨てるべきです、Informを溯源したエージェントがInformへの1つの応答しか必要としないので。
ii. information is extracted from the LCD concerning all
combinations of userName, qoS, agentID, contextSelector and
transport address with which the received message is to be
forwarded.
ii情報は進められる受信されたメッセージがことであるuserName、qoS、agentID、contextSelector、および輸送アドレスのすべての組み合わせに関してLCDから抜粋されます。
iii. for each such combination whose access rights permit Inform
operations to be forwarded, a new SNMPv2 message is
constructed, as follows: its PDUs component is copied from
that in the received message except that the contained
request-id is replaced by the value selected in Step i above;
its <userName>, <qoS>, <agentID> and <contextSelector> fields
are set to the values extracted in Step ii above; and its
<maxSize> field is set to the minimum of the value in the
received message and the local system's maximum message size
for the transport domain which will be used to forward this
message.
iiiアクセス権が、Inform操作が進められることを許可するそのような各組み合わせにおいて、新しいSNMPv2メッセージは構成されます、以下の通りです: 含まれた要求イドを上でStep iで選択された値に取り替えるのを除いて、PDUsの部品は受信されたメッセージにそれからコピーされます。 <userName>、<qoS>、<agentID>、および<contextSelector>分野はStep iiで上に抽出された値に用意ができています。 そして、<maxSize>分野は受信されたメッセージの価値の最小限に設定されます、そして、ローカルのシステムはこのメッセージを転送するのに使用される輸送ドメインへの最大のメッセージサイズです。
iv. for each constructed SNMPv2 message, information concerning
the <userName>, <qoS>, <agentID>, <contextSelector>,
request-id and sending transport address of the received
message, as well as the request- id, agentID and
contextSelector of the constructed message, is cached for
later use in generating a response message.
ivそれぞれの組み立てられたSNMPv2メッセージに関しては、要求イドと同様に受信されたメッセージの<userName>、<qoS>、<agentID>、<contextSelector>、要求イド、および送付輸送アドレスの情報(組み立てられたメッセージのagentIDとcontextSelector)は、応答メッセージを発生させることにおける後の使用のためにキャッシュされます。
v. each constructed message is forwarded to the appropriate
transport address extracted from the LCD in step ii above.
v. ステップiiでLCDから上に抜粋された適切な輸送アドレスにそれぞれの組み立てられたメッセージを転送します。
Waters Experimental [Page 26] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[26ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
(15) If the SNMPv2 operation type is a Response, then:
(15) 次に、SNMPv2操作タイプがResponseであるなら:
a) if the LCD information indicates the SNMPv2 context is of type
local, then the usecStatsUnauthorizedOperations counter is
incremented, a report PDU is generated, and the received message
is discarded without further processing.
a) LCD情報が、SNMPv2文脈がタイプ地方のものであることを示すなら、usecStatsUnauthorizedOperationsカウンタは増加されていて、レポートPDUは発生して、受信されたメッセージはさらなる処理なしで捨てられます。
b) if the LCD information indicates the SNMPv2 context is of type
remote, then the Response operation represented by the PDUs
value is performed by the receiving SNMPv2 entity according to
the procedures set forth in [12].
b) LCD情報が、SNMPv2文脈がタイプリモートであることを示すなら、[12]に詳しく説明された手順によると、PDUs値によって表されたResponse操作は受信SNMPv2実体によって実行されます。
c) if the LCD information indicates the SNMPv2 context is of type
local-proxy or remote-proxy, then:
次に、LCD情報がSNMPv2文脈を示すなら、タイプにはc)が地元のプロキシかリモートプロキシであることであります:
i. the request-id is extracted from the PDUs component of the
received message. The context's agentID and contextSelector
values together with the extracted request-id are used to
correlate this response message to the corresponding values
for a previously forwarded request by inspecting the cache of
information as augmented in Substep iii of Step 13f above or
in Substep iv of 14c above. If no such correlated
information is found, then the received message is discarded
without further processing.
i. 要求イドは受信されたメッセージのPDUsの部品から抜粋されます。 抽出された要求イドに伴う文脈のagentIDとcontextSelector値は、以前に転送された要求のためにこの応答メッセージをSubstepか14cのSubstep ivのStep 13fのSubstep iiiの増大するとしての情報の上のキャッシュを点検することによって換算値に関連させるのに使用されます。 そのような何か関連情報が見つけられないなら、受信されたメッセージはさらなる処理なしで捨てられます。
ii. a new SNMPv2 message is constructed: its PDUs component is
copied from that in the received message except that the
contained request-id is replaced by the value saved in the
correlated information from the original request; its
<userName>, <qoS>, <agentID> and <contextSelector> fields are
set to the values saved from the received message. The
<maxSize> field is set to the minimum of the value in the
received message and the local system's maximum message size
for the transport domain which will be used to forward the
message. The message is authenticated and/or protected from
disclosure according to the saved qoS value.
ii新しいSNMPv2メッセージは構成されます: 含まれた要求イドを関連情報でオリジナルの要求から節約された値に取り替えるのを除いて、PDUsの部品は受信されたメッセージにそれからコピーされます。 <userName>、<qoS>、<agentID>、および<contextSelector>分野は受信されたメッセージから節約された値に用意ができています。 <maxSize>分野は受信されたメッセージの価値の最小限に設定されます、そして、ローカルのシステムはメッセージを転送するのに使用される輸送ドメインへの最大のメッセージサイズです。 救われたqoS値に従って、メッセージは、公開から認証される、そして/または、保護されます。
iii. the constructed message is forwarded to the transport
address saved in the correlated information as the sending
transport address of the original request.
iiiオリジナルの要求の送付輸送アドレスとして関連情報に保存された輸送アドレスに組み立てられたメッセージを転送します。
iv. the correlated information is deleted from the cache of
information.
iv関連情報は情報のキャッシュから削除されます。
(16) If the SNMPv2 operation type is a SNMPv2-Trap, then:
(16) 次に、SNMPv2操作タイプがSNMPv2-罠であるなら:
a) if the LCD information indicates the SNMPv2 context is of type
local or local-proxy, then the usecStatsUnauthorizedOperations
LCD情報がSNMPv2文脈を示すなら、a)はタイプ地方か地元のプロキシのそうであり、その時はusecStatsUnauthorizedOperationsです。
Waters Experimental [Page 27] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[27ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
counter is incremented, a report PDU is generated, and the
received message is discarded without further processing.
カウンタは増加されています、そして、レポートPDUは発生します、そして、受信されたメッセージはさらなる処理なしで捨てられます。
b) if the LCD information indicates the SNMPv2 context is of type
remote, then the SNMPv2-Trap operation represented by the PDUs
value is performed by the receiving SNMPv2 entity according to
the procedures set forth in [12].
b) LCD情報が、SNMPv2文脈がタイプリモートであることを示すなら、[12]に詳しく説明された手順によると、PDUs値によって表されたSNMPv2-罠操作は受信SNMPv2実体によって実行されます。
c) if the LCD information indicates the SNMPv2 context is of type
remote-proxy, then:
次に、LCD情報がSNMPv2文脈を示すなら、タイプのリモートプロキシにはc)があります:
i. a unique request-id is selected for use in forwarding the
message.
i. ユニークな要求イドはメッセージを転送することにおける使用のために選択されます。
ii. information is extracted from the LCD concerning all
combinations of userName, qoS, agentID, contextSelector and
transport address with which the received message is to be
forwarded.
ii情報は進められる受信されたメッセージがことであるuserName、qoS、agentID、contextSelector、および輸送アドレスのすべての組み合わせに関してLCDから抜粋されます。
iii. for each such combination whose access rights permit
SNMPv2-Trap operations to be forwarded, a new SNMPv2 message
is constructed, as follows: its PDUs component is copied from
that in the received message except that the contained
request-id is replaced by the value selected in Step i above;
its <userName>, <qoS>, <agentID> and <contextSelector> fields
are set to the values extracted in Step ii above.
iiiアクセス権が、SNMPv2-罠操作が進められることを許可するそのような各組み合わせにおいて、新しいSNMPv2メッセージは構成されます、以下の通りです: 含まれた要求イドを上でStep iで選択された値に取り替えるのを除いて、PDUsの部品は受信されたメッセージにそれからコピーされます。 <userName>、<qoS>、<agentID>、および<contextSelector>分野はStep iiで上に抽出された値に用意ができています。
iv. each constructed message is forwarded to the appropriate
transport address extracted from the LCD in step ii above.
ivステップiiでLCDから上に抜粋された適切な輸送アドレスにそれぞれの組み立てられたメッセージを転送します。
3.2.1. Additional Details
3.2.1. 追加詳細
For the sake of clarity and to prevent the above procedure from being even longer, the following details were omitted from the above procedure.
明快の目的、上の手順がさらに長いのを防ぐために、以下の詳細は上の手順から省略されました。
3.2.1.1. ASN.1 Parsing Errors
3.2.1.1. ASN.1構文解析誤り
For ASN.1 parsing errors, the snmpInASNParseErrs counter [15] is incremented and a report PDU is generated whenever such an ASN.1 parsing error is discovered. However, if the parsing error causes the information able to be extracted from the message to be insufficient for generating a report PDU, then the report PDU is not sent.
ASN.1構文解析誤りにおいて、snmpInASNParseErrsカウンタ[15]は増加されています、そして、そのようなASN.1構文解析誤りが発見されるときはいつも、レポートPDUは発生します。 しかしながら、構文解析誤りがレポートPDUを発生させるのにおいて不十分になるメッセージから抽出できる情報を引き起こすなら、レポートPDUは送られません。
Waters Experimental [Page 28] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[28ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
3.2.1.2. Incorrectly Encoded Parameters
3.2.1.2. 不当にコード化されたパラメタ
For an incorrectly encoded parameters component of the Message value (e.g., incorrect or inconsistent value of the <userLen> or <authLen> fields), the usecStatsBadParameters counter is incremented. Since the encoded parameters are in error, the report flag in the qoS cannot be reliably determined. Thus, no report PDU is generated for the incorrectly encoded parameters error condition.
Message価値(例えば、<userLen>か<authLen>分野の不正確であるか矛盾した値)の不当にコード化されたパラメタコンポーネントにおいて、usecStatsBadParametersカウンタは増加されています。 コード化されたパラメタが間違っているので、qoSのレポート旗は確かに決定できません。 したがって、レポートPDUは全く不当にコード化されたパラメタエラー条件のために発生しません。
3.2.1.3. Generation of a Report PDU
3.2.1.3. レポートPDUの世代
Some steps specify that the received message is discarded without further processing whenever a report PDU is generated. However:
数ステップは、レポートPDUが発生するときはいつも、受信されたメッセージがさらなる処理なしで捨てられると指定します。 しかしながら:
- An SNMPv2 manager never generates a report PDU.
- SNMPv2マネージャはレポートPDUを決して発生させません。
- If the operation type can reliably be determined and it is
determined to be a Report, SNMPv2-Trap, Inform, or a Response then
a report PDU is not generated.
- 操作タイプが確かに決心できて、それがReport、SNMPv2-罠、Inform、またはResponseであると決心しているなら、レポートPDUは発生しません。
- A report PDU is only generated when the report flag in the qoS is
set to the value 1.
- qoSのレポート旗が値1に設定されるときだけ、レポートPDUは発生します。
A generated report PDU must always use the current values of agentID, agentBoots, and agentTime from the LCD. In addition, a generated report PDU must whenever possible contain the same request-id value as in the PDU contained in the received message. Meeting this constraint normally requires the message to be further processed just enough so as to extract its request-id. There are two situations in which the SNMPv2 request-id cannot be determined. The first situation occurs when the userName is unknown and the qoS indicates that the message is encrypted. The other situation is when there is an ASN.1 parsing error. In cases where the the request-id cannot be determined, the default request-id value 2147483647 is used.
発生しているレポートPDUはLCDからagentID、agentBoots、およびagentTimeの現行価値をいつも使用しなければなりません。 添加、可能であるときはいつも、PDUがそうしなければならない発生しているレポートでは、受信されたメッセージにPDUに含まれているのと同じ要求イド値を含んでください。 通常、この規制を満たすのは要求イドを抜粋するためにさらにちょうど十分処理されるべきメッセージを必要とします。 SNMPv2要求イドが決定できない2つの状況があります。 userNameが未知であり、qoSが、メッセージがコード化されているのを示すとき、最初の状況は起こります。 もう片方の状況はASN.1構文解析誤りがある時です。 要求イドが決定できない場合デフォルト要求イド価値2147483647は使用されています。
3.2.1.4. Cache Timeout
3.2.1.4. キャッシュタイムアウト
Some steps specify that information is cached so that a Response operation may be correlated to the appropriate Request operation. However, a number of situations could cause the cache to grow without bound. One such situation is when the Response operation does not arrive or arrives "late" at the entity. In order to ensure that the cache does not grow without bound, it is recommended that cache entries be deleted when they are determined to be no longer valid. It is an implementation dependent decision as to how long cache entries remain valid, however, caching entries more than 150 seconds is not useful since any use of the cache entry after that time would generate a usecStatsNotInWindows error condition.
数ステップは、情報がResponse操作が適切なRequest操作に関連できるようにキャッシュされると指定します。 しかしながら、多くの状況で、キャッシュはバウンドなしで成長できました。 そのような状況の1つはResponse操作が実体に到着しないか、または「遅く」到着する時です。 キャッシュがバウンドなしで成長しないのを確実にするために、彼らがもう有効にならないように断固としているとき、キャッシュエントリーが削除されるのは、お勧めです。 それがキャッシュエントリーがどれくらい長い間有効なままで残るかに関する実現に依存する決定である、キャッシュエントリーのどんな使用もそれ以後usecStatsNotInWindowsエラー条件を発生させるでしょう、しかしながら、したがって、150秒以上のエントリーをキャッシュするのは役に立ちません。
Waters Experimental [Page 29] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[29ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
3.3. Generating a Response
3.3. 応答を発生させます。
The procedure for generating a response to an SNMPv2 management request is identical to the procedure for transmitting a request (see Section 3.1), with these exceptions:
SNMPv2管理要求への応答を発生させるための手順は要求を伝えるための手順と同じです(セクション3.1を見てください)、これらの例外で:
- The response is sent on behalf of the same user and with the same
value of the agentID and contextSelector as the request.
- 同じユーザを代表した要求としてのagentIDとcontextSelectorの同じ値と共に応答を送ります。
- The PDUs value of the responding Message value is the response
which results from performing the operation specified in the
original PDUs value.
- Messageが評価する応じることのPDUs値は操作を実行するのからの結果が元のPDUs値で指定した応答です。
- The authentication protocol and other relevant information for the
user is obtained, not from the LCD, but rather from information
cached (in Step 13d) when processing the original message.
- ユーザへの認証プロトコルと他の関連情報を得ます、むしろLCDではなく、オリジナルのメッセージを処理するときキャッシュされた(Step 13dで)情報から。
- The serialized Message value is transmitted using any transport
address belonging to the agent for the transport domain from which
the corresponding request originated - even if that is different
from any transport information obtained from the LCD.
- 連載されたMessage値は、それがLCDから得られたどんな輸送情報とも異なっても対応する要求が由来した輸送ドメインにエージェントのものであるどんな輸送アドレスも使用することで送られます。
- If the qoS specifies that the message is to be authenticated or the
response is being generated by a SNMPv2 entity acting in an agent
role, then the current values of agentBoots and agentTime from the
LCD are used. Otherwise, the <agentBoots> and <agentTime> fields
are set to zero-filled octets.
- qoSが、メッセージが認証されることであるまたは応答がエージェントの役割で行動するSNMPv2実体で発生していると指定するなら、LCDからのagentBootsとagentTimeの現行価値は使用されています。 さもなければ、<agentBoots>と<agentTime>分野は無いっぱいにされた八重奏に用意ができています。
- The report flag in the qoS is set to the value 0.
- qoSのレポート旗は値0に設定されます。
4. Discovery
4. 発見
This security model requires that a discovery process obtain sufficient information about an SNMPv2 entity's agent in order to communicate with it. Discovery requires the SNMPv2 manager to learn the agent's agentID value before communication may proceed. This may be accomplished by formulating a get-request communication with the qoS set to noAuth/noPriv, the userName set to "public", the agentID set to all zeros (binary), the contextSelector set to "", and the VarBindList left empty. The response to this message will be an reportPDU that contains the agentID within the <parameters> field (and containing the usecStatsUnknownContexts counter in the VarBindList). If authenticated communication is required then the discovery process may invoke the procedure described in Section 2.7 to synchronize the clocks.
この機密保護モデルは、発見の過程がそれで交信するためにSNMPv2実体のエージェントに関する十分な情報を得るのを必要とします。 コミュニケーションが続くかもしれない前に発見は、SNMPv2マネージャがエージェントのagentID値を学ぶのを必要とします。 これはqoSセットとの要求を得ているコミュニケーションをnoAuth/noPrivに定式化することによって、達成されるかもしれません、「公衆」に用意ができているuserName、すべてのゼロ(バイナリー)に用意ができているagentID、用意ができているcontextSelector、「「そして、空の状態で残っているVarBindList、」 このメッセージへの応答は<パラメタ>分野の中にagentIDを保管しているreportPDUになるでしょう(VarBindListにusecStatsUnknownContextsカウンタを含んでいて)。 認証されたコミュニケーションが必要であるなら、発見の過程は時計を連動させるようにセクション2.7で説明された手順を呼び出すかもしれません。
Waters Experimental [Page 30] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[30ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
5. Definitions
5. 定義
SNMPv2-USEC-MIB DEFINITIONS ::= BEGIN
SNMPv2-USEC-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32,
snmpModules
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
SNMPv2-Tcモジュールコンプライアンス、物グループからの原文のコンベンションのSNMPv2-SMIからSNMPv2-CONFからモジュールアイデンティティ、オブジェクト・タイプ、Counter32、Unsigned32、snmpModulesを輸入します。
usecMIB MODULE-IDENTITY
LAST-UPDATED "9601120000Z"
ORGANIZATION "IETF SNMPv2 Working Group"
CONTACT-INFO
" Glenn W. Waters
usecMIBモジュールアイデンティティは"9601120000Z"組織「IETF SNMPv2作業部会」コンタクトインフォメーション「グレンW.水域」をアップデートしました。
Postal: Bell-Northern Research, Ltd.
P.O. Box 3511, Station C
Ottawa, ON, K1Y 4H7
Canada
郵便: ベル-北研究Ltd.私書箱3511、Cオタワ、オン駅のK1Y 4H7カナダ
Tel: +1 613 763 3933
Tel: +1 613 763 3933
E-mail: gwaters@bnr.ca"
DESCRIPTION
"The MIB module for SNMPv2 entities implementing the user-
based security model."
::= { snmpModules 6 }
メール: " gwaters@bnr.ca "記述、「ユーザを実行するSNMPv2実体のためのMIBモジュールは機密保護モデルを基礎づけました」。 ::= snmpModules6
usecMIBObjects OBJECT IDENTIFIER ::= { usecMIB 1 }
usecMIBObjects物の識別子:、:= usecMIB1
-- Textual Conventions
-- 原文のコンベンション
AgentID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An agent's administratively-unique identifier.
AgentID:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「エージェントの行政上ユニークな識別子。」
The value for this object may not be all zeros or all 'ff'H.
この物のための値はすべてゼロでないかもしれませんすべてが'ff'H'です。
The initial value for this object may be configured via an
operator console entry or via an algorithmic function. In
このオブジェクトのための初期の値はオペレータコンソールエントリーを通ってアルゴリズムの機能で構成されるかもしれません。 コネ
Waters Experimental [Page 31] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[31ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
the later case, the following guidelines are recommended:
後のケースであり、以下のガイドラインはお勧めです:
1) The first four octets are set to the binary equivalent
of the agent's SNMP network management private
enterprise number as assigned by the Internet Assigned
Numbers Authority (IANA). For example, if Acme
Networks has been assigned { enterprises 696 }, the
first four octets would be assigned '000002b8'H.
1) インターネットAssigned民数記Authority(IANA)によって割り当てられるように最初の4つの八重奏がエージェントのSNMPネットワークマネージメント私企業番号の2進の同等物に設定されます。 例えば、Acme Networksが企業696に配属されたなら、'000002b8'H'は最初の4つの八重奏に割り当てられるでしょう。
2) The remaining eight octets are the cookie whose
contents are determined via one or more enterprise-
specific methods. Such methods must be designed so as
to maximize the possibility that the value of this
object will be unique in the agent's administrative
domain. For example, the cookie may be the IP address
of the agent, or the MAC address of one of the
interfaces, with each address suitably padded with
random octets. If multiple methods are defined, then
it is recommended that the cookie be further divided
into one octet that indicates the method being used and
seven octets which are a function of the method."
SYNTAX OCTET STRING (SIZE (12))
2) 残っている8つの八重奏がコンテンツが1つ以上の企業の特定のメソッドで決定しているクッキーです。 このオブジェクトの値がエージェントの管理ドメインでユニークになる可能性を最大にするようにそのようなメソッドを設計しなければなりません。 例えば、クッキーは、エージェントのIPアドレス、またはインタフェースの1つのMACアドレスであるかもしれません、各アドレスが無作為の八重奏で適当に水増しされている状態で。 「複数のメソッドが定義されるなら、クッキーがさらに使用されるメソッドを示す1つの八重奏とメソッドの機能である7つの八重奏に分割されるのは、お勧めです。」 構文八重奏ストリング(サイズ(12))
-- the USEC Basic group -- -- a collection of objects providing basic instrumentation of -- the SNMPv2 entity implementing the user-based security model
-- USEC Basicグループ----オブジェクトの収集、SNMPv2実体がユーザベースの機密保護モデルを実装して、基本的な計装を提供します。
usecAgent OBJECT IDENTIFIER ::= { usecMIBObjects 1 }
usecAgentオブジェクト識別子:、:= usecMIBObjects1
agentID OBJECT-TYPE
SYNTAX AgentID
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The agent's administratively-unique identifier."
::= { usecAgent 1 }
agentID OBJECT-TYPE SYNTAX AgentIDのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「エージェントの行政上ユニークな識別子。」 ::= usecAgent1
agentBoots OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that the agent has re-initialized
itself since its initial configuration."
::= { usecAgent 2 }
agentBoots OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「初期の構成以来エージェントがそれ自体を再初期化しているという回の数。」 ::= usecAgent2
Waters Experimental [Page 32] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[32ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
agentTime OBJECT-TYPE
SYNTAX Unsigned32 (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds since the agent last incremented the
agentBoots object."
::= { usecAgent 3 }
agentTime OBJECT-TYPE SYNTAX Unsigned32(0 .2147483647)UNITSはマックス-ACCESSの書き込み禁止のSTATUSの現在の記述を「後援します」。「エージェントが持続するので、秒数はagentBootsオブジェクトを増加しました」。 ::= usecAgent3
agentSize OBJECT-TYPE
SYNTAX INTEGER (484..65507)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum length in octets of an SNMPv2 message which
this agent will accept using any transport mapping."
::= { usecAgent 4 }
agentSize OBJECT-TYPE SYNTAX INTEGER(484 .65507)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「どんな輸送マッピングも使用するこのエージェントが受け入れるSNMPv2メッセージの八重奏における最大の長さ。」 ::= usecAgent4
-- USEC statistics -- -- a collection of objects providing basic instrumentation of -- the SNMPv2 entity implementing the user-based security model
-- USEC統計----オブジェクトの収集、SNMPv2実体がユーザベースの機密保護モデルを実装して、基本的な計装を提供します。
usecStats OBJECT IDENTIFIER ::= { usecMIBObjects 2 }
usecStatsオブジェクト識別子:、:= usecMIBObjects2
usecStatsUnsupportedQoS OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they requested a quality-of-
service that was unknown to the agent or otherwise
unavailable."
::= { usecStats 1 }
「パケットの総数は-品質を要求したので下げられて、それがサービスでは、エージェントにとって未知である、またはそうでなければ、入手できなかったということであったSNMPv2実体で受けた」usecStatsUnsupportedQoS OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= usecStats1
usecStatsNotInWindows OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they appeared outside of the
agent's window."
::= { usecStats 2 }
「パケットの総数はエージェントの窓の外に現れたので下げられたSNMPv2実体で受けた」usecStatsNotInWindows OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= usecStats2
Waters Experimental [Page 33] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[33ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
usecStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they referenced a user that was
not known to the agent."
::= { usecStats 3 }
「パケットの総数はエージェントにとって知られていなかったユーザに参照をつけたので下げられたSNMPv2実体で受けた」usecStatsUnknownUserNames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= usecStats3
usecStatsWrongDigestValues OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they didn't contain the expected
digest value."
::= { usecStats 4 }
「パケットの総数は予想されたダイジェスト値を含まなかったので下げられたSNMPv2実体で受けた」usecStatsWrongDigestValues OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= usecStats4
usecStatsUnknownContexts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they referenced a context that
was not known to the agent."
::= { usecStats 5 }
「パケットの総数はエージェントにとって知られていなかった文脈に参照をつけたので下げられたSNMPv2実体で受けた」usecStatsUnknownContexts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= usecStats5
usecStatsBadParameters OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because the <parameters> field was
improperly encoded or had invalid syntax."
::= { usecStats 6 }
「パケットの総数は<パラメタ>分野には、不適切にコード化されたか、または無効の構文があったので下げられたSNMPv2実体で受けた」usecStatsBadParameters OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= usecStats6
usecStatsUnauthorizedOperations OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because the PDU type referred to an
operation that is invalid or not authorized."
「パケットの総数はPDUタイプが無効の操作について言及したので下げられたか、または認可されなかったSNMPv2実体で受けた」usecStatsUnauthorizedOperations OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
Waters Experimental [Page 34] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[34ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
::= { usecStats 7 }
::= usecStats7
-- conformance information
-- 順応情報
usecMIBConformance
OBJECT IDENTIFIER ::= { usecMIB 2 }
usecMIBConformanceオブジェクト識別子:、:= usecMIB2
usecMIBCompliances
OBJECT IDENTIFIER ::= { usecMIBConformance 1 }
usecMIBGroups OBJECT IDENTIFIER ::= { usecMIBConformance 2 }
usecMIBCompliancesオブジェクト識別子:、:= usecMIBConformance1usecMIBGroupsオブジェクト識別子:、:= usecMIBConformance2
-- compliance statements
-- 承諾声明
usecMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 USEC model."
MODULE -- this module
MANDATORY-GROUPS { usecBasicGroup,
usecStatsGroup }
::= { usecMIBCompliances 1 }
usecMIBCompliance MODULE-COMPLIANCE STATUSの現在の記述、「SNMPv2 USECモデルを実装するSNMPv2実体のための承諾声明。」 MODULE--、このモジュールMANDATORY-GROUPS、usecBasicGroup、usecStatsGroup:、:= usecMIBCompliances1
-- units of conformance
-- ユニットの順応
usecBasicGroup OBJECT-GROUP
OBJECTS { agentID,
agentBoots,
agentTime,
agentSize }
STATUS current
DESCRIPTION
"A collection of objects providing identification, clocks,
and capabilities of an SNMPv2 entity which implements the
SNMPv2 USEC model."
::= { usecMIBGroups 1 }
usecBasicGroup OBJECT-GROUP OBJECTS、agentID、agentBoots、agentTime、agentSize、STATUSの現在の記述、「識別を提供するオブジェクトの収集、時計、およびSNMPv2 USECを実装するSNMPv2実体の能力はモデル化します」。 ::= usecMIBGroups1
usecStatsGroup OBJECT-GROUP
OBJECTS { usecStatsUnsupportedQoS,
usecStatsNotInWindows,
usecStatsUnknownUserNames,
usecStatsWrongDigestValues,
usecStatsUnknownContexts,
usecStatsBadParameters,
usecStatsUnauthorizedOperations }
usecStatsGroupオブジェクト群対象usecStatsUnsupportedQoS、usecStatsNotInWindows、usecStatsUnknownUserNames、usecStatsWrongDigestValues、usecStatsUnknownContexts、usecStatsBadParameters、usecStatsUnauthorizedOperations
Waters Experimental [Page 35] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[35ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
STATUS current
DESCRIPTION
"A collection of objects providing basic error statistics of
an SNMPv2 entity which implements the SNMPv2 USEC model."
::= { usecMIBGroups 2 }
「オブジェクトがSNMPv2 USECを実装するSNMPv2実体の基本的な誤り統計を提供する収集はモデル化する」STATUSの現在の記述。 ::= usecMIBGroups2
END
終わり
6. Security Considerations
6. セキュリティ問題
6.1. Recommended Practices
6.1. 推奨案
This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo.
このセクションはこのメモで定義されたメカニズムの安全で、有効な操作に貢献する習慣について説明します。
- A management station must discard SNMPv2 responses for which
neither the request-id component nor the represented management
information corresponds to any currently outstanding request.
- 管理局は要求イドコンポーネントも表された経営情報もどんな現在傑出している要求とも食い違っているSNMPv2応答を捨てなければなりません。
Although it would be typical for a management station to do this as
a matter of course, when using these security protocols it is
significant due to the possibility of message duplication
(malicious or otherwise).
管理局が当然のこととしてこれをするのが、典型的でしょうが、これらのセキュリティプロトコルを使用するとき、それはメッセージ複製の可能性のために重要です(悪意があるかそうでない)。
- A management station must generate unpredictable request-ids in
authenticated messages in order to protect against the possibility
of message duplication (malicious or otherwise).
- 管理局は、メッセージ複製(悪意があるかそうでない)の可能性から守るために認証されたメッセージの予測できない要求イドを生成しなければなりません。
- A management station should perform time synchronization using
authenticated messages in order to protect against the possibility
of message duplication (malicious or otherwise).
- 管理局は、メッセージ複製(悪意があるかそうでない)の可能性から守るのに認証されたメッセージを使用することで時間同期化を実行するはずです。
- When sending state altering messages to a managed agent, a
management station should delay sending successive messages to the
managed agent until a positive acknowledgement is received for the
previous message or until the previous message expires.
- 州に管理されたエージェントにメッセージを変更させるとき、管理局は、前のメッセージのために積極的な承認を受けるか、または前のメッセージが期限が切れるまで連続したメッセージを管理されたエージェントに送るのを遅らせるはずです。
No message ordering is imposed by the SNMPv2. Messages may be
received in any order relative to their time of generation and each
will be processed in the ordered received. Note that when an
authenticated message is sent to a managed agent, it will be valid
for a period of time of approximately 150 seconds under normal
circumstances, and is subject to replay during this period.
Indeed, a management station must cope with the loss and re-
ordering of messages resulting from anomalies in the network as a
matter of course.
メッセージ注文はSNMPv2によって課されません。 メッセージは、順不同に彼らの世代の時間に比例して受け取られるかもしれなくて、受けられた注文でそれぞれ処理されるでしょう。 認証されたメッセージを管理されたエージェントに送るとき、この期間、再演するのはしばらく、およそ150秒で通常の状況下で有効であり、受けることがあることに注意してください。 本当に、管理局はネットワークで当然のこととして例外から生じるメッセージの損失と再注文を切り抜けなければなりません。
Waters Experimental [Page 36] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[36ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
However, a managed object, snmpSetSerialNo [15], is specifically
defined for use with SNMPv2 set operations in order to provide a
mechanism to ensure the processing of SNMPv2 messages occurs in a
specific order.
しかしながら、SNMPv2メッセージの処理が特定の順序で起こるのを保証するためにメカニズムを提供して、管理オブジェクト(snmpSetSerialNo[15])は使用のためにSNMPv2集合演算で明確に定義されます。
- The frequency with which the secrets of an SNMPv2 user should be
changed is indirectly related to the frequency of their use.
- 頻度はSNMPv2ユーザの秘密が変えられるべきである間接的に彼らの使用の頻度に関連します。
Protecting the secrets from disclosure is critical to the overall
security of the protocols. Frequent use of a secret provides a
continued source of data that may be useful to a cryptanalyst in
exploiting known or perceived weaknesses in an algorithm. Frequent
changes to the secret avoid this vulnerability.
公開から秘密を保護するのはプロトコルの総合的なセキュリティに重要です。 秘密の頻繁な使用は弱点であると知られているか、または知覚された利用でアルゴリズムで暗号解読者の役に立つかもしれないデータの継続的な源を提供します。 秘密への頻繁な変化はこの脆弱性を避けます。
Changing a secret after each use is generally regarded as the most
secure practice, but a significant amount of overhead may be
associated with that approach.
大部分が習慣を機密保護するとき、秘密を変えるのは使用後その都度一般に見なされますが、かなりの量のオーバーヘッドがそのアプローチに関連しているかもしれません。
Note, too, in a local environment the threat of disclosure may be
less significant, and as such the changing of secrets may be less
frequent. However, when public data networks are the communication
paths, more caution is prudent.
また、地方の環境で公開の脅威がそれほど重要でないかもしれないことに注意してください。そうすれば、そういうものとして、秘密の変化はそれほど頻繁である必要はありません。 しかしながら、公衆データネットワークが通信路であるときに、より多くの警告が慎重です。
6.2. Defining Users
6.2. ユーザを定義します。
The mechanisms defined in this document employ the notion of "users" having access rights. How "users" are defined is subject to the security policy of the network administration. For example, users could be individuals (e.g., "joe" or "jane"), or a particular role (e.g., "operator" or "administrator"), or a combination (e.g., "joe- operator", "jane-operator" or "joe-admin"). Furthermore, a "user" may be a logical entity, such as a manager station application or set of manager station applications, acting on behalf of a individual or role, or set of individuals, or set of roles, including combinations.
メカニズムはこのドキュメント雇用で「ユーザ」にはアクセス権があるという概念を定義しました。 「ユーザ」がどう定義されるかは、ネットワーク管理の安全保障政策を受けることがあります。 例えば、ユーザが個人(例えば、"joe"か"jane")であるかもしれないか特定の役割(例えば、「オペレータ」か「管理者」)、または組み合わせが(例えば、「joeオペレータ」、「jane-オペレータ」または「joe-アドミン」)です。 その上、「ユーザ」は、マネージャステーションアプリケーションのマネージャステーションアプリケーションかセット、個人か役割を代表した芝居、または個人のセットなどの論理的な実体、または役割のセットであるかもしれません、組み合わせを含んでいて。
Appendix A describes an algorithm for mapping a user "password" to a 16 octet value for use as either a user's authentication key or privacy key (or both). Passwords are often generated, remembered, and input by a human. Human-generated passwords may be less than the 16 octets required by the authentication and privacy protocols, and brute force attacks can be quite easy on a relatively short ASCII character set. Therefore, the algorithm is Appendix A performs a transformation on the password. If the Appendix A algorithm is used, agent implementations (and agent configuration applications) must ensure that passwords are at least 8 characters in length.
付録Aは使用のためにユーザの認証キーかプライバシーキー(ともに)のどちらかとしてユーザ「パスワード」を16八重奏価値に写像するためのアルゴリズムを説明します。 パスワードは、人間によってしばしば生成されて、覚えていられて、入力されます。 人間が発生しているパスワードは16の八重奏が認証、プライバシープロトコル、およびブルートフォースアタックで必要とした以下が比較的短いASCII文字の組でかなり簡単である場合があるということであるかもしれません。 したがって、アルゴリズムはAppendix Aがパスワードに変換を実行するということです。 Appendix Aアルゴリズムが使用されているなら、エージェント実装(そして、エージェント構成アプリケーション)は、パスワードが長さが少なくとも8つのキャラクタであることを確実にしなければなりません。
Because the Appendix A algorithm uses such passwords (nearly) directly, it is very important that they not be easily guessed. It
Appendix Aアルゴリズムが(ほとんど)直接そのようなパスワードを使用するので、それらが容易に推測されないのは、非常に重要です。 それ
Waters Experimental [Page 37] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[37ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
is suggested that they be composed of mixed-case alphanumeric and punctuation characters that don't form words or phrases that might be found in a dictionary. Longer passwords improve the security of the system. Users may wish to input multiword phrases to make their password string longer while ensuring that it is memorable.
示される、それ、それら、英数字で複雑なケースで構成されてください。そうすれば、単語を形成しない句読文字か力をある句が中に辞書を設立します。 より長いパスワードはシステムのセキュリティを向上させます。 ユーザは、確実に忘れられなくなるようにしている間、それらのパスワードストリングを作るために、より長い間「マルチ-単語」句を入力したがっているかもしれません。
Note that there is security risk in configuring the same "user" on multiple systems where the same password is used on each system, since the compromise of that user's secrets on one system results in the compromise of that user on all other systems having the same password.
複数のシステムの上で同じ「ユーザ」を構成するのにおいてセキュリティリスクが同じパスワードが各システムの上で使用されるところにあることに注意してください、1台のシステムに関するそのユーザの秘密の感染が同じパスワードを持ちながら他のすべてのシステムの上でそのユーザの感染をもたらすので。
The algorithm in Appendix A avoids this problem by including the agent's agentID value as well as the user's password in the calculation of a user's secrets; this results in the user's secrets being different at different agents; however, if the password is compromised the algorithm in Appendix A is not effective.
Appendix Aのアルゴリズムはユーザの秘密の計算におけるユーザのパスワードと同様にエージェントのagentID値を含んでいることによって、この問題を避けます。 これはユーザの異なったエージェントで異なった秘密をもたらします。 しかしながら、パスワードがAppendixのアルゴリズムであると感染されるなら、Aは有効ではありません。
6.3. Conformance
6.3. 順応
To be termed a "Secure SNMPv2 implementation", an SNMPv2 implementation:
「安全なSNMPv2実装」、SNMPv2実装と呼ばれるために:
- must implement the Digest Authentication Protocol.
- Digest Authenticationがプロトコルであると実装しなければなりません。
- must, to the maximal extent possible, prohibit access to the secret(s) of each user about which it maintains information in a LCD, under all circumstances except as required to generate and/or validate SNMPv2 messages with respect to that user.
- そのユーザに関してSNMPv2メッセージを生成する、そして/または、有効にするために必要に応じてそれがLCDの情報を保守するすべての状況によるそれぞれのユーザの秘密へのアクセスを可能な最大限度の範囲に禁止しなければなりません。
- must implement the SNMPv2 USEC MIB.
- SNMPv2 USEC MIBを実装しなければなりません。
In addition, an SNMPv2 agent must provide initial configuration in accordance with Appendix A.1.
さらに、Appendix A.1に応じて、SNMPv2エージェントは初期の構成を提供しなければなりません。
Implementation of the Symmetric Encryption Protocol is optional.
Symmetric Encryptionプロトコルの実装は任意です。
7. Editor's Address
7. エディタのアドレス
Glenn W. Waters Bell-Northern Research Ltd. P.O. Box 3511, Station C Ottawa, Ontario K1Y 4H7 CA
グレンW.はベル-北研究株式会社私書箱3511、駅のCオタワ、オンタリオK1Y 4H7カリフォルニアに水をまきます。
Phone: +1 613 763 3933 EMail: gwaters@bnr.ca
以下に電話をしてください。 +1 3933年の613 763メール: gwaters@bnr.ca
Waters Experimental [Page 38] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[38ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
8. Acknowledgements
8. 承認
This document is the result of significant work by three major contributors:
このドキュメントは3人の一流の貢献者による重要な仕事の結果です:
Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca)
キースMcCloghrie(シスコシステムズ、 kzm@cisco.com )マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング、 mrose@dbc.mtview.ca.us )グレンW.水域(ベル-北研究株式会社、 gwaters@bnr.ca )
The authors wish to acknowledge James M. Galvin of Trusted Information Systems who contributed significantly to earlier work on which this memo is based, and the general contributions of members of the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov and Steven L. Waldbusser.
作者はこのメモが基づいている前に働くためにかなり貢献したTrusted情報システムのジェームス・M.ガルビン、および特にSNMPv2作業部会、アレックセイ・Y.ロマーノフ、およびスティーブンL.Waldbusserのメンバーの一般的な貢献を承諾したがっています。
A special thanks is extended for the contributions of:
以下の貢献のために特別な感謝を表します。
Uri Blumenthal (IBM)
Shawn Routhier (Epilogue)
Barry Sheehan (IBM)
Bert Wijnen (IBM)
ユリ・ブルーメンソル(IBM)ショーンRouthier(エピローグ)バリトンサックスシーハン(IBM)バートWijnen(IBM)
9. References
9. 参照
[1] McCloghrie, K., Editor, "An Administrative Infrastructure for
SNMPv2", RFC 1909, Cisco Systems, January 1996.
[1]McCloghrie、K.、エディタ、「SNMPv2"のための管理インフラストラクチャ、RFC1909、シスコシステムズ1996年1月。」
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
[2] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
Laboratory for Computer Science, April 1992.
[3] 最もRivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、MITコンピュータサイエンス研究所、4月1992日
[4] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Coexistence between Version 1 and Version 2 of
the Internet-standard Network Management Framework", RFC 1908,
January 1996.
[4] SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「インターネット標準ネットワークマネージメントフレームワークのバージョン1とバージョン2の間の共存」、RFC1908(1996年1月)。
[5] Data Encryption Standard, National Institute of Standards and
Technology. Federal Information Processing Standard (FIPS)
Publication 46-1. Supersedes FIPS Publication 46, (January, 1977;
reaffirmed January, 1988).
[5] データ暗号化規格、米国商務省標準技術局。 連邦情報処理基準(FIPS)公表46-1。 FIPS Publication46、(再び断言された1月、1977年1月;1988)に取って代わります。
[6] Data Encryption Algorithm, American National Standards Institute.
ANSI X3.92-1981, (December, 1980).
[6] データ暗号化アルゴリズム、American National Standards Institut。 ANSI X3.92-1981、(1980年12月。)
Waters Experimental [Page 39] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[39ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
[7] DES Modes of Operation, National Institute of Standards and
Technology. Federal Information Processing Standard (FIPS)
Publication 81, (December, 1980).
[7] DES運転モード、米国商務省標準技術局。 連邦情報処理基準(FIPS)公表81、(1980年12月。)
[8] Data Encryption Algorithm - Modes of Operation, American National
Standards Institute. ANSI X3.106-1983, (May 1983).
[8]データ暗号化アルゴリズム--運転モード、American National Standards Institut。 ANSI X3.106-1983、(1983年5月。)
[9] Guidelines for Implementing and Using the NBS Data Encryption
Standard, National Institute of Standards and Technology. Federal
Information Processing Standard (FIPS) Publication 74, (April,
1981).
[9] NBSデータ暗号化規格、米国商務省標準技術局を実装して、使用するためのガイドライン。 連邦情報処理基準(FIPS)公表74、(1981年4月。)
[10] Validating the Correctness of Hardware Implementations of the NBS
Data Encryption Standard, National Institute of Standards and
Technology. Special Publication 500-20.
[10] NBSデータ暗号化規格のハードウェア実装、米国商務省標準技術局の正当性を有効にすること。 特別な公表500-20。
[11] Maintenance Testing for the Data Encryption Standard, National
Institute of Standards and Technology. Special Publication 500-61,
(August, 1980).
[11] データ暗号化規格がないかどうかテストされるメインテナンス、米国商務省標準技術局。 特別な公表500-61、(1980年8月。)
[12] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S., Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[12] SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.、Waldbusserは「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[13] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[13] SNMPv2作業部会、ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[14] Krawczyk, H., "Keyed-MD5 for Message Authentication", Work in
Progress, IBM, June 1995.
[14] Krawczyk、「通報認証のための合わせられたMD5」であるH.は1995年6月に進歩、IBMで働いています。
[15] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1907
January 1996.
[15] SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための管理情報ベース」、RFC1907 1996年1月。
Waters Experimental [Page 40] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[40ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
APPENDIX A - Installation
付録A--インストール
A.1. Agent Installation Parameters
A.1。 エージェントインストールパラメタ
During installation, an agent is configured with several parameters. These include:
インストールの間、エージェントはいくつかのパラメタによって構成されます。 これらは:
(1) a security posture
(1) 警戒姿勢
The choice of security posture determines the extent of the view
configured for unauthenticated access. One of three possible
choices is selected:
警戒姿勢の選択は非認証されたアクセサリーのために構成された視点の範囲を測定します。 3つの可能な選択の1つは選択されます:
minimum-secure,
semi-secure, or
very-secure.
最小に安全であるか、準安全であるか、または安全ですまさしくその。
(2) one or more transport service addresses
(2) 1つ以上の輸送サービスアドレス
These parameters may be specified explicitly, or they may be
specified implicitly as the same set of network-layer addresses
configured for other uses by the device together with the well-
known transport-layer "port" information for the appropriate
transport domain [13]. The agent listens on each of these
transport service addresses for messages sent on behalf of any user
it knows about.
これらのパラメタが明らかに指定されるかもしれませんか、または同じセットのネットワーク層アドレスが他の用途のために適切な輸送ドメイン[13]のためのよく知られているトランスポート層「ポート」情報と共にデバイスで構成したようにそれらはそれとなく指定されるかもしれません。 エージェントはそれが知っているどんなユーザを代表して送られたメッセージのためのそれぞれのこれらの輸送サービスアドレスで聴きます。
(3) one or more secrets
(3) 1つ以上の秘密
These are the authentication/privacy secrets for the first user to
be configured.
これらは構成されるべき最初のユーザへの認証/プライバシー秘密です。
One way to accomplish this is to have the installer enter a
"password" for each required secret. The password is then
algorithmically converted into the required secret by:
これを達成する1つの方法はインストーラをそれぞれの必要な秘密のための「パスワード」に入らせることです。 そして、パスワードは以下によってalgorithmicallyに必要な秘密に変換されます。
- forming a string of length 1,048,576 octets by repeating the
value of the password as often as necessary, truncating
accordingly, and using the resulting string as the input to the
MD5 algorithm. The resulting digest, termed "digest1", is used in
the next step.
- 必要で、先端を切るのと同じくらい頻繁にそれに従って、パスワードの値を繰り返すことによって一連の長さの104万8576八重奏を形成して、入力としてMD5アルゴリズムに結果として起こるストリングを使用します。 「digest1"は次のステップで使用されている」と呼ばれた結果として起こるダイジェスト。
- a second string of length 44 octets is formed by concatenating
digest1, the agent's agentID value, and digest1. This string is
used as input to the MD5 algorithm. The resulting digest is the
required secret (see Appendix A.2).
- 長さの44八重奏の2番目のストリングは、digest1、エージェントのagentID値、およびdigest1を連結することによって、形成されます。 このストリングはMD5アルゴリズムに入力されるように使用されています。 結果として起こるダイジェストは必要な秘密(Appendix A.2を見る)です。
Waters Experimental [Page 41] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[41ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
With these configured parameters, the agent instantiates the following user, context, views and access rights. This configuration information should be readOnly (persistent).
これらの構成されたパラメタで、エージェントは以下のユーザ、文脈、視点、およびアクセス権を例示します。 この設定情報はreadOnlyであるべきです(永続的な)。
- One user:
- 1人のユーザ:
privacy not supported privacy supported
--------------------- -----------------
<userName> "public" "public"
<authProtocol> Digest Auth. Protocol Digest Auth. Protocol
<authPrivateKey> authentication key authentication key
<privProtocol> none Symmetric Privacy Protocol
<privPrivateKey> -- privacy key
サポートされたプライバシーであることはサポートされなかったプライバシー--------------------- ----------------- <ユーザ名の>の「公共」の「公共」の<authProtocol>はAuthを読みこなします。 ダイジェストAuthについて議定書の中で述べてください。 なにもに<のauthPrivateKeyの>の認証の主要な認証の主要な<privProtocol>について議定書の中で述べてください、Symmetric Privacyプロトコル<privPrivateKey>--、プライバシーキー
- One local context with its <contextSelector> as the empty-string.
- 空のストリングとしての<contextSelector>がある1つのローカルの関係。
- One view for authenticated access:
- 認証されたアクセスのための1つの視点:
- the <all> MIB view is the "internet" subtree.
- すべての>MIBが見る<は「インターネット」下位木です。
- A second view for unauthenticated access. This view is configured
according to the selected security posture. For the "very-secure"
posture:
- 非認証されたアクセサリーのための2番目の視点 選択された警戒姿勢に従って、この視点は構成されます。 「安全まさしくその」姿勢のために:
- the <restricted> MIB view is the union of the "snmp" [15],
"usecAgent" and "usecStats" subtrees.
- 制限された>MIBが見る<は"snmp"[15]、"usecAgent"、および「usecStats」下位木の組合です。
For the "semi-secure" posture:
「準安全な」姿勢のために:
- the <restricted> MIB view is the union of the "snmp" [15],
"usecAgent", "usecStats" and "system" subtrees.
- 制限された>MIBが見る<は"snmp"[15]、"usecAgent"、「usecStats」、および「システム」下位木の組合です。
For the "minimum-secure" posture:
「最小に安全な」姿勢のために:
- the <restricted> MIB view is the "internet" subtree.
- 制限された>MIBが見る<は「インターネット」下位木です。
- Access rights to allow:
- 許容するアクセス権:
- read-only access for unauthenticated messages on behalf of the
user "public" to the <restricted> MIB view of contextSelector
"".
- <へのユーザ「公衆」を代表した非認証されたメッセージのためのリード・オンリー・アクセスがMIBが見るcontextSelectorの>を制限した、「「.」
- read-write access for authenticated but not private messages
on behalf of the user "public" to the <all> MIB view of
contextSelector "".
- <へのユーザ「公衆」を代表した認証されましたが、個人的でないメッセージのためのアクセスにcontextSelectorのすべての>MIB視点を読書して書いてください、「「.」
- if privacy is supported, read-write access for authenticated
and private messages on behalf of the user "public" to the
- プライバシーがサポートされるなら、ユーザ「公衆」を代表した認証されて個人的なメッセージのためのアクセスを読書して書いてください。
Waters Experimental [Page 42] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[42ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
<all> MIB view of contextSelector "".
すべての>MIBが見るcontextSelectorの<、「「.」
A.2. Password to Key Algorithm
A.2。 主要なアルゴリズムへのパスワード
The following code fragment demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key. (The calls to MD5 are as documented in RFC 1321.)
以下のコード断片は認証かプライバシーキーにパスワードを写像するとき使用できる主要なアルゴリズムにパスワードを示します。 (MD5への呼び出しがRFC1321に記録されるようにあります。)
void password_to_key(password, passwordlen, agentID, key)
u_char *password; /* IN */
u_int passwordlen; /* IN */
u_char *agentID; /* IN - pointer to 12 octet long agentID */
u_char *key; /* OUT - caller supplies pointer to 16
octet buffer */ {
MD5_CTX MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;
_主要な(パスワード、passwordlen、agentID、キー)u_炭*パスワードにパスワード_を欠如させてください。 _/*IN*/u int passwordlen。 _/*IN*/u炭*agentID。 /*IN--12八重奏の長いagentID*/u_への指針は*キーを炭にします。 /*OUT、--、訪問者が16八重奏バッファ*/に指針を供給するMD5_CTX MD; u_炭*のcp、パスワード_buf[64]; u_の長いパスワード_インデックス=0; u_の長いカウントは0、iと等しいです。
MD5Init (&MD); /* initialize MD5 */
MD5Init(MD)。 /*はMD5*/を初期化します。
/* loop until we've done 1 Megabyte */
while (count < 1048576) {
cp = password_buf;
for(i = 0; i < 64; i++) {
*cp++ = password[ password_index++ % passwordlen ];
/*
* Take the next byte of the password, wrapping to the
* beginning of the password as necessary.
*/
}
MDupdate (&MD, password_buf, 64);
count += 64;
}
MD5Final (key, &MD); /* tell MD5 we're done */
私たちが(カウント<1048576)である間、1Megabyte*/をするまで、/*は輪にされます。{ cpはパスワード_bufと等しいです。 (i=0。 i<64。 i++){ *cp++はパスワード[+ + パスワード_インデックス%passwordlen]と等しいです。 /**は必要に応じてパスワードの次のバイト、パスワードの*始まりまでのラッピングを取ります。 */、MDupdate、(パスワード_buf、64歳のMD)。 カウント+=64。 } MD5Final(キー、およびMD)。 /*は、*/を私たちにするとMD5に言います。
/* localize the key with the agentID and pass through MD5
to produce final key */
memcpy (password_buf, key, 16);
memcpy (password_buf+16, agentID, 12);
memcpy (password_buf+28, key, 16);
/*は、最終的な主要な*/memcpy(パスワード_buf、キー、16)を生産するためにagentIDと共にキーをローカライズして、MD5を通り抜けます。 memcpy(パスワード_buf+16、agentID、12)。 memcpy(パスワード_buf+28、キー、16)。
MD5Init (&MD);
MDupdate (&MD, password_buf, 44);
MD5Final (key, &MD);
MD5Init(MD)。 MDupdate、(パスワード_buf、44歳のMD)。 MD5Final(キー、およびMD)。
return; }
戻ってください。 }
Waters Experimental [Page 43] RFC 1910 User-based Security Model for SNMPv2 February 1996
SNMPv2 February 1996のために実験的な[43ページ]RFC1910ユーザベースの機密保護モデルに水をやらせます。
A.3. Password to Key Sample
A.3。 主要なサンプルへのパスワード
The following shows a sample output of the password to key algorithm.
サンプルが出力した主要なアルゴリズムへのパスワードの以下のショー。
With a password of "maplesyrup" the output of the password to key algorithm before the key is localized with the agent's agentID is:
"maplesyrup"に関するパスワードで、キーがエージェントのagentIDと共にローカライズされる前に主要なアルゴリズムへのパスワードの出力は以下の通りです。
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
'9f af32 83 88 4e92 83 4e bc98 47d8教育d9 63'H
After the intermediate key (shown above) is localized with the agentID value of:
中間介在物の後に、キー(上では、目立つ)が以下のagentID値でローカライズされます。
'00 00 00 00 00 00 00 00 00 00 00 02'H
'00 00 00 00 00 00 00 00 00 00 00 02'H
the final output of the password to key algorithm is:
主要なアルゴリズムへのパスワードの最終産出物は以下の通りです。
'52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H
52年の6f 5e教育9f cc e2 6f89 64c2 93 07 87d8 2b'H'
Waters Experimental [Page 44]
実験的に、水を飲みます。[44ページ]
一覧
スポンサーリンク
