Network Working Group U. Blumenthal
Request for Comments: 2574 IBM T. J. Watson Research
Obsoletes: 2274 B. Wijnen
Category: Standards Track IBM T. J. Watson Research
April 1999
User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2571]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.
この文書では、SNMPアーキテクチャ[RFC2571]で使用するSNMPバージョン3のためのユーザベースセキュリティモデル（USM）について説明します。これは、SNMPメッセージレベルのセキュリティを提供するための手順の要素を定義します。また、このドキュメントでは、リモートで、このセキュリティモデルの構成パラメータを管理/監視するためのMIBが含まれています。
Table of Contents
目次
1. Introduction 3 1.1. Threats 4 1.2. Goals and Constraints 5 1.3. Security Services 6 1.4. Module Organization 7 1.4.1. Timeliness Module 7 1.4.2. Authentication Protocol 8 1.4.3. Privacy Protocol 8 1.5. Protection against Message Replay, Delay and Redirection 8 1.5.1. Authoritative SNMP engine 8 1.5.2. Mechanisms 9 1.6. Abstract Service Interfaces 10 1.6.1. User-based Security Model Primitives for Authentication 11 1.6.2. User-based Security Model Primitives for Privacy 11 2. Elements of the Model 12 2.1. User-based Security Model Users 12
1.はじめに3 1.1。脅威4 1.2。目標と制約5 1.3。セキュリティサービス6 1.4。モジュール機構7 1.4.1。適時モジュール7 1.4.2。認証プロトコル8 1.4.3。プライバシープロトコル8 1.5。メッセージリプレイ、遅延に対する保護とリダイレクト8 1.5.1。権威SNMPエンジン8 1.5.2。メカニズム9 1.6。抽象サービスインターフェイス10 1.6.1。認証11 1.6.2のためのユーザベースセキュリティモデルプリミティブ。ユーザベースセキュリティモデルプリミティブモデル12 2.1のプライバシー11 2の要素のため。ユーザベースセキュリティモデルのユーザー12
2.2. Replay Protection 13 2.2.1. msgAuthoritativeEngineID 13 2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime14 2.2.3. Time Window 15 2.3. Time Synchronization 15 2.4. SNMP Messages Using this Security Model 16 2.5. Services provided by the User-based Security Model 17 2.5.1. Services for Generating an Outgoing SNMP Message 17 2.5.2. Services for Processing an Incoming SNMP Message 19 2.6. Key Localization Algorithm. 21 3. Elements of Procedure 21 3.1. Generating an Outgoing SNMP Message 22 3.2. Processing an Incoming SNMP Message 25 4. Discovery 30 5. Definitions 31 6. HMAC-MD5-96 Authentication Protocol 50 6.1. Mechanisms 50 6.1.1. Digest Authentication Mechanism 50 6.2. Elements of the Digest Authentication Protocol 51 6.2.1. Users 51 6.2.2. msgAuthoritativeEngineID 51 6.2.3. SNMP Messages Using this Authentication Protocol 51 6.2.4. Services provided by the HMAC-MD5-96 Authentication Module52 6.2.4.1. Services for Generating an Outgoing SNMP Message 52 6.2.4.2. Services for Processing an Incoming SNMP Message 53 6.3. Elements of Procedure 53 6.3.1. Processing an Outgoing Message 54 6.3.2. Processing an Incoming Message 54 7. HMAC-SHA-96 Authentication Protocol 55 7.1. Mechanisms 55 7.1.1. Digest Authentication Mechanism 56 7.2. Elements of the HMAC-SHA-96 Authentication Protocol 56 7.2.1. Users 56 7.2.2. msgAuthoritativeEngineID 57 7.2.3. SNMP Messages Using this Authentication Protocol 57 7.2.4. Services provided by the HMAC-SHA-96 Authentication Module57 7.2.4.1. Services for Generating an Outgoing SNMP Message 57 7.2.4.2. Services for Processing an Incoming SNMP Message 58 7.3. Elements of Procedure 59 7.3.1. Processing an Outgoing Message 59 7.3.2. Processing an Incoming Message 60 8. CBC-DES Symmetric Encryption Protocol 61 8.1. Mechanisms 61 8.1.1. Symmetric Encryption Protocol 61 8.1.1.1. DES key and Initialization Vector. 62 8.1.1.2. Data Encryption. 63 8.1.1.3. Data Decryption 63 8.2. Elements of the DES Privacy Protocol 63
2.2. リプレイ保護13 2.2.1。 13 2.2.2をmsgAuthoritativeEngineID。 msgAuthoritativeEngineBootsとmsgAuthoritativeEngineTime14 2.2.3。タイムウィンドウ15 2.3。時刻同期15 2.4。このセキュリティモデル16 2.5を使用してSNMPメッセージ。ユーザベースセキュリティモデル17 2.5.1によって提供されるサービス。送信SNMPメッセージ17 2.5.2を生成するためのサービス。着信SNMPメッセージ19 2.6を処理するためのサービス。キーローカリゼーションアルゴリズム。手順21 3.1 21の3要素。送信SNMPメッセージ22 3.2を生成します。着信SNMPメッセージ25の4.ディスカバリー30の5.定義31 6 HMAC-MD5-96認証プロトコル50 6.1を処理します。メカニズム50 6.1.1。ダイジェスト認証機構50 6.2。ダイジェスト認証プロトコル51 6.2.1の要素。ユーザー51 6.2.2。 51 6.2.3をmsgAuthoritativeEngineID。この認証プロトコル51 6.2.4を使用してSNMPメッセージ。 HMAC-MD5-96認証Module52 6.2.4.1によって提供されるサービス。送信SNMPメッセージ52 6.2.4.2を生成するためのサービス。着信SNMPメッセージ53 6.3を処理するためのサービス。手順53 6.3.1の要素。送信メッセージ54 6.3.2を処理します。認証プロトコル55 7.1 54 7 HMAC-SHA-96着信メッセージを処理します。メカニズム55 7.1.1。ダイジェスト認証機構56 7.2。 HMAC-SHA-96認証プロトコル56 7.2.1の要素。ユーザー56 7.2.2。 57 7.2.3をmsgAuthoritativeEngineID。この認証プロトコル57 7.2.4を使用してSNMPメッセージ。 HMAC-SHA-96認証Module57 7.2.4.1によって提供されるサービス。送信SNMPメッセージ57 7.2.4.2を生成するためのサービス。着信SNMPメッセージ58 7.3を処理するためのサービス。手順59 7.3.1の要素。送信メッセージ59 7.3.2を処理します。受信メッセージ60 8 CBC-DES対称暗号化プロトコル61 8.1を処理します。メカニズム61 8.1.1。対称暗号化プロトコル61 8.1.1.1。 DESのキーと初期化ベクトル。 62 8.1.1.2。データ暗号化。 63 8.1.1.3。データ復号化63 8.2。 DESプライバシープロトコル63の要素
8.2.1. Users 63 8.2.2. msgAuthoritativeEngineID 64 8.2.3. SNMP Messages Using this Privacy Protocol 64 8.2.4. Services provided by the DES Privacy Module 64 8.2.4.1. Services for Encrypting Outgoing Data 64 8.2.4.2. Services for Decrypting Incoming Data 65 8.3. Elements of Procedure. 66 8.3.1. Processing an Outgoing Message 66 8.3.2. Processing an Incoming Message 66 9. Intellectual Property 67 10. Acknowledgements 67 11. Security Considerations 69 11.1. Recommended Practices 69 11.2. Defining Users 71 11.3. Conformance 72 11.4. Use of Reports 72 11.5. Access to the SNMP-USER-BASED-SM-MIB 72 12. References 73 13. Editors' Addresses 75 A.1. SNMP engine Installation Parameters 76 A.2. Password to Key Algorithm 78 A.2.1. Password to Key Sample Code for MD5 79 A.2.2. Password to Key Sample Code for SHA 80 A.3. Password to Key Sample Results 81 A.3.1. Password to Key Sample Results using MD5 81 A.3.2. Password to Key Sample Results using SHA 81 A.4. Sample encoding of msgSecurityParameters 82 A.5. Sample keyChange Results 83 A.5.1. Sample keyChange Results using MD5 83 A.5.2. Sample keyChange Results using SHA 84 B. Change Log 85 C. Full Copyright Statement 86
8.2.1. ユーザー63 8.2.2。 64 8.2.3をmsgAuthoritativeEngineID。このプライバシープロトコル64 8.2.4を使用してSNMPメッセージ。 DESプライバシーモジュール64 8.2.4.1で提供されるサービス。送信データ64 8.2.4.2を暗号化するためのサービス。着信データ65 8.3を復号化するためのサービス。手順の要素。 66 8.3.1。送信メッセージ66 8.3.2を処理します。着信メッセージ66 9.知的財産67 10.謝辞67 11.セキュリティについての考慮事項69 11.1を処理します。推奨プラクティス69 11.2。ユーザの定義71 11.3。適合性72 11.4。レポート72 11.5の使用。 SNMP-USER-BASED-SM-MIBへのアクセス72 12.参考文献73人の13編集者のアドレス75 A.1。 SNMPエンジンのインストールは76 A.2パラメータ。鍵アルゴリズム78のA.2.1へのパスワード。 MD5 79 A.2.2のキーサンプルコードへのパスワード。 SHA 80 A.3のキーサンプルコードへのパスワード。キーサンプルへのパスワードは81 A.3.1結果。 MD5 81 A.3.2を使用してキーのサンプル結果へのパスワード。 SHA 81 A.4を使用してキーのサンプル結果へのパスワード。 msgSecurityParameters 82 A.5のサンプル・エンコーディング。サンプルてkeyChangeは83 A.5.1結果。 MD5 83 A.5.2を使用してサンプルてkeyChange結果。 SHA 84 B.変更ログ85 C.完全な著作権声明86を使用したサンプルてkeyChange結果
The Architecture for describing Internet Management Frameworks [RFC2571] describes that an SNMP engine is composed of:
インターネット管理フレームワーク[RFC2571]を記述するためのアーキテクチャは、SNMPエンジンが構成されていることを説明します。
1) a Dispatcher 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem.
1）ディスパッチャ2）メッセージ処理サブシステム、3）セキュリティサブシステム、及び4）アクセス制御サブシステム。
Applications make use of the services of these subsystems.
アプリケーションは、これらのサブシステムのサービスを利用します。
It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Security Model described in this document fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC2571].
この文書で説明するセキュリティモデルは、アーキテクチャに適合し、アーキテクチャ内の他のサブシステムと対話するかを理解するためにSNMPアーキテクチャとアーキテクチャの専門用語を理解することが重要です。 [RFC2571]で定義されるように、リーダは、読み取りおよびSNMPアーキテクチャの説明を理解していると予想されます。
This memo [RFC2274] describes the User-based Security Model as it is used within the SNMP Architecture. The main idea is that we use the traditional concept of a user (identified by a userName) with which to associate security information.
それはSNMPアーキテクチャ内で使用されるように、このメモ[RFC2274]はユーザベースセキュリティモデルを記述する。主なアイデアは、我々は、セキュリティ情報を関連付ける（ユーザ名で識別される）は、ユーザーの伝統的な概念を使用することです。
This memo describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the authentication protocols and the use of CBC-DES as the privacy protocol. The User-based Security Model however allows for other such protocols to be used instead of or concurrent with these protocols. Therefore, the description of HMAC-MD5-96, HMAC-SHA-96 and CBC-DES are in separate sections to reflect their self-contained nature and to indicate that they can be replaced or supplemented in the future.
このメモは、認証プロトコルとしてHMAC-MD5-96およびHMAC-SHA-96の使用およびプライバシープロトコルとしてCBC-DESの使用を記載しています。ユーザベースセキュリティモデルは、しかし、代わりに、あるいはこれらのプロトコルと同時に使用する他のそのようなプロトコルが可能になります。したがって、HMAC-MD5-96、HMAC-SHA-96およびCBC-DESの記述は、それらの自己完結型の性質を反映するために、それらが置換または将来的に補うことができることを示すために、別のセクションにあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any SNMP 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.
ネットワークプロトコルへの古典的な脅威のいくつかは、ネットワーク管理の問題に適用可能であり、したがって、任意のSNMPセキュリティモデルに適用可能です。その他の脅威は、ネットワーク管理上の問題には適用されません。このセクションでは、あまり重要である主要な脅威、二次的な脅威、および脅威を論じています。
The principal threats against which this SNMP Security Model should provide protection are:
このSNMPセキュリティモデルは、保護を提供する必要があり、これに対して主要な脅威は以下のとおりです。
- Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object.
- 情報の修正脅威の変更は、オブジェクトの値を改ざんなどの不正な管理操作を、影響するよう、いくつかの不正なエンティティは、このような方法で、許可された元本を代表して生成されたイン・トランジットSNMPメッセージを変更してしまう危険があります。
- 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 Model defined in this memo provides limited protection against:
二つの二次的な脅威も同定されています。このメモで定義されたセキュリティモデルはに対して限られた保護を提供します。
- 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.
- 開示開示の脅威は、管理エージェントと管理局の間の交流の盗聴の危険性があります。この脅威からの保護は、ローカルポリシーの問題として必要になることがあります。
- Message Stream Modification The SNMP protocol is typically based upon a connection-less transport service which may operate over any sub-network service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such sub-network 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 sub-network service, in order to effect unauthorized management operations.
- メッセージストリーム変更ザSNMPプロトコルは、典型的には、任意のサブネットワークサービス上で動作することができるコネクションレス型トランスポート・サービスに基づいています。メッセージの再注文、遅れまたは再生することができますし、そのような多くのサブネットワークサービスの自然な操作で起こるん。メッセージ・ストリーム修正脅威は、メッセージが悪意を持って、再順序付け遅延や不正管理操作を行うために、サブネットワークサービスの自然な操作によって発生する可能性がより大きい程度まで再生されてもよいことは危険です。
There are at least two threats that an SNMP Security Model need not protect against. The security protocols defined in this memo do not provide protection against:
SNMPセキュリティモデルはから保護する必要はありません少なくとも二つの脅威があります。保護を提供していないこのメモで定義されたセキュリティプロトコル：
- Denial of Service This SNMP Security Model does 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. - Traffic Analysis This SNMP Security Model does not attempt to address traffic analysis attacks. Indeed, many traffic patterns are predictable - devices may be managed on a regular basis by a relatively small number of management applications - and therefore there is no significant advantage afforded by protecting against traffic analysis.
- サービスこのSNMPセキュリティモデルの拒否は、許可されたユーザーに代わってサービスが拒否されたことにより、広範囲の攻撃に対処しようとしません。実際、このようなサービス拒否攻撃は、多くの場合、任意の実行可能なネットワーク管理プロトコルは、当然のこととして対処しなければならないとのネットワーク障害の種類と区別できません。 - トラフィック分析このSNMPセキュリティモデルは、トラフィック解析攻撃に対処しようとしません。デバイスは、管理アプリケーションの比較的小さな数で、定期的に管理することができる - - 実際、多くのトラフィックパターンが予測可能であるため、トラフィック解析からの保護によってもたらされる有意な利点がありません。
Based on the foregoing account of threats in the SNMP network management environment, the goals of this SNMP Security Model are as follows.
次のようにSNMPネットワーク管理環境における脅威の以上のアカウントに基づいて、このSNMPセキュリティモデルの目標は。
1) Provide for verification that each received SNMP message has not been modified during its transmission through the network.
1）それぞれがネットワークを介してその送信中に変更されていないSNMPメッセージを受信した検証を提供します。
2) Provide for verification of the identity of the user on whose behalf a received SNMP message claims to have been generated.
2）代行受信したSNMPメッセージが生成されていると主張する上でのユーザの身元の確認のために提供します。
3) Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent.
3）要求したり、その時間世代の最近なかった管理情報を含む受信したSNMPメッセージの検出を提供します。
4) Provide, when necessary, that the contents of each received SNMP message are protected from disclosure.
それぞれの内容はSNMPメッセージを受信したときに必要に応じて、4）提供する開示から保護されます。
In addition to the principal goal of supporting secure network management, the design of this SNMP Security Model is also influenced by the following constraints:
セキュアなネットワーク管理をサポートする主な目的に加えて、このSNMPセキュリティモデルの設計は、以下の制約によって影響されます。
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 management protocols).
2）セキュリティプロトコルもその基礎となるセキュリティメカニズムのいずれもが、他のネットワークサービスの入手しやすさに依存すべきである（例えば、ネットワーク・タイム・プロトコル（NTP）またはキー管理プロトコル）。
3) A security mechanism should entail no changes to the basic SNMP network management philosophy.
3）セキュリティ・メカニズムは、基本的なSNMPネットワーク管理理念への変更を伴うべきではありません。
The security services necessary to support the goals of this SNMP Security Model are as follows:
次のようにこのSNMPセキュリティモデルの目標をサポートするために必要なセキュリティ・サービスは以下のとおりです。
- 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.
- データ発信元認証は、ユーザーの要求されたアイデンティティは、その代わりに、裏付けされた発信されたデータを受信したプロパティを提供することです。
- Data Confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes.
- データの機密性は、情報が利用可能か、権限のない個人、エンティティ、またはプロセスに開示されていないプロパティを提供することです。
- Message timeliness and limited replay protection is the provision of the property that a message whose generation time is outside of a specified time window is not accepted. Note that message reordering is not dealt with and can occur in normal conditions too.
- メッセージの適時性および限られた再生保護が発生時刻指定された時間窓の外にあるメッセージを受け付けていないプロパティを提供することです。そのメッセージの並べ替えは取り扱っておりませんし、あまりにも通常の条件で発生する可能性があります注意してください。
For the protocols specified in this memo, it is not possible to assure the specific originator of a received SNMP message; rather, it is the user on whose behalf the message was originated that is authenticated.
このメモで指定されたプロトコルのために、受信したSNMPメッセージの特定の発信を保証することは不可能です。むしろ、それはその代理としてメッセージが発信されたことが認証されている上のユーザーです。
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.
このメモで使用されるセキュリティプロトコルは、書き込み時に容認できる安全であると考えています。しかし、手続きは必要が生じた場合は、新しい認証とプライバシー方法が将来の時に指定することを可能にします。
The security protocols defined in this memo are split in three different modules and each has its specific responsibilities such that together they realize the goals and security services described above:
このメモで定義されたセキュリティプロトコルは、3つの異なるモジュールに分割され、それぞれが一緒に、彼らは、上記の目標とセキュリティサービスを実現するように、その具体的な役割があります。
- The authentication module MUST provide for:
- 認証モジュールは、のために提供する必要があります。
- Data Integrity,
- データの整合性、
- Data Origin Authentication
- データ発信元認証
- The timeliness module MUST provide for:
- 適時モジュールは、のために提供する必要があります。
- Protection against message delay or replay (to an extent greater than can occur through normal operation)
- （通常の操作を介して起こり得るよりも高い程度に）メッセージ遅延または応答に対する保護
- The privacy module MUST provide for
- プライバシーモジュールは、のために提供しなければなりません
- Protection against disclosure of the message payload.
- メッセージペイロードの開示に対する保護。
The timeliness module is fixed for the User-based Security Model while there is provision for multiple authentication and/or privacy modules, each of which implements a specific authentication or privacy protocol respectively.
それぞれ固有の認証やプライバシープロトコルを実装それぞれが複数の認証および/またはプライバシーモジュールのための規定があるが適時モジュールは、ユーザベースのセキュリティモデルのために固定されています。
Section 3 (Elements of Procedure) uses the timeliness values in an SNMP message to do timeliness checking. The timeliness check is only performed if authentication is applied to the message. Since the complete message is checked for integrity, we can assume that the timeliness values in a message that passes the authentication module are trustworthy.
第3節（手順の要素）が適時チェックを行うにはSNMPメッセージにタイムリー値を使用しています。認証がメッセージに適用された場合に適時チェックのみが行われます。完全なメッセージが整合性をチェックされているので、我々は、認証モジュールを渡すメッセージでタイムリー値が信頼できると仮定することができます。
Section 6 describes the HMAC-MD5-96 authentication protocol which is the first authentication protocol that MUST be supported with the User-based Security Model. Section 7 describes the HMAC-SHA-96 authentication protocol which is another authentication protocol that SHOULD be supported with the User-based Security Model. In the future additional or replacement authentication protocols may be defined as new needs arise.
第6章は、ユーザベースセキュリティモデルをサポートしなければならない最初の認証プロトコルであるHMAC-MD5-96認証プロトコルを記述しています。セクション7は、ユーザベースのセキュリティモデルでサポートされてください別の認証プロトコルであるHMAC-SHA-96認証プロトコルを記述する。新たなニーズが発生したとして、将来的に追加または交換用の認証プロトコルを定義することができます。
The User-based Security Model prescribes that, if authentication is used, then the complete message is checked for integrity in the authentication module.
ユーザベースセキュリティモデルは、認証が使用されている場合は、完全なメッセージは認証モジュールで整合性のためにチェックされている、ことを規定しています。
For a message to be authenticated, it needs to pass authentication check by the authentication module and the timeliness check which is a fixed part of this User-based Security model.
メッセージが認証されるためには、認証モジュールと、このユーザベースのセキュリティモデルの固定部である適時確認して認証チェックを通過する必要があります。
Section 8 describes the CBC-DES Symmetric Encryption Protocol which is the first privacy protocol to be used with the User-based Security Model. In the future additional or replacement privacy protocols may be defined as new needs arise.
第8章は、ユーザベースセキュリティモデルで使用されるべき最初のプライバシープロトコルであるCBC-DES対称暗号化プロトコルを記述しています。新たなニーズが発生したとして将来的には、追加または交換プライバシープロトコルが定義されてもよいです。
The User-based Security Model prescribes that the scopedPDU is protected from disclosure when a message is sent with privacy.
ユーザベースセキュリティモデルは、メッセージがプライバシーを送信されたときscopedPDUには、開示から保護されていることを規定しています。
The User-based Security Model also prescribes that a message needs to be authenticated if privacy is in use.
ユーザベースセキュリティモデルは、メッセージがプライバシーを使用している場合、認証する必要があることを規定しています。
In order to protect against message replay, delay and redirection, one of the SNMP engines involved in each communication is designated to be the authoritative SNMP engine. When an SNMP message contains a payload which expects a response (those messages that contain a Confirmed Class PDU [RFC2571]), then the receiver of such messages is authoritative. When an SNMP message contains a payload which does not expect a response (those messages that contain an Unconfirmed Class PDU [RFC2571]), then the sender of such a message is authoritative.
メッセージ再生、遅延及びリダイレクトを防ぐために、各通信に関与するSNMPエンジンの一つが正式のSNMPエンジンに指定されています。 SNMPメッセージが応答（確認クラスPDU [RFC2571]を含むそれらのメッセージ）を期待するペイロードを含む場合、そのようなメッセージの受信機は、権威あります。 SNMPメッセージが応答（未確認クラスPDU [RFC2571]を含むそれらのメッセージ）を期待していないペイロードを含む場合、そのようなメッセージの送信者は、権威あります。
The following mechanisms are used:
以下のメカニズムが使用されます。
1) To protect against the threat of message delay or replay (to an extent greater than can occur through normal operation), a set of timeliness indicators (for the authoritative SNMP engine) are included in each message generated. An SNMP engine evaluates the timeliness indicators to determine if a received message is recent. An SNMP engine may evaluate the timeliness indicators to ensure that a received message is at least as recent as the last message it received from the same source. A non-authoritative SNMP engine uses received authentic messages to advance its notion of the timeliness indicators at the remote authoritative source.
1））は、通常の操作により発生する可能性がより高い程度にメッセージ遅延または再生（の脅威から保護するために、正式のSNMPエンジンのための適時性インジケータのセットは、（）生成された各メッセージに含まれています。 SNMPエンジンは、受信したメッセージが最近のものであるかどうかを判断するために適時指標を評価します。 SNMPエンジンは、受信したメッセージが、それは同じソースから受け取った最後のメッセージと少なくとも同じ最近のものであることを保証するために、適時性指標を評価することができます。非正式のSNMPエンジンはリモート権威あるソースで適時指標のその概念を進めるために受けた本物のメッセージを使用しています。
An SNMP engine MUST also use a mechanism to match incoming Responses to outstanding Requests and it MUST drop any Responses that do not match an outstanding request. For example, a msgID can be inserted in every message to cater for this functionality.
SNMPエンジンは、未処理の要求への着信応答を一致させるためのメカニズムを使用しなければならないし、それが未処理の要求と一致しない任意の応答を削除する必要があります。例えば、MSGIDは、この機能に対応するためにすべてのメッセージに挿入することができます。
These mechanisms provide for the detection of authenticated messages whose time of generation was not recent.
これらのメカニズムは、時間世代の最近のではなかった認証済みメッセージの検出を提供します。
This protection against the threat of message delay or replay does not imply nor provide any protection against unauthorized deletion or suppression of messages. Also, an SNMP engine may not be able to detect message reordering if all the messages involved are sent within the Time Window interval. 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 [RFC1907]).
メッセージ遅延やリプレイの脅威に対するこの保護は暗示したり不正な削除やメッセージの抑制に対する任意の保護を提供しません。また、SNMPエンジンは、関係するすべてのメッセージがタイムウィンドウ間隔内に送信された場合の並べ替えメッセージを検出できない場合があります。セキュリティプロトコルの独立定義された他の機構も設定操作を含むメッセージの再順序付け再生、削除、または抑制を検出するために使用することができる（例えば、MIB変数snmpSetSerialNo [RFC1907]）。
2) Verification that a message sent to/from one authoritative SNMP engine cannot be replayed to/as-if-from another authoritative SNMP engine.
2）検証1つの正式のSNMPエンジンへ/から送信されたメッセージは、/に再生することができないよう-IF-から別の正式のSNMPエンジン。
Included in each message is an identifier unique to the authoritative SNMP engine associated with the sender or intended recipient of the message.
各メッセージに含まれる送信者又はメッセージの意図された受信者に関連付けられた正式のSNMPエンジンに固有の識別子です。
A message containing an Unconfirmed Class PDU sent by an authoritative SNMP engine to one non-authoritative SNMP engine can potentially be replayed to another non-authoritative SNMP engine. The latter non-authoritative SNMP engine might (if it knows about the same userName with the same secrets at the authoritative SNMP engine) as a result update its notion of timeliness indicators of the authoritative SNMP engine, but that is not considered a threat. In this case, A Report or Response message will be discarded by the Message Processing Model, because there should not be an outstanding Request message. A Trap will possibly be accepted. Again, that is not considered a threat, because the communication was authenticated and timely. It is as if the authoritative SNMP engine was configured to start sending Traps to the second SNMP engine, which theoretically can happen without the knowledge of the second SNMP engine anyway. Anyway, the second SNMP engine may not expect to receive this Trap, but is allowed to see the management information contained in it.
一つの非正式のSNMPエンジンに正式のSNMPエンジンによって送信された未確認クラスPDUを含むメッセージは、潜在的に別の非正式のSNMPエンジンに再生することができます。後者の非正式のSNMPエンジンは、（それが信頼できるSNMPエンジンで同じ秘密と同じユーザ名を知っている場合）、結果として信頼できるSNMPエンジンの適時指標のその概念を更新する可能性がありますが、それは脅威と見なされていません。未処理の要求メッセージがあってはならないので、この場合、Aレポートまたは応答メッセージは、メッセージ処理モデルによって破棄されます。トラップは、おそらく受け入れられます。通信が認証され、タイムリーされたため、再び、それは、脅威と見なされていません。信頼できるSNMPエンジンは理論的にはとにかく二SNMPエンジンの知識がなくても起こることができる二SNMPエンジンへのトラップの送信を開始するように構成されていたかのようにそれはあります。とにかく、二SNMPエンジンは、このトラップを受け取ることを期待していないかもしれないが、それに含まれている管理情報を参照することが許可されています。
3) Detection of messages which were not recently generated.
3）最近生成されなかったメッセージの検出。
A set of time indicators are included in the message, indicating the time of generation. Messages without recent time indicators are not considered authentic. In addition, an SNMP engine MUST drop any Responses that do not match an outstanding request. This however is the responsibility of the Message Processing Model.
時間インジケータのセットを生成する時間を示す、メッセージに含まれています。最近の時間インジケーターのないメッセージは本物とみなされていません。また、SNMPエンジンは、未処理の要求と一致しない任意の応答を削除する必要があります。しかし、これは、メッセージ処理モデルの責任です。
This memo allows the same user to be defined on multiple SNMP engines. Each SNMP engine maintains a value, snmpEngineID, which uniquely identifies the SNMP engine. This value is included in each message sent to/from the SNMP engine that is authoritative (see section 1.5.1). On receipt of a message, an authoritative SNMP engine checks the value to ensure that it is the intended recipient, and a non-authoritative SNMP engine uses the value to ensure that the message is processed using the correct state information.
このメモは、同じユーザーが複数のSNMPエンジン上で定義することができます。各SNMPエンジンは、一意のSNMPエンジンを識別する値、のsnmpEngineIDを維持します。この値は、権限のあるSNMPエンジンから/へ送信される各メッセージに含まれている（セクション1.5.1を参照）。メッセージの受信時に、正式のSNMPエンジンは、それが意図された受取人であることを保証するために値をチェックし、非正式のSNMPエンジンは、メッセージが正しい状態情報を使用して処理されることを保証するために値を使用します。
Each SNMP engine maintains two values, snmpEngineBoots and snmpEngineTime, which taken together provide an indication of time at that SNMP engine. Both of these values are included in an authenticated message sent to/received from that SNMP engine. On receipt, the values are checked to ensure that the indicated timeliness value is within a Time Window of the current time. The Time Window represents an administrative upper bound on acceptable delivery delay for protocol messages.
各SNMPエンジンは、一緒になって2つの値snmpEngineBootsとsnmpEngineTimeは、そのSNMPエンジンで時間の表示を提供維持します。これらの値の両方は、そのSNMPエンジンから受信/に送信され認証されたメッセージに含まれています。受信時に、値が示された適時の値が現在の時刻の時間窓内であることを保証するためにチェックされます。タイムウィンドウは、プロトコルメッセージの許容供給遅延に管理上限を表します。
For an SNMP engine to generate a message which an authoritative SNMP engine will accept as authentic, and to verify that a message received from that authoritative SNMP engine is authentic, such an SNMP engine must first achieve timeliness synchronization with the authoritative SNMP engine. See section 2.3.
SNMPエンジンは、正式のSNMPエンジンが本物受け入れる、その正式のSNMPエンジンから受信したメッセージが本物であることを確認するメッセージを生成するために、そのようなSNMPエンジンは、最初の正式のSNMPエンジンと適時同期を達成しなければなりません。セクション2.3を参照してください。
Abstract service interfaces have been defined to describe the conceptual interfaces between the various subsystems within an SNMP entity. Similarly a set of abstract service interfaces have been defined within the User-based Security Model (USM) to describe the conceptual interfaces between the generic USM services and the self-contained authentication and privacy services.
抽象サービスインターフェースは、SNMPエンティティ内の様々なサブシステム間の概念的なインタフェースを記述するために定義されています。同様に、抽象サービス・インターフェースのセットは、一般的なUSMサービスと自己完結型認証とプライバシーのサービスとの間の概念的なインタフェースを記述するためにユーザベースセキュリティモデル（USM）内で定義されています。
These abstract service interfaces are defined by a set of primitives that define the services provided and the abstract data elements that must be passed when the services are invoked. This section lists the primitives that have been defined for the User-based Security Model.
これらの抽象サービスインタフェースは提供されるサービスとサービスが呼び出されるときに通過しなければならない抽象データ要素を定義するプリミティブのセットによって定義されます。このセクションでは、ユーザベースセキュリティモデルのために定義されているプリミティブを示しています。
The User-based Security Model provides the following internal primitives to pass data back and forth between the Security Model itself and the authentication service:
ユーザベースセキュリティモデルは、セキュリティモデル自体と認証サービスの間で前後にデータを渡すために、次の内部プリミティブを提供します。
statusInformation = authenticateOutgoingMsg( IN authKey -- secret key for authentication IN wholeMsg -- unauthenticated complete message OUT authenticatedWholeMsg -- complete authenticated message )
statusInformationを= authenticateOutgoingMsg（てAuthKey、IN - wholeMsgでの認証用の秘密鍵 - 認証されていない完全なメッセージOUT authenticatedWholeMsg - 完全な認証されたメッセージ）
statusInformation = authenticateIncomingMsg( IN authKey -- secret key for authentication IN authParameters -- as received on the wire IN wholeMsg -- as received on the wire OUT authenticatedWholeMsg -- complete authenticated message )
statusInformationを= authenticateIncomingMsg（てAuthKey、IN - authParametersでの認証用の秘密鍵 - wholeMsgワイヤ上で受信した - authenticatedWholeMsg OUTワイヤ上で受信された - 認証されたメッセージを完了）
The User-based Security Model provides the following internal primitives to pass data back and forth between the Security Model itself and the privacy service:
ユーザベースセキュリティモデルは、セキュリティモデル自体およびプライバシーサービスの間で前後にデータを渡すために、次の内部プリミティブを提供します。
statusInformation = encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU) OUT encryptedData -- encrypted data (encryptedPDU) OUT privParameters -- filled in by service provider )
statusInformationを= encryptData（encryptKey、IN - dataToEncryptにおける暗号化のための秘密鍵 - 暗号化するデータ（scopedPDUに）OUTはEncryptedData - 暗号化されたデータ（encryptedPDU）OUT privParameters - サービスプロバイダーによって記入）
statusInformation = decryptData( IN decryptKey -- secret key for decrypting IN privParameters -- as received on the wire
statusInformationを= decryptData（decryptKey、IN - privParametersにおける復号用の秘密鍵 - ワイヤ上で受信されます
IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) )
EncryptedData IN - 暗号化されたデータ（encryptedPDU）OUT decryptedData - 復号化されたデータ（たscopedPDU））
This section contains definitions required to realize the security model defined by this memo.
このセクションでは、このメモで定義されたセキュリティモデルを実現するために必要な定義が含まれています。
Management operations using this Security Model make use of a defined set of user identities. For any user on whose behalf management operations are authorized at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user.
このセキュリティモデルを使用して管理操作は、ユーザIDの定義されたセットを利用します。その代理として管理業務特定のSNMPエンジンで認可されている上の任意のユーザーのために、そのSNMPエンジンは、そのユーザの知識を持っている必要があります。別のSNMPエンジンと通信したいSNMPエンジンはまた、ユーザの適用可能な属性の知識を含め、そのエンジンに知られているユーザの知識を有していなければなりません。
A user and its attributes are defined as follows:
次のようにユーザーとその属性が定義されています。
userName A string representing the name of the user.
ユーザーの名前を表す文字列をユーザ名。
securityName A human-readable string representing the user in a format that is Security Model independent.
独立したセキュリティモデルのフォーマットでユーザーを表現するのsecurityName判読できる文字列。
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. Two such protocols are defined in this memo:
このユーザーの代わりに送信されるメッセージを認証することができるかどうかの指示をauthProtocol、もしそうであれば、使用する認証プロトコルの種類。二つのそのようなプロトコルはこのメモで定義されています。
- the HMAC-MD5-96 authentication protocol.
- the HMAC-SHA-96 authentication protocol.
authKey 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 authoritative SNMP engines. The authKey is not accessible via SNMP. The length requirements of the authKey are defined by the authProtocol in use.
AuthKeyこのユーザーの代わりに送信されたメッセージは、認証プロトコルで使用するための（プライベート）認証キーを認証することができます。ユーザーの認証キーは、通常、異なる権威SNMPエンジンで異なることに注意してください。 AuthKeyは、SNMP経由でアクセスすることはできません。 AuthKeyの長さの要件は、使用中のauthProtocolによって定義されています。
authKeyChange and authOwnKeyChange The only way to remotely update the authentication key. Does that in a secure manner, so that the update can be completed without the need to employ privacy protection.
authKeyChangeとauthOwnKeyChangeリモートで認証キーを更新する唯一の方法。更新は、プライバシー保護を利用することなく完了することができるように、安全な方法でそれを行います。
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 CBC-DES Symmetric Encryption Protocol.
このユーザーの代わりに送信されたメッセージを開示から保護することができるかどうかの指示をprivProtocol、もしそうであれば、使用されるプライバシープロトコルの種類。そのようなプロトコルの1つは、このメモで定義されています。CBC-DES対称暗号化プロトコル。
privKey If messages sent on behalf of this user can be en/decrypted, the (private) privacy key for use with the privacy protocol. Note that a user's privacy key will normally be different at different authoritative SNMP engines. The privKey is not accessible via SNMP. The length requirements of the privKey are defined by the privProtocol in use.
privKeyこのユーザーの代わりに送信されたメッセージは、EN /復号化し、プライバシープロトコルで使用するための（プライベート）のプライバシーキーすることができます。ユーザーのプライバシーキーが正常に異なる権威SNMPエンジンで異なることに注意してください。 privKeyは、SNMP経由でアクセスすることはできません。 privKeyの長さの要件は、使用中のprivProtocolによって定義されています。
privKeyChange and privOwnKeyChange The only way to remotely update the encryption key. Does that in a secure manner, so that the update can be completed without the need to employ privacy protection.
privKeyChangeとprivOwnKeyChangeリモートで暗号化キーを更新する唯一の方法。更新は、プライバシー保護を利用することなく完了することができるように、安全な方法でそれを行います。
Each SNMP engine maintains three objects:
それぞれのSNMPエンジンは、3つのオブジェクトを維持します。
- snmpEngineID, which (at least within an administrative domain) uniquely and unambiguously identifies an SNMP engine.
- （少なくとも管理ドメイン内で）一意かつ明確SNMPエンジンを特定のsnmpEngineID、。
- snmpEngineBoots, which is a count of the number of times the SNMP engine has re-booted/re-initialized since snmpEngineID was last configured; and,
- 倍のSNMPエンジンが再起動した/再初期化のsnmpEngineIDが最後に設定されてからの数のカウントでsnmpEngineBoots、。そして、
- snmpEngineTime, which is the number of seconds since the snmpEngineBoots counter was last incremented.
- snmpEngineBootsカウンタが最後にインクリメントされてからの秒数でsnmpEngineTime、。
Each SNMP engine is always authoritative with respect to these objects in its own SNMP entity. It is the responsibility of a non-authoritative SNMP engine to synchronize with the authoritative SNMP engine, as appropriate.
それぞれのSNMPエンジンは、独自のSNMPエンティティでこれらのオブジェクトに関して常に権威です。必要に応じて、信頼できるSNMPエンジンと同期する非正式のSNMPエンジンの責任です。
An authoritative SNMP engine is required to maintain the values of its snmpEngineID and snmpEngineBoots in non-volatile storage.
正式のSNMPエンジンは、不揮発性記憶装置にそののsnmpEngineIDとsnmpEngineBootsの値を維持するために必要とされます。
The msgAuthoritativeEngineID value contained in an authenticated message is used to defeat attacks in which messages from one SNMP engine to another SNMP engine are replayed to a different SNMP engine. It represents the snmpEngineID at the authoritative SNMP engine involved in the exchange of the message.
認証されたメッセージに含まmsgAuthoritativeEngineID値が別のSNMPエンジンへの1つのSNMPエンジンからのメッセージが異なるSNMPエンジンに再生された攻撃を破るために使用されます。これは、メッセージの交換にかかわる正式のSNMPエンジンででsnmpEngineIDを表します。
When an authoritative SNMP engine is first installed, it sets its local value of snmpEngineID according to a enterprise-specific algorithm (see the definition of the Textual Convention for SnmpEngineID in the SNMP Architecture document [RFC2571]).
正式のSNMPエンジンが最初にインストールされている場合、それは（SNMPアーキテクチャ文書[RFC2571]でのsnmpEngineIDためのテキストの表記法の定義を参照）企業固有のアルゴリズムに従ってのsnmpEngineIDのローカル値を設定します。
The msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values contained in an authenticated message are used to defeat attacks in which messages are replayed when they are no longer valid. They represent the snmpEngineBoots and snmpEngineTime values at the authoritative SNMP engine involved in the exchange of the message.
認証されたメッセージに含まれるmsgAuthoritativeEngineBootsとmsgAuthoritativeEngineTime値は、それらがもはや有効でときにメッセージが再生されませんした攻撃を打ち負かすために使用されています。彼らは、メッセージの交換にかかわる正式のSNMPエンジンでsnmpEngineBootsとsnmpEngineTime値を表します。
Through use of snmpEngineBoots and snmpEngineTime, there is no requirement for an SNMP engine to have a non-volatile clock which ticks (i.e., increases with the passage of time) even when the SNMP engine is powered off. Rather, each time an SNMP engine re-boots, it retrieves, increments, and then stores snmpEngineBoots in non-volatile storage, and resets snmpEngineTime to zero.
snmpEngineBootsとsnmpEngineTimeの使用を通じて、SNMPエンジンの電源がオフされてもチック不揮発クロックを持っているSNMPエンジンのための要件は、（すなわち、時間の経過とともに増大）がありません。むしろ、各時間SNMPエンジンの再起動は、それが、増分を取得し、不揮発性記憶装置にsnmpEngineBootsを格納し、ゼロにsnmpEngineTimeをリセットします。
When an SNMP engine is first installed, it sets its local values of snmpEngineBoots and snmpEngineTime to zero. If snmpEngineTime ever reaches its maximum value (2147483647), then snmpEngineBoots is incremented as if the SNMP engine has re-booted and snmpEngineTime is reset to zero and starts incrementing again.
SNMPエンジンが最初にインストールされている場合、それはゼロにsnmpEngineBootsとsnmpEngineTimeのローカル値を設定します。 snmpEngineTimeが今までその最大値（2147483647）に達する場合、snmpEngineBootsは、SNMPエンジンが起動再おり、snmpEngineTimeがゼロにリセットされ、再びカウントアップを開始しているかのようにインクリメントされます。
Each time an authoritative SNMP engine re-boots, any SNMP engines holding that authoritative SNMP engine's values of snmpEngineBoots and snmpEngineTime need to re-synchronize prior to sending correctly authenticated messages to that authoritative SNMP engine (see Section 2.3 for (re-)synchronization procedures). Note, however, that the procedures do provide for a notification to be accepted as authentic by a receiving SNMP engine, when sent by an authoritative SNMP engine which has re-booted since the receiving SNMP engine last (re-)synchronized.
たびに信頼できるSNMPエンジンの再起動するには、snmpEngineBootsとsnmpEngineTimeの信頼できるSNMPエンジンの値はその前信頼できるSNMPエンジンに正しく認証されたメッセージを送信するために再同期する必要があることを保持する任意のSNMPエンジンは、（（再）同期の手順については、2.3節を参照してください）。ただし、手順は最後の（再）同期受信SNMPエンジンのために再起動した正式のSNMPエンジンによって送信された場合、受信SNMPエンジンによって本物として受け入れられるための通知を提供しないこと。
If an authoritative SNMP engine is ever unable to determine its latest snmpEngineBoots value, then it must set its snmpEngineBoots value to 2147483647.
正式のSNMPエンジンはこれまで、最新のsnmpEngineBoots値を決定することができない場合、それは2147483647にそのsnmpEngineBoots値を設定する必要があります。
Whenever the local value of snmpEngineBoots has the value 2147483647 it latches at that value and an authenticated message always causes an notInTimeWindow authentication failure.
snmpEngineBootsのローカル値が値2147483647を持っているときはいつでも、それはその値でラッチし、認証されたメッセージは、常にnotInTimeWindow認証の失敗の原因となります。
In order to reset an SNMP engine whose snmpEngineBoots value has reached the value 2147483647, manual intervention is required. The engine must be physically visited and re-configured, either with a new snmpEngineID value, or with new secret values for the authentication and privacy protocols of all users known to that SNMP engine. Note that even if an SNMP engine re-boots once a second that it would still take approximately 68 years before the max value of 2147483647 would be reached.
snmpEngineBoots値値2147483647に達したSNMPエンジンをリセットするためには、手動の介入が必要です。エンジンは、物理的に新しいのsnmpEngineID値を持つ、またはそのSNMPエンジンに知られているすべてのユーザの認証とプライバシープロトコルのための新しい秘密の値のいずれかで、訪問して再構成する必要があります。場合でも、それはまだ2147483647の最大値の前に約68年かかるだろうと二度のSNMPエンジンを再起動するに到達することに注意してください。
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秒は、すべてのユーザーのために使用されていることを指定します。
Time synchronization, required by a non-authoritative SNMP engine in order to proceed with authentic communications, has occurred when the non-authoritative SNMP engine has obtained a local notion of the authoritative SNMP engine's values of snmpEngineBoots and snmpEngineTime from the authoritative SNMP engine. These values must be (and remain) within the authoritative SNMP engine's Time Window. So the local notion of the authoritative SNMP engine's values must be kept loosely synchronized with the values stored at the authoritative SNMP engine. In addition to keeping a local copy of snmpEngineBoots and snmpEngineTime from the authoritative SNMP engine, a non-authoritative SNMP engine must also keep one local variable, latestReceivedEngineTime. This value records the highest value of snmpEngineTime that was received by the non-authoritative SNMP engine from the authoritative SNMP engine and is used to eliminate the possibility of replaying messages that would prevent the non-authoritative SNMP engine's notion of the snmpEngineTime from advancing.
非正式のSNMPエンジンは、信頼できるSNMPエンジンからsnmpEngineBootsとsnmpEngineTimeの信頼できるSNMPエンジンの値のローカルの概念を取得した際に本物のコミュニケーションを進めるために、権限のないSNMPエンジンによって必要な時刻同期は、発生しています。これらの値は、信頼できるSNMPエンジンのタイムウィンドウ内（およびまま）でなければなりません。だから、信頼できるSNMPエンジンの値のローカルの概念は緩く正式のSNMPエンジンに格納された値を使用して同期を維持する必要があります。信頼できるSNMPエンジンからsnmpEngineBootsとsnmpEngineTimeのローカルコピーを維持することに加えて、非正式のSNMPエンジンは、一つのローカル変数、latestReceivedEngineTimeを維持する必要があります。この値は、信頼できるSNMPエンジンから非正式のSNMPエンジンによって受信されたと進行するからsnmpEngineTimeの非正式のSNMPエンジンの概念を妨げるメッセージを再生する可能性を排除するために使用されているsnmpEngineTimeの最高値を記録します。
A non-authoritative SNMP engine must keep local notions of these values (snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime) for each authoritative SNMP engine with which it wishes to communicate. Since each authoritative SNMP engine is uniquely and unambiguously identified by its value of snmpEngineID, the non-authoritative SNMP engine may use this value as a key in order to cache its local notions of these values.
非正式のSNMPエンジンは、それが通信することを希望する各正式のSNMPエンジンのために、これらの値（snmpEngineBoots、snmpEngineTime及びlatestReceivedEngineTime）の局所的な概念を維持しなければなりません。それぞれの正式のSNMPエンジンは、一意かつ明確のsnmpEngineIDのその値によって識別されるので、非正式のSNMPエンジンは、これらの値のローカルの概念をキャッシュするためにキーとしてこの値を使用してもよいです。
Time synchronization occurs as part of the procedures of receiving an SNMP message (Section 3.2, step 7b). As such, no explicit time synchronization procedure is required by a non-authoritative SNMP engine. Note, that whenever the local value of snmpEngineID is changed (e.g., through discovery) or when secure communications are first established with an authoritative SNMP engine, the local values of snmpEngineBoots and latestReceivedEngineTime should be set to zero. This will cause the time synchronization to occur when the next authentic message is received.
時間同期は、SNMPメッセージ（セクション3.2、ステップ7B）を受信する手順の一部として生じます。このように、明示的な時間同期化手順は、非正式のSNMPエンジンによって必要とされません。たびのsnmpEngineIDのローカル値が変更されることに留意されたい（例えば、発見を介して）またはセキュア通信が最初に正式のSNMPエンジンとの間で確立されたとき、snmpEngineBootsとlatestReceivedEngineTimeのローカル値はゼロに設定されるべきです。これは、次の本格的なメッセージを受信したときに時刻同期が発生する原因となります。
The syntax of an SNMP message using this Security Model adheres to the message format defined in the version-specific Message Processing Model document (for example [RFC2572]).
このセキュリティモデルを使用してSNMPメッセージの構文は、バージョン固有のメッセージ処理モデルドキュメント（例えば、[RFC2572]）で定義されたメッセージフォーマットに準拠します。
The field msgSecurityParameters in SNMPv3 messages has a data type of OCTET STRING. Its value is the BER serialization of the following ASN.1 sequence:
SNMPv3メッセージのフィールドMSGセキュリティパラメータは、オクテット文字列のデータ型を持っています。その値は以下のASN.1シーケンスのBERのシリアライゼーションであります：
USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
UsmSecurityParameters ::=
SEQUENCE {
-- global User-based security parameters
msgAuthoritativeEngineID OCTET STRING,
msgAuthoritativeEngineBoots INTEGER (0..2147483647),
msgAuthoritativeEngineTime INTEGER (0..2147483647),
msgUserName OCTET STRING (SIZE(0..32)),
-- authentication protocol specific parameters
msgAuthenticationParameters OCTET STRING,
-- privacy protocol specific parameters
msgPrivacyParameters OCTET STRING
}
END
The fields of this sequence are:
このシーケンスのフィールドは、次のとおりです。
- The msgAuthoritativeEngineID specifies the snmpEngineID of the authoritative SNMP engine involved in the exchange of the message.
- msgAuthoritativeEngineIDは、メッセージの交換にかかわる正式のSNMPエンジンのでsnmpEngineIDを指定します。
- The msgAuthoritativeEngineBoots specifies the snmpEngineBoots value at the authoritative SNMP engine involved in the exchange of the message.
- msgAuthoritativeEngineBootsは、メッセージの交換にかかわる正式のSNMPエンジンでsnmpEngineBoots値を指定します。
- The msgAuthoritativeEngineTime specifies the snmpEngineTime value at the authoritative SNMP engine involved in the exchange of the message.
- msgAuthoritativeEngineTimeは、メッセージの交換にかかわる正式のSNMPエンジンでsnmpEngineTime値を指定します。
- The msgUserName specifies the user (principal) on whose behalf the message is being exchanged. Note that a zero-length userName will not match any user, but it can be used for snmpEngineID discovery.
- msgUserNameメッセージが交換され、その代わりに、ユーザ（プリンシパル）を指定します。長さゼロのユーザ名は、任意のユーザと一致しないであろうが、それはのsnmpEngineID発見のために使用することができることに留意されたいです。
- The msgAuthenticationParameters are defined by the authentication protocol in use for the message, as defined by the usmUserAuthProtocol column in the user's entry in the usmUserTable.
- のusmUserTableにユーザのエントリでusmUserAuthProtocol列によって定義されるようmsgAuthenticationParametersは、メッセージのために使用された認証プロトコルによって定義されます。
- The msgPrivacyParameters are defined by the privacy protocol in use for the message, as defined by the usmUserPrivProtocol column in the user's entry in the usmUserTable).
- のusmUserTableにユーザのエントリでusmUserPrivProtocol列によって定義されるようmsgPrivacyParameters）は、メッセージのために使用中のプライバシープロトコルによって定義されます。
See appendix A.4 for an example of the BER encoding of field msgSecurityParameters.
フィールドmsgSecurityParametersのBERコード化の例については、付録A.4を参照してください。
This section describes the services provided by the User-based Security Model with their inputs and outputs.
このセクションでは、入力と出力とユーザベースセキュリティモデルが提供するサービスについて説明します。
The services are described as primitives of an abstract service interface and the inputs and outputs are described as abstract data elements as they are passed in these abstract service primitives.
サービスは、抽象サービスインタフェースのプリミティブとして記載されており、入力と出力は、彼らがこれらの抽象的なサービスプリミティブに渡される抽象データ要素として記述されています。
When the Message Processing (MP) Subsystem invokes the User-based Security module to secure an outgoing SNMP message, it must use the appropriate service as provided by the Security module. These two services are provided:
メッセージ処理（MP）サブシステムは、発信SNMPメッセージを確保するためにユーザベースセキュリティモジュールを呼び出すと、セキュリティモジュールによって提供されるように、それが適切なサービスを使用する必要があります。これら2つのサービスが提供されています。
1) A service to generate a Request message. The abstract service primitive is:
1）サービス要求メッセージを生成します。原始的な抽象サービスは以下のとおりです。
statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message )
statusInformationを= - 成功またはmessageProcessingModel IN errorIndication generateRequestMsg（ - 典型的には、グローバルデータIN SNMPバージョン - メッセージヘッダー、maxMessageSize IN管理データ - securityModel IN送信SNMPエンティティの - securityEngineID IN発信メッセージのための - 正式のSNMPエンティティセキュリティ名IN - たsecurityLevelこのIN校長に代わって - セキュリティのレベルで要求されたscopedPDU - メッセージ（平文）OUTペイロードsecurityParameters - 生成されたメッセージをOUT完了wholeMsgLength - - 生成されたメッセージの長さはセキュリティモジュールOUT wholeMsgによって記入を）
2) A service to generate a Response message. The abstract service primitive is: statusInformation = -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload IN securityStateReference -- reference to security state -- information from original -- request OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message )
2）サービスは、応答メッセージを生成します。原始的な抽象サービスは次のとおりです。statusInformationを= - グローバルデータに典型的に、SNMPのバージョン - - 成功またはerrorIndication generateResponseMsg（messageProcessingModelのメッセージヘッダ、maxMessageSizeのAdminデータ - securityModelを送ったSNMPエンティティのIN - 送信メッセージについてsecurityEngineID - セキュリティ名で権限SNMPエンティティ - たsecurityLevelこのIN校長に代わって - セキュリティのレベルがたscopedPDUで要求された - securityStateReferenceにメッセージ（平文）ペイロード - セキュリティの状態を参照する - 元からの情報 - securityParametersをOUT要求 - セキュリティモジュールOUT wholeMsgによって記入 - wholeMsgLength生成されたメッセージをOUT完了 - 生成されたメッセージの長さ）
The abstract data elements passed as parameters in the abstract service primitives are as follows:
次のように抽象的サービスプリミティブのパラメータとして渡された抽象データ要素は次のとおりです。
statusInformation An indication of whether the encoding and securing of the message was successful. If not it is an indication of the problem. messageProcessingModel The SNMP version number for the message to be generated. This data is not used by the User-based Security module. globalData The message header (i.e., its administrative information). This data is not used by the User-based Security module. maxMessageSize The maximum message size as included in the message. This data is not used by the User-based Security module. securityParameters These are the security parameters. They will be filled in by the User-based Security module.
メッセージの符号化およびセキュリティ保護が成功したかどうかの表示をステータス情報。そうでない場合には、問題の兆候です。生成されるメッセージのmessageProcessingModel SNMPのバージョン番号。このデータは、ユーザベースセキュリティモジュールで使用されていません。メッセージヘッダ（すなわち、その管理情報）グローバルデータ。このデータは、ユーザベースセキュリティモジュールで使用されていません。メッセージに含まれるメッセージの最大サイズをmaxMessageSize。このデータは、ユーザベースセキュリティモジュールで使用されていません。 securityParametersこれらはセキュリティパラメータです。彼らは、ユーザーベースのセキュリティモジュールによって入力されます。
securityModel The securityModel in use. Should be User-based Security Model. This data is not used by the User-based Security module. securityName Together with the snmpEngineID it identifies a row in the usmUserTable that is to be used for securing the message. The securityName has a format that is independent of the Security Model. In case of a response this parameter is ignored and the value from the cache is used.
使用中のsecurityModelをsecurityModel。ユーザベースセキュリティモデルでなければなりません。このデータは、ユーザベースセキュリティモジュールで使用されていません。それは、メッセージを保護するために使用されることのusmUserTableの行を特定のsnmpEngineIDと一緒のsecurityName。セキュリティ名は、セキュリティモデルとは独立した形式です。応答の場合、このパラメータは無視され、キャッシュからの値が使用されます。
securityLevel The Level of Security from which the User-based Security module determines if the message needs to be protected from disclosure and if the message needs to be authenticated. securityEngineID The snmpEngineID of the authoritative SNMP engine to which a Request message is to be sent. In case of a response it is implied to be the processing SNMP engine's snmpEngineID and so if it is specified, then it is ignored. scopedPDU The message payload. The data is opaque as far as the User-based Security Model is concerned. securityStateReference A handle/reference to cachedSecurityData to be used when securing an outgoing Response message. This is the exact same handle/reference as it was generated by the User-based Security module when processing the incoming Request message to which this is the Response message. wholeMsg The fully encoded and secured message ready for sending on the wire. wholeMsgLength The length of the encoded and secured message (wholeMsg).
メッセージを開示から保護する必要がある場合、メッセージを認証する必要がある場合は、ユーザーベースのセキュリティモジュールが判断し、そこからセキュリティのたsecurityLevelレベル。要求メッセージが送信されるべき正式のSNMPエンジンのsnmpEngineIDをsecurityEngineID。応答の場合には、処理SNMPエンジンのでsnmpEngineIDであることを暗示され、それが指定されている場合はそう、それは無視されます。メッセージペイロードをscopedPDUに。データは限りユーザベースセキュリティモデルに関しては不透明です。発信応答メッセージを固定するときに使用するcachedSecurityDataにsecurityStateReferenceハンドル/参照。これは、応答メッセージであるため、着信要求メッセージを処理するとき、それがユーザベースのセキュリティモジュールによって生成されたので、これは全く同じハンドル/参照です。 wholeMsgワイヤ上で送信するための準備ができて、完全にエンコードされ、固定したメッセージ。 wholeMsgLength符号化および保護されたメッセージ（wholeMsg）の長さ。
Upon completion of the process, the User-based Security module returns statusInformation. If the process was successful, the completed message with privacy and authentication applied if such was requested by the specified securityLevel is returned. If the process was not successful, then an errorIndication is returned.
プロセスが完了すると、ユーザベースセキュリティモジュールはstatusInformationをを返します。プロセスが成功した場合に返されるように指定したsecurityLevelによって要求された場合、プライバシーと認証で完了のメッセージが適用されます。プロセスが成功しなかった場合は、errorIndicationが返されます。
When the Message Processing (MP) Subsystem invokes the User-based Security module to verify proper security of an incoming message, it must use the service provided for an incoming message. The abstract service primitive is:
メッセージ処理（MP）サブシステムは、着信メッセージの適切なセキュリティを確認するために、ユーザベースセキュリティモジュールを呼び出すと、それが入ってくるメッセージのために提供されるサービスを使用する必要があります。原始的な抽象サービスは以下のとおりです。
statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire OUT securityEngineID -- authoritative SNMP entity
statusInformationを= - 受信のための - securityModel IN受信されたメッセージのために - errorIndicationまたは成功 - エラーカウンタOID /値場合messageProcessingModel INエラーprocessIncomingMsg（ - maxMessageSize IN典型的には、SNMPバージョン - securityParameters IN送信SNMPエンティティの信頼できるSNMPエンティティ - たsecurityLevelにメッセージ - セキュリティINのレベルwholeMsg - wholeMsgLengthワイヤ上で受信される - ワイヤーOUT securityEngineID上で受信した長さ
OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU OUT securityStateReference -- reference to security state ) -- information, needed for response
securityName OUT - プリンシパルの識別OUTたscopedPDU、 - メッセージ（平文）ペイロードOUT maxSizeResponseScopedPDU - 応答PDU OUT securityStateReferenceの最大サイズ - セキュリティ状態を参照） - 情報、応答のために必要
The abstract data elements passed as parameters in the abstract service primitives are as follows:
次のように抽象的サービスプリミティブのパラメータとして渡された抽象データ要素は次のとおりです。
statusInformation An indication of whether the process was successful or not. If not, then the statusInformation includes the OID and the value of the error counter that was incremented. messageProcessingModel The SNMP version number as received in the message. This data is not used by the User-based Security module. maxMessageSize The maximum message size as included in the message. The User-based Security module uses this value to calculate the maxSizeResponseScopedPDU. securityParameters These are the security parameters as received in the message. securityModel The securityModel in use. Should be the User-based Security Model. This data is not used by the User-based Security module. securityLevel The Level of Security from which the User-based Security module determines if the message needs to be protected from disclosure and if the message needs to be authenticated. wholeMsg The whole message as it was received. wholeMsgLength The length of the message as it was received (wholeMsg). securityEngineID The snmpEngineID that was extracted from the field msgAuthoritativeEngineID and that was used to lookup the secrets in the usmUserTable. securityName The security name representing the user on whose behalf the message was received. The securityName has a format that is independent of the Security Model. scopedPDU The message payload. The data is opaque as far as the User-based Security Model is concerned.
プロセスが成功したかどうかの表示をステータス情報。そうでない場合には、statusInformationをはOIDとインクリメントされたエラーカウンタの値が含まれています。メッセージで受信したmessageProcessingModel SNMPバージョン番号。このデータは、ユーザベースセキュリティモジュールで使用されていません。メッセージに含まれるメッセージの最大サイズをmaxMessageSize。ユーザベースセキュリティモジュールはmaxSizeResponseScopedPDUを計算し、この値を使用しています。 securityParametersこれらはメッセージで受信したセキュリティパラメータです。使用中のsecurityModelをsecurityModel。ユーザベースセキュリティモデルでなければなりません。このデータは、ユーザベースセキュリティモジュールで使用されていません。メッセージを開示から保護する必要がある場合、メッセージを認証する必要がある場合は、ユーザーベースのセキュリティモジュールが判断し、そこからセキュリティのたsecurityLevelレベル。それを受け取ったとして、メッセージ全体をwholeMsg。 wholeMsgLength、受信したメッセージの長さ（wholeMsg）。フィールドmsgAuthoritativeEngineIDから抽出し、それはのusmUserTableで秘密をルックアップするために使用されたでsnmpEngineIDをsecurityEngineID。代わってメッセージを受信した上でユーザーを表すセキュリティ名をSECURITYNAME。セキュリティ名は、セキュリティモデルとは独立した形式です。メッセージペイロードをscopedPDUに。データは限りユーザベースセキュリティモデルに関しては不透明です。
maxSizeResponseScopedPDU The maximum size of a scopedPDU to be included in a possible Response message. The User-based Security module calculates this size based on the msgMaxSize (as received in the message) and the space required for the message header (including the securityParameters) for such a Response message. securityStateReference A handle/reference to cachedSecurityData to be used when securing an outgoing Response message. When the Message Processing Subsystem calls the User-based Security module to generate a response to this incoming message it must pass this handle/reference.
たscopedPDUのmaxSizeResponseScopedPDU最大サイズは、可能な応答メッセージに含まれます。ユーザーベースのセキュリティモジュールは、応答メッセージをmsgMaxSizeに基づいて、このサイズ（メッセージで受信されるように）と（securityParameters含む）メッセージヘッダに必要なスペースを計算します。発信応答メッセージを固定するときに使用するcachedSecurityDataにsecurityStateReferenceハンドル/参照。メッセージ処理サブシステムは、この受信メッセージへの応答を生成するために、ユーザベースセキュリティモジュールを呼び出すときには、このハンドル/参照を渡す必要があります。
Upon completion of the process, the User-based Security module returns statusInformation and, if the process was successful, the additional data elements for further processing of the message. If the process was not successful, then an errorIndication, possibly with a OID and value pair of an error counter that was incremented.
プロセスが成功した場合は処理が完了すると、ユーザベースのセキュリティモジュールは、メッセージのさらなる処理のために追加のデータ要素をstatusInformationをを返し。プロセスが成功しなかった場合、次にerrorIndication、おそらくインクリメントされたエラーカウンタのOIDと値のペアを持ちます。
A localized key is a secret key shared between a user U and one authoritative SNMP engine E. Even though a user may have only one password and therefore one key for the whole network, the actual secrets shared between the user and each authoritative SNMP engine will be different. This is achieved by key localization [Localized-key].
ローカライズされたキーは、ユーザが一つだけのパスワードと、ネットワーク全体のために、従って一つのキーを有することができるにもかかわらず、ユーザUと一つ正式のSNMPエンジンEとの間で共有される秘密鍵であり、ユーザと各正式のSNMPエンジンであろうとの間で共有実際の秘密異なる。これは、キーのローカライズ[ローカライズされたキー]によって達成されます。
First, if a user uses a password, then the user's password is converted into a key Ku using one of the two algorithms described in Appendices A.2.1 and A.2.2.
ユーザーがパスワードを使用する場合、最初に、そのユーザーのパスワードは、付録A.2.1とA.2.2で説明された2つのアルゴリズムのいずれかを使用して鍵Kuに変換されます。
To convert key Ku into a localized key Kul of user U at the authoritative SNMP engine E, one appends the snmpEngineID of the authoritative SNMP engine to the key Ku and then appends the key Ku to the result, thus enveloping the snmpEngineID within the two copies of user's key Ku. Then one runs a secure hash function (which one depends on the authentication protocol defined for this user U at authoritative SNMP engine E; this document defines two authentication protocols with their associated algorithms based on MD5 and SHA). The output of the hash-function is the localized key Kul for user U at the authoritative SNMP engine E.
一つは鍵Kuに正式のSNMPエンジンのsnmpEngineIDを付加した後、このように二つのコピー内のsnmpEngineIDを包む、結果を鍵Kuを付加し、正式のSNMPエンジンEのユーザUのローカライズキークルに鍵Kuを変換しますユーザーの鍵Kuの。その後、一方は、セキュアハッシュ関数実行（一方は正式のSNMPエンジンEでこのユーザUのために定義された認証プロトコルに依存し、この文書は、MD5とSHAに基づいて、それらの関連するアルゴリズムを用いて2つの認証プロトコルを定義します）。ハッシュ関数の出力は、正式のSNMPエンジンEのユーザUのローカライズキークルであります
This section describes the security related procedures followed by an SNMP engine when processing SNMP messages according to the User-based Security Model.
このセクションでは、ユーザベースセキュリティモデルに応じてSNMPメッセージを処理するときにSNMPエンジンに続いて、セキュリティ関連の手順を説明します。
This section describes the procedure followed by an SNMP engine whenever it generates a message containing a management operation (like a request, a response, a notification, or a report) on behalf of a user, with a particular securityLevel.
このセクションでは、特定たsecurityLevelをユーザに代わって（要求、応答、通知、またはレポートなど）の管理操作を含むメッセージを生成するたびにSNMPエンジンの処理手順を記述しています。
1) a) If any securityStateReference is passed (Response or Report message), then information concerning the user is extracted from the cachedSecurityData. The cachedSecurityData can now be discarded. The securityEngineID is set to the local snmpEngineID. The securityLevel is set to the value specified by the calling module.
任意securityStateReferenceが経過している場合1）a）から（応答またはレポートメッセージ）、ユーザに関するその後の情報はcachedSecurityDataから抽出されます。 cachedSecurityDataは現在、破棄することができます。 securityEngineIDは地元のsnmpEngineIDに設定されています。たsecurityLevelは、呼び出し側のモジュールで指定された値に設定されています。
Otherwise,
そうでなければ、
b) based on the securityName, information concerning the user at the destination snmpEngineID, specified by the securityEngineID, is extracted from the Local Configuration Datastore (LCD, usmUserTable). If information about the user is absent from the LCD, then an error indication (unknownSecurityName) is returned to the calling module.
B）のsecurityNameに基づいて、先のsnmpEngineIDのユーザに関する情報は、securityEngineIDによって指定された、ローカルコンフィギュレーションデータストア（LCD、のusmUserTable）から抽出されます。ユーザに関する情報がLCDに存在しない場合は、エラー表示（unknownSecurityName）は、呼び出し側モジュールに戻されます。
2) If the securityLevel specifies that the message is to be protected from disclosure, but the user does not support both an authentication and a privacy protocol then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module.
2）たsecurityLevelメッセージが漏洩から保護されることを指定し、ユーザが認証した後、メッセージを送信することができないプライバシープロトコルの両方をサポートしていない場合。エラー表示（unsupportedSecurityLevel）を呼ぶモジュールに返します。
3) If the securityLevel specifies that the message is to be authenticated, but the user does not support an authentication protocol, then the message cannot be sent. An error indication (unsupportedSecurityLevel) is returned to the calling module.
たsecurityLevelが、メッセージが認証されることを指定するが、ユーザが認証プロトコルをサポートしていない場合3）、メッセージは送信できません。エラー表示（unsupportedSecurityLevel）を呼ぶモジュールに返します。
4) a) If the securityLevel specifies that the message is to be protected from disclosure, then the octet sequence representing the serialized scopedPDU is encrypted according to the user's privacy protocol. To do so a call is made to the privacy module that implements the user's privacy protocol according to the abstract primitive:
たsecurityLevelが、メッセージが漏洩から保護されることを指定した場合4）A）、次いで、シリアル化されたscopedPDUを表すオクテットシーケンスは、ユーザのプライバシープロトコルに従って暗号化されています。そうするために呼び出しが原始的抽象に応じて、ユーザーのプライバシープロトコルを実装して、プライバシーモジュールに構成されています。
statusInformation = -- success or failure
encryptData(
IN encryptKey -- user's localized privKey
IN dataToEncrypt -- serialized scopedPDU
OUT encryptedData -- serialized encryptedPDU
OUT privParameters -- serialized privacy parameters
)
statusInformation indicates if the encryption process was successful or not. encryptKey the user's localized private privKey is the secret key that can be used by the encryption algorithm. dataToEncrypt the serialized scopedPDU is the data to be encrypted. encryptedData the encryptedPDU represents the encrypted scopedPDU, encoded as an OCTET STRING. privParameters the privacy parameters, encoded as an OCTET STRING.
暗号化プロセスが成功したかどうstatusInformationをを示します。 encryptKeyユーザーのローカライズされたプライベートprivKeyは、暗号化アルゴリズムで使用できる秘密鍵です。 dataToEncryptシリアライズされたscopedPDUは暗号化されるデータです。 EncryptedData encryptedPDUはOCTET STRINGとして符号化された暗号化されたscopedPDUを表します。オクテット文字列としてエンコードされたプライバシーパラメータを、privParameters。
If the privacy module returns failure, then the message cannot be sent and an error indication (encryptionError) is returned to the calling module.
プライバシーモジュールが失敗を返した場合、メッセージは送信できず、エラー表示（encryptionError）を呼ぶモジュールに戻されます。
If the privacy module returns success, then the returned privParameters are put into the msgPrivacyParameters field of the securityParameters and the encryptedPDU serves as the payload of the message being prepared.
プライバシーモジュールが成功を返す場合、返さprivParametersはsecurityParametersのmsgPrivacyParametersフィールドに入れているとencryptedPDUが準備されているメッセージのペイロードとして機能します。
Otherwise,
そうでなければ、
b) If the securityLevel specifies that the message is not to be be protected from disclosure, then a zero-length OCTET STRING is encoded into the msgPrivacyParameters field of the securityParameters and the plaintext scopedPDU serves as the payload of the message being prepared.
B）たsecurityLevelは、メッセージがゼロ長のオクテット列をsecurityParametersのmsgPrivacyParametersフィールドに符号化され、平文たscopedPDUが準備されたメッセージのペイロードとして機能する、本開示から保護されるべきではないことを指定した場合。
5) The securityEngineID is encoded as an OCTET STRING into the msgAuthoritativeEngineID field of the securityParameters. Note that an empty (zero length) securityEngineID is OK for a Request message, because that will cause the remote (authoritative) SNMP engine to return a Report PDU with the proper securityEngineID included in the msgAuthoritativeEngineID in the securityParameters of that returned Report PDU.
5）securityEngineIDはsecurityParametersのmsgAuthoritativeEngineIDフィールドにOCTET STRINGとして符号化されます。それは、そのレポートPDUを返さの適切securityEngineIDと報告PDUを返すリモート（権威）SNMPエンジンはsecurityParametersにmsgAuthoritativeEngineIDに含まれる原因となるので、空（ゼロ長さ）securityEngineID要求メッセージのためのOKであることに留意されたいです。
6) a) If the securityLevel specifies that the message is to be authenticated, then the current values of snmpEngineBoots and snmpEngineTime corresponding to the securityEngineID from the LCD are used.
たsecurityLevelが、メッセージが認証されることを指定した場合6）A）、次いで、LCDからsecurityEngineIDに対応するsnmpEngineBootsとsnmpEngineTimeの現在の値が使用されています。
Otherwise,
そうでなければ、
b) If this is a Response or Report message, then the current value of snmpEngineBoots and snmpEngineTime corresponding to the local snmpEngineID from the LCD are used.
B）これは、使用される応答または報告メッセージ、LCDからのローカルのsnmpEngineIDに対応するsnmpEngineBootsとsnmpEngineTimeの現在値である場合。
Otherwise,
そうでなければ、
c) If this is a Request message, then a zero value is used for both snmpEngineBoots and snmpEngineTime. This zero value gets used if snmpEngineID is empty.
この要求メッセージである場合c）に示すように、ゼロ値がsnmpEngineBootsとsnmpEngineTimeの両方のために使用されます。 snmpEngineIDが空の場合、このゼロ値が使用されます。
The values are encoded as INTEGER respectively into the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields of the securityParameters.
値はmsgAuthoritativeEngineBootsとsecurityParametersのmsgAuthoritativeEngineTimeフィールドにそれぞれINTEGERとしてコード化されます。
7) The userName is encoded as an OCTET STRING into the msgUserName field of the securityParameters.
7）ユーザ名はsecurityParametersのmsgUserNameフィールドにOCTET STRINGとして符号化されます。
8) a) If the securityLevel specifies that the message is to be authenticated, the message is authenticated according to the user's authentication protocol. To do so a call is made to the authentication module that implements the user's authentication protocol according to the abstract service primitive:
たsecurityLevelが、メッセージが認証されることを指定した場合8）a）に示すように、メッセージは、ユーザの認証プロトコルに従って認証されます。そうするために呼び出しが原始的、抽象サービスに応じて、ユーザの認証プロトコルを実装する認証モジュールに構成されています。
statusInformation =
authenticateOutgoingMsg(
IN authKey -- the user's localized authKey
IN wholeMsg -- unauthenticated message
OUT authenticatedWholeMsg -- authenticated complete message
)
statusInformation indicates if authentication was successful or not. authKey the user's localized private authKey is the secret key that can be used by the authentication algorithm. wholeMsg the complete serialized message to be authenticated. authenticatedWholeMsg the same as the input given to the authenticateOutgoingMsg service, but with msgAuthenticationParameters properly filled in.
認証が成功したかどうstatusInformationをを示します。ユーザーのローカライズされたプライベートてAuthKeyてAuthKey認証アルゴリズムで使用できる秘密鍵です。完全なシリアル化されたメッセージは、認証されるwholeMsg。しかし、適切に充填msgAuthenticationParametersと、authenticateOutgoingMsgサービスに与えられる入力と同じauthenticatedWholeMsg。
If the authentication module returns failure, then the message cannot be sent and an error indication (authenticationFailure) is returned to the calling module.
認証モジュールが失敗を返した場合、メッセージは送信できず、エラー表示（のauthenticationFailure）を呼ぶモジュールに戻されます。
If the authentication module returns success, then the msgAuthenticationParameters field is put into the securityParameters and the authenticatedWholeMsg represents the serialization of the authenticated message being prepared.
認証モジュールが成功を返す場合、msgAuthenticationParametersフィールドはsecurityParametersに入れているとauthenticatedWholeMsgが準備されて認証されたメッセージのシリアライズを表します。
Otherwise,
そうでなければ、
b) If the securityLevel specifies that the message is not to be authenticated then a zero-length OCTET STRING is encoded into the msgAuthenticationParameters field of the securityParameters. The wholeMsg is now serialized and then represents the unauthenticated message being prepared.
B）たsecurityLevelメッセージがゼロ長のオクテット列をsecurityParametersのmsgAuthenticationParametersフィールドにエンコードされ、次いで、認証されないことを指定した場合。 wholeMsgは現在シリアル化され、その後、準備されて認証されていないメッセージを表しています。
9) The completed message with its length is returned to the calling module with the statusInformation set to success.
9）その長さと完成したメッセージを成功に設定statusInformationを持つ呼ぶモジュールに返されます。
This section describes the procedure followed by an SNMP engine whenever it receives a message containing a management operation on behalf of a user, with a particular securityLevel.
このセクションでは、特定たsecurityLevelと、ユーザに代わって管理操作を含むメッセージを受信するたびにSNMPエンジンの処理手順を記述しています。
To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message gets discarded, the state information should also be released. Also, an error indication can return an OID and value for an incremented counter and optionally a value for securityLevel, and values for contextEngineID or contextName for the counter. In addition, the securityStateReference data is returned if any such information is available at the point where the error is detected.
手順の要素を簡単にするために、状態情報のリリースは常に明示的に指定されていません。メッセージは破棄されますときの状態情報が利用可能な場合は、原則として、状態情報も解放されなければなりません。また、エラー表示は、カウンタのcontextEngineIDまたはのcontextNameのためのインクリメントカウンタ及び任意たsecurityLevelの値、および値のためのOIDと値を返すことができます。また、securityStateReferenceデータは、任意のそのような情報は、エラーが検出された時点で利用可能である場合に返されます。
1) If the received securityParameters is not the serialization (according to the conventions of [RFC1906]) of an OCTET STRING formatted according to the UsmSecurityParameters defined in section 2.4, then the snmpInASNParseErrs counter [RFC1907] is incremented, and an error indication (parseError) is returned to the calling module. Note that we return without the OID and value of the incremented counter, because in this case there is not enough information to generate a Report PDU.
1）受信securityParametersのシリアル化されていない場合（セクション2.4で定義されたUsmSecurityParametersに従ってフォーマットオクテットストリングのの規則[RFC1906]）によれば、次にsnmpInASNParseErrsカウンタ[RFC1907]インクリメントされ、エラー表示（ParseErrorです）を呼ぶモジュールに返します。この場合にはレポートPDUを生成するのに十分な情報がないため、我々は、インクリメントカウンタのOIDと値なしで返すことに注意してください。
2) The values of the security parameter fields are extracted from the securityParameters. The securityEngineID to be returned to the caller is the value of the msgAuthoritativeEngineID field. The cachedSecurityData is prepared and a securityStateReference is prepared to reference this data. Values to be cached are:
2）セキュリティパラメータフィールドの値はsecurityParametersから抽出されます。呼び出し元に返されるsecurityEngineIDはmsgAuthoritativeEngineIDフィールドの値です。 cachedSecurityDataを用意し、securityStateReferenceは、このデータを参照するために用意されています。キャッシュされる値は次のとおりです。
msgUserName
msgUserName
3) If the value of the msgAuthoritativeEngineID field in the securityParameters is unknown then: a) a non-authoritative SNMP engine that performs discovery may optionally create a new entry in its Local Configuration Datastore (LCD) and continue processing;
3）securityParametersでmsgAuthoritativeEngineIDフィールドの値が不明である場合は、a）必要に応じてそのローカル設定データストア（LCDで新しいエントリを作成）し、処理を継続することができるという発見を行う非正式のSNMPエンジン。
or
または
b) the usmStatsUnknownEngineIDs counter is incremented, and an error indication (unknownEngineID) together with the OID and value of the incremented counter is returned to the calling module.
B）usmStatsUnknownEngineIDsカウンタがインクリメントされ、そして一緒にインクリメントカウンタのOIDと値とのエラー表示（unknownEngineID）は、呼び出し側モジュールに戻されます。
Note in the event that a zero-length, or other illegally sized msgAuthoritativeEngineID is received, b) should be chosen to facilitate engineID discovery. Otherwise the choice between a) and b) is an implementation issue.
ゼロ長た場合には注意し、または他の不正なサイズmsgAuthoritativeEngineIDが受信され、b）のエンジンIDの検出を容易にするように選択されるべきです。それ以外の場合はa）とb）の間の選択は、実装上の問題です。
4) Information about the value of the msgUserName and msgAuthoritativeEngineID fields is extracted from the Local Configuration Datastore (LCD, usmUserTable). If no information is available for the user, then the usmStatsUnknownUserNames counter is incremented and an error indication (unknownSecurityName) together with the OID and value of the incremented counter is returned to the calling module.
4）msgUserNameとmsgAuthoritativeEngineIDフィールドの値に関する情報は、ローカルコンフィギュレーションデータストア（LCD、のusmUserTable）から抽出されます。何の情報がユーザにとって利用可能でない場合、次にusmStatsUnknownUserNamesカウンタがインクリメントされ、エラー表示（unknownSecurityName）一緒にインクリメントカウンタのOIDと値と呼ぶモジュールに戻されます。
5) If the information about the user indicates that it does not support the securityLevel requested by the caller, then the usmStatsUnsupportedSecLevels counter is incremented and an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module.
5）ユーザーに関する情報は、呼び出し側モジュールに戻されたOIDとインクリメントカウンタの値とともに）発呼者、次いでusmStatsUnsupportedSecLevelsカウンタがインクリメントされ、エラー表示（unsupportedSecurityLevelによって要求されたsecurityLevelをサポートしていないことを示す場合。
6) If the securityLevel specifies that the message is to be authenticated, then the message is authenticated according to the user's authentication protocol. To do so a call is made to the authentication module that implements the user's authentication protocol according to the abstract service primitive:
6）たsecurityLevelメッセージは、メッセージがユーザの認証プロトコルに従って認証され、認証されることを指定している場合。そうするために呼び出しが原始的、抽象サービスに応じて、ユーザの認証プロトコルを実装する認証モジュールに構成されています。
statusInformation = -- success or failure
authenticateIncomingMsg(
IN authKey -- the user's localized authKey
IN authParameters -- as received on the wire
IN wholeMsg -- as received on the wire
OUT authenticatedWholeMsg -- checked for authentication
)
statusInformation indicates if authentication was successful or not. authKey the user's localized private authKey is the secret key that can be used by the authentication algorithm. wholeMsg the complete serialized message to be authenticated. authenticatedWholeMsg the same as the input given to the authenticateIncomingMsg service, but after authentication has been checked.
認証が成功したかどうstatusInformationをを示します。ユーザーのローカライズされたプライベートてAuthKeyてAuthKey認証アルゴリズムで使用できる秘密鍵です。完全なシリアル化されたメッセージは、認証されるwholeMsg。 authenticateIncomingMsgサービスに与えられた入力と同じauthenticatedWholeMsgが、認証後にチェックされています。
If the authentication module returns failure, then the message cannot be trusted, so the usmStatsWrongDigests counter is incremented and an error indication (authenticationFailure) together with the OID and value of the incremented counter is returned to the calling module.
認証モジュールが失敗を返す場合usmStatsWrongDigestsカウンタがインクリメントされ、一緒にインクリメントカウンタのOIDと値とのエラー表示（のauthenticationFailure）を呼ぶモジュールに戻されるように、メッセージは、信頼することができません。
If the authentication module returns success, then the message is authentic and can be trusted so processing continues.
認証モジュールが成功を返した場合、メッセージは本物であると、処理は継続して信頼することができます。
7) If the securityLevel indicates an authenticated message, then the local values of snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime corresponding to the value of the msgAuthoritativeEngineID field are extracted from the Local Configuration Datastore.
たsecurityLevelが認証されたメッセージを示している場合7）、次いでmsgAuthoritativeEngineIDフィールドの値に対応するsnmpEngineBoots、snmpEngineTimeとlatestReceivedEngineTimeのローカル値は、ローカルコンフィギュレーションデータストアから抽出されます。
a) If the extracted value of msgAuthoritativeEngineID is the
same as the value of snmpEngineID of the processing SNMP
engine (meaning this is the authoritative SNMP engine),
then if any of the following conditions is true, then the
message is considered to be outside of the Time Window:
- the local value of snmpEngineBoots is 2147483647;
- snmpEngineBootsの局所的な値は2147483647です。
- the value of the msgAuthoritativeEngineBoots field differs from the local value of snmpEngineBoots; or,
- msgAuthoritativeEngineBootsフィールドの値はsnmpEngineBootsのローカル値とは異なります。または、
- the value of the msgAuthoritativeEngineTime field differs from the local notion of snmpEngineTime by more than +/- 150 seconds.
- msgAuthoritativeEngineTimeフィールドの値を超える+/- 150秒でsnmpEngineTimeのローカルの概念とは異なります。
If the message is considered to be outside of the Time Window then the usmStatsNotInTimeWindows counter is incremented and an error indication (notInTimeWindow) together with the OID, the value of the incremented counter, and an indication that the error must be reported with a securityLevel of authNoPriv, is returned to the calling module
メッセージは、タイムウィンドウの外にあると考えられる場合、usmStatsNotInTimeWindowsカウンタがインクリメントされ、エラー表示（notInTimeWindow）と共にOID、インクリメントカウンタの値、エラーがのたsecurityLevelで報告されなければならないという指示とauthNoPrivは、呼び出し元のモジュールに返されます
b) If the extracted value of msgAuthoritativeEngineID is not the same as the value snmpEngineID of the processing SNMP engine (meaning this is not the authoritative SNMP engine), then:
B）msgAuthoritativeEngineIDの抽出された値は、次に、（）これは正式のSNMPエンジンでない意味処理SNMPエンジンの値のsnmpEngineIDと同じでない場合。
1) if at least one of the following conditions is true:
1）以下の条件の少なくともいずれかに該当する場合。
- the extracted value of the msgAuthoritativeEngineBoots field is greater than the local notion of the value of snmpEngineBoots; or,
- msgAuthoritativeEngineBootsフィールドの抽出された値はsnmpEngineBootsの値の局所的な概念よりも大きいです。または、
- the extracted value of the msgAuthoritativeEngineBoots field is equal to the local notion of the value of snmpEngineBoots, and the extracted value of msgAuthoritativeEngineTime field is greater than the value of latestReceivedEngineTime,
- 、msgAuthoritativeEngineBootsフィールドの抽出された値はsnmpEngineBootsの値の局所的な概念に等しく、msgAuthoritativeEngineTimeフィールドの抽出された値は、latestReceivedEngineTimeの値よりも大きいです
then the LCD entry corresponding to the extracted value of the msgAuthoritativeEngineID field is updated, by setting:
次いでmsgAuthoritativeEngineIDフィールドの抽出された値に対応するLCDエントリが設定することにより、更新されます。
- the local notion of the value of snmpEngineBoots to the value of the msgAuthoritativeEngineBoots field, - the local notion of the value of snmpEngineTime to the value of the msgAuthoritativeEngineTime field, and - the latestReceivedEngineTime to the value of the value of the msgAuthoritativeEngineTime field.
- msgAuthoritativeEngineTimeフィールドの値にsnmpEngineTimeの価値のローカルの概念、および - - latestReceivedEngineTime msgAuthoritativeEngineTimeフィールドの値の値にmsgAuthoritativeEngineBootsフィールドの値にsnmpEngineBootsの価値のローカルの概念。
2) if any of the following conditions is true, then the message is considered to be outside of the Time Window:
以下の条件のいずれかが真である場合2）、次いで、メッセージは、タイムウィンドウの外であると考えられています。
- the local notion of the value of snmpEngineBoots is 2147483647;
- snmpEngineBootsの価値のローカルの概念は2147483647です。
- the value of the msgAuthoritativeEngineBoots field is less than the local notion of the value of snmpEngineBoots; or,
- msgAuthoritativeEngineBootsフィールドの値はsnmpEngineBootsの価値のローカルの概念以下です。または、
- the value of the msgAuthoritativeEngineBoots field is equal to the local notion of the value of snmpEngineBoots and the value of the msgAuthoritativeEngineTime field is more than 150 seconds less than the local notion of the value of snmpEngineTime.
- msgAuthoritativeEngineBootsフィールドの値はsnmpEngineBootsの値とmsgAuthoritativeEngineTimeフィールドの値の局所的な概念に等しいsnmpEngineTimeの値の局所的な概念より以上150秒以下です。
If the message is considered to be outside of the Time Window then an error indication (notInTimeWindow) is returned to the calling module.
メッセージは、タイムウィンドウの外にあると考えられる場合は、エラー表示（notInTimeWindow）を呼ぶモジュールに戻されます。
Note that this means that a too old (possibly replayed) message has been detected and is deemed unauthentic.
これはあまりにも古い（多分リプレイ）メッセージが検出されたことを意味し、不正とみなされることに注意してください。
Note that this procedure allows for the value of msgAuthoritativeEngineBoots in the message to be greater than the local notion of the value of snmpEngineBoots to allow for received messages to be accepted as authentic when received from an authoritative SNMP engine that has re-booted since the receiving SNMP engine last (re-)synchronized.
この手順は、受信するので、再起動した正式のSNMPエンジンから受信したときに受信したメッセージが本物として受け入れられる可能にするためにsnmpEngineBootsの値の局所的な概念よりも大きくなるように、メッセージにmsgAuthoritativeEngineBootsの値を可能にすることに注意してくださいSNMPエンジンの最後の（再）同期。
8) a) If the securityLevel indicates that the message was protected from disclosure, then the OCTET STRING representing the encryptedPDU is decrypted according to the user's privacy protocol to obtain an unencrypted serialized scopedPDU value. To do so a call is made to the privacy module that implements the user's privacy protocol according to the abstract primitive:
8）A）たsecurityLevelが、メッセージが次にencryptedPDUを表すオクテット文字列が暗号化されていないシリアル化されたscopedPDU値を取得するためにユーザのプライバシープロトコルに従って復号され、開示から保護したことを示している場合。そうするために呼び出しが原始的抽象に応じて、ユーザーのプライバシープロトコルを実装して、プライバシーモジュールに構成されています。
statusInformation = -- success or failure
decryptData(
IN decryptKey -- the user's localized privKey
IN privParameters -- as received on the wire
IN encryptedData -- encryptedPDU as received
OUT decryptedData -- serialized decrypted scopedPDU
)
statusInformation indicates if the decryption process was successful or not. decryptKey the user's localized private privKey is the secret key that can be used by the decryption algorithm. privParameters the msgPrivacyParameters, encoded as an OCTET STRING. encryptedData the encryptedPDU represents the encrypted scopedPDU, encoded as an OCTET STRING. decryptedData the serialized scopedPDU if decryption is successful.
復号処理が成功したかどうstatusInformationをを示します。ユーザーのローカライズされたプライベートprivKey decryptKey解読アルゴリズムで使用できる秘密鍵です。 OCTET STRINGとしてエンコードされ、msgPrivacyParametersをprivParameters。 EncryptedData encryptedPDUはOCTET STRINGとして符号化された暗号化されたscopedPDUを表します。シリアル化されたscopedPDU decryptedData復号化が成功した場合。
If the privacy module returns failure, then the message can not be processed, so the usmStatsDecryptionErrors counter is incremented and an error indication (decryptionError) together with the OID and value of the incremented counter is returned to the calling module.
プライバシーモジュールが失敗を返した場合、メッセージはusmStatsDecryptionErrorsカウンタがインクリメントされるように、処理することができないと一緒にOIDとインクリメントカウンタの値にエラー表示（decryptionError）を呼ぶモジュールに戻されます。
If the privacy module returns success, then the decrypted scopedPDU is the message payload to be returned to the calling module.
プライバシーモジュールが成功を返す場合、解読されたscopedPDUは呼ぶモジュールに返されるメッセージペイロードです。
Otherwise,
そうでなければ、
b) The scopedPDU component is assumed to be in plain text and is the message payload to be returned to the calling module.
B）たscopedPDU成分はプレーンテキストであると仮定と呼ぶモジュールに返されるメッセージペイロードです。
9) The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message. Provision is made for a message header that allows the same securityLevel as the received Request.
9）maxSizeResponseScopedPDUが算出されます。これは、可能な応答メッセージのためのscopedPDUの最大サイズです。規定は、受信した要求と同じたsecurityLevelを可能にするメッセージヘッダーのために作られています。
10) The securityName for the user is retrieved from the usmUserTable.
10）ユーザのためのsecurityNameはのusmUserTableから取得されます。
11) The security data is cached as cachedSecurityData, so that a possible response to this message can and will use the same authentication and privacy secrets. Information to be saved/cached is as follows:
このメッセージへの可能な応答は、同じ認証とプライバシー秘密を使用することができるように11）、セキュリティデータは、cachedSecurityDataとしてキャッシュされます。情報がキャッシュされた/保存する次のとおりです。
msgUserName,
usmUserAuthProtocol, usmUserAuthKey
usmUserPrivProtocol, usmUserPrivKey
12) The statusInformation is set to success and a return is made to the calling module passing back the OUT parameters as specified in the processIncomingMsg primitive.
12）statusInformationを成功に設定され、リターンがprocessIncomingMsgプリミティブで指定された呼び出し元のモジュールは、OUTパラメータを渡すバックに行われます。
The User-based Security Model requires that a discovery process obtains sufficient information about other SNMP engines in order to communicate with them. Discovery requires an non-authoritative SNMP engine to learn the authoritative SNMP engine's snmpEngineID value before communication may proceed. This may be accomplished by generating a Request message with a securityLevel of noAuthNoPriv, a msgUserName of zero-length, a msgAuthoritativeEngineID value of zero length, and the varBindList left empty. The response to this message will be a Report message containing the snmpEngineID of the authoritative SNMP engine as the value of the msgAuthoritativeEngineID field within the msgSecurityParameters field. It contains a Report PDU with the usmStatsUnknownEngineIDs counter in the varBindList.
ユーザベースセキュリティモデルは、発見プロセスは、それらと通信するために他のSNMPエンジンに関する十分な情報を得ることが必要です。ディスカバリーは、通信が進行してもよい前に、信頼できるSNMPエンジンのsnmpEngineIDの値を学習する非正式のSNMPエンジンが必要です。これはnoAuthNoPrivというのたsecurityLevel、長さゼロのmsgUserName、長さゼロのmsgAuthoritativeEngineID値を有する要求メッセージを生成することによって達成され、varBindListは空のままにしてもよいです。このメッセージへの応答はmsgSecurityParametersフィールド内msgAuthoritativeEngineIDフィールドの値として信頼できるSNMPエンジンのでsnmpEngineIDを含むReportメッセージになります。それはvarBindListでusmStatsUnknownEngineIDsカウンターでレポートPDUが含まれています。
If authenticated communication is required, then the discovery process should also establish time synchronization with the authoritative SNMP engine. This may be accomplished by sending an authenticated Request message with the value of msgAuthoritativeEngineID set to the newly learned snmpEngineID and with the values of msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime set to zero. For an authenticated Request message, a valid userName must be used in the msgUserName field. The response to this authenticated message will be a Report message containing the up to date values of the authoritative SNMP engine's snmpEngineBoots and snmpEngineTime as the value of the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields respectively. It also contains the usmStatsNotInTimeWindows counter in the varBindList of the Report PDU. The time synchronization then happens automatically as part of the procedures in section 3.2 step 7b. See also section 2.3.
認証された通信が必要な場合は、検出プロセスはまた、信頼できるSNMPエンジンで時間同期を確立する必要があります。これは、新たに学習のsnmpEngineIDにmsgAuthoritativeEngineIDセットの値を使用して認証要求メッセージを送信することによって、およびmsgAuthoritativeEngineBootsの値を用いて達成することができるとmsgAuthoritativeEngineTimeはゼロに設定しました。認証された要求メッセージの場合は、有効なユーザー名はmsgUserNameの分野で使用されなければなりません。この認証されたメッセージへの応答は、それぞれmsgAuthoritativeEngineBootsとmsgAuthoritativeEngineTimeフィールドの値として、信頼できるSNMPエンジンのsnmpEngineBootsの日付値までとsnmpEngineTimeを含むReportメッセージになります。また、レポートPDUのvarBindListでusmStatsNotInTimeWindowsカウンタが含まれています。時間同期は、次に、セクション3.2、ステップ7bに手順の一部として自動的に行われます。また、セクション2.3を参照してください。
SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules, Counter32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TestAndIncr, RowStatus, RowPointer, StorageType, AutonomousType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString, SnmpEngineID, snmpAuthProtocols, snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB;
SNMPv2の-CONFれるSnmpAdminString FROMのSNMPv2-TCのMODULE-COMPLIANCEからの輸入MODULE-IDENTITY、OBJECT-TYPE、OBJECT-IDENTITY、snmpModules、Counter32のはSNMPv2-SMI TEXTUAL-CONVENTION、TestAndIncr、RowStatusの、RowPointer、StorageType FROM、AutonomousTypeの、オブジェクト・グループ、 snmpEngineID、snmpAuthProtocols、SNMP-FRAMEWORK-MIB FROM snmpPrivProtocols。
snmpUsmMIB MODULE-IDENTITY LAST-UPDATED "9901200000Z" -- 20 Jan 1999, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3
snmpUsmMIBのMODULE-IDENTITY LAST-UPDATED "9901200000Z" - 1999年1月20日、深夜組織 "のSNMPv3ワーキンググループ" CONTACT-INFO「WG-メール：snmpv3@lists.tislabs.com購読：majordomo@lists.tislabs.com MSGボディで：SNMPv3のサブスクライブ
Chair: Russ Mundy
Trusted Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
USA
email: mundy@tislabs.com
phone: +1-301-854-6889
Co-editor Uri Blumenthal
共同編集者ウリブルーメンソール
IBM T. J. Watson Research postal: 30 Saw Mill River Pkwy, Hawthorne, NY 10532 USA email: uri@watson.ibm.com phone: +1-914-784-7964
IBM T. J.ワトソン研究所が郵便：30は、ミルリバーパークウェイ、ホーソーン、NY 10532 USAメールを見ました：uri@watson.ibm.com電話：+ 1-914-784-7964
Co-editor: Bert Wijnen IBM T. J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-432-794 " DESCRIPTION "The management information definitions for the SNMP User-based Security Model. " -- Revision history
共同編集者：バートWijnen IBM TJワトソン研究所郵便：ショームバーグ33 3461 GL Linschotenオランダ電子メール：wijnen@vnet.ibm.com電話：+ 31-348-432-794「DESCRIPTION」SNMPユーザベースの管理情報の定義セキュリティモデル。 「 - 改訂履歴
REVISION "9901200000Z" -- 20 Jan 1999, midnight
DESCRIPTION "Clarifications, published as RFC2574"
REVISION "9711200000Z" -- 20 Nov 1997, midnight DESCRIPTION "Initial version, published as RFC2274"
REVISION "9711200000Z" - 1997年11月20日、深夜の説明 "初期バージョン、RFC2274として公開"
::= { snmpModules 15 }
-- Administrative assignments ****************************************
- 行政割り当て****************************************
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
-- Identification of Authentication and Privacy Protocols ************
- 認証の同定およびプライバシープロトコル************
usmNoAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Authentication Protocol."
::= { snmpAuthProtocols 1 }
usmHMACMD5AuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol." REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC: Keyed-Hashing for Message Authentication, RFC2104, Feb 1997. - Rivest, R., Message Digest Algorithm MD5, RFC1321. "
usmHMACMD5AuthProtocol OBJECT-IDENTITYステータス現在の説明 "HMAC-MD5-96ダイジェスト認証プロトコル。" REFERENCE " - H. Krawczyk、M.ベラー、R.カネッティHMAC：メッセージ認証、RFC2104 2012年02月1997年のための鍵付きハッシング - リベスト、R.、メッセージダイジェストアルゴリズムMD5、RFC1321。"
::= { snmpAuthProtocols 2 }
usmHMACSHAAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol."
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
Keyed-Hashing for Message Authentication,
RFC2104, Feb 1997.
- Secure Hash Algorithm. NIST FIPS 180-1.
"
::= { snmpAuthProtocols 3 }
usmNoPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Privacy Protocol."
::= { snmpPrivProtocols 1 }
usmDESPrivProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The CBC-DES Symmetric Encryption Protocol." REFERENCE "- 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).
usmDESPrivProtocol OBJECT-IDENTITYステータス現在の説明 "CBC-DES対称暗号化プロトコル。" REFERENCE「 - データ暗号化規格、国立標準技術研究所連邦情報処理標準（FIPS）出版物46-1優先さFIPSパブリケーション46、（1月、1977;再確認した1月、1988）。。。
- Data Encryption Algorithm, American National
Standards Institute. ANSI X3.92-1981,
(December, 1980).
- DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980).
- 操作のDESモード、アメリカ国立標準技術研究所。連邦情報処理標準（FIPS）出版81、（12月、1980）。
- Data Encryption Algorithm - Modes of Operation,
American National Standards Institute.
ANSI X3.106-1983, (May 1983).
"
::= { snmpPrivProtocols 2 }
-- Textual Conventions ***********************************************
- テキストの表記法********************************************** *
KeyChange ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Every definition of an object with this syntax must identify
a protocol P, a secret key K, and a hash algorithm H
that produces output of L octets.
The object's value is a manager-generated, partially-random value which, when modified, causes the value of the secret key K, to be modified via a one-way function.
オブジェクトの値は、修飾された場合、秘密鍵Kの値は、一方向関数によって変更されることを引き起こすマネージャが生成し、部分的にランダムな値です。
The value of an instance of this object is the concatenation of two components: first a 'random' component and then a 'delta' component.
最初の「ランダムな」成分とし、「デルタ」コンポーネント：このオブジェクトのインスタンスの値は、2つの構成要素の連結です。
The lengths of the random and delta components are given by the corresponding value of the protocol P; if P requires K to be a fixed length, the length of both the random and delta components is that fixed length; if P allows the length of K to be variable up to a particular maximum length, the length of the random component is that maximum length and the length of the delta component is any length less than or equal to that maximum length. For example, usmHMACMD5AuthProtocol requires K to be a fixed length of 16 octets and L - of 16 octets. usmHMACSHAAuthProtocol requires K to be a fixed length of 20 octets and L - of 20 octets. Other protocols may define other sizes, as deemed appropriate.
ランダムおよびデルタコンポーネントの長さは、プロトコルPの対応する値によって与えられます。 Pが固定長であることがKを必要とする場合、両方のランダムおよびデルタコンポーネントの長さは固定長です。 PがKの長さは、特定の最大長まで可変にすることができる場合、ランダム成分の長さが最大長及びデルタコンポーネントの長さがその最大長までの任意の長さ以下であることです。 16オクテットの - 例えば、usmHMACMD5AuthProtocolは、固定16オクテットの長さLとKを必要とします。 20オクテットの - usmHMACSHAAuthProtocolは、固定20オクテットの長さLとKを必要とします。適切と思われるような他のプロトコルは、他のサイズを定義することができます。
When a requester wants to change the old key K to a new key keyNew on a remote entity, the 'random' component is obtained from either a true random generator, or from a pseudorandom generator, and the 'delta' component is computed as follows:
依頼者は、リモートエンティティに新しいキーkeyNewに古いキーKを変更したい場合は、以下のように、「ランダム」コンポーネントは、真の乱数発生器のいずれかから入手した、または擬似乱数発生器から、と「デルタ」コンポーネントが計算されています：
- a temporary variable is initialized to the existing value
of K;
- if the length of the keyNew is greater than L octets,
then:
- the random component is appended to the value of the
temporary variable, and the result is input to the
the hash algorithm H to produce a digest value, and
the temporary variable is set to this digest value;
- the value of the temporary variable is XOR-ed with
the first (next) L-octets (16 octets in case of MD5)
of the keyNew to produce the first (next) L-octets
(16 octets in case of MD5) of the 'delta' component.
- the above two steps are repeated until the unused
portion of the keyNew component is L octets or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the hash algorithm H to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the keyNew, is XOR-ed
with the unused portion of the keyNew to produce the
(final portion of the) 'delta' component.
For example, using MD5 as the hash algorithm H:
例えば、ハッシュアルゴリズムHとしてMD5を使用して：
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
delta[i*16 .. (i*16)+15] =
temp XOR keyNew[i*16 .. (i*16)+15];
}
temp = MD5 (temp || random);
delta[i*16 .. lenOfDelta-1] =
temp XOR keyNew[i*16 .. lenOfDelta-1];
The 'random' and 'delta' components are then concatenated as described above, and the resulting octet string is sent to the recipient as the new value of an instance of this object.
上記のように「ランダム」と「デルタ」成分は、その後連結され、そして得られたオクテットストリングが、このオブジェクトのインスタンスの新しい値として受信者に送信されます。
At the receiver side, when an instance of this object is set to a new value, then a new value of K is computed as follows:
このオブジェクトのインスタンスが新しい値に設定されている場合、次のように受信機側では、Kの新しい値が計算されます。
- a temporary variable is initialized to the existing value
of K;
- if the length of the delta component is greater than L
octets, then:
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value, and the
temporary variable is set to this digest value;
- the value of the temporary variable is XOR-ed with
the first (next) L-octets (16 octets in case of MD5)
of the delta component to produce the first (next)
L-octets (16 octets in case of MD5) of the new value
of K.
- the above two steps are repeated until the unused
portion of the delta component is L octets or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the delta component, is
XOR-ed with the unused portion of the delta component to
produce the (final portion of the) new value of K.
For example, using MD5 as the hash algorithm H:
例えば、ハッシュアルゴリズムHとしてMD5を使用して：
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
keyNew[i*16 .. (i*16)+15] =
temp XOR delta[i*16 .. (i*16)+15];
}
temp = MD5 (temp || random);
keyNew[i*16 .. lenOfDelta-1] =
temp XOR delta[i*16 .. lenOfDelta-1];
The value of an object with this syntax, whenever it is retrieved by the management protocol, is always the zero length string.
それは管理プロトコルによって取得されるたびに、この構文を使用してオブジェクトの値は、常にゼロ長の文字列です。
Note that the keyOld and keyNew are the localized keys.
keyOldとkeyNewがローカライズされた鍵であることに注意してください。
Note that it is probably wise that when an SNMP entity sends a SetRequest to change a key, that it keeps a copy of the old key until it has confirmed that the key change actually succeeded. " SYNTAX OCTET STRING
それはSNMPエンティティは、それがキーの変更が実際に成功していることが確認されるまで、それは古いキーのコピーを保持していること、キーを変更するのSetRequestを送信したときに、おそらく賢明であることに注意してください。 「構文オクテットSTRING
-- Statistics for the User-based Security Model **********************
- ユーザベースセキュリティモデルの統計**********************
usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
usmStatsUnsupportedSecLevels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they requested a
securityLevel that was unknown to the SNMP engine
or otherwise unavailable.
"
::= { usmStats 1 }
usmStatsNotInTimeWindows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current
usmStatsNotInTimeWindows OBJECT-TYPE SYNTAXカウンタACCESS read-onlyステータス現在
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they appeared
outside of the authoritative SNMP engine's window.
"
::= { usmStats 2 }
usmStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they referenced a
user that was not known to the SNMP engine.
"
::= { usmStats 3 }
usmStatsUnknownEngineIDs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they referenced an
snmpEngineID that was not known to the SNMP engine.
"
::= { usmStats 4 }
usmStatsWrongDigests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they didn't
contain the expected digest value.
"
::= { usmStats 5 }
usmStatsDecryptionErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they could not be
decrypted.
"
::= { usmStats 6 }
-- The usmUser Group ************************************************ usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
usmUserSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
Command Generator Applications to coordinate their
use of facilities to alter secrets in the
usmUserTable.
"
::= { usmUser 1 }
-- The table of valid users for the User-based Security Model ********
- ユーザベースセキュリティモデルの********ための有効なユーザーの表
usmUserTable OBJECT-TYPE SYNTAX SEQUENCE OF UsmUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of users configured in the SNMP engine's Local Configuration Datastore (LCD).
UsmUserEntry MAX-ACCESSステータス現在の説明「SNMPエンジンのローカルコンフィギュレーションデータストア（LCD）で構成されたユーザーのテーブルOFのusmUserTable OBJECT-TYPE構文配列。
To create a new user (i.e., to instantiate a new
conceptual row in this table), it is recommended to
follow this procedure:
1) GET(usmUserSpinLock.0) and save in sValue. 2) SET(usmUserSpinLock.0=sValue, usmUserCloneFrom=templateUser, usmUserStatus=createAndWait) You should use a template user to clone from which has the proper auth/priv protocol defined.
1）GET（usmUserSpinLock.0）およびsValueに保存します。 2）SET（usmUserSpinLock.0 = sValue、usmUserCloneFrom = templateUser、usmUserStatus = createAndWaitに）あなたはそこから定義された適切なAUTH / PRIVプロトコルを有するクローニングするテンプレートユーザーを使用する必要があります。
If the new user is to use privacy:
新しいユーザーがプライバシーを使用している場合：
3) generate the keyChange value based on the secret privKey of the clone-from user and the secret key to be used for the new user. Let us call this pkcValue. 4) GET(usmUserSpinLock.0) and save in sValue. 5) SET(usmUserSpinLock.0=sValue, usmUserPrivKeyChange=pkcValue usmUserPublic=randomValue1) 6) GET(usmUserPulic) and check it has randomValue1. If not, repeat steps 4-6.
3）利用者からのクローンおよび新規ユーザに使用する秘密鍵の秘密privKeyに基づいてkeyChange値を生成します。私たちはこのpkcValueを呼びましょう。 4）GET（usmUserSpinLock.0）およびsValueに保存します。 5）SET（usmUserSpinLock.0 = sValue、usmUserPrivKeyChange = pkcValue usmUserPublic = randomValue1）6）（usmUserPulicをGET）、それはrandomValue1を有するチェック。ない場合は、繰り返しは4-6を繰り返します。
If the new user will never use privacy:
新しいユーザーは、プライバシーを使用することはありません場合は：
7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
7）SET（usmUserPrivプロトコル= usmNoPrivプロトコル）
If the new user is to use authentication:
新しいユーザーが認証を使用する場合：
8) generate the keyChange value based on the secret authKey of the clone-from user and the secret key to be used for the new user. Let us call this akcValue. 9) GET(usmUserSpinLock.0) and save in sValue. 10) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=akcValue usmUserPublic=randomValue2) 11) GET(usmUserPulic) and check it has randomValue2. If not, repeat steps 9-11.
8）新しいユーザーのために使用されるユーザーからのクローンと秘密鍵の秘密てAuthKeyに基づいてkeyChange値を生成します。私たちはこのakcValueを呼びましょう。 9）GET（usmUserSpinLock.0）およびsValueに保存します。 10）SET（usmUserSpinLock.0 = sValue、usmUserAuthKeyChange = akcValue usmUserPublic = randomValue2）11）（usmUserPulic）を取得し、それがrandomValue2を有するチェック。ない場合は、繰り返し9-11を繰り返します。
If the new user will never use authentication:
新しいユーザーが認証を使用することはありません場合は：
12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
12）SET（usmUserAuthProtocol = usmNoAuthProtocol）
Finally, activate the new user:
最後に、新しいユーザーをアクティブ化：
13) SET(usmUserStatus=active)
13）SET（usmUserStatus =アクティブ）
The new user should now be available and ready to be used for SNMPv3 communication. Note however that access to MIB data must be provided via configuration of the SNMP-VIEW-BASED-ACM-MIB.
新しいユーザーが利用可能になりましたし、SNMPv3通信に使用する準備ができているはずです。注しかしMIBデータへのアクセスは、SNMP-VIEW-BASED-ACM-MIBの構成を介して提供されなければなりません。
The use of usmUserSpinlock is to avoid conflicts with
another SNMP command responder application which may
also be acting on the usmUserTable.
"
::= { usmUser 2 }
usmUserEntry OBJECT-TYPE
SYNTAX UsmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A user configured in the SNMP engine's Local
Configuration Datastore (LCD) for the User-based
Security Model.
"
INDEX { usmUserEngineID,
usmUserName
}
::= { usmUserTable 1 }
UsmUserEntry ::= SEQUENCE
{
usmUserEngineID SnmpEngineID,
usmUserName SnmpAdminString,
usmUserSecurityName SnmpAdminString,
usmUserCloneFrom RowPointer,
usmUserAuthProtocol AutonomousType,
usmUserAuthKeyChange KeyChange,
usmUserOwnAuthKeyChange KeyChange,
usmUserPrivProtocol AutonomousType,
usmUserPrivKeyChange KeyChange,
usmUserOwnPrivKeyChange KeyChange,
usmUserPublic OCTET STRING,
usmUserStorageType StorageType,
usmUserStatus RowStatus
}
usmUserEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS not-accessible STATUS current DESCRIPTION "An SNMP engine's administratively-unique identifier.
usmUserEngineIDのOBJECT-TYPE SYNTAXのsnmpEngineID MAX-ACCESSステータス現在の説明「SNMPエンジンの管理上ユニークな識別子。
In a simple agent, this value is always that agent's
own snmpEngineID value.
The value can also take the value of the snmpEngineID
of a remote SNMP engine with which this user can
communicate.
"
::= { usmUserEntry 1 }
usmUserName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A human readable string representing the name of the user.
usmUserName OBJECT-TYPE SYNTAXれるSnmpAdminString（SIZE（1 32））MAX-ACCESSステータス現在の説明は「ユーザの名前を表す、人間が読める形式の文字列。
This is the (User-based Security) Model dependent
security ID.
"
::= { usmUserEntry 2 }
usmUserSecurityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable string representing the user in
usmUserSecurityNameのOBJECT-TYPE SYNTAXれるSnmpAdminString MAX-ACCESS read-onlyステータス現在の説明「のユーザーを表す、人間が読める形式の文字列
Security Model independent format.
セキュリティモデルに依存しないフォーマット。
The default transformation of the User-based Security
Model dependent security ID to the securityName and
vice versa is the identity function so that the
securityName is the same as the userName.
"
::= { usmUserEntry 3 }
usmUserCloneFrom OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to another conceptual row in this usmUserTable. The user in this other conceptual row is called the clone-from user.
usmUserCloneFrom OBJECT-TYPE構文RowPointer MAX-ACCESSリード作成ステータス現在の説明「本のusmUserTable内の別の概念的な列へのポインタ。この他の概念的な行のユーザがクローンからユーザと呼ばれています。
When a new user is created (i.e., a new conceptual
row is instantiated in this table), the privacy and
authentication parameters of the new user must be
cloned from its clone-from user. These parameters are:
- authentication protocol (usmUserAuthProtocol)
- privacy protocol (usmUserPrivProtocol)
They will be copied regardless of what the current
value is.
Cloning also causes the initial values of the secret authentication key (authKey) and the secret encryption key (privKey) of the new user to be set to the same value as the corresponding secret of the clone-from user.
クローニングはまた、秘密認証キー（てAuthKey）と新しいユーザの秘密暗号化キー（privKey）の初期値は、クローンからのユーザーの対応する秘密と同じ値に設定されます。
The first time an instance of this object is set by a management operation (either at or after its instantiation), the cloning process is invoked. Subsequent writes are successful but invoke no action to be taken by the receiver. The cloning process fails with an 'inconsistentName' error if the conceptual row representing the clone-from user does not exist or is not in an active state when the cloning process is invoked.
最初の時間は、このオブジェクトのインスタンスが（そのインスタンスに又は後のいずれか）管理操作によって設定され、クローニングプロセスが呼び出されます。以降の書き込みは成功しているが、受信機がとるべき何もアクションを呼び出しません。クローニングプロセスは、クローンからユーザを表す概念的な行が存在しない場合は「inconsistentName」エラーで失敗またはクローニングプロセスが呼び出されたときに、アクティブ状態ではありません。
When this object is read, the ZeroDotZero OID
is returned.
"
::= { usmUserEntry 4 }
usmUserAuthProtocol OBJECT-TYPE
usmUserAuthProtocolのOBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An indication of whether messages sent on behalf of
this user to/from the SNMP engine identified by
usmUserEngineID, can be authenticated, and if so,
the type of authentication protocol which is used.
An instance of this object is created concurrently
with the creation of any other object instance for
the same user (i.e., as part of the processing of
the set operation which creates the first object
instance in the same conceptual row).
If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned.
（すなわち、行の作成時に）初期設定動作が不明またはサポートされていないプロトコルの値を設定しようとした場合、その後、「wrongValue」エラーが返されなければなりません。
The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom.
セット動作はusmUserCloneFromの対応するインスタンス上で実行されたときに値がセット/上書きされます。
Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoAuthProtocol.
インスタンス化されると、このオブジェクトのそのようなインスタンスの値のみusmNoAuthProtocolの値に設定された動作を介して変更することができます。
If a set operation tries to change the value of an existing instance of this object to any value other than usmNoAuthProtocol, then an 'inconsistentValue' error must be returned.
セット動作がusmNoAuthProtocol以外の値にこのオブジェクトの既存のインスタンスの値を変更しようとする場合、「はinconsistentValue」エラーが返されなければなりません。
If a set operation tries to set the value to the
usmNoAuthProtocol while the usmUserPrivProtocol value
in the same row is not equal to usmNoPrivProtocol,
then an 'inconsistentValue' error must be returned.
That means that an SNMP command generator application
must first ensure that the usmUserPrivProtocol is set
to the usmNoPrivProtocol value before it can set
the usmUserAuthProtocol value to usmNoAuthProtocol.
"
DEFVAL { usmNoAuthProtocol }
::= { usmUserEntry 5 }
usmUserAuthKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5 -- typically (SIZE (0 | 40)) for HMACSHA MAX-ACCESS read-create STATUS current
usmUserAuthKeyChangeのOBJECT-TYPE SYNTAXてkeyChange - 通常（SIZE（0 | 32））HMACMD5について - 通常（SIZE（0 | 40））HMACSHA MAX-ACCESSはリード作成しますステータス現在のために
DESCRIPTION "An object, which when modified, causes the secret
authentication key used for messages sent on behalf
of this user to/from the SNMP engine identified by
usmUserEngineID, to be modified via a one-way
function.
The associated protocol is the usmUserAuthProtocol.
The associated secret key is the user's secret
authentication key (authKey). The associated hash
algorithm is the algorithm used by the user's
usmUserAuthProtocol.
When creating a new user, it is an 'inconsistentName' error for a set operation to refer to this object unless it is previously or concurrently initialized through a set operation on the corresponding instance of usmUserCloneFrom.
新しいユーザを作成する場合、以前または同時にusmUserCloneFromの対応するインスタンスに設定された動作により初期化されない限り、このオブジェクトを参照するために設定された操作のための「inconsistentName」エラーです。
When the value of the corresponding usmUserAuthProtocol is usmNoAuthProtocol, then a set is successful, but effectively is a no-op.
対応usmUserAuthProtocolの値がusmNoAuthProtocolである場合、次いで、セットが成功しているが、事実上何もしません。
When this object is read, the zero-length (empty) string is returned.
このオブジェクトが読まれるとき、ゼロ長（空の）文字列が返されます。
The recommended way to do a key change is as follows:
次のようにキーの変更を行うための推奨方法は、次のとおりです。
1) GET(usmUserSpinLock.0) and save in sValue. 2) generate the keyChange value based on the old (existing) secret key and the new secret key, let us call this kcValue.
1）GET（usmUserSpinLock.0）およびsValueに保存します。 2）古い（既存の）秘密鍵および新しい秘密鍵に基づいてkeyChange値を生成し、私たちはこのkcValueを呼びましょう。
If you do the key change on behalf of another user:
あなたが別のユーザーに代わって重要な変更を行う場合：
3) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=kcValue usmUserPublic=randomValue)
3）SET（usmUserSpinLock.0 = sValue、usmUserAuthKeyChange = kcValue usmUserPublic = randomValue）
If you do the key change for yourself:
あなた自身のためのキーの変更を行う場合：
4) SET(usmUserSpinLock.0=sValue, usmUserOwnAuthKeyChange=kcValue usmUserPublic=randomValue)
4）SET（usmUserSpinLock.0 = sValue、usmUserOwnAuthKeyChange = kcValue usmUserPublic = randomValue）
If you get a response with error-status of noError,
then the SET succeeded and the new key is active.
If you do not get a response, then you can issue a
GET(usmUserPublic) and check if the value is equal to the randomValue you did send in the SET. If so, then
the key change succeeded and the new key is active
(probably the response got lost). If not, then the SET
request probably never reached the target and so you
can start over with the procedure above.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 6 }
usmUserOwnAuthKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5 -- typically (SIZE (0 | 40)) for HMACSHA MAX-ACCESS read-create STATUS current DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one notable difference: in order for the set operation to succeed, the usmUserName of the operation requester must match the usmUserName that indexes the row which is targeted by this operation. In addition, the USM security model must be used for this operation.
usmUserOwnAuthKeyChangeのOBJECT-TYPE SYNTAXてkeyChange - 通常（SIZE（0 | 32））HMACMD5ためには - 通常、（SIZE（0 | 40））HMACSHA MAX-ACCESSはリード作成しますステータス現在の説明のためには、「注目すべきものと、usmUserAuthKeyChangeとして正確に動作します違いは：セット動作が成功するためには、操作要求元のusmUserNameがインデックスは、この操作によって目標とされる行はまた、USMセキュリティモデルは、この操作のために使用されなければならないことusmUserNameと一致しなければなりません。
The idea here is that access to this column can be
public, since it will only allow a user to change
his own secret authentication key (authKey).
Note that this can only be done once the row is active.
When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned.
セットが受信されusmUserName要求は、この操作によって目標とされる行は、その後、「NOACCESS」エラーが返さなければならないインデックスumsUserNameと同じではない場合。
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 7 }
usmUserPrivProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, can be protected from disclosure, and if so, the type of privacy protocol which is used.
オブジェクトタイプusmUserPrivProtocol SYNTAX AutonomousTypeのMAX-ACCESSリード作成ステータス現在の説明「usmUserEngineIDによって識別されるSNMPエンジンからの/そのユーザに代わって送信されたメッセージは、開示から保護することができるかどうかの指示を、そうであれば、種類の使用されているプライバシープロトコル。
An instance of this object is created concurrently
with the creation of any other object instance for
the same user (i.e., as part of the processing of
the set operation which creates the first object
instance in the same conceptual row).
If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned.
（すなわち、行の作成時に）初期設定動作が不明またはサポートされていないプロトコルの値を設定しようとした場合、その後、「wrongValue」エラーが返されなければなりません。
The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom.
セット動作はusmUserCloneFromの対応するインスタンス上で実行されたときに値がセット/上書きされます。
Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoPrivProtocol.
インスタンス化されると、このオブジェクトのそのようなインスタンスの値のみusmNoPrivProtocolの値に設定された動作を介して変更することができます。
If a set operation tries to change the value of an existing instance of this object to any value other than usmNoPrivProtocol, then an 'inconsistentValue' error must be returned.
セット動作がusmNoPrivProtocol以外の値にこのオブジェクトの既存のインスタンスの値を変更しようとする場合、「はinconsistentValue」エラーが返されなければなりません。
Note that if any privacy protocol is used, then you
must also use an authentication protocol. In other
words, if usmUserPrivProtocol is set to anything else
than usmNoPrivProtocol, then the corresponding instance
of usmUserAuthProtocol cannot have a value of
usmNoAuthProtocol. If it does, then an
'inconsistentValue' error must be returned.
"
DEFVAL { usmNoPrivProtocol }
::= { usmUserEntry 8 }
usmUserPrivKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES MAX-ACCESS read-create STATUS current DESCRIPTION "An object, which when modified, causes the secret encryption key used for messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, to be modified via a one-way function.
usmUserPrivKeyChangeのOBJECT-TYPE SYNTAXてkeyChange - 通常（SIZE（0 | 32））DES MAX-ACCESSはリード作成しますステータス現在の説明のための「変更する場合、このユーザーの代わりに送信されるメッセージに使用される秘密の暗号化キーを起こしたオブジェクト、 usmUserEngineIDによって識別されるSNMPエンジンからの/への、一方向関数を介して変更されます。
The associated protocol is the usmUserPrivProtocol.
The associated secret key is the user's secret
privacy key (privKey). The associated hash
algorithm is the algorithm used by the user's usmUserAuthProtocol.
When creating a new user, it is an 'inconsistentName' error for a set operation to refer to this object unless it is previously or concurrently initialized through a set operation on the corresponding instance of usmUserCloneFrom.
新しいユーザを作成する場合、以前または同時にusmUserCloneFromの対応するインスタンスに設定された動作により初期化されない限り、このオブジェクトを参照するために設定された操作のための「inconsistentName」エラーです。
When the value of the corresponding usmUserPrivProtocol is usmNoPrivProtocol, then a set is successful, but effectively is a no-op.
対応usmUserPrivProtocolの値がusmNoPrivProtocolである場合、次いで、セットが成功しているが、事実上何もしません。
When this object is read, the zero-length (empty)
string is returned.
See the description clause of usmUserAuthKeyChange for
a recommended procedure to do a key change.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 9 }
usmUserOwnPrivKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES MAX-ACCESS read-create STATUS current DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one notable difference: in order for the Set operation to succeed, the usmUserName of the operation requester must match the usmUserName that indexes the row which is targeted by this operation. In addition, the USM security model must be used for this operation.
Set操作が成功するためには、usmUserName：| - usmUserOwnPrivKeyChangeのOBJECT-TYPE SYNTAXてkeyChange通常（SIZE（0 32））DES MAX-ACCESSはリード作成しますステータス現在の説明のためには、「正確に一つの大きな違いとusmUserPrivKeyChange、として振る舞い操作要求元のインデックス、この操作によって目標とされる行usmUserNameと一致しなければなりません。また、USMセキュリティモデルは、この操作のために使用されなければなりません。
The idea here is that access to this column can be
public, since it will only allow a user to change
his own secret privacy key (privKey).
Note that this can only be done once the row is active.
When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned.
セットが受信されusmUserName要求は、この操作によって目標とされる行は、その後、「NOACCESS」エラーが返さなければならないインデックスumsUserNameと同じではない場合。
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 10 }
usmUserPublic OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A publicly-readable value which can be written as part
of the procedure for changing a user's secret
authentication and/or privacy key, and later read to
determine whether the change of the secret was
effected.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 11 }
usmUserStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row.
usmUserStorageType OBJECT-TYPE構文StorageType MAX-ACCESSリード作成ステータス現在の説明「この概念的な列のためのストレージタイプを。
Conceptual rows having the value 'permanent' must
allow write-access at a minimum to:
- usmUserAuthKeyChange, usmUserOwnAuthKeyChange and usmUserPublic for a user who employs authentication, and - usmUserPrivKeyChange, usmUserOwnPrivKeyChange and usmUserPublic for a user who employs privacy.
- usmUserPrivKeyChange、usmUserOwnPrivKeyChangeとusmUserPublicプライバシーを用いるユーザ向け - 認証を採用し、ユーザーのためのusmUserAuthKeyChange、usmUserOwnAuthKeyChangeとusmUserPublic。
Note that any user who employs authentication or privacy must allow its secret(s) to be updated and thus cannot be 'readOnly'.
認証やプライバシーを使用する任意のユーザーがその秘密（s）は「読み取り専用」にすることはできませんので、更新してできるようにする必要があることに注意してください。
If an initial set operation tries to set the value to 'readOnly' for a user who employs authentication or privacy, then an 'inconsistentValue' error must be returned. Note that if the value has been previously set (implicit or explicit) to any value, then the rules as defined in the StorageType Textual Convention apply.
初期設定操作は、認証やプライバシーを採用し、ユーザーのための「読み取り専用」に値を設定しようとすると、その後から「inconsistentValue」エラーが返されなければなりません。値が予め任意の値に（暗黙的または明示的に）設定されている場合、StorageTypeテキストの表記法で定義されるように、その後のルールが適用されます。
It is an implementation issue to decide if a SET for
a readOnly or permanent row is accepted at all. In some
contexts this may make sense, in others it may not. If
a SET for a readOnly or permanent row is not accepted
at all, then a 'wrongValue' error must be returned.
"
DEFVAL { nonVolatile }
::= { usmUserEntry 12 }
usmUserStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row.
usmUserStatusのOBJECT-TYPE構文RowStatus MAX-ACCESSリード作成ステータス現在の説明「この概念的な列のステータス。
Until instances of all corresponding columns are
appropriately configured, the value of the
corresponding instance of the usmUserStatus column
is 'notReady'.
In particular, a newly created row for a user who employs authentication, cannot be made active until the corresponding usmUserCloneFrom and usmUserAuthKeyChange have been set.
対応usmUserCloneFromとusmUserAuthKeyChangeが設定されるまで、特に、認証を用いたユーザの新しく作成された行は、アクティブにすることができません。
Further, a newly created row for a user who also employs privacy, cannot be made active until the usmUserPrivKeyChange has been set.
usmUserPrivKeyChangeが設定されるまで更に、またプライバシーを採用し、ユーザー用に新しく作成した行は、アクティブに作ることができません。
The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified:
RowStatusのTC [RFC2579]この行の他のオブジェクトが修正することができ、この説明節状態どの状況下でいる必要があります。
The value of this object has no effect on whether
other objects in this conceptual row can be modified,
except for usmUserOwnAuthKeyChange and
usmUserOwnPrivKeyChange. For these 2 objects, the
value of usmUserStatus MUST be active.
"
::= { usmUserEntry 13 }
-- Conformance Information *******************************************
- 適合情報*******************************************
usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
-- Compliance statements
- コンプライアンスステートメント
usmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-USER-BASED-SM-MIB. "
usmMIBCompliance MODULE-COMPLIANCEステータス現在の説明 "SNMP-USER-BASED-SM-MIBを実装するSNMPエンジンのための準拠宣言。"
MODULE -- this module
MANDATORY-GROUPS { usmMIBBasicGroup }
OBJECT usmUserAuthProtocol
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT usmUserPrivProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT usmUserPrivProtocol MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
::= { usmMIBCompliances 1 }
-- Units of compliance
usmMIBBasicGroup OBJECT-GROUP
OBJECTS {
usmStatsUnsupportedSecLevels,
usmStatsNotInTimeWindows,
usmStatsUnknownUserNames,
usmStatsUnknownEngineIDs,
usmStatsWrongDigests,
usmStatsDecryptionErrors,
usmUserSpinLock,
usmUserSecurityName,
usmUserCloneFrom,
usmUserAuthProtocol,
usmUserAuthKeyChange,
usmUserOwnAuthKeyChange,
usmUserPrivProtocol,
usmUserPrivKeyChange,
usmUserOwnPrivKeyChange,
usmUserPublic,
usmUserStorageType,
usmUserStatus
}
STATUS current
DESCRIPTION "A collection of objects providing for configuration
of an SNMP engine which implements the SNMP
User-based Security Model.
"
::= { usmMIBGroups 1 }
END
終わり
This section describes the HMAC-MD5-96 authentication protocol. This authentication protocol is the first defined for the User-based Security Model. It uses MD5 hash-function which is described in [MD5], in HMAC mode described in [RFC2104], truncating the output to 96 bits.
このセクションでは、HMAC-MD5-96認証プロトコルを記述しています。この認証プロトコルは、ユーザベースセキュリティモデルのために定義された最初です。これは、96ビット出力を切り捨て、[RFC2104]に記載HMACモードで、[MD5]に記載されているMD5ハッシュ関数を使用します。
This protocol is identified by usmHMACMD5AuthProtocol.
このプロトコルはusmHMACMD5AuthProtocolによって識別されます。
Over time, other authentication protocols may be defined either as a replacement of this protocol or in addition to this protocol.
時間をかけて、他の認証プロトコルは、このプロトコルの代替として、またはこのプロトコルに加えてのいずれかで定義されてもよいです。
- In support of data integrity, a message digest algorithm is required. A digest is calculated over an appropriate portion of an SNMP message and included as part of the message sent to the recipient.
- データの整合性のサポートでは、メッセージダイジェストアルゴリズムが必要です。ダイジェストはSNMPメッセージの適切な部分にわたって計算され、受信者に送信されたメッセージの一部として含まれています。
- In support of data origin authentication and data integrity, a secret value is prepended to SNMP message prior to computing the digest; the calculated digest is partially inserted into the SNMP message prior to transmission, and the prepended value is not transmitted. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user.
- データ発信元認証およびデータの整合性のサポートでは、秘密の値は、ダイジェストを計算する前に、SNMPメッセージに付加されています。計算されたダイジェストは、部分的に送信前にSNMPメッセージに挿入され、プリペンド値が送信されません。秘密の値は、適切なユーザーの代わりにメッセージを発信することを許可すべてのSNMPエンジンによって共有されています。
The Digest Authentication Mechanism defined in this memo provides for:
このメモで定義されたダイジェスト認証メカニズムは、のために用意されています。
- verification of 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 the message. The digest is computed by the originator of the message, transmitted with the message, and verified by the recipient of the message.
メッセージの完全性は、メッセージの適切な部分の上にダイジェストを計算することによって保護されています。ダイジェストは、メッセージで送信されたメッセージの発信元で計算され、メッセージの受信者によって検証されます。
- verification of the user on whose behalf the message was generated.
- メッセージが生成されたその代わりに、ユーザーの検証。
A secret value known only to SNMP engines authorized to generate messages on behalf of a user is used in HMAC mode (see [RFC2104]). It also recommends the hash-function output used as Message Authentication Code, to be truncated.
唯一のユーザーに代わってメッセージを生成することを許可SNMPエンジンに知られている秘密の値がHMACモードで使用されている（[RFC2104]を参照）。それはまた、メッセージ認証コードとして使用されるハッシュ関数の出力、トランケートされることをお勧めします。
This protocol uses the MD5 [MD5] message digest algorithm. A 128-bit MD5 digest is calculated in a special (HMAC) way over the designated portion of an SNMP message and the first 96 bits of this digest is included as part of the message sent to the recipient. The size of the digest carried in a message is 12 octets. The size of the private authentication key (the secret) is 16 octets. For the details see section 6.3.
このプロトコルはMD5 [MD5]メッセージダイジェストアルゴリズムを使用します。 128ビットのMD5ダイジェストは、SNMPメッセージの指定された部分と、このダイジェストの最初の96ビットを超える特別な（HMAC）のように算出される受信者に送信されたメッセージの一部として含まれています。メッセージで運ばダイジェストの大きさは12オクテットです。プライベート認証キー（秘密）の大きさが16オクテットです。詳細は6.3節を参照してください。
This section contains definitions required to realize the authentication module defined in this section of this memo.
このセクションでは、このメモのこのセクションで定義された認証モジュールを実現するために必要な定義が含まれています。
Authentication using this authentication protocol makes use of a defined set of userNames. For any user on whose behalf a message must be authenticated at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user.
この認証プロトコルを使用した認証は、ユーザ名の定義されたセットを利用します。代わって、任意のユーザのためのメッセージは、SNMPエンジンは、そのユーザの知識を持っていなければならないこと、特定のSNMPエンジンで認証する必要があります。別のSNMPエンジンと通信したいSNMPエンジンはまた、ユーザの適用可能な属性の知識を含め、そのエンジンに知られているユーザの知識を有していなければなりません。
A user and its attributes are defined as follows:
次のようにユーザーとその属性が定義されています。
<userName> A string representing the name of the user. <authKey> A user's secret key to be used when calculating a digest. It MUST be 16 octets long for MD5.
<ユーザー名>ユーザーの名前を表す文字列。 <てAuthKey>ダイジェストを計算する際に、ユーザの秘密鍵を使用します。これは、MD5のために16オクテット長でなければなりません。
The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC2571]).
認証されたメッセージに含まmsgAuthoritativeEngineID値（SNMPアーキテクチャ文書[RFC2571]でのsnmpEngineIDの定義を参照）、その特定のメッセージのための正式のSNMPエンジンを指定します。
The user's (private) authentication key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the authentication process.
ユーザーの（プライベート）認証キーがそれぞれの正式のSNMPエンジンで通常異なっているので、のsnmpEngineIDは、認証プロセスのための適切なキーを選択するために使用されます。
Messages using this authentication protocol carry a msgAuthenticationParameters field as part of the msgSecurityParameters. For this protocol, the msgAuthenticationParameters field is the serialized OCTET STRING representing the first 12 octets of the HMAC-MD5-96 output done over the wholeMsg.
この認証プロトコルを使用したメッセージは、msgSecurityParametersの一部としてmsgAuthenticationParametersフィールドを運びます。このプロトコルのために、msgAuthenticationParametersフィールドはwholeMsgにわたって行わHMAC-MD5-96出力の最初の12個のオクテットを表すシリアル化されたオクテット列です。
The digest is calculated over the wholeMsg so if a message is authenticated, that also means that all the fields in the message are intact and have not been tampered with.
メッセージは、メッセージ内のすべてのフィールドは無傷であり、改ざんされていないことを意味し、認証されているので、もしダイジェストがwholeMsgの上に計算されます。
This section describes the inputs and outputs that the HMAC-MD5-96 Authentication module expects and produces when the User-based Security module calls the HMAC-MD5-96 Authentication module for services.
このセクションでは、HMAC-MD5-96認証モジュールが期待するとユーザベースセキュリティモジュールは、サービスのためのHMAC-MD5-96認証モジュールを呼び出したときに生成入力と出力について説明します。
The HMAC-MD5-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used.
HMAC-MD5-96認証プロトコルは、てAuthKeyの選択は、発信者が、発信者が使用する秘密鍵を渡すことが行われていることを前提としています。
Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg with the digest inserted at the proper place. The abstract service primitive is:
完了時に認証モジュールは、メッセージダイジェストが正しく計算された場合、ダイジェストとwholeMsgが適切な場所に挿入され、statusInformationをを返し。原始的な抽象サービスは以下のとおりです。
statusInformation = -- success or failure authenticateOutgoingMsg( IN authKey -- secret key for authentication IN wholeMsg -- unauthenticated complete message OUT authenticatedWholeMsg -- complete authenticated message )
statusInformationを= - （てAuthKey、IN - wholeMsgでの認証用の秘密鍵 - 認証されていない完全なメッセージOUT authenticatedWholeMsg - 完全な認証されたメッセージ）を成功または失敗authenticateOutgoingMsg
The abstract data elements are:
抽象データ要素は次のとおりです。
statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 16 octets. wholeMsg The message to be authenticated. authenticatedWholeMsg The authenticated message (including inserted digest) on output.
認証プロセスが成功したかどうかの表示をステータス情報。そうでない場合には、問題の兆候です。秘密鍵てAuthKey認証アルゴリズムによって使用されます。このキーの長さは16個のオクテットでなければなりません。メッセージが認証されるwholeMsg。出力オン（挿入ダイジェストを含む）認証されたメッセージをauthenticatedWholeMsg。
Note, that authParameters field is filled by the authentication module and this module and this field should be already present in the wholeMsg before the Message Authentication Code (MAC) is generated.
authParametersフィールドが認証モジュールと、このモジュールにより充填され、メッセージ認証コード（MAC）が生成される前に、このフィールドはwholeMsgに既に存在しなければならないことに、留意されたいです。
The HMAC-MD5-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used.
HMAC-MD5-96認証プロトコルは、てAuthKeyの選択は、発信者が、発信者が使用する秘密鍵を渡すことが行われていることを前提としています。
Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg as it was processed. The abstract service primitive is:
完了時に認証モジュールは、それが処理されたように、メッセージダイジェストが正しく、wholeMsgを算出した場合、statusInformationをを返し。原始的な抽象サービスは以下のとおりです。
statusInformation = -- success or failure authenticateIncomingMsg( IN authKey -- secret key for authentication IN authParameters -- as received on the wire IN wholeMsg -- as received on the wire OUT authenticatedWholeMsg -- complete authenticated message )
statusInformationを= - 成功または失敗authenticateIncomingMsg（てAuthKey、IN - authParametersでの認証用の秘密鍵 - wholeMsgワイヤ上で受信される - 受け取ったとして、ワイヤOUT authenticatedWholeMsgに - 完全な認証されたメッセージ）
The abstract data elements are:
抽象データ要素は次のとおりです。
statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 16 octets. authParameters The authParameters from the incoming message. wholeMsg The message to be authenticated on input and the authenticated message on output. authenticatedWholeMsg The whole message after the authentication check is complete.
認証プロセスが成功したかどうかの表示をステータス情報。そうでない場合には、問題の兆候です。秘密鍵てAuthKey認証アルゴリズムによって使用されます。このキーの長さは16個のオクテットでなければなりません。受信メッセージからauthParametersをauthParameters。メッセージは、入力と出力に認証されたメッセージに認証されるwholeMsg。認証チェックが完了した後に、メッセージ全体をauthenticatedWholeMsg。
This section describes the procedures for the HMAC-MD5-96 authentication protocol.
このセクションでは、HMAC-MD5-96認証プロトコルのための手順を説明します。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an outgoing message using the usmHMACMD5AuthProtocol.
このセクションでは、それがusmHMACMD5AuthProtocolを使用して送信メッセージを認証しなければならない時はいつでもSNMPエンジンに続いて手順を説明します。
1) The msgAuthenticationParameters field is set to the serialization, according to the rules in [RFC1906], of an OCTET STRING containing 12 zero octets.
1）msgAuthenticationParametersフィールドは12ゼロ個のオクテットを含むオクテット文字列の[RFC1906]のルールに従って、シリアライゼーションに設定されています。
2) From the secret authKey, two keys K1 and K2 are derived:
2）秘密てAuthKeyからは、二つの鍵K1とK2が導き出されます。
a) extend the authKey to 64 octets by appending 48 zero
octets; save it as extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
3) Prepend K1 to the wholeMsg and calculate MD5 digest over it according to [MD5].
3）wholeMsgの先頭に追加K1及び[MD5]によれば、上にMD5ダイジェストを計算します。
4) Prepend K2 to the result of the step 4 and calculate MD5 digest over it according to [MD5]. Take the first 12 octets of the final digest - this is Message Authentication Code (MAC).
4）プリペンドK2は、ステップ4の結果および[MD5]によれば、上にMD5ダイジェストを計算します。最終ダイジェストの最初の12個のオクテットを取る - これは、メッセージ認証コード（MAC）です。
5) Replace the msgAuthenticationParameters field with MAC obtained in the step 4.
5）工程4で得られたMACとmsgAuthenticationParametersフィールドを交換します。
6) The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success.
6）authenticatedWholeMsgは、次に成功を示すstatusInformationを一緒に呼び出し元に戻されます。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using the usmHMACMD5AuthProtocol.
このセクションでは、usmHMACMD5AuthProtocolを使用して、着信メッセージを認証しなければならないたびにSNMPエンジンの処理手順を記述しています。
1) If the digest received in the msgAuthenticationParameters field is not 12 octets long, then an failure and an errorIndication (authenticationError) is returned to the calling module.
1）ダイジェストがmsgAuthenticationParametersフィールドに受信した場合、故障とerrorIndication（authenticationError）が呼び出し側モジュールに戻される長い12個のオクテットではありません。
2) The MAC received in the msgAuthenticationParameters field is saved.
2）MACフィールドが保存されmsgAuthenticationParametersで受信しました。
3) The digest in the msgAuthenticationParameters field is replaced by the 12 zero octets.
3）msgAuthenticationParametersフィールドのダイジェストは、12個のゼロオクテットで置き換えられています。
4) From the secret authKey, two keys K1 and K2 are derived:
4）秘密てAuthKeyからは、二つの鍵K1とK2が導き出されます。
a) extend the authKey to 64 octets by appending 48 zero
octets; save it as extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
5) The MAC is calculated over the wholeMsg:
5）MACはwholeMsgにわたって計算されます。
a) prepend K1 to the wholeMsg and calculate the MD5 digest
over it;
b) prepend K2 to the result of step 5.a and calculate the
MD5 digest over it;
c) first 12 octets of the result of step 5.b is the MAC.
The msgAuthenticationParameters field is replaced with the MAC value that was saved in step 2.
msgAuthenticationParametersフィールドは、ステップ2で保存されたMAC値に置き換えられます。
6) Then the newly calculated MAC is compared with the MAC saved in step 2. If they do not match, then an failure and an errorIndication (authenticationFailure) is returned to the calling module.
それらが一致しない場合、MACは、その後故障とerrorIndication（のauthenticationFailure）を呼ぶモジュールに戻され、ステップ2で保存で6）次に、新たに計算されたMACが比較されます。
7) The authenticatedWholeMsg and statusInformation indicating success are then returned to the caller.
7）authenticatedWholeMsgとstatusInformationを示す成功は、その後、呼び出し側に返されます。
This section describes the HMAC-SHA-96 authentication protocol. This protocol uses the SHA hash-function which is described in [SHA-NIST], in HMAC mode described in [RFC2104], truncating the output to 96 bits.
このセクションでは、HMAC-SHA-96認証プロトコルを記述する。このプロトコルは、96ビット出力を切り捨て、[RFC2104]に記載HMACモードで、[SHA-NIST]に記載されているSHAハッシュ関数を使用します。
This protocol is identified by usmHMACSHAAuthProtocol.
このプロトコルはusmHMACSHAAuthProtocolによって識別されます。
Over time, other authentication protocols may be defined either as a replacement of this protocol or in addition to this protocol.
時間をかけて、他の認証プロトコルは、このプロトコルの代替として、またはこのプロトコルに加えてのいずれかで定義されてもよいです。
- In support of data integrity, a message digest algorithm is required. A digest is calculated over an appropriate portion of an SNMP message and included as part of the message sent to the recipient.
- データの整合性のサポートでは、メッセージダイジェストアルゴリズムが必要です。ダイジェストはSNMPメッセージの適切な部分にわたって計算され、受信者に送信されたメッセージの一部として含まれています。
- In support of data origin authentication and data integrity, a secret value is prepended to the SNMP message prior to computing the digest; the calculated digest is then partially inserted into the message prior to transmission. The prepended secret is not transmitted. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user.
- データ発信元認証およびデータの整合性のサポートでは、秘密の値は、ダイジェストを計算する前に、SNMPメッセージに付加されています。計算されたダイジェストは、次いで、部分的に送信する前にメッセージに挿入されます。プリペンド秘密は送信されません。秘密の値は、適切なユーザーの代わりにメッセージを発信することを許可すべてのSNMPエンジンによって共有されています。
The Digest Authentication Mechanism defined in this memo provides for:
このメモで定義されたダイジェスト認証メカニズムは、のために用意されています。
- verification of the integrity of a received message, i.e., the the message received is the message sent.
- 受信されたメッセージ、すなわち、受信したメッセージが送信されたメッセージでの整合性の検証。
The integrity of the message is protected by computing a digest over an appropriate portion of the message. The digest is computed by the originator of the message, transmitted with the message, and verified by the recipient of the message.
メッセージの完全性は、メッセージの適切な部分の上にダイジェストを計算することによって保護されています。ダイジェストは、メッセージで送信されたメッセージの発信元で計算され、メッセージの受信者によって検証されます。
- verification of the user on whose behalf the message was generated.
- メッセージが生成されたその代わりに、ユーザーの検証。
A secret value known only to SNMP engines authorized to generate messages on behalf of a user is used in HMAC mode (see [RFC2104]). It also recommends the hash-function output used as Message Authentication Code, to be truncated.
唯一のユーザーに代わってメッセージを生成することを許可SNMPエンジンに知られている秘密の値がHMACモードで使用されている（[RFC2104]を参照）。それはまた、メッセージ認証コードとして使用されるハッシュ関数の出力、トランケートされることをお勧めします。
This mechanism uses the SHA [SHA-NIST] message digest algorithm. A 160-bit SHA digest is calculated in a special (HMAC) way over the designated portion of an SNMP message and the first 96 bits of this digest is included as part of the message sent to the recipient. The size of the digest carried in a message is 12 octets. The size of the private authentication key (the secret) is 20 octets. For the details see section 7.3.
この機構は、SHA [SHA-NIST]メッセージダイジェストアルゴリズムを使用します。 160ビットSHAダイジェストはSNMPメッセージの指定された部分と、このダイジェストの最初の96ビットを超える特別な（HMAC）のように算出される受信者に送信されたメッセージの一部として含まれています。メッセージで運ばダイジェストの大きさは12オクテットです。プライベート認証キー（秘密）の大きさが20オクテットです。詳細は7.3節を参照してください。
This section contains definitions required to realize the authentication module defined in this section of this memo.
このセクションでは、このメモのこのセクションで定義された認証モジュールを実現するために必要な定義が含まれています。
Authentication using this authentication protocol makes use of a defined set of userNames. For any user on whose behalf a message must be authenticated at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user.
この認証プロトコルを使用した認証は、ユーザ名の定義されたセットを利用します。代わって、任意のユーザのためのメッセージは、SNMPエンジンは、そのユーザの知識を持っていなければならないこと、特定のSNMPエンジンで認証する必要があります。別のSNMPエンジンと通信したいSNMPエンジンはまた、ユーザの適用可能な属性の知識を含め、そのエンジンに知られているユーザの知識を有していなければなりません。
A user and its attributes are defined as follows:
次のようにユーザーとその属性が定義されています。
<userName> A string representing the name of the user. <authKey> A user's secret key to be used when calculating a digest. It MUST be 20 octets long for SHA.
<ユーザー名>ユーザーの名前を表す文字列。 <てAuthKey>ダイジェストを計算する際に、ユーザの秘密鍵を使用します。それは長いSHAのための20個のオクテットでなければなりません。
The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC2571]).
認証されたメッセージに含まmsgAuthoritativeEngineID値（SNMPアーキテクチャ文書[RFC2571]でのsnmpEngineIDの定義を参照）、その特定のメッセージのための正式のSNMPエンジンを指定します。
The user's (private) authentication key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the authentication process.
ユーザーの（プライベート）認証キーがそれぞれの正式のSNMPエンジンで通常異なっているので、のsnmpEngineIDは、認証プロセスのための適切なキーを選択するために使用されます。
Messages using this authentication protocol carry a msgAuthenticationParameters field as part of the msgSecurityParameters. For this protocol, the msgAuthenticationParameters field is the serialized OCTET STRING representing the first 12 octets of HMAC-SHA-96 output done over the wholeMsg.
この認証プロトコルを使用したメッセージは、msgSecurityParametersの一部としてmsgAuthenticationParametersフィールドを運びます。このプロトコルのために、msgAuthenticationParametersフィールドはwholeMsgにわたって行わHMAC-SHA-96の出力の最初の12個のオクテットを表すシリアル化されたオクテット列です。
The digest is calculated over the wholeMsg so if a message is authenticated, that also means that all the fields in the message are intact and have not been tampered with.
メッセージは、メッセージ内のすべてのフィールドは無傷であり、改ざんされていないことを意味し、認証されているので、もしダイジェストがwholeMsgの上に計算されます。
This section describes the inputs and outputs that the HMAC-SHA-96 Authentication module expects and produces when the User-based Security module calls the HMAC-SHA-96 Authentication module for services.
このセクションでは、HMAC-SHA-96認証モジュールが期待およびユーザベースのセキュリティモジュールは、サービスのためのHMAC-SHA-96認証モジュールを呼び出したときに生成入力および出力を記述する。
HMAC-SHA-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used.
HMAC-SHA-96認証プロトコルは、てAuthKeyの選択は、発信者が、発信者が使用する秘密鍵を渡すことが行われていることを前提としています。
Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg with the digest inserted at the proper place. The abstract service primitive is:
完了時に認証モジュールは、メッセージダイジェストが正しく計算された場合、ダイジェストとwholeMsgが適切な場所に挿入され、statusInformationをを返し。原始的な抽象サービスは以下のとおりです。
statusInformation = -- success or failure authenticateOutgoingMsg( IN authKey -- secret key for authentication IN wholeMsg -- unauthenticated complete message OUT authenticatedWholeMsg -- complete authenticated message )
statusInformationを= - （てAuthKey、IN - wholeMsgでの認証用の秘密鍵 - 認証されていない完全なメッセージOUT authenticatedWholeMsg - 完全な認証されたメッセージ）を成功または失敗authenticateOutgoingMsg
The abstract data elements are:
抽象データ要素は次のとおりです。
statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 20 octets. wholeMsg The message to be authenticated. authenticatedWholeMsg The authenticated message (including inserted digest) on output.
認証プロセスが成功したかどうかの表示をステータス情報。そうでない場合には、問題の兆候です。秘密鍵てAuthKey認証アルゴリズムによって使用されます。このキーの長さは20個のオクテットでなければなりません。メッセージが認証されるwholeMsg。出力オン（挿入ダイジェストを含む）認証されたメッセージをauthenticatedWholeMsg。
Note, that authParameters field is filled by the authentication module and this field should be already present in the wholeMsg before the Message Authentication Code (MAC) is generated.
authParametersフィールドが認証モジュールによって充填され、メッセージ認証コード（MAC）が生成される前に、このフィールドはwholeMsgに既に存在しなければならないことに、留意されたいです。
HMAC-SHA-96 authentication protocol assumes that the selection of the authKey is done by the caller and that the caller passes the secret key to be used.
HMAC-SHA-96認証プロトコルは、てAuthKeyの選択は、発信者が、発信者が使用する秘密鍵を渡すことが行われていることを前提としています。
Upon completion the authentication module returns statusInformation and, if the message digest was correctly calculated, the wholeMsg as it was processed. The abstract service primitive is:
完了時に認証モジュールは、それが処理されたように、メッセージダイジェストが正しく、wholeMsgを算出した場合、statusInformationをを返し。原始的な抽象サービスは以下のとおりです。
statusInformation = -- success or failure authenticateIncomingMsg( IN authKey -- secret key for authentication IN authParameters -- as received on the wire IN wholeMsg -- as received on the wire OUT authenticatedWholeMsg -- complete authenticated message )
statusInformationを= - 成功または失敗authenticateIncomingMsg（てAuthKey、IN - authParametersでの認証用の秘密鍵 - wholeMsgワイヤ上で受信される - 受け取ったとして、ワイヤOUT authenticatedWholeMsgに - 完全な認証されたメッセージ）
The abstract data elements are:
抽象データ要素は次のとおりです。
statusInformation An indication of whether the authentication process was successful. If not it is an indication of the problem. authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 20 octets. authParameters The authParameters from the incoming message. wholeMsg The message to be authenticated on input and the authenticated message on output. authenticatedWholeMsg The whole message after the authentication check is complete.
認証プロセスが成功したかどうかの表示をステータス情報。そうでない場合には、問題の兆候です。秘密鍵てAuthKey認証アルゴリズムによって使用されます。このキーの長さは20個のオクテットでなければなりません。受信メッセージからauthParametersをauthParameters。メッセージは、入力と出力に認証されたメッセージに認証されるwholeMsg。認証チェックが完了した後に、メッセージ全体をauthenticatedWholeMsg。
This section describes the procedures for the HMAC-SHA-96 authentication protocol.
このセクションでは、HMAC-SHA-96認証プロトコルのための手順を記載しています。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an outgoing message using the usmHMACSHAAuthProtocol.
このセクションでは、それがusmHMACSHAAuthProtocolを使用して送信メッセージを認証しなければならない時はいつでもSNMPエンジンに続いて手順を説明します。
1) The msgAuthenticationParameters field is set to the serialization, according to the rules in [RFC1906], of an OCTET STRING containing 12 zero octets.
1）msgAuthenticationParametersフィールドは12ゼロ個のオクテットを含むオクテット文字列の[RFC1906]のルールに従って、シリアライゼーションに設定されています。
2) From the secret authKey, two keys K1 and K2 are derived:
2）秘密てAuthKeyからは、二つの鍵K1とK2が導き出されます。
a) extend the authKey to 64 octets by appending 44 zero
octets; save it as extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
3) Prepend K1 to the wholeMsg and calculate the SHA digest over it according to [SHA-NIST].
3）プリペンドK1はwholeMsgおよび[SHA-NIST]によれば、上SHAダイジェストを計算します。
4) Prepend K2 to the result of the step 4 and calculate SHA digest over it according to [SHA-NIST]. Take the first 12 octets of the final digest - this is Message Authentication Code (MAC).
4）プリペンドステップ4の結果をK2と計算SHAは[SHA-NIST]によれば、上消化します。最終ダイジェストの最初の12個のオクテットを取る - これは、メッセージ認証コード（MAC）です。
5) Replace the msgAuthenticationParameters field with MAC obtained in the step 5.
5）工程5で得られたMACとmsgAuthenticationParametersフィールドを交換します。
6) The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success.
6）authenticatedWholeMsgは、次に成功を示すstatusInformationを一緒に呼び出し元に戻されます。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using the usmHMACSHAAuthProtocol.
このセクションでは、usmHMACSHAAuthProtocolを使用して、着信メッセージを認証しなければならないたびにSNMPエンジンの処理手順を記述しています。
1) If the digest received in the msgAuthenticationParameters field is not 12 octets long, then an failure and an errorIndication (authenticationError) is returned to the calling module.
1）ダイジェストがmsgAuthenticationParametersフィールドに受信した場合、故障とerrorIndication（authenticationError）が呼び出し側モジュールに戻される長い12個のオクテットではありません。
2) The MAC received in the msgAuthenticationParameters field is saved.
2）MACフィールドが保存されmsgAuthenticationParametersで受信しました。
3) The digest in the msgAuthenticationParameters field is replaced by the 12 zero octets.
3）msgAuthenticationParametersフィールドのダイジェストは、12個のゼロオクテットで置き換えられています。
4) From the secret authKey, two keys K1 and K2 are derived:
4）秘密てAuthKeyからは、二つの鍵K1とK2が導き出されます。
a) extend the authKey to 64 octets by appending 44 zero
octets; save it as extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
5) The MAC is calculated over the wholeMsg:
5）MACはwholeMsgにわたって計算されます。
a) prepend K1 to the wholeMsg and calculate the SHA digest
over it;
b) prepend K2 to the result of step 5.a and calculate the
SHA digest over it;
c) first 12 octets of the result of step 5.b is the MAC.
The msgAuthenticationParameters field is replaced with the MAC value that was saved in step 2.
msgAuthenticationParametersフィールドは、ステップ2で保存されたMAC値に置き換えられます。
6) The the newly calculated MAC is compared with the MAC saved in step 2. If they do not match, then a failure and an errorIndication (authenticationFailure) are returned to the calling module.
MACが一致しない場合は、故障とerrorIndication（のauthenticationFailure）を呼ぶモジュールに戻され、ステップ2で保存で6）新たに計算されたMACが比較されます。
7) The authenticatedWholeMsg and statusInformation indicating success are then returned to the caller.
7）authenticatedWholeMsgとstatusInformationを示す成功は、その後、呼び出し側に返されます。
This section describes the CBC-DES Symmetric Encryption Protocol. This protocol is the first privacy protocol defined for the User-based Security Model.
このセクションでは、CBC-DES対称暗号化プロトコルを記述しています。このプロトコルは、ユーザベースセキュリティモデルのために定義された最初のプライバシープロトコルです。
This protocol is identified by usmDESPrivProtocol.
このプロトコルはusmDESPrivProtocolによって識別されます。
Over time, other privacy protocols may be defined either as a replacement of this protocol or in addition to this protocol.
時間が経つにつれて、他のプライバシープロトコルは、このプロトコルの代替として、またはこのプロトコルに加えてのいずれかで定義されてもよいです。
- In support of data confidentiality, an encryption algorithm is required. An appropriate portion of the message is encrypted prior to being transmitted. The User-based Security Model specifies that the scopedPDU is the portion of the message that needs to be encrypted.
- データの機密性のサポートでは、暗号化アルゴリズムが必要です。メッセージの適切な部分は、前に送信されることに暗号化されます。ユーザベースセキュリティモデルは、scopedPDUには、暗号化する必要のあるメッセージの一部であることを指定します。
- A secret value in combination with a timeliness value is used to create the en/decryption key and the initialization vector. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user.
- タイムリー値と組み合わせて秘密の値は、EN /復号化鍵および初期化ベクトルを作成するために使用されます。秘密の値は、適切なユーザーの代わりにメッセージを発信することを許可すべてのSNMPエンジンによって共有されています。
The Symmetric Encryption Protocol defined in this memo provides support for data confidentiality. The designated portion of an SNMP message is encrypted and included as part of the message sent to the recipient.
このメモで定義された対称暗号化プロトコルは、データの機密性のためのサポートを提供します。 SNMPメッセージの指定された部分は、暗号化され、受信者に送信されたメッセージの一部として含まれています。
Two organizations have published specifications defining the DES: the National Institute of Standards and Technology (NIST) [DES-NIST] and the American National Standards Institute [DES-ANSI]. There is a companion Modes of Operation specification for each definition ([DESO-NIST] and [DESO-ANSI], respectively).
国立標準技術研究所（NIST）[DES-NIST]と米国規格協会[DES-ANSI]：二つの組織は、仕様DESの定義を公開しています。各定義の動作仕様のコンパニオン・モード（それぞれ[DESO-NIST]と[DESO-ANSI]）があります。
The NIST has published three additional documents that implementors may find useful.
NISTは、実装者が有用見つけるかもしれ三つの追加書類を公開しています。
- There is a document with guidelines for implementing and using the DES, including functional specifications for the DES and its modes of operation [DESG-NIST].
- DESとその運転モードのための機能仕様[DESG-NIST]を含め、DESを実装して使用する際のガイドラインとの文書があります。
- There is a specification of a validation test suite for the DES [DEST-NIST]. The suite is designed to test all aspects of the DES and is useful for pinpointing specific problems.
- DES [DEST-NIST]の検証テストスイートの仕様があります。スイートは、DESのすべての側面をテストするために設計されており、特定の問題を特定するために有用です。
- There is a specification of a maintenance test for the DES [DESM-NIST]. 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 re-boots.
- DES [DESM-NIST]の保守試験の仕様があります。試験は、DESのすべてのコンポーネントをテストするためのデータ及び処理の最小量を使用します。これは、正しい動作の単純なイエス・オア・兆候を提供せず、初期化ステップの一部として実行することが有用であり、例えば、ときにコンピュータを再起動します。
The first 8 octets of the 16-octet secret (private privacy key) are used as a DES key. Since DES uses only 56 bits, the Least Significant Bit in each octet is disregarded.
16オクテットの秘密（個人的なプライバシーキー）の最初の8つのオクテットは、DESのキーとして使用されています。 DESは56ビットのみを使用するので、各オクテットの最下位ビットは無視されます。
The Initialization Vector for encryption is obtained using the following procedure.
暗号化のための初期化ベクトルは、次の手順を使用して得られます。
The last 8 octets of the 16-octet secret (private privacy key) are used as pre-IV.
16オクテットの秘密（個人的なプライバシーキー）の最後の8つのオクテットは、事前-IVとして使用されています。
In order to ensure that the IV for two different packets encrypted by the same key, are not the same (i.e., the IV does not repeat) we need to "salt" the pre-IV with something unique per packet. An 8-octet string is used as the "salt". The concatenation of the generating SNMP engine's 32-bit snmpEngineBoots and a local 32-bit integer, that the encryption engine maintains, is input to the "salt". The 32-bit integer is initialized to an arbitrary value at boot time.
同じキーで暗号化された二つの異なるパケットに対するIVは、同じではないことを確実にするために（すなわち、IVが繰り返されません）私たちは、「塩」、パケットごとに固有のもので、事前-IVにする必要があります。 8オクテット文字列は「塩」として使用されています。生成SNMPエンジンの32ビットのsnmpEngineBootsとローカルの32ビット整数の連結は、暗号化エンジンを保持している、「塩」に入力されます。 32ビット整数は、起動時に任意の値に初期化されます。
The 32-bit snmpEngineBoots is converted to the first 4 octets (Most Significant Byte first) of our "salt". The 32-bit integer is then converted to the last 4 octet (Most Significant Byte first) of our "salt". The resulting "salt" is then XOR-ed with the pre-IV to obtain the IV. The 8-octet "salt" is then put into the privParameters field encoded as an OCTET STRING. The "salt" integer is then modified. We recommend that it be incremented by one and wrap when it reaches the maximum value.
32ビットのsnmpEngineBootsは、当社の「塩」の最初の4つのオクテット（最上位バイトが最初）に変換されます。 32ビット整数は、最後の4オクテットに私達の「塩」の（最上位バイト）に変換されます。得られた「塩」その後、IVを得るために、事前-IVとのXOR演算です。 8オクテット「塩」その後、OCTET STRINGとしてコード化さprivParametersフィールドに入れられます。 「塩」整数は、次に変更されます。私たちは、それが1ずつ増加し、それが最大値に達したときにラップすることをお勧めします。
How exactly the value of the "salt" (and thus of the IV) varies, is an implementation issue, as long as the measures are taken to avoid producing a duplicate IV.
（したがって、IVの）「塩」の値がどのように変化するかを正確に、限りの対策が重複IVを生成しないように注意しているとして、実装上の問題です。
The "salt" must be placed in the privParameters field to enable the receiving entity to compute the correct IV and to decrypt the message.
「塩」は、正しいIVを計算するために、メッセージを解読するために受信エンティティを有効にするprivParametersフィールドに配置しなければなりません。
The data to be encrypted is treated as sequence of octets. Its length should be an integral multiple of 8 - and if it is not, the data is padded at the end as necessary. The actual pad value is irrelevant.
暗号化されるデータは、オクテットのシーケンスとして扱われます。その長さは8の倍数でなければならない - それがない場合、データは、必要に応じて端部に埋め込まれています。実際のパッド値は無関係です。
The data is encrypted in Cipher Block Chaining mode.
データは暗号ブロック連鎖モードで暗号化されています。
The plaintext is divided into 64-bit blocks.
平文は、64ビットのブロックに分割されます。
The plaintext for each block is XOR-ed with the ciphertext of the previous block, the result is encrypted and the output of the encryption is the ciphertext for the block. This procedure is repeated until there are no more plaintext blocks.
各ブロックの平文は、前のブロックの暗号文とXOR-EDで、結果は暗号化され、暗号化の出力は、ブロックの暗号文です。これ以上の平文ブロックが存在しなくなるまでこの手順を繰り返します。
For the very first block, the Initialization Vector is used instead of the ciphertext of the previous block.
非常に最初のブロックのために、初期化ベクトルではなく、前のブロックの暗号文で使用されます。
Before decryption, the encrypted data length is verified. If the length of the OCTET STRING to be decrypted is not an integral multiple of 8 octets, the decryption process is halted and an appropriate exception noted. When decrypting, the padding is ignored.
復号化する前に、暗号化されたデータ長が検証されます。復号化されるオクテットストリングの長さが8つのオクテットの整数倍でない場合、復号処理は停止し、適切な例外が注目されます。解読すると、パディングは無視されます。
The first ciphertext block is decrypted, the decryption output is XOR-ed with the Initialization Vector, and the result is the first plaintext block.
第一の暗号文ブロックを復号化し、復号化出力は、初期化ベクトルとの排他的論理和演算され、その結果が最初の平文ブロックです。
For each subsequent block, the ciphertext block is decrypted, the decryption output is XOR-ed with the previous ciphertext block and the result is the plaintext block.
後続の各ブロックについて、暗号文ブロックを復号化し、復号化出力は、前の暗号文ブロックとXORされ、結果は平文ブロックです。
This section contains definitions required to realize the privacy module defined by this memo.
このセクションでは、このメモで定義されたプライバシーモジュールを実現するために必要な定義が含まれています。
Data en/decryption using this Symmetric Encryption Protocol makes use of a defined set of userNames. For any user on whose behalf a message must be en/decrypted at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that SNMP engine, including knowledge of the applicable attributes of that user.
この対称暗号化プロトコルを使用してデータアン/復号化はユーザ名の定義されたセットを利用します。代わって、任意のユーザのためのメッセージは、SNMPエンジンは、そのユーザの知識を持っている必要があることを、EN /特定のSNMPエンジンで復号化しなければなりません。別のSNMPエンジンと通信したいSNMPエンジンはまた、ユーザの適用可能な属性の知識を含め、そのSNMPエンジンに知られているユーザの知識を有していなければなりません。
A user and its attributes are defined as follows:
次のようにユーザーとその属性が定義されています。
<userName> An octet string representing the name of the user.
<ユーザー名>のユーザーの名前を表すオクテット文字列。
<privKey> A user's secret key to be used as input for the DES key and IV. The length of this key MUST be 16 octets.
<privKey>利用者の秘密鍵は、DESのキーとIVのための入力として使用されます。このキーの長さは16個のオクテットでなければなりません。
The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC2571]).
認証されたメッセージに含まmsgAuthoritativeEngineID値（SNMPアーキテクチャ文書[RFC2571]でのsnmpEngineIDの定義を参照）、その特定のメッセージのための正式のSNMPエンジンを指定します。
The user's (private) privacy key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the en/decryption process.
ユーザーの（プライベート）のプライバシーキーがそれぞれの正式のSNMPエンジンで通常異なっているので、のsnmpEngineIDはアン/復号化プロセスのための適切なキーを選択するために使用されます。
Messages using this privacy protocol carry a msgPrivacyParameters field as part of the msgSecurityParameters. For this protocol, the msgPrivacyParameters field is the serialized OCTET STRING representing the "salt" that was used to create the IV.
このプライバシープロトコルを使用したメッセージは、msgSecurityParametersの一部としてmsgPrivacyParametersフィールドを運びます。このプロトコルでは、msgPrivacyParametersフィールドはIVを作成するために使用された「塩」を表す連載されたOCTET STRINGです。
This section describes the inputs and outputs that the DES Privacy module expects and produces when the User-based Security module invokes the DES Privacy module for services.
このセクションでは、DESプライバシーモジュールが期待するとユーザベースセキュリティモジュールは、サービスのためのDESプライバシーモジュールを呼び出したときに生成入力と出力について説明します。
This DES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used.
このDESプライバシープロトコルはprivKeyの選択は、呼び出し側によって、呼び出し元が使用する秘密鍵を渡すことで行われていることを前提としています。
Upon completion the privacy module returns statusInformation and, if the encryption process was successful, the encryptedPDU and the msgPrivacyParameters encoded as an OCTET STRING. The abstract service primitive is:
完了時にプライバシーモジュールは、暗号化プロセスが成功した場合、encryptedPDUとmsgPrivacyParametersはOCTET STRINGとしてエンコードされ、statusInformationをを返し。原始的な抽象サービスは以下のとおりです。
statusInformation = -- success of failure encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU)
dataToEncryptでの暗号化のための秘密鍵 - - 暗号化するデータ（scopedPDUに）statusInformationを= - encryptKeyに失敗encryptData（の成功
OUT encryptedData -- encrypted data (encryptedPDU) OUT privParameters -- filled in by service provider )
サービスプロバイダによって記入） - OUTはEncryptedData - 暗号化されたデータ（encryptedPDU）OUT privParameters
The abstract data elements are:
抽象データ要素は次のとおりです。
statusInformation An indication of the success or failure of the encryption process. In case of failure, it is an indication of the error. encryptKey The secret key to be used by the encryption algorithm. The length of this key MUST be 16 octets. dataToEncrypt The data that must be encrypted. encryptedData The encrypted data upon successful completion. privParameters The privParameters encoded as an OCTET STRING.
暗号化プロセスの成功または失敗の表示をステータス情報。障害が発生した場合には、エラーの指標です。 encryptKey秘密鍵は、暗号化アルゴリズムによって使用されます。このキーの長さは16個のオクテットでなければなりません。暗号化されなければならないデータdataToEncrypt。正常に完了した場合はEncryptedData暗号化されたデータ。 OCTET STRINGとしてエンコードさprivParametersをprivParameters。
This DES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used.
このDESプライバシープロトコルはprivKeyの選択は、呼び出し側によって、呼び出し元が使用する秘密鍵を渡すことで行われていることを前提としています。
Upon completion the privacy module returns statusInformation and, if the decryption process was successful, the scopedPDU in plain text. The abstract service primitive is:
完了すると、プライバシーモジュールは、復号処理がプレーンテキストで、scopedPDUに成功した場合、statusInformationをを返します。原始的な抽象サービスは以下のとおりです。
statusInformation = decryptData( IN decryptKey -- secret key for decryption IN privParameters -- as received on the wire IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) )
statusInformationを= decryptData（はEncryptedDataワイヤ上で受信した - - decryptKey IN - privParameters、IN復号用の秘密鍵暗号化されたデータ（encryptedPDU）OUT decryptedData - 復号化されたデータ（たscopedPDU））
The abstract data elements are:
抽象データ要素は次のとおりです。
statusInformation An indication whether the data was successfully decrypted and if not an indication of the error. decryptKey The secret key to be used by the decryption algorithm. The length of this key MUST be 16 octets. privParameters The "salt" to be used to calculate the IV.
データが正常にエラーの表示を復号化し、そうでない場合れたかどうかを指示する状態情報。解読アルゴリズムが使用する秘密鍵decryptKey。このキーの長さは16個のオクテットでなければなりません。 IVを計算するのに使用される「塩」をprivParameters。
encryptedData The data to be decrypted. decryptedData The decrypted data.
EncryptedDataデータを復号化します。 decryptedDataザ・データを復号化されます。
This section describes the procedures for the DES privacy protocol.
このセクションでは、DESプライバシープロトコルのための手順を説明します。
This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usmDESPrivProtocol.
このセクションでは、usmDESPrivProtocolを使用して発信メッセージの一部を暗号化しなければならないたびにSNMPエンジンの処理手順を記述しています。
1) The secret cryptKey is used to construct the DES encryption key, the "salt" and the DES pre-IV (from which the IV is computed as described in section 8.1.1.1).
1）秘密cryptKeyは、DES暗号化キー、セクション8.1.1.1に記載されているようにIVが計算される「塩」とDESプリIV（）を構築するために使用されます。
2) The privParameters field is set to the serialization according to the rules in [RFC1906] of an OCTET STRING representing the the "salt" string.
2）privParametersフィールドは「塩」の文字列を表すオクテット文字列の[RFC1906]の規則に従ってシリアル化に設定されています。
3) The scopedPDU is encrypted (as described in section 8.1.1.2) and the encrypted data is serialized according to the rules in [RFC1906] as an OCTET STRING.
3）たscopedPDUは暗号化され（セクション8.1.1.2参照）と暗号化されたデータはOCTET STRINGとして[RFC1906]の規則に従ってシリアル化されます。
4) The serialized OCTET STRING representing the encrypted scopedPDU together with the privParameters and statusInformation indicating success is returned to the calling module.
4）privParametersとstatusInformationを示す成功と共に暗号化されたscopedPDUを表す連載されたOCTET STRINGは、呼び出し側モジュールに戻されます。
This section describes the procedure followed by an SNMP engine whenever it must decrypt part of an incoming message using the usmDESPrivProtocol.
このセクションでは、usmDESPrivProtocolを使用して着信メッセージの一部を復号化しなければならないたびにSNMPエンジンの処理手順を記述しています。
1) If the privParameters field is not an 8-octet OCTET STRING, then an error indication (decryptionError) is returned to the calling module.
1）privParametersフィールドは8オクテットオクテットSTRING、エラー表示（decryptionErrorない場合）呼び出し側モジュールに戻されます。
2) The "salt" is extracted from the privParameters field.
2）「塩」privParametersフィールドから抽出されます。
3) The secret cryptKey and the "salt" are then used to construct the DES decryption key and pre-IV (from which the IV is computed as described in section 8.1.1.1).
3）秘密cryptKeyと「塩」は、セクション8.1.1.1に記載されているようにIVが計算されたDES解読鍵とプレIV（）を構築するために使用されます。
4) The encryptedPDU is then decrypted (as described in section 8.1.1.3).
セクション8.1.1.3に記載されているように4）encryptedPDUはその後）（復号されます。
5) If the encryptedPDU cannot be decrypted, then an error indication (decryptionError) is returned to the calling module.
encryptedPDUを復号できない場合5）、エラー表示（decryptionError）は、呼び出し側モジュールに戻されます。
6) The decrypted scopedPDU and statusInformation indicating success are returned to the calling module.
6）復号化されたscopedPDUとstatusInformationを示す成功は呼ぶモジュールに返されます。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members:
この文書では、SNMPv3の作業部会の努力の結果です。いくつかの特別な感謝は、以下のSNMPv3 WGメンバーへの順序であります：
Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation)) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard)
ハラルド・トバイット・アルベストランド（Maxware）デイヴ・バトル（SNMPリサーチ社）アラン・ビアード（ディズニーワールドワイド・サービス）ポール・Berrevoets（SWIシステムウェア/ハルシオン社）マーティンBjorklund（エリクソン）ウリブルーメンタール（IBM TJワトソン研究所）ジェフケース（SNMPリサーチ社）ジョン・カラン（BBN）マイク・ダニエル（コンパックコンピュータ株式会社））T.マックスデブリン（Eltraxシステムズ）ジョン・フリック（ヒューレット・パッカード）
Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T.J. Watson Research Center)
ロブ・フライ（MCI）ウェスHardaker（UCDavis、情報技術 - DCAS）デヴィッド・ハリントン（Cabletronシステムズ社）ローレン・ハインツ（BMCソフトウェア株式会社）NC飛燕（IBM TJワトソン研究所）マイケル・Kirkham（インターワーキング研究所、（株） ）デイヴ・レビ（SNMPリサーチ社）ルイス・A Mamakos（UUNETテクノロジー株式会社）ジョー・Marzot（ノーテルネットワーク）ネットワークでのポール・メイヤー（セキュアコンピューティング社）キースMcCloghrie（シスコシステムズ）、ボブ・ムーア（IBM）ラスマンディ（TIS研究所アソシエイツ）ボブ・ナターレ（ACE * COMM社）マイク・オデル（UUNETテクノロジー株式会社）デーヴパーキンス（DeskTalk）ピーター・ポーキングホーン（ブルネル大学）ランディPresuhn（BMCソフトウェア株式会社）デビッドReederの（ネットワークアソシエイツでTIS研究所）デビッドリード（SNMPリサーチ社）アレクセイ・ロマノフ（品質クォーラム）ショーンRouthier（エピローグ）ユルゲンSchoenwaelder（TUブラウンシュヴァイク）ボブ・スチュワート（シスコシステムズ）マイク・サッチャー（独立コンサルタント）バートWijnen（IBM TJワトソン研究所）
The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were:
文書は、SNMP諮問チームのためのIETFセキュリティおよび管理フレームワークの進化の勧告に基づいています。その諮問チームのメンバーは以下の通りでした。
David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center)
デヴィッド・ハリントン（Cabletronシステムズ社）ジェフ・ジョンソン（シスコシステムズ）デビッド・レビ（SNMPリサーチ社）ジョン・リン（Openvision）ラスマンディ（信頼できる情報システム）椅子ショーンRouthier（エピローグ）グレン・ウォーターズ（ノーテル）バートWijnen（IBM TJワトソン研究所）
As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*:
諮問チームおよびSNMPv3ワーキンググループ憲章によって推奨されているように、デザインは以前のRFCとドラフトから実用的な限りが組み込まれています。その結果、特別な感謝はSNMPv2uとSNMPv2 *として知られている従来の設計の作者によるものです：
Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.)
ジェフケース（SNMPリサーチ社）デヴィッド・ハリントン（Cabletronシステムズ社）デヴィッドレビ（SNMPリサーチ社）
Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.)
キースMcCloghrie（シスコシステムズ）ブライアン・オキーフ（ヒューレット・パッカード）マーシャルT.ローズ（ドーヴァービーチコンサルティング）ジョンSaperia（BGSシステムズ社）のスティーブWaldbusser（国際ネットワークサービス）グレンW.ウォーターズ（ベル・ノーザン・リサーチ株式会社）
This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo.
このセクションでは、このメモで定義されたメカニズムを安全に、効果的な運用に資するプラクティスについて説明します。
- An SNMP engine must discard SNMP Response messages that do not correspond to any currently outstanding Request message. It is the responsibility of the Message Processing module to take care of this. For example it can use a msgID for that.
- SNMPエンジンは、任意の現在未処理の要求メッセージに対応していないSNMP応答メッセージを破棄しなければなりません。このの世話をするためのメッセージ処理モジュールの責任です。例えば、それは、そのためにMSGIDを使用することができます。
An SNMP Command Generator Application must discard any Response Class PDU for which there is no currently outstanding Confirmed Class PDU; for example for SNMPv2 [RFC1905] PDUs, the request-id component in the PDU can be used to correlate Responses to outstanding Requests.
SNMPコマンドジェネレータアプリケーションはありません現在、卓越した確認クラスPDUがあるため任意の応答クラスPDUを破棄しなければなりません。 SNMPv2の[RFC1905] PDUに対して、例えば、PDU内の要求IDコンポーネントは、未処理の要求に対する応答を相関させるために使用することができます。
Although it would be typical for an SNMP engine and an SNMP Command Generator Application 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).
それは当然のこととしてこれを行うためのSNMPエンジンとSNMPコマンドジェネレータアプリケーションの典型的であるが、これらのセキュリティプロトコルを使用した場合、それが原因メッセージの重複（悪意のあるまたはその他）の可能性に重要です。
- If an SNMP engine uses a msgID for correlating Response messages to outstanding Request messages, then it MUST use different msgIDs in all such Request messages that it sends out during a Time Window (150 seconds) period.
- SNMPエンジンは、未処理の要求メッセージに対する応答メッセージを相関させるためMSGIDを使用している場合、それはそれは時間窓（150秒）の期間中に送信し、すべてのそのような要求メッセージに異なるmsgIDsを使用しなければなりません。
A Command Generator or Notification Originator Application MUST use different request-ids in all Request PDUs that it sends out during a TimeWindow (150 seconds) period.
コマンドジェネレータか通知創始者アプリケーションは、それがTimeWindow（150秒）の期間中に送信するすべての要求のPDUに異なる要求-IDを使用しなければなりません。
This must be done to protect against the possibility of message duplication (malicious or otherwise).
これは、（悪意のあるまたはそれ以外）メッセージの重複の可能性から保護するために行う必要があります。
For example, starting operations with a msgID and/or request-id value of zero is not a good idea. Initializing them with an unpredictable number (so they do not start out the same after each reboot) and then incrementing by one would be acceptable.
例えば、MSGIDおよび/またはゼロの要求ID値を使用して操作を開始することは良い考えではありません。予測不可能な数（そう、彼らはそれぞれの再起動後に同じを起動しない）でそれらを初期化してから1ずつ増加することは許容可能です。
- An SNMP engine should perform time synchronization using authenticated messages in order to protect against the possibility of message duplication (malicious or otherwise).
- SNMPエンジンは、（悪意のある、またはそうでなければ）メッセージの重複の可能性から保護するために認証されたメッセージを使用して時間同期を行うべきです。
- When sending state altering messages to a managed authoritative SNMP engine, a Command Generator Application should delay sending successive messages to that managed SNMP engine until a positive acknowledgement is received for the previous message or until the previous message expires.
- 管理正式のSNMPエンジンに状態変更メッセージを送信する場合、コマンドジェネレータアプリケーションは、肯定応答が前のメッセージまたは前のメッセージの有効期限が切れるまで受信されるまで、それに連続したメッセージを送信すると、SNMPエンジンを管理遅らせる必要があります。
No message ordering is imposed by the SNMP. 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 SNMP engine, 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, an SNMP engine and SNMP Command Generator Applications must cope with the loss and re-ordering of messages resulting from anomalies in the network as a matter of course.
いいえメッセージの順序は、SNMPによって課されていません。メッセージは、世代の彼らの時間に任意の順序の相対で受信されてもよく、それぞれは、順序付けられた受信で処理されます。認証されたメッセージが管理SNMPエンジンに送信されたとき、それは通常の状況下で、約150秒の期間のために有効であり、この期間中に再生される場合がありますのでご注意ください。確かに、SNMPエンジンとSNMPコマンドジェネレータアプリケーションは、当然のこととして、ネットワーク内の異常に起因するメッセージの喪失と再発注に対処しなければなりません。
However, a managed object, snmpSetSerialNo [RFC1907], is specifically defined for use with SNMP Set operations in order to provide a mechanism to ensure that the processing of SNMP messages occurs in a specific order.
しかし、管理オブジェクト、snmpSetSerialNo [RFC1907]は、具体的にはSNMPメッセージの処理は特定の順序で発生することを確実にするメカニズムを提供するために、SNMP Set操作で使用するために定義されています。
- The frequency with which the secrets of a User-based Security Model user should be changed is indirectly related to the frequency of their use.
- ユーザベースセキュリティモデルの利用者の秘密を変更する必要がある頻度は、その使用頻度に間接的に関連しています。
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 used as the communication paths, more caution is prudent.
あまりにも、ローカル環境に開示の脅威はそれほど重要であってもよく、秘密の、このような変化として、それほど頻繁であってもよいし、注意してください。公衆データ網を通信路として使用する場合しかし、より多くの注意が賢明です。
The mechanisms defined in this document employ the notion of users on whose behalf messages are sent. 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 an SNMP Application or a set of SNMP Applications, acting on behalf of an individual or role, or set of individuals, or set of roles, including combinations.
この文書で定義されたメカニズムは、代理メッセージ送信された上でのユーザーの概念を採用しています。どのように「ユーザー」が定義されていることは、ネットワーク管理のセキュリティポリシーが適用されます。たとえば、ユーザーは、個人（例えば、「ジョー」または「ジェーン」）、または特定のロール（例えば、「オペレータ」または「管理者」）、またはそれらの組み合わせ（例えば、「ジョー・オペレーター」、「可能性がありjane-オペレータ」または 『ジョー・管理者』）。さらに、ユーザーは、個人または役割、あるいは個人の設定、またはそれらの組み合わせを含む役割のセットのために行動する、そのようなSNMPアプリケーションまたはSNMPアプリケーションのセットとして論理的なエンティティであってもよいです。
Appendix A describes an algorithm for mapping a user "password" to a 16/20 octet value for use as either a user's authentication key or privacy key (or both). Note however, that using the same password (and therefore the same key) for both authentication and privacy is very poor security practice and should be strongly discouraged. Passwords are often generated, remembered, and input by a human. Human-generated passwords may be less than the 16/20 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, SNMP implementations (and SNMP configuration applications) must ensure that passwords are at least 8 characters in length. Please note that longer passwords with repetitive strings may result in exactly the same key. For example, a password 'bertbert' will result in exactly the same key as password 'bertbertbert'.
付録Aは、ユーザの認証キーまたはプライバシーキー（あるいは両方）として使用するための16/20オクテット値にユーザー「パスワード」をマッピングするためのアルゴリズムを説明します。認証とプライバシーの両方に同じパスワード（したがって、同じキー）を使用することは非常に悪いセキュリティの実践であると強く推奨されるべきであること、しかし、注意してください。パスワードは、多くの場合、人間によって、生成思い出し、および入力されています。人間生成されたパスワードは、認証とプライバシープロトコルによって必要16/20オクテット未満であってもよいし、ブルートフォース攻撃は比較的短いASCII文字セットには非常に簡単にすることができます。したがって、アルゴリズムは、付録Aは、パスワードに変換を行います。付録Aのアルゴリズムが使用される場合、SNMPの実装（およびSNMP設定アプリケーション）は、パスワードの長さは8文字以上であることを保証しなければなりません。繰り返しの文字列を含む長いパスワードがまったく同じキーになる場合がありますのでご了承ください。たとえば、パスワード「bertbertは、」パスワード「bertbertbert」とまったく同じキーになります。
Because the Appendix A algorithm uses such passwords (nearly) directly, it is very important that they not be easily guessed. It 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.
付録Aアルゴリズムは、このようなパスワードを使用しているため（ほぼ）直接、彼らが容易に推測されないことが非常に重要です。それらが辞書に見つかる可能性がある単語やフレーズを形成しない混在ケースの英数字および句読点文字で構成されていることが示唆されました。長いパスワードは、システムのセキュリティを向上させます。ユーザーは、それが記憶に残るであることを保証しながら、長いパスワード文字列を作るために、入力マルチワードフレーズに望むことができます。
Since it is infeasible for human users to maintain different passwords for every SNMP engine, but security requirements strongly discourage having the same key for more than one SNMP engine, the User-based Security Model employs a compromise proposed in [Localized-key]. It derives the user keys for the SNMP engines from user's password in such a way that it is practically impossible to either determine the user's password, or user's key for another SNMP engine from any combination of user's keys on SNMP engines.
それは、すべてのSNMPエンジンの異なるパスワードを維持するために、人間のユーザのために実行不可能であるが、セキュリティ要件が強く、複数のSNMPエンジンのために同じキーを持つ落胆するので、ユーザベースセキュリティモデルは、[ローカライズされたキー]で提案された妥協案を採用しています。それは、ユーザーのパスワードを決定、またはSNMPエンジン上でのユーザのキーの任意の組み合わせから別のSNMPエンジンのために、ユーザのキーのいずれかに実質的に不可能であるような方法で、ユーザーのパスワードからSNMPエンジンのためのユーザーキーを導出します。
Note however, that if user's password is disclosed, then key localization will not help and network security may be compromised in this case. Therefore a user's password or non-localized key MUST NOT be stored on a managed device/node. Instead the localized key SHALL be stored (if at all) , so that, in case a device does get compromised, no other managed or managing devices get compromised.
ユーザーのパスワードが開示されている場合、キー局在は助けにはなりませんし、ネットワークのセキュリティが、この場合に損なわれる可能性があること、しかし、注意してください。したがって、ユーザーのパスワードや非局在する鍵は、管理対象デバイス/ノード上に格納されてはなりません。 （すべての場合）の場合には、デバイスが危険にさらさ取得しない、他の管理または管理するデバイスが危険にさらさないように取得する代わりにローカライズされたキーは、保管されなければなりません。
To be termed a "Secure SNMP implementation" based on the User-based Security Model, an SNMP implementation MUST:
ユーザベースセキュリティモデル、SNMPの実装に基づいて、「セキュアなSNMPの実装」をしなければならないと呼ばれることには：
- implement one or more Authentication Protocol(s). The HMAC-MD5-96 and HMAC-SHA-96 Authentication Protocols defined in this memo are examples of such protocols.
- 1つ以上の認証プロトコル（複数可）を実施します。このメモで定義されたHMAC-MD5-96およびHMAC-SHA-96認証プロトコルは、そのようなプロトコルの例です。
- to the maximum extent possible, prohibit access to the secret(s) of each user about which it maintains information in a Local Configuration Datastore (LCD) under all circumstances except as required to generate and/or validate SNMP messages with respect to that user.
- 可能な限り、それが生成及び/又はそのユーザに対してSNMPメッセージを検証するために必要とされる以外のすべての状況下でローカル設定データストア（LCD）内の情報を維持するかについて、各ユーザの秘密（S）へのアクセスを禁止。
- implement the key-localization mechanism.
- キー・ローカリゼーションメカニズムを実装します。
- implement the SNMP-USER-BASED-SM-MIB.
- SNMP-USER-BASED-SM-MIBを実装します。
In addition, an authoritative SNMP engine SHOULD provide initial configuration in accordance with Appendix A.1.
また、信頼できるSNMPエンジンは、付録A.1に従って初期構成を提供する必要があります。
Implementation of a Privacy Protocol (the DES Symmetric Encryption Protocol defined in this memo is one such protocol) is optional.
プライバシープロトコルの実装は、（このメモで定義されたDES対称暗号化プロトコルは、1つのそのようなプロトコルである）任意です。
The use of unsecure reports (i.e. sending them with a securityLevel of noAuthNoPriv) potentially exposes a non-authoritative SNMP engine to some form of attacks. Some people consider these denial of service attacks, others don't. An installation should evaluate the risk involved before deploying unsecure Report PDUs.
保護されていないレポート（すなわちnoAuthNoPrivというのたsecurityLevelでそれらを送信する）の使用は、潜在的な攻撃のいくつかのフォームに非正式のSNMPエンジンを公開します。一部の人々は他の人にはない、サービス攻撃のこれらの拒否を検討してください。インストールは安全でないレポートPDUを展開する前に、関連するリスクを評価する必要があります。
The objects in this MIB may be considered sensitive in many environments. Specifically the objects in the usmUserTable contain information about users and their authentication and privacy protocols. It is important to closely control (both read and write) access to these MIB objects by using appropriately configured Access Control models (for example the View-based Access Control Model as specified in [RFC2575]).
このMIBのオブジェクトは、多くの環境で敏感と考えることができます。具体のusmUserTable内のオブジェクトは、ユーザーとその認証とプライバシープロトコルに関する情報が含まれています。 （[RFC2575]で指定されるように、例えばビューベースアクセス制御モデル）適切に構成されたアクセス制御モデルを用いて、これらのMIBオブジェクトへのアクセス密接制御（読み取りと書き込みの両方）することが重要です。
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "メッセージダイジェストアルゴリズムMD5"、RFC 1321、1992年4月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC1905] 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.
[RFC1905]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[RFC1906] 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.
[RFC1906]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、RFC 1906 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための交通マッピング"、1996年1月。
[RFC1907] 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.
[RFC1907]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、RFC 1907 1996年1月、 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための管理情報ベース"。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for describing SNMP Management Frameworks", RFC 2571, April 1999.
[RFC2571]ハリントン、D.、PresuhnとR.とB. Wijnen、 "SNMP管理フレームワークを記述するためのアーキテクチャ"、RFC 2571、1999年4月。
[RFC2572] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[RFC2572]ケース、J.、ハリントン、D.、PresuhnとR.とB. Wijnen、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、RFC 2572、1999年4月。
[RF2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[RF2575] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（SNMP）"、RFC 2575、1999年4月。
[Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen "Key Derivation for Network Management Applications" IEEE Network Magazine, April/May issue, 1997.
[ローカライズされたキー] U.ブルーメンソール、N. C.ヒエン、B. WijnenのIEEEネットワークマガジン4月/月号、1997年の「ネットワーク管理アプリケーションのためのキー派生」。
[DES-NIST] 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).
[DES-NIST]データ暗号化規格、アメリカ国立標準技術研究所。連邦情報処理標準（FIPS）出版46-1。 FIPS出版46、（;再確認1988年1月、1月、1977年）よりも優先されます。
[DES-ANSI] Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980).
[DES-ANSI]データ暗号化アルゴリズム、米国規格協会。 ANSI X3.92-1981、（12月、1980）。
[DESO-NIST] DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980).
[DESO-NIST] DES運転モード、アメリカ国立標準技術研究所。連邦情報処理標準（FIPS）出版81、（12月、1980）。
[DESO-ANSI] Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106- 1983, (May 1983).
[DESO-ANSI]データ暗号化アルゴリズム - 動作モード、米国規格協会。 ANSI X3.106- 1983、（1983年5月）。
[DESG-NIST] 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).
[DESG-NIST]の実装とNBSデータ暗号化規格、アメリカ国立標準技術研究所の使用に関するガイドライン。連邦情報処理標準（FIPS）出版74、（4月、1981）。
[DEST-NIST] Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-20.
NBSデータ暗号化規格、アメリカ国立標準技術研究所のハードウェア実装の正しさを検証[DEST-NIST]。特別刊行物500から20。
[DESM-NIST] Maintenance Testing for the Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-61, (August, 1980).
[DESM-NIST]データ暗号化規格のためのメンテナンスのテスト、アメリカ国立標準技術研究所。特別刊行物500から61、（8月、1980）。
[SHA-NIST] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.ps (Postscript)
[SHA-NIST]はセキュアハッシュアルゴリズム。 NIST FIPS 180-1、（1995年4月）http://csrc.nist.gov/fips/fip180-1.txt（ASCII）http://csrc.nist.gov/fips/fip180-1.ps（ポストスクリプト）
Uri Blumenthal IBM T. J. Watson Research 30 Saw Mill River Pkwy, Hawthorne, NY 10532 USA
ウリブルーメンソールIBM T. J.ワトソン研究所30は、ミルリバーパークウェイ、ホーソーン、NY 10532 USAを見ました
Phone: +1-914-784-7064 EMail: uri@watson.ibm.com
電話：+ 1-914-784-7064 Eメール：uri@watson.ibm.com
Bert Wijnen IBM T. J. Watson Research Schagen 33 3461 GL Linschoten Netherlands
バート・ワインIBM T. J.ワトソン研究所ショームバーグ33 3461 GL Linschotenオランダ
Phone: +31-348-432-794 EMail: wijnen@vnet.ibm.com
電話：+ 31-348-432-794メールアドレス：wijnen@vnet.ibm.com
APPENDIX A - Installation
付録A - インストール
A.1. SNMP engine Installation Parameters
A.1。 SNMPエンジンのインストールパラメータ
During installation, an authoritative SNMP engine SHOULD (in the meaning as defined in [RFC2119]) be configured with several initial parameters. These include:
インストール時に、正式のSNMPエンジンは、（[RFC2119]で定義されるような意味で）、いくつかの初期パラメータを設定する必要があります。これらは、次のとおりです。
1) A security posture
1）セキュリティ態勢
The choice of security posture determines if initial configuration is implemented and if so how. One of three possible choices is selected:
初期設定が実装され、どのようにされている場合ならば、セキュリティの姿勢の選択が決定されます。三つの可能な選択肢の一つが選択されています。
minimum-secure,
semi-secure,
very-secure (i.e., no-initial-configuration)
In the case of a very-secure posture, there is no initial configuration, and so the following steps are irrelevant.
非常にセキュア姿勢の場合、そこには初期設定されていない、従って次の手順は無関係です。
2) one or more secrets
2）は、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:
これを実現する一つの方法は、インストーラが必要な各秘密のための「パスワード」を入力することです。パスワードは、その後、アルゴリズムによって必要とされる秘密に変換されます。
- 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 [MD5]. The resulting digest, termed "digest1", is used in the next step.
- 応じて切り捨て、およびMD5アルゴリズム[MD5]への入力として得られた文字列を使用して、必要に応じてできるだけ頻繁にパスワードの値を繰り返すことにより、長さの文字列1,048,576オクテットを形成します。 「digest1」と呼ばれる、得られた消化物を、次の工程で使用されます。
- a second string is formed by concatenating digest1, the SNMP engine's snmpEngineID value, and digest1. This string is used as input to the MD5 algorithm [MD5].
- 第二列はdigest1、SNMPエンジンののsnmpEngineID値、及びdigest1を連結することによって形成されています。この文字列は、MD5アルゴリズム[MD5]への入力として使用されます。
The resulting digest is the required secret (see Appendix A.2).
結果のダイジェストは、必要な秘密（付録A.2を参照）です。
With these configured parameters, the SNMP engine instantiates the following usmUserEntry in the usmUserTable:
これらの設定したパラメータと、SNMPエンジンはのusmUserTableに次のusmUserEntryをインスタンス化します。
no privacy support privacy support
------------------ ---------------
usmUserEngineID localEngineID localEngineID
usmUserName "initial" "initial"
usmUserSecurityName "initial" "initial"
usmUserCloneFrom ZeroDotZero ZeroDotZero
usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol
usmUserAuthKeyChange "" ""
usmUserOwnAuthKeyChange "" ""
usmUserPrivProtocol none usmDESPrivProtocol
usmUserPrivKeyChange "" ""
usmUserOwnPrivKeyChange "" ""
usmUserPublic "" ""
usmUserStorageType anyValidStorageType anyValidStorageType
usmUserStatus active active
It is recommended to also instantiate a set of template usmUserEntries which can be used as clone-from users for newly created usmUserEntries. These are the two suggested entries:
また、クローンから新しく作成されたusmUserEntriesためのユーザーとして使用することができますテンプレートusmUserEntriesのセットをインスタンス化することをお勧めします。これらは、2つの提案エントリです。
no privacy support privacy support
------------------ ---------------
usmUserEngineID localEngineID localEngineID
usmUserName "templateMD5" "templateMD5"
usmUserSecurityName "templateMD5" "templateMD5"
usmUserCloneFrom ZeroDotZero ZeroDotZero
usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol
usmUserAuthKeyChange "" ""
usmUserOwnAuthKeyChange "" ""
usmUserPrivProtocol none usmDESPrivProtocol
usmUserPrivKeyChange "" ""
usmUserOwnPrivKeyChange "" ""
usmUserPublic "" ""
usmUserStorageType permanent permanent
usmUserStatus active active
no privacy support privacy support
------------------ ---------------
usmUserEngineID localEngineID localEngineID
usmUserName "templateSHA" "templateSHA"
usmUserSecurityName "templateSHA" "templateSHA"
usmUserCloneFrom ZeroDotZero ZeroDotZero
usmUserAuthProtocol usmHMACSHAAuthProtocol usmHMACSHAAuthProtocol
usmUserAuthKeyChange "" ""
usmUserOwnAuthKeyChange "" ""
usmUserPrivProtocol none usmDESPrivProtocol
usmUserPrivKeyChange "" ""
usmUserOwnPrivKeyChange "" ""
usmUserPublic "" ""
usmUserStorageType permanent permanent
usmUserStatus active active
A.2. Password to Key Algorithm
A.2。鍵アルゴリズムへのパスワード
A sample code fragment (section A.2.1) demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key using MD5. The reference source code of MD5 is available in [RFC1321].
サンプル・コード・フラグメント（セクションA.2.1）はMD5を使用して、認証またはプライバシーキーにパスワードをマッピングする際に使用することができる鍵アルゴリズムにパスワードを示します。 MD5の参照ソースコードは[RFC1321]で入手可能です。
Another sample code fragment (section A.2.2) demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key using SHA (documented in SHA-NIST).
別のサンプル・コード・フラグメント（セクションA.2.2）は、SHA（SHA-NISTに記載）を使用して認証またはプライバシーキーにパスワードをマッピングする際に使用することができる鍵アルゴリズムにパスワードを示します。
An example of the results of a correct implementation is provided (section A.3) which an implementor can use to check if his implementation produces the same result.
正しい実装の結果の一例は、実装者は、彼の実装では、同じ結果を生成するかどうかを確認するために使用できる（セクションA.3）が設けられています。
A.2.1. Password to Key Sample Code for MD5
A.2.1。 MD5のキーサンプルコードへのパスワード
void password_to_key_md5(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *engineID, /* IN - pointer to snmpEngineID */
u_int engineLength,/* IN - length of snmpEngineID */
u_char *key) /* OUT - pointer to caller 16-octet buffer */
{
MD5_CTX MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;
MD5Init (&MD); /* initialize MD5 */
/**********************************************/
/* Use while loop until we've done 1 Megabyte */
/**********************************************/
while (count < 1048576) {
cp = password_buf;
for (i = 0; i < 64; i++) {
/*************************************************/
/* Take the next octet of the password, wrapping */
/* to the beginning of the password as necessary.*/
/*************************************************/
*cp++ = password[password_index++ % passwordlen];
}
MD5Update (&MD, password_buf, 64);
count += 64;
}
MD5Final (key, &MD); /* tell MD5 we're done */
/*****************************************************/
/* Now localize the key with the engineID and pass */
/* through MD5 to produce final key */
/* May want to ensure that engineLength <= 32, */
/* otherwise need to use a buffer larger than 64 */
/*****************************************************/
memcpy(password_buf, key, 16);
memcpy(password_buf+16, engineID, engineLength);
memcpy(password_buf+16+engineLength, key, 16);
MD5Init(&MD);
MD5Update(&MD, password_buf, 32+engineLength);
MD5Final(key, &MD);
return;
}
A.2.2. Password to Key Sample Code for SHA
A.2.2。 SHAの主なサンプルコードへのパスワード
void password_to_key_sha(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *engineID, /* IN - pointer to snmpEngineID */
u_int engineLength,/* IN - length of snmpEngineID */
u_char *key) /* OUT - pointer to caller 20-octet buffer */
{
SHA_CTX SH;
u_char *cp, password_buf[72];
u_long password_index = 0;
u_long count = 0, i;
SHAInit (&SH); /* initialize SHA */
/**********************************************/
/* Use while loop until we've done 1 Megabyte */
/**********************************************/
while (count < 1048576) {
cp = password_buf;
for (i = 0; i < 64; i++) {
/*************************************************/
/* Take the next octet of the password, wrapping */
/* to the beginning of the password as necessary.*/
/*************************************************/
*cp++ = password[password_index++ % passwordlen];
}
SHAUpdate (&SH, password_buf, 64);
count += 64;
}
SHAFinal (key, &SH); /* tell SHA we're done */
/*****************************************************/
/* Now localize the key with the engineID and pass */
/* through SHA to produce final key */
/* May want to ensure that engineLength <= 32, */
/* otherwise need to use a buffer larger than 72 */
/*****************************************************/
memcpy(password_buf, key, 20);
memcpy(password_buf+20, engineID, engineLength);
memcpy(password_buf+20+engineLength, key, 20);
SHAInit(&SH);
SHAUpdate(&SH, password_buf, 40+engineLength);
SHAFinal(key, &SH);
return;
}
A.3. Password to Key Sample Results
A.3。キーサンプル結果へのパスワード
A.3.1. Password to Key Sample Results using MD5
A.3.1。 MD5を使用してキーのサンプル結果へのパスワード
The following shows a sample output of the password to key algorithm for a 16-octet key using MD5.
以下は、MD5を使用して、16オクテットキーのキーアルゴリズムへのパスワードのサンプル出力を示しています。
With a password of "maplesyrup" the output of the password to key algorithm before the key is localized with the SNMP engine's snmpEngineID is:
「メープルシロップ」キーの前に鍵アルゴリズムへのパスワードの出力のパスワードを使用して、SNMPエンジンのsnmpEngineIDのでローカライズされています：
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
「4E 32 83 88 92 83 98 47 BC 4E D8 D9のEDの63'Hの9F
After the intermediate key (shown above) is localized with the snmpEngineID value of:
中間鍵（上記）後ののsnmpEngineID値にローカライズされています。
'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の89 64 C2 93 07 87 D8 2b'H 6F
A.3.2. Password to Key Sample Results using SHA
A.3.2。 SHAを使用したキーサンプル結果へのパスワード
The following shows a sample output of the password to key
algorithm for a 20-octet key using SHA.
With a password of "maplesyrup" the output of the password to key algorithm before the key is localized with the SNMP engine's snmpEngineID is:
「メープルシロップ」キーの前に鍵アルゴリズムへのパスワードの出力のパスワードを使用して、SNMPエンジンのsnmpEngineIDのでローカライズされています：
'9f b5 cc 03 81 49 7b 37 93 52 89 39 ff 78 8d 5d 79 14 52 11'H
「CCのB5 9F 03 81 49 7B 37 93 52 89 39 FF 78 8D 5D 79 14 52 11'H
After the intermediate key (shown above) is localized with the snmpEngineID value of:
中間鍵（上記）後ののsnmpEngineID値にローカライズされています。
'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:
鍵アルゴリズムへのパスワードの最終的な出力は次のようになります。
'66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f'H
3f'H 8F '66 95 FE C7 62 82 23 5F E3 88 92 BC 15 1F 12 84 97 B3
A.4. Sample encoding of msgSecurityParameters
A.4。 msgSecurityParametersのサンプル・エンコーディング
The msgSecurityParameters in an SNMP message are represented as an OCTET STRING. This OCTET STRING should be considered opaque outside a specific Security Model.
SNMPメッセージにmsgSecurityParametersはOCTET STRINGとして表されています。このオクテット文字列は、特定のセキュリティモデルの外に不透明考慮されるべきです。
The User-based Security Model defines the contents of the OCTET STRING as a SEQUENCE (see section 2.4).
ユーザベースセキュリティモデルは、シーケンスとしてオクテット文字列の内容を定義します（セクション2.4を参照してください）。
Given these two properties, the following is an example of the msgSecurityParameters for the User-based Security Model, encoded as an OCTET STRING:
これら二つの特性を考えると、次はOCTET STRINGとしてエンコードされたユーザベースセキュリティモデル、のためmsgSecurityParametersの例です。
04 <length> 30 <length> 04 <length> <msgAuthoritativeEngineID> 02 <length> <msgAuthoritativeEngineBoots> 02 <length> <msgAuthoritativeEngineTime> 04 <length> <msgUserName> 04 0c <HMAC-MD5-96-digest> 04 08 <salt>
04 <長さ> 30 <長さ> 04 <長さ> <msgAuthoritativeEngineID> 02 <長さ> <msgAuthoritativeEngineBoots> 02 <長さ> <msgAuthoritativeEngineTime> 04 <長さ> <msgUserName> 04 0C <HMAC-MD5-96ダイジェスト> 04 08 <塩>
Here is the example once more, but now with real values (except for the digest in msgAuthenticationParameters and the salt in msgPrivacyParameters, which depend on variable data that we have not defined here):
ここでは例がもう一度あるが、今（私たちがここで定義されていない変数のデータに依存msgAuthenticationParametersとmsgPrivacyParameters中の塩でダイジェストを除いて、）実際の値を持ちます：
Hex Data Description
-------------- -----------------------------------------------
04 39 OCTET STRING, length 57
30 37 SEQUENCE, length 55
04 0c 80000002 msgAuthoritativeEngineID: IBM
01 IPv4 address
09840301 9.132.3.1
02 01 01 msgAuthoritativeEngineBoots: 1
02 02 0101 msgAuthoritativeEngineTime: 257
04 04 62657274 msgUserName: bert
04 0c 01234567 msgAuthenticationParameters: sample value
89abcdef
fedcba98
04 08 01234567 msgPrivacyParameters: sample value
89abcdef
A.5. Sample keyChange Results
A.5。サンプルてkeyChange結果
A.5.1. Sample keyChange Results using MD5
A.5.1。 MD5を使用したサンプルてkeyChange結果
Let us assume that a user has a current password of "maplesyrup" as in section A.3.1. and let us also assume the snmpEngineID of 12 octets:
私たちは、ユーザがセクションA.3.1のように「メープルシロップ」の現在のパスワードを持っていると仮定しましょう。私たちはまた、12オクテットのでsnmpEngineIDを想定してみましょう：
'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
If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows:
私たちは今、「newsyrup」にパスワードを変更したい場合は、我々は最初に新しいパスワードのキーを計算します。以下のようになります：
'01 ad d2 73 10 7c 4e 59 6b 4b 00 f8 2b 1d 42 a7'H
01 AD e2は10 shtts ashtah 2B 1E 42 59 IIIb族BW 00 P8ことをshtz
If we localize it for the above snmpEngineID, then the localized new key becomes:
我々は上記のsnmpEngineIDのためにそれをローカライズする場合は、ローカライズされた新しいキーは次のようになります。
'87 02 1d 7b d9 d1 01 ba 05 ea 6e 3b f9 d9 bd 4a'H
'87 02 1D 7BのD9 D1を01 BA 05 EA 6E 3B F9 D9 BD 4a'H
If we then use a (not so good, but easy to test) random value of:
我々は、その後の（あまりよくありませんが、テストしやすい）、ランダムな値を使用している場合：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
Then the value we must send for keyChange is:
その後、我々は、てkeyChangeのために送付しなければならない値は、次のとおりです。
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 05 61 51 41 67 6c c9 19 61 74 e7 42 a3 25 51'H
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 05 61 51 41 67 6C C9 19 61 74 E7 42 A3 25 51'H
If this were for the privacy key, then it would be exactly the same.
これはプライバシーのキーのためだったら、それはまったく同じになります。
A.5.2. Sample keyChange Results using SHA
A.5.2。 SHAを使用したサンプルてkeyChange結果
Let us assume that a user has a current password of "maplesyrup" as in section A.3.2. and let us also assume the snmpEngineID of 12 octets:
私たちは、ユーザがセクションA.3.2のように「メープルシロップ」の現在のパスワードを持っていると仮定しましょう。私たちはまた、12オクテットのでsnmpEngineIDを想定してみましょう：
'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
If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows:
私たちは今、「newsyrup」にパスワードを変更したい場合は、我々は最初に新しいパスワードのキーを計算します。以下のようになります：
'3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H
「3A 51 A6 D7 36 AA 34 7B 83直流4A 87 E3、E5 5E E4 D6 98交流71'H
If we localize it for the above snmpEngineID, then the localized new key becomes:
我々は上記のsnmpEngineIDのためにそれをローカライズする場合は、ローカライズされた新しいキーは次のようになります。
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 91 f1 cd 25'H
'78 e2の直流CE 79 D5 94 03 B5 8C 1B BA A5 BF F4 63 91 F1のCD 25'H
If we then use a (not so good, but easy to test) random value of:
我々は、その後の（あまりよくありませんが、テストしやすい）、ランダムな値を使用している場合：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
Then the value we must send for keyChange is:
その後、我々は、てkeyChangeのために送付しなければならない値は、次のとおりです。
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c 10 17 f4 fd 48 3d 2d e8 d5 fa db f8 43 92 cb 06 45 70 51'
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9C 10 17 F4 48 3D 2D E8 D5 FA DB F8 43 92、CB 06 45 70 51' をfdが
For the key used for privacy, the new nonlocalized key would be:
プライバシーのために使用されるキーの場合は、新しいローカライズされていないキーは次のようになります。
'3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H
「3A 51 A6 D7 36 AA 34 7B 83直流4A 87 E3、E5 5E E4 D6 98交流71'H
For the key used for privacy, the new localized key would be (note that they localized key gets truncated to 16 octets for DES):
プライバシーのために使用されるキーの場合は、新しいローカライズされたキーは、（彼らは鍵がDESのための16個のオクテットに切り詰められます局在していることに注意してください）のようになります。
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63'H
'78 e2の直流CE 79 D5 94 03 B5 8C 1B BA A5のBFのF4の63'H
If we then use a (not so good, but easy to test) random value of:
我々は、その後の（あまりよくありませんが、テストしやすい）、ランダムな値を使用している場合：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
Then the value we must send for keyChange for the privacy key is:
その後、我々はプライバシーのキーのためてkeyChangeのために送付しなければならない値は、次のとおりです。
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '7e f8 d8 a4 c9 cd b2 6b 47 59 1c d8 52 ff 88 b5'H
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00「7E F8 D8のA4サイズのC9 CD B2 6B 47 59 1C D8 52 FF 88 b5'H
B. Change Log
B.変更ログ
Changes made since RFC2274: - Fixed msgUserName to allow size of zero and explain that this can be used for snmpEngineID discovery. - Clarified section 3.1 steps 4.b, 5, 6 and 8.b. - Clarified section 3.2 paragraph 2. - Clarified section 3.2 step 7.a last paragraph, step 7.b.1 second bullet and step 7.b.2 third bullet. - Clarified section 4 to indicate that discovery can use a userName of zero length in unAuthenticated messages, whereas a valid userName must be used in authenticated messages. - Added REVISION clauses to MODULE-IDENTITY - Clarified KeyChange TC by adding a note that localized keys must be used when calculating a KeyChange value. - Added clarifying text to the DESCRIPTION clause of usmUserTable. Added text describes a recommended procedure for adding a new user. - Clarified the use of usmUserCloneFrom object. - Clarified how and under which conditions the usmUserAuthProtocol and usmUserPrivProtocol can be initialized and/or changed. - Added comment on typical sizes for usmUserAuthKeyChange and usmUserPrivKeyChange. Also for usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange. - Added clarifications to the DESCRIPTION clauses of usmUserAuthKeyChange, usmUserOwnAuthKeychange, usmUserPrivKeyChange and usmUserOwnPrivKeychange. - Added clarification to DESCRIPTION clause of usmUserStorageType. - Added clarification to DESCRIPTION clause of usmUserStatus. - Clarified IV generation procedure in section 8.1.1.1 and in addition clarified section 8.3.1 step 1 and section 8.3.2. step 3. - Clarified section 11.2 and added a warning that different size passwords with repetitive strings may result in same key. - Added template users to appendix A for cloning process. - Fixed C-code examples in Appendix A. - Fixed examples of generated keys in Appendix A. - Added examples of KeyChange values to Appendix A. - Used PDU Classes instead of RFC1905 PDU types. - Added text in the security section about Reports and Access Control to the MIB - Removed a incorrect note at the end of section 3.2 step 7. - Added a note in section 3.2 step 3. - Corrected various spelling errors and typos. - Corrected procedure for 3.2 step 2.a) - various clarifications. - Fixed references to new/revised documents - Change to no longer cache data that is not used
RFC2274以降に行われた変更点： - 固定msgUserNameゼロのサイズを許可し、これはのsnmpEngineID発見のために使用することができることを説明します。 - 明確化セクション3.1ステップ4.B、5、6及び8.b. - 最後の段落、ステップ7.b.1第二弾ステップ7.b.2第三弾7.A清澄セクション3.2ステップ - 3.2段落2を明らかにしました。 - 有効なユーザ名が認証されたメッセージに使用されなければならないのに対し、認証されていないメッセージに長さゼロのユーザ名を使用することができるという発見を示すために、セクション4を明らかにしました。 - てkeyChange値を計算するときにローカライズされたキーを使用しなければならない注意事項を追加することによっててkeyChange TC明確化 - モジュールIDENTITY改正条項を追加しました。 - のusmUserTableの説明句にテキストを明確に追加しました。追加されたテキストは、新しいユーザーを追加するための推奨手順を説明します。 - usmUserCloneFromオブジェクトを使用することを明らかにしました。 - どのようにしてusmUserAuthProtocolとusmUserPrivProtocolが初期化および/または変更することができますどのような条件の下で明らかにしました。 - usmUserAuthKeyChangeとusmUserPrivKeyChangeの典型的な大きさにコメントを追加しました。またusmUserOwnAuthKeyChangeとusmUserOwnPrivKeyChangeため。 - usmUserAuthKeyChange、usmUserOwnAuthKeychange、usmUserPrivKeyChangeとusmUserOwnPrivKeychangeの記述節への明確化を追加しました。 - usmUserStorageTypeの説明節に説明を追加しました。 - usmUserStatusの説明節に説明を追加しました。 - セクション8.3.1ステップ1およびセクション8.3.2を明らかセクション8.1.1.1でしかもIV生成手順を明らかにしました。ステップ3 - セクション11.2を明らかにし、繰り返し文字列と異なるサイズのパスワードが同一の鍵をもたらすことができるという警告を追加しました。 - クローニングプロセスについては、付録するテンプレートユーザーを追加しました。代わりに、RFC1905 PDUタイプの使用済みPDUクラス - 付録AへてkeyChange値の追加された例 - 付録Aで生成されたキーの修正例 - - 付録Aの修正Cコード例。 - MIBへの報告に関するセキュリティセクションおよびアクセスコントロールで追加されたテキスト - セクション3.2ステップ3で注意を追加 - - セクション3.2ステップ7の終了時に間違ったノートを削除しましたが、様々なスペルミスやタイプミスを修正しました。 - 種々の明確化 - 3.2ステップ2.A）の手順を修正しました。 - 使用されていない、もはやキャッシュデータへの変更 - 新/改訂版のドキュメントへの固定の参照
C. Full Copyright Statement
C.完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。