[要約] RFC 5591は、SNMPのための輸送セキュリティモデルに関する規格です。このRFCの目的は、SNMPの通信を保護し、機密性と完全性を確保するためのセキュリティメカニズムを提供することです。
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)
シンプルなネットワーク管理プロトコル（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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).
このメモは、Simple Network Management Protocol（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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アーキテクチャまたはサブシステムとの互換性に関連するコンテキストで使用されますが、それはワイヤの互換性に影響を与えないかもしれません。これらの用語は、提案されたIETFモデルの設計者がRFC 3411サブシステムと抽象サービスインターフェイス（ASIS）と互換性のあるものにするためのガイダンスとして使用されます。実装者の実装は異なる方法で自由に実装できます。これらの小文字の用語のいくつかの使用法は、単に通常の英語の使用です。
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関連の仕様との一貫性のために、このドキュメントは、同じ用語の異なるバリエーションを使用する非SNMP仕様と一致する用語を支持するのではなく、STD 62で定義されている用語を好みます。これは、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.
このドキュメントの認証とは、通常、データソース認証やピアアイデンティティ認証ではなく、メッセージの信ity性を証明するために「役立つ」という英語の意味を指します。
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.
「マネージャー」と「エージェント」という用語は、このドキュメントでは使用されません。RFC3411アーキテクチャでは、すべてのSNMPエンティティがエンジンに含まれるSNMPアプリケーションに応じて、マネージャー、エージェント、またはその両方として機能する機能を備えているためです。区別が必要な場合、コマンドジェネレーターのアプリケーション名、コマンドレスポンダー、通知オリジネーター、通知レシーバー、およびプロキシフォワーダーが使用されます。詳細については、「Simple Network Management Protocol（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]およびこのメモで使用される用語は「プリンシパル」です。校長とは、「WHO」に代わって提供されるか、処理が行われます。プリンシパルは、とりわけ、特定の役割で行動する個人、それぞれが特定の役割で行動する個人のセット、アプリケーションまたはアプリケーションのセット、または管理領域内のこれらの組み合わせです。
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アーキテクチャの説明を読み、理解することが期待されています。また、「Simple Network Management Protocol（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. セキュリティモデルは、SNMPアーキテクチャの変更を必要としないでください。
5. A Security Model SHOULD NOT require changes to the underlying security protocol.
5. セキュリティモデルは、基礎となるセキュリティプロトコルの変更を必要としないでください。
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.
Transport Securityモデルは、セキュリティサブシステムのセキュリティモデルとして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]で説明されているTMSTATEREFEREUNTキャッシュに渡されます。RFC 3411のモジュール性を維持するために、トランスポートモデルはどのセキュリティモデルが着信メッセージを処理するかを知りません。メッセージ処理モデルがこれを決定します。輸送セキュリティモデルが非セキュアトランスポートモデルで使用されている場合、キャッシュは存在しないか、セキュリティパラメーターが存在しないため、輸送セキュリティモデルにエラーが返されます（セクション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.
トランスポートセキュリティモデルは、アプリケーションに渡されるSecurityNameと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 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.
BCP 74 [RFC3584]で説明されているSNMPV1およびSNMPV2Cメッセージ処理は、常にSNMPV1（1）およびSNMPV2C（2）セキュリティモデルを選択します。RFC 3584には代替セキュリティモデルを選択するメカニズムが定義されていないため、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フィールドからセキュリティモデルを抽出します。この値がTransportSecurityModel（4）の場合、セキュリティ処理はトランスポートセキュリティモデルに向けられます。Transport Securityモデルを使用して発信メッセージを保護するには、アプリケーションはSendPDU Abstract Service Interface（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がSecurityNameのトランスポートモデルのプレフィックスを準備するかどうかを構成できます。これにより、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]など、TMSTATEREFFERECEを処理する方法を知っている輸送モデルでのみ使用する必要があります。
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つのレベルがあります。リクエスト応答ペアをリンクする即時状態と、輸送とセキュリティに関連する潜在的に長期的な状態です。「シンプルネットワーク管理プロトコル（SNMP）の輸送サブシステム」[RFC5590]は、キャッシュと参照の一般的な要件を定義します。
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.
トランスポートセキュリティモデルは、ProcessIncomingMsg ASIから受信したTMSTATEREFEULEをSecurityStateReferenceに追加します。このtmStateReferenceは、輸送モデルに渡すことができるように、Generateresponsemsg asi中に取得できます。
For outgoing messages, the Transport Security Model uses parameters provided by the SNMP application to look up or create a tmStateReference.
発信メッセージの場合、Transport Securityモデルは、SNMPアプリケーションによって提供されるパラメーターを使用して、TMSTATEREFERENTを検索または作成します。
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の一部として保存されているTMSTATEREFERENTを使用します。回答とレポートについては、このセキュリティモデルは、TMSTATEREFENEREでTMSAMESECURTYフラグをTRUEに設定してから、輸送モデルに渡します。
For incoming messages, the Transport Security Model uses parameters provided in the tmStateReference cache to establish a securityName, and to verify adequate security levels.
着信メッセージの場合、Transport Securityモデルは、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ベースの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に設定されている場合、輸送セキュリティモデルによって提供または提供されるすべてのセキュリティ名が有効なトランスポートドメインプレフィックスを含める必要があります。
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に設定されている場合、輸送セキュリティモデルが提供または提供するすべてのセキュリティ名は、トランスポートドメインのプレフィックスを含めてはなりません。
The tmSecurityName in the tmStateReference stored as part of the securityStateReference does not contain a prefix.
SecurityStateReferenceの一部として保存されているTMSTateReferenceのtmsecurityNameには、プレフィックスが含まれていません。
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.
エラー表示は、オブジェクト識別子（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.
メッセージを生成するために必要なパラメーターは、GenerateReponsemsg（）ASIを介してメッセージ処理モデルによってセキュリティモデルに提供されます。トランスポートサブシステムアーキテクチャの拡張により、TransportDomain、TransportAddress、およびTMSTateReferenceパラメーターが元のRFC 3411 ASISに追加されました。
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 = -- success or errorIndication
generateResponseMsg(
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
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.
1. SecurityStateReference（応答またはレポートメッセージ）がある場合、このセキュリティモデルは、ASIが提供する情報ではなく、キャッシュされた情報を使用します。SecurityStateReferenceキャッシュからtmStateReferenceを抽出します。抽出されたtmtransportsecuritylevelの値にtmrequestedsecurityLevelを設定します。tmStateReferenceキャッシュのtmsamesecurityパラメーターをtrueに設定します。このメッセージの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キャッシュを作成します。tmtransportdomainは、Transportdomainの価値、TmtransportaddressをTransportAddressの価値に設定し、TmRequestedSecurityLevelをSecurityLevelの価値に再クエストします。（実装者は、これらのセッション固有の値のコピーが保存されたことを指して最適化する場合があります。）トランザクション固有のTMSAMESセキュリティパラメーターをfalseに設定します。
If the snmpTsmConfigurationUsePrefix object is set to false, then set tmSecurityName to the value of securityName.
snmptsmconfigurationuseprefixオブジェクトがfalsに設定されている場合、tmsecurityNameを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).
SNMPTSMCONFIGURATIONSUSEPREFIXオブジェクトが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.
ルックアップが成功しますが、securityNameにプレフィックスがない場合、または返されたプレフィックスがセキュリティ名のプレフィックスと一致しない場合、またはプレフィックスの長さが1つ以下または4つのUS-ASCII Alpha-Numeric文字を超えています。SNMPTSMINVALIDPREFIXESカウンターが増加し、エラー表示が呼び出しモジュールに返され、メッセージ処理が停止します。
Strip the transport-specific prefix and trailing ':' character (US-ASCII 0x3a) from the securityName. Set tmSecurityName to the value of securityName.
SecurityNameからトランスポート固有のプレフィックスとTrailing '：'文字（US-ASCII 0x3a）を剥ぎ取ります。tmsecurityNameをSecurityNameの値に設定します。
3. Set securityParameters to a zero-length OCTET STRING ('0400').
3. SecurityParametersをゼロの長さのOctet String（ '0400'）に設定します。
4. Combine the message parts into a wholeMsg and calculate wholeMsgLength.
4. メッセージパーツをwholemsgに組み合わせて、glemsglengthを計算します。
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.
エラーの表示により、OIDと値が戻ってきたカウンターの値、セキュリティレベルの値、コンテキストEngineIDの値とカウンターのコンテキスト名、およびこの情報がエラーが検出されたポイントで利用可能な場合、セキュリティの観測が可能になります。
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
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
1. Set the securityEngineID to the local snmpEngineID.
1. SecurityEngineIDをローカルSNMPENGINEIDに設定します。
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カウンターが増加します。
3. Copy the tmSecurityName to securityName.
3. tmsecurityNameをSecurityNameにコピーします。
If the snmpTsmConfigurationUsePrefix object is set to true, then use the tmTransportDomain to look up the corresponding prefix.
snmptsmconfigurationuseprefixオブジェクトがtrueに設定されている場合、tmtransportdomainを使用して対応するプレフィックスを検索します。
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.
ルックアップが成功したが、プレフィックスの長さが4オクテットより1未満である場合、SNMPTSMINVALIDPREFIXESカウンターが増加し、呼び出しモジュールにエラー表示が返され、メッセージ処理が停止します。
Set the securityName to be the concatenation of the prefix, a ':' character (US-ASCII 0x3a), and the tmSecurityName.
SecurityNameをプレフィックス、 '：'文字（us-ascii 0x3a）、およびtmsecurityNameの連結に設定します。
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. tmStateReferenceキャッシュのtmtransportsecuritylevelの値を、ProcessincomingMsg ASIで渡されたSecurityLevelパラメーターの値と比較します。SecurityLevelがプライバシー（PRIV）とTMTRANSPORTSECURTYLEVELがプライバシー（NOPRIV）を指定しない場合、またはSecurityLevelが認証（AUTH）を指定し、TMTransportSecurityLevelが輸送モデル、そしてSNMPTSMINADECURATELEVELS COUTIONによって提供されていない場合（NOAUTH）を指定した場合UnsupportedSecurityLevel）は、Incremented Counterの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としてキャッシュされているため、このメッセージに対する可能な応答が同じセキュリティパラメーターを使用します。次に、このキャッシュされたデータへのその後の参照にセキュリティ測定が設定されます。
6. The scopedPDU component is extracted from the wholeMsg.
6. scopedpduコンポーネントは、wholemsgから抽出されます。
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で指定されているように、Calling Moduleが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.
このサブツリーには、管理者がアプリケーションで使用するためにセキュリティ名に準備されたトランスポートドメインのプレフィックスが必要かどうかを指定できる構成オブジェクトが含まれています。
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 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.
他のMIBモジュールで定義されている一部の管理オブジェクトは、トランスポートセキュリティモデルを実装するエンティティに適用できます。特に、トランスポートセキュリティモデルを実装するエンティティは、SNMP-Framework-MIB [RFC3411]、SNMP-Target-MIB [RFC3413]、SNMP-ViewベースのACM-MIB [RFC3415]を実装すると想定されています。およびsnmpv2-mib [rfc3418]。これらは、SNMP-TSM-MIBを実装するために必要はありません。
The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580].
次のMIBモジュールは、[RFC2578]、[RFC2579]、および[RFC2580]からアイテムをインポートします。
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-SMIからモジュール同一性、オブジェクトタイプ、MIB-2、Counter32をインポート - RFC2578モジュールコンプライアンス、SNMPV2-CONF-RFC2580 SNMPV2-TCからのTruthValue-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モジュールIDINTITY最終アップデーション「2009060900Z」組織「ISMSワーキンググループ」ワーキンググループ「連絡先」wg-email：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 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
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany 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
編集者：David Harrington Huawei Technologies USA 1700 Alma Dr. Plano 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.
Wes Hardaker Cobham Analytic Solutions P.O.Box 382 Davis、CA 95617 USA 1 530 792 1913 ietf@hardakers.net "説明"輸送セキュリティモデル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.
自己完結型ドキュメントを使用するためのRFC 3411の設計決定に沿って、このMIBモジュールの定義を含むRFCには、SNMPの輸送セキュリティモデルを処理するために必要な手順の要素も含まれています。これらのMIBオブジェクトは、他のドキュメントで定義されている他のサブシステムまたはモデルを介して変更されるべきではありません。これにより、SNMPの輸送セキュリティモデルを独立して自己完結型として設計および文書化することができ、他のモジュールに直接影響を与えません。他のモジュールとは異なるタイムラインで。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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.
このソフトウェアは、著作権所有者と貢献者が「現状のまま」と、特定の目的に対する黙示の保証と黙示的または黙示的な保証が提供されますが、これらに限定されない保証が提供されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
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."
リビジョン「200906090000Z」説明「RFC 5591で公開されている初期バージョン。」
::= { 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 counter32 max-access読み取り専用ステータス現在の説明
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
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.
Access Control、通知の生成、プロキシ転送などの目的で、SNMPアプリケーションで認証されたプリンシパル識別子（SecurityName）が使用されます。このセキュリティモデルは、複数の輸送モデルをサポートしています。オペレーターは、一部のトランスポートが他のトランスポートよりも安全であると判断する可能性があるため、このセキュリティモデルは、プリンシパルを認証するために使用されるトランスポートモデルを示すように、SecurityNameのプレフィックスを準備するように構成できます。オペレーターは、アクセスのレベルに関するアプリケーションの決定を下すときに、プレフィックス付きSecurityNameを使用できます。
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)).
このMIBモジュールには、読み取りワイトおよび/またはread-Createの最大アクセス句を備えた管理オブジェクトが多数あります。このようなオブジェクトは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしの非セキュア環境でのセット操作のサポートは、ネットワーク操作に悪影響を与える可能性があります。これらはテーブルとオブジェクトであり、その感度/脆弱性です：o SNMPTSMCONFIGURATIONSUSEPREFIXオブジェクトを変更することができ、サービスの拒否を作成したり、アクセス制御モデル（例えば、ビューベースのアクセス制御）によって許可されていなかった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モジュールの読み取り可能なオブジェクトのいくつか（つまり、アクセスできないこと以外に最大アクセスを備えたオブジェクト）は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのオブジェクトへのアクセスを取得および/または通知することさえ制御し、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を使用して）安全である場合でも、それでもセキュアネットワーク上の誰がアクセス/セット/セット（読み取り/変更/作成/削除/削除）を制御することはできません。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エンティティが、実際に取得または設定する正当な権利を持つプリンシパル（ユーザー）にのみオブジェクトにアクセスできるように適切に構成されていることを保証するのは、顧客/オペレーターの責任です（変更を変更します（変更）/作成/削除）それら。
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.
1. このドキュメントのMIBモジュールのMIBモジュールレジストリにMIB-2の接頭辞を備えた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. SNMP番号スペースレジストリのセキュリティモデルレジストリで、輸送セキュリティモデルを識別する値（4）。これにより、次の値の表が得られます。
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.
編集者は、SSHの洞察を共有してくれたJeffrey Hutzelmanと、既存のドキュメントを単語に照らして組織と明確さを改善してくれた傑出した仕事をしてくれたDave Shieldを共有してくれたことに感謝します。
Additionally, helpful document reviews were received from Juergen Schoenwaelder.
さらに、Juergen Schoenwaelderから有用なドキュメントレビューが受け取られました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「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.、Perkins、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] Harrington、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] Case、J.、Harrington、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] Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（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.
[RFC3414] Blumenthal、U.およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590] Harrington、D。およびJ. Schoenwaelder、「Simple Network Management Protocol（SNMP）の輸送サブシステム」、RFC 5590、2009年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、2002年12月、RFC 3415、RFC 3415。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R。、「単純なネットワーク管理プロトコル（SNMP）の管理情報基盤（MIB）」、STD 62、RFC 3418、2002年12月。
[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] Frye、R.、Levi、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] Harrington、D.、Salowey、J。、およびW. Hardaker、「Secure Shell Transport Model for the Simple Network Management Protocol（SNMP）」、RFC 5592、2009年6月。
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
transportAddress = 192.0.2.1:5162
TransportAddress = 192.0.2.1:5162
securityModel = Transport Security Model
securityName = alice
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.
次の例では、SecurityName「Alice」を使用して、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
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 row：snmptargetparamsname tocr snmptargetparamsmpmodel snmpv3 * snmptargetparamssecuritymodel transportsecuritymodel snmptargetaramsecurityname "alice" alice "snmptargetparamsecurity snmptargedageparedageparedageparegparedageparegparegparedageparegparegparegparedageparegparegparegparegparegparegparegparegpared
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
)
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の値から作成されたTMSTATEREFERENT CACHEを使用して、適切な輸送接続を選択します。
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メッセージをデコードすると、セキュリティ処理が起動します。、整合性チェック、およびモデルに依存しないパラメーターへのパラメーターの翻訳。比較すると、Secure Transportは、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と安全な輸送で同じです。
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) モデルに依存しないパラメーターを使用して、復号化された部分を渡します。
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で、認証されたアイデンティティ（SSHユーザー名）から人間に優しい識別子（TMSECURITYNAME）への翻訳を提供します。セキュリティモデルは、その識別子からモデルに依存しないセキュリティ名へのマッピング。
Authors' Addresses
著者のアドレス
David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
David Harrington Huawei Technologies（USA）1700 Alma Dr. Suite 100 Plano、TX 75075 USA
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US
Wes Hardaker Cobham Analytic Solutions P.O.Box 382 Davis、CA 95617 US
Phone: +1 530 792 1913
EMail: ietf@hardakers.net