RFC2274 日本語訳
2274 User-based Security Model (USM) for version 3 of the SimpleNetwork Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. January 1998. (Format: TXT=168950 bytes) (Obsoletes RFC2264) (Obsoleted by RFC2574) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group U. Blumenthal
Request for Comments: 2274 IBM T. J. Watson Research
Obsoletes: 2264 B. Wijnen
Category: Standards Track IBM T. J. Watson Research
January 1998
コメントを求めるワーキンググループU.ブルーメンソル要求をネットワークでつないでください: 2274年のIBMのT.J.ワトソン研究は以下を時代遅れにします。 2264年のB.Wijnenカテゴリ: 標準化過程IBM T.J.ワトソン研究1998年1月
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
IANA Note
IANA注意
Due to a clerical error in the assignment of the snmpModules in this memo, this RFC provides the corrected number assignment for this protocol. This memo obsoletes RFC 2264.
このメモにおける、snmpModulesの課題における事務員の誤りのため、このRFCはこのプロトコルのための直っている数の課題を提供します。 このメモはRFC2264を時代遅れにします。
Abstract
要約
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.
このドキュメントはSNMPアーキテクチャ[RFC2271]における使用のためのSNMPバージョン3のために、UserベースのSecurity Model(USM)について説明します。 それは、メッセージレベルセキュリティをSNMPに供給するためにProcedureのElementsを定義します。 また、このドキュメントはこのSecurity Modelのための設定パラメータを離れてモニターするか、または管理するためのMIBを含んでいます。
Table of Contents
目次
1. Introduction 3 1.1. Threats 4 1.2. Goals and Constraints 5 1.3. Security Services 6 1.4. Module Organization 7 1.4.1. Timeliness Module 7 1.4.2. Authentication Protocol 8 1.4.3. Privacy Protocol 8 1.5. Protection against Message Replay, Delay and Redirection 8 1.5.1. Authoritative SNMP engine 8
1. 序論3 1.1。 脅威4 1.2。 目標と規制5 1.3。 セキュリティー・サービス6 1.4。 モジュール組織7 1.4.1。 タイムリーモジュール7 1.4.2。 認証プロトコル8 1.4.3。 プライバシープロトコル8 1.5。 メッセージに対する保護は遅れとリダイレクション8 1.5に.1に再演されます。 正式のSNMPエンジン8
Blumenthal & Wijnen Standards Track [Page 1] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[1ページ]RFC2274USM
1.5.2. Mechanisms 9 1.6. Abstract Service Interfaces. 10 1.6.1. User-based Security Model Primitives for Authentication 11 1.6.2. User-based Security Model Primitives for Privacy 11 2. Elements of the Model 12 2.1. User-based Security Model Users 12 2.2. Replay Protection 13 2.2.1. msgAuthoritativeEngineID 13 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 19 2.6. Key Localization Algorithm. 21 3. Elements of Procedure 21 3.1. Generating an Outgoing SNMP Message 22 3.2. Processing an Incoming SNMP Message 25 4. Discovery 30 5. Definitions 31 6. HMAC-MD5-96 Authentication Protocol 45 6.1. Mechanisms 45 6.1.1. Digest Authentication Mechanism 46 6.2. Elements of the Digest Authentication Protocol 46 6.2.1. Users 46 6.2.2. msgAuthoritativeEngineID 47 6.2.3. SNMP Messages Using this Authentication Protocol 47 6.2.4. Services provided by the HMAC-MD5-96 Authentication Module 47 6.2.4.1. Services for Generating an Outgoing SNMP Message 47 6.2.4.2. Services for Processing an Incoming SNMP Message 48 6.3. Elements of Procedure 49 6.3.1. Processing an Outgoing Message 49 6.3.2. Processing an Incoming Message 50 7. HMAC-SHA-96 Authentication Protocol 51 7.1. Mechanisms 51 7.1.1. Digest Authentication Mechanism 51 7.2. Elements of the HMAC-SHA-96 Authentication Protocol 52 7.2.1. Users 52 7.2.2. msgAuthoritativeEngineID 52 7.2.3. SNMP Messages Using this Authentication Protocol 53 7.2.4. Services provided by the HMAC-SHA-96 Authentication Module 53 7.2.4.1. Services for Generating an Outgoing SNMP Message 53 7.2.4.2. Services for Processing an Incoming SNMP Message 54 7.3. Elements of Procedure 54 7.3.1. Processing an Outgoing Message 55 7.3.2. Processing an Incoming Message 55 8. CBC-DES Symmetric Encryption Protocol 56
1.5.2. メカニズム9 1.6。 抽象的なサービスは連結します。 10 1.6.1. ユーザベースのセキュリティは.2に認証11 1.6のための基関数をモデル化します。 ユーザベースのセキュリティはプライバシー11 2のための基関数をモデル化します。 モデル12 2.1のもののElements。 ユーザベースのセキュリティはユーザ12 2.2をモデル化します。 .3に保護13 2.2.1msgAuthoritativeEngineID13 2.2.2msgAuthoritativeEngineBootsとmsgAuthoritativeEngineTime14 2.2を再演してください。 タイム・ウィンドウ15 2.3。 時間同期化15 2.4。 SNMP Messages UsingはこのSecurity Model16 2.5です。 .1にユーザベースの機密保護モデル17 2.5で提供されたサービス 外向的なSNMPメッセージ17 2.5.2を生成するためのサービス。 入って来るSNMPメッセージ19 2.6を処理するためのサービス。 主要なローカライズアルゴリズム。 21 3. 手順21 3.1歳のElements。 送信するSNMPメッセージ22が3.2であると生成します。 入って来るSNMPメッセージ25 4を処理します。 発見30 5。 定義31 6。 HMAC-MD5-96認証プロトコル45 6.1。 メカニズム、45 6.1 .1。 認証機構46 6.2を読みこなしてください。 ダイジェスト認証の要素は6.2に.1に46について議定書の中で述べます。 ユーザ46 6.2.2msgAuthoritativeEngineID47 6.2、.3 SNMP Messages UsingはこのAuthenticationプロトコル47 6.2.4です。 HMAC-MD5-96認証モジュール47 6.2.4.1で提供されたサービス。 .2に外向的なSNMPメッセージ47 6.2.4を生成するためのサービス 入って来るSNMPメッセージ48 6.3を処理するためのサービス。 手順49 6.3歳のElements、.1 .2に外向的なメッセージ49 6.3を処理します。 入って来るメッセージ50 7を処理します。 HMAC-SHA-96認証プロトコル51 7.1。 メカニズム、51 7.1 .1。 認証機構51 7.2を読みこなしてください。 HMAC-SHA-96認証の要素は7.2に.1に52について議定書の中で述べます。 ユーザ52 7.2.2msgAuthoritativeEngineID52 7.2、.3 SNMP Messages UsingはこのAuthenticationプロトコル53 7.2.4です。 HMAC-SHA-96認証モジュール53 7.2.4.1で提供されたサービス。 .2に外向的なSNMPメッセージ53 7.2.4を生成するためのサービス 入って来るSNMPメッセージ54 7.3を処理するためのサービス。 手順54 7.3歳のElements、.1 .2に外向的なメッセージ55 7.3を処理します。 入って来るメッセージ55 8を処理します。 CBC-DESの左右対称の暗号化プロトコル56
Blumenthal & Wijnen Standards Track [Page 2] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[2ページ]RFC2274USM
8.1. Mechanisms 56 8.1.1. Symmetric Encryption Protocol 57 8.1.1.1. DES key and Initialization Vector. 57 8.1.1.2. Data Encryption. 58 8.1.1.3. Data Decryption 59 8.2. Elements of the DES Privacy Protocol 59 8.2.1. Users 59 8.2.2. msgAuthoritativeEngineID 59 8.2.3. SNMP Messages Using this Privacy Protocol 60 8.2.4. Services provided by the DES Privacy Module 60 8.2.4.1. Services for Encrypting Outgoing Data 60 8.2.4.2. Services for Decrypting Incoming Data 61 8.3. Elements of Procedure. 61 8.3.1. Processing an Outgoing Message 61 8.3.2. Processing an Incoming Message 62 9. Intellectual Property 62 10. Acknowledgements 63 11. Security Considerations 64 11.1. Recommended Practices 64 11.2. Defining Users 66 11.3. Conformance 67 12. References 67 13. Editors' Addresses 69 A.1. SNMP engine Installation Parameters 70 A.2. Password to Key Algorithm 71 A.2.1. Password to Key Sample Code for MD5 71 A.2.2. Password to Key Sample Code for SHA 72 A.3. Password to Key Sample Results 73 A.3.1. Password to Key Sample Results using MD5 73 A.3.2. Password to Key Sample Results using SHA 74 A.4. Sample encoding of msgSecurityParameters 74 B. Full Copyright Statement 76
8.1. メカニズム、56 8.1 .1。 左右対称の暗号化は議定書を作ります。57 8.1 .1 .1。 DESキーと初期設定Vector。 57 8.1.1.2. データ暗号化。 58 8.1.1.3. データ復号59 8.2。 DESプライバシープロトコル59 8.2.1のもののElements。 ユーザ59 8.2.2msgAuthoritativeEngineID59 8.2、.3 SNMP Messages UsingはこのPrivacyプロトコル60 8.2.4です。 DESプライバシーモジュール60 8.2.4.1で提供されたサービス。 発信データ60 8.2に.4を暗号化するために、.2を修理します。 受信データ61が8.3であると解読するためのサービス。 手順のElements。 61 8.3.1. .2に外向的なメッセージ61 8.3を処理します。 入って来るメッセージ62 9を処理します。 知的所有権62 10。 承認63 11。 セキュリティ問題64 11.1。 推奨案64 11.2。 ユーザ66 11.3を定義します。 順応67 12。 参照67 13。 エディタのものは69A.1を扱います。 SNMPエンジンInstallation Parameters70A.2。 主要なアルゴリズム71A.2.1へのパスワード。 MD5 71A.2.2に、主要なサンプルコードへのパスワード。 SHA72A.3に、主要なサンプルコードへのパスワード。 主要なサンプル結果73A.3.1へのパスワード。 主要なサンプルへのパスワードは、MD5 73A.3.2を使用することで結果として生じます。 主要なサンプルへのパスワードは、SHA74A.4を使用することで結果として生じます。 msgSecurityParameters74B.Full Copyright Statement76のサンプルコード化
1. Introduction
1. 序論
The Architecture for describing Internet Management Frameworks [RFC2271] describes that an SNMP engine is composed of:
インターネットManagement Frameworks[RFC2271]について説明するための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
そしてSNMPアーキテクチャとアーキテクチャの用語が、本書では説明されたSecurity Modelがどこにアーキテクチャに収まるかを理解しているのを理解しているのが重要である。
Blumenthal & Wijnen Standards Track [Page 3] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[3ページ]RFC2274USM
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 [RFC2271].
アーキテクチャの中で他のサブシステムと対話します。 読者は、[RFC2271]で定義されるようにSNMPアーキテクチャの記述を読んで、理解していたと予想されます。
This memo [RFC2274] describes the User-based Security Model as it is used within the SNMP Architecture. The main idea is that we use the traditional concept of a user (identified by a userName) with which to associate security information.
それがSNMP Architectureの中で使用されるとき、このメモ[RFC2274]は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が保護を提供するはずである主要な脅威は以下の通りです。
- 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 user 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は以下に対して限定保護を提供します。
Blumenthal & Wijnen Standards Track [Page 4] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[4ページ]RFC2274USM
- 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.
- 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.
- サービス妨害This SNMP Security Modelは、認定ユーザを代表したサービスが否定される攻撃の広い声域を扱うのを試みません。 本当に、どんな実行可能なネットワーク管理プロトコルも当然のこととして対処されなければならないネットワーク失敗のタイプから区別できない多くの場合にはそのようなサービス不能攻撃があります。 - トラフィックAnalysis This SNMP Security Modelは、トラヒック分析が攻撃であると扱うのを試みません。 本当に、多くのトラフィック・パターンが予測できます、そして、(デバイスは比較的少ない数の管理アプリケーションで定期的に管理されるかもしれません)したがって、トラヒック分析から守ることによって提供されたどんな重要な利点もありません。
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メッセージが、主張するかにおけるユーザのアイデンティティの検証に備えてください。
Blumenthal & Wijnen Standards Track [Page 5] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[5ページ]RFC2274USM
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
should prefer the former.
1) ネットワーク圧力の時代による効果的な管理の要件がセキュリティのものに矛盾しているとき、デザインは前者を好むべきです。
2) Neither the security protocol nor its underlying security
mechanisms should depend upon the ready availability of other
network services (e.g., Network Time Protocol (NTP) or key
management protocols).
2) セキュリティプロトコルもその基本的なセキュリティー対策も他のネットワーク・サービス(例えば、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は特性の設備です。だれの利益受信データが溯源されたかのユーザの要求されたアイデンティティは確証されます。
- 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.
- メッセージタイムリーさであるのと限られた反復操作による保護は受け入れて、世代時間があるメッセージが指定されたタイムウィンドウの外にない特性の設備です。 メッセージ再命令が対処されていなくて、正常な状態でも起こることができることに注意してください。
Blumenthal & Wijnen Standards Track [Page 6] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[6ページ]RFC2274USM
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.
- メッセージペイロードの公開に対する保護。
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
セクション3(ProcedureのElements)はタイムリー照合をするSNMPメッセージでタイムリー値を使用します。 認証がメッセージに適用される場合にだけ、タイムリーチェックは実行されます。 以来
Blumenthal & Wijnen Standards Track [Page 7] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[7ページ]RFC2274USM
complete message is checked for integrity, we can assume that the timeliness values in a message that passes the authentication module are trustworthy.
完全なメッセージは保全がないかどうかチェックされて、私たちは、認証モジュールを通過するメッセージのタイムリー値が信頼できると思うことができます。
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ベースは使用中です。
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 (for example a Get, GetNext, GetBulk, Set or Inform PDU), then the receiver of such messages is authoritative. When an SNMP message contains a payload which does not expect a response (for example an SNMPv2-Trap, Response or Report PDU), then the sender of such a message is authoritative.
メッセージ再生、遅れ、およびリダイレクションから守って、各コミュニケーションにかかわるSNMPエンジンの1つは、正式のSNMPエンジンになるように指定されます。 SNMPメッセージが応答(例えば、Get、GetNext、GetBulk、SetまたはInform PDU)を予想するペイロードを含んでいると、そのようなメッセージの受信機は正式です。 SNMPメッセージが応答(例えば、SNMPv2-罠、ResponseまたはReport PDU)を予想しないペイロードを含んでいると、そのようなメッセージの送付者は正式です。
Blumenthal & Wijnen Standards Track [Page 8] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[8ページ]RFC2274USM
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
[RFC1907]).
メッセージ遅延か再生の脅威に対するこの保護は、メッセージの権限のない削除か秘匿に対する少しの保護も含意して、提供しません。 また、SNMPエンジンは、タイム・ウィンドウ間隔中にメッセージがかかわったすべてを送るならメッセージが再命令されるのを検出できないかもしれません。 また、Set操作(例えば、MIBの可変snmpSetSerialNo[RFC1907])を含むメッセージの再注文再生、削除、または秘匿を検出するのにセキュリティプロトコルの如何にかかわらず定義された他のメカニズムは使用できます。
2) Verification that a message sent to/from one authoritative SNMP
engine cannot be replayed to/as-if-from another authoritative SNMP
engine.
2) ある正式の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 Report, Response or Trap message 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.
潜在的に正式のSNMPエンジンによって1台の非正式のSNMPエンジンに送られたReport、ResponseまたはTrapメッセージは別の非正式のSNMPエンジンに再演できます。 後者の非正式のSNMPエンジンはその結果正式のSNMPエンジンのタイムリーインディケータの概念をアップデートするかもしれませんが(同じ秘密が正式のSNMPエンジンにある状態でほぼ同じくらいのuserNameを知っているなら)、それは脅威であると考えられません。
Blumenthal & Wijnen Standards Track [Page 9] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[9ページ]RFC2274USM
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.
この場合、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 timeliness value is within a Time Window of the current time. The Time Window represents an administrative upper bound on acceptable delivery delay for protocol messages.
それぞれのSNMPエンジンは2つの値、snmpEngineBoots、およびsnmpEngineTimeを維持します。(一緒に取って、snmpEngineTimeはそのSNMPエンジンで時間のしるしを供給します)。 そのSNMPエンジンからこれらの値の両方を発信する認証されたメッセージに含んでいるか、または受け取ります。 領収書の上では、値は、現在の時間のタイム・ウィンドウの中に示されたタイムリー値があるのを保証するためにチェックされます。 タイム・ウィンドウはプロトコルメッセージのために許容できる配送遅れに管理上限を表します。
For an SNMP engine to generate a message which an authoritative SNMP engine will accept as authentic, and to verify that a message received from that authoritative SNMP engine is authentic, such an SNMP engine must first achieve timeliness synchronization with the authoritative SNMP engine. See section 2.3.
SNMPエンジンが、正式のSNMPエンジンが正統であるとして認めるメッセージを生成して、その正式のSNMPエンジンから受け取られたメッセージが正統であることを確かめるように、そのようなSNMPエンジンは最初に、正式のSNMPエンジンとのタイムリー同期を達成しなければなりません。 セクション2.3を見てください。
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
抽象的なサービスインタフェースは、SNMP実体の中で様々なサブシステムの間の概念的なインタフェースについて説明するために定義されました。 同様に、1セットの抽象的なサービスインタフェースがありました。
Blumenthal & Wijnen Standards Track [Page 10] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[10ページ]RFC2274USM
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.
ジェネリック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のための秘密鍵--完全な認証されたメッセージ)
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
statusInformationがdecryptDataと等しい、(ワイヤの上に受け取られるIN decryptKey(IN privParametersを解読するための秘密鍵)
Blumenthal & Wijnen Standards Track [Page 11] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[11ページ]RFC2274USM
IN encryptedData -- encrypted data (encryptedPDU)
OUT decryptedData -- decrypted data (scopedPDU)
)
データ(scopedPDU)であると解読されたIN encryptedData(暗号化されたデータ(encryptedPDU)OUT decryptedData)
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.
Security Model独立者である形式でユーザの代理をするsecurityNameのA人間読み込み可能なストリング。
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:
- the HMAC-MD5-96 authentication protocol.
- the HMAC-SHA-96 authentication protocol.
メッセージがこのユーザを代表して発信したかどうかauthProtocol Anしるしを認証できます、そして、そうだとすれば、認証のタイプは議定書を作ります(使用されています)。 そのような2つのプロトコルがこのメモで定義されます: - 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。 アップデートがプライバシー保護を使う必要性なしで終了できるように、安全な方法でそれをします。
Blumenthal & Wijnen Standards Track [Page 12] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[12ページ]RFC2274USM
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エンジンを特定します(少なくとも管理ドメインの中で))。
- 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を表します。
Blumenthal & Wijnen Standards Track [Page 13] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[13ページ]RFC2274USM
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 [RFC2271]).
正式のSNMPエンジンが最初にインストールされるとき、企業特有のアルゴリズムによると、それはsnmpEngineIDの地方の値を設定します(SnmpEngineIDに関してSNMP Architectureドキュメント[RFC2271]の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はゼロにリセットされて、再び増加し始めます。
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
snmpEngineBoots値が値2147483647に達したSNMPエンジンをリセットするために、手動の介入が必要です。 エンジンを物理的に訪問されて、再構成しなければなりません。
Blumenthal & Wijnen Standards Track [Page 14] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[14ページ]RFC2274USM
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.
新しい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 local variable, latestReceivedEngineTime. This value records the highest value of snmpEngineTime that was received by the non-authoritative SNMP engine from the authoritative SNMP engine and is used to eliminate the possibility of replaying messages that would prevent the non-authoritative SNMP engine's notion of the snmpEngineTime from advancing.
非正式のSNMPエンジンが正式のSNMPエンジンから正式のSNMPエンジンのsnmpEngineBootsとsnmpEngineTimeの値のローカルの概念を得たとき、正統のコミュニケーションを続けるために非正式のSNMPエンジンによって必要とされた時間同期化は起こりました。 正式のSNMPエンジンのタイム・ウィンドウの中にこれらの値があるに違いありません(残ってください)。 それで、緩く正式のSNMPエンジンに保存される値に連動しているように正式のSNMPエンジンの値のローカルの概念を保たなければなりません。 また、正式のSNMPエンジンからsnmpEngineBootsとsnmpEngineTimeの地方の写しを取っておくことに加えて、非正式のSNMPエンジンは1つの局所変数(latestReceivedEngineTime)を保たなければなりません。 この値は非正式のSNMPエンジンによって正式のSNMPエンジンから受け取られて、非正式のSNMPエンジンのsnmpEngineTimeの概念が進むのを防ぐメッセージを再演する可能性を排除するのに使用されるsnmpEngineTimeの最も高い値を記録します。
A non-authoritative SNMP engine must keep local notions of these values 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エンジンのためにこれらの値のローカルの概念を保たなければなりません。 それぞれの正式の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
時間同期化はSNMPメッセージ(セクション3.2、ステップ7b)を受け取る手順の一部として起こります。 そういうものとして、どんな明白な時間同期化手順も非正式のSNMPエンジンによって必要とされません。 注意、snmpEngineIDの地方の値を変えるか(例えば、発見で)、またはいつがコミュニケーションを保証するかのときはいつも、それは最初に正式のSNMPエンジンで設立されます、地方
Blumenthal & Wijnen Standards Track [Page 15] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[15ページ]RFC2274USM
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.
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 [RFC2272]).
このSecurity Modelを使用するSNMPメッセージの構文はバージョン特有のMessage Processing Modelドキュメント(例えば、[RFC2272])で定義されたメッセージ・フォーマットを固く守ります。
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(1..32)),
-- authentication protocol specific parameters
msgAuthenticationParameters OCTET STRING,
-- privacy protocol specific parameters
msgPrivacyParameters OCTET STRING
}
END
UsmSecurityParameters:、:= {--グローバルなUserベースのセキュリティパラメタmsgAuthoritativeEngineID OCTET STRING、msgAuthoritativeEngineBoots INTEGER(0 .2147483647)、msgAuthoritativeEngineTime INTEGER(0 .2147483647)、msgUserName OCTET STRING(SIZE(1 .32))--認証は特定のパラメタmsgAuthenticationParameters OCTET STRINGについて議定書の中で述べます--プライバシープロトコルの特定のパラメタmsgPrivacyParameters OCTET STRING}というSEQUENCE 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.
- msgUserNameはメッセージがに代わって交換されているユーザ(主体)を指定します。
Blumenthal & Wijnen Standards Track [Page 16] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[16ページ]RFC2274USM
- 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つのサービスを提供します:
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メッセージを生成するサービス。 抽象的なサービス基関数は以下の通りです。
Blumenthal & Wijnen Standards Track [Page 17] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[17ページ]RFC2274USM
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.
essageProcessingModel
The SNMP version number for the message to be generated. This
data is not used by the User-based Security module.
globalData
The message header (i.e., its administrative information). This
data is not used by the User-based Security module.
maxMessageSize
The maximum message size as included in the message. This data is
not used by the User-based Security module.
securityParameters
These are the security parameters. They will be filled in by the
User-based Security module.
securityModel
The securityModel in use. Should be User-based Security Model.
This data is not used by the User-based Security module.
securityName
Together with the snmpEngineID it identifies a row in the
usmUserTable that is to be used for securing the message. The
securityName has a format that is independent of the Security
Model. In case of a response this parameter is ignored and the
value from the cache is used.
securityLevel
The Level of Security from which the User-based Security module
determines if the message needs to be protected from disclosure
メッセージをコード化と機密保護するのがうまくいったかどうかstatusInformation Anしるし。 それでないなら. 問題essageProcessingModelのしるしは生成するべきメッセージのSNMPバージョン番号ですか? このデータはそうです。UserベースのSecurityモジュールで. メッセージヘッダー(すなわち、管理情報)のglobalDataを使用しませんでした。 このデータは. メッセージの含まれるとしての最大のメッセージサイズのUserベースのSecurityモジュールmaxMessageSizeによって使用されません。 このデータはUserベースのSecurityモジュールで使用されません。securityParameters Theseはセキュリティパラメタです。 それらは使用中のUserベースのSecurityのモジュールsecurityModel securityModelによって記入されるでしょう。 UserベースのSecurity Modelであるべきです。 このデータはそれが使用されるためにusmUserTableの行を特定するメッセージを保証するsnmpEngineIDと共に. UserベースのSecurityモジュールsecurityName Togetherによって使用されません。 securityNameには、Security Modelから独立している形式があります。 応答の場合にはこのパラメタが無視されて、キャッシュからの値が使用されている、UserベースのSecurityモジュールが、メッセージが、公開から保護される必要であるかどうか決定するSecurityの. securityLevel Level
Blumenthal & Wijnen Standards Track [Page 18] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[18ページ]RFC2274USM
and if the message needs to be authenticated. In case of a
response this parameter is ignored and the value from the cache is
used.
securityEngineID
The snmpEngineID of the authoritative SNMP engine to which a
Request message is to be sent. In case of a response it is implied
to be the processing SNMP engine's snmpEngineID and so if it is
specified, then it is ignored.
scopedPDU
The message payload. The data is opaque as far as the User-based
Security Model is concerned.
securityStateReference
A handle/reference to cachedSecurityData to be used when securing
an outgoing Response message. This is the exact same
handle/reference as it was generated by the User-based Security
module when processing the incoming Request message to which this
is the Response message.
wholeMsg
The fully encoded and secured message ready for sending on the
wire.
wholeMsgLength
The length of the encoded and secured message (wholeMsg).
そして、メッセージが、必要があるなら、認証されてください。 応答の場合には、このパラメタは無視されます、そして、キャッシュからの値は使用されています。a Requestが通信する正式のSNMPエンジンのsecurityEngineID snmpEngineIDは送られることになっています。 指定されるなら応答の場合には処理SNMPエンジンのsnmpEngineIDであることが暗示しているのでそれが無視される、scopedPDU、メッセージペイロード。 データはUserベースのSecurity Modelが遠いのですが、送信するResponseメッセージを保証するとき不透明なものが. cachedSecurityDataのsecurityStateReference Aハンドル/参照が使用されるのが関係があったということです。 これがResponseメッセージである入って来るRequestメッセージを処理するとき、それがUserベースのSecurityモジュールで生成されたとき、これは全く同じハンドル/参照です。完全にコード化されていて機密保護されるのが通信させる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
statusInformationは誤りprocessIncomingMsgであるなら誤りカウンタOID/価値と等しいです(errorIndicationか成功)。(受信されたメッセージIN securityModelのための送付SNMP実体IN securityParametersのIN messageProcessingModel(通常SNMPバージョンIN maxMessageSize); ワイヤIN wholeMsgLength--ワイヤOUT securityEngineIDに受け取られる長さ--正式のSNMP実体OUT securityNameに受け取られる受信されたメッセージIN securityLevel(Security IN wholeMsgのレベル)のために--、主体の識別
Blumenthal & Wijnen Standards Track [Page 19] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[19ページ]RFC2274USM
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
OUT securityStateReference -- reference to security state
) -- information, needed for response
OUT scopedPDU--メッセージ(平文) ペイロード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.
messageProcessingModel
The SNMP version number as received in the message. This data is
not used by the User-based Security module.
maxMessageSize
The maximum message size as included in the message. The User-
based Security module uses this value to calculate the
maxSizeResponseScopedPDU.
securityParameters
These are the security parameters as received in the message.
securityModel
The securityModel in use. Should be the User-based Security
Model. This data is not used by the User-based Security module.
securityLevel
The Level of Security from which the User-based Security module
determines if the message needs to be protected from disclosure
and if the message needs to be authenticated.
wholeMsg
The whole message as it was received.
wholeMsgLength
The length of the message as it was received (wholeMsg).
securityEngineID
The snmpEngineID that was extracted from the field
msgAuthoritativeEngineID and that was used to lookup the secrets
in the usmUserTable.
securityName
The security name representing the user on whose behalf the
message was received. The securityName has a format that is
independent of the Security Model.
scopedPDU
The message payload. The data is opaque as far as the User-based
Security Model is concerned.
maxSizeResponseScopedPDU
The maximum size of a scopedPDU to be included in a possible
Response message. The User-base Security module calculates
プロセスがうまくいったかどうかstatusInformation Anしるし。 そうでなければ、その時、statusInformationは増加された誤りカウンタのOIDと値を含んでいます。. バージョンがメッセージに受け取るように付番するmessageProcessingModel SNMP。 このデータは. メッセージの含まれるとしての最大のメッセージサイズのUserベースのSecurityモジュールmaxMessageSizeによって使用されません。 UserのベースのSecurityモジュールは、maxSizeResponseScopedPDU. securityParameters Theseが. メッセージsecurityModel securityModelに受け取るようにセキュリティパラメタであると見込むのに使用中であるこの値を使用します。 UserベースのSecurity Modelであるべきです。 このデータはUserベースのSecurityモジュールが、メッセージが、公開から保護される必要があるかどうかと、メッセージが. それが全体が通信させるwholeMsgでしたが、認証される必要であるかどうか受け取られていた状態で決定するSecurityの. UserベースのSecurityモジュールsecurityLevel Levelによって使用されません; それとしてのメッセージの長さのwholeMsgLengthを受け取りました(wholeMsg)。分野msgAuthoritativeEngineIDとそれから抽出されたsecurityEngineID snmpEngineIDをルックアップに使用しました。セキュリティがメッセージがに代わって受け取られたユーザの代理をすると命名するusmUserTable. securityNameの秘密。 securityNameには、Security Model. scopedPDUの如何にかかわらずメッセージペイロードである形式があります。 データはUserベースのSecurity Modelが遠いのですが、不透明なものが. scopedPDUの最大サイズのmaxSizeResponseScopedPDUが可能なResponseメッセージに含まれているのが関係があったということです。 User-ベースSecurityモジュールは計算します。
Blumenthal & Wijnen Standards Track [Page 20] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[20ページ]RFC2274USM
this size based on the mms (as received in the message) and the
space required for the message header (including the
securityParameters) for such a Response message.
securityStateReference
A handle/reference to cachedSecurityData to be used when securing
an outgoing Response message. When the Message Processing
Subsystem calls the User-based Security module to generate a
response to this incoming message it must pass this
handle/reference.
送信するResponseメッセージを保証するとき、使用されて、mms(メッセージに受け取るように)に基づくこのサイズとスペースが、そのようなResponseメッセージのためのメッセージヘッダー(securityParametersを含んでいる)に. cachedSecurityDataのsecurityStateReference Aハンドル/参照は必要でした。 Message Processing Subsystemがこの入力メッセージへの応答を生成するためにUserベースのSecurityモジュールを呼ぶとき、それはこのハンドル/参照に合格しなければなりません。
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エンジンを続けたセキュリティについて説明します。
Blumenthal & Wijnen Standards Track [Page 21] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[21ページ]RFC2274USM
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と共に。
1) a) If any securityStateReference is passed (Response message),
then information concerning the user is extracted from the
cachedSecurityData. The securityEngineID and the
securityLevel are extracted from the cachedSecurityData. The
cachedSecurityData can now be discarded.
1) a) (応答メッセージ)がどんなsecurityStateReferenceにも通過されるなら、ユーザの情報はcachedSecurityDataから抜粋されます。 securityEngineIDとsecurityLevelはcachedSecurityDataから抽出されます。 現在、cachedSecurityDataを捨てることができます。
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--プライバシーパラメタを連載します)
Blumenthal & Wijnen Standards Track [Page 22] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[22ページ]RFC2274USM
statusInformation
indicates if the encryption process was successful or not.
encryptKey
the user's localized private privKey is the secret key that
can be used by the encryption algorithm.
dataToEncrypt
the serialized scopedPDU is the data that to be encrypted.
encryptedData
the encryptedPDU represents the encrypted scopedPDU,
encoded as an OCTET STRING.
privParameters
the privacy parameters, encoded as an OCTET STRING.
statusInformationは、暗号化プロセスがうまくいったかどうかを示します。ユーザが個人的なprivKeyをローカライズしたencryptKeyは暗号化アルゴリズムで使用できる秘密鍵です。dataToEncryptの連載されたscopedPDUはデータです。暗号化されるために. encryptedData encryptedPDUはプライバシーパラメタであって、OCTET STRINGとしてコード化されたOCTET STRING. privParametersとしてコード化された暗号化されたscopedPDUを表します。
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
protected from disclosure, then the NULL string is encoded as
an OCTET STRING and put into the msgPrivacyParameters field of
the securityParameters and the plaintext scopedPDU serves as
the payload of the message being prepared.
b) securityLevelが、メッセージが公開から保護されないことであると指定するなら、NULLストリングをOCTET STRINGとしてコード化して、securityParametersのmsgPrivacyParameters分野に入れます、そして、準備されていて、平文scopedPDUはメッセージのペイロードとして機能します。
5) The snmpEngineID is encoded as an OCTET STRING into the
msgAuthoritativeEngineID field of the securityParameters. Note
that an empty (zero length) snmpEngineID is OK for a Request
message, because that will cause the remote (authoritative) SNMP
engine to return a Report PDU with the proper snmpEngineID
included in the msgAuthoritativeEngineID in the
securityParameters of that returned Report PDU.
5) snmpEngineIDはOCTET STRINGとしてsecurityParametersのmsgAuthoritativeEngineID分野にコード化されます。 それがリモートを引き起こすので(正式の)、Requestメッセージに、空(ゼロ・レングス)のsnmpEngineIDがOKであることに注意してください。 返すそのsecurityParametersのmsgAuthoritativeEngineIDに適切なsnmpEngineIDと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 snmpEngineID from the LCD
are used.
6) a) securityLevelが、メッセージが認証されることであると指定するなら、LCDからのsnmpEngineIDに対応するsnmpEngineBootsとsnmpEngineTimeの現行価値は使用されています。
Otherwise,
そうでなければ
b) If this is a Response message, then the current value of
snmpEngineBoots and snmpEngineTime corresponding to the local
snmpEngineID from the LCD are used.
b) これがResponseメッセージであり、その時がsnmpEngineBootsの現在の値であり、snmpEngineTimeが対応しているなら、LCDからの地方のsnmpEngineIDは使用されています。
Blumenthal & Wijnen Standards Track [Page 23] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[23ページ]RFC2274USM
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.
authKey
the user's localized private authKey is the secret key that
can be used by the authentication algorithm.
wholeMsg
the complete serialized message to be authenticated.
authenticatedWholeMsg
the same as the input given to the authenticateOutgoingMsg
service, but with msgAuthenticationParameters properly
filled in.
statusInformationは、認証がうまくいったかどうかを示します。ユーザのauthKeyの局所化された個人的なauthKeyは認証アルゴリズムで使用できる秘密鍵です。完全なwholeMsgは認証されるべきメッセージを連載しました。. 中の入力が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)を呼ぶモジュールに返します。
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は認証されたメッセージの連載を表します。
Blumenthal & Wijnen Standards Track [Page 24] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[24ページ]RFC2274USM
Otherwise,
そうでなければ
b) If the securityLevel specifies that the message is not to
be authenticated then the NULL string is encoded as an OCTET
STRING into the msgAuthenticationParameters field of the
securityParameters. The wholeMsg is now serialized and then
represents the unauthenticated message being prepared.
b) securityLevelが、メッセージが認証されないことであると指定するなら、NULLストリングは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, when an error indication with an OID and value for an incremented counter is returned, then the available information (like securityStateReference) must be passed back to the caller so it can generate a Report PDU.
手順の要素を簡素化するために、州の情報のリリースはいつも明らかに指定されるというわけではありません。 また、概して、メッセージがいつ捨てられるかという州の情報が利用可能であるなら、州の情報は発表されるべきです。 また、そして、OIDとの誤り表示と増加しているカウンタへの値を返すとき、Report PDUを発生させることができるように、入手可能な情報(securityStateReferenceのような)を訪問者に戻さなければなりません。
1) If the received securityParameters is not the serialization
(according to the conventions of [RFC1906]) of an OCTET STRING
formatted according to the UsmSecurityParameters defined in
section 2.4, then the snmpInASNParseErrs counter [RFC1907] is
incremented, and an error indication (parseError) is returned to
the calling module. Note that we return without the OID and
value of the incremented counter, because in this case there is
not enough information to generate a Report PDU.
1) 容認されたsecurityParametersがセクション2.4で定義されたUsmSecurityParametersによると、フォーマットされたOCTET STRINGの連載([RFC1906]のコンベンションによると)でないなら、snmpInASNParseErrsカウンタ[RFC1907]は増加しています、そして、誤り表示(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
securityEngineID
securityLevel
msgUserName securityEngineID securityLevel
3) If the value of the msgAuthoritativeEngineID field in the
securityParameters is unknown then:
3) securityParametersのmsgAuthoritativeEngineID分野の値がその時未知であるなら:
Blumenthal & Wijnen Standards Track [Page 25] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[25ページ]RFC2274USM
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)を呼ぶモジュールに返します。
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)
statusInformation
indicates if authentication was successful or not.
authKey
the user's localized private authKey is the secret key that
can be used by the authentication algorithm.
wholeMsg
the complete serialized message to be authenticated.
statusInformationは、認証がうまくいったかどうかを示します。ユーザのauthKeyの局所化された個人的なauthKeyは認証アルゴリズムで使用できる秘密鍵です。完全なwholeMsgは認証されるべきメッセージを連載しました。
Blumenthal & Wijnen Standards Track [Page 26] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[26ページ]RFC2274USM
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 and snmpEngineTime
corresponding to the value of the msgAuthoritativeEngineID
field are extracted from the Local Configuration Datastore.
7) securityLevelが認証されたメッセージを示すなら、msgAuthoritativeEngineID分野の値に対応するsnmpEngineBootsとsnmpEngineTimeの地方の値は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
and value of the incremented counter is returned to the
calling module.
タイム・ウィンドウの外にあるとメッセージを考えるなら、usmStatsNotInTimeWindowsカウンタは増加しています、そして、増加しているカウンタのOIDと値に伴う誤り表示(notInTimeWindow)を呼ぶモジュールに返します。
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の価値のローカルの概念より大きいです。 または
Blumenthal & Wijnen Standards Track [Page 27] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[27ページ]RFC2274USM
- the extracted value of the msgAuthoritativeEngineBoots
field is equal to the local notion of the value of
snmpEngineBoots, the extracted value of
msgAuthoritativeEngineTime field is greater than the
value of latestReceivedEngineTime,
- msgAuthoritativeEngineBoots分野の抽出された値がsnmpEngineBootsの価値のローカルの概念と等しい、msgAuthoritativeEngineTime分野の抽出された値はlatestReceivedEngineTimeの値より大きいです。
then the LCD entry corresponding to the extracted value
of the msgAuthoritativeEngineID field is updated, by
setting:
次に、設定はmsgAuthoritativeEngineID分野の抽出された値に対応するLCDエントリーをアップデートします:
- the local notion of the value of snmpEngineBoots to
the value of the msgAuthoritativeEngineBoots field,
- the local notion of the value of snmpEngineTime to
the value of the msgAuthoritativeEngineTime field,
and
- the latestReceivedEngineTime to the value of the
value of the msgAuthoritativeEngineTime field.
- そして、msgAuthoritativeEngineBoots分野の値へのsnmpEngineBootsの価値のローカルの概念--msgAuthoritativeEngineTime分野の値へのsnmpEngineTimeの価値のローカルの概念、--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 of the value of
snmpEngineTime.
- msgAuthoritativeEngineBoots分野の値はsnmpEngineBootsの価値のローカルの概念と等しいです、そして、msgAuthoritativeEngineTime分野の値は150がsnmpEngineTimeの価値についてローカルの概念以下を後援する以上です。
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
この手順が考慮するsnmpEngineBootsの価値のローカルの概念が正統であるとして認められるべきメッセージを受け取ったよりすばらしくなるメッセージのmsgAuthoritativeEngineBootsの値を考慮することに注意してください。
Blumenthal & Wijnen Standards Track [Page 28] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[28ページ]RFC2274USM
when received from an authoritative SNMP engine that has
re-booted since the receiving SNMP engine last
(re-)synchronized.
いつが受信SNMPエンジン最終以来リブートされている正式のSNMPエンジンから受信されたか、(再、)、連動しています。
Note that this procedure does not allow for automatic
time synchronization if the non-authoritative SNMP engine
has a real out-of-sync situation whereby the authoritative
SNMP engine is more than 150 seconds behind the
non-authoritative SNMP engine.
非正式のSNMPエンジンに非正式のSNMPエンジンの150秒以上後ろに正式のSNMPエンジンがある全く同期していない状況があるならこの手順が自動時間同期化を考慮しないことに注意してください。
8) a) If the securityLevel indicates that the message was protected
from disclosure, then the OCTET STRING representing the
encryptedPDU is decrypted according to the user's privacy
protocol to obtain an unencrypted serialized scopedPDU value.
To do so a call is made to the privacy module that implements
the user's privacy protocol according to the abstract
primitive:
8) a) securityLevelが、メッセージが公開から保護されたのを示すなら、ユーザのプライバシープロトコルによると、encryptedPDUを表す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.
decryptKey
the user's localized private privKey is the secret key that
can be used by the decryption algorithm.
privParameters
the msgPrivacyParameters, encoded as an OCTET STRING.
encryptedData
the encryptedPDU represents the encrypted scopedPDU, encoded
as an OCTET STRING.
decryptedData
the serialized scopedPDU if decryption is successful.
statusInformationは、復号化の過程がうまくいったかどうかを示します。ユーザのdecryptKeyの局所化された個人的なprivKeyは復号化アルゴリズムで使用できる秘密鍵です。復号化がうまくいくなら、OCTET STRING. encryptedData encryptedPDUがコード化されたscopedPDUを表すのでコード化されたprivParameters msgPrivacyParametersはOCTET STRING. decryptedDataとして連載されたscopedPDUをコード化しました。
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は呼ぶモジュールに返されるメッセージペイロードです。
Blumenthal & Wijnen Standards Track [Page 29] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[29ページ]RFC2274USM
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, the same securityLevel and
the same value for msgAuthoritativeEngineID. Information to be
saved/cached is as follows:
11) セキュリティー・データはcachedSecurityDataとしてキャッシュされます、このメッセージへの可能な応答が使用できて、msgAuthoritativeEngineIDに同じ認証、プライバシー秘密、同じsecurityLevel、および同じ値を使用するように。 救われるべきであるか、またはキャッシュされるべき情報は以下の通りです:
msgUserName,
usmUserAuthProtocol, usmUserAuthKey
usmUserPrivProtocol, usmUserPrivKey
securityEngineID, securityLevel
msgUserName、usmUserAuthProtocol、usmUserAuthKey usmUserPrivProtocol、usmUserPrivKey securityEngineID、securityLevel
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 "initial", a msgAuthoritativeEngineID value of zero length, and the varBindList left empty. The response to this message will be a Report message containing the snmpEngineID of the authoritative SNMP engine as the value of the msgAuthoritativeEngineID field within the msgSecurityParameters field. It contains a Report PDU with the usmStatsUnknownEngineIDs counter in the varBindList.
UserベースのSecurity Modelは、発見プロセスが彼らとコミュニケートするために他のSNMPエンジンに関する十分な情報を得るのを必要とします。 発見は、コミュニケーションが続くかもしれない前に正式のSNMPエンジンのsnmpEngineID値を学ぶために非正式のSNMPエンジンを必要とします。 これは、noAuthNoPrivのsecurityLevel、「初期」のmsgUserName、ゼロ・レングスのmsgAuthoritativeEngineID値、および空の状態で残っているvarBindListと共にRequestメッセージを生成することによって、達成されるかもしれません。 このメッセージへの応答はmsgAuthoritativeEngineID分野の値としてmsgSecurityParameters分野の中に正式のSNMPエンジンのsnmpEngineIDを保管しているReportメッセージになるでしょう。 それは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
また、認証されたコミュニケーションが必要であるなら、発見プロセスは正式のSNMPエンジンで時間同期化を確立するはずです。 これは、発信することによって、達成されるかもしれません。
Blumenthal & Wijnen Standards Track [Page 30] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[30ページ]RFC2274USM
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. 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.
msgAuthoritativeEngineIDの値がある認証されたRequestメッセージは新たに学習されたsnmpEngineIDとmsgAuthoritativeEngineBootsの値でセットしました、そして、msgAuthoritativeEngineTimeはゼロにセットしました。 この認証されたメッセージへの応答はそれぞれ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 "9711200000Z" -- 20 Nov 1997, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In msg body: subscribe snmpv3
snmpUsmMIB MODULE-IDENTITY LAST-UPDATED"9711200000Z"--1997年11月20日、真夜中の組織「SNMPv3ワーキンググループ」コンタクトインフォメーションは「以下をWGメールします」。 snmpv3@tis.com は申し込まれます: msgボディーの majordomo@tis.com : snmpv3を申し込んでください。
Chair: Russ Mundy
Trusted Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
USA
email: mundy@tis.com
phone: +1-301-854-6889
議長: ラスマンディTrusted情報Systems郵便: 3060 ワシントンRdグレンウッドMD21738米国メール: mundy@tis.com 電話: +1-301-854-6889
Co-editor Uri Blumenthal
IBM T. J. Watson Research
postal: 30 Saw Mill River Pkwy,
Hawthorne, NY 10532
USA
email: uri@watson.ibm.com
共同エディタユリブルーメンソルIBM T.J.ワトソンResearch郵便: 30 Mill川のPkwy、ホーソーン、ニューヨーク10532米国メールは見ました: uri@watson.ibm.com
Blumenthal & Wijnen Standards Track [Page 31] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[31ページ]RFC2274USM
phone: +1-914-784-7964
電話: +1-914-784-7964
Co-editor: Bert Wijnen
IBM T. J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-432-794
"
共同エディタ: バートWijnen IBM T.J.ワトソンResearch郵便: Schagen33 3461GLリンスホーテン・オランダはメールされます: wijnen@vnet.ibm.com 電話: +31-348-432-794 "
DESCRIPTION "The management information definitions for the
SNMP User-based Security Model.
"
::= { snmpModules 15 }
記述、「SNMP UserベースのSecurity Modelのための経営情報定義。」 " ::= 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
Blumenthal & Wijnen Standards Track [Page 32] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[32ページ]RFC2274USM
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.
Supersedes FIPS Publication 46,
(January, 1977; reaffirmed January, 1988).
「CBC-DESの左右対称の暗号化は議定書の中で述べる」usmDESPrivProtocol OBJECT-IDENTITY STATUSの現在の記述。 参照、「-、データ暗号化規格、米国商務省標準技術局、」 連邦情報処理基準(FIPS)公表46-1。 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つのコンポーネントの連結です: 最初に、'無作為'のコンポーネントとそして、'デルタ'コンポーネント。
Blumenthal & Wijnen Standards Track [Page 33] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[33ページ]RFC2274USM
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の八重奏の固定長であることを必要とします。 適切であると考えられるように他のプロトコルは他のサイズを定義するかもしれません。
When a requestor 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 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 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ステップはデルタコンポーネントの未使用の部分が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);
繰り返しは/16と等しいです(lenOfDelta--1)。 /*整数分割*/臨時はkeyOldと等しいです。 臨時はMD5と等しいです。(i=0; i<繰り返し; i++)、(派遣社員として働いてください|、|、無作為である、)、。
Blumenthal & Wijnen Standards Track [Page 34] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[34ページ]RFC2274USM
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];
デルタ[i*16(i*16)+15]は臨時XOR keyNewと等しいです[i*16(i*16)+15]。 臨時はMD5と等しいです。(派遣社員として働いてください|、|、無作為である、)、。 デルタ[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 receipient as the new value of an instance of this
object.
次に、上で説明されるように'無作為'と'デルタ'コンポーネントを連結します、そして、このオブジェクトのインスタンスの新しい値として結果として起こる八重奏ストリングをreceipientに送ります。
At the receiver side, when an instance of this object is set
to a new value, then a new value of K is computed as follows:
次に、受信機側では、このオブジェクトのインスタンスが新しい値に設定されるとき、Kの新しい値が以下の通り計算されます:
- a temporary variable is initialized to the existing value
of K;
- if the length of the delta component is greater than L
octets, then:
- the random component is appended to the value of the
temporary variable, and the result is input to the
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);
繰り返しは/16と等しいです(lenOfDelta--1)。 /*整数分割*/臨時はkeyOldと等しいです。 臨時はMD5と等しいです。臨時はMD5と等しいです。(i=0; i<繰り返し; i++)、(派遣社員として働いてください|、|、無作為である、)、; keyNew[i*16(i*16)+15]は臨時XORデルタ[i*16(i*16)+15]と等しいです;、(派遣社員として働いてください|、|、無作為である、)、。
Blumenthal & Wijnen Standards Track [Page 35] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[35ページ]RFC2274USM
keyNew[i*16 .. lenOfDelta-1] =
temp XOR delta[i*16 .. lenOfDelta-1];
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.
"
SYNTAX OCTET STRING
それが管理プロトコルによって検索されるときはいつも、いつもこの構文があるオブジェクトの値はゼロ長ストリングです。 「構文八重奏ストリング」
-- 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
usmStatsUnknownEngineIDsオブジェクト・タイプ
Blumenthal & Wijnen Standards Track [Page 36] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[36ページ]RFC2274USM
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エンジンで受けた」SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 " ::= usmStats4
usmStatsWrongDigests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they didn't
contain the expected digest value.
"
::= { usmStats 5 }
「パケットの総数は予想されたダイジェスト値を含まなかったので下げられたSNMPエンジンで受けた」usmStatsWrongDigests OBJECT-TYPE 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
UsmUserEntryのusmUserTableオブジェクト・タイプ構文系列
Blumenthal & Wijnen Standards Track [Page 37] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[37ページ]RFC2274USM
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of users configured in the SNMP engine's
Local Configuration Datastore (LCD)."
::= { usmUser 2 }
「ユーザのテーブルはSNMPエンジンのLocal Configuration Datastore(LCD)で構成した」マックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= 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 38] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[38ページ]RFC2274USM
"
::= { 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 are cloned
from its clone-from user.
新しいユーザの新しいユーザがいつ創造されるか、そして、(すなわち、新しい概念的な行はこのテーブルに例示されます)プライバシーと認証パラメタがクローンを作られる、それ、クローン、-、ユーザ
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'
初めて管理操作(具体化におけるその具体化の後の)でこのオブジェクトのインスタンスが設定されるとき、クローニングプロセスは呼び出されます。 その後、書く、うまくいきますが、'inconsistentName'に応じて. クローニングプロセスが失敗する受信機で取るために動作を全く呼び出しません。
Blumenthal & Wijnen Standards Track [Page 39] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[39ページ]RFC2274USM
error if the conceptual row representing the
clone-from user is not in an active state when the
cloning process is invoked.
誤りが概念的であるなら表すことをこぐ、クローン、-、ユーザ、クローニングプロセスが呼び出されるとき、活動的な状態には、ありません。
Cloning also causes the initial values of the secret
authentication key and the secret encryption key of
the new user to be set to the same value as the
corresponding secret of the clone-from user.
また、対応と同じ値へのセットが秘密であったならクローニングが秘密の認証キーと新しいユーザの秘密の暗号化キーの初期の値を引き起こす、クローン、-、ユーザ
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). Once created,
the value of an instance of this object can not be
changed.
このオブジェクトのインスタンスは同じユーザ(すなわち、同じ概念的な行における最初のオブジェクトインスタンスを作成する集合演算の処理の一部としての)のために同時にいかなる他のオブジェクトインスタンスの作成でも作成されます。 いったん作成されると、このオブジェクトのインスタンスの値を変えることができません。
If a set operation tries to set a value for an unknown
or unsupported protocol, then a wrongValue error must
be returned.
"
DEFVAL { usmHMACMD5AuthProtocol }
::= { usmUserEntry 5 }
集合演算が未知の、または、サポートされないプロトコルに値を設定しようとするなら、wrongValue誤りを返さなければなりません。 「DEFVAL usmHMACMD5AuthProtocol:、:、」= usmUserEntry5
usmUserAuthKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0..32))
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))、マックス-ACCESSがSTATUSの現在の記述を読書して作成する「オブジェクト、どれ、変更されたいつ、秘密の認証キーがSNMPエンジンからの/へのこのユーザを代表して送られたメッセージに使用した原因が一方向関数で変更されるためにusmUserEngineIDを特定したか、」
Blumenthal & Wijnen Standards Track [Page 40] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[40ページ]RFC2274USM
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 value
of usmUserCloneFrom.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 6 }
新しいユーザを創造するとき、以前にか同時にusmUserCloneFromの換算値における集合演算で初期化されない場合、それはSet操作がこのオブジェクトについて言及する'inconsistentName'誤りです。 「DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry6
usmUserOwnAuthKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0..32))
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.
通常(SIZE(0 .32))、マックス-ACCESSはSTATUSを読書して作成します。usmUserOwnAuthKeyChange OBJECT-TYPE SYNTAX KeyChange--、現在の記述は「ちょうど1つの注目に値する違いがあるusmUserAuthKeyChangeとして以下を振る舞います」。 引き継ぐSet操作において整然とします、操作リクエスタのusmUserNameはこの操作で狙う行に索引をつけるusmUserNameに合わなければなりません。
The idea here is that access to this column can be
public, since it will only allow a user to change
his own secret authentication key (authKey).
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 7 }
このコラムへのアクセスが公共である場合があるという考えがここにあります、ユーザがそれで、彼自身の秘密の認証キー(authKey)を変えることができるだけであるので。 「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). Once created,
the value of an instance of this object can not be
このオブジェクトのインスタンスは同じユーザ(すなわち、同じ概念的な行における最初のオブジェクトインスタンスを作成する集合演算の処理の一部としての)のために同時にいかなる他のオブジェクトインスタンスの作成でも作成されます。 いったん作成されると、このオブジェクトのインスタンスの値は作成されるはずがありません。
Blumenthal & Wijnen Standards Track [Page 41] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[41ページ]RFC2274USM
changed.
変える。
If a set operation tries to set a value for an unknown
or unsupported protocol, then a wrongValue error must
be returned.
"
DEFVAL { usmNoPrivProtocol }
::= { usmUserEntry 8 }
集合演算が未知の、または、サポートされないプロトコルに値を設定しようとするなら、wrongValue誤りを返さなければなりません。 「DEFVAL usmNoPrivProtocol:、:、」= usmUserEntry8
usmUserPrivKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An object, which when modified, causes the secret
encryption key used for messages sent on behalf
of this user to/from the SNMP engine identified by
usmUserEngineID, to be modified via a one-way
function.
usmUserPrivKeyChange OBJECT-TYPE SYNTAX KeyChange、--、通常(SIZE(0 .32))、マックス-ACCESSが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 value
of usmUserCloneFrom.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 9 }
新しいユーザを創造するとき、以前にか同時にusmUserCloneFromの換算値における集合演算で初期化されない場合、それは集合演算がこのオブジェクトについて言及する'inconsistentName'誤りです。 「DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry9
usmUserOwnPrivKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
notable difference: in order for the Set operation
to succeed, the usmUserName of the operation
requester must match the usmUserName that indexes
the row which is targeted by this operation.
通常(SIZE(0 .32))、マックス-ACCESSはSTATUSを読書して作成します。usmUserOwnPrivKeyChange OBJECT-TYPE SYNTAX KeyChange--、現在の記述は「ちょうど1つの注目に値する違いがあるusmUserPrivKeyChangeとして以下を振る舞います」。 引き継ぐSet操作において整然とします、操作リクエスタのusmUserNameはこの操作で狙う行に索引をつけるusmUserNameに合わなければなりません。
The idea here is that access to this column can be
public, since it will only allow a user to change
his own secret privacy key (privKey).
"
このコラムへのアクセスが公共である場合があるという考えがここにあります、ユーザがそれで、彼自身の秘密のプライバシーキー(privKey)を変えることができるだけであるので。 "
Blumenthal & Wijnen Standards Track [Page 42] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[42ページ]RFC2274USM
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 10 }
DEFVAL、「H、--空は以下を結びます:、」= usmUserEntry10
usmUserPublic OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A publicly-readable value which is 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。
Note that any user who employs authentication or
privacy must allow its secret(s) to be updated and
thus cannot be 'readOnly'.
"
DEFVAL { nonVolatile }
::= { usmUserEntry 12 }
認証かプライバシーを使うどんなユーザも秘密をアップデートするのを許容しなければならなくて、その結果、'readOnly'であることができないことに注意してください。 「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
すべての対応のインスタンスまで、コラムは適切に構成されて、usmUserStatusの対応するインスタンスの値はコラムです。
Blumenthal & Wijnen Standards Track [Page 43] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[43ページ]RFC2274USM
is 'notReady'.
'notReady'はそうですか?
In particular, a newly created row cannot be made
active until the corresponding usmUserCloneFrom,
usmUserAuthKeyChange, usmUserOwnAuthKeyChange,
usmUserPrivKeyChange and usmUserOwnPrivKeyChange
have all been set.
新たに作成された行はアクティブに特に、対応するusmUserCloneFrom、usmUserAuthKeyChange、usmUserOwnAuthKeyChange、usmUserPrivKeyChange、およびusmUserOwnPrivKeyChangeがすべて用意ができるまですることができません。
The RowStatus TC [RFC1903] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
RowStatus TC[RFC1903]は、この記述節が、どの状況でこの行の他のオブジェクトを変更できるかを述べるのを必要とします:
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { usmUserEntry 13 }
このオブジェクトの値はこの概念的な行の他のオブジェクトを変更できるかどうかに関して効き目がありません。 " ::= 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,
-- ユニットの承諾usmMIBBasicGroup OBJECT-GROUP OBJECTS、usmStatsUnsupportedSecLevels、usmStatsNotInTimeWindows
Blumenthal & Wijnen Standards Track [Page 44] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[44ページ]RFC2274USM
usmStatsUnknownUserNames,
usmStatsUnknownEngineIDs,
usmStatsWrongDigests,
usmStatsDecryptionErrors,
usmUserSpinLock,
usmUserSecurityName,
usmUserCloneFrom,
usmUserAuthProtocol,
usmUserAuthKeyChange,
usmUserOwnAuthKeyChange,
usmUserPrivProtocol,
usmUserPrivKeyChange,
usmUserOwnPrivKeyChange,
usmUserPublic,
usmUserStorageType,
usmUserStatus
}
STATUS current
DESCRIPTION "A collection of objects providing for configuration
of an SNMP engine which implements the SNMP
User-based Security Model.
"
::= { usmMIBGroups 1 }
usmStatsUnknownUserNames、usmStatsUnknownEngineIDs、usmStatsWrongDigests、usmStatsDecryptionErrors、usmUserSpinLock、usmUserSecurityName、usmUserCloneFrom、usmUserAuthProtocol、usmUserAuthKeyChange、usmUserOwnAuthKeyChange、usmUserPrivProtocol、usmUserPrivKeyChange、usmUserOwnPrivKeyChange、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 [MD5], in HMAC mode described in [RFC2104], truncating the output to 96 bits.
このセクションはHMAC-MD5-96認証プロトコルについて説明します。 この認証プロトコルはUserベースのSecurity Modelのために定義された1番目です。 それは[MD5]で説明される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メッセージの適切な部分に関して計算されて、含まれています。
Blumenthal & Wijnen Standards Track [Page 45] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[45ページ]RFC2274USM
- 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の保全の検証はメッセージを受け取って、すなわち、受け取られたメッセージは送られたメッセージです。
The integrity of the message is protected by computing a digest
over an appropriate portion of the message. The digest is computed
by the originator of the message, transmitted with the message, and
verified by the recipient of the message.
メッセージの保全は、メッセージの適切な部分に関してダイジェストを計算することによって、保護されます。 ダイジェストは、メッセージで送られたメッセージの創始者によって計算されて、メッセージの受取人によって確かめられます。
- verification of the user on whose behalf the message was generated.
- メッセージがだれの代理に生成されたかにおけるユーザの検証。
A secret value known only to SNMP engines authorized to generate
messages on behalf of a user is used in HMAC mode (see [RFC2104]).
It also recommends the hash-function output used as Message
Authentication Code, to be truncated.
ユーザを代表してメッセージを生成するのが認可されたSNMPエンジンだけに知られている秘密の値はHMACモードで使用されます([RFC2104]を見てください)。 また、それは先端を切られるのにメッセージ立証コードとして使用されるハッシュ関数出力を推薦します。
This protocol uses the MD5 [MD5] message digest algorithm. A 128-bit MD5 digest is calculated in a special (HMAC) way over the designated portion of an SNMP message and the first 96 bits of this digest is included as part of the message sent to the recipient. The size of the digest carried in a message is 12 octets. The size of the private authentication key (the secret) is 16 octets. For the details see section 6.3.
このプロトコルはMD5[MD5]メッセージダイジェストアルゴリズムを使用します。 128ビットのMD5ダイジェストはSNMPメッセージの指定された部分に関して特別な(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
この認証プロトコルを使用する認証がuserNamesの定義されたセットを利用します。 特定のSNMPエンジンでに代わってメッセージを認証しなければならないどんなユーザに関してはも、そのSNMPエンジンには、そのユーザに関する知識がなければなりません。 そうしたがっているSNMPエンジン
Blumenthal & Wijnen Standards Track [Page 46] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[46ページ]RFC2274USM
communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user.
SNMPエンジンがコミュニケートしなければならない別のものとコミュニケートしてください、そして、また、ユーザに関する知識をそのエンジンに知らせてください、そのユーザの適切な属性に関する知識を含んでいて。
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の八重奏でなければなりません。
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 [RFC2271]).
認証されたメッセージに含まれたmsgAuthoritativeEngineID値はその特定のメッセージに正式のSNMPエンジンを指定します(SNMP Architectureドキュメント[RFC2271]の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の選択を完了していて、訪問者が使用されるために秘密鍵を渡すと仮定します。
Blumenthal & Wijnen Standards Track [Page 47] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[47ページ]RFC2274USM
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.
authKey
The secret key to be used by the authentication algorithm.
The length of this key MUST be 16 octets.
wholeMsg
The message to be authenticated.
authenticatedWholeMsg
The authenticated message (including inserted digest) on output.
認証過程がうまくいったかどうかstatusInformation Anしるし。 それでないなら、認証アルゴリズムによって. 問題authKeyのしるしは使用されているために主要な秘密ですか? このキーの長さは16の八重奏wholeMsgが認証されるべきメッセージであったならそうしなければなりません。. 認証が出力のときに通信させる(包含はダイジェストを挿入しました)authenticatedWholeMsg。
Note, that authParameters field is filled by the authentication module and this field should be already present in the wholeMsg before the Message Authentication Code (MAC) is generated.
注意、そのauthParameters分野は認証モジュールでいっぱいにされます、そして、メッセージ立証コード(MAC)が発生している前にこの分野はwholeMsgに既に存在しているべきです。
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:
抽象的なデータ要素は以下の通りです。
Blumenthal & Wijnen Standards Track [Page 48] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[48ページ]RFC2274USM
statusInformation
An indication of whether the authentication process was
successful. If not it is an indication of the problem.
authKey
The secret key to be used by the authentication algorithm.
The length of this key MUST be 16 octets.
authParameters
The authParameters from the incoming message.
wholeMsg
The message to be authenticated on input and the authenticated
message on output.
authenticatedWholeMsg
The whole message after the authentication check is complete.
認証過程がうまくいったかどうかstatusInformation Anしるし。 それでないなら、認証アルゴリズムによって. 問題authKeyのしるしは使用されているために主要な秘密ですか? このキーの長さは. 入力メッセージwholeMsgからの16の八重奏authParameters authParametersが入力のときに認証されるべきメッセージと出力に関する認証されたメッセージであったなら完全でなければなりません。認証の後の全体のメッセージがチェックする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 [RFC1906], of an OCTET
STRING containing 12 zero octets.
1) msgAuthenticationParameters分野は連載に設定されます、[RFC1906]の規則に従って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
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
a)は、追加することによって、authKeyを64の八重奏まで広げています。48 八重奏のゼロを合わせてください。 それを保存する、extendedAuthKey b) 八重奏0x36 64回模写することによって、IPADを入手してください。 c) XORing extendedAuthKeyはIPADと共にK1を入手してください。 d) 64回八重奏0x5Cを模写することによって、OPADを入手してください。 e) OPADと共にXORing extendedAuthKeyでケーツーを得てください。
4) Prepend K1 to the wholeMsg and calculate MD5 digest over it
according to [MD5].
4) そして、wholeMsgへのPrepend K1、[MD5]に従ってMD5がそれの上で読みこなすと見込んでください。
5) Prepend K2 to the result of the step 4 and calculate MD5 digest
over it according to [MD5]. Take the first 12 octets of the final
digest - this is Message Authentication Code (MAC).
5) ステップ4の結果にケーツーをPrependして、[MD5]に従ってMD5がそれの上で読みこなすと見込みます。 最終的なダイジェストの最初の12の八重奏を取ってください--これはメッセージ立証コード(MAC)です。
6) Replace the msgAuthenticationParameters field with MAC obtained
in the step 5.
6) msgAuthenticationParameters分野をステップ5で入手されたMACに取り替えてください。
Blumenthal & Wijnen Standards Track [Page 49] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[49ページ]RFC2274USM
7) The authenticatedWholeMsg is then returned to the caller
together with statusInformation indicating success.
7) そして、成功を示す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
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
a)は、追加することによって、authKeyを64の八重奏まで広げています。48 八重奏のゼロを合わせてください。 それを保存する、extendedAuthKey b) 八重奏0x36 64回模写することによって、IPADを入手してください。 c) XORing extendedAuthKeyはIPADと共にK1を入手してください。 d) 64回八重奏0x5Cを模写することによって、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;
b) prepend K2 to the result of step 5.a and calculate the
MD5 digest over it;
c) first 12 octets of the result of step 5.b is the MAC.
そして、wholeMsgへのa)prepend K1、それの上でMD5ダイジェストについて計算してください。 b)は、ステップ5.aの結果にケーツーをprependして、それの上でMD5ダイジェストについて計算します。 c) まず最初に、ステップ5.bの結果の12の八重奏がMACです。
The msgAuthenticationParameters field is replaced with the MAC
value that was saved in step 2.
msgAuthenticationParameters野原をステップ2で節約されたMAC値に取り替えます。
6) Then the newly calculated MAC is compared with the MAC
saved in step 2. If they do not match, then an failure and an
errorIndication (authenticationFailure) is returned to the
calling module.
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 50] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[50ページ]RFC2274USM
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
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.
メッセージの保全は、メッセージの適切な部分に関してダイジェストを計算することによって、保護されます。 ダイジェストは、メッセージで送られたメッセージの創始者によって計算されて、メッセージの受取人によって確かめられます。
- 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]を見てください)。 また、それは先端を切られるのにメッセージ立証コードとして使用されるハッシュ関数出力を推薦します。
Blumenthal & Wijnen Standards Track [Page 51] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[51ページ]RFC2274USM
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 [RFC2271]).
認証されたメッセージに含まれたmsgAuthoritativeEngineID値はその特定のメッセージに正式のSNMPエンジンを指定します(SNMP Architectureドキュメント[RFC2271]の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 52] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[52ページ]RFC2274USM
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.
authKey
The secret key to be used by the authentication algorithm.
The length of this key MUST be 20 octets.
wholeMsg
The message to be authenticated.
認証過程がうまくいったかどうかstatusInformation Anしるし。 それでないなら、認証アルゴリズムによって. 問題authKeyのしるしは使用されているために主要な秘密ですか? このキーの長さは20の八重奏wholeMsgが認証されるべきメッセージであったならそうしなければなりません。
Blumenthal & Wijnen Standards Track [Page 53] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[53ページ]RFC2274USM
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.
authKey
The secret key to be used by the authentication algorithm.
The length of this key MUST be 20 octets.
authParameters
The authParameters from the incoming message.
wholeMsg
The message to be authenticated on input and the authenticated
message on output.
authenticatedWholeMsg
The whole message after the authentication check is complete.
認証過程がうまくいったかどうかstatusInformation Anしるし。 それでないなら、認証アルゴリズムによって. 問題authKeyのしるしは使用されているために主要な秘密ですか? このキーの長さは. 入力メッセージwholeMsgからの20の八重奏authParameters authParametersが入力のときに認証されるべきメッセージと出力に関する認証されたメッセージであったなら完全でなければなりません。認証の後の全体のメッセージがチェックするauthenticatedWholeMsgは完全です。
7.3. Elements of Procedure
7.3. 手順のElements
This section describes the procedures for the HMAC-SHA-96 authentication protocol.
このセクションはHMAC-SHA-96認証プロトコルのために手順について説明します。
Blumenthal & Wijnen Standards Track [Page 54] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[54ページ]RFC2274USM
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 [RFC1906], of an OCTET
STRING containing 12 zero octets.
1) msgAuthenticationParameters分野は連載に設定されます、[RFC1906]の規則に従って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
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
a)は、追加することによって、authKeyを64の八重奏まで広げています。44 八重奏のゼロを合わせてください。 それを保存する、extendedAuthKey b) 八重奏0x36 64回模写することによって、IPADを入手してください。 c) XORing extendedAuthKeyはIPADと共にK1を入手してください。 d) 64回八重奏0x5Cを模写することによって、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エンジンについて説明します。
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が八重奏のゼロに合っているということです。
Blumenthal & Wijnen Standards Track [Page 55] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[55ページ]RFC2274USM
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
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
a)は、追加することによって、authKeyを64の八重奏まで広げています。44 八重奏のゼロを合わせてください。 それを保存する、extendedAuthKey b) 八重奏0x36 64回模写することによって、IPADを入手してください。 c) XORing extendedAuthKeyはIPADと共にK1を入手してください。 d) 64回八重奏0x5Cを模写することによって、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;
b) prepend K2 to the result of step 5.a and calculate the
SHA digest over it;
c) first 12 octets of the result of step 5.b is the MAC.
そして、wholeMsgへのa)prepend K1、それの上でSHAダイジェストについて計算してください。 b)は、ステップ5.aの結果にケーツーをprependして、それの上でSHAダイジェストについて計算します。 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を訪問者に返します。
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が暗号化される必要があるメッセージの部分であると指定します。
Blumenthal & Wijnen Standards Track [Page 56] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[56ページ]RFC2274USM
- 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の全面をテストするように設計されていて、特定の問題を正確に指摘することの役に立ちます。
- 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として使用されます。
Blumenthal & Wijnen Standards Track [Page 57] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[57ページ]RFC2274USM
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. 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との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分野に置かなければなりません。
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は前のブロックの暗号文の代わりに使用されます。
Blumenthal & Wijnen Standards Track [Page 58] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[58ページ]RFC2274USM
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 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.
このSymmetric Encryptionプロトコルを使用するデータアン/復号化がuserNamesの定義されたセットを利用します。 メッセージがに代わっているに違いないどんなユーザに関してはも、そのSNMPエンジンには、特定のSNMPエンジンでアン/解読されて、そのユーザに関する知識がなければなりません。 また、別のSNMPエンジンとコミュニケートしたがっているSNMPエンジンで、そのSNMPエンジンにユーザに関する知識を知らなければなりません、そのユーザの適切な属性に関する知識を含んでいて。
A user and its attributes are defined as follows:
ユーザとその属性は以下の通り定義されます:
<userName>
An octet string representing the name of the user.
<privKey>
A user's secret key to be used as input for the DES key and IV.
The length of this key MUST be 16 octets.
ユーザの名前を表す<userName>An八重奏ストリング。 <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 [RFC2271]).
認証されたメッセージに含まれたmsgAuthoritativeEngineID値はその特定のメッセージに正式のSNMPエンジンを指定します(SNMP Architectureドキュメント[RFC2271]のSnmpEngineIDの定義を見てください)。
Blumenthal & Wijnen Standards Track [Page 59] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[59ページ]RFC2274USM
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を返します。 抽象的なサービス基関数は以下の通りです。
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.
encryptKey
The secret key to be used by the encryption algorithm.
The length of this key MUST be 16 octets.
dataToEncrypt
The data that must be encrypted.
encryptedData
The encrypted data upon successful completion.
暗号化プロセスの成否のstatusInformation Anしるし。 失敗の場合には、それは. 秘密が暗号化アルゴリズムで使用されるために合わせる誤りencryptKeyのしるしです。 このキーの長さが16の八重奏dataToEncryptが暗号化しなければならないデータであったならそうしなければならない、encryptedData、無事終了に関する暗号化されたデータ。
Blumenthal & Wijnen Standards Track [Page 60] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[60ページ]RFC2274USM
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のための秘密鍵))
The abstract data elements are:
抽象的なデータ要素は以下の通りです。
statusInformation
An indication whether the data was successfully decrypted
and if not an indication of the error.
decryptKey
The secret key to be used by the decryption algorithm.
The length of this key MUST be 16 octets.
privParameters
The "salt" to be used to calculate the IV.
encryptedData
The data to be decrypted.
decryptedData
The decrypted data.
秘密が、データが首尾よく解読されて. 誤りdecryptKeyのしるしでないなら復号化アルゴリズムで使用されるのを合わせるというstatusInformation An指示。 このキーの長さは16の八重奏IVについて計算するのに使用されるべき「塩からさ」privParameters encryptedDataが. 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 (as described in section 8.1.1.1).
1) 秘密のcryptKeyは、DES暗号化キー、「塩」、およびDESプレIVを組み立てるのに使用されます(セクション8.1.1で.1について説明するので)。
Blumenthal & Wijnen Standards Track [Page 61] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[61ページ]RFC2274USM
2) The privParameters field is set to the serialization according
to the rules in [RFC1906] of an OCTET STRING representing the the
"salt" string.
2) privParameters分野は「塩」ストリングを表すOCTET STRINGの[RFC1906]の規則に従った連載へのセットです。
3) The scopedPDU is encrypted (as described in section 8.1.1.2)
and the encrypted data is serialized according to the rules in
[RFC1906] as an OCTET STRING.
3) scopedPDUは暗号化されています、そして、(セクション8.1.1で.2について説明するので)[RFC1906]の規則に従って、暗号化されたデータは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を呼ぶモジュールに返します。
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 (as described in section 8.1.1.1).
3) そして、秘密のcryptKeyと「塩」は、DES復号化キーとプレ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
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 公表に利用可能にされた権利のクレームと利用可能に作られるべきライセンスのどんな保証か、された試みの結果もコピーされます。
Blumenthal & Wijnen Standards Track [Page 62] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[62ページ]RFC2274USM
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事務局からこの仕様のユーザを得ることができます。
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専務に情報を扱ってください。
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メンバー:
Dave Battle (SNMP Research, Inc.)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
T. Max Devlin (Hi-TECH Connections)
John Flick (Hewlett Packard)
David Harrington (Cabletron Systems Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Russ Mundy (Trusted Information Systems, Inc.)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reid (SNMP Research, Inc.)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Bert Wijnen (IBM T.J. Watson Research Center)
デーヴBattle(SNMP研究Inc.) ユリ・ブルーメンソル(IBM T.J.ワトソン研究所) ジェフCase(SNMP研究Inc.) ジョン・カラン(BBN)・T.マックス・デブリン(高科学技術のコネクションズ)・ジョン・軽打(ヒューレットパッカード)デヴィッド・ハリントン(CabletronシステムInc.) ノースカロライナ州Hien(IBM T.J.ワトソン研究所) デーヴ・レビ(SNMP研究Inc.) ルイスはMamakos(UUNET技術Inc.)です。 ポール・マイヤー(安全なコンピューティング社)キースMcCloghrie(シスコシステムズ)ラス・マンディ(情報システムInc.を信じます) ボブNatale(ACE*COMM社)マイク・オデル(UUNET技術Inc.) デーヴ・パーキンス(DeskTalk)・ピーター・ポーキングホーン(Brunel大学)ランディPresuhn(BMCソフトウェアInc.) デヴィッド・リード(SNMP研究Inc.) ショーンRouthier(エピローグ)ユルゲンSchoenwaelder(TUブラウンシュバイク)ボブ・スチュワート(シスコシステムズ)バートWijnen(IBM T.J.ワトソン研究所)
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)
デヴィッド・ハリントン(CabletronシステムInc.) ジェフ・ジョンソン(シスコシステムズ)・デヴィッド・レビ(SNMP研究Inc.) ジョン・リン(Openvision)
Blumenthal & Wijnen Standards Track [Page 63] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[63ページ]RFC2274USM
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
ラス・マンディ(情報システムを信じる)いすショーン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 PDU
for which there is no currently outstanding Request PDU; for
example for SNMPv2 [RFC1905] PDUs, the request-id component in the
PDU can be used to correlate Responses to outstanding Requests.
SNMP Command Generator Applicationはどんな現在傑出しているRequest PDUもないどんなResponse PDUも捨てなければなりません。 例えば、SNMPv2[RFC1905]PDUsに関しては、傑出しているRequestsにResponsesを関連させるのにPDUの要求イドコンポーネントを使用できます。
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を使用しなければなりません。
Blumenthal & Wijnen Standards Track [Page 64] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[64ページ]RFC2274USM
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 [RFC1907], is
specifically defined for use with SNMP Set operations in order to
provide a mechanism to ensure that the processing of SNMP messages
occurs in a specific order.
しかしながら、SNMPメッセージの処理が特定の順序で起こるのを保証するためにメカニズムを提供して、管理オブジェクト(snmpSetSerialNo[RFC1907])は使用のためにSNMP Set操作で明確に定義されます。
- The frequency with which the secrets of a User-based Security
Model user should be changed is indirectly related to the frequency
of their use.
- 頻度は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.
公開から秘密を保護するのはプロトコルの総合的なセキュリティに重要です。 秘密の頻繁な使用は弱点であると知られているか、または知覚された利用でアルゴリズムで暗号解読者の役に立つかもしれないデータの継続的な源を提供します。 秘密への頻繁な変化はこの脆弱性を避けます。
Blumenthal & Wijnen Standards Track [Page 65] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[65ページ]RFC2274USM
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 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 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.
付録Aは使用のためにユーザの認証キーかプライバシーキー(ともに)のどちらかとしてユーザ「パスワード」を16八重奏価値に写像するためのアルゴリズムを説明します。 しかしながら、認証とプライバシーの両方に、同じパスワード(そして、したがって、同じキー)を使用するのが、非常に貧しいセキュリティであることが練習して、強くがっかりするべきであることに注意してください。 パスワードは、人間によってしばしば生成されて、覚えていられて、入力されます。 人間が発生しているパスワードは16の八重奏が認証、プライバシープロトコル、およびブルートフォースアタックで必要とした以下が比較的短いASCII文字の組でかなり簡単である場合があるということであるかもしれません。 したがって、アルゴリズムはAppendix Aがパスワードに変換を実行するということです。 Appendix Aアルゴリズムが使用されているなら、SNMP実装(そして、SNMP構成アプリケーション)は、パスワードが長さが少なくとも8つのキャラクタであることを確実にしなければなりません。
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
人間のユーザがあらゆるSNMPエンジンのための異なったパスワードを維持するのが、実行不可能ですが、セキュリティ要件が1台以上のSNMPエンジンに主要な状態で有を強く同じようにがっかりさせるので、UserベースのSecurity Modelは[ローカライズしているキー]で提案された感染を使います。 それはSNMPのためのキーが蒸気機関を備えているユーザを引き出します。
Blumenthal & Wijnen Standards Track [Page 66] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[66ページ]RFC2274USM
user's password in such a way that it is practically impossible to either determine the user's password, or user's key for another SNMP engine from any combination of user's keys on SNMP engines.
別のSNMPエンジンのためにSNMPエンジンにおけるユーザのキーのどんな組み合わせからもユーザのパスワード、またはユーザのキーを決定するのが実際に不可能であるような方法によるユーザのパスワード。
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つである)の実装は任意です。
12. References
12. 参照
[RFC1321] Rivest, R., "Message Digest Algorithm MD5",
RFC 1321, April 1992.
[RFC1321] Rivest、R.、「メッセージダイジェストアルゴリズムMD5"、RFC1321、1992年4月。」
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1903] ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
Blumenthal & Wijnen Standards Track [Page 67] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[67ページ]RFC2274USM
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1906]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[RFC1907] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Management Information Base for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1907 January 1996.
[RFC1907]ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための管理情報ベース」、RFC1907 1996年1月。
[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月。
[RFC2028] Hovey, R., and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC2028] ハービ、R.、およびS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。
[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月。
[RFC2271] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for describing SNMP Management Frameworks", RFC 2271,
January 1998.
1998年1月の[RFC2271]ハリントンとD.とPresuhn、R.とB.Wijnen、「SNMP Management Frameworksについて説明するためのArchitecture」RFC2271。
[RFC2272] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC 2272, January 1998.
[RFC2272] ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2272、1998年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-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)に取って代わります。
[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-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月。)
[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)
NBSデータ暗号化規格、米国商務省標準技術局を実装して、使用するための[DESG-NIST]ガイドライン。 連邦情報処理基準(FIPS)
Blumenthal & Wijnen Standards Track [Page 68] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[68ページ]RFC2274USM
Publication 74, (April, 1981).
公表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月。)
[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 (追伸)
13. Editors' Addresses
13. エディタのアドレス
Uri Blumenthal IBM T. J. Watson Research 30 Saw Mill River Pkwy, Hawthorne, NY 10532 USA
ユリブルーメンソルIBMのT.J.ワトソン研究30は工場川のPkwy、ホーソーン、ニューヨーク10532米国を見ました。
EMail: uri@watson.ibm.com Phone: +1-914-784-7064
メール: uri@watson.ibm.com 電話: +1-914-784-7064
Bert Wijnen IBM T. J. Watson Research Schagen 33 3461 GL Linschoten Netherlands
バートWijnen IBM T.J.ワトソン研究Schagen33 3461GLリンスホーテン・オランダ
EMail: wijnen@vnet.ibm.com Phone: +31-348-432-794
メール: wijnen@vnet.ibm.com 電話: +31-348-432-794
Blumenthal & Wijnen Standards Track [Page 69] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[69ページ]RFC2274USM
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 [MD5]. The resulting digest, termed "digest1", is used
in the next step.
- 必要で、先端を切るのと同じくらい頻繁にそれに従って、パスワードの値を繰り返すことによって一連の長さの104万8576八重奏を形成して、入力としてMD5アルゴリズム[MD5]に結果として起こるストリングを使用します。 「digest1"は次のステップで使用されている」と呼ばれた結果として起こるダイジェスト。
- a second string is formed by concatenating digest1, the SNMP
engine's snmpEngineID value, and digest1. This string is used as
input to the MD5 algorithm [MD5].
- 2番目のストリングは、SNMPエンジンのdigest1、snmpEngineID値、およびdigest1を連結することによって、形成されます。 このストリングはMD5アルゴリズム[MD5]に入力されるように使用されています。
The resulting digest is the required secret (see Appendix A.2).
結果として起こるダイジェストは必要な秘密(Appendix A.2を見る)です。
With these configured parameters, the SNMP engine instantiates the following usmUserEntry in the usmUserTable:
これらの構成されたパラメタで、SNMPエンジンはusmUserTableに以下のusmUserEntryを例示します:
Blumenthal & Wijnen Standards Track [Page 70] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[70ページ]RFC2274USM
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のアクティブな能動態」
A.2. Password to Key Algorithm
A.2。 主要なアルゴリズムへのパスワード
A sample code fragment (section A.2.1) demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key using MD5. The reference source code of MD5 is available in [RFC1321].
サンプルコード断片(セクションA.2.1)はMD5を使用することで認証かプライバシーキーにパスワードを写像するとき使用できる主要なアルゴリズムにパスワードを示します。 MD5の照合線源コードは[RFC1321]で利用可能です。
Another sample code fragment (section A.2.2) demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key using SHA (documented in SHA- NIST).
別のサンプルコード断片(セクションA.2.2)はSHA(SHA- NISTに記録される)を使用することで認証かプライバシーキーにパスワードを写像するとき使用できる主要なアルゴリズムにパスワードを示します。
An example of the results of a correct implementation is provided (section A.3) which an implementor can use to check if his implementation produces the same result.
作成者が彼の実装が同じ結果を生むかどうかチェックするのに使用できる(セクションA.3)に正しい実装の結果に関する例を提供します。
A.2.1. Password to Key Sample Code for MD5
A.2.1。 MD5に、主要なサンプルコードへのパスワード
void password_to_key_md5(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *engineID, /* IN - pointer to snmpEngineID */
u_int engineLength /* IN - length of snmpEngineID */
u_char *key) /* OUT - pointer to caller 16-octet buffer */
{
MD5_CTX MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;
欠如..パスワード..主要..炭..パスワード..炭..指針..長さ..炭..キー..指針..訪問者..八重奏..バッファリング..炭..パスワード..長い..パスワード..インデックス..長い..カウント..等しい
MD5Init (&MD); /* initialize MD5 */
MD5Init(MD)。 /*はMD5*/を初期化します。
Blumenthal & Wijnen Standards Track [Page 71] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[71ページ]RFC2274USM
/**********************************************/
/* 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); /*は、*/を私たちにするとMD5に言います。
/*****************************************************/ /* 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+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(パスワード_buf+16、engineID、engineLength)。 memcpy(パスワード_buf+engineLength、キー、16)。
MD5Init(&MD); MD5Update(&MD, password_buf, 32+engineLength); MD5Final(key, &MD);
MD5Init(MD)。 MD5Update(MD、パスワード_buf、32+engineLength)。 MD5Final(キー、およびMD)。
return; }
戻ってください。 }
A.2.2. Password to Key Sample Code for SHA
A.2.2。 SHAに、主要なサンプルコードへのパスワード
void password_to_key_sha(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *engineID, /* IN - pointer to snmpEngineID */
u_int engineLength /* IN - length of snmpEngineID */
u_char *key) /* OUT - pointer to caller 20-octet buffer */
{
SHA_CTX SH;
u_char *cp, password_buf[72];
u_long password_index = 0;
u_long count = 0, i;
欠如..パスワード..主要..炭..パスワード..炭..ポインタ..長さ..炭..キー..ポインタ..訪問者..八重奏..バッファリング..炭..パスワード..長い..パスワード..インデックス..長い..カウント..等しい
Blumenthal & Wijnen Standards Track [Page 72] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[72ページ]RFC2274USM
SHAInit (&SH); /* initialize SHA */
SHAInit(SH)。 /*は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); /*は、*/を私たちにするとSHAに言います。
/*****************************************************/ /* 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+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(パスワード_buf+20、engineID、engineLength)。 memcpy(パスワード_buf+engineLength、キー、20)。
SHAInit(&SH); SHAUpdate(&SH, password_buf, 40+engineLength); SHAFinal(key, &SH);
SHAInit(SH)。 SHAUpdate(SH、パスワード_buf、40+engineLength)。 SHAFinal(キー、およびSH)。
return; }
戻ってください。 }
A.3. Password to Key Sample Results
A.3。 主要なサンプル結果へのパスワード
A.3.1. Password to Key Sample Results using MD5
A.3.1。 MD5を使用する主要なサンプル結果へのパスワード
The following shows a sample output of the password to key algorithm for a 16-octet key using MD5.
サンプルが出力したMD5を使用する16八重奏のキーのための主要なアルゴリズムへのパスワードの以下のショー。
With a password of "maplesyrup" the output of the password to key algorithm before the key is localized with the SNMP engine's snmpEngineID is:
"maplesyrup"に関するパスワードで、キーがSNMPエンジンのsnmpEngineIDと共に局所化される前に主要なアルゴリズムへのパスワードの出力は以下の通りです。
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
'9f af32 83 88 4e92 83 4e bc98 47d8教育d9 63'H
Blumenthal & Wijnen Standards Track [Page 73] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[73ページ]RFC2274USM
After the intermediate key (shown above) is localized with the snmpEngineID value of:
中間介在物の後に、キー(上では、目立つ)が以下のsnmpEngineID値で局所化されます。
'00 00 00 00 00 00 00 00 00 00 00 02'H
'00 00 00 00 00 00 00 00 00 00 00 02'H
the final output of the password to key algorithm is:
主要なアルゴリズムへのパスワードの最終産出物は以下の通りです。
'52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H
52年の6f 5e教育9f cc e2 6f89 64c2 93 07 87d8 2b'H'
A.3.2. Password to Key Sample Results using SHA
A.3.2。 SHAを使用する主要なサンプル結果へのパスワード
The following shows a sample output of the password to key
algorithm for a 20-octet key using SHA.
サンプルが出力したSHAを使用する20八重奏のキーのための主要なアルゴリズムへのパスワードの以下のショー。
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:
"maplesyrup"に関するパスワードで、キーがSNMPエンジンのsnmpEngineIDと共に局所化される前に主要なアルゴリズムへのパスワードの出力は以下の通りです。
'f1 be a9 ae 66 7f 4f b6 34 1e 51 af 06 80 7e 91 e4 3b 01 ac'H
'f1、a9 ae66 7f 4f b6 34 1e51af06 80 7e91e4 3b01ac'Hになってください、'
After the intermediate key (shown above) is localized with the snmpEngineID value of:
中間介在物の後に、キー(上では、目立つ)が以下のsnmpEngineID値で局所化されます。
'00 00 00 00 00 00 00 00 00 00 00 02'H
'00 00 00 00 00 00 00 00 00 00 00 02'H
the final output of the password to key algorithm is:
主要なアルゴリズムへのパスワードの最終産出物は以下の通りです。
'8a a3 d9 9e 3e 30 56 f2 bf e3 a9 ee f3 45 d5 39 54 91 12 be'H
'8a a3 d9 9e 3e30 56f2 bf e3 a9 ee f3 45d5 39 54 91 12be'H'
A.4. Sample encoding of msgSecurityParameters
A.4。 msgSecurityParametersのサンプルコード化
The msgSecurityParameters in an SNMP message are represented as an OCTET STRING. This OCTET STRING should be considered opaque outside a specific Security Model.
SNMPメッセージのmsgSecurityParametersはOCTET STRINGとして表されます。 このOCTET STRINGは特定のSecurity Modelの外で不透明であると考えられるべきです。
The User-based Security Model defines the contents of the OCTET STRING as a SEQUENCE (see section 2.4).
UserベースのSecurity ModelはOCTET STRINGのコンテンツをSEQUENCEと定義します(セクション2.4を見てください)。
Given these two properties, the following is an example of the msgSecurityParameters for the User-based Security Model, encoded as an OCTET STRING:
これらの2つの特性を考えて、↓これはOCTET STRINGとしてコード化されたUserベースのSecurity ModelのためのmsgSecurityParametersに関する例です:
04 <length>
30 <length>
04 <length> <msgAuthoritativeEngineID>
02 <length> <msgAuthoritativeEngineBoots>
02 <length> <msgAuthoritativeEngineTime>
04 <length> <msgUserName>
04 <長さの>30<長さの>04<長さの><msgAuthoritativeEngineID>02<長さの><msgAuthoritativeEngineBoots>02<長さ><msgAuthoritativeEngineTime>04の<の長さの><msgUserName>。
Blumenthal & Wijnen Standards Track [Page 74] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[74ページ]RFC2274USM
04 0c <HMAC-MD5-96-digest>
04 08 <salt>
04 0c<HMAC-MD5-96ダイジェストの>04 08<塩の>。
Here is the example once more, but now with real values (except for the digest in msgAuthenticationParameters and the salt in msgPrivacyParameters, which depend on variable data that we have not defined here):
ここに、もう一度にもかかわらずの、現在、実価(可変データに私たちがここで定義していないよるmsgAuthenticationParametersのダイジェストとmsgPrivacyParametersの塩を除いた)がある例があります:
Hex Data Description
-------------- -----------------------------------------------
04 39 OCTET STRING, length 57
30 37 SEQUENCE, length 55
04 0c 80000002 msgAuthoritativeEngineID: IBM
01 IPv4 address
09840301 9.132.3.1
02 01 01 msgAuthoritativeEngineBoots: 1
02 02 0101 msgAuthoritativeEngineTime: 257
04 04 62657274 msgUserName: bert
04 0c 01234567 msgAuthenticationParameters: sample value
89abcdef
fedcba98
04 08 01234567 msgPrivacyParameters: sample value
89abcdef
十六進法データ記述-------------- ----------------------------------------------- 04 39OCTET STRING、長さ57 30 37のSEQUENCE、長さ55 04の0c80000002msgAuthoritativeEngineID: IBM01IPv4は09840301 9.132.3.1 02 01 01 msgAuthoritativeEngineBootsを記述します: 1 02 02 0101msgAuthoritativeEngineTime: 257 04 04 62657274msgUserName: bert04 0c01234567msgAuthenticationParameters: 値の89abcdef fedcba98 04 08 01234567 msgPrivacyParametersを抽出してください: 標本値89abcdef
Blumenthal & Wijnen Standards Track [Page 75] RFC 2274 USM for SNMPv3 January 1998
SNMPv3 January 1998のためのブルーメンソルとWijnen標準化過程[75ページ]RFC2274USM
B. Full Copyright Statement
B。 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Blumenthal & Wijnen Standards Track [Page 76]
ブルーメンソルとWijnen標準化過程[76ページ]
一覧
スポンサーリンク
