RFC3414 日本語訳
3414 User-based Security Model (USM) for version 3 of the SimpleNetwork Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. December 2002. (Format: TXT=193558 bytes) (Obsoletes RFC2574) (Also STD0062) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group U. Blumenthal Request for Comments: 3414 B. Wijnen STD: 62 Lucent Technologies Obsoletes: 2574 December 2002 Category: Standards Track
コメントを求めるワーキンググループU.ブルーメンソル要求をネットワークでつないでください: 3414B.Wijnen STD: 62 ルーセントテクノロジーズは以下を時代遅れにします。 2574 2002年12月のカテゴリ: 標準化過程
User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3)
Simple Network Managementプロトコルのバージョン3のためのユーザベースのSecurity Model(USM)(SNMPv3)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574.
このドキュメントはSNMPアーキテクチャにおける使用のためのSimple Network Managementプロトコル(SNMP)バージョン3のために、UserベースのSecurity Model(USM)について説明します。 それは、メッセージレベルセキュリティをSNMPに供給するためにProcedureのElementsを定義します。 また、このドキュメントはこのSecurity Modelのための設定パラメータを離れてモニターするか、または管理するためのManagement Information基地(MIB)を含んでいます。 このドキュメントはRFC2574を時代遅れにします。
Table of Contents
目次
1. Introduction.......................................... 4
1.1. Threats............................................... 4
1.2. Goals and Constraints................................. 6
1.3. Security Services..................................... 6
1.4. Module Organization................................... 7
1.4.1. Timeliness Module..................................... 8
1.4.2. Authentication Protocol............................... 8
1.4.3. Privacy Protocol...................................... 8
1.5. Protection against Message Replay, Delay
and Redirection....................................... 9
1.5.1. Authoritative SNMP engine............................. 9
1.5.2. Mechanisms............................................ 9
1.6. Abstract Service Interfaces........................... 11
1. 序論… 4 1.1. 脅威… 4 1.2. 目標と規制… 6 1.3. セキュリティサービス… 6 1.4. モジュール組織… 7 1.4.1. タイムリーモジュール… 8 1.4.2. 認証プロトコル… 8 1.4.3. プライバシープロトコル… 8 1.5. メッセージ再生、遅れ、およびリダイレクションに対する保護… 9 1.5.1. 正式のSNMPエンジン… 9 1.5.2. メカニズム… 9 1.6. 抽象的なサービスは連結します… 11
Blumenthal & Wijnen Standards Track [Page 1] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[1ページ]RFC3414USM
1.6.1. User-based Security Model Primitives
for Authentication.................................... 11
1.6.2. User-based Security Model Primitives
for Privacy........................................... 12
2. Elements of the Model................................. 12
2.1. User-based Security Model Users....................... 12
2.2. Replay Protection..................................... 13
2.2.1. msgAuthoritativeEngineID.............................. 14
2.2.2. msgAuthoritativeEngineBoots and
msgAuthoritativeEngineTime............................ 14
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...... 20
2.6. Key Localization Algorithm............................ 22
3. Elements of Procedure................................. 22
3.1. Generating an Outgoing SNMP Message................... 22
3.2. Processing an Incoming SNMP Message................... 26
4. Discovery............................................. 31
5. Definitions........................................... 32
6. HMAC-MD5-96 Authentication Protocol................... 51
6.1. Mechanisms............................................ 51
6.1.1. Digest Authentication Mechanism....................... 51
6.2. Elements of the Digest Authentication Protocol........ 52
6.2.1. Users................................................. 52
6.2.2. msgAuthoritativeEngineID.............................. 53
6.2.3. SNMP Messages Using this Authentication Protocol...... 53
6.2.4. Services provided by the HMAC-MD5-96
Authentication Module................................. 53
6.2.4.1. Services for Generating an Outgoing SNMP Message...... 53
6.2.4.2. Services for Processing an Incoming SNMP Message...... 54
6.3. Elements of Procedure................................. 55
6.3.1. Processing an Outgoing Message........................ 55
6.3.2. Processing an Incoming Message........................ 56
7. HMAC-SHA-96 Authentication Protocol................... 57
7.1. Mechanisms............................................ 57
7.1.1. Digest Authentication Mechanism....................... 57
7.2. Elements of the HMAC-SHA-96 Authentication Protocol... 58
7.2.1. Users................................................. 58
7.2.2. msgAuthoritativeEngineID.............................. 58
7.2.3. SNMP Messages Using this Authentication Protocol...... 59
7.2.4. Services provided by the HMAC-SHA-96
Authentication Module................................. 59
7.2.4.1. Services for Generating an Outgoing SNMP Message...... 59
7.2.4.2. Services for Processing an Incoming SNMP Message...... 60
7.3. Elements of Procedure................................. 61
1.6.1. ユーザベースのセキュリティは認証のための基関数をモデル化します… 11 1.6.2. ユーザベースのセキュリティはプライバシーのための基関数をモデル化します… 12 2. モデルのElements… 12 2.1. ユーザベースのセキュリティはユーザをモデル化します… 12 2.2. 保護を再演してください… 13 2.2.1msgAuthoritativeEngineID… 14 2.2 .2msgAuthoritativeEngineBootsとmsgAuthoritativeEngineTime… 14 2.2.3. 時間ウィンドウ… 15 2.3. 時間同期化… 15 2.4. SNMP Messages Using、このSecurity Model… 16 2.5. ユーザベースのセキュリティによって提供されたサービスはモデル化されます… 17 2.5.1. 送信するSNMPメッセージを生成するためのサービス… 17 2.5.2. 入って来るSNMPメッセージを処理するためのサービス… 20 2.6. 主要なローカライズアルゴリズム… 22 3. 手順のElements… 22 3.1. 送信するSNMPメッセージを生成します… 22 3.2. 入って来るSNMPメッセージを処理します… 26 4. 発見… 31 5. 定義… 32 6. HMAC-MD5-96認証プロトコル… 51 6.1. メカニズム… 51 6.1.1. 認証機構を読みこなしてください… 51 6.2. ダイジェスト認証の要素は議定書を作ります… 52 6.2.1. ユーザ… 52 6.2.2msgAuthoritativeEngineID… 53 6.2.3. SNMP Messages Using、このAuthenticationプロトコル… 53 6.2.4. HMAC-MD5-96認証モジュールで提供されたサービス… 53 6.2.4.1. 送信するSNMPメッセージを生成するためのサービス… 53 6.2.4.2. 入って来るSNMPメッセージを処理するためのサービス… 54 6.3. 手順のElements… 55 6.3.1. 送信されるメッセージを処理します… 55 6.3.2. 入力メッセージを処理します… 56 7. HMAC-SHA-96認証プロトコル… 57 7.1. メカニズム… 57 7.1.1. 認証機構を読みこなしてください… 57 7.2. HMAC-SHA-96認証の要素は議定書を作ります… 58 7.2.1. ユーザ… 58 7.2.2msgAuthoritativeEngineID… 58 7.2.3. SNMP Messages Using、このAuthenticationプロトコル… 59 7.2.4. HMAC-SHA-96認証モジュールで提供されたサービス… 59 7.2.4.1. 送信するSNMPメッセージを生成するためのサービス… 59 7.2.4.2. 入って来るSNMPメッセージを処理するためのサービス… 60 7.3. 手順のElements… 61
Blumenthal & Wijnen Standards Track [Page 2] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[2ページ]RFC3414USM
7.3.1. Processing an Outgoing Message........................ 61
7.3.2. Processing an Incoming Message........................ 61
8. CBC-DES Symmetric Encryption Protocol................. 63
8.1. Mechanisms............................................ 63
8.1.1. Symmetric Encryption Protocol......................... 63
8.1.1.1. DES key and Initialization Vector..................... 64
8.1.1.2. Data Encryption....................................... 65
8.1.1.3. Data Decryption....................................... 65
8.2. Elements of the DES Privacy Protocol.................. 65
8.2.1. Users................................................. 65
8.2.2. msgAuthoritativeEngineID.............................. 66
8.2.3. SNMP Messages Using this Privacy Protocol............. 66
8.2.4. Services provided by the DES Privacy Module........... 66
8.2.4.1. Services for Encrypting Outgoing Data................. 66
8.2.4.2. Services for Decrypting Incoming Data................. 67
8.3. Elements of Procedure................................. 68
8.3.1. Processing an Outgoing Message........................ 68
8.3.2. Processing an Incoming Message........................ 69
9. Intellectual Property................................. 69
10. Acknowledgements...................................... 70
11. Security Considerations............................... 71
11.1. Recommended Practices................................. 71
11.2. Defining Users........................................ 73
11.3. Conformance........................................... 74
11.4. Use of Reports........................................ 75
11.5. Access to the SNMP-USER-BASED-SM-MIB.................. 75
12. References............................................ 75
A.1. SNMP engine Installation Parameters................... 78
A.2. Password to Key Algorithm............................. 80
A.2.1. Password to Key Sample Code for MD5................... 81
A.2.2. Password to Key Sample Code for SHA................... 82
A.3. Password to Key Sample Results........................ 83
A.3.1. Password to Key Sample Results using MD5.............. 83
A.3.2. Password to Key Sample Results using SHA.............. 83
A.4. Sample encoding of msgSecurityParameters.............. 83
A.5. Sample keyChange Results.............................. 84
A.5.1. Sample keyChange Results using MD5.................... 84
A.5.2. Sample keyChange Results using SHA.................... 85
B. Change Log............................................ 86
Editors' Addresses.................................... 87
Full Copyright Statement.............................. 88
7.3.1. 送信されるメッセージを処理します… 61 7.3.2. 入力メッセージを処理します… 61 8. CBC-DESの左右対称の暗号化プロトコル… 63 8.1. メカニズム… 63 8.1.1. 左右対称の暗号化プロトコル… 63 8.1.1.1. DESキーと初期設定Vector… 64 8.1.1.2. データ暗号化… 65 8.1.1.3. データ復号化… 65 8.2. DESプライバシーの要素は議定書を作ります… 65 8.2.1. ユーザ… 65 8.2.2msgAuthoritativeEngineID… 66 8.2.3. SNMP Messages Using、このPrivacyプロトコル… 66 8.2.4. DESプライバシーモジュールで提供されたサービス… 66 8.2.4.1. 発信データを暗号化するためのサービス… 66 8.2.4.2. 受信データを解読するためのサービス… 67 8.3. 手順のElements… 68 8.3.1. 送信されるメッセージを処理します… 68 8.3.2. 入力メッセージを処理します… 69 9. 知的所有権… 69 10. 承認… 70 11. セキュリティ問題… 71 11.1. お勧めの習慣… 71 11.2. ユーザを定義します… 73 11.3. 順応… 74 11.4. レポートの使用… 75 11.5. SNMPのユーザベースのSm MIBへのアクセス… 75 12. 参照… 75 A.1。 SNMPエンジンInstallation Parameters… 78 A.2。 主要なアルゴリズムへのパスワード… 80 A.2.1。 MD5に、主要なサンプルコードへのパスワード… 81 A.2.2。 SHAに、主要なサンプルコードへのパスワード… 82 A.3。 主要なサンプルへのパスワードは結果として生じます… 83 A.3.1。 主要なサンプルへのパスワードはMD5を使用することで結果として生じます… 83 A.3.2。 主要なサンプルへのパスワードはSHAを使用することで結果として生じます… 83 A.4。 msgSecurityParametersのコード化を抽出してください… 83 A.5。 サンプルkeyChangeは結果になります… 84 A.5.1。 サンプルkeyChangeはMD5を使用することで結果になります… 84 A.5.2。 サンプルkeyChangeはSHAを使用することで結果になります… 85 B. ログを変えてください… 86人のエディタのアドレス… 87 完全な著作権宣言文… 88
Blumenthal & Wijnen Standards Track [Page 3] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[3ページ]RFC3414USM
1. Introduction
1. 序論
The Architecture for describing Internet Management Frameworks [RFC3411] describes that an SNMP engine is composed of:
インターネットManagement Frameworks[RFC3411]について説明するためのArchitectureは、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 [RFC3411].
SNMPアーキテクチャとアーキテクチャの用語が、本書では説明されたSecurity Modelがどこでアーキテクチャに収まって、アーキテクチャの中で他のサブシステムと対話するかを理解しているのを理解しているのは重要です。 読者は、[RFC3411]で定義されるようにSNMPアーキテクチャの記述を読んで、理解していたと予想されます。
This memo 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 Architectureの中で使用されるとき、このメモはUserベースのSecurity Modelについて説明します。 本旨は私たちがセキュリティ情報を関連づけるユーザ(userNameによって特定される)の伝統的な考え方を使用するということです。
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.
このメモはプライバシープロトコルとして認証プロトコルとCBC-DESの使用としてHMAC-MD5-96とHMAC-SHA-96の使用を記述します。 しかしながら、UserベースのSecurity Modelは、他のそのようなプロトコルがこれらのプロトコルで中古であるか、または同時発生であることを許容します。 したがって、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.1. Threats
1.1. 脅威
Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any 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 Security Modelにも適切でしょう。 他の脅威はネットワーク管理問題に適切ではありません。 このセクションは、より少なく重要な主要な脅威、セカンダリ脅威、および脅威について論じます。
The principal threats against which this SNMP Security Model should provide protection are:
このSNMP Security Modelが保護を提供するはずである主要な脅威は以下の通りです。
Blumenthal & Wijnen Standards Track [Page 4] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[4ページ]RFC3414USM
- 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:
また、2つのセカンダリ脅威が特定されます。 このメモで定義されたSecurity Modelは以下に対して限定保護を提供します。
- 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が議定書の中で述べるメッセージStream Modificationはどんなサブネットワークサービスの上でも作動するかもしれないコネクションレスな輸送サービスに通常基づいています。 メッセージの再注文、遅れまたは再生が、起こって、そのような多くのサブネットワーク・サービスの自然な操作で起こることができます。 メッセージストリーム変更の脅威はメッセージが自然なサブネットワークサービスの操作で起こることができるより大きい程度まで陰湿に再命令されるか、遅らせられるか、または再演されるかもしれないという危険です、権限のない管理操作に作用するように。
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 Security Modelが守る必要はない少なくとも2つの脅威があります。 このメモで定義されたセキュリティプロトコルは以下に対して保護を提供しません。
- 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.
- サービス妨害This SNMP Security Modelは、認定ユーザを代表したサービスが否定される攻撃の広い声域を扱うのを試みません。 本当に、どんな実行可能なネットワーク管理プロトコルも当然のこととして対処されなければならないネットワーク失敗のタイプから区別できない多くの場合にはそのようなサービス不能攻撃があります。
- 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.
- トラフィックAnalysis This SNMP Security Modelは、トラヒック分析が攻撃であると扱うのを試みません。 本当に、多くのトラフィック・パターンが予測できます、そして、(デバイスは比較的少ない数の管理アプリケーションで定期的に管理されるかもしれません)したがって、トラヒック分析から守ることによって提供されたどんな重要な利点もありません。
Blumenthal & Wijnen Standards Track [Page 5] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[5ページ]RFC3414USM
1.2. Goals and Constraints
1.2. 目標と規制
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 Security Modelの目標は以下の通りです。
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.
4) 必要であるときには、それぞれの受信されたSNMPメッセージの内容が公開から保護されるのを前提としてください。
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 Security Modelのデザインは影響を及ぼされます:
1) When the requirements of effective management in times of network
stress are inconsistent with those of security, the design of USM
has given preference to the former.
1) ネットワーク圧力の時代による効果的な管理の要件がセキュリティのものに矛盾しているとき、USMのデザインは優先を前者に与えました。
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) セキュリティプロトコルもその基本的なセキュリティー対策も他のネットワーク・サービス(例えば、Network Timeプロトコル(NTP)かかぎ管理プロトコル)の持ち合わせの有用性に依存するはずがありません。
3) A security mechanism should entail no changes to the basic SNMP
network management philosophy.
3) セキュリティー対策は基本的なSNMPネットワークマネージメント哲学への変化を全く伴うはずがありません。
1.3. Security Services
1.3. セキュリティー・サービス
The security services necessary to support the goals of this SNMP Security Model are as follows:
このSNMP Security Modelの目標をサポートするのに必要なセキュリティー・サービスは以下の通りです:
- Data Integrity is the provision of the property that data has not
been altered or destroyed in an unauthorized manner, nor have data
sequences been altered to an extent greater than can occur non-
maliciously.
- データの保全はデータが権限のない方法で変更もされませんし、破壊もされないで、程度まで変更されたデータ系列を非陰湿に起こることができるよりすばらしくするのをさせる特性の設備です。
- Data Origin Authentication is the provision of the property that
the claimed identity of the user on whose behalf received data was
originated is corroborated.
- データOrigin Authenticationは特性の設備です。だれの利益受信データが溯源されたかのユーザの要求されたアイデンティティは確証されます。
Blumenthal & Wijnen Standards Track [Page 6] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[6ページ]RFC3414USM
- Data Confidentiality is the provision of the property that
information is not made available or disclosed to unauthorized
individuals, entities, or processes.
- 権限のない個人、実体、またはプロセスに利用可能に作られているか、または明らかにされて、データConfidentialityは情報がない特性の設備です。
- 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.
このメモで使用されるセキュリティプロトコルは書くこと時点で、許容できて安全であると考えられます。 しかしながら、必要性が起こるなら、手順は新しい認証と将来の時間に指定されるべきプライバシーメソッドを考慮します。
1.4. Module Organization
1.4. モジュール組織
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.
- メッセージペイロードの公開に対する保護。
Blumenthal & Wijnen Standards Track [Page 7] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[7ページ]RFC3414USM
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.
支給が複数の認証、そして/または、プライバシーモジュール(それのそれぞれがそれぞれ特定の認証かプライバシープロトコルを実装する)のためにある間、タイムリーモジュールはUserベースのSecurity Modelのために修理されています。
1.4.1. Timeliness Module
1.4.1. タイムリーモジュール
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(ProcedureのElements)はタイムリー照合をするSNMPメッセージでタイムリー値を使用します。 認証がメッセージに適用される場合にだけ、タイムリーチェックは実行されます。 完全なメッセージが保全がないかどうかチェックされるので、私たちは、認証モジュールを通過するメッセージのタイムリー値が信頼できると思うことができます。
1.4.2. Authentication Protocol
1.4.2. 認証プロトコル
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はUserベースのSecurity Modelと共にサポートしなければならない最初の認証プロトコルであるHMAC-MD5-96認証プロトコルについて説明します。 セクション7はUserベースのSecurity Modelと共にサポートされた状態でSHOULDがある別の認証プロトコルである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.
認証が使用されているなら、UserベースのSecurity Modelはそれを処方して、次に、完全なメッセージは認証モジュールによる保全がないかどうかチェックされます。
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.
認証されるべきメッセージのために、それは、認証モジュールとこのUserベースのSecurityモデルの固定部分であるタイムリーチェックで認証チェックを通過する必要があります。
1.4.3. Privacy Protocol
1.4.3. プライバシープロトコル
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はUserベースのSecurity Modelと共に使用されるべき最初のプライバシープロトコルであるCBC-DES Symmetric Encryptionプロトコルについて説明します。 プロトコルが定義されるかもしれない追加するか交換の将来のプライバシーでは、新たな必要性は起こります。
The User-based Security Model prescribes that the scopedPDU is protected from disclosure when a message is sent with privacy.
メッセージであるときに、プライバシーと共にSecurity Modelが処方するscopedPDUが保護されるUserベース公開を送ります。
The User-based Security Model also prescribes that a message needs to be authenticated if privacy is in use.
またSecurity Modelが処方するメッセージがプライバシーであるなら認証される必要があるUserベースは使用中です。
Blumenthal & Wijnen Standards Track [Page 8] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[8ページ]RFC3414USM
1.5. Protection against Message Replay, Delay and Redirection
1.5. メッセージ再生、遅れ、およびリダイレクションに対する保護
1.5.1. Authoritative SNMP Engine
1.5.1. 正式のSNMPエンジン
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 [RFC3411]), 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 [RFC3411]), then the sender of such a message is authoritative.
メッセージ再生、遅れ、およびリダイレクションから守って、各コミュニケーションにかかわるSNMPエンジンの1つは、正式のSNMPエンジンになるように指定されます。 SNMPメッセージが応答(Confirmed Class PDU[RFC3411]を含むそれらのメッセージ)を予想するペイロードを含んでいると、そのようなメッセージの受信機は正式です。 SNMPメッセージが応答(Unconfirmed Class PDU[RFC3411]を含むそれらのメッセージ)を予想しないペイロードを含んでいると、そのようなメッセージの送付者は正式です。
1.5.2. Mechanisms
1.5.2. メカニズム
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) メッセージ遅延の脅威から守るか、または再演する(通常の操作で起こることができるより大きい程度まで)ために、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エンジンは入って来るResponsesを傑出しているRequestsに合わせるのにメカニズムを使用しなければなりません、そして、それは傑出している要求に合っていないどんなResponsesも下げなければなりません。 例えば、この機能性を満たすあらゆるメッセージに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
[RFC3418]).
メッセージ遅延か再生の脅威に対するこの保護は、メッセージの権限のない削除か秘匿に対する少しの保護も含意して、提供しません。 また、SNMPエンジンは、タイム・ウィンドウ間隔中にメッセージがかかわったすべてを送るならメッセージが再命令されるのを検出できないかもしれません。 また、Set操作(例えば、MIBの可変snmpSetSerialNo[RFC3418])を含むメッセージの再注文再生、削除、または秘匿を検出するのにセキュリティプロトコルの如何にかかわらず定義された他のメカニズムは使用できます。
Blumenthal & Wijnen Standards Track [Page 9] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[9ページ]RFC3414USM
2) Verification that a message sent to/from one authoritative SNMP
engine cannot be replayed to/as-if-from another authoritative SNMP
engine.
2) ある正式のSNMPエンジンから/にメッセージが/に送った検証を再演できない、別の正式の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エンジンによって1台の非正式のSNMPエンジンに送られたUnconfirmed Class PDUを含むメッセージは別の非正式のSNMPエンジンに再演できます。 後者の非正式のSNMPエンジンはその結果正式のSNMPエンジンのタイムリーインディケータの概念をアップデートするかもしれませんが(同じ秘密が正式のSNMPエンジンにある状態でほぼ同じくらいのuserNameを知っているなら)、それは脅威であると考えられません。 この場合、A ReportかResponseメッセージがMessage Processing Modelによって捨てられるでしょう、傑出しているRequestメッセージがあるべきでないので。 ことによるとTrapを受け入れるでしょう。 一方、コミュニケーションが認証されていてタイムリーであったので、それは脅威であると考えられません。 まるで正式のSNMPエンジンが2番目のSNMPエンジンに関する知識なしで理論的にとにかく起こることができる2番目のSNMPエンジンにTrapsを送り始めるために構成されるようでした。 とにかく、2番目のSNMPエンジンは、このTrapを受け取ると予想しないかもしれませんが、経営情報がそれに含まれているのを見ることができます。
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.
世代の時間を示して、1セットの期間表示はメッセージに含まれています。 最近の期間表示のないメッセージは正統であると考えられません。 さらに、SNMPエンジンは傑出している要求に合っていないどんなResponsesも下げなければなりません。 しかしながら、これはMessage Processing Modelの責任です。
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
それぞれのSNMPエンジンは2つの値、snmpEngineBoots、およびsnmpEngineTimeを維持します。(一緒に取って、snmpEngineTimeはそのSNMPエンジンで時間のしるしを供給します)。 そのSNMPエンジンからこれらの値の両方を発信する認証されたメッセージに含んでいるか、または受け取ります。 領収書の上では、値がそれを確実にするためにチェックされる、表示
Blumenthal & Wijnen Standards Track [Page 10] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[10ページ]RFC3414USM
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.
現在の時間のタイム・ウィンドウの中にタイムリー値があります。 タイム・ウィンドウはプロトコルメッセージのために許容できる配送遅れに管理上限を表します。
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を見てください。
1.6. Abstract Service Interfaces
1.6. 抽象的なサービスインタフェース
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実体の中で様々なサブシステムの間の概念的なインタフェースについて説明するために定義されました。 同様に、1セットの抽象的なサービスインタフェースは、ジェネリックUSMサービスと、自己充足的な認証とプライバシーサービスとの概念的なインタフェースについて説明するためにUserベースのSecurity Model(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.
これらの抽象的なサービスインタフェースは提供されたサービスを定義する1セットの基関数とサービスが呼び出されるとき渡さなければならない抽象的なデータ要素によって定義されます。 このセクションはUserベースのSecurity Modelのために定義された基関数をリストアップします。
1.6.1. User-based Security Model Primitives for Authentication
1.6.1. 認証のためのユーザベースの機密保護モデル基関数
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:
UserベースのSecurity ModelはSecurity Model自身と認証サービスの間でデータを前後に通過するために以下の内部の基関数を提供します:
statusInformation =
authenticateOutgoingMsg(
IN authKey -- secret key for authentication
IN wholeMsg -- unauthenticated complete message
OUT authenticatedWholeMsg -- complete authenticated message
)
statusInformationはauthenticateOutgoingMsgと等しいです。(IN 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と等しいです。(IN authKey--ワイヤIN wholeMsgに受け取るようなワイヤOUT authenticatedWholeMsgに受け取られる認証IN authParametersのための秘密鍵--完全な認証されたメッセージ)
Blumenthal & Wijnen Standards Track [Page 11] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[11ページ]RFC3414USM
1.6.2. User-based Security Model Primitives for Privacy
1.6.2. プライバシーのためのユーザベースの機密保護モデル基関数
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:
UserベースのSecurity ModelはSecurity Model自身とプライバシーサービスの間でデータを前後に通過するために以下の内部の基関数を提供します:
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と等しいです。(IN encryptKey--暗号化IN dataToEncryptのための秘密鍵--サービスプロバイダーによって記入された(scopedPDU)OUT encryptedData(暗号化されたデータ(encryptedPDU)OUT privParameters)を暗号化するデータ)
statusInformation =
decryptData(
IN decryptKey -- secret key for decrypting
IN privParameters -- as received on the wire
IN encryptedData -- encrypted data (encryptedPDU)
OUT decryptedData -- decrypted data (scopedPDU)
)
statusInformationはdecryptDataと等しいです。(ワイヤIN encryptedDataに受け取るようにIN privParametersを解読するための秘密鍵がデータ(encryptedPDU)OUT decryptedDataを暗号化したというデータ(scopedPDU)であると解読されたIN decryptKey)
2. Elements of the Model
2. モデルのElements
This section contains definitions required to realize the security model defined by this memo.
このセクションはこのメモで定義された機密保護モデルがわかるのに必要である定義を含みます。
2.1. User-based Security Model Users
2.1. ユーザベースの機密保護モデルのユーザ
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.
このSecurity Modelを使用する管理操作が定義されたセットのユーザアイデンティティを利用します。 だれの利益管理操作が特定のSNMPエンジンで認可されるかのどんなユーザに関してはも、そのSNMPエンジンには、そのユーザに関する知識がなければなりません。 また、別のSNMPエンジンとコミュニケートしたがっているSNMPエンジンで、ユーザに関する知識をそのエンジンに知らなければなりません、そのユーザの適切な属性に関する知識を含んでいて。
A user and its attributes are defined as follows:
ユーザとその属性は以下の通り定義されます:
userName
A string representing the name of the user.
ユーザの名前を表すuserName五弦。
securityName
A human-readable string representing the user in a format that is
Security Model independent. There is a one-to-one relationship
between userName and securityName.
Security Model独立者である形式でユーザの代理をするsecurityNameのA人間読み込み可能なストリング。 userNameとsecurityNameとの1〜1つの関係があります。
Blumenthal & Wijnen Standards Track [Page 12] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[12ページ]RFC3414USM
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 Anしるしを認証できます、そして、そうだとすれば、認証のタイプは議定書を作ります(使用されています)。 そのような2つのプロトコルがこのメモで定義されます:
- the HMAC-MD5-96 authentication protocol.
- the HMAC-SHA-96 authentication protocol.
- HMAC-MD5-96認証プロトコル。 - HMAC-SHA-96認証プロトコル。
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 Ifメッセージは認証できます、使用に、認証プロトコルによって主要な(個人的)の認証。 通常、ユーザの認証キーが異なった正式の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 Anしるしを保護できます、そして、そうだとすれば、プライバシーのタイプは議定書を作ります(使用されています)。 そのようなプロトコルの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 Ifメッセージは/が解読したアンであるかもしれません、使用に、プライバシープロトコルによって主要な(個人的)のプライバシー。 通常、ユーザのプライバシーキーが異なった正式の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。 アップデートがプライバシー保護を使う必要性なしで終了できるように、安全な方法でそれをします。
2.2. Replay Protection
2.2. 反復操作による保護
Each SNMP engine maintains three objects:
それぞれのSNMPエンジンは3個のオブジェクトを維持します:
- snmpEngineID, which (at least within an administrative domain)
uniquely and unambiguously identifies an SNMP engine.
- snmpEngineID。(そのsnmpEngineIDは唯一、明白にSNMPエンジンを特定します(少なくとも管理ドメインの中で))。
Blumenthal & Wijnen Standards Track [Page 13] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[13ページ]RFC3414USM
- snmpEngineBoots, which is a count of the number of times the SNMP
engine has re-booted/re-initialized since snmpEngineID was last
configured; and,
- snmpEngineBoots、snmpEngineIDが最後に構成されて以来、SNMPエンジンがリブートするか、または再初期化している回数のカウントはどれです。 そして
- snmpEngineTime, which is the number of seconds since the
snmpEngineBoots counter was last incremented.
- snmpEngineTime、snmpEngineBootsが反対するのでどれが秒数であるかは最後に増加されました。
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の値を維持するのに必要です。
2.2.1. msgAuthoritativeEngineID
2.2.1. msgAuthoritativeEngineID
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値は、1台のSNMPエンジンから別の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 [RFC3411]).
正式のSNMPエンジンが最初にインストールされるとき、企業特有のアルゴリズムによると、それはsnmpEngineIDの地方の値を設定します(SnmpEngineIDに関してSNMP Architectureドキュメント[RFC3411]のTextual Conventionの定義を見てください)。
2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime
2.2.2. msgAuthoritativeEngineBootsとmsgAuthoritativeEngineTime
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エンジンが動力付きであるときにさえカチカチする(すなわち、時がたつにつれて、増加します)非揮発性の時計を持っているという要件が全くありません。 むしろ、それは、非揮発性記憶装置でsnmpEngineBootsを検索して、増加して、次に、保存して、SNMPエンジンがリブートされるたびにゼロに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)に達するならまるでSNMPエンジンがリブートされたかのようにsnmpEngineBootsが増加されていて、snmpEngineTimeはゼロにリセットされて、再び増加し始めます。
Blumenthal & Wijnen Standards Track [Page 14] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[14ページ]RFC3414USM
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エンジンがリブートされる各回、その正式のSNMPエンジンのsnmpEngineBootsとsnmpEngineTimeの値を保持するどんな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値を決定できないなら、それはsnmpEngineBoots値を2147483647に設定しなければなりません。
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エンジンに知られているすべてのユーザの認証とプライバシープロトコルのための新しい秘密の値でエンジンを物理的に訪問されて、再構成しなければなりません。 SNMPエンジンが、1秒に一度2147483647の最大値に達する前にそれがまだおよそ68年かかっているのをリブートしても、それに注意してください。
2.2.3. Time Window
2.2.3. タイム・ウィンドウ
The Time Window is a value that specifies the window of time in which a message generated on behalf of any user is valid. This memo specifies that the same value of the Time Window, 150 seconds, is used for all users.
タイム・ウィンドウはどんなユーザを代表して生成されたメッセージが有効である時間の窓を指定する値です。 このメモは、タイム・ウィンドウの同じ値(150秒)がすべてのユーザに使用されると指定します。
2.3. Time Synchronization
2.3. 時間同期化
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
非正式のSNMPエンジンが正式のSNMPエンジンから正式のSNMPエンジンのsnmpEngineBootsとsnmpEngineTimeの値のローカルの概念を得たとき、正統のコミュニケーションを続けるために非正式のSNMPエンジンによって必要とされた時間同期化は起こりました。 正式のSNMPエンジンのタイム・ウィンドウの中にこれらの値があるに違いありません(残ってください)。 それで、緩く正式のSNMPエンジンに保存される値に連動しているように正式のSNMPエンジンの値のローカルの概念を保たなければなりません。 また、正式のSNMPエンジンからsnmpEngineBootsとsnmpEngineTimeの地方の写しを取っておくことに加えて、非正式のSNMPエンジンは1つを保たなければなりません。
Blumenthal & Wijnen Standards Track [Page 15] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[15ページ]RFC3414USM
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.
局所変数、latestReceivedEngineTime。 この値は非正式のSNMPエンジンによって正式のSNMPエンジンから受け取られて、非正式のSNMPエンジンのsnmpEngineTimeの概念が進むのを防ぐメッセージを再演する可能性を排除するのに使用される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の地方の値がゼロに設定されるべきであるというメモ。 次の正統のメッセージが受信されているとき、これで、時間同期化は起こるでしょう。
2.4. SNMP Messages Using this Security Model
2.4. SNMP Messages UsingはこのSecurity Modelです。
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 [RFC3412]).
このSecurity Modelを使用するSNMPメッセージの構文はバージョン特有のMessage Processing Modelドキュメント(例えば、[RFC3412])で定義されたメッセージ・フォーマットを固く守ります。
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メッセージの分野msgSecurityParametersには、OCTET STRINGに関するデータ型があります。 値は以下のASN.1系列のBER連載です:
USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
USMSecurityParametersSyntax定義、内在しているタグ:、:= 始まってください。
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
UsmSecurityParameters:、:= SEQUENCE、--グローバルなUserベースのセキュリティパラメタmsgAuthoritativeEngineID OCTET STRING、msgAuthoritativeEngineBoots INTEGER(0 .2147483647)、msgUserName OCTET STRING(SIZE(0 .32))--認証プロトコルの特定のパラメタmsgAuthenticationParameters OCTET STRING--msgAuthoritativeEngineTime INTEGER(0 .2147483647)、プライバシーが特定のパラメタmsgPrivacyParameters OCTET STRINGについて議定書の中で述べる
Blumenthal & Wijnen Standards Track [Page 16] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[16ページ]RFC3414USM
}
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はメッセージがに代わって交換されているユーザ(主体)を指定します。 無の長さのuserNameがどんなユーザにも合いませんが、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.
- msgAuthenticationParametersはメッセージに、使用中の認証プロトコルによって定義されます、ユーザのエントリーでusmUserAuthProtocolコラムによってusmUserTableで定義されるように。
- 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).
- msgPrivacyParametersはメッセージのためにプライバシープロトコルによって使用中に定義されます、ユーザのエントリーでusmUserPrivProtocolコラムによってusmUserTableで定義されるように)
See appendix A.4 for an example of the BER encoding of field msgSecurityParameters.
分野msgSecurityParametersのBERコード化の例に関して付録A.4を見てください。
2.5. Services provided by the User-based Security Model
2.5. ユーザベースの機密保護モデルによって提供されたサービス
This section describes the services provided by the User-based Security Model with their inputs and outputs.
このセクションはUserベースのSecurity Modelによって彼らの入力と出力に提供されたサービスについて説明します。
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.
サービスは抽象的なサービスインタフェースに関する基関数として記述されています、そして、それらがこれらの抽象的なサービス基関数で通過されるのに従って、入力と出力は抽象的なデータ要素として記述されています。
2.5.1. Services for Generating an Outgoing SNMP Message
2.5.1. 送信するSNMPメッセージを生成するためのサービス
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:
Message Processing(MP)サブシステムが送信するSNMPメッセージを保証するためにUserベースのSecurityモジュールを呼び出すとき、それはSecurityモジュールで提供するように適切なサービスを利用しなければなりません。 これらの2つのサービスを提供します:
Blumenthal & Wijnen Standards Track [Page 17] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[17ページ]RFC3414USM
1) A service to generate a Request message. The abstract service
primitive is:
1) Requestメッセージを生成するサービス。 抽象的なサービス基関数は以下の通りです。
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=--成功かerrorIndication generateRequestMsg( IN messageProcessingModel--送信されるメッセージIN securityEngineIDのための送付SNMP実体IN securityModelの通常SNMPバージョンIN globalData(メッセージヘッダー、アドミンデータIN maxMessageSize)--正式のSNMP実体IN securityName; この主要なIN securityLevel--Securityの要求されたIN scopedPDU--メッセージ(平文)ペイロードOUT securityParameters(Security Module OUT wholeMsgによって記入される)の完全な発生しているメッセージOUT wholeMsgLengthのレベル--発生しているメッセージの長さを代表して; )
2) A service to generate a Response message. The abstract service
primitive is:
2) Responseメッセージを生成するサービス。 抽象的なサービス基関数は以下の通りです。
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
)
statusInformation=--成功かerrorIndication generateResponseMsg( IN messageProcessingModel--通常SNMPバージョンIN globalData--メッセージヘッダー(この主要なIN securityLevelを代表した送信されるメッセージIN securityEngineID(正式のSNMP実体IN securityName)のための送付SNMP実体IN securityModelのアドミンデータIN maxMessageSize); Securityのレベルは、IN scopedPDU--メッセージ(平文)ペイロードIN securityStateReference--セキュリティ状態の参照(オリジナルからの情報)がOUT securityParametersを要求するよう要求しました--Security Module OUT wholeMsg--完全な発生しているメッセージOUT wholeMsgLength--発生しているメッセージの長さで、記入されます; )
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.
メッセージをコード化と機密保護するのがうまくいったかどうかstatusInformation Anしるし。 まして、それは問題のしるしです。
Blumenthal & Wijnen Standards Track [Page 18] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[18ページ]RFC3414USM
messageProcessingModel
The SNMP version number for the message to be generated. This
data is not used by the User-based Security module.
バージョンが生成するべきメッセージのために付番するmessageProcessingModel SNMP。 このデータはUserベースのSecurityモジュールで使用されません。
globalData
The message header (i.e., its administrative information). This
data is not used by the User-based Security module.
メッセージヘッダー(すなわち、管理情報)のglobalData。 このデータはUserベースのSecurityモジュールで使用されません。
maxMessageSize
The maximum message size as included in the message. This data is
not used by the User-based Security module.
メッセージの含まれるとしての最大のメッセージサイズのmaxMessageSize。 このデータはUserベースのSecurityモジュールで使用されません。
securityParameters
These are the security parameters. They will be filled in by the
User-based Security module.
securityParameters Theseはセキュリティパラメタです。 UserベースのSecurityモジュールでそれらは記入されるでしょう。
securityModel
The securityModel in use. Should be User-based Security Model.
This data is not used by the User-based Security module.
使用中のsecurityModelのsecurityModel。 UserベースのSecurity Modelであるべきです。 このデータはUserベースのSecurityモジュールで使用されません。
securityName
Together with the snmpEngineID it identifies a row in the
usmUserTablethat 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.
メッセージを保証するusmUserTablethatが使用されていることになっているそれが行を特定するsnmpEngineIDでのsecurityName Together。 securityNameには、Security Modelから独立している形式があります。 応答の場合には、このパラメタは無視されます、そして、キャッシュからの値は使用されています。
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.
UserベースのSecurityモジュールが、メッセージが、公開から保護される必要があるかどうかと、メッセージが、認証される必要であるかどうか決定するSecurityのsecurityLevel Level。
securityEngineID
The snmpEngineID of the authoritative SNMP engine to which a
dateRequest 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.
送られるdateRequestメッセージがことである正式のSNMPエンジンのsecurityEngineID snmpEngineID。 応答の場合には処理SNMPエンジンのsnmpEngineIDであることが暗示しているので、指定されるなら、それは無視されます。
scopedPDU
The message payload. The data is opaque as far as the User-based
Security Model is concerned.
scopedPDU、メッセージペイロード。 UserベースのSecurity Modelに関する限り、データは不明瞭です。
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.
送信するResponseメッセージを保証するとき使用されるべきcachedSecurityDataのsecurityStateReference Aハンドル/参照。 これがResponseメッセージである入って来るRequestメッセージを処理するとき、それがUserベースのSecurityモジュールで生成されたとき、これは全く同じハンドル/参照です。
Blumenthal & Wijnen Standards Track [Page 19] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[19ページ]RFC3414USM
wholeMsg
The fully encoded and secured message ready for sending on the
wire.
ワイヤを転送するための完全にコード化されていて機密保護しているメッセージ準備ができることのwholeMsg。
wholeMsgLength
The length of the encoded and secured message (wholeMsg).
コード化されて機密保護しているメッセージ(wholeMsg)の長さのwholeMsgLength。
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.
プロセスの完成のときに、UserベースのSecurityモジュールはstatusInformationを返します。 プロセスがうまくいったなら、指定されたsecurityLevelがそのようなものを要求したなら、プライバシーと認証が適用されている完成したメッセージを返します。 プロセスがうまくいかなかったなら、errorIndicationを返します。
2.5.2. Services for Processing an Incoming SNMP Message
2.5.2. 入って来るSNMPメッセージを処理するためのサービス
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:
Message Processing(MP)サブシステムが入力メッセージの適切なセキュリティについて確かめるためにUserベースのSecurityモジュールを呼び出すとき、それは入力メッセージに提供されたサービスを利用しなければなりません。 抽象的なサービス基関数は以下の通りです。
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
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
statusInformation=--errorIndicationか成功; 誤りは誤りであるならOID/値を打ち返します; processIncomingMsg、(受信されたメッセージIN securityModel、ワイヤIN wholeMsgLength--ワイヤOUT securityEngineIDに受け取られる長さ--正式のSNMP実体OUT securityName--主要なOUT scopedPDUの識別--メッセージに受け取られる受信されたメッセージIN securityLevel(Security IN wholeMsgのレベル)のためのIN messageProcessingModel(送付SNMP実体IN securityParametersの通常SNMPバージョンIN maxMessageSize)、(平文; )、OUT maxSizeResponseScopedPDU(Response 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.
プロセスがうまくいったかどうかstatusInformation Anしるし。 そうでなければ、そして、statusInformationは増加された誤りカウンタのOIDと値を含んでいます。
messageProcessingModel
The SNMP version number as received in the message. This data is
not used by the User-based Security module.
バージョンがメッセージに受け取るように付番するmessageProcessingModel SNMP。 このデータはUserベースのSecurityモジュールで使用されません。
Blumenthal & Wijnen Standards Track [Page 20] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[20ページ]RFC3414USM
maxMessageSize
The maximum message size as included in the message. The User-bas
User-based Security module uses this value to calculate the
maxSizeResponseScopedPDU.
メッセージの含まれるとしての最大のメッセージサイズのmaxMessageSize。 User-BaのUserベースのSecurityモジュールは、maxSizeResponseScopedPDUについて計算するのにこの値を使用します。
securityParameters
These are the security parameters as received in the message.
securityParameters Theseはメッセージに受け取るようにセキュリティパラメタです。
securityModel
The securityModel in use. Should be the User-based Security
Model. This data is not used by the User-based Security module.
使用中のsecurityModelのsecurityModel。 UserベースのSecurity Modelであるべきです。 このデータはUserベースのSecurityモジュールで使用されません。
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.
UserベースのSecurityモジュールが、メッセージが、公開から保護される必要があるかどうかと、メッセージが、認証される必要であるかどうか決定するSecurityのsecurityLevel Level。
wholeMsg
The whole message as it was received.
全体がそれとして通信させるwholeMsgを受け取りました。
wholeMsgLength
The length of the message as it was received (wholeMsg).
それとしてのメッセージの長さのwholeMsgLengthを受け取りました(wholeMsg)。
securityEngineID
The snmpEngineID that was extracted from the field
msgAuthoritativeEngineID and that was used to lookup the secrets
in the usmUserTable.
分野msgAuthoritativeEngineIDとそれから抽出されたsecurityEngineID snmpEngineIDはルックアップに使用されました。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.
securityName、メッセージがに代わって受け取られたユーザの代理をするセキュリティ名。 securityNameには、Security Modelから独立している形式があります。
scopedPDU
The message payload. The data is opaque as far as the User-based
Security Model is concerned.
scopedPDU、メッセージペイロード。 UserベースのSecurity Modelに関する限り、データは不明瞭です。
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.
可能なResponseメッセージに含まれるべきscopedPDUの最大サイズのmaxSizeResponseScopedPDU。 UserベースのSecurityモジュールはmsgMaxSizeに基づくこのサイズについて計算します、そして、(メッセージに受け取るように)スペースがそのようなResponseメッセージのためのメッセージヘッダー(securityParametersを含んでいる)に必要です。
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メッセージを保証するとき使用されるべきcachedSecurityDataのsecurityStateReference Aハンドル/参照。 Message Processing Subsystemがaを生成するためにUserベースのSecurityモジュールを呼ぶとき
Blumenthal & Wijnen Standards Track [Page 21] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[21ページ]RFC3414USM
response to this incoming message it must pass this
handle/reference.
それがこのハンドル/参照に合格しなければならないこの入力メッセージへの応答。
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.
プロセスの完成のときに、UserベースのSecurityモジュールはメッセージのさらなる処理のためにstatusInformationとプロセスがうまくいったときの追加データに要素を返します。 プロセスがうまくいかなかったなら、そして、ことによると増加された誤りカウンタのOIDと値の組をもってerrorIndicationです。
2.6. Key Localization Algorithm.
2.6. 主要なローカライズアルゴリズム。
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].
ユーザは、全体のネットワークのために1つのパスワードしか持っていなくて、したがって、1個のキーを持っているかもしれませんが、ローカライズしているキーはユーザUと1台の正式のSNMPエンジンE.Evenの間で共有された秘密鍵です、そして、実際の秘密はユーザを平等に割り当てました、そして、それぞれの正式の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.
まず最初に、ユーザがパスワードを使用するなら、ユーザのパスワードは、Appendices A.2.1とA.2.2で説明された2つのアルゴリズムの1つを使用することで主要な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.
1つは、正式のSNMPエンジンEでユーザUのローカライズしている主要なKulに主要なKuを変換するために、正式のSNMPエンジンのsnmpEngineIDを主要なKuに追加して、次に、主要なKuを結果に追加します、その結果、ユーザの主要なKuのコピー2部の中でsnmpEngineIDをおおいます。 そして、1つは安全なハッシュ関数を実行します(どれが認証プロトコルによるかがこのユーザのために正式のSNMPエンジンEでUを定義しました; このドキュメントはMD5に基づくそれらの関連アルゴリズムとSHAと共に2つの認証プロトコルを定義します)。 ハッシュ関数の出力は正式のSNMPエンジンEのユーザUのためのローカライズしている主要なKulです。
3. Elements of Procedure
3. 手順のElements
This section describes the security related procedures followed by an SNMP engine when processing SNMP messages according to the User-based Security Model.
このセクションはUserベースのSecurity Modelによると、SNMPメッセージを処理するとき関連する手順がSNMPエンジンを続けたセキュリティについて説明します。
3.1. Generating an Outgoing SNMP Message
3.1. 送信する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.
このセクションはユーザを代表して管理操作(要求、応答、通知、またはレポートのような)を含むメッセージを生成するときはいつも、SNMPエンジンが支えた手順について説明します、特定のsecurityLevelと共に。
Blumenthal & Wijnen Standards Track [Page 22] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[22ページ]RFC3414USM
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.
1) a) (応答かReportメッセージ)がどんなsecurityStateReferenceにも通過されるなら、ユーザの情報は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.
securityNameに基づくb)(securityEngineIDによって指定された目的地snmpEngineIDのユーザの情報)はLocal Configuration Datastore(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.
3) securityLevelが、メッセージが認証されることであると指定しますが、ユーザが認証プロトコルをサポートしないなら、メッセージを送ることができません。 誤り表示(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:
4) a) securityLevelが、メッセージが公開から保護されることであると指定するなら、ユーザのプライバシープロトコルによると、連載された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=--成否encryptData(ユーザがprivKey IN dataToEncryptであることが配属されるというIN encryptKeyはscopedPDU OUT encryptedDataを連載しました--連載されたencryptedPDU OUT privParameters--プライバシーパラメタを連載します)
statusInformation
indicates if the encryption process was successful or not.
statusInformationは、暗号化プロセスがうまくいったかどうかを示します。
encryptKey
the user's localized private privKey is the secret key that
can be used by the encryption algorithm.
ユーザが個人的なprivKeyをローカライズしたencryptKeyは暗号化アルゴリズムで使用できる秘密鍵です。
Blumenthal & Wijnen Standards Track [Page 23] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[23ページ]RFC3414USM
dataToEncrypt
the serialized scopedPDU is the data to be encrypted.
dataToEncryptの連載されたscopedPDUは暗号化されるべきデータです。
encryptedData
the encryptedPDU represents the encrypted scopedPDU, encoded
as an OCTET STRING.
encryptedData encryptedPDUはOCTET STRINGとしてコード化された暗号化されたscopedPDUを表します。
privParameters
the privacy parameters, encoded as an OCTET STRING.
プライバシーパラメタであって、OCTET STRINGとしてコード化された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.
プライバシーモジュールが成功を返すなら、securityParametersのmsgPrivacyParameters分野に返されたprivParametersを入れます、そして、準備されていて、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が、メッセージが公開から保護されています、次に、無の長さのOCTET STRINGが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はOCTET STRINGとしてsecurityParametersのmsgAuthoritativeEngineID分野にコード化されます。 それがリモートを引き起こすので(正式の)、Requestメッセージに、空(ゼロ・レングス)のsecurityEngineIDがOKであることに注意してください。 返すそのsecurityParametersのmsgAuthoritativeEngineIDに適切なsecurityEngineIDとReport PDUを含んでいるSNMPエンジンはReport PDUを返しました。
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.
6) a) securityLevelが、メッセージが認証されることであると指定するなら、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) これがResponseかReportメッセージであり、その時がsnmpEngineBootsの現在の値であり、snmpEngineTimeが対応しているなら、LCDからの地方のsnmpEngineIDは使用されています。
Blumenthal & Wijnen Standards Track [Page 24] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[24ページ]RFC3414USM
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) これがRequestメッセージであり、次に、snmpEngineBootsとsnmpEngineTimeの両方に使用されるならゼロが、評価する。 snmpEngineIDが空であるなら、これは使用されますゼロが、評価する。
The values are encoded as INTEGER respectively into the
msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime
fields of the securityParameters.
値はINTEGERとしてそれぞれsecurityParametersのmsgAuthoritativeEngineBootsとmsgAuthoritativeEngineTime分野にコード化されます。
7) The userName is encoded as an OCTET STRING into the msgUserName
field of the securityParameters.
7) userNameはOCTET STRINGとしてsecurityParametersのmsgUserName分野にコード化されます。
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:
8) a) securityLevelが、メッセージが認証されることであると指定するなら、ユーザの認証プロトコルによると、メッセージは認証されます。 そう呼び出しするのを抽象的なサービスに従って原始的にユーザの認証プロトコルを実装する認証モジュールにします:
statusInformation =
authenticateOutgoingMsg(
IN authKey -- the user's localized authKey
IN wholeMsg -- unauthenticated message
OUT authenticatedWholeMsg -- authenticated complete message
)
statusInformationはauthenticateOutgoingMsgと等しいです。(ユーザがauthKey IN wholeMsgであることが配属されるというIN authKeyはメッセージOUT authenticatedWholeMsgを非認証しました--認証された完全なメッセージ)
statusInformation
indicates if authentication was successful or not.
statusInformationは、認証がうまくいったかどうかを示します。
authKey
the user's localized private authKey is the secret key that
can be used by the authentication algorithm.
ユーザが個人的なauthKeyをローカライズしたauthKeyは認証アルゴリズムで使用できる秘密鍵です。
wholeMsg
the complete serialized message to be authenticated.
完全なwholeMsgは認証されるべきメッセージを連載しました。
authenticatedWholeMsg
the same as the input given to the authenticateOutgoingMsg
service, but with msgAuthenticationParameters properly
filled in.
中の入力がauthenticateOutgoingMsgサービスに与えましたが、msgAuthenticationParametersで適切にいっぱいになったのと同じ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)を呼ぶモジュールに返します。
Blumenthal & Wijnen Standards Track [Page 25] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[25ページ]RFC3414USM
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が、メッセージが認証されないことであると指定するなら、無の長さのOCTET STRINGはsecurityParametersのmsgAuthenticationParameters分野にコード化されます。 wholeMsgは現在、連載されて、準備されていて、次に、非認証されたメッセージを表します。
9) The completed message with its length is returned to the calling
module with the statusInformation set to success.
9) 成功に用意ができているstatusInformationがある呼ぶモジュールに長さがある完成したメッセージを返します。
3.2. Processing an Incoming SNMP Message
3.2. 入って来るSNMPメッセージを処理します。
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.
このセクションはユーザを代表して管理操作を含むメッセージを受け取るときはいつも、SNMPエンジンが支えた手順について説明します、特定のsecurityLevelと共に。
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.
手順の要素を簡素化するために、州の情報のリリースはいつも明らかに指定されるというわけではありません。 また、概して、メッセージがいつ捨てられるかという州の情報が利用可能であるなら、州の情報は発表されるべきです。 また、誤り表示は任意にOIDと値を増加しているカウンタに返すことができます。securityLevelのための値、およびカウンタへのcontextEngineIDかcontextNameのための値。 さらに、誤りがどこに検出されるかというそのような何か情報がポイントで利用可能であるなら、securityStateReferenceデータを返します。
1) If the received securityParameters is not the serialization
(according to the conventions of [RFC3417]) of an OCTET STRING
formatted according to the UsmSecurityParameters defined in
section 2.4, then the snmpInASNParseErrs counter [RFC3418] 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によると、フォーマットされたOCTET STRINGの連載([RFC3417]のコンベンションによると)でないなら、snmpInASNParseErrsカウンタ[RFC3418]は増加しています、そして、誤り表示(parseError)を呼ぶモジュールに返します。 私たちが増加しているカウンタのOIDと値なしで戻ることに注意してください、この場合、Report PDUを発生させることができるくらいの情報がないので。
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
Blumenthal & Wijnen Standards Track [Page 26] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[26ページ]RFC3414USM
3) If the value of the msgAuthoritativeEngineID field in the
securityParameters is unknown then:
3) securityParametersのmsgAuthoritativeEngineID分野の値がその時未知であるなら:
a) a non-authoritative SNMP engine that performs discovery may
optionally create a new entry in its Local Configuration
Datastore (LCD) and continue processing;
a) 発見を実行する非正式のSNMPエンジンは、Local Configuration Datastore(LCD)で任意に新しいエントリーを作成して、処理し続けるかもしれません。
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)は、engineID発見を容易にするために選ばれるべきです。 さもなければ、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分野の値に関する情報はLocal Configuration Datastore(LCD、usmUserTable)から抜粋されます。 どんな情報もユーザに利用可能でないなら、usmStatsUnknownUserNamesカウンタは増加しています、そして、増加しているカウンタのOIDと値に伴う誤り表示(unknownSecurityName)を呼ぶモジュールに返します。
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) ユーザの情報が、訪問者によって要求されたsecurityLevelを支持しないのを示すなら、usmStatsUnsupportedSecLevelsカウンタは増加しています、そして、増加しているカウンタのOIDと値に伴う誤り表示(unsupportedSecurityLevel)を呼ぶモジュールに返します。
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=--成否authenticateIncomingMsg(ユーザがauthKey IN authParametersを局所化したというワイヤOUT authenticatedWholeMsgに受け取るような認証がないかどうかチェックされたワイヤIN wholeMsgに受け取られるIN authKey)
Blumenthal & Wijnen Standards Track [Page 27] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[27ページ]RFC3414USM
statusInformation
indicates if authentication was successful or not.
statusInformationは、認証がうまくいったかどうかを示します。
authKey
the user's localized private authKey is the secret key that
can be used by the authentication algorithm.
ユーザのauthKeyの局所化された個人的なauthKeyは認証アルゴリズムで使用できる秘密鍵です。
wholeMsg
the complete serialized message to be authenticated.
完全なwholeMsgは認証されるべきメッセージを連載しました。
authenticatedWholeMsg
the same as the input given to the authenticateIncomingMsg
service, but after authentication has been checked.
入力を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.
7) securityLevelが認証されたメッセージを示すなら、msgAuthoritativeEngineID分野の値に対応するsnmpEngineBoots、snmpEngineTime、およびlatestReceivedEngineTimeの地方の値はLocal Configuration Datastoreから抽出されます。
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:
a) msgAuthoritativeEngineIDの抽出された値が処理SNMPエンジンのsnmpEngineIDの値と同じであるなら(これを意味するのは、正式のSNMPエンジンです)、以下の条件のどれかが本当であるなら、メッセージがタイム・ウィンドウの外にあると考えられます:
- 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分野の値は+/-以上でsnmpEngineTimeのローカルの概念と150秒異なっています。
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
メッセージがタイム・ウィンドウの外にあると考えられるなら、usmStatsNotInTimeWindowsカウンタは、増加されていてOIDに伴う誤り表示(notInTimeWindow)、増加しているカウンタの値であり、指示はそれです。
Blumenthal & Wijnen Standards Track [Page 28] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[28ページ]RFC3414USM
the error must be reported with a securityLevel of authNoPriv,
is returned to the calling module
誤りは、authNoPrivのsecurityLevelと共に報告しなければならなくて、呼ぶモジュールに返されます。
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エンジンのsnmpEngineID(これを意味するのは、正式のSNMPエンジンでない)ではありません:
1) if at least one of the following conditions is true:
1) 少なくとも以下の条件の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,
- msgAuthoritativeEngineBoots分野の値へのsnmpEngineBootsの価値のローカルの概念
- the local notion of the value of snmpEngineTime to the
value of the msgAuthoritativeEngineTime field, and
- そしてmsgAuthoritativeEngineTime分野の値へのsnmpEngineTimeの価値のローカルの概念。
- the latestReceivedEngineTime to the value of the value of
the msgAuthoritativeEngineTime field.
- msgAuthoritativeEngineTime分野の価値の値へのlatestReceivedEngineTime。
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秒以上少ないです。
Blumenthal & Wijnen Standards Track [Page 29] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[29ページ]RFC3414USM
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.
これが、古過ぎる(ことによると再演された)メッセージが検出されて、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エンジン最終以来リブートされている正式のSNMPエンジンから受け取ると考慮するsnmpEngineBootsの価値のローカルの概念が正統であるとして認められるべきメッセージを受け取ったよりすばらしくなるメッセージのmsgAuthoritativeEngineBootsの値を考慮することに注意してください、(再、)、連動しています。
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を表すOCTET STRINGは、非コード化された連載された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=--成否decryptData(ユーザがprivKey IN privParametersを局所化したというワイヤIN encryptedData--容認されたOUT decryptedDataとしてのencryptedPDU--連載された解読されたscopedPDUに受け取られるIN decryptKey)
statusInformation
indicates if the decryption process was successful or not.
statusInformationは、復号化の過程がうまくいったかどうかを示します。
decryptKey
the user's localized private privKey is the secret key that
can be used by the decryption algorithm.
ユーザのdecryptKeyの局所化された個人的なprivKeyは復号化アルゴリズムで使用できる秘密鍵です。
privParameters
the msgPrivacyParameters, encoded as an OCTET STRING.
OCTET STRINGとしてコード化されたprivParameters msgPrivacyParameters。
encryptedData
the encryptedPDU represents the encrypted scopedPDU,
encoded as an OCTET STRING.
encryptedData encryptedPDUはOCTET STRINGとしてコード化されたコード化されたscopedPDUを表します。
decryptedData
the serialized scopedPDU if decryption is successful.
decryptedDataの連載されたscopedPDUは復号化であるならうまくいっています。
Blumenthal & Wijnen Standards Track [Page 30] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[30ページ]RFC3414USM
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は計算されます。 これは可能なResponseメッセージのためのscopedPDUのために許容された最大サイズです。 容認されたRequestと同じ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
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パラメタを戻す呼ぶモジュールにします。
4. Discovery
4. 発見
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
UserベースのSecurity Modelは、発見の過程が彼らとコミュニケートするために他のSNMPエンジンに関する十分な情報を得るのを必要とします。 発見は、コミュニケーションが続くかもしれない前に正式のSNMPエンジンのsnmpEngineID値を学ぶために非正式のSNMPエンジンを必要とします。 これは、noAuthNoPrivのsecurityLevel、ゼロ・レングスのmsgUserName、ゼロ・レングスのmsgAuthoritativeEngineID値、および空の状態で残っているvarBindListと共にRequestメッセージを発生させることによって、達成されるかもしれません。 このメッセージへの応答はmsgAuthoritativeEngineID分野の値としてmsgSecurityParametersの中に正式のSNMPエンジンのsnmpEngineIDを含むReportメッセージになるでしょう。
Blumenthal & Wijnen Standards Track [Page 31] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[31ページ]RFC3414USM
field. It contains a Report PDU with the usmStatsUnknownEngineIDs counter in the varBindList.
さばきます。 それはusmStatsUnknownEngineIDsカウンタがvarBindListにあるReport 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の値で認証されたRequestメッセージを送ることによって、達成されたかもしれません、そして、msgAuthoritativeEngineTimeはゼロにセットしました。 認証されたRequestメッセージのために、msgUserName分野で有効なuserNameを使用しなければなりません。 この認証されたメッセージへの応答はそれぞれmsgAuthoritativeEngineBootsの値として正式のSNMPエンジンのsnmpEngineBootsとsnmpEngineTimeの値の日付を入れるために上がるのとmsgAuthoritativeEngineTime分野を含むReportメッセージになるでしょう。 また、それはReport PDUのvarBindListにusmStatsNotInTimeWindowsカウンタを含んでいます。 そして、時間同期化はセクション3.2ステップ7bの手順の一部として自動的に起こります。 また、セクション2.3を見てください。
5. Definitions
5. 定義
SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
SNMPのユーザベースのSm MIB定義:、:= 始まってください。
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;
SNMPフレームワークMIBからモジュールアイデンティティ、オブジェクト・タイプ、オブジェクトアイデンティティにSNMPv2-CONF SnmpAdminString、SnmpEngineID、snmpAuthProtocols、snmpPrivProtocolsからのsnmpModules、SNMPv2-SMIの原文のコンベンションからのCounter32、TestAndIncr、RowStatus、RowPointer、StorageType、SNMPv2-TcモジュールコンプライアンスからのAutonomousType、オブジェクトグループをインポートします。
snmpUsmMIB MODULE-IDENTITY
LAST-UPDATED "200210160000Z" -- 16 Oct 2002, 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"200210160000Z"--2002年10月16日、真夜中の組織「SNMPv3ワーキンググループ」コンタクトインフォメーションは「以下をWGメールします」。 snmpv3@lists.tislabs.com は申し込まれます: msgボディーの majordomo@lists.tislabs.com : snmpv3を申し込んでください。
Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
email: mundy@tislabs.com
議長: ラスマンディNetwork Associates研究所、郵便: 15204 オメガDrive、Suite300MD20850-4601ロックビル(米国)はメールされます: mundy@tislabs.com
Blumenthal & Wijnen Standards Track [Page 32] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[32ページ]RFC3414USM
phone: +1 301-947-7107
電話: +1 301-947-7107
Co-Chair: David Harrington
Enterasys Networks
Postal: 35 Industrial Way
P. O. Box 5004
Rochester, New Hampshire 03866-5005
USA
EMail: dbh@enterasys.com
Phone: +1 603-337-2614
共同議長: デヴィッドハリントンEnterasysがネットワークでつなぐ、郵便: 35の産業方法、私書箱5004ニューハンプシャー03866-5005ロチェスター(米国)はメールされます: dbh@enterasys.com 電話: +1 603-337-2614
Co-editor Uri Blumenthal
Lucent Technologies
postal: 67 Whippany Rd.
Whippany, NJ 07981
USA
email: uri@lucent.com
phone: +1-973-386-2163
共同エディタユリブルーメンソルルーセントテクノロジーズ郵便: 67ウィッパニー通り ニュージャージー07981ウィッパニー(米国)はメールされます: uri@lucent.com 電話: +1-973-386-2163
Co-editor: Bert Wijnen
Lucent Technologies
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: bwijnen@lucent.com
phone: +31-348-480-685
"
DESCRIPTION "The management information definitions for the
SNMP User-based Security Model.
共同エディタ: バートWijnenルーセントテクノロジーズ郵便: Schagen33 3461GLリンスホーテン・オランダはメールされます: bwijnen@lucent.com 電話: +31-348-480-685、「記述、「SNMP UserベースのSecurity Modelのための経営情報定義。」
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3414;
see the RFC itself for full legal notices.
"
-- Revision history
Copyright(C)インターネット協会(2002)。 このMIBモジュールのこのバージョンはRFC3414の一部です。 完全な法定の通知に関してRFC自身を見てください。 「--、改訂履歴、」
REVISION "200210160000Z" -- 16 Oct 2002, midnight
DESCRIPTION "Changes in this revision:
- Updated references and contact info.
- Clarification to usmUserCloneFrom DESCRIPTION
clause
- Fixed 'command responder' into 'command generator'
in last para of DESCRIPTION clause of
usmUserTable.
This revision published as RFC3414.
"
REVISION "199901200000Z" -- 20 Jan 1999, midnight
DESCRIPTION "Clarifications, published as RFC2574"
REVISION"200210160000Z"--2002年10月16日、真夜中の記述は「この改正で以下を変えます」。 - 参照とコンタクトインフォメーションをアップデートしました。 - usmUserCloneFrom記述節への明確化--usmUserTableの記述節の最後のパラの'コマンドジェネレータ'への固定'コマンド応答者'。 この改正はRFC3414として発行されました。 「"REVISION"199901200000Z」--1999年1月20日、「明確化であって、RFC2574として発行された」真夜中の記述
Blumenthal & Wijnen Standards Track [Page 33] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[33ページ]RFC3414USM
REVISION "199711200000Z" -- 20 Nov 1997, midnight
DESCRIPTION "Initial version, published as RFC2274"
REVISION"199711200000Z"--1997年11月20日、「初期のバージョンであって、RFC2274として発行された」真夜中の記述
::= { snmpModules 15 }
::= snmpModules15
-- Administrative assignments ****************************************
-- 管理課題****************************************
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
usmMIBObjectsオブジェクト識別子:、:= snmpUsmMIB1usmMIBConformanceオブジェクト識別子:、:= snmpUsmMIB2
-- Identification of Authentication and Privacy Protocols ************
-- 認証とプライバシープロトコル************の識別
usmNoAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Authentication Protocol."
::= { snmpAuthProtocols 1 }
usmNoAuthProtocol OBJECT-IDENTITY STATUSの現在の記述「いいえ認証プロトコル。」 ::= snmpAuthProtocols1
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.
"
::= { snmpAuthProtocols 2 }
「HMAC-MD5-96ダイジェスト認証は議定書の中で述べる」usmHMACMD5AuthProtocol OBJECT-IDENTITY STATUSの現在の記述。 参照、「-、H.Krawczyk、M.Bellare、R.カネッティHMAC:、」 通報認証、RFC2104のための1997年2月ときの合わせられた論じ尽くすこと。 - 最もRivest、R.、メッセージダイジェストアルゴリズムMD5、RFC1321。 " ::= snmpAuthProtocols2
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 }
「HMAC-SHA-96ダイジェスト認証は議定書の中で述べる」usmHMACSHAAuthProtocol OBJECT-IDENTITY STATUSの現在の記述。 参照、「-、H.Krawczyk、M.Bellare、R.カネッティ、HMAC:、」 通報認証、RFC2104のための1997年2月ときの合わせられた論じ尽くすこと。 - ハッシュアルゴリズムを保証してください。 NIST FIPS180-1。 " ::= snmpAuthProtocols3
usmNoPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Privacy Protocol."
::= { snmpPrivProtocols 1 }
usmNoPrivProtocol OBJECT-IDENTITY STATUSの現在の記述「いいえプライバシープロトコル。」 ::= snmpPrivProtocols1
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.
「CBC-DESの左右対称の暗号化は議定書の中で述べる」usmDESPrivProtocol OBJECT-IDENTITY STATUSの現在の記述。 参照、「-、データ暗号化規格、米国商務省標準技術局、」 連邦情報処理基準(FIPS)公表46-1。
Blumenthal & Wijnen Standards Track [Page 34] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[34ページ]RFC3414USM
Supersedes FIPS Publication 46,
(January, 1977; reaffirmed January, 1988).
FIPS Publication46、(再び断言された1月、1977年1月;1988)に取って代わります。
- Data Encryption Algorithm, American National
Standards Institute. ANSI X3.92-1981,
(December, 1980).
- データ暗号化アルゴリズム、American National Standards Institut。 ANSI X3.92-1981、(1980年12月。)
- DES Modes of Operation, National Institute of
Standards and Technology. Federal Information
Processing Standard (FIPS) Publication 81,
(December, 1980).
- DES運転モード、米国商務省標準技術局。 連邦情報処理基準(FIPS)公表81、(1980年12月。)
- Data Encryption Algorithm - Modes of Operation,
American National Standards Institute.
ANSI X3.106-1983, (May 1983).
"
::= { snmpPrivProtocols 2 }
- データ暗号化アルゴリズム--運転モード、American National Standards Institut。 ANSI X3.106-1983、(1983年5月。) " ::= snmpPrivProtocols2
-- 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.
KeyChange:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「この構文によるオブジェクトのあらゆる定義がプロトコルP、秘密鍵K、およびL八重奏の出力を起こすハッシュアルゴリズムHを特定しなければなりません」。
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の長さが特定の最大の長さまで可変であることを許容するなら、無作為のコンポーネントの長さはデルタコンポーネントの最大の長さと長さがその最大の、より長さであらゆる長さであるということです。 例えば、usmHMACMD5AuthProtocolは、Kが16八重奏とL、16の八重奏の固定長であることを必要とします。usmHMACSHAAuthProtocolは、Kが20八重奏とL、20の八重奏の固定長であることを必要とします。 適切であると考えられるように他のプロトコルは他のサイズを定義するかもしれません。
Blumenthal & Wijnen Standards Track [Page 35] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[35ページ]RFC3414USM
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:
リクエスタがリモート実体で古い主要なKを新しい主要なkeyNewに変えたいと、本当の無作為のジェネレータか、擬似ランダムジェネレータから'無作為'のコンポーネントを得ます、そして、以下の通り'デルタ'コンポーネントを計算します:
- 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.
- 一時的数値変数はKの既存の値に初期化されます。 - 次に、keyNewの長さがL八重奏より大きいなら: - 無作為のコンポーネントを一時的数値変数の値に追加します、そして、ダイジェスト値を生産するためにハッシュアルゴリズムHに結果を入力します、そして、このダイジェスト値に一時的数値変数を設定します。 - 'デルタ'コンポーネントの(次)の最初のL-八重奏(MD5の場合の16の八重奏)を起こすkeyNewの(次)の最初のL-八重奏(MD5の場合の16の八重奏)で一時的数値変数の値はXOR-教育です。 - 上の2ステップはkeyNewの部品の未使用の部分がL八重奏か以下になるまで繰り返されます--無作為のコンポーネントを一時的数値変数の値に追加します、そして、ダイジェスト値を生産するためにハッシュアルゴリズムHに結果を入力します。 - 必要ならkeyNewの未使用の部分と同じ長さになるように先端を切られたこのダイジェスト値が生産するkeyNewの未使用の部分があるXOR-教育である、(最終的な部分、)、'デルタ'コンポーネント。
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];
繰り返しは/16と等しいです(lenOfDelta--1)。 /*整数分割*/臨時はkeyOldと等しいです。 臨時はMD5と等しいです。臨時はMD5と等しいです。(i=0; i<繰り返し; i++)、(派遣社員として働いてください|、|、無作為である、)、; デルタ[i*16(i*16)+15]=臨時XOR keyNew[i*16(i*16)+15];、(派遣社員として働いてください|、|、無作為である、)、。 デルタ[i*16lenOfDelta-1]は臨時XOR keyNewと等しいです[i*16lenOfDelta-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の新しい値が以下の通り計算されます:
Blumenthal & Wijnen Standards Track [Page 36] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[36ページ]RFC3414USM
- 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.
- 一時的数値変数はKの既存の値に初期化されます。 - 次に、デルタコンポーネントの長さがL八重奏より大きいなら: - 無作為のコンポーネントを一時的数値変数の値に追加します、そして、ダイジェスト値を生産するためにハッシュアルゴリズムHに結果を入力します、そして、このダイジェスト値に一時的数値変数を設定します。 - K.の新しい価値の(次)の最初のL-八重奏(MD5の場合の16の八重奏)を起こすデルタコンポーネントの(次)の最初のL-八重奏(MD5の場合の16の八重奏)で一時的数値変数の値はXOR-教育です--上の2ステップはデルタコンポーネントの未使用の部分がL八重奏か以下になるまで繰り返されます--無作為のコンポーネントを一時的数値変数の値に追加します、そして、ダイジェスト値を生産するためにハッシュアルゴリズムHに結果を入力します。 - 必要ならデルタコンポーネントの未使用の部分と同じ長さになるように先端を切られたこのダイジェスト値が生産するデルタコンポーネントの未使用の部分があるXOR-教育である、(最終的な部分、)、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];
繰り返しは/16と等しいです(lenOfDelta--1)。 /*整数分割*/臨時はkeyOldと等しいです。 臨時はMD5と等しいです。臨時はMD5と等しいです。(i=0; i<繰り返し; i++)、(派遣社員として働いてください|、|、無作為である、)、; keyNew[i*16(i*16)+15]は臨時XORデルタ[i*16(i*16)+15]と等しいです;、(派遣社員として働いてください|、|、無作為である、)、。 keyNew[i*16lenOfDelta-1]は臨時XORデルタ[i*16lenOfDelta-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を送るのが賢明であり、キーチェンジが実際に成功したと確認するまで古いキーの写しを取っておくことに注意してください。 「構文八重奏ストリング」
Blumenthal & Wijnen Standards Track [Page 37] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[37ページ]RFC3414USM
-- Statistics for the User-based Security Model **********************
-- ユーザベースの機密保護モデル**********************のための統計
usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
usmStatsオブジェクト識別子:、:= usmMIBObjects1
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 }
「パケットの総数はSNMPエンジンにおいて未知であることの、または、そうでなければ入手できなかったsecurityLevelを要求したので下げられたSNMPエンジンで受けた」usmStatsUnsupportedSecLevels OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 " ::= usmStats1
usmStatsNotInTimeWindows 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 appeared
outside of the authoritative SNMP engine's window.
"
::= { usmStats 2 }
「パケットの総数は正式のSNMPエンジンの窓の外に現れたので下げられたSNMPエンジンで受けた」usmStatsNotInTimeWindows OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 " ::= usmStats2
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 }
「パケットの総数はSNMPエンジンに知られていなかったユーザに参照をつけたので下げられたSNMPエンジンで受けた」usmStatsUnknownUserNames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 " ::= usmStats3
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 }
「パケットの総数はSNMPエンジンに知られていなかったsnmpEngineIDに参照をつけたので下げられたSNMPエンジンで受けた」usmStatsUnknownEngineIDs OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 " ::= usmStats4
usmStatsWrongDigests OBJECT-TYPE
usmStatsWrongDigestsオブジェクト・タイプ
Blumenthal & Wijnen Standards Track [Page 38] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[38ページ]RFC3414USM
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 }
「パケットの総数は予想されたダイジェスト値を含まなかったので下げられたSNMPエンジンで受けた」SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 " ::= usmStats5
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 }
「パケットの総数はそれらを解読することができなかったので下げられたSNMPエンジンで受けた」usmStatsDecryptionErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 " ::= usmStats6
-- The usmUser Group ************************************************
-- usmUserグループ************************************************
usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
usmUserオブジェクト識別子:、:= usmMIBObjects2
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 }
usmUserSpinLock OBJECT-TYPE SYNTAX TestAndIncrマックス-ACCESSは「通知ロックで、数個の協力Command Generator ApplicationsがusmUserTableの秘密を変更するために以前はよく彼らの施設の使用を調整することができたこと」をSTATUSの現在の記述に読書して書きます。 " ::= usmUser1
-- The table of valid users for the User-based Security Model ********
-- Userベースの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).
「ユーザのテーブルはSNMPエンジンのLocal Configuration Datastore(LCD)で構成した」usmUserTable OBJECT-TYPE SYNTAX SEQUENCE OF UsmUserEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
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.
1) sValueのGET(usmUserSpinLock.0)とセーブ。
Blumenthal & Wijnen Standards Track [Page 39] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[39ページ]RFC3414USM
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.
2) (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) keyChangeが秘密のprivKeyに基づく値であると生成してください、クローン、-、ユーザ、そして、新しいユーザにとって使用されているために主要な秘密。 このpkcValueを呼びましょう。 4) sValueのGET(usmUserSpinLock.0)とセーブ。 5) (usmUserSpinLock.0=sValue、usmUserPrivKeyChange=pkcValue usmUserPublic=randomValue1)を設定してください。 6) GET(usmUserPulic)とそれが持っているチェック、randomValue1。 そうでなければ、ステップ4-6を繰り返してください。
If the new user will never use privacy:
新しいユーザがプライバシーを決して使用しないなら:
7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
7) セットします。(usmUserPrivProtocol=usmNoPrivProtocol)
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) keyChangeが秘密のauthKeyに基づく値であると生成してください、クローン、-、ユーザ、そして、新しいユーザにとって使用されているために主要な秘密。 このakcValueを呼びましょう。 9) sValueのGET(usmUserSpinLock.0)とセーブ。 10) (usmUserSpinLock.0=sValue、usmUserAuthKeyChange=akcValue usmUserPublic=randomValue2)を設定してください。 11) GET(usmUserPulic)とそれが持っているチェック、randomValue2。 そうでなければ、反復は9-11テロを踏みます。
If the new user will never use authentication:
新しいユーザが認証を決して使用しないなら:
12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
12) セットします。(usmUserAuthProtocol=usmNoAuthProtocol)
Finally, activate the new user:
最終的に、新しいユーザを動かしてください:
13) SET(usmUserStatus=active)
13) セットします。(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コミュニケーションに使用される準備ができているべきです。 しかしながら、SNMP-VIEWベースのACM-MIBの構成でMIBデータへのアクセスを提供しなければならないことに注意してください。
Blumenthal & Wijnen Standards Track [Page 40] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[40ページ]RFC3414USM
The use of usmUserSpinlock is to avoid conflicts with
another SNMP command generator application which may
also be acting on the usmUserTable.
"
::= { usmUser 2 }
usmUserSpinlockの使用はまた、usmUserTableに影響しているかもしれない別のSNMPコマンドジェネレータアプリケーションで摩擦を避けることです。 " ::= usmUser2
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 }
「ユーザはUserベースのSecurity ModelのためにSNMPエンジンのLocal Configuration Datastore(LCD)で構成した」usmUserEntry OBJECT-TYPE SYNTAX UsmUserEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「usmUserEngineID、usmUserNameに索引をつけてください:、:、」= usmUserTable1
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
}
UsmUserEntry:、:= 系列usmUserEngineID SnmpEngineID、usmUserName SnmpAdminString、usmUserSecurityName SnmpAdminString、usmUserCloneFrom RowPointer、usmUserAuthProtocol AutonomousType、usmUserAuthKeyChange KeyChange、usmUserOwnAuthKeyChange KeyChange、usmUserPrivProtocol AutonomousType、usmUserPrivKeyChange KeyChange、usmUserOwnPrivKeyChange KeyChange、usmUserPublic八重奏ストリング、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のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「SNMPエンジンの行政上ユニークな識別子。」
In a simple agent, this value is always that agent's
own snmpEngineID value.
純真なエージェントでは、この値はいつもそのエージェントの自己のsnmpEngineID値です。
The value can also take the value of the snmpEngineID
of a remote SNMP engine with which this user can
communicate.
また、値はこのユーザが交信できるリモートSNMPエンジンのsnmpEngineIDの値を取ることができます。
Blumenthal & Wijnen Standards Track [Page 41] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[41ページ]RFC3414USM
"
::= { usmUserEntry 1 }
" ::= usmUserEntry1
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))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「ユーザの名前を表す人間の読み込み可能なストリング。」
This is the (User-based Security) Model dependent
security ID.
"
::= { usmUserEntry 2 }
これは(ユーザベースのSecurity)モデルの依存するセキュリティIDです。 " ::= usmUserEntry2
usmUserSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the user in
Security Model independent format.
usmUserSecurityName OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「Security Modelの独立している形式でユーザの代理をする人間の読み込み可能なストリング。」
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 }
securityNameへのUserベースのSecurity Model依存するセキュリティIDのデフォルト変換が逆もまた同様にアイデンティティ機能であるので、securityNameはuserNameと同じです。 " ::= usmUserEntry3
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 SYNTAX RowPointerマックス-ACCESSは「別のものに概念的な指針はこのusmUserTableでこぐ」STATUSの現在の記述を読書して作成します。 この他の概念的な行のユーザが呼ばれる、クローン、-、ユーザ。
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.
新しいユーザの新しいユーザがいつ創造されるか、そして、(すなわち、新しい概念的な行はこのテーブルに例示されます)プライバシーと認証パラメタのクローンを作らなければならない、それ、クローン、-、ユーザ これらのパラメタは以下の通りです。 - 認証は(usmUserAuthProtocol)について議定書の中で述べます--プライバシーは(usmUserPrivProtocol)について議定書の中で述べます。それらは現行価値が何であるかにかかわらずコピーされるでしょう。
Cloning also causes the initial values of the secret
authentication key (authKey) and the secret encryption
また、クローニングは秘密の認証キー(authKey)の初期の値と秘密の暗号化を引き起こします。
Blumenthal & Wijnen Standards Track [Page 42] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[42ページ]RFC3414USM
key (privKey) of the new user to be set to the same
values as the corresponding secrets of the clone-from
user to allow the KeyChange process to occur as
required during user creation.
対応する秘密と同じ値に設定されるべき新しいユーザのキー(privKey)、クローン、-、ユーザ、KeyChangeプロセスが必要に応じてユーザ作成の間、起こるのを許容するために。
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 }
このオブジェクトを読むとき、ZeroDotZero OIDを返します。 " ::= usmUserEntry4
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.
usmUserAuthProtocol OBJECT-TYPE SYNTAX AutonomousTypeマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「メッセージが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 usmNoAuthProtocol.
一度例示されています、usmNoAuthProtocolの値への集合演算でこのオブジェクトのそのようなインスタンスの値を変えることができるだけです。
If a set operation tries to change the value of an
操作が値を変えようとするセットです。
Blumenthal & Wijnen Standards Track [Page 43] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[43ページ]RFC3414USM
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 }
同じ行のusmUserPrivProtocol値がusmNoPrivProtocolと等しくない間、集合演算がusmNoAuthProtocolに値を設定しようとするなら、'inconsistentValue'誤りを返さなければなりません。 それは、SNMPコマンドジェネレータアプリケーションが、最初にusmUserAuthProtocol値をusmNoAuthProtocolに設定できる前にusmUserPrivProtocolがusmNoPrivProtocol値に用意ができているのを確実にしなければならないことを意味します。 「DEFVAL usmNoAuthProtocol:、:、」= usmUserEntry5
usmUserAuthKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
-- typically (SIZE (0 | 40)) for HMACSHA
MAX-ACCESS read-create
STATUS current
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.
usmUserAuthKeyChange OBJECT-TYPE SYNTAX KeyChange--通常(SIZE(0|32))、HMACMD5、通常(SIZE(0|40))、HMACSHA MAX-ACCESSに関して、STATUSの現在の記述を読書して作成してください、「オブジェクト、どれ、変更されたいつ、秘密の認証キーがSNMPエンジンからの/へのこのユーザを代表して送られたメッセージに使用した原因が一方向関数で変更されるためにusmUserEngineIDを特定したか、」
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.
関連プロトコルはusmUserAuthProtocolです。 関連秘密鍵はユーザの秘密の認証キー(authKey)です。 関連ハッシュアルゴリズムはユーザの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:
キーチェンジをするお勧めの方法は以下の通りです:
Blumenthal & Wijnen Standards Track [Page 44] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[44ページ]RFC3414USM
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) sValueのGET(usmUserSpinLock.0)とセーブ。 2) 値で古い(存在している)秘密鍵と新しい秘密鍵に基づいて、私たちがこのkcValueを呼ぶことができたkeyChangeを生成してください。
If you do the key change on behalf of another user:
キーをするなら、別のユーザを代表して、変化してください:
3) SET(usmUserSpinLock.0=sValue,
usmUserAuthKeyChange=kcValue
usmUserPublic=randomValue)
3) セットします。(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) セットします。(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 }
あなたがnoErrorのエラー状況で返事をもらうなら、SETは成功しました、そして、新しいキーはアクティブです。 返事をもらわないなら、あなたは、GET(usmUserPublic)を発行して、値があなたがSETで送ったrandomValueと等しいかどうかチェックできます。 そうだとすれば、次に、キーチェンジは成功しました、そして、新しいキーはアクティブです(たぶん失せた応答)。 そうでなければ、次に、SET要求がたぶん目標に決して達しなかったので、あなたは上で手順でやり直すことができます。 「DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry6
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.
HMACSHA MAX-ACCESSがSTATUSの現在の記述を読書して作成するので、usmUserOwnAuthKeyChange OBJECT-TYPE SYNTAX KeyChange--HMACMD5のための通常(SIZE(0|32))--通常(SIZE(0|40))は「ちょうどある注目に値する違いがあるusmUserAuthKeyChangeとして以下を振る舞います」。 引き継ぐ集合演算において整然とします、操作リクエスタのusmUserNameはこの操作で狙う行に索引をつける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 authentication key (authKey).
Note that this can only be done once the row is active.
このコラムへのアクセスが公共である場合があるという考えがここにあります、ユーザがそれで、彼自身の秘密の認証キー(authKey)を変えることができるだけであるので。 行がいったんアクティブになる後これができるだけであることに注意してください。
Blumenthal & Wijnen Standards Track [Page 45] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[45ページ]RFC3414USM
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がこの操作で狙う行に索引をつけるumsUserNameと同じでないと、'noAccess'誤りを返さなければなりません。
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 }
そして、セットが受け取られていて、使用中の機密保護モデルがUSMでないときに、'noAccess'誤りを返さなければなりません。 「DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry7
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 OBJECT-TYPE SYNTAX AutonomousTypeマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「メッセージが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
また、何かプライバシープロトコルが使用されているなら認証プロトコルを使用しなければならないことに注意してください。 言い換えれば、usmUserAuthProtocolの対応するインスタンスが値を持つことができないその時usmUserPrivProtocolがusmNoPrivProtocolより他の何かに用意ができているなら
Blumenthal & Wijnen Standards Track [Page 46] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[46ページ]RFC3414USM
usmNoAuthProtocol. If it does, then an
'inconsistentValue' error must be returned.
"
DEFVAL { usmNoPrivProtocol }
::= { usmUserEntry 8 }
usmNoAuthProtocol。 そうするなら、'inconsistentValue'誤りを返さなければなりません。 「DEFVAL usmNoPrivProtocol:、:、」= usmUserEntry8
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、--、通常、デスマックス-ACCESSのための(SIZE(0|32))がSTATUSの現在の記述を読書して作成する「オブジェクト、どれ、変更されたいつ、秘密の暗号化キーがSNMPエンジンからの/へのこのユーザを代表して送られたメッセージに使用した原因が一方向関数で変更されるためにusmUserEngineIDを特定したか、」
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.
関連プロトコルはusmUserPrivProtocolです。 関連秘密鍵はユーザの秘密のプライバシーキー(privKey)です。 関連ハッシュアルゴリズムはユーザの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 }
このオブジェクトを読むとき、ゼロ・レングスの(空)のストリングを返します。 usmUserAuthKeyChangeの記述節を見て、お勧めの手順はキーチェンジをしてください。 「DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry9
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
usmUserOwnPrivKeyChange OBJECT-TYPE SYNTAX KeyChange--デスマックス-ACCESSがSTATUSの現在の記述を読書して作成するので、通常(SIZE(0|32))は「ちょうどある注目に値する違いがあるusmUserPrivKeyChangeとして以下を振る舞います」。 Set操作が引き継ぐように、操作リクエスタのusmUserNameは索引をつけるusmUserNameに合わなければなりません。
Blumenthal & Wijnen Standards Track [Page 47] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[47ページ]RFC3414USM
the row which is targeted by this operation.
In addition, the USM security model must be
used for this operation.
この操作で狙う行。 さらに、この操作に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.
このコラムへのアクセスが公共である場合があるという考えがここにあります、ユーザがそれで、彼自身の秘密のプライバシーキー(privKey)を変えることができるだけであるので。 行がいったんアクティブになる後これができるだけであることに注意してください。
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がこの操作で狙う行に索引をつけるumsUserNameと同じでないと、'noAccess'誤りを返さなければなりません。
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 }
そして、セットが受け取られていて、使用中の機密保護モデルがUSMでないときに、'noAccess'誤りを返さなければなりません。 「DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry10
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 }
usmUserPublic OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0 .32))マックス-ACCESSは「ユーザの秘密の認証を変えるための手順の一部として書くことができる公的に読み込み可能な値、そして/または、プライバシーは、秘密の変化が作用したかどうか決定するために合わせて、後で読む」STATUSの現在の記述を読書して作成します。 「DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry11
usmUserStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
usmUserStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「これに、概念的なストレージタイプはこぐ」STATUSの現在の記述を読書して作成します。
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.
- そして、認証を使うユーザのためのusmUserAuthKeyChange、usmUserOwnAuthKeyChange、およびusmUserPublic、--プライバシーを使うユーザのためのusmUserPrivKeyChange、usmUserOwnPrivKeyChange、およびusmUserPublic。
Blumenthal & Wijnen Standards Track [Page 48] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[48ページ]RFC3414USM
Note that any user who employs authentication or
privacy must allow its secret(s) to be updated and
thus cannot be 'readOnly'.
認証かプライバシーを使うどんなユーザも秘密をアップデートするのを許容しなければならなくて、その結果、'readOnly'であることができないことに注意してください。
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.
始発操作が認証かプライバシーを使うユーザのために'readOnly'に値を設定しようとするなら、'inconsistentValue'誤りを返さなければなりません。 値が以前にどんな値にも設定されたなら(暗黙の、または、明白な)StorageType Textual Conventionで定義される規則が適用されることに注意してください。
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 }
readOnlyか永久的な行のためのSETを少しでも受け入れるなら、それは決める導入問題です。 いくつかの文脈では、これはそれがそうしない他のもので理解できるかもしれません。 readOnlyか永久的な行のためのSETが全く受け入れられないなら、'wrongValue'誤りを返さなければなりません。 「DEFVAL、不揮発性:、:、」= usmUserEntry12
usmUserStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
usmUserStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「これほど概念的の状態はこぐ」STATUSの現在の記述を読書して作成します。
Until instances of all corresponding columns are
appropriately configured, the value of the
corresponding instance of the usmUserStatus column
is 'notReady'.
すべての対応するコラムのインスタンスが適切に構成されるまで、usmUserStatusコラムの対応するインスタンスの値は'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.
さらに、aはまた、プライバシーを使うユーザのために新たに行を作成して、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
このオブジェクトの値はこの概念的な行の他のオブジェクトを変更できるかどうかに関して効き目がありません、usmUserOwnAuthKeyChangeとusmUserOwnPrivKeyChangeを除いて。 これらの2個のオブジェクトのために
Blumenthal & Wijnen Standards Track [Page 49] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[49ページ]RFC3414USM
value of usmUserStatus MUST be active.
"
::= { usmUserEntry 13 }
usmUserStatusの値はアクティブであるに違いありません。 " ::= usmUserEntry13
-- Conformance Information *******************************************
-- 順応情報*******************************************
usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
usmMIBCompliancesオブジェクト識別子:、:= usmMIBConformance1usmMIBGroupsオブジェクト識別子:、:= usmMIBConformance2
-- 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 STATUSの現在の記述、「SNMP-USERベースのSM-MIBを実装するSNMPエンジンのための承諾声明。」 "
MODULE -- this module
MANDATORY-GROUPS { usmMIBBasicGroup }
MODULE--このモジュールMANDATORY-GROUPSusmMIBBasicGroup
OBJECT usmUserAuthProtocol
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT usmUserAuthProtocol MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT usmUserPrivProtocol
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT usmUserPrivProtocol MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
::= { usmMIBCompliances 1 }
::= usmMIBCompliances1
-- Units of compliance
usmMIBBasicGroup OBJECT-GROUP
OBJECTS {
usmStatsUnsupportedSecLevels,
usmStatsNotInTimeWindows,
usmStatsUnknownUserNames,
usmStatsUnknownEngineIDs,
usmStatsWrongDigests,
usmStatsDecryptionErrors,
usmUserSpinLock,
usmUserSecurityName,
usmUserCloneFrom,
usmUserAuthProtocol,
usmUserAuthKeyChange,
usmUserOwnAuthKeyChange,
usmUserPrivProtocol,
usmUserPrivKeyChange,
usmUserOwnPrivKeyChange,
-- ユニットの承諾usmMIBBasicGroup OBJECT-GROUP OBJECTS、usmStatsUnsupportedSecLevels、usmStatsNotInTimeWindows、usmStatsUnknownUserNames、usmStatsUnknownEngineIDs、usmStatsWrongDigests、usmStatsDecryptionErrors、usmUserSpinLock、usmUserSecurityName、usmUserCloneFrom、usmUserAuthProtocol、usmUserAuthKeyChange、usmUserOwnAuthKeyChange、usmUserPrivProtocol、usmUserPrivKeyChange、usmUserOwnPrivKeyChange
Blumenthal & Wijnen Standards Track [Page 50] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[50ページ]RFC3414USM
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 }
usmUserPublic、usmUserStorageType、usmUserStatus STATUSの現在の記述、「SNMP UserベースのSecurity Modelを実装するSNMPエンジンの構成に備えるオブジェクトの収集。」 " ::= usmMIBGroups1
END
終わり
6. HMAC-MD5-96 Authentication Protocol
6. HMAC-MD5-96認証プロトコル
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 [RFC1321], in HMAC mode described in [RFC2104], truncating the output to 96 bits.
このセクションはHMAC-MD5-96認証プロトコルについて説明します。 この認証プロトコルはUserベースのSecurity Modelのために定義された1番目です。 それは[RFC1321]で説明されるMD5ハッシュ関数を使用します、[RFC2104]で説明されたHMACモードで、96ビットに出力に先端を切らせて。
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.
時間がたつにつれて、他の認証プロトコルはこのプロトコルの交換かこのプロトコルに加えて定義されるかもしれません。
6.1. Mechanisms
6.1. メカニズム
- 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メッセージにprependedされます。 計算されたダイジェストはトランスミッションの前にSNMPメッセージに部分的に挿入されます、そして、prepended値は送られません。 秘密の値は適切なユーザを代表してメッセージを溯源するのが認可されたすべてのSNMPエンジンによって共有されます。
6.1.1. Digest Authentication Mechanism
6.1.1. ダイジェスト認証機構
The Digest Authentication Mechanism defined in this memo provides for:
このメモで定義されたDigest Authentication Mechanismは以下に提供します。
- verification of the integrity of a received message, i.e., the
message received is the message sent.
- aの保全の検証はメッセージを受け取って、すなわち、受け取られたメッセージは送られたメッセージです。
Blumenthal & Wijnen Standards Track [Page 51] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[51ページ]RFC3414USM
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 [RFC1321] 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[RFC1321]メッセージダイジェストアルゴリズムを使用します。 128ビットのMD5ダイジェストはSNMPメッセージの指定された部分に関して特別な(HMAC)方法で計算されます、そして、メッセージの一部が受取人に発信したので、このダイジェストの最初の96ビットは含まれています。 メッセージで運ばれたダイジェストのサイズは12の八重奏です。 個人的な認証キー(秘密)のサイズは16の八重奏です。 詳細に関しては、セクション6.3を見てください。
6.2. Elements of the Digest Authentication Protocol
6.2. ダイジェスト認証プロトコルのElements
This section contains definitions required to realize the authentication module defined in this section of this memo.
このセクションはこのメモのこのセクションで定義された認証モジュールがわかるのに必要である定義を含みます。
6.2.1. Users
6.2.1. ユーザ
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.
この認証プロトコルを使用する認証がuserNamesの定義されたセットを利用します。 特定の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.
ユーザの名前を表す<userName>五弦。 <authKey>Aユーザのダイジェストについて計算するとき、使用されているために主要な秘密。 長い間、それはMD5のための16の八重奏でなければなりません。
Blumenthal & Wijnen Standards Track [Page 52] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[52ページ]RFC3414USM
6.2.2. msgAuthoritativeEngineID
6.2.2. msgAuthoritativeEngineID
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 [RFC3411]).
認証されたメッセージに含まれたmsgAuthoritativeEngineID値はその特定のメッセージに正式のSNMPエンジンを指定します(SNMP Architectureドキュメント[RFC3411]のSnmpEngineIDの定義を見てください)。
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は認証過程のために適切なキーを選択するのに使用されます。
6.2.3. SNMP Messages Using this Authentication Protocol
6.2.3. SNMP Messages UsingはこのAuthenticationプロトコルです。
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の八重奏を表す連載されたOCTET STRINGです。
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の上で見込まれるので、メッセージが認証されるなら、また、それは、メッセージのすべての分野が完全であり、いじられるというわけではなかったことを意味します。
6.2.4. Services provided by the HMAC-MD5-96 Authentication Module
6.2.4. HMAC-MD5-96認証モジュールで提供されたサービス
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.
UserベースのSecurityモジュールがサービスのためのHMAC-MD5-96 Authenticationモジュールを呼ぶとき、このセクションはHMAC-MD5-96 Authenticationモジュールが予想して、作り出す入力と出力について説明します。
6.2.4.1. Services for Generating an Outgoing SNMP Message
6.2.4.1. 送信するSNMPメッセージを生成するためのサービス
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:
完成のときに、ダイジェストが適所で挿入されている状態で、認証モジュールはstatusInformationとメッセージダイジェストが正しく計算されたときのwholeMsgを返します。 抽象的なサービス基関数は以下の通りです。
statusInformation = -- success or failure
authenticateOutgoingMsg(
IN authKey -- secret key for authentication
IN wholeMsg -- unauthenticated complete message
OUT authenticatedWholeMsg -- complete authenticated message
)
statusInformation=--成否authenticateOutgoingMsg(IN authKey(認証IN wholeMsgのための秘密鍵)は完全なメッセージOUT authenticatedWholeMsgを非認証しました--完全な認証されたメッセージ)
Blumenthal & Wijnen Standards Track [Page 53] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[53ページ]RFC3414USM
The abstract data elements are:
抽象的なデータ要素は以下の通りです。
statusInformation
An indication of whether the authentication process was successful.
If not it is an indication of the problem.
認証過程がうまくいったかどうかstatusInformation Anしるし。 まして、それは問題のしるしです。
authKey
The secret key to be used by the authentication algorithm. The
length of this key MUST be 16 octets.
authKey、認証アルゴリズムによる使用されているために主要な秘密。 このキーの長さは16の八重奏であるに違いありません。
wholeMsg
The message to be authenticated.
wholeMsg、認証されるべきメッセージ。
authenticatedWholeMsg
The authenticated message (including inserted digest) on output.
認証が出力のときに通信させる(包含はダイジェストを挿入しました)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に既に存在しているべきです。
6.2.4.2. Services for Processing an Incoming SNMP Message
6.2.4.2. 入って来るSNMPメッセージを処理するためのサービス
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:
完成のときに、それが処理されたとき、認証モジュールはstatusInformationとメッセージダイジェストが正しく計算されたときのwholeMsgを返します。 抽象的なサービス基関数は以下の通りです。
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(IN authKey--ワイヤIN wholeMsgに受け取るようなワイヤOUT authenticatedWholeMsgに受け取られる認証IN authParametersのための秘密鍵--完全な認証されたメッセージ)
The abstract data elements are:
抽象的なデータ要素は以下の通りです。
statusInformation
An indication of whether the authentication process was successful.
If not it is an indication of the problem.
認証過程がうまくいったかどうかstatusInformation Anしるし。 まして、それは問題のしるしです。
authKey
The secret key to be used by the authentication algorithm. The
length of this key MUST be 16 octets.
authKey、認証アルゴリズムによる使用されているために主要な秘密。 このキーの長さは16の八重奏であるに違いありません。
Blumenthal & Wijnen Standards Track [Page 54] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[54ページ]RFC3414USM
authParameters
The authParameters from the incoming message.
入力メッセージからのauthParameters authParameters。
wholeMsg
The message to be authenticated on input and the authenticated
message on output.
入力のときに認証されるべきメッセージと認証が出力のときに通信させるwholeMsg。
authenticatedWholeMsg
The whole message after the authentication check is complete.
認証の後の全体のメッセージがチェックするauthenticatedWholeMsgは完全です。
6.3. Elements of Procedure
6.3. 手順のElements
This section describes the procedures for the HMAC-MD5-96 authentication protocol.
このセクションはHMAC-MD5-96認証プロトコルのために手順について説明します。
6.3.1. Processing an Outgoing Message
6.3.1. 送信されるメッセージを処理します。
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 [RFC3417], of an OCTET STRING containing
12 zero octets.
1) msgAuthenticationParameters分野は連載に設定されます、[RFC3417]の規則に従ってOCTET STRING含有では、12は八重奏のゼロに合っています。
2) From the secret authKey, two keys K1 and K2 are derived:
2) 秘密のauthKey、2から、キーK1とケーツーは引き出されます:
a) extend the authKey to 64 octets by appending 48 zero octets;
save it as extendedAuthKey
a)は、追加することによって、authKeyを64の八重奏まで広げています。48 八重奏のゼロを合わせてください。 extendedAuthKeyとしてそれを保存してください。
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 八重奏0x36 64回模写することによって、IPADを入手してください。
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) XORing extendedAuthKeyはIPADと共にK1を入手してください。
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 64回八重奏0x5Cを模写することによって、OPADを入手してください。
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) OPADと共にXORing extendedAuthKeyでケーツーを得てください。
3) Prepend K1 to the wholeMsg and calculate MD5 digest over it
according to [RFC1321].
3) そして、wholeMsgへのPrepend K1、[RFC1321]に従ってMD5がそれの上で読みこなすと見込んでください。
4) Prepend K2 to the result of the step 4 and calculate MD5 digest
over it according to [RFC1321]. Take the first 12 octets of the
final digest - this is Message Authentication Code (MAC).
4) ステップ4の結果にケーツーをPrependして、[RFC1321]に従ってMD5がそれの上で読みこなすと見込みます。 最終的なダイジェストの最初の12の八重奏を取ってください--これはメッセージ立証コード(MAC)です。
5) Replace the msgAuthenticationParameters field with MAC obtained in
the step 4.
5) msgAuthenticationParameters分野をステップ4で入手されたMACに取り替えてください。
Blumenthal & Wijnen Standards Track [Page 55] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[55ページ]RFC3414USM
6) The authenticatedWholeMsg is then returned to the caller together
with statusInformation indicating success.
6) そして、成功を示すstatusInformationと共にauthenticatedWholeMsgを訪問者に返します。
6.3.2. Processing an Incoming Message
6.3.2. 入力メッセージを処理します。
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分野に受け取られたダイジェストが12の八重奏でないなら、失敗とerrorIndication(authenticationError)を呼ぶモジュールに返します。
2) The MAC received in the msgAuthenticationParameters field is
saved.
2) msgAuthenticationParameters分野に受け取られたMACは取っておかれます。
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、2から、キーK1とケーツーは引き出されます:
a) extend the authKey to 64 octets by appending 48 zero octets;
save it as extendedAuthKey
a)は、追加することによって、authKeyを64の八重奏まで広げています。48 八重奏のゼロを合わせてください。 extendedAuthKeyとしてそれを保存してください。
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 八重奏0x36 64回模写することによって、IPADを入手してください。
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) XORing extendedAuthKeyはIPADと共にK1を入手してください。
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 64回八重奏0x5Cを模写することによって、OPADを入手してください。
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) OPADと共にXORing extendedAuthKeyでケーツーを得てください。
5) The MAC is calculated over the wholeMsg:
5) MACはwholeMsgの上で計算されます:
a) prepend K1 to the wholeMsg and calculate the MD5 digest over
it;
そして、wholeMsgへのa)prepend K1、それの上でMD5ダイジェストについて計算してください。
b) prepend K2 to the result of step 5.a and calculate the MD5
digest over it;
b)は、ステップ5.aの結果にケーツーをprependして、それの上でMD5ダイジェストについて計算します。
c) first 12 octets of the result of step 5.b is the MAC.
c) まず最初に、ステップ5.bの結果の12の八重奏がMACです。
The msgAuthenticationParameters field is replaced with the MAC
value that was saved in step 2.
msgAuthenticationParameters野原をステップ2で節約されたMAC値に取り替えます。
Blumenthal & Wijnen Standards Track [Page 56] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[56ページ]RFC3414USM
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.
6) そして、新たに計算されたMACはステップ2に取っておかれるMACと比較されます。 彼らが合っていないなら、失敗とerrorIndication(authenticationFailure)を呼ぶモジュールに返します。
7) The authenticatedWholeMsg and statusInformation indicating success
are then returned to the caller.
7) そして、成功を示すauthenticatedWholeMsgとstatusInformationを訪問者に返します。
7. HMAC-SHA-96 Authentication Protocol
7. HMAC-SHA-96認証プロトコル
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認証プロトコルについて説明します。 このプロトコルは[SHA-NIST]で説明されるSHAハッシュ関数を使用します、[RFC2104]で説明されたHMACモードで、96ビットに出力に先端を切らせて。
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.
時間がたつにつれて、他の認証プロトコルはこのプロトコルの交換かこのプロトコルに加えて定義されるかもしれません。
7.1. Mechanisms
7.1. メカニズム
- 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メッセージにprependedされます。 そして、計算されたダイジェストはトランスミッションの前にメッセージに部分的に挿入されます。 prepended秘密は伝えられません。 秘密の値は適切なユーザを代表してメッセージを溯源するのが認可されたすべてのSNMPエンジンによって共有されます。
7.1.1. Digest Authentication Mechanism
7.1.1. ダイジェスト認証機構
The Digest Authentication Mechanism defined in this memo provides for:
このメモで定義されたDigest Authentication Mechanismは以下に提供します。
- verification of the integrity of a received message, i.e., the
message received is the message sent.
- aの保全の検証はメッセージを受け取って、すなわち、受け取られたメッセージは送られたメッセージです。
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.
メッセージの保全は、メッセージの適切な部分に関してダイジェストを計算することによって、保護されます。 ダイジェストは、メッセージで送られたメッセージの創始者によって計算されて、メッセージの受取人によって確かめられます。
Blumenthal & Wijnen Standards Track [Page 57] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[57ページ]RFC3414USM
- 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メッセージの指定された部分に関して特別な(HMAC)方法で計算されます、そして、メッセージの一部が受取人に発信したので、このダイジェストの最初の96ビットは含まれています。 メッセージで運ばれたダイジェストのサイズは12の八重奏です。 個人的な認証キー(秘密)のサイズは20の八重奏です。 詳細に関しては、セクション7.3を見てください。
7.2. Elements of the HMAC-SHA-96 Authentication Protocol
7.2. HMAC-SHA-96認証プロトコルのElements
This section contains definitions required to realize the authentication module defined in this section of this memo.
このセクションはこのメモのこのセクションで定義された認証モジュールがわかるのに必要である定義を含みます。
7.2.1. Users
7.2.1. ユーザ
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.
この認証プロトコルを使用する認証がuserNamesの定義されたセットを利用します。 特定の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.
ユーザの名前を表す<userName>五弦。 <authKey>Aユーザのダイジェストについて計算するとき、使用されているために主要な秘密。 長い間、それはSHAのための20の八重奏でなければなりません。
7.2.2. msgAuthoritativeEngineID
7.2.2. msgAuthoritativeEngineID
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 [RFC3411]).
認証されたメッセージに含まれたmsgAuthoritativeEngineID値はその特定のメッセージに正式のSNMPエンジンを指定します(SNMP Architectureドキュメント[RFC3411]のSnmpEngineIDの定義を見てください)。
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は認証過程のために適切なキーを選択するのに使用されます。
Blumenthal & Wijnen Standards Track [Page 58] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[58ページ]RFC3414USM
7.2.3. SNMP Messages Using this Authentication Protocol
7.2.3. SNMP Messages UsingはこのAuthenticationプロトコルです。
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の八重奏を表す連載されたOCTET STRINGです。
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の上で見込まれるので、メッセージが認証されるなら、また、それは、メッセージのすべての分野が完全であり、いじられるというわけではなかったことを意味します。
7.2.4. Services Provided by the HMAC-SHA-96 Authentication Module
7.2.4. HMAC-SHA-96認証モジュールで提供されたサービス
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.
UserベースのSecurityモジュールがサービスのためのHMAC-SHA-96 Authenticationモジュールを呼ぶとき、このセクションはHMAC-SHA-96 Authenticationモジュールが予想して、作り出す入力と出力について説明します。
7.2.4.1. Services for Generating an Outgoing SNMP Message
7.2.4.1. 送信するSNMPメッセージを生成するためのサービス
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:
完成のときに、ダイジェストが適所で挿入されている状態で、認証モジュールはstatusInformationとメッセージダイジェストが正しく計算されたときのwholeMsgを返します。 抽象的なサービス基関数は以下の通りです。
statusInformation = -- success or failure
authenticateOutgoingMsg(
IN authKey -- secret key for authentication
IN wholeMsg -- unauthenticated complete message
OUT authenticatedWholeMsg -- complete authenticated message
)
statusInformation=--成否authenticateOutgoingMsg(IN authKey(認証IN 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.
認証過程がうまくいったかどうかstatusInformation Anしるし。 まして、それは問題のしるしです。
authKey
The secret key to be used by the authentication algorithm. The
length of this key MUST be 20 octets.
authKey、認証アルゴリズムによる使用されているために主要な秘密。 このキーの長さは20の八重奏であるに違いありません。
Blumenthal & Wijnen Standards Track [Page 59] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[59ページ]RFC3414USM
wholeMsg
The message to be authenticated.
wholeMsg、認証されるべきメッセージ。
authenticatedWholeMsg
The authenticated message (including inserted digest) on output.
認証が出力のときに通信させる(包含はダイジェストを挿入しました)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に既に存在しているべきです。
7.2.4.2. Services for Processing an Incoming SNMP Message
7.2.4.2. 入って来るSNMPメッセージを処理するためのサービス
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:
完成のときに、それが処理されたとき、認証モジュールはstatusInformationとメッセージダイジェストが正しく計算されたときのwholeMsgを返します。 抽象的なサービス基関数は以下の通りです。
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(IN authKey--ワイヤIN wholeMsgに受け取るようなワイヤOUT authenticatedWholeMsgに受け取られる認証IN authParametersのための秘密鍵--完全な認証されたメッセージ)
The abstract data elements are:
抽象的なデータ要素は以下の通りです。
statusInformation
An indication of whether the authentication process was successful.
If not it is an indication of the problem.
認証過程がうまくいったかどうかstatusInformation Anしるし。 まして、それは問題のしるしです。
authKey
The secret key to be used by the authentication algorithm. The
length of this key MUST be 20 octets.
authKey、認証アルゴリズムによる使用されているために主要な秘密。 このキーの長さは20の八重奏であるに違いありません。
authParameters
The authParameters from the incoming message.
入力メッセージからのauthParameters authParameters。
wholeMsg
The message to be authenticated on input and the authenticated
message on output.
入力のときに認証されるべきメッセージと認証が出力のときに通信させるwholeMsg。
authenticatedWholeMsg
The whole message after the authentication check is complete.
認証の後の全体のメッセージがチェックするauthenticatedWholeMsgは完全です。
Blumenthal & Wijnen Standards Track [Page 60] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[60ページ]RFC3414USM
7.3. Elements of Procedure
7.3. 手順のElements
This section describes the procedures for the HMAC-SHA-96 authentication protocol.
このセクションはHMAC-SHA-96認証プロトコルのために手順について説明します。
7.3.1. Processing an Outgoing Message
7.3.1. 送信されるメッセージを処理します。
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 [RFC3417], of an OCTET STRING containing
12 zero octets.
1) msgAuthenticationParameters分野は連載に設定されます、[RFC3417]の規則に従ってOCTET STRING含有では、12は八重奏のゼロに合っています。
2) From the secret authKey, two keys K1 and K2 are derived:
2) 秘密のauthKey、2から、キーK1とケーツーは引き出されます:
a) extend the authKey to 64 octets by appending 44 zero octets;
save it as extendedAuthKey
a)は、追加することによって、authKeyを64の八重奏まで広げています。44 八重奏のゼロを合わせてください。 extendedAuthKeyとしてそれを保存してください。
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 八重奏0x36 64回模写することによって、IPADを入手してください。
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) XORing extendedAuthKeyはIPADと共にK1を入手してください。
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 64回八重奏0x5Cを模写することによって、OPADを入手してください。
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) OPADと共にXORing extendedAuthKeyでケーツーを得てください。
3) Prepend K1 to the wholeMsg and calculate the SHA digest over it
according to [SHA-NIST].
3) そして、wholeMsgへのPrepend K1、[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の結果にケーツーをPrependして、[SHA-NIST]に従ってSHAがそれの上で読みこなすと見込みます。 最終的なダイジェストの最初の12の八重奏を取ってください--これはメッセージ立証コード(MAC)です。
5) Replace the msgAuthenticationParameters field with MAC obtained in
the step 5.
5) msgAuthenticationParameters分野をステップ5で入手されたMACに取り替えてください。
6) The authenticatedWholeMsg is then returned to the caller together
with statusInformation indicating success.
6) そして、成功を示すstatusInformationと共にauthenticatedWholeMsgを訪問者に返します。
7.3.2. Processing an Incoming Message
7.3.2. 入力メッセージを処理します。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using the usmHMACSHAAuthProtocol.
このセクションは手順について説明します、続いて、usmHMACSHAAuthProtocolを使用することで入力メッセージを認証しなければならないときはいつも、SNMPエンジンについて説明します。
Blumenthal & Wijnen Standards Track [Page 61] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[61ページ]RFC3414USM
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分野に受け取られたダイジェストが12の八重奏でないなら、失敗とerrorIndication(authenticationError)を呼ぶモジュールに返します。
2) The MAC received in the msgAuthenticationParameters field is
saved.
2) msgAuthenticationParameters分野に受け取られたMACは取っておかれます。
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、2から、キーK1とケーツーは引き出されます:
a) extend the authKey to 64 octets by appending 44 zero octets;
save it as extendedAuthKey
a)は、追加することによって、authKeyを64の八重奏まで広げています。44 八重奏のゼロを合わせてください。 extendedAuthKeyとしてそれを保存してください。
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 八重奏0x36 64回模写することによって、IPADを入手してください。
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) XORing extendedAuthKeyはIPADと共にK1を入手してください。
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 64回八重奏0x5Cを模写することによって、OPADを入手してください。
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) OPADと共にXORing extendedAuthKeyでケーツーを得てください。
5) The MAC is calculated over the wholeMsg:
5) MACはwholeMsgの上で計算されます:
a) prepend K1 to the wholeMsg and calculate the SHA digest over
it;
そして、wholeMsgへのa)prepend K1、それの上でSHAダイジェストについて計算してください。
b) prepend K2 to the result of step 5.a and calculate the SHA
digest over it;
b)は、ステップ5.aの結果にケーツーをprependして、それの上でSHAダイジェストについて計算します。
c) first 12 octets of the result of step 5.b is the MAC.
c) まず最初に、ステップ5.bの結果の12の八重奏が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.
6) 新たに計算されたMACはステップ2に取っておかれるMACと比較されます。 彼らが合っていないなら、失敗とerrorIndication(authenticationFailure)を呼ぶモジュールに返します。
7) The authenticatedWholeMsg and statusInformation indicating success
are then returned to the caller.
7) そして、成功を示すauthenticatedWholeMsgとstatusInformationを訪問者に返します。
Blumenthal & Wijnen Standards Track [Page 62] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[62ページ]RFC3414USM
8. CBC-DES Symmetric Encryption Protocol
8. CBC-DESの左右対称の暗号化プロトコル
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 Symmetric Encryptionプロトコルについて説明します。 このプロトコルはUserベースのSecurity Modelのために定義された最初のプライバシープロトコルです。
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.
時間がたつにつれて、他のプライバシープロトコルはこのプロトコルの交換かこのプロトコルに加えて定義されるかもしれません。
8.1. Mechanisms
8.1. メカニズム
- 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.
- データの機密性を支持して、暗号化アルゴリズムが必要です。 メッセージの適切な部分は伝えられる前に、暗号化されます。 UserベースのSecurity Modelは、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.
- タイムリー値と組み合わせた秘密の値は、アン/復号化キーと初期化ベクトルを作成するのに使用されます。 秘密の値は適切なユーザを代表してメッセージを溯源するのが認可されたすべてのSNMPエンジンによって共有されます。
8.1.1. Symmetric Encryption Protocol
8.1.1. 左右対称の暗号化プロトコル
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.
このメモで定義されたSymmetric Encryptionプロトコルはデータの機密性のサポートを提供します。 メッセージの一部が受取人に発信したので、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).
2つの組織がDESを定義する仕様を発表しました: 米国商務省標準技術局(NIST)[デス-NIST]とAmerican National Standards Institut[デス-ANSI]。 各定義(それぞれ[DESO-NIST]と[DESO-ANSI])のためのOperation仕様の仲間Modesがあります。
The NIST has published three additional documents that implementors may find useful.
NISTは作成者が役に立つのがわかるかもしれない3通の追加ドキュメントを発表しました。
- There is a document with guidelines for implementing and using the
DES, including functional specifications for the DES and its modes
of operation [DESG-NIST].
- DESを実装して、使用するためのガイドラインがあるドキュメントがあります、DESのための機能的な仕様とその運転モード[DESG-NIST]を含んでいて。
- 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.
- デス[DEST-NIST]のための合法化テストスイートの仕様があります。 スイートは、DESの全面をテストするように設計されていて、特定の問題を正確に指摘することの役に立ちます。
Blumenthal & Wijnen Standards Track [Page 63] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[63ページ]RFC3414USM
- 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.
- デス[DESM- NIST]のためのメインテナンステストの仕様があります。 テストは、DESのすべての部品をテストするのに最小量のデータ量と処理を利用します。 初期化ステップの一部として稼働するのは、正しい操作の簡単な諾否しるしを供給して、役に立ちます、例えば、コンピュータがリブートされるとき。
8.1.1.1. DES key and Initialization Vector
8.1.1.1. DESキーと初期設定Vector
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ビットだけを使用するので、各八重奏におけるLeast Significant Bitは無視されます。
The Initialization Vector for encryption is obtained using the following procedure.
以下の手順を用いることで暗号化のための初期設定Vectorを入手します。
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.
2つの異なったパケットのためのIVが同じくらいでキーを暗号化したのを確実にするために、私たちが何かでプレIVに「塩味を付けさせる」ために必要とする同じくらい(すなわち、IVは繰り返されない)はパケット単位でユニークではありませんか? 8八重奏のストリングは「塩」として使用されます。 生成しているSNMPエンジンの32ビットのsnmpEngineBootsとa地方の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つの八重奏(ほとんどのSignificant Byte1番目)に変換されます。 そして、32ビットの整数は私たちの「塩」のベスト4八重奏(ほとんどのSignificant Byte1番目)に変換されます。 そして、結果として起こる「塩」は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)は、異なって、導入問題です、対策がa写し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分野に置かなければなりません。
Blumenthal & Wijnen Standards Track [Page 64] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[64ページ]RFC3414USM
8.1.1.2. Data Encryption
8.1.1.2. データ暗号化
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.
データはCipher Block Chainingモードで暗号化されます。
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-教育です、そして、結果は暗号化されています、そして、暗号化の出力はブロックで暗号文です。 それ以上の平文ブロックが全くないまで、この手順は繰り返されます。
For the very first block, the Initialization Vector is used instead of the ciphertext of the previous block.
まさしくその最初のブロックのために、初期設定Vectorは前のブロックの暗号文の代わりに使用されます。
8.1.1.3. Data Decryption
8.1.1.3. データ復号
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.
復号化の前に、暗号化されたデータの長さは確かめられます。 解読されるOCTET STRINGの長さは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.
最初の暗号文ブロックは解読されます、そして、復号化出力は初期設定VectorとのXOR-教育です、そして、結果は最初の平文ブロックです。
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-教育であり、結果は平文ブロックです。
8.2. Elements of the DES Privacy Protocol
8.2. DESプライバシープロトコルのElements
This section contains definitions required to realize the privacy module defined by this memo.
このセクションはこのメモで定義されたプライバシーモジュールがわかるのに必要である定義を含みます。
8.2.1. Users
8.2.1. ユーザ
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
このSymmetric Encryptionプロトコルを使用するデータアン/復号化がuserNamesの定義されたセットを利用します。 メッセージがに代わっているに違いないどんなユーザに関してはも、そのSNMPエンジンには、特定のSNMPエンジンでアン/解読されて、そのユーザに関する知識がなければなりません。 願われているSNMPエンジン
Blumenthal & Wijnen Standards Track [Page 65] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[65ページ]RFC3414USM
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エンジンとコミュニケートするのに、そのSNMPエンジンにユーザに関する知識を知らなければなりません、そのユーザの適切な属性に関する知識を含んでいて。
A user and its attributes are defined as follows:
ユーザとその属性は以下の通り定義されます:
<userName>
An octet string representing the name of the user.
ユーザの名前を表す<userName>An八重奏ストリング。
<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>AユーザのDESキーとIVのために入力されるように使用されているために主要な秘密。 このキーの長さは16の八重奏であるに違いありません。
8.2.2. msgAuthoritativeEngineID
8.2.2. msgAuthoritativeEngineID
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 [RFC3411]).
認証されたメッセージに含まれたmsgAuthoritativeEngineID値はその特定のメッセージに正式のSNMPエンジンを指定します(SNMP Architectureドキュメント[RFC3411]のSnmpEngineIDの定義を見てください)。
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はアン/復号化プロセスのために適切なキーを選択するのに使用されます。
8.2.3. SNMP Messages Using this Privacy Protocol
8.2.3. SNMP Messages UsingはこのPrivacyプロトコルです。
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です。
8.2.4. Services Provided by the DES Privacy Module
8.2.4. DESプライバシーモジュールで提供されたサービス
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.
UserベースのSecurityモジュールがサービスのためのDES Privacyモジュールを呼び出すとき、このセクションはDES Privacyモジュールが予想して、作り出す入力と出力について説明します。
8.2.4.1. Services for Encrypting Outgoing Data
8.2.4.1. 発信データを暗号化するためのサービス
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:
完成のときに、プライバシーモジュールは暗号化プロセスがうまくいったときのOCTET STRINGとしてコード化されたstatusInformation、encryptedPDU、およびmsgPrivacyParametersを返します。 抽象的なサービス基関数は以下の通りです。
Blumenthal & Wijnen Standards Track [Page 66] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[66ページ]RFC3414USM
statusInformation = -- success of failure
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の成功(IN encryptKey--暗号化IN dataToEncryptのための秘密鍵--サービスプロバイダーによって記入された(scopedPDU)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.
暗号化プロセスの成否のstatusInformation Anしるし。 失敗の場合には、それは誤りのしるしです。
encryptKey
The secret key to be used by the encryption algorithm. The length
of this key MUST be 16 octets.
encryptKey、暗号化アルゴリズムによる使用されているために主要な秘密。 このキーの長さは16の八重奏であるに違いありません。
dataToEncrypt
The data that must be encrypted.
dataToEncrypt、暗号化しなければならないデータ。
encryptedData
The encrypted data upon successful completion.
encryptedData、無事終了に関する暗号化されたデータ。
privParameters
The privParameters encoded as an OCTET STRING.
privParametersがOCTET STRINGとしてコード化したprivParameters。
8.2.4.2. Services for Decrypting Incoming Data
8.2.4.2. 受信データを解読するためのサービス
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:
完成のときに、プライバシーモジュールはプレーンテキストでstatusInformationと復号化プロセスがうまくいったときのscopedPDUを返します。 抽象的なサービス基関数は以下の通りです。
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と等しいです。(データ(scopedPDU)であると解読されたワイヤIN encryptedData(暗号化されたデータ(encryptedPDU)OUT decryptedData)に受け取られるIN decryptKey(復号化IN privParametersのための秘密鍵))
Blumenthal & Wijnen Standards Track [Page 67] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[67ページ]RFC3414USM
The abstract data elements are:
抽象的なデータ要素は以下の通りです。
statusInformation
An indication whether the data was successfully decrypted and if
not an indication of the error.
statusInformation An指示、データは首尾よく解読されたかどうか、そして、まして、誤りのしるし。
decryptKey
The secret key to be used by the decryption algorithm. The length
of this key MUST be 16 octets.
decryptKey、復号化アルゴリズムによる使用されているために主要な秘密。 このキーの長さは16の八重奏であるに違いありません。
privParameters
The "salt" to be used to calculate the IV.
IVについて計算するのに使用されるべき「塩からさ」privParameters。
encryptedData
The data to be decrypted.
encryptedData、解読されるデータ。
decryptedData
The decrypted data.
decryptedData、解読されたデータ。
8.3. Elements of Procedure.
8.3. 手順のElements。
This section describes the procedures for the DES privacy protocol.
このセクションはDESプライバシープロトコルのために手順について説明します。
8.3.1. Processing an Outgoing Message
8.3.1. 送信されるメッセージを処理します。
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暗号化キー、「塩」、およびDESプレIV(IVがどれであるかから、セクション8.1.1で.1について説明するとき、計算される)を組み立てるのに使用されます。
2) The privParameters field is set to the serialization according to
the rules in [RFC3417] of an OCTET STRING representing the "salt"
string.
2) privParameters分野は「塩」ストリングを表すOCTET STRINGの[RFC3417]の規則に従った連載へのセットです。
3) The scopedPDU is encrypted (as described in section 8.1.1.2)
and the encrypted data is serialized according to the rules in
[RFC3417] as an OCTET STRING.
3) scopedPDUは暗号化されています、そして、(セクション8.1.1で.2について説明するので)[RFC3417]の規則に従って、暗号化されたデータはOCTET STRINGとして連載されます。
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を呼ぶモジュールに返します。
Blumenthal & Wijnen Standards Track [Page 68] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[68ページ]RFC3414USM
8.3.2. Processing an Incoming Message
8.3.2. 入力メッセージを処理します。
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八重奏のOCTET 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と「塩」は、DES復号化キーとプレIVを組み立てるのに使用されます(IVがどれであるかから、セクション8.1.1で.1について説明するとき、計算されます)。
4) The encryptedPDU is then decrypted (as described in section
8.1.1.3).
4) そして、encryptedPDUは解読されます(セクション8.1.1で.3について説明するので)。
5) If the encryptedPDU cannot be decrypted, then an error indication
(decryptionError) is returned to the calling module.
5) encryptedPDUを解読することができないなら、誤り表示(decryptionError)を呼ぶモジュールに返します。
6) The decrypted scopedPDU and statusInformation indicating success
are returned to the calling module.
6) 成功を示す解読されたscopedPDUとstatusInformationを呼ぶモジュールに返します。
9. Intellectual Property
9. 知的所有権
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Blumenthal & Wijnen Standards Track [Page 69] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[69ページ]RFC3414USM
10. Acknowledgements
10. 承認
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)
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)
ハラルドTveit Alvestrand(Maxware)デーヴBattle(SNMP研究Inc.) アランBeard(ディズニーの世界的なServices)ポールBerrevoets(SWI Systemware/アルキュオーン株式会社) マーチンBjorklund(エリクソン)ユリ・ブルーメンソル(IBM T.J.ワトソン研究所) ジェフCase(SNMP研究Inc.) ジョン・カラン(BBN)・マイク・ダニエル(コンパックコンピュータ社) T。 マックス・デブリン(Eltraxシステム) ジョンFlick(ヒューレットパッカード) ロブ・フライ(MCI) ウェスHardaker、(U.C.デイヴィス、情報技術--直流、A.S.) デヴィッド・ハリントン(CabletronシステムInc.) ローレン・ハインツ(BMCソフトウェアInc.) ノースカロライナ州Hien(IBM T.J.ワトソン研究所) マイケル・カーカム(研究室Inc.を織り込みます) デーヴ・レビ(SNMP研究Inc.) ルイスはMamakos(UUNET技術Inc.)です。 ジョーMarzot(ノーテルネットワーク) ポール・マイヤー(安全なコンピューティング社) キースMcCloghrie(シスコシステムズ) ボブ・ムーア(IBM) ラス・マンディ(ネットワーク関連のTIS研究室) ボブNatale(ACE*COMM社) マイク・オデル(UUNET技術Inc.) デーヴ・パーキンス(DeskTalk) ピーター・ポーキングホーン(Brunel大学) ランディPresuhn(BMCソフトウェアInc.) デヴィッド・リーダー(ネットワーク関連のTIS研究室) デヴィッド・リード(SNMP研究Inc.) アレックセイ・ロマーノフ(上質の定足数) ショーンRouthier(エピローグ) ユルゲンSchoenwaelder(TUブラウンシュバイク) ボブ・スチュワート(シスコシステムズ) マイク・サッチャー(独立しているコンサルタント) バートWijnen(IBM T.J.ワトソン研究所)
Blumenthal & Wijnen Standards Track [Page 70] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[70ページ]RFC3414USM
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 Advisory TeamのためのIETF SecurityとAdministrative Framework Evolutionの推薦に基づいています。 そのAdvisory Teamのメンバーは以下の通りでした。
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システムInc.) ジェフ・ジョンソン(シスコシステムズ)・デヴィッド・レビ(SNMP研究Inc.) ジョン・リン(Openvision)・ラス・マンディ(情報システムを信じる)いすショーンRouthier(エピローグ)グレンWaters(ノーテル)バートWijnen(IBM T.J.ワトソン研究所)
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*:
Advisory TeamとSNMPv3作業部会憲章によって推薦されるように、デザインは前のRFCsと草稿によって実用的であるのと同じくらい多くを取り入れます。 その結果、特別な感謝はSNMPv2uとSNMPv2*として知られている前のデザインの作者のためです:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
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.)
ジェフCase(SNMP研究Inc.) デヴィッド・ハリントン(CabletronシステムInc.) デヴィッド・レビ(SNMP研究Inc.) キースMcCloghrie(シスコシステムズ)ブライアン・オキーフ(ヒューレットパッカード)・マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング)ジョンSaperia(BGSシステムInc.) スティーブWaldbusser(国際ネットワークサービス)グレンW.水域(ベル-北研究株式会社)
11. Security Considerations
11. セキュリティ問題
11.1. Recommended Practices
11.1. 推奨案
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エンジンはどんな現在傑出しているRequestメッセージとも食い違っているSNMP Responseメッセージを捨てなければなりません。 これの世話をするのは、Message Processingモジュールの責任です。 例えば、それはそれに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 [RFC3416] PDUs, the request-id
component in the PDU can be used to correlate Responses to
outstanding Requests.
SNMP Command Generator Applicationはどんな現在傑出しているConfirmed Class PDUもないどんなResponse Class PDUも捨てなければなりません。 例えば、SNMPv2[RFC3416]PDUsに関しては、傑出しているRequestsにResponsesを関連させるのにPDUの要求イドコンポーネントを使用できます。
Blumenthal & Wijnen Standards Track [Page 71] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[71ページ]RFC3414USM
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 Command Generator Applicationが当然のこととしてこれをするのが、典型的でしょうが、これらのセキュリティプロトコルを使用するとき、それはメッセージ複製の可能性のために重要です(悪意があるかそうでない)。
- 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エンジンが傑出しているRequestメッセージにResponseメッセージを関連させるのにmsgIDを使用するなら、それはタイム・ウィンドウ(150秒)の期間出すくらいのすべてのRequestメッセージで異なった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.
Command GeneratorかNotification Originator ApplicationがそれがTimeWindow(150秒)の期間、出すすべてのRequest PDUsの異なった要求イドを使用しなければなりません。
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、そして/または、要求イド値と共に活動を開始するのは、名案ではありません。 予測できない数(彼らが各リブートの後に同じように始めないで)でそれらを初期化して、次に、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エンジンにメッセージを変更させるとき、Command Generator Applicationは、前のメッセージのために積極的な承認を受けるか、または前のメッセージが期限が切れるまでその管理された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 Command Generator Applicationsはネットワークで当然のこととして例外から生じるメッセージの損失と再注文を切り抜けなければなりません。
However, a managed object, snmpSetSerialNo [RFC3418], 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.
しかしながら、SNMPメッセージの処理が特定の順序で起こるのを保証するためにメカニズムを提供して、管理オブジェクト(snmpSetSerialNo[RFC3418])は使用のためにSNMP Set操作で明確に定義されます。
Blumenthal & Wijnen Standards Track [Page 72] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[72ページ]RFC3414USM
- 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.
- 頻度はUserベースのSecurity Modelユーザの秘密が変えられるべきである間接的に彼らの使用の頻度に関連します。
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.
また、地方の環境で公開の脅威がそれほど重要でないかもしれないことに注意してください。そうすれば、そういうものとして、秘密の変化はそれほど頻繁である必要はありません。 しかしながら、公衆データネットワークが通信路として使用されるとき、より多くの警告が慎重です。
11.2 Defining Users
11.2 ユーザを定義すること。
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.
メカニズムはだれの利益メッセージを送るかに関してこのドキュメント雇用でユーザの概念を定義しました。 「ユーザ」がどう定義されるかは、ネットワーク管理の安全保障政策を受けることがあります。 例えば、ユーザが個人(例えば、"joe"か"jane")であるかもしれないか特定の役割(例えば、「オペレータ」か「管理者」)、または組み合わせが(例えば、「joe-オペレータ」、「jane-オペレータ」または「joe-アドミン」)です。 その上、ユーザは、SNMP Application、SNMP Applicationsの1セット、個人か役割を代表した芝居、または個人のセットなどの論理的な実体、または役割のセットであるかもしれません、組み合わせを含んでいて。
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文字の組でかなり簡単である場合があるということであるかもしれません。 したがって、アルゴリズムはAppendix Aがパスワードに変換を実行するということです。 Appendix Aアルゴリズムが使用されているなら、SNMP実装(そして、SNMP構成アプリケーション)は、パスワードが長さが少なくとも8つのキャラクタであることを確実にしなければなりません。 反復性のストリングがある、より長いパスワードはまさに同じキーをもたらすかもしれません。 例えば、'bertbert'というパスワードはまさに'bertbertbert'というパスワードと同じキーをもたらすでしょう。
Blumenthal & Wijnen Standards Track [Page 73] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[73ページ]RFC3414USM
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.
Appendix 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エンジンのための異なったパスワードを維持するのが、実行不可能ですが、セキュリティ要件が1台以上のSNMPエンジンに主要な状態で有を強く同じようにがっかりさせるので、UserベースのSecurity Modelは[ローカライズしているキー]で提案された感染を使います。 それは、ユーザのパスワードを決定するのが実際に不可能であるような方法によるユーザのパスワードからの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.
しかしながら、それがユーザのパスワードが明らかにされて、次に、主要なローカライズであるなら助けないで、ネットワークセキュリティがこの場合感染されるかもしれないことに注意してください。 したがって、管理されたデバイス/ノードの上にユーザのパスワードか非ローカライズしているキーを保存してはいけません。 代わりにローカライズしている主要なSHALLが保存されて(せいぜい)、したがって、場合では、デバイスに感染します、どんな他のものも管理しなかったか、またはデバイスが管理し始めるのは妥協しました。
11.3. Conformance
11.3. 順応
To be termed a "Secure SNMP implementation" based on the User-based Security Model, an SNMP implementation MUST:
UserベースのSecurity Modelに基づく「安全な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.
- 1Authenticationがプロトコルであると実装してください。 プロトコルがこのメモで定義したHMAC-MD5-96とHMAC-SHA-96 Authenticationはそのようなプロトコルに関する例です。
- 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メッセージをどれを除いて、それがあらゆる情勢のもとでLocal Configuration Datastore(LCD)の情報を保守するかに関して可能な最大の範囲に、必要に応じてそれぞれのユーザの秘密へのアクセスを禁止して、生成する、そして/または、有効にしてください。
- implement the key-localization mechanism.
- 主要な局在機構を実装してください。
- implement the SNMP-USER-BASED-SM-MIB.
- SNMP-USERベースのSM-MIBを実装してください。
In addition, an authoritative SNMP engine SHOULD provide initial configuration in accordance with Appendix A.1.
追加、SHOULDが提供する正式のSNMPエンジンでは、Appendix A.1に従って、構成に頭文字をつけてください。
Implementation of a Privacy Protocol (the DES Symmetric Encryption Protocol defined in this memo is one such protocol) is optional.
Privacyプロトコル(このメモで定義されたDES Symmetric Encryptionプロトコルはそのようなプロトコルの1つである)の実装は任意です。
Blumenthal & Wijnen Standards Track [Page 74] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[74ページ]RFC3414USM
11.4. Use of Reports
11.4. レポートの使用
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.
unsecureレポート(すなわち、noAuthNoPrivのsecurityLevelと共にそれらを送る)の使用は潜在的に非正式のSNMPエンジンを何らかの形式の攻撃に暴露します。 これらのサービス不能攻撃、他のものがそうしないと考える人々もいます。 インストールはunsecure Report PDUsを配布する前にかかわった危険を評価するべきです。
11.5 Access to the SNMP-USER-BASED-SM-MIB
11.5 SNMPのユーザベースのSm MIBへのアクセス
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 [RFC3415]).
このMIBのオブジェクトは多くの環境で敏感であると考えられるかもしれません。 明確にusmUserTableのオブジェクトはユーザの情報、彼らの認証、およびプライバシープロトコルを含んでいます。 適切に構成されたAccess Controlモデル(例えば、[RFC3415]の指定されるとしてのViewベースのAccess Control Model)を使用することによってしっかりとこれらのMIBオブジェクトへのアクセスを制御するのは(読んで、書きます)重要です。
12. References
12. 参照
12.1 Normative References
12.1 標準の参照
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「メッセージダイジェストアルゴリズムMD5"、RFC1321、1992年4月。」
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M. and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58,
RFC 2578, April 1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M. and S. Waldbusser, "Textual Conventions
for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M. and S. Waldbusser, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
Blumenthal & Wijnen Standards Track [Page 75] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[75ページ]RFC3414USM
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC
3411, December 2002.
[RFC3411] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411、2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC
3412, December 2002.
[RFC3412] ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-
based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP)", STD 62, RFC
3415, December 2002.
[RFC3415]Wijnen(B.、Presuhn、R.、およびK.McCloghrie)は「Simple Network Managementプロトコル(SNMP)に関してベースのAccess Control Model(VACM)を見ます」、STD62、RFC3415、2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and
S. Waldbusser, "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3416, December 2002.
[RFC3416] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
[RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and
S. Waldbusser, "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62, RFC
3417, December 2002.
[RFC3417]Presuhn(R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMP)のためのマッピングを輸送します」、STD62、RFC3417、2002年12月。
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and
S. Waldbusser, "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)", STD
62, RFC 3418, December 2002.
[RFC3418] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、2002年12月。
[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).
[デス-NIST] データ暗号化規格、米国商務省標準技術局。 連邦情報処理基準(FIPS)公表46-1。 FIPS Publication46、(再び断言された1月、1977年1月;1988)に取って代わります。
[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、(1980年12月。)
[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 FIPS180-1、(1995年4月) http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.ps (追伸)
Blumenthal & Wijnen Standards Track [Page 76] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[76ページ]RFC3414USM
12.1 Informative References
12.1 有益な参照
[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.Hien、B.Wijnen「ネットワークマネージメントアプリケーションのための主要な派生」IEEE Network Magazine、4月/5月号、1997。
[DES-ANSI] Data Encryption Algorithm, American National
Standards Institute. ANSI X3.92-1981, (December,
1980).
[デス-ANSI] データ暗号化アルゴリズム、American National Standards Institut。 ANSI X3.92-1981、(1980年12月。)
[DESO-ANSI] Data Encryption Algorithm - Modes of Operation,
American National Standards Institute. ANSI X3.106-
1983, (May 1983).
[DESO-ANSI]データ暗号化アルゴリズム--運転モード、American National Standards Institut。 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).
NBSデータ暗号化規格、米国商務省標準技術局を実装して、使用するための[DESG-NIST]ガイドライン。 連邦情報処理基準(FIPS)公表74、(1981年4月。)
[DEST-NIST] Validating the Correctness of Hardware
Implementations of the NBS Data Encryption Standard,
National Institute of Standards and Technology.
Special Publication 500-20.
[DEST-NIST] NBSデータ暗号化規格のハードウェア実装、米国商務省標準技術局の正当性を有効にします。 特別な公表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、(1980年8月。)
[RFC3174] Eastlake, D. 3rd and P. Jones, "US Secure Hash
Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレークとD.3番目とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
Blumenthal & Wijnen Standards Track [Page 77] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[77ページ]RFC3414USM
APPENDIX A - Installation
付録A--インストール
A.1. SNMP engine Installation Parameters
A.1。 SNMPエンジンInstallation Parameters
During installation, an authoritative SNMP engine SHOULD (in the meaning as defined in [RFC2119]) be configured with several initial parameters. These include:
インストールの間、構成されていて、正式のSNMPはいくつかの初期値パラメタでSHOULD([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:
警戒姿勢の選択は、初期の構成が実装されるかどうか決定します、そして、そうだとすれば、どのようにですか? 3つの可能な選択の1つは選択されます:
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:
これを達成する1つの方法はインストーラをそれぞれの必要な秘密のための「パスワード」に入らせることです。 そして、パスワードは以下によってalgorithmicallyに必要な秘密に変換されます。
- forming a string of length 1,048,576 octets by repeating the
value of the password as often as necessary, truncating
accordingly, and using the resulting string as the input to the
MD5 algorithm [RFC1321]. The resulting digest, termed
"digest1", is used in the next step.
- 必要で、先端を切るのと同じくらい頻繁にそれに従って、パスワードの値を繰り返すことによって一連の長さの104万8576八重奏を形成して、入力としてMD5アルゴリズム[RFC1321]に結果として起こるストリングを使用します。 「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 [RFC1321].
- 2番目のストリングは、SNMPエンジンのdigest1、snmpEngineID値、およびdigest1を連結することによって、形成されます。 このストリングはMD5アルゴリズム[RFC1321]に入力されるように使用されています。
The resulting digest is the required secret (see Appendix A.2).
結果として起こるダイジェストは必要な秘密(Appendix A.2を見る)です。
Blumenthal & Wijnen Standards Track [Page 78] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[78ページ]RFC3414USM
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
プライバシーサポートプライバシーサポートがありません。------------------ --------------- usmUserEngineID localEngineID localEngineID usmUserNameの「初期」の「初期」のusmUserSecurityNameが「初期」のusmUserCloneFrom ZeroDotZero ZeroDotZero usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol usmUserAuthKeyChangeに「頭文字をつける」、「「「「usmUserOwnAuthKeyChange、「「「「usmUserPrivProtocol、usmDESPrivProtocol usmUserPrivKeyChangeのいずれ、も「でない「「「usmUserOwnPrivKeyChange、「「「「usmUserPublic、「「「「usmUserStorageType anyValidStorageTypeのanyValidStorageType usmUserStatusのアクティブな能動態」
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の1セットを例示するのがお勧めである、クローン、-、ユーザ、新たに作成された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
プライバシーサポートプライバシーサポートがありません。------------------ --------------- usmUserEngineID localEngineID localEngineID usmUserName"templateMD5""templateMD5" usmUserSecurityName"templateMD5""templateMD5" usmUserCloneFrom ZeroDotZero ZeroDotZero usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol usmUserAuthKeyChange、「「「「usmUserOwnAuthKeyChange、「「「「usmUserPrivProtocol、usmDESPrivProtocol usmUserPrivKeyChangeのいずれ、も「でない「「「usmUserOwnPrivKeyChange、「「「「usmUserPublic、「「「「usmUserStorageTypeの永久的な永久的なusmUserStatusアクティブな能動態」
Blumenthal & Wijnen Standards Track [Page 79] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[79ページ]RFC3414USM
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
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. Password to Key Algorithm
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 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].
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).
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).
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.
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.
Blumenthal & Wijnen Standards Track [Page 80] RFC 3414 USM for SNMPv3 December 2002
Blumenthal & Wijnen Standards Track [Page 80] RFC 3414 USM for SNMPv3 December 2002
A.2.1. Password to Key Sample Code for MD5
A.2.1. Password to Key Sample Code for 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;
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 */
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 */
/**********************************************/ /* 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);
/*****************************************************/ /* 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;
}
MD5Init(&MD); MD5Update(&MD, password_buf, 32+engineLength); MD5Final(key, &MD); return; }
Blumenthal & Wijnen Standards Track [Page 81] RFC 3414 USM for SNMPv3 December 2002
Blumenthal & Wijnen Standards Track [Page 81] RFC 3414 USM for SNMPv3 December 2002
A.2.2. Password to Key Sample Code for SHA
A.2.2. Password to Key Sample Code for 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;
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 */
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 */
/**********************************************/ /* 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);
/*****************************************************/ /* 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;
}
SHAInit(&SH); SHAUpdate(&SH, password_buf, 40+engineLength); SHAFinal(key, &SH); return; }
Blumenthal & Wijnen Standards Track [Page 82] RFC 3414 USM for SNMPv3 December 2002
Blumenthal & Wijnen Standards Track [Page 82] RFC 3414 USM for SNMPv3 December 2002
A.3. Password to Key Sample Results
A.3. Password to Key Sample Results
A.3.1. Password to Key Sample Results using MD5
A.3.1. Password to Key Sample Results using MD5
The following shows a sample output of the password to key algorithm for a 16-octet key using MD5.
The following shows a sample output of the password to key algorithm for a 16-octet key using MD5.
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:
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:
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
After the intermediate key (shown above) is localized with the snmpEngineID value of:
After the intermediate key (shown above) is localized with the snmpEngineID value of:
'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:
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 ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H
A.3.2. Password to Key Sample Results using SHA
A.3.2. Password to Key Sample Results using SHA
The following shows a sample output of the password to key algorithm for a 20-octet key using 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:
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:
'9f b5 cc 03 81 49 7b 37 93 52 89 39 ff 78 8d 5d 79 14 52 11'H
'9f b5 cc 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:
After the intermediate key (shown above) is localized with the snmpEngineID value of:
'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:
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
'66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f'H
A.4. Sample Encoding of msgSecurityParameters
A.4. Sample Encoding of 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.
The msgSecurityParameters in an SNMP message are represented as an OCTET STRING. This OCTET STRING should be considered opaque outside a specific Security Model.
Blumenthal & Wijnen Standards Track [Page 83] RFC 3414 USM for SNMPv3 December 2002
Blumenthal & Wijnen Standards Track [Page 83] RFC 3414 USM for SNMPv3 December 2002
The User-based Security Model defines the contents of the OCTET STRING as a SEQUENCE (see section 2.4).
The User-based Security Model defines the contents of the OCTET STRING as a SEQUENCE (see section 2.4).
Given these two properties, the following is an example of they msgSecurityParameters for the User-based Security Model, encoded as an OCTET STRING:
Given these two properties, the following is an example of they msgSecurityParameters for the User-based Security Model, encoded as an OCTET STRING:
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 <length> 30 <length> 04 <length> <msgAuthoritativeEngineID> 02 <length> <msgAuthoritativeEngineBoots> 02 <length> <msgAuthoritativeEngineTime> 04 <length> <msgUserName> 04 0c <HMAC-MD5-96-digest> 04 08 <salt>
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):
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):
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
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. Sample keyChange Results
A.5.1. Sample keyChange Results using MD5
A.5.1. Sample keyChange Results using MD5
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:
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:
'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
Blumenthal & Wijnen Standards Track [Page 84] RFC 3414 USM for SNMPv3 December 2002
Blumenthal & Wijnen Standards Track [Page 84] RFC 3414 USM for SNMPv3 December 2002
If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows:
If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows:
'01 ad d2 73 10 7c 4e 59 6b 4b 00 f8 2b 1d 42 a7'H
'01 ad d2 73 10 7c 4e 59 6b 4b 00 f8 2b 1d 42 a7'H
If we localize it for the above snmpEngineID, then the localized new key becomes:
If we localize it for the above snmpEngineID, then the localized new key becomes:
'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:
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:
Then the value we must send for keyChange is:
'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.
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. Sample keyChange Results using SHA
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:
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:
'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:
If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows:
'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 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H
If we localize it for the above snmpEngineID, then the localized new key becomes:
If we localize it for the above snmpEngineID, then the localized new key becomes:
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 91 f1 cd 25'H
'78 e2 dc 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:
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:
Then the value we must send for keyChange is:
'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 fd 48 3d 2d e8 d5 fa db f8 43 92 cb 06 45 70 51'
Blumenthal & Wijnen Standards Track [Page 85] RFC 3414 USM for SNMPv3 December 2002
Blumenthal & Wijnen Standards Track [Page 85] RFC 3414 USM for SNMPv3 December 2002
For the key used for privacy, the new nonlocalized key would be:
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 dc 4a 87 e3 e5 5e e4 d6 98 ac 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):
For the key used for privacy, the new localized key would be (note that they localized key gets truncated to 16 octets for DES):
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63'H
'78 e2 dc 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:
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:
Then the value we must send for keyChange for the privacy key is:
'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. Change Log
Changes made since RFC2574:
Changes made since RFC2574:
- Updated references
- Updated contact info
- Clarifications
- to first constraint item 1) on page 6.
- to usmUserCloneFrom DESCRIPTION clause
- to securityName in section 2.1
- Fixed "command responder" into "command generator" in last para of
DESCRIPTION clause of usmUserTable.
- Updated references - Updated contact info - Clarifications - to first constraint item 1) on page 6. - to usmUserCloneFrom DESCRIPTION clause - to securityName in section 2.1 - Fixed "command responder" into "command generator" in last para of DESCRIPTION clause of usmUserTable.
Changes made since RFC2274:
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.
- 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.
Blumenthal & Wijnen Standards Track [Page 86] RFC 3414 USM for SNMPv3 December 2002
Blumenthal & Wijnen Standards Track [Page 86] RFC 3414 USM for SNMPv3 December 2002
- 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
- どれがusmUserAuthProtocolとusmUserPrivProtocolを条件とさせるかの下で、その方法をはっきりさせて、初期化される、そして/または、変えることができます。 - usmUserAuthKeyChangeとusmUserPrivKeyChangeのために典型的なサイズのコメントを加えました。 usmUserOwnAuthKeyChangeとusmUserOwnPrivKeyChangeのためにも。 - usmUserAuthKeyChange、usmUserOwnAuthKeychange、usmUserPrivKeyChange、およびusmUserOwnPrivKeychangeの記述節に明確化を追加しました。 - usmUserStorageTypeの記述節に明確化を追加しました。 - usmUserStatusの記述節に明確化を追加しました。 - セクション8.1.1.1とさらに、はっきりさせられたセクション8.3.1ステップ1とセクション8.3.2ステップ3におけるIV世代手順をはっきりさせました。 - セクション11.2をはっきりさせて、反復性のストリングがある異なったサイズパスワードが同じキーをもたらすかもしれないという警告を加えました。 - クローニングのための付録Aへの加えられたテンプレートユーザは処理します。 - Appendix A.(Appendix A.の発生しているキーに関する例は修理されています)の固定C-コードの例はKeyChange値に関する例をAppendix A.に加えました--RFC1905 PDUタイプの代わりにPDU Classesを使用します。 - MIBへのセキュリティ部のReportsとAccess Controlに関するテキストを加えました。 - セクション3.2ステップ7の端で不正確な注意を取り除きました。 - セクション3.2ステップ3における注意を加えました。 - 直っている様々なスペルミスと誤植。 - 3.2ステップ2.a)のための直っている手順 - 様々な明確化。 - 新しいか改訂されたドキュメントの固定参照--もう使用されなかったキャッシュデータへの変化
Editors' Addresses
エディタのアドレス
Uri Blumenthal Lucent Technologies 67 Whippany Rd. Whippany, NJ 07981 USA
ユリブルーメンソルルーセントテクノロジーズ67ウィッパニー通り ウィッパニー、ニュージャージー07981米国
Phone: +1-973-386-2163 EMail: uri@lucent.com
以下に電話をしてください。 +1-973-386-2163 メールしてください: uri@lucent.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
バートWijnenルーセントテクノロジーズSchagen33 3461GLリンスホーテン・オランダ
Phone: +31-348-480-685 EMail: bwijnen@lucent.com
以下に電話をしてください。 +31-348-480-685 メールしてください: bwijnen@lucent.com
Blumenthal & Wijnen Standards Track [Page 87] RFC 3414 USM for SNMPv3 December 2002
SNMPv3 December 2002のためのブルーメンソルとWijnen標準化過程[87ページ]RFC3414USM
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Blumenthal & Wijnen Standards Track [Page 88]
ブルーメンソルとWijnen標準化過程[88ページ]
一覧
スポンサーリンク
