Network Working Group D. Harrington
Request for Comments: 5591 Huawei Technologies (USA)
Category: Standards Track W. Hardaker
Cobham Analytic Solutions
June 2009
Transport Security Model for the
Simple Network Management Protocol (SNMP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).
このメモは、簡易ネットワーク管理プロトコル（SNMP）のためのトランスポート・セキュリティモデルについて説明します。
This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP.
また、このメモはSNMPのためのトランスポート・セキュリティモデルを監視し、管理するための管理情報ベース（MIB）の一部を定義します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................4
1.4. Motivation .................................................5
1.5. Constraints ................................................5
2. How the Transport Security Model Fits in the Architecture .......6
2.1. Security Capabilities of this Model ........................6
2.1.1. Threats .............................................6
2.1.2. Security Levels .....................................7
2.2. Transport Sessions .........................................7
2.3. Coexistence ................................................7
2.3.1. Coexistence with Message Processing Models ..........7
2.3.2. Coexistence with Other Security Models ..............8
2.3.3. Coexistence with Transport Models ...................8
3. Cached Information and References ...............................8
3.1. Transport Security Model Cached Information ................9
3.1.1. securityStateReference ..............................9
3.1.2. tmStateReference ....................................9
3.1.3. Prefixes and securityNames ..........................9
4. Processing an Outgoing Message .................................10
4.1. Security Processing for an Outgoing Message ...............10
4.2. Elements of Procedure for Outgoing Messages ...............11
5. Processing an Incoming SNMP Message ............................12
5.1. Security Processing for an Incoming Message ...............12
5.2. Elements of Procedure for Incoming Messages ...............13
6. MIB Module Overview ............................................14
6.1. Structure of the MIB Module ...............................14
6.1.1. The snmpTsmStats Subtree ...........................14
6.1.2. The snmpTsmConfiguration Subtree ...................14
6.2. Relationship to Other MIB Modules .........................14
6.2.1. MIB Modules Required for IMPORTS ...................15
7. MIB Module Definition ..........................................15
8. Security Considerations ........................................20
8.1. MIB Module Security .......................................20
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
Appendix A. Notification Tables Configuration ....................24
A.1. Transport Security Model Processing for Notifications .....25
Appendix B. Processing Differences between USM and Secure
Transport ............................................26
B.1. USM and the RFC 3411 Architecture .........................26
B.2. Transport Subsystem and the RFC 3411 Architecture .........27
This memo describes a Transport Security Model for the Simple Network Management Protocol for use with secure Transport Models in the Transport Subsystem [RFC5590].
このメモは輸送サブシステム[RFC5590]で安全な輸送モデルで使用するための簡易ネットワーク管理プロトコルのためのトランスポート・セキュリティモデルについて説明します。
This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP.
また、このメモはSNMPのためのトランスポート・セキュリティモデルを監視し、管理するための管理情報ベース（MIB）の一部を定義します。
It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Transport Security Model described in this memo fits into the architecture and interacts with other subsystems and models within the architecture. It is expected that readers will have also read and understood [RFC3411], [RFC3412], [RFC3413], and [RFC3418].
このメモで説明した転送セキュリティモデルは、アーキテクチャに適合し、アーキテクチャ内の他のサブシステムやモデルと対話するかを理解するためにSNMPアーキテクチャとアーキテクチャの専門用語を理解することが重要です。読者も読み、[RFC3411]、[RFC3412]、[RFC3413]及び[RFC3418]を理解しているであろうことが予想されます。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準の管理フレームワークを記述したドキュメントの詳細な概要については、RFC 3410 [RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベースまたはMIBと呼ばれます。 MIBオブジェクトは、一般的に簡易ネットワーク管理プロトコル（SNMP）を介してアクセスされます。 MIBのオブジェクトは、管理情報（SMI）の構造で定義されたメカニズムを使用して定義されています。このメモは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]とSTD 58、RFC 2580 [RFC2580]に記載されているSMIv2のに準拠しているMIBモジュールを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Lowercase versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context that relates to compatibility with the RFC 3411 architecture or the subsystem defined here but that might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage.
キーワードの小文字バージョンは、通常、英語のように読まれるべきです。彼らは通常、常にではないが、RFC 3411のアーキテクチャや、ここで定義されたサブシステムとの互換性のためにそれがオン・ワイヤーの互換性に影響を与えないかもしれない関係のコンテキストで使用されます。これらの用語は、RFC 3411個のサブシステムと抽象サービスインターフェイス（ASIを）とデザインが両立させるために提案されているIETFモデルのデザイナーのための指針として使用されています。実装者は、異なる自由に実装できます。これらの小文字の用語のいくつかの用途は、単に通常の英語の使用状況です。
For consistency with SNMP-related specifications, this document favors terminology as defined in STD 62, rather than favoring terminology that is consistent with non-SNMP specifications that use different variations of the same terminology. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard.
むしろ同じ用語の異なるバリエーションを使用する非SNMP仕様と一致している用語を好むより、STD 62で定義されるようにSNMP関連の仕様に一貫性のために、この文書は用語を好みます。これは、SNMPv3のは、全規格に進められたときのSNMPv3の用語は、他の非SNMP仕様の使用を一致するように変更する必要がないためにIESGの決定と一致しています。
Authentication in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication.
この文書の認証は、通常のメッセージではなく、データソース認証またはピアのアイデンティティ認証「の信憑性を証明するのに役立つ」の英語の意味を指します。
The terms "manager" and "agent" are not used in this document because, in the RFC 3411 architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP applications included in the engine. Where distinction is needed, the application names of command generator, command responder, notification originator, notification receiver, and proxy forwarder are used. See "Simple Network Management Protocol (SNMP) Applications" [RFC3413] for further information.
RFC 3411のアーキテクチャでは、すべてのSNMPエンティティは、アプリケーションがエンジンに含まSNMPマネージャに応じて、エージェント、またはその両方として作用する能力を有している、ので、用語「マネージャ」と「エージェント」は、本文書で使用されていません。区別が必要な場合、コマンド生成、コマンド応答、通知発信、通知受信、およびプロキシフォワーダのアプリケーション名が使用されています。詳細については、「簡易ネットワーク管理プロトコル（SNMP）アプリケーション」[RFC3413]を参照してください。
While security protocols frequently refer to a user, the terminology used in [RFC3411] and in this memo is "principal". A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role, a set of individuals each acting in a particular role, an application or a set of applications, or a combination of these within an administrative domain.
セキュリティプロトコルが頻繁にユーザーを参照しながら、[RFC3411]にし、このメモで使用される用語は、「主」です。校長は、「誰が」その代理としてサービスを提供しているか、処理には行われています。校長は、とりわけ、特定のロール内の個々の演技、それぞれ特定の役割は、アプリケーションまたはアプリケーションのセット、または管理ドメイン内のこれらの組み合わせで働く個人の集合とすることができます。
The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411], and the architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590], which enables the use of external "lower-layer transport" protocols to provide message security. Transport Models are tied into the SNMP architecture through the Transport Subsystem. The Transport Security Model is designed to work with such lower-layer, secure Transport Models.
読者は[RFC3411]で定義されるように、読み取りおよびSNMPアーキテクチャの説明を理解していると予想されており、使用することを可能に[RFC5590]、「簡易ネットワーク管理プロトコル（SNMP）のための輸送サブシステム」に指定されたアーキテクチャの拡張メッセージセキュリティを提供するために、外部の「下位層のトランスポート」プロトコルの。輸送モデルは、交通サブシステムを通じてSNMPアーキテクチャに接続されています。交通セキュリティモデルは、下位層、安全な輸送モデルで動作するように設計されています。
In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects that are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD NOT be referenced in other documents. This allows the Transport Security Model to be designed and documented as independent and self-contained, having no direct impact on other modules. It also allows this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules.
自己完結型のドキュメントを使用するRFC 3411の設計上の決定を踏まえて、このメモは、手順の要素を加えたSNMPのためのトランスポート・セキュリティモデルを処理するために必要な関連するMIBオブジェクトが含まれています。これらのMIBオブジェクトは、他のドキュメントで参照することはできません。これは、他のモジュールに直接影響を与えていない、交通セキュリティモデルは、独立した自己完結型として設計し、文書化することができます。また、必要に応じて、このモジュールをアップグレードして補完することができ、かつ他のモジュールから異なる時間ライン上で追跡基準に沿って移動します。
This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation.
仕様のこのモジュールは、実装上の任意の特定の要件を課すものと解釈されるものではありません。
This memo describes a Security Model to make use of Transport Models that use lower-layer, secure transports and existing and commonly deployed security infrastructures. This Security Model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success, and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible.
このメモは、下位層、セキュアなトランスポートと既存のと、一般的に展開されたセキュリティ・インフラストラクチャを使用して輸送モデルを利用するためにセキュリティモデルについて説明します。このセキュリティモデルは、ネットワーク管理者のセキュリティと運用上のニーズを満たす高の展開の成功を達成するための運用環境での使いやすさを最大化し、同時に展開が可能になるまでの時間を最小限にするために、実装および導入コストを最小限に抑えるように設計されています。
The design of this SNMP Security Model is also influenced by the following constraints:
このSNMPセキュリティモデルの設計は、以下の制約によって影響されます。
1. In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend solely upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols).
ネットワークストレス、セキュリティプロトコルとその基盤となるセキュリティメカニズムの時代に1.他のネットワークサービス（例えば、ネットワーク・タイム・プロトコル（NTP）または認証、許可、およびアカウンティング（AAA）プロトコル）が容易に入手できる時にのみ依存すべきではありません。
2. When the network is not under stress, the Security Model and its underlying security mechanisms MAY depend upon the ready availability of other network services.
ネットワークに負荷がかかっていない場合2.セキュリティモデルとその基盤となるセキュリティメカニズムは、他のネットワークサービスの入手しやすさに依存してもよいです。
3. It might not be possible for the Security Model to determine when the network is under stress.
ネットワークに負荷がかかっているとき、セキュリティモデルが決定するため3.それは可能ではないかもしれません。
4. A Security Model SHOULD NOT require changes to the SNMP architecture.
4. Aセキュリティモデルは、SNMPアーキテクチャへの変更を要求すべきではありません。
5. A Security Model SHOULD NOT require changes to the underlying security protocol.
5. Aセキュリティモデルは、基本的なセキュリティプロトコルへの変更を要求すべきではありません。
The Transport Security Model is designed to fit into the RFC 3411 architecture as a Security Model in the Security Subsystem and to utilize the services of a secure Transport Model.
交通セキュリティモデルは、セキュリティサブシステムのセキュリティモデルとしてRFC 3411のアーキテクチャに適合し、安全な輸送モデルのサービスを利用するように設計されています。
For incoming messages, a secure Transport Model will pass a tmStateReference cache, described in [RFC5590]. To maintain RFC 3411 modularity, the Transport Model will not know which securityModel will process the incoming message; the Message Processing Model will determine this. If the Transport Security Model is used with a non-secure Transport Model, then the cache will not exist or will not be populated with security parameters, which will cause the Transport Security Model to return an error (see Section 5.2).
受信メッセージの場合は、安全な輸送モデルは[RFC5590]で説明tmStateReferenceキャッシュを、渡します。 RFC 3411モジュール性を維持するために、輸送モデルはsecurityModelが着信メッセージを処理するかわからないだろう。メッセージ処理モデルはこれを決定します。交通セキュリティモデルは、非セキュア輸送モデルで使用されている場合は、キャッシュが存在しないか、トランスポート・セキュリティモデルは（5.2節を参照してください）エラーを返すようになりますセキュリティパラメータ、移入されることはありません。
The Transport Security Model will create the securityName and securityLevel to be passed to applications, and will verify that the tmTransportSecurityLevel reported by the Transport Model is at least as strong as the securityLevel requested by the Message Processing Model.
交通セキュリティモデルは、アプリケーションに渡されるセキュリティ名とたsecurityLevelを作成し、輸送モデルによって報告tmTransportSecurityLevelは、メッセージ処理モデルによって要求されたsecurityLevelと少なくとも同じ強力であることを確認します。
For outgoing messages, the Transport Security Model will create a tmStateReference cache (or use an existing one), and will pass the tmStateReference to the specified Transport Model.
送信メッセージの場合は、トランスポート・セキュリティモデルは、tmStateReferenceキャッシュを作成します（または既存のものを使用）、および指定された輸送モデルにtmStateReferenceを渡します。
The Transport Security Model is compatible with the RFC 3411 architecture and provides protection against the threats identified by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself. Which threats are addressed and how they are mitigated depends on the Transport Model used. To avoid creating potential security vulnerabilities, operators should configure their system so this Security Model is always used with a Transport Model that provides appropriate security, where "appropriate" for a particular deployment is an administrative decision.
交通セキュリティモデルは、RFC 3411のアーキテクチャと互換性があり、RFC 3411アーキテクチャによって識別された脅威に対する保護を提供します。しかし、トランスポート・セキュリティモデルは、認証と暗号化自体などのセキュリティメカニズムを提供しません。どの脅威に対処されており、それらがどのように軽減されて使用されるトランスポートモデルに依存します。このセキュリティモデルは、常に特定の展開のための「適切な」は行政決定である適切なセキュリティを提供し、輸送モデルで使用されるように、潜在的なセキュリティの脆弱性を作成しないように、事業者は、システムを構成する必要があります。
The RFC 3411 architecture recognizes three levels of security:
RFC 3411アーキテクチャは、3つのセキュリティレベルを認識します。
- without authentication and without privacy (noAuthNoPriv)
- 認証なしとプライバシーなし（noAuthNoPrivという）
- with authentication but without privacy (authNoPriv)
- 認証ではなく、プライバシーなし（authNoPriv）
- with authentication and with privacy (authPriv)
- 認証を用いるとプライバシーと（authPrivの）
The model-independent securityLevel parameter is used to request specific levels of security for outgoing messages and to assert that specific levels of security were applied during the transport and processing of incoming messages.
モデルに依存したsecurityLevelパラメータは、送信メッセージのセキュリティの特定のレベルを要求すると、セキュリティの特定のレベルは、着信メッセージの輸送及び処理の間に適用されたことをアサートするために使用されます。
The transport-layer algorithms used to provide security should not be exposed to the Transport Security Model, as the Transport Security Model has no mechanisms by which it can test whether an assertion made by a Transport Model is accurate.
トランスポート・セキュリティ・モデルは、それが輸送モデル製アサーションが正確であるかどうかをテストすることが可能ないかなる機構を有していないようにセキュリティを提供するために使用されるトランスポート層のアルゴリズムは、トランスポート・セキュリティ・モデルに曝されるべきではありません。
The Transport Security Model trusts that the underlying secure transport connection has been properly configured to support security characteristics at least as strong as reported in tmTransportSecurityLevel.
交通セキュリティモデルは、基礎となる安全なトランスポート接続が正しくtmTransportSecurityLevelで報告されているように、少なくともとして強力なセキュリティ特性をサポートするように設定されていることを信頼しています。
The Transport Security Model does not work with transport sessions directly. Instead the transport-related state is associated with a unique combination of transportDomain, transportAddress, securityName, and securityLevel, and is referenced via the tmStateReference parameter. How and if this is mapped to a particular transport or channel is the responsibility of the Transport Subsystem.
交通セキュリティモデルは、直接トランスポートセッションでは動作しません。代わりに輸送関連状態はtransportDomain、transportAddress、のsecurityName、そしてたsecurityLevelのユニークな組み合わせに関連付けられ、そしてtmStateReferenceパラメータで参照されます。どのように、これは特定のトランスポートまたはチャネルにマッピングされている場合は交通サブシステムの責任です。
In the RFC 3411 architecture, a Message Processing Model determines which Security Model SHALL be called. As of this writing, IANA has registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, SNMPv2c, and the User-based Security Model).
RFC 3411アーキテクチャでは、メッセージ処理モデルは、セキュリティモデルを呼ぶことにするかを決定します。この記事の執筆時点で、IANAは、4つのメッセージ処理モデル（SNMPv1の、SNMPv2cの、SNMPv2u / SNMPv2の*、およびSNMPv3）と3つの他のセキュリティモデル（SNMPv1の、SNMPv2c、およびユーザベースセキュリティモデル）が登録されています。
The SNMPv1 and SNMPv2c message processing described in BCP 74 [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security Models. Since there is no mechanism defined in RFC 3584 to select an
BCP 74 [RFC3584]に記載のSNMPv1およびSNMPv2cのメッセージ処理は、常に、SNMPv1の（1）およびSNMPv2c（2）セキュリティモデルを選択します。 ANを選択するために、RFC 3584で定義されたメカニズムはありませんので
alternative Security Model, SNMPv1 and SNMPv2c messages cannot use the Transport Security Model. Messages might still be able to be conveyed over a secure transport protocol, but the Transport Security Model will not be invoked.
代替セキュリティモデル、SNMPv1およびSNMPv2cのメッセージは、トランスポート・セキュリティモデルを使用することはできません。メッセージはまだ安全なトランスポートプロトコル上で搬送することができる可能性がありますが、交通のセキュリティモデルは呼び出されません。
The SNMPv2u/SNMPv2* Message Processing Model is an historic artifact for which there is no existing IETF specification.
SNMPv2u / SNMPv2の*メッセージ処理モデルは、既存のIETF仕様がありませんそのため、歴史的な成果物です。
The SNMPv3 message processing defined in [RFC3412] extracts the securityModel from the msgSecurityModel field of an incoming SNMPv3Message. When this value is transportSecurityModel(4), security processing is directed to the Transport Security Model. For an outgoing message to be secured using the Transport Security Model, the application MUST specify a securityModel parameter value of transportSecurityModel(4) in the sendPdu Abstract Service Interface (ASI).
[RFC3412]で定義されたSNMPv3のメッセージ処理は、着信SNMPv3MessageのmsgSecurityModelフィールドからsecurityModelを抽出します。この値はtransportSecurityModel（4）である場合には、セキュリティ処理は、交通セキュリティモデルを対象としています。送信メッセージは、トランスポート・セキュリティ・モデルを使用して確保するために、アプリケーションはsendPduアブストラクトサービスインターフェイス（ASI）でtransportSecurityModel（4）のsecurityModelパラメータ値を指定する必要があります。
The Transport Security Model uses its own MIB module for processing to maintain independence from other Security Models. This allows the Transport Security Model to coexist with other Security Models, such as the User-based Security Model (USM) [RFC3414].
処理は、他のセキュリティモデルからの独立性を維持するためにトランスポート・セキュリティモデルは、独自のMIBモジュールを使用しています。これは、トランスポート・セキュリティモデルは、このようなユーザベースセキュリティモデル（USM）[RFC3414]などの他のセキュリティモデル、と共存することができます。
The Transport Security Model (TSM) MAY work with multiple Transport Models, but the RFC 3411 Abstract Service Interfaces (ASIs) do not carry a value for the Transport Model. The MIB module defined in this memo allows an administrator to configure whether or not TSM prepends a Transport Model prefix to the securityName. This will allow SNMP applications to consider Transport Model as a factor when making decisions, such as access control, notification generation, and proxy forwarding.
交通セキュリティモデル（TSM）は、複数の輸送モデルでも動作しますが、RFC 3411抽象サービスインターフェイス（ASIを）は、輸送モデルの値を運びません。このメモで定義されたMIBモジュールは、管理者がTSMは、セキュリティ名に輸送モデルの接頭辞を付加するかどうかを設定することができます。これは、アクセス制御、通知生成、およびプロキシ転送として意思決定を、作る時にSNMPアプリケーションが要因として輸送モデルを検討することができます。
To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [RFC5592].
SNMPが適切に輸送セキュリティモデルによって調整セキュリティサービスを使用するには、上このセキュリティモデルは、このようなセキュアシェル輸送モデル[RFC5592]として、tmStateReferenceを処理する方法を知っている輸送モデルを使用しなければなりません。
When performing SNMP processing, there are two levels of state information that might need to be retained: the immediate state linking a request-response pair and a potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590] defines general requirements for caches and references.
SNMP処理を行う際に、保持する必要がある場合があります状態情報の2つのレベルがあります：リクエスト・レスポンスのペアを結ぶ即時状態と潜在的に長期的な状態は、トランスポートとセキュリティに関連します。 [RFC5590]「簡易ネットワーク管理プロトコル（SNMP）のためのトランスポートサブシステムは、」キャッシュおよび参照のための一般的な要件を定義します。
This document defines additional cache requirements related to the Transport Security Model.
この文書では、トランスポート・セキュリティモデルに関連する追加のキャッシュ要件を定義します。
The Transport Security Model has specific responsibilities regarding the cached information.
交通セキュリティモデルは、キャッシュされた情報についての具体的な責任を持っています。
The Transport Security Model adds the tmStateReference received from the processIncomingMsg ASI to the securityStateReference. This tmStateReference can then be retrieved during the generateResponseMsg ASI so that it can be passed back to the Transport Model.
交通セキュリティモデルはtmStateReferenceがsecurityStateReferenceにprocessIncomingMsg ASIから受信した追加します。それは輸送モデルに戻って渡すことができるように、このtmStateReferenceは、generateResponseMsg ASI中に取得することができます。
For outgoing messages, the Transport Security Model uses parameters provided by the SNMP application to look up or create a tmStateReference.
送信メッセージの場合は、トランスポート・セキュリティモデルは、ルックアップまたはtmStateReferenceを作成するために、SNMPアプリケーションによって提供されるパラメータを使用しています。
For the Transport Security Model, the security parameters used for a response MUST be the same as those used for the corresponding request. This Security Model uses the tmStateReference stored as part of the securityStateReference when appropriate. For responses and reports, this Security Model sets the tmSameSecurity flag to true in the tmStateReference before passing it to a Transport Model.
交通セキュリティモデルでは、応答のために使用するセキュリティパラメータは、対応する要求のために使用されるものと同じでなければなりません。このセキュリティモデルは、securityStateReference適切な場合の一部として保存されtmStateReferenceを使用しています。応答およびレポートの場合、このセキュリティモデルは、輸送モデルに渡す前にtmStateReferenceでtrueにtmSameSecurityフラグを設定します。
For incoming messages, the Transport Security Model uses parameters provided in the tmStateReference cache to establish a securityName, and to verify adequate security levels.
受信メッセージの場合は、交通セキュリティモデルは、セキュリティ名を確立すること、および適切なセキュリティレベルを確認するためにtmStateReferenceキャッシュで提供されるパラメータを使用しています。
The SNMP-VIEW-BASED-ACM-MIB module [RFC3415], the SNMP-TARGET-MIB module [RFC3413], and other MIB modules contain objects to configure security parameters for use by applications such as access control, notification generation, and proxy forwarding.
SNMP-VIEW-BASED-ACM-MIBモジュール[RFC3415]、SNMP-TARGET-MIBモジュール[RFC3413]、および他のMIBモジュールは、アクセス制御、通知の生成、およびプロキシなどのアプリケーションによって使用されるセキュリティパラメータを設定するためのオブジェクトが含まれています転送。
Transport domains and their corresponding prefixes are coordinated via the IANA registry "SNMP Transport Domains".
交通ドメインとそれに対応するプレフィックスはIANAレジストリ「SNMP交通ドメイン」を介して調整されています。
If snmpTsmConfigurationUsePrefix is set to true, then all securityNames provided by, or provided to, the Transport Security Model MUST include a valid transport domain prefix.
snmpTsmConfigurationUsePrefixがtrueに設定されている場合は、すべてのsecurityNamesはにより提供される、またはに提供し、交通のセキュリティモデルは、有効なトランスポートドメインプレフィックスを含まなければなりません。
If snmpTsmConfigurationUsePrefix is set to false, then all securityNames provided by, or provided to, the Transport Security Model MUST NOT include a transport domain prefix.
snmpTsmConfigurationUsePrefixがfalseに設定されている場合、すべてのsecurityNamesはによって提供、またはに提供し、交通のセキュリティモデルは、輸送ドメインプレフィックスを含んではいけません。
The tmSecurityName in the tmStateReference stored as part of the securityStateReference does not contain a prefix.
tmStateReferenceでtmSecurityNameはsecurityStateReferenceの一部接頭辞が含まれていないとして保存します。
An error indication might return an Object Identifier (OID) and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, if this information is available at the point where the error is detected.
この情報は、エラーが検出された時点で利用可能である場合は、エラー表示は、インクリメントカウンタたsecurityLevelの値、カウンタのcontextEngineIDとのcontextNameの値、及びsecurityStateReferenceのオブジェクト識別子（OID）と値を返すかもしれません。
This section describes the procedure followed by the Transport Security Model.
このセクションでは、トランスポート・セキュリティモデルに続いて手順を説明します。
The parameters needed for generating a message are supplied to the Security Model by the Message Processing Model via the generateRequestMsg() or the generateResponseMsg() ASI. The Transport Subsystem architectural extension has added the transportDomain, transportAddress, and tmStateReference parameters to the original RFC 3411 ASIs.
メッセージを生成するために必要なパラメータはgenerateRequestMsg（経由のメッセージ処理モデル）またはgenerateResponseMsg（）ASIによってセキュリティモデルに供給されています。トランスポートサブシステムアーキテクチャ拡張は、元のRFC 3411 ASIをにtransportDomain、transportAddress、及びtmStateReferenceパラメータを追加しました。
statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- (NEW) specified by application IN transportAddress -- (NEW) specified by application 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 OUT tmStateReference -- (NEW) transport info )
statusInformationを= - 成功またはerrorIndication generateRequestMsg（messageProcessingModel IN - 典型的には、グローバルデータIN SNMPバージョン - メッセージヘッダー、maxMessageSize IN管理データ - transportDomain IN送信SNMPエンティティの - （NEW）transportAddressでアプリケーションによって指定されました - （たsecurityLevel INこのプリンシパルに代わって - - セキュリティ名で権限SNMPエンティティ - securityEngineID、IN送信メッセージのために - NEW）securityModelでアプリケーションによって指定されたセキュリティのレベルで要求されたscopedPDU - メッセージ（平文）はsecurityParametersをOUTペイロード - セキュリティモジュールOUT wholeMsgによって記入 - 生成されたメッセージの長さOUT tmStateReference - - wholeMsgLength生成されたメッセージをOUT完了（NEW）交通情報を）
statusInformation = -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version
statusInformationを= - 成功またはerrorIndication generateResponseMsg（messageProcessingModel、IN - 一般的に、SNMPのバージョン
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- (NEW) specified by application
IN transportAddress -- (NEW) specified by application
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
OUT tmStateReference -- (NEW) transport info
)
1. If there is a securityStateReference (Response or Report message), then this Security Model uses the cached information rather than the information provided by the ASI. Extract the tmStateReference from the securityStateReference cache. Set the tmRequestedSecurityLevel to the value of the extracted tmTransportSecurityLevel. Set the tmSameSecurity parameter in the tmStateReference cache to true. The cachedSecurityData for this message can now be discarded.
securityStateReference（レスポンスやレポートメッセージ）がある場合1.、このセキュリティモデルは、キャッシュされた情報ではなく、ASIによって提供される情報を使用しています。 securityStateReferenceキャッシュからtmStateReferenceを抽出します。抽出されたtmTransportSecurityLevelの値にtmRequestedSecurityLevelを設定してください。 trueにtmStateReferenceキャッシュにtmSameSecurityパラメータを設定します。このメッセージのcachedSecurityDataは現在、破棄することができます。
2. If there is no securityStateReference (e.g., a Request-type or Notification message), then create a tmStateReference cache. Set tmTransportDomain to the value of transportDomain, tmTransportAddress to the value of transportAddress, and tmRequestedSecurityLevel to the value of securityLevel. (Implementers might optimize by pointing to saved copies of these session-specific values.) Set the transaction-specific tmSameSecurity parameter to false.
2.ないsecurityStateReference（例えば、リクエスト型または通知メッセージ）が存在しない場合、tmStateReferenceキャッシュを作成します。たsecurityLevelの値にtransportAddressの値にtransportDomain、tmTransportAddressの値にtmTransportDomainを設定し、tmRequestedSecurityLevel。 （実装者はこれらのセッション固有の値の保存されたコピーを指していることにより、最適化するかもしれません。）falseにトランザクション固有tmSameSecurityパラメータを設定します。
If the snmpTsmConfigurationUsePrefix object is set to false, then
set tmSecurityName to the value of securityName.
If the snmpTsmConfigurationUsePrefix object is set to true, then use the transportDomain to look up the corresponding prefix. (Since the securityStateReference stores the tmStateReference with the tmSecurityName for the incoming message, and since tmSecurityName never has a prefix, the prefix-stripping step only occurs when we are not using the securityStateReference).
snmpTsmConfigurationUsePrefixオブジェクトがtrueに設定されている場合、対応する接頭辞をルックアップするためにtransportDomainを使用しています。 （securityStateReference着信メッセージのtmSecurityNameとtmStateReferenceを格納し、そしてtmSecurityNameに接頭辞が付いていることはないので、我々はsecurityStateReferenceを使用していない場合、プレフィックスストリッピング工程のみ起こるので）。
If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
プレフィックス検索が何らかの理由で失敗した場合、snmpTsmUnknownPrefixesカウンタがインクリメントされ、エラー表示が呼ぶモジュールに返され、メッセージ処理が停止します。
If the lookup succeeds, but there is no prefix in the securityName, or the prefix returned does not match the prefix in the securityName, or the length of the prefix is less than 1 or greater than 4 US-ASCII alpha-numeric characters, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
ルックアップは成功しますが、そこにセキュリティ名には接頭辞ではありません、または、その後、返されたプレフィックスはセキュリティ名にプレフィックスと一致していない、またはプレフィックスの長さは4 US-ASCIIの英数字未満1以上であればsnmpTsmInvalidPrefixesカウンタがインクリメントされ、エラー表示が呼び出し側モジュールに戻され、メッセージ処理が停止されます。
Strip the transport-specific prefix and trailing ':' character (US-ASCII 0x3a) from the securityName. Set tmSecurityName to the value of securityName.
「：」文字（US-ASCIIの0x3a）のsecurityNameからのトランスポート固有のプレフィックスと末尾を取り除きます。セキュリティ名の値にtmSecurityNameを設定してください。
4. Combine the message parts into a wholeMsg and calculate wholeMsgLength.
4. wholeMsgにメッセージ部分を合わせ、wholeMsgLengthを計算します。
5. The wholeMsg, wholeMsgLength, securityParameters, and tmStateReference are returned to the calling Message Processing Model with the statusInformation set to success.
5. wholeMsg、wholeMsgLength、securityParameters、およびtmStateReferenceはstatusInformationを持つ呼び出しメッセージ処理モデルを成功に設定に戻ります。
An error indication might return an OID and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, if this information is available at the point where the error is detected.
この情報は、エラーが検出された時点で利用可能である場合は、エラー表示は、インクリメントカウンタたsecurityLevelの値、カウンタのcontextEngineIDとのcontextNameの値、およびsecurityStateReferenceのOIDと値を返すかもしれません。
This section describes the procedure followed by the Transport Security Model whenever it receives an incoming message from a Message Processing Model. The ASI from a Message Processing Model to the Security Subsystem for a received message is:
このセクションでは、メッセージ処理モデルからの着信メッセージを受信するたびに交通セキュリティモデルに続いて手順を説明します。受信したメッセージのメッセージ処理モデルからセキュリティサブシステムにASIは以下のとおりです。
statusInformation = -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- from the received message IN securityParameters -- from the received message IN securityModel -- from the received message IN securityLevel -- from the received message
statusInformationを= - errorIndicationまたは成功 - エラーカウンタOID /値messageProcessingModel INエラーprocessIncomingMsg（IF - maxMessageSize典型的に、SNMPバージョン - 受信されたメッセージから - securityModelで受信されたメッセージから - securityParametersで受信したメッセージからたsecurityLevel、IN - 受信したメッセージから
IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire IN tmStateReference -- (NEW) from the Transport Model OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response
wholeMsg IN - wholeMsgLengthワイヤ上で受信されるよう - 長tmStateReferenceワイヤ上で受信される - （NEW）輸送モデルOUT securityEngineIDから - 正式のSNMP実体OUTのsecurityName - プリンシパルの識別OUTたscopedPDU、 - メッセージ（平文）ペイロードOUT maxSizeResponseScopedPDU - 最大サイズの送信者がsecurityStateReference OUT扱うことができる - セキュリティ状態への参照） - 情報、応答のために必要
2. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, and tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is incremented, an error indication is returned to the calling module, and Security Model processing stops for this message.
2. tmStateReferenceはtmTransportDomain、tmTransportAddress、tmSecurityName、およびtmTransportSecurityLevelの値を含むキャッシュを参照していない場合は、snmpTsmInvalidCachesカウンタがインクリメントされ、エラー表示は、呼び出し元のモジュールに戻り、セキュリティモデルの処理は、このメッセージのために停止しています。
If the snmpTsmConfigurationUsePrefix object is set to true, then
use the tmTransportDomain to look up the corresponding prefix.
If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
プレフィックス検索が何らかの理由で失敗した場合、snmpTsmUnknownPrefixesカウンタがインクリメントされ、エラー表示が呼ぶモジュールに返され、メッセージ処理が停止します。
If the lookup succeeds but the prefix length is less than 1 or greater than 4 octets, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
ルックアップは成功したが、プレフィックスの長さが1未満または4つのオクテットよりも大きい場合、snmpTsmInvalidPrefixesカウンタがインクリメントされ、エラー表示が呼び出し側モジュールに戻され、メッセージ処理が停止されます。
Set the securityName to be the concatenation of the prefix, a ':' character (US-ASCII 0x3a), and the tmSecurityName.
「：」文字（US-ASCIIの0x3a）、およびtmSecurityName接頭辞、Aの連結をするセキュリティ名を設定します。
4. Compare the value of tmTransportSecurityLevel in the tmStateReference cache to the value of the securityLevel parameter passed in the processIncomingMsg ASI. If securityLevel specifies privacy (Priv) and tmTransportSecurityLevel specifies no privacy (noPriv), or if securityLevel specifies authentication (auth) and tmTransportSecurityLevel specifies no authentication (noAuth) was provided by the Transport Model, then the snmpTsmInadequateSecurityLevels counter is incremented, an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module, and Transport Security Model processing stops for this message.
4. processIncomingMsg ASIに渡されたsecurityLevelパラメータの値にtmStateReferenceキャッシュにtmTransportSecurityLevelの値を比較してください。 （たsecurityLevelは（プライベート）のプライバシーを指定し、tmTransportSecurityLevelには、プライバシー（NOPRIV）を指定していない、またはたsecurityLevelが認証（認証）を指定し、tmTransportSecurityLevelは、輸送モデルにより提供されたいかなる認証（NOAUTH）を指定しない場合は、snmpTsmInadequateSecurityLevelsカウンタは、エラー表示がインクリメントされた場合unsupportedSecurityLevel）一緒にインクリメントカウンタのOIDと値では、呼び出し元のモジュールに戻され、輸送セキュリティモデルの処理は、このメッセージのために停止します。
5. The tmStateReference is cached as cachedSecurityData so that a possible response to this message will use the same security parameters. Then securityStateReference is set for subsequent references to this cached data.
このメッセージへの可能な応答は、同じセキュリティパラメータを使用するように5. tmStateReferenceはcachedSecurityDataとしてキャッシュされます。その後securityStateReferenceは、このキャッシュされたデータへのその後の参照用に設定されています。
7. The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message.
7. maxSizeResponseScopedPDUが計算されます。これは、可能な応答メッセージのためのscopedPDUの最大サイズです。
8. 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 ASI.
8. statusInformationを成功に設定され、リターンがprocessIncomingMsg ASIで指定された呼び出し元のモジュールは、OUTパラメータを渡すバックに行われます。
This MIB module provides objects for use only by the Transport Security Model. It defines a configuration scalar and related error counters.
このMIBモジュールはトランスポート・セキュリティ・モデルで使用するためのオブジェクトを提供します。これは、コンフィギュレーション・スカラーおよび関連エラーカウンタを定義します。
Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below.
このMIBモジュール内のオブジェクトは、サブツリーに配置されています。各サブツリーは、関連するオブジェクトの集合として構成されています。全体的な構造およびそのサブツリーへのオブジェクトの割り当て、及び各サブツリーの意図された目的は、以下に示されています。
This subtree contains error counters specific to the Transport Security Model.
このサブツリーは、トランスポート・セキュリティモデルに固有のエラーカウンタが含まれています。
This subtree contains a configuration object that enables administrators to specify if they want a transport domain prefix prepended to securityNames for use by applications.
このサブツリーは、彼らがアプリケーションで使用するためsecurityNamesの前に追加輸送ドメインプレフィックスをしたい場合に指定し、管理者を可能な構成オブジェクトが含まれています。
Some management objects defined in other MIB modules are applicable to an entity implementing the Transport Security Model. In particular, it is assumed that an entity implementing the Transport Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the
他のMIBモジュールで定義された一部の管理オブジェクトは、トランスポート・セキュリティモデルを実装するエンティティに適用されます。特に、交通セキュリティモデルを実装するエンティティは、SNMP-FRAMEWORK-MIB [RFC3411]を実装することが想定されます
SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and the SNMPv2-MIB [RFC3418]. These are not needed to implement the SNMP-TSM-MIB.
SNMP-TARGET-MIB [RFC3413]、SNMP-VIEW-BASED-ACM-MIB [RFC3415]、およびSNMPv2-MIB [RFC3418]。これらは、SNMP-TSM-MIBを実装するために必要されていません。
The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580].
[RFC2578]、[RFC2579]及び[RFC2580]から次のMIBモジュールの輸入アイテム。
SNMP-TSM-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Counter32 FROM SNMPv2-SMI -- RFC2578 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 TruthValue FROM SNMPv2-TC -- RFC2579 ;
SNMPv2-CONF FROM RFC2578のMODULE-COMPLIANCE、オブジェクト・グループ - - のSNMPv2-SMIからの輸入MODULE-IDENTITY、OBJECT-TYPE、MIB-2、Counter32のRFC2580のTruthValueのSNMPv2-TC FROM - RFC2579。
snmpTsmMIB MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org
snmpTsmMIB MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMSワーキンググループ" CONTACT-INFO「WG-Eメール：isms@lists.ietf.org購読：isms-request@lists.ietf.org
Chairs:
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
+49 6221 90511-15
quittek@netlab.nec.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de
ユルゲンSchoenwaelderジェイコブス大学ブレーメンキャンパスリング1 28725ブレーメンドイツ+49 421 200から3587 j.schoenwaelder@jacobs-university.de
Editor: David Harrington Huawei Technologies USA 1700 Alma Dr. Plano TX 75075 USA +1 603-436-8634 ietfdbh@comcast.net
エディタ：デヴィッド・ハリントン華為技術USA 1700アルマ博士プラノTX 75075 USA +1 603-436-8634 ietfdbh@comcast.net
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 USA +1 530 792 1913 ietf@hardakers.net " DESCRIPTION "The Transport Security Model MIB.
ウェスHardakerコブハム分析ソリューション私書箱382デイビス、CA 95617 USA +1 530 792 1913 ietf@hardakers.net "DESCRIPTION" 交通セキュリティモデルMIBをボックスです。
In keeping with the RFC 3411 design decisions to use
self-contained documents, the RFC that contains the definition
of this MIB module also includes the elements of procedure
that are needed for processing the Transport Security Model
for SNMP. These MIB objects SHOULD NOT be modified via other
subsystems or models defined in other documents. This allows
the Transport Security Model for SNMP to be designed and
documented as independent and self-contained, having no direct
impact on other modules, and this allows this module to be
upgraded and supplemented as the need arises, and to move
along the standards track on different time-lines from other
modules.
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2009 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
再配布および、改変してまたは改変せずに、ソースおよびバイナリ形式で使用し、以下の条件が満たされていることを許可されます。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布は、上記の著作権表示、条件のリストおよび以下の免責事項を保持しなければなりません。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式で再配布は、上記の著作権表示、条件のリストおよび文書および/または分布を備えた他の材料で次の免責事項を再現しなければなりません。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- インターネット協会、IETFやIETFトラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
このソフトウェアは、著作権所有者によって提供され、貢献者AS IS 'AND明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証を放棄されています。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
This version of this MIB module is part of RFC 5591; see the RFC itself for full legal notices."
このMIBモジュールのこのバージョンはRFC 5591の一部です。完全な適法な通知についてはRFC自体を参照してください。」
REVISION "200906090000Z" DESCRIPTION "The initial version, published in RFC 5591."
"RFC 5591.に掲載された最初のバージョン、" REVISION "200906090000Z" DESCRIPTION
::= { mib-2 190 }
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-TSM-MIB
-- ---------------------------------------------------------- --
snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 }
snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 }
snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
-- Statistics for the Transport Security Model
- トランスポートセキュリティモデルのための統計
snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 }
snmpTsmInvalidCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the
snmpTsmInvalidCachesのOBJECT-TYPE SYNTAXカウンタACCESS read-onlyステータス現在の説明「着信メッセージの数が低下したため、
tmStateReference referred to an invalid cache.
"
::= { snmpTsmStats 1 }
snmpTsmInadequateSecurityLevels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of incoming messages dropped because
the securityLevel asserted by the Transport Model was
less than the securityLevel requested by the
application.
"
::= { snmpTsmStats 2 }
snmpTsmUnknownPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
snmpTsmConfigurationUsePrefix was set to true and
there is no known prefix for the specified transport
domain.
"
::= { snmpTsmStats 3 }
snmpTsmInvalidPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
the securityName associated with an outgoing message
did not contain a valid transport domain prefix.
"
::= { snmpTsmStats 4 }
-- -------------------------------------------------------------
-- Configuration
-- -------------------------------------------------------------
-- Configuration for the Transport Security Model
- トランスポートセキュリティモデルの設定
snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 }
snmpTsmConfigurationUsePrefix OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current
snmpTsmConfigurationUsePrefix OBJECT-TYPE構文のTruthValue MAX-ACCESS読み取りと書き込みステータス現在の
DESCRIPTION "If this object is set to true, then securityNames
passing to and from the application are expected to
contain a transport-domain-specific prefix. If this
object is set to true, then a domain-specific prefix
will be added by the TSM to the securityName for
incoming messages and removed from the securityName
when processing outgoing messages. Transport domains
and prefixes are maintained in a registry by IANA.
This object SHOULD persist across system reboots.
"
DEFVAL { false }
::= { snmpTsmConfiguration 1 }
-- -------------------------------------------------------------
-- snmpTsmMIB - Conformance Information
-- -------------------------------------------------------------
snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 }
snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 }
-- -------------------------------------------------------------
-- Compliance statements
-- -------------------------------------------------------------
snmpTsmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines that support
the SNMP-TSM-MIB.
"
MODULE
MANDATORY-GROUPS { snmpTsmGroup }
::= { snmpTsmCompliances 1 }
-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
snmpTsmGroup OBJECT-GROUP
OBJECTS {
snmpTsmInvalidCaches,
snmpTsmInadequateSecurityLevels,
snmpTsmUnknownPrefixes,
snmpTsmInvalidPrefixes,
snmpTsmConfigurationUsePrefix
}
STATUS current
DESCRIPTION "A collection of objects for maintaining
information of an SNMP engine that implements the SNMP Transport Security Model.
"
::= { snmpTsmGroups 2 }
END
終わり
This document describes a Security Model, compatible with the RFC 3411 architecture, that permits SNMP to utilize security services provided through an SNMP Transport Model. The Transport Security Model relies on Transport Models for mutual authentication, binding of keys, confidentiality, and integrity.
この文書では、SNMP輸送モデルを通じて提供されるセキュリティ・サービスを利用するためにSNMPを許可するRFC 3411のアーキテクチャと互換性のあるセキュリティモデルを、説明しています。交通セキュリティモデルは、キー、機密性、および完全性の結合、相互認証のための輸送モデルに依存しています。
The Transport Security Model relies on secure Transport Models to provide an authenticated principal identifier and an assertion of whether authentication and privacy are used during transport. This Security Model SHOULD always be used with Transport Models that provide adequate security, but "adequate security" is a configuration and/or run-time decision of the operator or management application. The security threats and how these threats are mitigated should be covered in detail in the specifications of the Transport Models and the underlying secure transports.
交通セキュリティモデルは、認証されたプリンシパル識別子と認証やプライバシーが輸送中に使用されているかどうかのアサーションを提供するために、安全な輸送モデルに依存しています。このセキュリティモデルは、常に十分なセキュリティを提供する輸送モデルに使用する必要がありますが、「十分なセキュリティは、」コンフィギュレーションおよび/またはオペレータや管理アプリケーションの実行時に決定です。セキュリティの脅威とどのようにこれらの脅威が軽減されているが輸送モデルと基礎となる安全なトランスポートの仕様で詳しく説明されなければなりません。
An authenticated principal identifier (securityName) is used in SNMP applications for purposes such as access control, notification generation, and proxy forwarding. This Security Model supports multiple Transport Models. Operators might judge some transports to be more secure than others, so this Security Model can be configured to prepend a prefix to the securityName to indicate the Transport Model used to authenticate the principal. Operators can use the prefixed securityName when making application decisions about levels of access.
認証プリンシパル識別子（のsecurityName）は、アクセス制御、通知生成、及びプロキシ転送などの目的のためにSNMPアプリケーションで使用されています。このセキュリティモデルは、複数の輸送モデルをサポートしています。オペレータは他のものより安全になるように、いくつかのトランスポートを判断するかもしれないので、このセキュリティモデルは、プリンシパルを認証するために使用される輸送モデルを示すために、セキュリティ名に接頭辞を付加するように構成することができます。アクセスレベルに関するアプリケーションの意思決定を行う際にオペレータは接頭辞セキュリティ名を使用することができます。
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o The snmpTsmConfigurationUsePrefix object could be modified, creating a denial of service or authorizing SNMP messages that would not have previously been authorized by an Access Control Model (e.g., the View-based Access Control Model (VACM)).
読み書きおよび/またはリード作成のMAX-ACCESS句でこのMIBモジュールで定義された管理オブジェクトの数があります。そのようなオブジェクトは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響を与える可能性があります。これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です：snmpTsmConfigurationUsePrefixオブジェクトが変更される可能性がO、サービス拒否を作成するか、以前のアクセス制御モデル（例えば、ビューベースのアクセス制御によって許可されなかったであろうSNMPメッセージを許可しますモデル（VACM））。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュールで読み取り可能なオブジェクトの一部（すなわち、アクセス可能ではない以外MAX-ACCESS持つオブジェクト）は、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。 GETおよび/またはこれらのオブジェクトへのアクセスを通知し、おそらくSNMPを通してネットワークの上にそれらを送信する場合でも、これらのオブジェクトの値を暗号化するためにも、制御することが重要です。これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です：
o All the counters in this module refer to configuration errors and do not expose sensitive information.
Oこのモジュールのすべてのカウンタは、設定エラーを参照して機密情報を公開していません。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3の前のSNMPバージョンは十分なセキュリティを含んでいませんでした。ネットワーク自体が（IPsecを使って、例えば）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）この内のオブジェクトが存在しませんMIBモジュール。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy).
（認証とプライバシーのため）USMとトランスポートセキュリティモデルの暗号化メカニズムの完全なサポートを含むSNMPv3フレームワーク（[RFC3410]、セクション8を参照）、によって提供される実装は、セキュリティ機能を検討することが推奨されます。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はお勧めしません。代わりに、SNMPv3を展開すると、暗号化セキュリティを有効にすることをお勧めします。このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が適切にのみプリンシパル（ユーザ）にオブジェクトへのアクセスを提供するように設定されていることを確認するために、顧客/オペレータ責任実際にGETまたはSET（変化への正当な権利を有することです/）/削除、それらを作成します。
IANA has assigned:
IANAが割り当てられています：
1. An SMI number (190) with a prefix of mib-2 in the MIB module registry for the MIB module in this document.
この文書に記載されているMIBモジュールのMIBモジュールレジストリのMIB-2のプレフィクスを持つ1】SMI番号（190）。
2. A value (4) to identify the Transport Security Model, in the Security Models registry of the SNMP Number Spaces registry. This results in the following table of values:
2.値（4）SNMP番号スペースレジストリのセキュリティモデルのレジストリに、トランスポート・セキュリティモデルを識別するために。これは、値の次の表のような結果になります。
Value Description References
----- ----------- ----------
0 reserved for 'any' [RFC3411]
1 reserved for SNMPv1 [RFC3411]
2 reserved for SNMPv2c [RFC3411]
3 User-Based Security Model (USM) [RFC3411]
4 Transport Security Model (TSM) [RFC5591]
The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity.
編集者は、組織と明瞭度を改善するために、既存の文書をwordsmithing優れた仕事のための彼のSSHの洞察力とDave盾を共有するためのジェフリーHutzelmanに感謝したいと思います。
Additionally, helpful document reviews were received from Juergen Schoenwaelder.
また、役立つ文書のレビューは、ユルゲンSchoenwaelderから受け取りました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、エド。、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412]ケース、J.、ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、STD 62、RFC 3412、2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]レビ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル（SNMP）アプリケーション"、STD 62、RFC 3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
、STD 62、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590]ハリントン、D.とJ. Schoenwaelder、RFC 5590、2009年6月 "簡易ネットワーク管理プロトコル（SNMP）のための輸送サブシステム"。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnenの、B.、Presuhn、R.、およびK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、STD 62、RFC 3415、2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
、STD 62、RFC 3418、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）" [RFC3418] Presuhn、R.、。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]フライ、R.、レヴィ、D.、Routhier、S.、およびB. Wijnenの、 "バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、BCP 74、RFC 3584 、2003年8月。
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
[RFC5592]ハリントン、D.、Salowey、J.、およびW. Hardakerは、RFC 5592、2009年6月 "シェル輸送モデルは、簡易ネットワーク管理プロトコル（SNMP）のための安全な"。
Appendix A. Notification Tables Configuration
付録A.通知表の設定
The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to configure notification originators with the destinations to which notifications should be sent.
SNMP-TARGET-MIBとSNMP-NOTIFICATION-MIB [RFC3413]は通知が送信すべき送信先を通知発信元を設定するために使用されています。
Most of the configuration is Security-Model-independent and Transport-Model-independent.
ほとんどの設定は、セキュリティモデルに依存しないとトランスポート・モデルに依存しています。
The values we will use in the examples for the five model-independent security and transport parameters are:
我々は5機種に依存しないセキュリティおよび輸送のパラメータの例で使用する値は次のとおりです。
transportDomain = snmpSSHDomain
輸送ドメイン= SNMP SSHドメイン
transportAddress = 192.0.2.1:5162
transportAddress = 192.0.2.1:5162
securityModel = Transport Security Model
securityModel =トランスポート・セキュリティモデル
securityName = alice
セキュリティ名=アリス
securityLevel = authPriv
たsecurityLevel = authPrivの
The following example will configure the notification originator to send informs to a notification receiver at 192.0.2.1:5162 using the securityName "alice". "alice" is the name for the recipient from the standpoint of the notification originator and is used for processing access controls before sending a notification.
次の例では、セキュリティ名「アリス」を使用して192.0.2.1:5162で通知受信機に知らせるを送信するために、通知の発信元を設定します。 「アリス」は通知創始者の立場から、受信者の名前であるとの通知を送信する前に、アクセス制御を処理するために使用されます。
The columns marked with an "*" are the items that are Security-Model-specific or Transport-Model-specific.
でマークされた列の「*」のセキュリティ・モデル固有またはトランスポート・モデル固有な項目があります。
The configuration for the "alice" settings in the SNMP-VIEW-BASED-ACM-MIB objects are not shown here for brevity. First, we configure which type of notification will be sent for this taglist (toCRTag). In this example, we choose to send an Inform. snmpNotifyTable row: snmpNotifyName CRNotif snmpNotifyTag toCRTag snmpNotifyType inform snmpNotifyStorageType nonVolatile snmpNotifyColumnStatus createAndGo
SNMP-VIEW-BASED-ACM-MIBオブジェクトの「アリス」の設定のための設定を簡潔にするためにここには示されていません。まず、我々はこのタグリスト（toCRTag）のために送られる通知の種類を設定します。この例では、通知の送信を選択します。たsnmpNotifyTable行：snmpNotifyName CRNotif snmpNotifyTag toCRTag snmpNotifyTypeにはsnmpNotifyStorageType nonVolatileのsnmpNotifyColumnStatus createAndGoを知らせます
Then we configure a transport address to which notifications associated with this taglist will be sent, and we specify which snmpTargetParamsEntry will be used (toCR) when sending to this transport address.
その後、我々は、このタグリストに関連付けられている通知が送信されます、そして我々は、このトランスポートアドレスへの送信時snmpTargetParamsEntryは（TOCR）に使用される指定のトランスポートアドレスを設定します。
snmpTargetAddrTable row:
snmpTargetAddrName toCRAddr
* snmpTargetAddrTDomain snmpSSHDomain
* snmpTargetAddrTAddress 192.0.2.1:5162
snmpTargetAddrTimeout 1500
snmpTargetAddrRetryCount 3
snmpTargetAddrTagList toCRTag
snmpTargetAddrParams toCR (MUST match below)
snmpTargetAddrStorageType nonVolatile
snmpTargetAddrColumnStatus createAndGo
Then we configure which principal at the host will receive the notifications associated with this taglist. Here, we choose "alice", who uses the Transport Security Model. snmpTargetParamsTable row: snmpTargetParamsName toCR snmpTargetParamsMPModel SNMPv3 * snmpTargetParamsSecurityModel TransportSecurityModel snmpTargetParamsSecurityName "alice" snmpTargetParamsSecurityLevel authPriv snmpTargetParamsStorageType nonVolatile snmpTargetParamsRowStatus createAndGo
その後、我々は、このタグリストに関連した通知を受信するホストでいる主要な構成します。ここでは、トランスポート・セキュリティモデルを使用しています「アリス」を選択します。たsnmpTargetParamsTable行：snmpTargetParamsName TOCR snmpTargetParamsMPModelのSNMPv3 * snmpTargetParamsSecurityModel TransportSecurityModel snmpTargetParamsSecurityName "アリス" snmpTargetParamsSecurityLevel authPrivのsnmpTargetParamsStorageType nonVolatileのsnmpTargetParamsRowStatus createAndGo
A.1. Transport Security Model Processing for Notifications
A.1。通知のためのトランスポート・セキュリティ・モデルの処理
The Transport Security Model is called using the generateRequestMsg() ASI, with the following parameters (those with an * are from the above tables):
交通セキュリティモデルは、以下のパラメータ（*を持つものは上記の表からのもの）で、generateRequestMsg（）ASIを使用して呼び出されます。
statusInformation = -- success or errorIndication generateRequestMsg( IN messageProcessingModel -- *snmpTargetParamsMPModel IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN transportDomain -- *snmpTargetAddrTDomain IN transportAddress -- *snmpTargetAddrTAddress IN securityModel -- *snmpTargetParamsSecurityModel IN securityEngineID -- immaterial; TSM will ignore. IN securityName -- snmpTargetParamsSecurityName IN securityLevel -- *snmpTargetParamsSecurityLevel IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- reference to transport info )
statusInformationをは= - messageProcessingModelの成功またはerrorIndication generateRequestMsg（ - グローバルデータ、IN * snmpTargetParamsMPModel - メッセージヘッダ、maxMessageSizeのAdminデータ - transportDomainを送ったSNMPエンティティの - transportAddress、IN * snmpTargetAddrTDomain - * securityModel、IN snmpTargetAddrTAddress - * securityEngineID、IN snmpTargetParamsSecurityModel - 軽微; TSM無視するセキュリティ名、IN - たsecurityLevel、IN snmpTargetParamsSecurityName - * snmpTargetParamsSecurityLevelたscopedPDU、IN - メッセージ（平文）ペイロードOUT securityParameters - セキュリティモジュールによって記入OUT wholeMsg - 生成されたメッセージをOUT wholeMsgLength完成 - - 生成されたメッセージの長さOUT tmStateReference - 情報を搬送する参照）
The Transport Security Model will determine the Transport Model based on the snmpTargetAddrTDomain. The selected Transport Model will select the appropriate transport connection using the tmStateReference cache created from the values of snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel.
交通セキュリティモデルはsnmpTargetAddrTDomainに基づいて輸送モデルを決定します。選択された輸送モデルはsnmpTargetAddrTAddress、snmpTargetParamsSecurityName、およびsnmpTargetParamsSecurityLevelの値から作成tmStateReferenceキャッシュを使用して、適切なトランスポート接続を選択します。
Appendix B. Processing Differences between USM and Secure Transport
USMとセキュアな交通との付録B.処理の違い
USM and secure transports differ in the processing order and responsibilities within the RFC 3411 architecture. While the steps are the same, they occur in a different order and might be done by different subsystems. The following lists illustrate the difference in the flow and the responsibility for different processing steps for incoming messages when using USM and when using a secure transport. (These lists are simplified for illustrative purposes, and do not represent all details of processing. Transport Models MUST provide the detailed elements of procedure.)
USMとセキュアトランスポートは、RFC 3411アーキテクチャ内の処理順序と責任が異なります。手順は同じですが、それらは異なる順序で発生し、異なるサブシステムによって行われることがあります。以下のリストは、フローおよび受信メッセージの異なる処理ステップの責任USMを使用して、安全な輸送を使用する際の違いを説明します。 （これらのリストは、例示の目的のために簡略化され、処理のすべての詳細を表すものではない。輸送モデルは、手順の詳細な要素を提供しなければなりません。）
With USM, SNMPv1, and SNMPv2c Security Models, security processing starts when the Message Processing Model decodes portions of the ASN.1 message to extract header fields that are used to determine which Security Model will process the message to perform authentication, decryption, timeliness checking, integrity checking, and translation of parameters to model-independent parameters. By comparison, a secure transport performs those security functions on the message, before the ASN.1 is decoded.
USM、SNMPv1の、およびSNMPv2cセキュリティモデルで、セキュリティ処理は、メッセージ処理モデルセキュリティモデルチェック認証、復号化、適時性を実行するためのメッセージを処理するかを決定するために使用されるヘッダフィールドを抽出するためにASN.1メッセージの部分をデコードするときに起動しますモデルに依存しないパラメータのパラメータの、整合性チェック、および翻訳。 ASN.1が復号される前に比較することにより、安全な輸送は、メッセージにこれらのセキュリティ機能を実行します。
Step 6 cannot occur until after decryption occurs. Steps 6 and beyond are the same for USM and a secure transport.
ステップ6は、復号化が発生した後まで発生することはできません。 6手順以降USMとの安全な輸送のために同じです。
B.1. USM and the Architecture
B.1。 USMとアーキテクチャ
1) Decode the ASN.1 header (Message Processing Model).
1）ASN.1ヘッダ（メッセージ処理モデル）をデコード。
2) Determine the SNMP Security Model and parameters (Message Processing Model).
2）SNMPセキュリティモデルおよびパラメータ（メッセージ処理モデル）を決定します。
3) Verify securityLevel (Security Model).
3）たsecurityLevel（セキュリティモデル）を確認してください。
4) Translate parameters to model-independent parameters (Security Model).
4）モデルに依存しないパラメータ（セキュリティモデル）にパラメータを変換します。
5) Authenticate the principal, check message integrity and timeliness, and decrypt the message (Security Model).
5）、プリンシパルを認証し、メッセージの完全性と適時性をチェックし、メッセージ（セキュリティモデル）を解読します。
6) Determine the pduType in the decrypted portions (Message Processing Model).
6）復号化部（メッセージ処理モデル）におけるpduTypeを決定します。
7) Pass on the decrypted portions with model-independent parameters.
7）モデルに依存しないパラメータで復号化された部分を渡します。
B.2. Transport Subsystem and the Architecture
B.2。交通サブシステムとアーキテクチャ
1) Authenticate the principal, check integrity and timeliness of the message, and decrypt the message (Transport Model).
1）、プリンシパルを認証し、メッセージの完全性と適時性をチェックし、メッセージ（トランスポートモデル）を解読。
2) Translate parameters to model-independent parameters (Transport Model).
2）モデルに依存しないパラメータ（輸送モデル）にパラメータを変換します。
3) Decode the ASN.1 header (Message Processing Model).
3）ASN.1ヘッダ（メッセージ処理モデル）をデコード。
4) Determine the SNMP Security Model and parameters (Message Processing Model).
4）SNMPセキュリティモデルおよびパラメータ（メッセージ処理モデル）を決定します。
5) Verify securityLevel (Security Model).
5）たsecurityLevel（セキュリティモデル）を確認してください。
6) Determine the pduType in the decrypted portions (Message Processing Model).
6）復号化部（メッセージ処理モデル）におけるpduTypeを決定します。
7) Pass on the decrypted portions with model-independent security parameters.
7）モデルに依存しないセキュリティパラメータを使用して復号化された部分を渡します。
If a message is secured using a secure transport layer, then the Transport Model will provide the translation from the authenticated identity (e.g., an SSH user name) to a human-friendly identifier (tmSecurityName) in step 2. The Security Model will provide a mapping from that identifier to a model-independent securityName.
メッセージはセキュアなトランスポート層を使用して固定されている場合は、輸送モデルは、セキュリティモデルが提供されますステップ2で人に優しい識別子（tmSecurityName）に認証されたアイデンティティ（例えば、SSHのユーザー名）からの翻訳を提供しますモデルに依存しないセキュリティ名への識別子のマッピング。
Authors' Addresses
著者のアドレス
David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
デヴィッド・ハリントン華為技術（USA）1700アルマ博士スイート100プラノ、TX 75075 USA
Phone: +1 603 436 8634 EMail: ietfdbh@comcast.net
電話：+1 603 436 8634 Eメール：ietfdbh@comcast.net
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US
ウェス・ハードフィールドコブハム分析ソリューション私書箱382デイビス、CA 95617米国箱
Phone: +1 530 792 1913 EMail: ietf@hardakers.net
電話：+1 530 792 1913 Eメール：ietf@hardakers.net