[要約] RFC 5953は、SNMPのためのTLSトランスポートモデルを定義しています。その目的は、SNMP通信のセキュリティを向上させることです。
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 5953 SPARTA, Inc.
Category: Standards Track August 2010
ISSN: 2070-1721
Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
シンプルなネットワーク管理プロトコル（SNMP）の輸送層セキュリティ（TLS）輸送モデル
Abstract
概要
This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.
このドキュメントでは、トランスポートレイヤーセキュリティプロトコルまたはデータグラムトランスポートレイヤーセキュリティ（DTLS）プロトコルのいずれかを使用する単純なネットワーク管理プロトコル（SNMP）のトランスポートモデルについて説明します。TLSおよびDTLSプロトコルは、SNMPアプリケーションに認証とプライバシーサービスを提供します。このドキュメントでは、TLSトランスポートモデル（TLSTM）が、この保護を相互運用可能な方法で可能にするために、SNMP輸送サブシステムの必要な機能をどのように実装するかについて説明します。
This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.
この輸送モデルは、ネットワーク管理者のセキュリティと運用上のニーズを満たすように設計されています。TLS/TCPおよびDTLS/UDPを介したSNMPメッセージの送信をサポートします。TLSモードは、より大きなパケットサイズのTCPの改善されたサポートを利用でき、DTLSモードは、接続のない（UDP）輸送が好ましい環境で潜在的に優れた動作を提供します。TLSとDTLの両方が、既存の公共キーイングインフラストラクチャによく統合されます。
This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP.
このドキュメントでは、ネットワーク管理プロトコルで使用する管理情報ベース（MIB）の一部も定義しています。特に、SNMPのTLS輸送モデルを管理するためのオブジェクトを定義します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5953.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5953で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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としての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions ................................................7
2. The Transport Layer Security Protocol ...........................8
3. How the TLSTM Fits into the Transport Subsystem .................8
3.1. Security Capabilities of this Model .......................10
3.1.1. Threats ............................................10
3.1.2. Message Protection .................................11
3.1.3. (D)TLS Connections .................................12
3.2. Security Parameter Passing ................................13
3.3. Notifications and Proxy ...................................13
4. Elements of the Model ..........................................14
4.1. X.509 Certificates ........................................14
4.1.1. Provisioning for the Certificate ...................14
4.2. (D)TLS Usage ..............................................16
4.3. SNMP Services .............................................17
4.3.1. SNMP Services for an Outgoing Message ..............17
4.3.2. SNMP Services for an Incoming Message ..............18
4.4. Cached Information and References .........................19
4.4.1. TLS Transport Model Cached Information .............19
4.4.1.1. tmSecurityName ............................19
4.4.1.2. tmSessionID ...............................20
4.4.1.3. Session State .............................20
5. Elements of Procedure ..........................................20
5.1. Procedures for an Incoming Message ........................20
5.1.1. DTLS over UDP Processing for Incoming Messages .....21
5.1.2. Transport Processing for Incoming SNMP Messages ....22
5.2. Procedures for an Outgoing SNMP Message ...................24
5.3. Establishing or Accepting a Session .......................25
5.3.1. Establishing a Session as a Client .................25
5.3.2. Accepting a Session as a Server ....................27
5.4. Closing a Session .........................................28
6. MIB Module Overview ............................................29
6.1. Structure of the MIB Module ...............................29
6.2. Textual Conventions .......................................29
6.3. Statistical Counters ......................................29
6.4. Configuration Tables ......................................29
6.4.1. Notifications ......................................30
6.5. Relationship to Other MIB Modules .........................30
6.5.1. MIB Modules Required for IMPORTS ...................30
7. MIB Module Definition ..........................................30
8. Operational Considerations .....................................53
8.1. Sessions ..................................................53
8.2. Notification Receiver Credential Selection ................54
8.3. contextEngineID Discovery .................................54
8.4. Transport Considerations ..................................55
9. Security Considerations ........................................55
9.1. Certificates, Authentication, and Authorization ...........55
9.2. (D)TLS Security Considerations ............................56
9.2.1. TLS Version Requirements ...........................56
9.2.2. Perfect Forward Secrecy ............................56
9.3. Use with SNMPv1/SNMPv2c Messages ..........................56
9.4. MIB Module Security .......................................57
10. IANA Considerations ...........................................58
11. Acknowledgements ..............................................59
12. References ....................................................60
12.1. Normative References .....................................60
12.2. Informative References ...................................61
Appendix A. Target and Notification Configuration Example ........63
A.1. Configuring a Notification Originator .....................63
A.2. Configuring TLSTM to Utilize a Simple Derivation of
tmSecurityName ............................................64
A.3. Configuring TLSTM to Utilize Table-Driven Certificate
Mapping ...................................................64
It is important to understand the modular SNMPv3 architecture as defined by [RFC3411] and enhanced by the Transport Subsystem [RFC5590]. It is also important to understand the terminology of the SNMPv3 architecture in order to understand where the Transport Model described in this document fits into the architecture and how it interacts with the other architecture subsystems. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of [RFC3410].
[RFC3411]で定義され、輸送サブシステム[RFC5590]によって強化されたモジュラーSNMPV3アーキテクチャを理解することが重要です。また、このドキュメントで説明されている輸送モデルがアーキテクチャに適合する場所と、それが他のアーキテクチャサブシステムとどのように相互作用するかを理解するために、SNMPV3アーキテクチャの用語を理解することも重要です。現在のインターネット標準管理フレームワークを説明するドキュメントの詳細な概要については、[RFC3410]のセクション7を参照してください。
This document describes a Transport Model that makes use of the Transport Layer Security (TLS) [RFC5246] and the Datagram Transport Layer Security (DTLS) Protocol [RFC4347], within a Transport Subsystem [RFC5590]. DTLS is the datagram variant of the Transport Layer Security (TLS) protocol [RFC5246]. The Transport Model in this document is referred to as the Transport Layer Security Transport Model (TLSTM). TLS and DTLS take advantage of the X.509 public keying infrastructure [RFC5280]. While (D)TLS supports multiple authentication mechanisms, this document only discusses X.509 certificate-based authentication. Although other forms of authentication are possible, they are outside the scope of this specification. This transport model is designed to meet the security and operational needs of network administrators, operating in both environments where a connectionless (e.g., UDP) transport is preferred and in environments where large quantities of data need to be sent (e.g., over a TCP-based stream). Both TLS and DTLS integrate well into existing public keying infrastructures. This document supports sending of SNMP messages over TLS/TCP and DTLS/UDP.
このドキュメントでは、トランスポートサブシステム[RFC5590]内で、トランスポートレイヤーセキュリティ（TLS）[RFC5246]およびデータグラムトランスポートレイヤーセキュリティ（DTLS）プロトコル[RFC4347]を使用する輸送モデルについて説明します。DTLSは、トランスポートレイヤーセキュリティ（TLS）プロトコル[RFC5246]のデータグラムバリアントです。このドキュメントの輸送モデルは、輸送層セキュリティ輸送モデル（TLSTM）と呼ばれます。TLSとDTLSは、X.509パブリックキーイングインフラストラクチャ[RFC5280]を活用しています。（d）TLSは複数の認証メカニズムをサポートしていますが、このドキュメントではX.509証明書ベースの認証のみについて説明します。他の形式の認証は可能ですが、それらはこの仕様の範囲外です。この輸送モデルは、ネットワーク管理者のセキュリティと運用上のニーズを満たすように設計されており、接続のない（UDP）輸送が好ましい両方の環境で動作し、大量のデータを送信する必要がある環境（例：TCP-を超えて - ベースのストリーム）。TLSとDTLの両方が、既存の公共キーイングインフラストラクチャによく統合されます。このドキュメントは、TLS/TCPおよびDTLS/UDPを介したSNMPメッセージの送信をサポートしています。
This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP.
このドキュメントでは、ネットワーク管理プロトコルで使用する管理情報ベース（MIB）の一部も定義しています。特に、SNMPのTLS輸送モデルを管理するためのオブジェクトを定義します。
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: [RFC2578], [RFC2579], and [RFC2580].
管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアからアクセスされます。MIBオブジェクトは通常、単純なネットワーク管理プロトコル（SNMP）からアクセスされます。MIBのオブジェクトは、管理情報の構造（SMI）で定義されたメカニズムを使用して定義されます。このメモは、STD 58：[RFC2578]、[RFC2579]、および[RFC2580]に記載されているSMIV2に準拠したMIBモジュールを指定します。
The diagram shown below gives a conceptual overview of two SNMP entities communicating using the TLS Transport Model (shown as "TLSTM"). One entity contains a command responder and notification originator application, and the other a command generator and notification receiver application. It should be understood that this particular mix of application types is an example only and other combinations are equally valid.
以下に示す図は、TLSトランスポートモデルを使用して通信する2つのSNMPエンティティの概念的概要を示しています（「TLSTM」として表示）。1つのエンティティには、コマンドレスポンダーおよび通知オリジナルアプリケーションが含まれ、もう1つはコマンドジェネレーターと通知受信者アプリケーションを含みます。アプリケーションタイプのこの特定の組み合わせは例のみであり、他の組み合わせが等しく有効であることを理解する必要があります。
Note: this diagram shows the Transport Security Model (TSM) being used as the security model that is defined in [RFC5591].
注：この図は、[RFC5591]で定義されているセキュリティモデルとして使用されている輸送セキュリティモデル（TSM）を示しています。
+---------------------------------------------------------------------+
| Network |
+---------------------------------------------------------------------+
^ | ^ |
|Notifications |Commands |Commands |Notifications
+---|---------------------|-------+ +--|---------------|--------------+
| | V | | | V |
| +------------+ +------------+ | | +-----------+ +----------+ |
| | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | |
| | (Client) | | (Server) | | | | (Client) | | (Server) | |
| +------------+ +------------+ | | +-----------+ +----------+ |
| ^ ^ | | ^ ^ |
| | | | | | | |
| +-------------+ | | +--------------+ |
| +-----|------------+ | | +-----|------------+ |
| | V | | | | V | |
| | +--------+ | +-----+ | | | +--------+ | +-----+ |
| | | TLS TM |<--------->|Cache| | | | | TLS TM |<--------->|Cache| |
| | +--------+ | +-----+ | | | +--------+ | +-----+ |
| |Transport Subsys. | ^ | | |Transport Subsys. | ^ |
| +------------------+ | | | +------------------+ | |
| ^ | | | ^ | |
| | +--+ | | | +--+ |
| v | | | V | |
| +-----+ +--------+ +-------+ | | | +-----+ +--------+ +-------+ | |
| | | |Message | |Securi.| | | | | | |Message | |Securi.| | |
| |Disp.| |Proc. | |Subsys.| | | | |Disp.| |Proc. | |Subsys.| | |
| | | |Subsys. | | | | | | | | |Subsys. | | | | |
| | | | | | | | | | | | | | | | | |
| | | | +----+ | | +---+ | | | | | | | +----+ | | +---+ | | |
| | <--->|v3MP|<--> |TSM|<--+ | | | <--->|v3MP|<--->|TSM|<--+ |
| | | | +----+ | | +---+ | | | | | | +----+ | | +---+ | |
| | | | | | | | | | | | | | | |
| +-----+ +--------+ +-------+ | | +-----+ +--------+ +-------+ |
| ^ | | ^ |
| | | | | |
| +-+------------+ | | +-+----------+ |
| | | | | | | |
| v v | | v V |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| | COMMAND | | NOTIFICAT. | | | | COMMAND | | NOTIFICAT. | |
| | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | |
| | application | | application | | | | application | | application | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| SNMP entity | | SNMP entity |
+---------------------------------+ +---------------------------------+
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. 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 a Full Standard.
SNMP関連の仕様との一貫性のために、このドキュメントは、非SNMP仕様と一致する用語を支持するのではなく、STD 62で定義されている用語を好みます。これは、SNMPV3がSNMPV3が完全な標準に昇格したときに、他の非SNMP仕様の使用に一致するようにSNMPV3用語を変更する必要がないという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 [RFC3411] architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP application types supported in the implementation. Where distinction is required, the application names of command generator, command responder, notification originator, notification receiver, and proxy forwarder are used. See "SNMP Applications" [RFC3413] for further information.
[RFC3411]アーキテクチャでは、すべてのSNMPエンティティが、実装でサポートされているSNMPアプリケーションタイプに応じて、すべてのSNMPエンティティがマネージャー、エージェント、またはその両方を行う機能を持っているため、「マネージャー」と「エージェント」という用語はこのドキュメントでは使用されていません。区別が必要な場合、コマンドジェネレーターのアプリケーション名、コマンドレスポンダー、通知オリジネーター、通知レシーバー、およびプロキシ転送業者のアプリケーション名が使用されます。詳細については、「SNMPアプリケーション」[RFC3413]を参照してください。
Large portions of this document simultaneously refer to both TLS and DTLS when discussing TLSTM components that function equally with either protocol. "(D)TLS" is used in these places to indicate that the statement applies to either or both protocols as appropriate. When a distinction between the protocols is needed, they are referred to independently through the use of "TLS" or "DTLS". The Transport Model, however, is named "TLS Transport Model" and refers not to the TLS or DTLS protocol but to the specification in this document, which includes support for both TLS and DTLS.
このドキュメントの大部分は、いずれかのプロトコルで等しく機能するTLSTMコンポーネントを議論する際に、TLSとDTLの両方を同時に参照しています。「（d）TLS」は、これらの場所で使用され、ステートメントが必要に応じていずれかまたは両方のプロトコルに適用されることを示します。プロトコル間の区別が必要な場合、それらは「TLS」または「DTLS」を使用して独立して参照されます。ただし、トランスポートモデルは「TLSトランスポートモデル」と呼ばれ、TLSまたはDTLSプロトコルではなく、TLSとDTLの両方のサポートを含むこのドキュメントの仕様を参照しています。
Throughout this document, the terms "client" and "server" are used to refer to the two ends of the (D)TLS transport connection. The client actively opens the (D)TLS connection, and the server passively listens for the incoming (D)TLS connection. An SNMP entity may act as a (D)TLS client or server or both, depending on the SNMP applications supported.
このドキュメント全体で、「クライアント」と「サーバー」という用語を使用して、（d）TLS輸送接続の両端を参照します。クライアントは（d）TLS接続を積極的に開き、サーバーは受動的に（d）TLS接続を聴きます。SNMPエンティティは、サポートされているSNMPアプリケーションに応じて、（d）TLSクライアントまたはサーバー、またはその両方として機能する場合があります。
The User-Based Security Model (USM) [RFC3414] is a mandatory-to-implement Security Model in STD 62. While (D)TLS and USM frequently refer to a user, the terminology preferred in RFC 3411 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, with each acting in a particular role; an application or a set of applications, or a combination of these within an administrative domain.
ユーザーベースのセキュリティモデル（USM）[RFC3414]はSTD 62の必須のセキュリティモデルです。一方、（d）TLSとUSMはユーザーを頻繁に参照します。主な"。プリンシパルは、その代わりにサービスが提供されるか、処理が行われる「WHO」です。校長は、とりわけ、特定の役割で行動する個人です。それぞれが特定の役割で行動する個人のセット。アプリケーションまたはアプリケーションのセット、または管理ドメイン内のこれらの組み合わせ。
Throughout this document, the term "session" is used to refer to a secure association between two TLS Transport Models that permits the transmission of one or more SNMP messages within the lifetime of the session. The (D)TLS protocols also have an internal notion of a session and although these two concepts of a session are related, when the term "session" is used this document is referring to the TLSTM's specific session and not directly to the (D)TLS protocol's session.
このドキュメント全体を通して、「セッション」という用語は、セッションの寿命内に1つ以上のSNMPメッセージの送信を許可する2つのTLS輸送モデル間の安全な関連性を参照するために使用されます。（d）TLSプロトコルにはセッションの内部概念もあり、セッションのこれら2つの概念は関連していますが、「セッション」という用語が使用される場合、このドキュメントはTLSTMの特定のセッションを指し、（d）に直接参照していません。TLSプロトコルのセッション。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
(D)TLS provides authentication, data message integrity, and privacy at the transport layer (see [RFC4347]).
（d）TLSは、輸送層で認証、データメッセージの整合性、プライバシーを提供します（[RFC4347]を参照）。
The primary goals of the TLS Transport Model are to provide privacy, peer identity authentication and data integrity between two communicating SNMP entities. The TLS and DTLS protocols provide a secure transport upon which the TLSTM is based. Please refer to [RFC5246] and [RFC4347] for complete descriptions of the protocols.
TLSトランスポートモデルの主な目標は、2つの通信SNMPエンティティ間でプライバシー、ピアアイデンティティ認証、およびデータの整合性を提供することです。TLSおよびDTLSプロトコルは、TLSTMの基礎となる安全なトランスポートを提供します。プロトコルの完全な説明については、[RFC5246]および[RFC4347]を参照してください。
A transport model is a component of the Transport Subsystem. The TLS Transport Model thus fits between the underlying (D)TLS transport layer and the Message Dispatcher [RFC3411] component of the SNMP engine.
トランスポートモデルは、トランスポートサブシステムのコンポーネントです。したがって、TLS輸送モデルは、基礎となる（d）TLS輸送層と、SNMPエンジンのメッセージディスパッチャー[RFC3411]コンポーネントの間に適合します。
The TLS Transport Model will establish a session between itself and the TLS Transport Model of another SNMP engine. The sending transport model passes unencrypted and unauthenticated messages from the Dispatcher to (D)TLS to be encrypted and authenticated, and the receiving transport model accepts decrypted and authenticated/ integrity-checked incoming messages from (D)TLS and passes them to the Dispatcher.
TLS輸送モデルは、それ自体と別のSNMPエンジンのTLS輸送モデルとの間のセッションを確立します。送信輸送モデルは、暗号化されていない、派遣されていない無認定のメッセージをディスパッチャーから（d）TLSに暗号化および認証するために通過し、受信輸送モデルは（d）TLSからの復号化および認証/整合性チェックされた受信メッセージを受け入れ、ディスパッチャーに渡します。
After a TLS Transport Model session is established, SNMP messages can conceptually be sent through the session from one SNMP message Dispatcher to another SNMP Message Dispatcher. If multiple SNMP messages are needed to be passed between two SNMP applications they MAY be passed through the same session. A TLSTM implementation engine MAY choose to close the session to conserve resources.
TLSトランスポートモデルセッションが確立された後、SNMPメッセージは、あるSNMPメッセージディスパッチャーから別のSNMPメッセージディスパッチャーにセッションを通じて概念的に送信できます。複数のSNMPメッセージを2つのSNMPアプリケーション間で渡す必要がある場合、同じセッションで渡される場合があります。TLSTM実装エンジンは、リソースを節約するためにセッションを閉じることを選択できます。
The TLS Transport Model of an SNMP engine will perform the translation between (D)TLS-specific security parameters and SNMP-specific, model-independent parameters.
SNMPエンジンのTLS輸送モデルは、（d）TLS固有のセキュリティパラメーターとSNMP固有のモデル非依存性パラメーターとの間の翻訳を実行します。
The diagram below depicts where the TLS Transport Model (shown as "(D)TLS TM") fits into the architecture described in RFC 3411 and the Transport Subsystem:
以下の図は、TLSトランスポートモデル（「（d））TLS TM」として表示される場所で、RFC 3411と輸送サブシステムに記載されているアーキテクチャに適合する場所を示しています。
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-------------------------------------------------------------------+
| +--------------------------------------------------+ |
| | Transport Subsystem | +--------+ |
| | +-----+ +-----+ +-------+ +-------+ | | | |
| | | UDP | | SSH | |(D)TLS | . . . | other |<--->| Cache | |
| | | | | TM | | TM | | | | | | |
| | +-----+ +-----+ +-------+ +-------+ | +--------+ |
| +--------------------------------------------------+ ^ |
| ^ | |
| | | |
| Dispatcher v | |
| +--------------+ +---------------------+ +----------------+ | |
| | Transport | | Message Processing | | Security | | |
| | Dispatch | | Subsystem | | Subsystem | | |
| | | | +------------+ | | +------------+ | | |
| | | | +->| v1MP |<--->| | USM | | | |
| | | | | +------------+ | | +------------+ | | |
| | | | | +------------+ | | +------------+ | | |
| | | | +->| v2cMP |<--->| | Transport | | | |
| | Message | | | +------------+ | | | Security |<--+ |
| | Dispatch <---->| +------------+ | | | Model | | |
| | | | +->| v3MP |<--->| +------------+ | |
| | | | | +------------+ | | +------------+ | |
| | PDU Dispatch | | | +------------+ | | | Other | | |
| +--------------+ | +->| otherMP |<--->| | Model(s) | | |
| ^ | +------------+ | | +------------+ | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
The TLS Transport Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411]:
TLS輸送モデルは、RFC 3411アーキテクチャ[RFC3411]によって特定された脅威に対する保護を提供します。
1. Modification of Information - The modification threat is the danger that an unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object.
1. 情報の修正 - 修正脅威は、許可されていないエンティティが、オブジェクトの価値を偽造することを含む不正な管理操作を実施するような方法で認可されたプリンシパルに代わって生成された輸送中のSNMPメッセージを変更する可能性のある危険です。
(D)TLS provides verification that the content of each received message has not been modified during its transmission through the network, data has not been altered or destroyed in an unauthorized manner, and data sequences have not been altered to an extent greater than can occur non-maliciously.
（d）TLSは、受信した各メッセージのコンテンツがネットワークを介した送信中に変更されておらず、データが不正な方法で変更または破壊されていないことを確認し、データシーケンスは発生するよりも大きい範囲に変更されていないことを確認します。非不当に。
2. Masquerade - The masquerade threat is the danger that management operations unauthorized for a given principal may be attempted by assuming the identity of another principal that has the appropriate authorizations.
2. 仮面舞踏会 - 仮面舞踏会の脅威は、適切な承認を持っている別の元本の身元を仮定することにより、特定のプリンシパルに対して許可されていない管理操作が試みられる可能性があるという危険です。
The TLSTM verifies the identity of the (D)TLS server through the use of the (D)TLS protocol and X.509 certificates. A TLS Transport Model implementation MUST support the authentication of both the server and the client.
TLSTMは、（d）TLSプロトコルとX.509証明書を使用して（d）TLSサーバーのIDを検証します。TLSトランスポートモデルの実装は、サーバーとクライアントの両方の認証をサポートする必要があります。
3. Message stream modification - The re-ordering, delay, or replay of messages can and does occur through the natural operation of many connectionless transport services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent that is greater than can occur through the natural operation of connectionless transport services, in order to effect unauthorized management operations.
3. メッセージストリームの変更 - メッセージの再注文、遅延、またはリプレイは、多くのコネクションレストランスポートサービスの自然操作を通じて発生する可能性があります。メッセージストリームの変更の脅威は、無許可の管理操作を実施するために、コネクションレス輸送サービスの自然な動作を通じて発生するよりも大きい範囲で、メッセージが悪意を持って再注文、遅延、またはリプレイされる危険です。
(D)TLS provides replay protection with a Message Authentication Code (MAC) that includes a sequence number. Since UDP provides no sequencing ability, DTLS uses a sliding window protocol with the sequence number used for replay protection (see [RFC4347]).
（d）TLSは、シーケンス番号を含むメッセージ認証コード（MAC）を備えたリプレイ保護を提供します。UDPはシーケンス機能を提供しないため、DTLSはリプレイ保護に使用されるシーケンス番号を備えたスライディングウィンドウプロトコルを使用します（[RFC4347]を参照）。
4. Disclosure - The disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines.
4. 開示 - 開示の脅威は、SNMPエンジン間の交換を盗聴する危険です。
(D)TLS provides protection against the disclosure of information to unauthorized recipients or eavesdroppers by allowing for encryption of all traffic between SNMP engines. A TLS Transport Model implementation MUST support message encryption to protect sensitive data from eavesdropping attacks.
（d）TLSは、SNMPエンジン間のすべてのトラフィックの暗号化を許可することにより、不正な受信者または盗聴者への情報の開示に対する保護を提供します。TLSトランスポートモデルの実装は、盗聴攻撃から機密データを保護するためにメッセージ暗号化をサポートする必要があります。
5. Denial of Service - the RFC 3411 architecture [RFC3411] states that denial-of-service (DoS) attacks need not be addressed by an SNMP security protocol. However, connectionless transports (like DTLS over UDP) are susceptible to a variety of DoS attacks because they are more vulnerable to spoofed IP addresses. See Section 4.2 for details on how the cookie mechanism is used. Note, however, that this mechanism does not provide any defense against DoS attacks mounted from valid IP addresses.
5. サービスの拒否-RFC 3411アーキテクチャ[RFC3411]は、SNMPセキュリティプロトコルによってサービス拒否（DOS）攻撃に対処する必要はないと述べています。ただし、Connectionless Transports（UDPを超えるDTLなど）は、Spoofed IPアドレスに対してより脆弱であるため、さまざまなDOS攻撃の影響を受けやすくなります。Cookieメカニズムの使用方法の詳細については、セクション4.2を参照してください。ただし、このメカニズムは、有効なIPアドレスから取り付けられたDOS攻撃に対する防御を提供しないことに注意してください。
See Section 9 for more detail on the security considerations associated with the TLSTM and these security threats.
TLSTMおよびこれらのセキュリティの脅威に関連するセキュリティに関する考慮事項の詳細については、セクション9を参照してください。
The RFC 3411 architecture recognizes three levels of security:
RFC 3411アーキテクチャは、3つのレベルのセキュリティを認識しています。
o without authentication and without privacy (noAuthNoPriv)
o 認証なしで、プライバシーなし（noauthnopriv）
o with authentication but without privacy (authNoPriv)
o 認証付きがプライバシーなし（authnopriv）
o with authentication and with privacy (authPriv)
o 認証とプライバシー付き（AuthPriv）
The TLS Transport Model determines from (D)TLS the identity of the authenticated principal, the transport type and the transport address associated with an incoming message. The TLS Transport Model provides the identity and destination type and address to (D)TLS for outgoing messages.
TLS輸送モデルは、（d）から、認証されたプリンシパル、輸送タイプ、および着信メッセージに関連付けられた輸送アドレスのIDから決定します。TLSトランスポートモデルは、発信メッセージの（d）TLSにIDと宛先タイプとアドレスを提供します。
When an application requests a session for a message, it also requests a security level for that session. The TLS Transport Model MUST ensure that the (D)TLS connection provides security at least as high as the requested level of security. How the security level is translated into the algorithms used to provide data integrity and privacy is implementation dependent. However, the NULL integrity and encryption algorithms MUST NOT be used to fulfill security level requests for authentication or privacy. Implementations MAY choose to force (D)TLS to only allow cipher_suites that provide both authentication and privacy to guarantee this assertion.
アプリケーションがメッセージのセッションを要求する場合、そのセッションのセキュリティレベルも要求します。TLS輸送モデルは、（d）TLS接続が、少なくとも要求されたセキュリティレベルと同じくらい高いセキュリティを提供することを保証する必要があります。セキュリティレベルがデータの整合性とプライバシーを提供するために使用されるアルゴリズムにどのように変換されるかは、実装に依存します。ただし、認証またはプライバシーのセキュリティレベルの要求を満たすために、ヌルの整合性と暗号化アルゴリズムを使用してはなりません。実装は、（d）TLSに、認証とプライバシーの両方を提供するCIPHER_SUITESのみを許可するように強制することを選択できます。
If a suitable interface between the TLS Transport Model and the (D)TLS Handshake Protocol is implemented to allow the selection of security-level-dependent algorithms (for example, a security level to cipher_suites mapping table), then different security levels may be utilized by the application.
TLSトランスポートモデルと（d）TLSハンドシェイクプロトコルとの間の適切なインターフェイスが実装されて、セキュリティレベル依存アルゴリズムの選択を可能にする場合（たとえば、CIPHER_SUITESマッピングテーブルに対するセキュリティレベル）、異なるセキュリティレベルを利用できます。アプリケーションによって。
The authentication, integrity, and privacy algorithms used by the (D)TLS Protocols may vary over time as the science of cryptography continues to evolve and the development of (D)TLS continues over time. Implementers are encouraged to plan for changes in operator trust of particular algorithms. Implementations SHOULD offer configuration settings for mapping algorithms to SNMPv3 security levels.
（d）TLSプロトコルで使用される認証、整合性、およびプライバシーアルゴリズムは、暗号化の科学が進化し続け、（d）TLSの開発が時間の経過とともに継続するため、時間とともに時間とともに異なる場合があります。実装者は、特定のアルゴリズムのオペレータートラストの変更を計画することをお勧めします。実装では、アルゴリズムをSNMPV3セキュリティレベルにマッピングするための構成設定を提供する必要があります。
(D)TLS connections are opened by the TLS Transport Model during the elements of procedure for an outgoing SNMP message. Since the sender of a message initiates the creation of a (D)TLS connection if needed, the (D)TLS connection will already exist for an incoming message.
（d）TLS接続は、発信SNMPメッセージの手順要素中にTLS輸送モデルによって開かれます。メッセージの送信者は、必要に応じて（d）TLS接続の作成を開始するため、（d）TLS接続が既に存在します。
Implementations MAY choose to instantiate (D)TLS connections in anticipation of outgoing messages. This approach might be useful to ensure that a (D)TLS connection to a given target can be established before it becomes important to send a message over the (D)TLS connection. Of course, there is no guarantee that a pre-established session will still be valid when needed.
実装は、発信メッセージを見越して（d）TLS接続をインスタンス化することを選択できます。このアプローチは、（d）TLS接続を介してメッセージを送信することが重要になる前に、特定のターゲットへの（d）TLS接続を確立できるようにするために役立つ場合があります。もちろん、事前に確立されたセッションが必要に応じて有効であるという保証はありません。
DTLS connections, when used over UDP, are uniquely identified within the TLS Transport Model by the combination of transportDomain, transportAddress, tmSecurityName, and requestedSecurityLevel associated with each session. Each unique combination of these parameters MUST have a locally chosen unique tlstmSessionID for each active session. For further information, see Section 5. TLS over TCP sessions, on the other hand, do not require a unique pairing of address and port attributes since their lower-layer protocols (TCP) already provide adequate session framing. But they must still provide a unique tlstmSessionID for referencing the session.
DTLS接続は、UDPを介して使用される場合、TLS Transportモデル内でTransportDomain、TransportAddress、TMSECurityName、および各セッションに関連付けられた要求のセキュリティレベルの組み合わせによって一意に識別されます。これらのパラメーターの各ユニークな組み合わせには、アクティブセッションごとにローカルに選択された一意のtlstmsessionIDが必要です。詳細については、セクション5を参照してください。一方、TCPセッションに関するTLSは、低層プロトコル（TCP）がすでに適切なセッションフレーミングを提供しているため、アドレスとポート属性の一意のペアリングを必要としません。しかし、彼らはまだセッションを参照するためのユニークなtlstmsessionidを提供する必要があります。
The tlstmSessionID MUST NOT change during the entire duration of the session from the TLSTM's perspective, and MUST uniquely identify a single session. As an implementation hint: note that the (D)TLS internal SessionID does not meet these requirements, since it can change over the life of the connection as seen by the TLSTM (for example, during renegotiation), and does not necessarily uniquely identify a TLSTM session (there can be multiple TLSTM sessions sharing the same D(TLS) internal SessionID).
TLSTMSESSIONIDは、TLSTMの観点からセッションの全期間中に変更されてはならず、単一のセッションを一意に特定する必要があります。実装としてのヒントとして：（d）TLS内部sessionIDはこれらの要件を満たしていないことに注意してください。これは、TLSTM（たとえば、再交渉中）で見られるように接続の寿命にわたって変化する可能性があり、必ずしもユニーに識別されるわけではないことに注意してください。TLSTMセッション（同じD（TLS）内部SESSIONIDを共有する複数のTLSTMセッションがあります）。
For the (D)TLS server-side, (D)TLS-specific security parameters (i.e., cipher_suites, X.509 certificate fields, IP addresses, and ports) are translated by the TLS Transport Model into security parameters for the TLS Transport Model and security model (e.g., tmSecurityLevel, tmSecurityName, transportDomain, transportAddress). The transport-related and (D)TLS-security-related information, including the authenticated identity, are stored in a cache referenced by tmStateReference.
（d）TLSサーバー側の場合、（d）TLS固有のセキュリティパラメーター（すなわち、CIPHER_SUITES、X.509証明書フィールド、IPアドレス、およびポート）は、TLSトランスポートモデルによってTLSトランスポートモデルのセキュリティパラメーターに変換されます。セキュリティモデル（たとえば、tmsecuritylevel、tmsecurityName、TransportDomain、TransportAddress）。輸送関連および（d）認証されたアイデンティティを含む（d）TLS-Security関連情報は、TMSTateReferenceが参照されるキャッシュに保存されます。
For the (D)TLS client side, the TLS Transport Model takes input provided by the Dispatcher in the sendMessage() Abstract Service Interface (ASI) and input from the tmStateReference cache. The (D)TLS Transport Model converts that information into suitable security parameters for (D)TLS and establishes sessions as needed.
（d）TLSクライアント側の場合、TLSトランスポートモデルは、sendmessage（）abstract Serviceインターフェイス（ASI）でディスパッチャーが提供する入力とtmStateReferenceキャッシュからの入力を受け取ります。（d）TLSトランスポートモデルは、その情報を（d）TLSの適切なセキュリティパラメーターに変換し、必要に応じてセッションを確立します。
The elements of procedure in Section 5 discuss these concepts in much greater detail.
セクション5の手順の要素では、これらの概念をより詳細に説明しています。
(D)TLS connections may be initiated by (D)TLS clients on behalf of SNMP applications that initiate communications, such as command generators, notification originators, proxy forwarders. Command generators are frequently operated by a human, but notification originators and proxy forwarders are usually unmanned automated processes. The targets to whom notifications and proxied requests should be sent is typically determined and configured by a network administrator.
（d）TLS接続は、コマンドジェネレーター、通知オリジネーター、プロキシフォワーダーなどの通信を開始するSNMPアプリケーションに代わって（d）TLSクライアントによって開始される場合があります。コマンドジェネレーターは頻繁に人間によって操作されますが、通知オリジネーターとプロキシフォワーダーは通常、無人の自動化されたプロセスです。通知とプロキシリクエストを送信するターゲットは、通常、ネットワーク管理者によって決定され、構成されます。
The SNMP-TARGET-MIB module [RFC3413] contains objects for defining management targets, including transportDomain, transportAddress, securityName, securityModel, and securityLevel parameters, for notification originator, proxy forwarder, and SNMP-controllable command generator applications. Transport domains and transport addresses are configured in the snmpTargetAddrTable, and the securityModel, securityName, and securityLevel parameters are configured in the snmpTargetParamsTable. This document defines a MIB module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to specify a (D)TLS client-side certificate to use for the connection.
SNMP-Target-MIBモジュール[RFC3413]には、通知オリジネーター、プロキシフォワーダー、SNMP制御可能なコマンドジェネレーターアプリケーション用のTransportDomain、TransportAddress、SecurityName、SecurityModel、SecurityLevelパラメーターなどの管理目標を定義するオブジェクトが含まれています。トランスポートドメインと輸送アドレスは、SNMPTARGETADDRTABLEで構成されており、SecurityModel、SecurityName、およびSecurityLevelパラメーターはSNMPTARGETPARAMSTABLEで構成されています。このドキュメントでは、SNMP-Target-MibのSNMPtargetParamstableを拡張して、接続に使用する（d）TLSクライアント側の証明書を指定するMIBモジュールを定義します。
When configuring a (D)TLS target, the snmpTargetAddrTDomain and snmpTargetAddrTAddress parameters in snmpTargetAddrTable SHOULD be set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an appropriate snmpTLSAddress value. When used with the SNMPv3 message processing model, the snmpTargetParamsMPModel column of the snmpTargetParamsTable SHOULD be set to a value of 3. The snmpTargetParamsSecurityName SHOULD be set to an appropriate securityName value and the snmpTlstmParamsClientFingerprint parameter of the snmpTlstmParamsTable SHOULD be set a value that refers to a locally held certificate (and the corresponding private key) to be used. Other parameters, for example, cryptographic configuration such as which cipher_suites to use, must come from configuration mechanisms not defined in this document.
（d）TLSターゲットを構成する場合、snmptargetaddrtaddressパラメーターをsnmptargetaddrtaddressパラメーターをsnmptlstcpdomainまたはsnmpdtlsudpdomainオブジェクトと適切なsnmptlsaddress値に設定する必要があります。SNMPV3メッセージ処理モデルで使用する場合、SNMPTARGETGERMSTABLEのSNMPTARGETGERMSMPMODEL列を3の値に設定する必要があります。SNMPTARGETPARAMSSECURTYNAMEは、適切なセキュリティ名値に設定する必要があり、SNMPTLSTMPARAMSCLIENTFINGERPRINT PARAMETER PARAMETERを設定する必要があります。使用するローカルに保持されている証明書（および対応する秘密鍵）。たとえば、使用するcipher_suitesなどの暗号構成など、他のパラメーターは、このドキュメントで定義されていない構成メカニズムから来る必要があります。
The securityName defined in the snmpTargetParamsSecurityName column will be used by the access control model to authorize any notifications that need to be sent.
SNMPTARGETPARAMSSECURTYNAME列で定義されているセキュリティ名は、アクセス制御モデルによって使用され、送信する必要がある通知を承認します。
This section contains definitions required to realize the (D)TLS Transport Model defined by this document.
このセクションには、このドキュメントで定義された（d）TLS輸送モデルを実現するために必要な定義が含まれています。
(D)TLS can make use of X.509 certificates for authentication of both sides of the transport. This section discusses the use of X.509 certificates in the TLSTM.
（d）TLSは、輸送の両側の認証のためにX.509証明書を使用できます。このセクションでは、TLSTMでのX.509証明書の使用について説明します。
While (D)TLS supports multiple authentication mechanisms, this document only discusses X.509-certificate-based authentication; other forms of authentication are outside the scope of this specification. TLSTM implementations are REQUIRED to support X.509 certificates.
（d）TLSは複数の認証メカニズムをサポートしていますが、このドキュメントではX.509の認証ベースの認証のみについて説明します。他の形式の認証は、この仕様の範囲外です。X.509証明書をサポートするには、TLSTMの実装が必要です。
Authentication using (D)TLS will require that SNMP entities have certificates, either signed by trusted Certification Authorities (CAs), or self signed. Furthermore, SNMP entities will most commonly need to be provisioned with root certificates that represent the list of trusted CAs that an SNMP entity can use for certificate verification. SNMP entities SHOULD also be provisioned with a X.509 certificate revocation mechanism which can be used to verify that a certificate has not been revoked. Trusted public keys from either CA certificates and/or self-signed certificates MUST be installed into the server through a trusted out-of-band mechanism and their authenticity MUST be verified before access is granted.
（d）TLSを使用した認証では、SNMPエンティティには、信頼できる認証当局（CA）によって署名されているか、自己署名された証明書が必要です。さらに、SNMPエンティティは、SNMPエンティティが証明書の検証に使用できる信頼できるCAのリストを表すルート証明書を提供する必要が最も一般的です。SNMPエンティティには、証明書が取り消されていないことを確認するために使用できるX.509証明書の取り消しメカニズムもプロビジョニングする必要があります。CA証明書および/または自己署名証明書のいずれかの信頼できるパブリックキーは、信頼できる帯域外メカニズムを介してサーバーにインストールする必要があり、アクセスが付与される前にそれらの信頼性を確認する必要があります。
Having received a certificate from a connecting TLSTM client, the authenticated tmSecurityName of the principal is derived using the snmpTlstmCertToTSNTable. This table allows mapping of incoming connections to tmSecurityNames through defined transformations. The transformations defined in the SNMP-TLS-TM-MIB include:
接続するTLSTMクライアントから証明書を受け取った後、プリンシパルの認証されたTMSECurityNameは、SNMPTLSTMCERTTOTSNTABLEを使用して導出されます。このテーブルは、定義された変換を介してTMSECurityNamesへの着信接続のマッピングを可能にします。SNMP-TLS-TM-MIBで定義されている変換には次のものがあります。
o Mapping a certificate's subjectAltName or CommonName components to a tmSecurityName, or
o 証明書のsubjectaltnameまたはcommonnameコンポーネントをtmsecurityNameにマッピングするか、
o Mapping a certificate's fingerprint value to a directly specified tmSecurityName
o 証明書の指紋値を直接指定されたtmsecurityNameにマッピングする
As an implementation hint: implementations may choose to discard any connections for which no potential snmpTlstmCertToTSNTable mapping exists before performing certificate verification to avoid expending computational resources associated with certificate verification.
実装のヒントとして：実装は、証明書の検証に関連する計算リソースの消費を避けるために証明書検証を実行する前に、潜在的なsnmptlstmcerttotsntableマッピングが存在しない接続を破棄することを選択できます。
Deployments SHOULD map the "subjectAltName" component of X.509 certificates to the TLSTM specific tmSecurityNames. The authenticated identity can be obtained by the TLS Transport Model by extracting the subjectAltName(s) from the peer's certificate. The receiving application will then have an appropriate tmSecurityName for use by other SNMPv3 components like an access control model.
展開は、x.509証明書の「subjectaltname」コンポーネントをtlstm固有のtmesecurityNamesにマッピングする必要があります。認証されたアイデンティティは、ピアの証明書からsubjectaltnameを抽出することにより、TLS輸送モデルによって取得できます。受信アプリケーションには、アクセス制御モデルのような他のSNMPV3コンポーネントが使用するための適切なTMSECURITYNAMEがあります。
An example of this type of mapping setup can be found in Appendix A.
このタイプのマッピングセットアップの例は、付録Aにあります。
This tmSecurityName may be later translated from a TLSTM specific tmSecurityName to a SNMP engine securityName by the security model. A security model, like the TSM security model [RFC5591], may perform an identity mapping or a more complex mapping to derive the securityName from the tmSecurityName offered by the TLS Transport Model.
このtmsecurityNameは、後でTLSTM固有のTMESECurityNameから、セキュリティモデルによってSNMPエンジンセキュリティ名に翻訳される場合があります。TSMセキュリティモデル[RFC5591]のようなセキュリティモデルは、TLSトランスポートモデルが提供するTMSECurityNameからSecurityNameを導出するためのIDマッピングまたはより複雑なマッピングを実行する場合があります。
The standard View-Based Access Control Model (VACM) access control model constrains securityNames to be 32 octets or less in length. A TLSTM generated tmSecurityName, possibly in combination with a messaging or security model that increases the length of the securityName, might cause the securityName length to exceed 32 octets. For example, a 32-octet tmSecurityName derived from an IPv6 address, paired with a TSM prefix, will generate a 36-octet securityName. Such a securityName will not be able to be used with standard VACM or TARGET MIB modules. Operators should be careful to select algorithms and subjectAltNames to avoid this situation.
標準ビューベースのアクセス制御モデル（VACM）アクセス制御モデルは、セキュリティ名を32オクテット以下に制限します。TLSTMは、おそらくセキュリティ名の長さを増加させるメッセージングまたはセキュリティモデルと組み合わせて、TMSECURITYNAMEを生成し、セキュリティ名の長さを32オクテットを超える可能性があります。たとえば、TSMプレフィックスとペアになったIPv6アドレスから派生した32-OCTET TMSECURITYNAMEは、36オクテットのセキュリティ名を生成します。このようなセキュリティ名は、標準のVacmまたはターゲットMIBモジュールで使用することはできません。オペレーターは、この状況を回避するために、アルゴリズムと件名を選択するように注意する必要があります。
A pictorial view of the complete transformation process (using the TSM security model for the example) is shown below:
完全な変換プロセスの絵画ビュー（例のTSMセキュリティモデルを使用）を以下に示します。
+-------------+ +-------+ +-----+
| Certificate | | | | |
| Path | | TLSTM | tmSecurityName | TSM |
| Validation | --> | | ----------------->| |
+-------------+ +-------+ +-----+
|
| securityName
V
+-------------+
| application |
+-------------+
(D)TLS MUST negotiate a cipher_suite that uses X.509 certificates for authentication, and MUST authenticate both the client and the server. The mandatory-to-implement cipher_suite is specified in the TLS specification [RFC5246].
（d）TLSは、認証にX.509証明書を使用するCIPHER_SUITEをネゴシエートする必要があり、クライアントとサーバーの両方を認証する必要があります。義務的なcipher_suiteは、TLS仕様[RFC5246]で指定されています。
TLSTM verifies the certificates when the connection is opened (see Section 5.3). For this reason, TLS renegotiation with different certificates MUST NOT be done. That is, implementations MUST either disable renegotiation completely (RECOMMENDED), or they MUST present the same certificate during renegotiation (and MUST verify that the other end presented the same certificate).
TLSTMは、接続が開かれたときに証明書を検証します（セクション5.3を参照）。このため、異なる証明書を使用したTLS再交渉を行う必要はありません。つまり、実装は再交渉を完全に無効にする（推奨）か、再交渉中に同じ証明書を提示する必要があります（また、反対側が同じ証明書を提示したことを確認する必要があります）。
For DTLS over UDP, each SNMP message MUST be placed in a single UDP datagram; it MAY be split to multiple DTLS records. In other words, if a single datagram contains multiple DTLS application_data records, they are concatenated when received. The TLSTM implementation SHOULD return an error if the SNMP message does not fit in the UDP datagram, and thus cannot be sent.
UDPを介したDTLSの場合、各SNMPメッセージは単一のUDPデータグラムに配置する必要があります。複数のDTLSレコードに分割される場合があります。つまり、単一のデータグラムに複数のDTLS Application_Dataレコードが含まれている場合、受信時に連結されます。SNMPメッセージがUDPデータグラムに収まらないため、送信できない場合、TLSTMの実装はエラーを返す必要があります。
For DTLS over UDP, the DTLS server implementation MUST support DTLS cookies ([RFC4347] already requires that clients support DTLS cookies). Implementations are not required to perform the cookie exchange for every DTLS handshake; however, enabling it by default is RECOMMENDED.
UDPを介したDTLSの場合、DTLSサーバーの実装はDTLS Cookieをサポートする必要があります（[RFC4347]では、クライアントがDTLS Cookieをサポートする必要があります）。すべてのDTLSハンドシェイクに対してCookie Exchangeを実行するために実装は必要ありません。ただし、デフォルトで有効にすることをお勧めします。
For DTLS, replay protection MUST be used.
DTLSの場合、リプレイ保護を使用する必要があります。
This section describes the services provided by the TLS Transport Model with their inputs and outputs. The services are between the Transport Model and the Dispatcher.
このセクションでは、TLSトランスポートモデルが入力と出力を備えたサービスについて説明します。サービスは、輸送モデルとディスパッチャーの間です。
The services are described as primitives of an abstract service interface (ASI) and the inputs and outputs are described as abstract data elements as they are passed in these abstract service primitives.
サービスは、抽象サービスインターフェイス（ASI）のプリミティブとして説明されており、入力と出力は、これらの抽象サービスプリミティブで渡されるため、抽象データ要素として説明されます。
The Dispatcher passes the information to the TLS Transport Model using the ASI defined in the Transport Subsystem:
ディスパッチャーは、トランスポートサブシステムで定義されているASIを使用して、情報をTLSトランスポートモデルに渡します。
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state
)
The abstract data elements returned from or passed as parameters into the abstract service primitives are as follows:
抽象的なデータ要素は、抽象サービスのプリミティブからパラメーターとして返されるか、渡されたものは次のとおりです。
statusInformation: An indication of whether the sending of the message was successful. If not, it is an indication of the problem.
StatusInformation：メッセージの送信が成功したかどうかを示しています。そうでない場合、それは問題の兆候です。
destTransportDomain: The transport domain for the associated destTransportAddress. The Transport Model uses this parameter to determine the transport type of the associated destTransportAddress. This document specifies the snmpTLSTCPDomain and the snmpDTLSUDPDomain transport domains.
DestRansportDomain：関連するDestRansportAddressの輸送ドメイン。トランスポートモデルは、このパラメーターを使用して、関連するDestRansportAddressの輸送タイプを決定します。このドキュメントは、snmptlstcpdomainとsnmpdtlsudpdomain輸送ドメインを指定します。
destTransportAddress: The transport address of the destination TLS Transport Model in a format specified by the SnmpTLSAddress TEXTUAL-CONVENTION.
DestRansportAddress：SNMPTLSADDRESS TEXTUAL CONVENTIONによって指定された形式での宛先TLS輸送モデルの輸送アドレス。
outgoingMessage: The outgoing message to send to (D)TLS for encapsulation and transmission.
OutgingMessage：カプセル化と送信のために（d）TLSに送信する発信メッセージ。
outgoingMessageLength: The length of the outgoingMessage.
OutinoveringMessagElength：inoveringMessageの長さ。
tmStateReference: A reference used to pass model-specific and mechanism-specific parameters between the Transport Subsystem and transport-aware Security Models.
TMSTATEREFERENT：トランスポートサブシステムとトランスポート対応セキュリティモデルの間のモデル固有およびメカニズム固有のパラメーターを渡すために使用される参照。
The TLS Transport Model processes the received message from the network using the (D)TLS service and then passes it to the Dispatcher using the following ASI:
TLSトランスポートモデルは、（d）TLSサービスを使用してネットワークから受信したメッセージを処理し、次のASIを使用してディスパッチャーに渡します。
statusInformation =
receiveMessage(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN incomingMessage -- the message received
IN incomingMessageLength -- its length
IN tmStateReference -- reference to transport state
)
The abstract data elements returned from or passed as parameters into the abstract service primitives are as follows:
抽象的なデータ要素は、抽象サービスのプリミティブからパラメーターとして返されるか、渡されたものは次のとおりです。
statusInformation: An indication of whether the passing of the message was successful. If not, it is an indication of the problem.
StatusInformation：メッセージの通過が成功したかどうかを示しています。そうでない場合、それは問題の兆候です。
transportDomain: The transport domain for the associated transportAddress. This document specifies the snmpTLSTCPDomain and the snmpDTLSUDPDomain transport domains.
TransportDomain：関連するTransportAddressの輸送ドメイン。このドキュメントは、snmptlstcpdomainとsnmpdtlsudpdomain輸送ドメインを指定します。
transportAddress: The transport address of the source of the received message in a format specified by the SnmpTLSAddress TEXTUAL-CONVENTION.
TransportAddress：SNMPTLSADDRESS Textual Conventionによって指定された形式で、受信したメッセージのソースの輸送アドレス。
incomingMessage: The whole SNMP message after being processed by (D)TLS.
IncomingMessage：（d）TLSによって処理された後のSNMPメッセージ全体。
incomingMessageLength: The length of the incomingMessage.
IncomingMessagElength：IncomingMessageの長さ。
tmStateReference: A reference used to pass model-specific and mechanism-specific parameters between the Transport Subsystem and transport-aware Security Models.
TMSTATEREFERENT：トランスポートサブシステムとトランスポート対応セキュリティモデルの間のモデル固有およびメカニズム固有のパラメーターを渡すために使用される参照。
When performing SNMP processing, there are two levels of state information that may need to be retained: the immediate state linking a request-response pair, and 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]は、キャッシュと参照の一般的な要件を定義します。
The TLS Transport Model has specific responsibilities regarding the cached information. See the Elements of Procedure in Section 5 for detailed processing instructions on the use of the tmStateReference fields by the TLS Transport Model.
TLSトランスポートモデルには、キャッシュされた情報に関して特定の責任があります。TLSトランスポートモデルによるTMSTATEREFERENTフィールドの使用に関する詳細な処理手順については、セクション5の手順の要素を参照してください。
The tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been set according to the procedures in Section 5. The tmSecurityName MUST be constant for all traffic passing through a single TLSTM session. Messages MUST NOT be sent through an existing (D)TLS connection that was established using a different tmSecurityName.
TMSECURITYNAMEは、セクション5の手順に従って設定されたIDを表す人間が読み取れる名前（SNMPADMINSTRING形式）である必要があります。TMSECURITYNAMEは、単一のTLSTMセッションを通過するすべてのトラフィックに対して一定でなければなりません。メッセージは、別のTMSECURITYNAMEを使用して確立された既存の（d）TLS接続を介して送信してはなりません。
On the (D)TLS server side of a connection, the tmSecurityName is derived using the procedures described in Section 5.3.2 and the SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable DESCRIPTION clause.
接続の（d）TLSサーバー側では、TMSECURTYNAMEはセクション5.3.2で説明されている手順とSNMP-TLS-TM-MIBのSNMPTLSTMCERTTOTSTABLE説明条項を使用して導出されます。
On the (D)TLS client side of a connection, the tmSecurityName is presented to the TLS Transport Model by the security model through the tmStateReference. This tmSecurityName is typically a copy of or is derived from the securityName that was passed by application (possibly because of configuration specified in the SNMP-TARGET-MIB). The Security Model likely derived the tmSecurityName from the securityName presented to the Security Model by the application (possibly because of configuration specified in the SNMP-TARGET-MIB).
接続の（d）TLSクライアント側では、TMSTateReferenceを通じてセキュリティモデルによりTMSECURITYNAMEがTLSトランスポートモデルに提示されます。このtmsecurityNameは、通常、アプリケーションで渡されたセキュリティ名のコピーまたは派生物です（おそらくSNMPターゲット-MIBで指定された構成のため）。セキュリティモデルは、おそらくアプリケーションによってセキュリティモデルに提示されたセキュリティ名からtmsecurityNameを導き出した可能性があります（おそらくSNMPターゲット-MIBで指定された構成のため）。
Transport-Model-aware security models derive tmSecurityName from a securityName, possibly configured in MIB modules for notifications and access controls. Transport Models SHOULD use predictable tmSecurityNames so operators will know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames. The TLSTM generates predictable tmSecurityNames based on the configuration found in the SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable and relies on the network operators to have configured this table appropriately.
Transport-Model-Awareセキュリティモデルは、TMESECURITYNAMEをセキュリティ名から導き出します。これは、通知とアクセス制御のためにMIBモジュールで構成される可能性があります。トランスポートモデルは予測可能なTMESECURITYNAMESを使用する必要があるため、オペレーターはTMSECURTYNAMESから派生したセキュリティ名を使用するMIBモジュールを構成するときに使用するものを知ることができます。TLSTMは、SNMP-TLS-TM-MIBのSNMPTLSTMCERTTOTSNTABLEで見つかった構成に基づいて予測可能なTMSECURITYNAMESを生成し、このテーブルを適切に構成するためにネットワークオペレーターに依存しています。
The tmSessionID MUST be recorded per message at the time of receipt. When tmSameSecurity is set, the recorded tmSessionID can be used to determine whether the (D)TLS connection available for sending a corresponding outgoing message is the same (D)TLS connection as was used when receiving the incoming message (e.g., a response to a request).
TMSESSIONIDは、領収書の時点でメッセージごとに記録する必要があります。TMSAMESECURTYが設定されている場合、記録されたTMESSESSIODを使用して、対応する発信メッセージを送信するために利用可能な（d）TLS接続が同じであるかどうかを判断できます。リクエスト）。
The per-session state that is referenced by tmStateReference may be saved across multiple messages in a Local Configuration Datastore. Additional session/connection state information might also be stored in a Local Configuration Datastore.
TMStateReferenceによって参照されるセッションごとの状態は、ローカル構成データストアの複数のメッセージにわたって保存される場合があります。追加のセッション/接続状態情報は、ローカル構成データストアにも保存される場合があります。
Abstract service interfaces have been defined by [RFC3411] and further augmented by [RFC5590] to describe the conceptual data flows between the various subsystems within an SNMP entity. The TLSTM uses some of these conceptual data flows when communicating between subsystems.
抽象サービスインターフェイスは[RFC3411]によって定義され、さらに[RFC5590]によってさらに増強され、SNMPエンティティ内のさまざまなサブシステム間の概念データフローを説明しています。TLSTMは、サブシステム間で通信するときにこれらの概念データフローの一部を使用します。
To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message gets discarded, the message-state information should also be released. If state information is available when a session is closed, the session state information should also be released. Sensitive information, like cryptographic keys, should be overwritten appropriately prior to being released.
手順の要素を簡素化するために、状態情報のリリースが必ずしも明示的に指定されているとは限りません。一般的なルールとして、メッセージが破棄されたときに状態情報が利用可能な場合、メッセージ状態情報もリリースする必要があります。セッションの閉鎖時に状態情報が利用可能な場合、セッション状態情報もリリースする必要があります。暗号化キーのような機密情報は、リリースされる前に適切に上書きする必要があります。
An error indication in statusInformation will typically include the Object Identifier (OID) and value for an incremented error counter. This may be accompanied by the requested securityLevel and the tmStateReference. Per-message context information is not accessible to Transport Models, so for the returned counter OID and value, contextEngine would be set to the local value of snmpEngineID and contextName to the default context for error counters.
ステータス情報のエラー表示には、通常、オブジェクト識別子（OID）と増分エラーカウンターの値が含まれます。これには、要求されたSecurityLevelとTMStateReferenceが伴う場合があります。輸送モデルには、輸送モデルがアクセスできないため、返されたカウンターOIDと値の場合、コンテキストエンジンはSNMPENGINEIDのローカル値に設定され、コンテキスト名はエラーカウンターのデフォルトコンテキストに設定されます。
This section describes the procedures followed by the (D)TLS Transport Model when it receives a (D)TLS protected packet. The required functionality is broken into two different sections.
このセクションでは、（d）TLS輸送モデルが（d）TLS保護されたパケットを受信したときの手順について説明します。必要な機能は2つの異なるセクションに分割されます。
Section 5.1.1 describes the processing required for de-multiplexing multiple DTLS connections, which is specifically needed for DTLS over UDP sessions. It is assumed that TLS protocol implementations already provide appropriate message demultiplexing.
セクション5.1.1では、複数のDTL接続を除去するために必要な処理について説明します。これは、UDPセッションでのDTLに特に必要です。TLSプロトコルの実装は、すでに適切なメッセージの非複数回表示を提供していると想定されています。
Section 5.1.2 describes the transport processing required once the (D)TLS processing has been completed. This will be needed for all (D)TLS-based connections.
セクション5.1.2では、（d）TLS処理が完了したら、必要な輸送処理について説明します。これは、すべての（d）TLSベースの接続に必要です。
Demultiplexing of incoming packets into separate DTLS sessions MUST be implemented. For connection-oriented transport protocols, such as TCP, the transport protocol takes care of demultiplexing incoming packets to the right connection. For DTLS over UDP, this demultiplexing will either need to be done within the DTLS implementation, if supported, or by the TLSTM implementation.
着信パケットの個別のDTLSセッションへの非難を実装する必要があります。TCPなどの接続指向のトランスポートプロトコルの場合、トランスポートプロトコルは、正しい接続に脱却するパケットを非難するパケットを処理します。UDPを介したDTLSの場合、この非gultiplexingは、サポートされている場合、またはTLSTM実装によってDTLS実装内で行う必要があります。
Like TCP, DTLS over UDP uses the four-tuple <source IP, destination IP, source port, destination port> for identifying the connection (and relevant DTLS connection state). This means that when establishing a new session, implementations MUST use a different UDP source port number for each active connection to a remote destination IP-address/port-number combination to ensure the remote entity can disambiguate between multiple connections.
TCPと同様に、UDPを介したDTLSは、接続（および関連するDTLS接続状態）を識別するために、4タプル<ソースIP、宛先IP、ソースポート、宛先ポート>を使用します。つまり、新しいセッションを確立する場合、実装は、リモートエンティティが複数の接続間で想像できるようにするために、リモートデスティネーションIPアドレス/ポート番号の組み合わせにアクティブな接続ごとに異なるUDPソースポート番号を使用する必要があります。
If demultiplexing received UDP datagrams to DTLS connection state is done by the TLSTM implementation (instead of the DTLS implementation), the steps below describe one possible method to accomplish this.
DEMULTIPLEXINGを受信したUDPデータグラムがDTLS接続状態を（DTLS実装の代わりに）TLSTM実装によって実行される場合、以下の手順は、これを達成するための1つの考えられる方法を説明します。
The important output results from the steps in this process are the remote transport address, incomingMessage, incomingMessageLength, and the tlstmSessionID.
このプロセスのステップからの重要な出力は、リモート輸送アドレス、IncomingMessage、IncomingMessagelength、およびTLSTMSESSIONIDです。
1) The TLS Transport Model examines the raw UDP message, in an implementation-dependent manner.
1) TLSトランスポートモデルは、実装依存的に生のUDPメッセージを調べます。
2) The TLS Transport Model queries the Local Configuration Datastore (LCD) (see [RFC3411] Section 3.4.2) using the transport parameters (source and destination IP addresses and ports) to determine if a session already exists.
2) TLSトランスポートモデルは、輸送パラメーター（ソースおよび宛先IPアドレスとポート）を使用して、ローカル構成データストア（LCD）（[RFC3411]セクション3.4.2を参照）を照会し、セッションが既に存在するかどうかを判断します。
2a) If a matching entry in the LCD does not exist, then the UDP packet is passed to the DTLS implementation for processing. If the DTLS implementation decides to continue with the connection and allocate state for it, it returns a new DTLS connection handle (an implementation dependent detail). In this case, TLSTM selects a new tlstmSessionId, and caches this and the DTLS connection handle as a new entry in the LCD (indexed by the transport parameters). If the DTLS implementation returns an error or does not allocate connection state (which can happen with the stateless cookie exchange), processing stops.
2a）LCDの一致するエントリが存在しない場合、UDPパケットは処理のためにDTLS実装に渡されます。DTLSの実装が接続を続行し、そのために状態を割り当てることを決定した場合、新しいDTLS接続ハンドル（実装依存の詳細）を返します。この場合、TLSTMは新しいTLSTMSESSIONIDを選択し、LCDの新しいエントリとしてこれとDTLS接続ハンドルをキャッシュします（輸送パラメーターによってインデックス化されています）。DTLSの実装がエラーを返したり、接続状態を割り当てない場合（これはStateless Cookie Exchangeで発生する可能性があります）、処理停止が停止します。
2b) If a session does exist in the LCD, then its DTLS connection handle (an implementation dependent detail) and its tlstmSessionId is extracted from the LCD. The UDP packet and the connection handle is passed to the DTLS implementation. If the DTLS implementation returns success but does not return an incomingMessage and an incomingMessageLength then processing stops (this is the case when the UDP datagram contained DTLS handshake messages, for example). If the DTLS implementation returns an error then processing stops.
2b）LCDにセッションが存在する場合、そのDTLS接続ハンドル（実装依存の詳細）とそのTLSTMSESSIONIDがLCDから抽出されます。UDPパケットと接続ハンドルは、DTLS実装に渡されます。DTLSの実装が成功を返しますが、IncomingMessageとIncomingMessagElengthを返さない場合、処理停止が停止します（UDPデータグラムにDTLSハンドシェイクメッセージが含まれていた場合です）。DTLS実装がエラーを返した場合、処理は停止します。
3) Retrieve the incomingMessage and an incomingMessageLength from DTLS. These results and the tlstmSessionID are used below in Section 5.1.2 to complete the processing of the incoming message.
3) DTLSからIncomingMessageとIncomessagElengthを取得します。これらの結果とTLSTMSESSIONIDは、セクション5.1.2の以下で使用され、着信メッセージの処理を完了します。
The procedures in this section describe how the TLS Transport Model should process messages that have already been properly extracted from the (D)TLS stream. Note that care must be taken when processing messages originating from either TLS or DTLS to ensure they're complete and single. For example, multiple SNMP messages can be passed through a single DTLS message and partial SNMP messages may be received from a TLS stream. These steps describe the processing of a singular SNMP message after it has been delivered from the (D)TLS stream.
このセクションの手順では、TLSトランスポートモデルが（d）TLSストリームから既に適切に抽出されているメッセージを処理する方法について説明します。TLSまたはDTLSのいずれかを処理して、それらが完全かつ単一であることを確認するために、注意を払う必要があることに注意してください。たとえば、複数のSNMPメッセージを単一のDTLSメッセージに渡すことができ、TLSストリームから部分的なSNMPメッセージを受信できます。これらの手順は、（d）TLSストリームから配信された後の特異なSNMPメッセージの処理について説明します。
1) Determine the tlstmSessionID for the incoming message. The tlstmSessionID MUST be a unique session identifier for this (D)TLS connection. The contents and format of this identifier are implementation dependent as long as it is unique to the session. A session identifier MUST NOT be reused until all references to it are no longer in use. The tmSessionID is equal to the tlstmSessionID discussed in Section 5.1.1. tmSessionID refers to the session identifier when stored in the tmStateReference and tlstmSessionID refers to the session identifier when stored in the LCD. They MUST always be equal when processing a given session's traffic.
1) 着信メッセージのtlstmsessionidを決定します。TLSTMSESSIONIDは、この（d）TLS接続の一意のセッション識別子でなければなりません。この識別子の内容と形式は、セッションに固有の限り、実装に依存します。セッション識別子は、すべての参照が使用されなくなるまで再利用してはなりません。TMSESSIONIDは、セクション5.1.1で説明したTLSTMSESTIONIDに等しくなります。TMSESSIONIDは、TMSTateReferenceに保存された場合のセッション識別子を参照し、TLSTMSESSIONIDはLCDに保存された場合のセッション識別子を参照します。特定のセッションのトラフィックを処理するときは、常に平等でなければなりません。
If this is the first message received through this session, and the session does not have an assigned tlstmSessionID yet, then the snmpTlstmSessionAccepts counter is incremented and a tlstmSessionID for the session is created. This will only happen on the server side of a connection because a client would have already assigned a tlstmSessionID during the openSession() invocation. Implementations may have performed the procedures described in Section 5.3.2 prior to this point or they may perform them now, but the procedures described in Section 5.3.2 MUST be performed before continuing beyond this point.
これがこのセッションを通じて受信した最初のメッセージであり、セッションにはまだ割り当てられたtlstmsessionIdがない場合、SnmptlstmsessionCectionsカウンターがインクリメントされ、セッションのtlstmsessionIDが作成されます。これは、クライアントがopensession（）の呼び出し中に既にtlstmsessionIdを割り当てていたため、接続のサーバー側でのみ発生します。実装は、この点の前にセクション5.3.2で説明されている手順を実行した場合があります。または、それらを実行する場合がありますが、セクション5.3.2で説明されている手順は、このポイントを超えて継続する前に実行する必要があります。
2) Create a tmStateReference cache for the subsequent reference and assign the following values within it:
2) 後続の参照のためにtmStatereferenceキャッシュを作成し、その中に次の値を割り当てます。
tmTransportDomain = snmpTLSTCPDomain or snmpDTLSUDPDomain as appropriate.
tmtransportdomain = snmptlstcpdomainまたはsnmpdtlsudpdomain必要に応じて。
tmTransportAddress = The address from which the message originated.
tmtransportaddress =メッセージが発信されたアドレス。
tmSecurityLevel = The derived tmSecurityLevel for the session, as discussed in Sections 3.1.2 and 5.3.
TMSECURITYLEVEL =セクション3.1.2および5.3で説明したように、セッションの派生TMSECURITYLEVEL。
tmSecurityName = The derived tmSecurityName for the session as discussed in Section 5.3. This value MUST be constant during the lifetime of the session.
TMSECURITYNAME =セクション5.3で説明したセッションの派生TMSECurityName。この値は、セッションの寿命中に一定でなければなりません。
tmSessionID = The tlstmSessionID described in step 1 above.
TMSESSIONID =上記のステップ1で説明されているTLSTMSESTIONID。
3) The incomingMessage and incomingMessageLength are assigned values from the (D)TLS processing.
3) IncomingMessageとIncomingMessagelengthは、（d）TLS処理から値が割り当てられます。
4) The TLS Transport Model passes the transportDomain, transportAddress, incomingMessage, and incomingMessageLength to the Dispatcher using the receiveMessage ASI:
4) TLSトランスポートモデルは、ReceiveMessage ASIを使用して、TransportDomain、TransportAddress、IncomingMessage、およびIncomingMessagelengthをディスパッチャーに渡します。
statusInformation =
receiveMessage(
IN transportDomain -- snmpTLSTCPDomain or snmpDTLSUDPDomain,
IN transportAddress -- address for the received message
IN incomingMessage -- the whole SNMP message from (D)TLS
IN incomingMessageLength -- the length of the SNMP message
IN tmStateReference -- transport info
)
The Dispatcher sends a message to the TLS Transport Model using the following ASI:
ディスパッチャーは、次のASIを使用してTLSトランスポートモデルにメッセージを送信します。
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- transport info
)
This section describes the procedure followed by the TLS Transport Model whenever it is requested through this ASI to send a message.
このセクションでは、このASIを介してメッセージを送信するように要求されるたびに、TLSトランスポートモデルが続く手順について説明します。
1) If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity, then increment the snmpTlstmSessionInvalidCaches counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops.
1) tmStateReferenceがtmtransportdomain、tmtransportaddress、tmsecurityName、tmrequestedsecuritylevel、およびtmesamesecurityの値を含むキャッシュを参照しない場合、snmptlstmsessioninvalidcaches counterを増やし、メッセージを捨てて、誤差を返します。このメッセージの処理は停止します。
2) Extract the tmSessionID, tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity values from the tmStateReference. Note: the tmSessionID value may be undefined if no session exists yet over which the message can be sent.
2) tmStateReferenceからTMSESSIONID、TMTRANSPORTDOMAIN、TMTRANSPORTADDRESS、TMTRANSPORTADDRESS、TMSECURITYNAME、TMREQUESTEDSECURTYLEVEL、およびTMESMESESCURTY値を抽出します。注：メッセージを送信できるセッションがまだ存在しない場合、TMSESSIONID値は未定義になる場合があります。
3) If tmSameSecurity is true and tmSessionID is either undefined or refers to a session that is no longer open, then increment the snmpTlstmSessionNoSessions counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops.
3) tmsamesecurityが真であり、tmessessionIDが未定義であるか、開いていないセッションを参照している場合、Snmptlstmsessionnosessionsカウンターをインクリメントし、メッセージを破棄し、ステータス情報のエラー表示を返します。このメッセージの処理は停止します。
4) If tmSameSecurity is false and tmSessionID refers to a session that is no longer available, then an implementation SHOULD open a new session, using the openSession() ASI (described in greater detail in step 5b). Instead of opening a new session an implementation MAY return a snmpTlstmSessionNoSessions error to the calling module and stop the processing of the message.
4) tmsamesecurityがfalseであり、tmessessionIDが利用できなくなったセッションを指す場合、実装はOpenSession（）ASIを使用して新しいセッションを開く必要があります（ステップ5Bで詳細に説明）。新しいセッションを開く代わりに、実装によりSNMPTLSTMSESSIONNOSESSIONSエラーが呼び出しモジュールに戻り、メッセージの処理を停止する場合があります。
5) If tmSessionID is undefined, then use tmTransportDomain, tmTransportAddress, tmSecurityName, and tmRequestedSecurityLevel to see if there is a corresponding entry in the LCD suitable to send the message over.
5) TMSESSIONIDが未定義の場合、TMTransportDomain、TMTransportAddress、TMSECURITYNAME、およびTMRequestedSecurityLevelを使用して、メッセージを送信するのに適したLCDに対応するエントリがあるかどうかを確認します。
5a) If there is a corresponding LCD entry, then this session will be used to send the message.
5a）対応するLCDエントリがある場合、このセッションはメッセージの送信に使用されます。
5b) If there is no corresponding LCD entry, then open a session using the openSession() ASI (discussed further in Section 5.3.1). Implementations MAY wish to offer message buffering to prevent redundant openSession() calls for the same cache entry. If an error is returned from openSession(), then discard the message, discard the tmStateReference, increment the snmpTlstmSessionOpenErrors, return an error indication to the calling module, and stop the processing of the message.
5b）対応するLCDエントリがない場合は、OpenSession（）ASIを使用してセッションを開きます（セクション5.3.1でさらに説明します）。実装は、同じキャッシュエントリを要求する冗長オープンセッション（）を防ぐためのメッセージバッファリングを提供する場合があります。opensession（）からエラーが返された場合、メッセージを破棄し、tmStateReferenceを破棄し、snmptlstmsセッションエラーをインクリメントし、呼び出しモジュールへのエラー表示を返し、メッセージの処理を停止します。
6) Using either the session indicated by the tmSessionID (if there was one) or the session resulting from a previous step (4 or 5), pass the outgoingMessage to (D)TLS for encapsulation and transmission.
6) TMSESSIONID（1つがある場合）で示されたセッションまたは前のステップ（4または5）に起因するセッションのいずれかを使用して、カプセル化と送信のために（d）TLSに発信を渡します。
Establishing a (D)TLS connection as either a client or a server requires slightly different processing. The following two sections describe the necessary processing steps.
クライアントまたはサーバーとして（d）TLS接続を確立するには、わずかに異なる処理が必要です。次の2つのセクションでは、必要な処理手順について説明します。
The TLS Transport Model provides the following primitive for use by a client to establish a new (D)TLS connection:
TLSトランスポートモデルは、クライアントが使用するための次の原始を提供して、新しい（d）TLS接続を確立します。
statusInformation = -- errorIndication or success
openSession(
IN tmStateReference -- transport information to be used
OUT tmStateReference -- transport information to be used
IN maxMessageSize -- of the sending SNMP entity
)
The following describes the procedure to follow when establishing an SNMP over a (D)TLS connection between SNMP engines for exchanging SNMP messages. This process is followed by any SNMP client's engine when establishing a session for subsequent use.
以下は、SNMPメッセージを交換するためにSNMPエンジン間の（d）TLS接続を介してSNMPを確立する際に従うべき手順について説明します。このプロセスの後に、その後の使用のためのセッションを確立する際に、SNMPクライアントのエンジンが続きます。
This procedure MAY be done automatically for an SNMP application that initiates a transaction, such as a command generator, a notification originator, or a proxy forwarder.
この手順は、コマンドジェネレーター、通知オリジネーター、プロキシフォワーダーなどのトランザクションを開始するSNMPアプリケーションに対して自動的に実行できます。
1) The snmpTlstmSessionOpens counter is incremented.
1) snmptlstmssossopensカウンターが増加します。
2) The client selects the appropriate certificate and cipher_suites for the key agreement based on the tmSecurityName and the tmRequestedSecurityLevel for the session. For sessions being established as a result of an SNMP-TARGET-MIB based operation, the certificate will potentially have been identified via the snmpTlstmParamsTable mapping and the cipher_suites will have to be taken from a system-wide or implementation-specific configuration. If no row in the snmpTlstmParamsTable exists, then implementations MAY choose to establish the connection using a default client certificate available to the application. Otherwise, the certificate and appropriate cipher_suites will need to be passed to the openSession() ASI as supplemental information or configured through an implementation-dependent mechanism. It is also implementation-dependent and possibly policy-dependent how tmRequestedSecurityLevel will be used to influence the security capabilities provided by the (D)TLS connection. However this is done, the security capabilities provided by (D)TLS MUST be at least as high as the level of security indicated by the tmRequestedSecurityLevel parameter. The actual security level of the session is reported in the tmStateReference cache as tmSecurityLevel. For (D)TLS to provide strong authentication, each principal acting as a command generator SHOULD have its own certificate.
2) クライアントは、セッションのTMSECurityNameとTMRequestedSecurityLevelに基づいて、主要な契約に適切な証明書とCIPHER_SUITESを選択します。SNMP-Target-MIBベースの操作の結果としてセッションが確立される場合、証明書はSNMPTLSTMPARAMSTABLEマッピングを介して特定される可能性があり、CIPHER_SUITESはシステム全体または実装固有の構成から取得する必要があります。SNMPTLSTMPARAMSTABLEに行が存在しない場合、アプリケーションで利用可能なデフォルトのクライアント証明書を使用して、実装が接続を確立することを選択できます。それ以外の場合、証明書と適切なCIPHER_SUITESは、補足情報としてOpenSession（）ASIに渡すか、実装依存メカニズムを介して構成する必要があります。また、実装依存性であり、おそらくは、（d）TLS接続によって提供されるセキュリティ機能に影響を与えるためにTMrequestedSecurityLevelを使用する方法もあります。ただし、これは行われていますが、（d）TLSによって提供されるセキュリティ機能は、少なくともTMRequestedSecurityLevelパラメーターで示されるセキュリティレベルと同じくらい高くなければなりません。セッションの実際のセキュリティレベルは、TMSTateReferenceキャッシュでTMSECURITYLEVELとして報告されています。（d）強力な認証を提供するためのTLSの場合、コマンドジェネレーターとして機能する各プリンシパルには独自の証明書が必要です。
3) Using the destTransportDomain and destTransportAddress values, the client will initiate the (D)TLS handshake protocol to establish session keys for message integrity and encryption.
3) DestRansportdomainとDestRansportAddressの値を使用して、クライアントは（d）TLSハンドシェイクプロトコルを開始し、メッセージの整合性と暗号化のためのセッションキーを確立します。
If the attempt to establish a session is unsuccessful, then snmpTlstmSessionOpenErrors is incremented, an error indication is returned, and processing stops. If the session failed to open because the presented server certificate was unknown or invalid, then the snmpTlstmSessionUnknownServerCertificate or snmpTlstmSessionInvalidServerCertificates MUST be incremented and an snmpTlstmServerCertificateUnknown or snmpTlstmServerInvalidCertificate notification SHOULD be sent as appropriate. Reasons for server certificate invalidation includes, but is not limited to, cryptographic validation failures and an unexpected presented certificate identity.
セッションを確立しようとする試みが失敗した場合、snmptlstmsセッションエラーは増加し、エラー表示が返され、処理が停止します。提示されたサーバー証明書が不明または無効であるためにセッションが開くことに失敗した場合、snmptlStmsSessionuncknownServercertificateまたはsnmptlstmsSessioninvalidServervercertificatesを増分し、snmptlStlStmervalidCertificateを必要とする必要があります。サーバー証明書の無効化の理由には、暗号化の検証障害と予期しない提示された証明書IDが含まれますが、これらに限定されません。
4) The (D)TLS client MUST then verify that the (D)TLS server's presented certificate is the expected certificate. The (D)TLS client MUST NOT transmit SNMP messages until the server certificate has been authenticated, the client certificate has been transmitted and the TLS connection has been fully established.
4) （d）TLSクライアントは、（d）TLSサーバーの提示された証明書が予想される証明書であることを確認する必要があります。（d）TLSクライアントは、サーバー証明書が認証され、クライアント証明書が送信され、TLS接続が完全に確立されるまでSNMPメッセージを送信してはなりません。
If the connection is being established from a configuration based on SNMP-TARGET-MIB configuration, then the snmpTlstmAddrTable DESCRIPTION clause describes how the verification is done (using either a certificate fingerprint, or an identity authenticated via certification path validation).
SNMP-Target-MIB構成に基づいた構成から接続が確立されている場合、SNMPTLSTMADDRTABLE説明条項は、検証の実行方法を説明します（証明書指紋または認証パス検証を介して認証されたIDのいずれかを使用）。
If the connection is being established for reasons other than configuration found in the SNMP-TARGET-MIB, then configuration and procedures outside the scope of this document should be followed. Configuration mechanisms SHOULD be similar in nature to those defined in the snmpTlstmAddrTable to ensure consistency across management configuration systems. For example, a command-line tool for generating SNMP GETs might support specifying either the server's certificate fingerprint or the expected host name as a command-line argument.
SNMPターゲット-MIBで見つかった構成以外の理由で接続が確立されている場合、このドキュメントの範囲外の構成と手順に従う必要があります。構成メカニズムは、管理構成システム全体で一貫性を確保するために、SNMPTLSTMADDRTABLEで定義されているものと本質的に類似している必要があります。たとえば、SNMP Getを生成するためのコマンドラインツールは、サーバーの証明書指紋または予想されるホスト名のいずれかをコマンドライン引数として指定することをサポートする場合があります。
5) (D)TLS provides assurance that the authenticated identity has been signed by a trusted configured Certification Authority. If verification of the server's certificate fails in any way (for example, because of failures in cryptographic verification or the presented identity did not match the expected named entity) then the session establishment MUST fail, the snmpTlstmSessionInvalidServerCertificates object is incremented. If the session cannot be opened for any reason at all, including cryptographic verification failures and snmpTlstmCertToTSNTable lookup failures, then the snmpTlstmSessionOpenErrors counter is incremented and processing stops.
5) （d）TLSは、信頼できる設定された認証機関によって認証されたIDが署名されたことを保証します。サーバーの証明書の検証が何らかの形で失敗した場合（たとえば、暗号化の検証または提示されたIDが予想される名前付きエンティティと一致しなかったため）、セッション確立が失敗する必要があります。暗号化検証障害やSNMPTLSTMCERTTOTSTABLEルックアップ障害など、何らかの理由でセッションを開くことができない場合、SNMPTLSTMSESTIONOPENERRORSカウンターが増加し、処理が停止します。
6) The TLSTM-specific session identifier (tlstmSessionID) is set in the tmSessionID of the tmStateReference passed to the TLS Transport Model to indicate that the session has been established successfully and to point to a specific (D)TLS connection for future use. The tlstmSessionID is also stored in the LCD for later lookup during processing of incoming messages (Section 5.1.2).
6) TLSTM固有のセッション識別子（TLSTMSESTIONID）は、TLSトランスポートモデルに渡されたTMSTATEREFENECEのTMSESSIONIDに設定され、セッションが正常に確立されたことを示し、将来の使用のための特定の（D）TLS接続を指すようにします。TLSTMSESSIONIDは、着信メッセージの処理中に後で検索するためにLCDに保存されます（セクション5.1.2）。
A (D)TLS server should accept new session connections from any client for which it is able to verify the client's credentials. This is done by authenticating the client's presented certificate through a certificate path validation process (e.g., [RFC5280]) or through certificate fingerprint verification using fingerprints configured in the snmpTlstmCertToTSNTable. Afterward, the server will determine the identity of the remote entity using the following procedures.
A（d）TLSサーバーは、クライアントの資格情報を確認できるクライアントからの新しいセッション接続を受け入れる必要があります。これは、証明書パス検証プロセス（[RFC5280]など）を通じてクライアントの提示された証明書を認証するか、SNMPTLSTMCERTTOTSNTABLEで構成された指紋を使用した証明書指紋検証を通じて行われます。その後、サーバーは、次の手順を使用してリモートエンティティのIDを決定します。
The (D)TLS server identifies the authenticated identity from the (D)TLS client's principal certificate using configuration information from the snmpTlstmCertToTSNTable mapping table. The (D)TLS server MUST request and expect a certificate from the client and MUST NOT accept SNMP messages over the (D)TLS connection until the client has sent a certificate and it has been authenticated. The resulting derived tmSecurityName is recorded in the tmStateReference cache as tmSecurityName. The details of the lookup process are fully described in the DESCRIPTION clause of the snmpTlstmCertToTSNTable MIB object. If any verification fails in any way (for example, because of failures in cryptographic verification or because of the lack of an appropriate row in the snmpTlstmCertToTSNTable), then the session establishment MUST fail, and the snmpTlstmSessionInvalidClientCertificates object is incremented. If the session cannot be opened for any reason at all, including cryptographic verification failures, then the snmpTlstmSessionOpenErrors counter is incremented and processing stops.
（d）TLSサーバーは、SNMPTLSTMCERTTOTSNTABLEマッピングテーブルからの構成情報を使用して、（d）TLSクライアントの元本証明書から認証されたIDを識別します。（d）TLSサーバーは、クライアントから証明書を要求して期待する必要があり、クライアントが証明書を送信して認証されるまで（d）TLS接続を介してSNMPメッセージを受け入れないでください。結果の導出されたtmsecurityNameは、tmStateReferenceキャッシュにtmsecurityNameとして記録されます。ルックアッププロセスの詳細は、SNMPTLSTMCERTTOTSNTABLE MIBオブジェクトの説明句で完全に説明されています。検証が何らかの方法で失敗した場合（たとえば、暗号化の検証の失敗やSNMPTLSTMCERTTOTSNTABLEに適切な行がないため）、セッション確立が失敗し、SNMPTLSTMSESSIONINVALIDCLIENTCERTIFICATESオブジェクトが増加します。暗号化検証障害を含む何らかの理由でセッションを開くことができない場合、SNMPTLSTMSESTIONOPENERRORSカウンターが増加し、処理が停止します。
Servers that wish to support multiple principals at a particular port SHOULD make use of a (D)TLS extension that allows server-side principal selection like the Server Name Indication extension defined in Section 3.1 of [RFC4366]. Supporting this will allow, for example, sending notifications to a specific principal at a given TCP or UDP port.
特定のポートで複数のプリンシパルをサポートしたいサーバーは、[RFC4366]のセクション3.1で定義されているサーバー名表示拡張機能のようなサーバー側のプリンシパル選択を可能にする（d）TLS拡張機能を使用する必要があります。これをサポートすると、たとえば、特定のTCPまたはUDPポートの特定のプリンシパルに通知を送信できます。
The TLS Transport Model provides the following primitive to close a session:
TLSトランスポートモデルは、セッションを終了するための次の原始を提供します。
statusInformation = closeSession( IN tmSessionID -- session ID of the session to be closed )
StatusInformation = closessession（TMSESSIONIDで - セッションのセッションIDを閉じる）
The following describes the procedure to follow to close a session between a client and server. This process is followed by any SNMP engine closing the corresponding SNMP session.
以下は、クライアントとサーバー間のセッションを閉じるために従う手順について説明します。このプロセスの後に、対応するSNMPセッションを閉じるSNMPエンジンが任意のものです。
1) Increment either the snmpTlstmSessionClientCloses or the snmpTlstmSessionServerCloses counter as appropriate.
1) 必要に応じて、snmptlstmssessionclientclosesまたはsnmptlstmsessionserverclosesのいずれかを増分します。
2) Look up the session using the tmSessionID.
2) TMSESSIONIDを使用してセッションを検索します。
3) If there is no open session associated with the tmSessionID, then closeSession processing is completed.
3) TMSESSIONIDに関連付けられたオープンセッションがない場合、閉鎖処理が完了します。
4) Have (D)TLS close the specified connection. This MUST include sending a close_notify TLS Alert to inform the other side that session cleanup may be performed.
4) （d）指定された接続を閉じます。これには、Close_Notify TLSアラートを送信して、セッションのクリーンアップが実行される可能性があることを反対側に通知する必要があります。
This MIB module provides management of the TLS Transport Model. It defines needed textual conventions, statistical counters, notifications, and configuration infrastructure necessary for session establishment. Example usage of the configuration tables can be found in Appendix A.
このMIBモジュールは、TLS輸送モデルの管理を提供します。必要なテキスト規則、統計カウンター、通知、およびセッションの確立に必要な構成インフラストラクチャを定義します。構成テーブルの使用例は、付録Aにあります。
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モジュールのオブジェクトは、サブツリーに配置されます。各サブツリーは、関連するオブジェクトのセットとして編成されています。サブツリーへのオブジェクトの全体的な構造と割り当て、および各サブツリーの意図された目的を以下に示します。
Generic and Common Textual Conventions used in this module can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html.
このモジュールで使用される一般的および一般的なテキストの規則は、http：//www.ops.ietf.org/mib-common-tcs.htmlにまとめられています。
This module defines the following new Textual Conventions:
このモジュールは、次の新しいテキスト規則を定義します。
o A new TransportAddress format for describing (D)TLS connection addressing requirements.
o （d）TLS接続に対処する要件を説明するための新しいTransportAddress形式。
o A certificate fingerprint allowing MIB module objects to generically refer to a stored X.509 certificate using a cryptographic hash as a reference pointer.
o MIBモジュールオブジェクトが参照ポインターとして暗号化ハッシュを使用して保存されたX.509証明書を一般的に参照できる証明書指紋。
The SNMP-TLS-TM-MIB defines counters that provide network management stations with information about session usage and potential errors that a device may be experiencing.
SNMP-TLS-TM-MIBは、ネットワーク管理ステーションにセッションの使用に関する情報と、デバイスが経験している可能性のある潜在的なエラーに関する情報を提供するカウンターを定義します。
The SNMP-TLS-TM-MIB defines configuration tables that an administrator can use for configuring a device for sending and receiving SNMP messages over (D)TLS. In particular, there are MIB tables that extend the SNMP-TARGET-MIB for configuring (D)TLS certificate usage and a MIB table for mapping incoming (D)TLS client certificates to SNMPv3 tmSecurityNames.
SNMP-TLS-TM-MIBは、管理者が（D）TLSでSNMPメッセージを送信および受信するためにデバイスを構成するために使用できる構成表を定義します。特に、（d）TLS証明書の使用法を構成するためのSNMPターゲット-MIBを拡張するMIBテーブルと、入力をマッピングするためのMIBテーブル（D）TLSクライアント証明書をSNMPV3 TMSECURITYNAMESにマッピングするためのMIBテーブルがあります。
The SNMP-TLS-TM-MIB defines notifications to alert management stations when a (D)TLS connection fails because a server's presented certificate did not meet an expected value (snmpTlstmServerCertificateUnknown) or because cryptographic validation failed (snmpTlstmServerInvalidCertificate).
SNMP-TLS-TM-MIBは、サーバーが提示された証明書が期待値を満たしていなかったため（SNMPTLSTMSERVERCERTIFICATEATEUNNKNOWN）、または暗号化の検証が失敗したため（d）TLS接続が失敗した場合に管理ステーションを警告する通知を定義します（SNMPTLSTMSERVERVERINVALIDCERTIFICATE）。
Some management objects defined in other MIB modules are applicable to an entity implementing the TLS Transport Model. In particular, it is assumed that an entity implementing the SNMP-TLS-TM-MIB will implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], the SNMP-TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413], and the SNMP-VIEW-BASED-ACM-MIB [RFC3415].
他のMIBモジュールで定義されている一部の管理オブジェクトは、TLSトランスポートモデルを実装するエンティティに適用できます。特に、SNMP-TLS-TM-MIBを実装するエンティティは、SNMPV2-MIB [RFC3418]、SNMP-Framework-MIB [RFC3411]、SNMP-Target-MIB [RFC3413]、SNMPを実装すると想定されています。-notification-mib [rfc3413]、およびsnmp-viewベースのacm-mib [rfc3415]。
The SNMP-TLS-TM-MIB module contained in this document is for managing TLS Transport Model information.
このドキュメントに含まれるSNMP-TLS-TM-MIBモジュールは、TLS輸送モデル情報を管理するためのものです。
The SNMP-TLS-TM-MIB module imports items from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB [RFC3413], and SNMPv2-CONF [RFC2580].
SNMP-TLS-TM-MIBモジュールは、SNMPV2-SMI [RFC2578]、SNMPV2-TC [RFC2579]、SNMP-Framework-MIB [RFC3411]、SNMP-Target-MIB [RFC3413]、およびSNMPV22-CONF [RFC2580からアイテムをインポートします。]。
SNMP-TLS-TM-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, snmpDomains, Counter32, Unsigned32, Gauge32, NOTIFICATION-TYPE FROM SNMPv2-SMI -- RFC 2578 or any update thereof TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, AutonomousType FROM SNMPv2-TC -- RFC 2579 or any update thereof MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580 or any update thereof SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 or any update thereof snmpTargetParamsName, snmpTargetAddrName FROM SNMP-TARGET-MIB -- RFC 3413 or any update thereof ;
インポートモジュール同一性、オブジェクトタイプ、オブジェクトアイデンティティ、MIB-2、SNMPDomains、Counter32、unsigned32、Gauge32、Snmpv2-Smi-RFC 2578またはその更新、またはテキスト統合、Timestamp、Rowstatus、Storagetype、snmpv2-tcからのautoloncoustype - RFC 2579またはその更新モジュールコンプライアンス、オブジェクトグループ、snmpv2-confからの通知グループ、またはsnmp-framework-mib-rfc 3411または任意のアップデートからのsnmpadminstringの更新Snmp-Target-Mibからのsnmptargetparamsname、snmptargetaddrname-rfc 3413またはその更新;
snmpTlstmMIB MODULE-IDENTITY LAST-UPDATED "201005070000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org
snmptlstmmib module-identity last-updated "2010050700z" ongumation "isms working group" contact-info "wg-email：isms@lists.ietf.org subscribe：isms-request@lists.ietf.org
Chairs: 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
Russ Mundy SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 USA
Russ Mundy Sparta、Inc。7110 Samuel Morse Drive Columbia、MD 21046 USA
Editor: Wes Hardaker SPARTA, Inc. P.O. Box 382 Davis, CA 95617 USA ietf@hardakers.net "
編集者：Wes Hardaker Sparta、Inc。P.O.Box 382 Davis、CA 95617 USA ietf@hardakers.net "
DESCRIPTION " The TLS Transport Model MIB
説明 "TLS輸送モデルMIB
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)."
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている簡略化されたBSDライセンスに基づいて許可されており、ライセンス条件に従うことが許可されています。http://trustee.ietf.org/license-info）。
REVISION "201005070000Z" DESCRIPTION "This version of this MIB module is part of RFC 5953; see the RFC itself for full legal notices."
リビジョン「201005070000Z」説明「このMIBモジュールのこのバージョンは、RFC 5953の一部です。完全な法的通知についてはRFC自体を参照してください。」
::= { mib-2 198 }
-- ************************************************
-- subtrees of the SNMP-TLS-TM-MIB
-- ************************************************
snmpTlstmNotifications OBJECT IDENTIFIER ::= { snmpTlstmMIB 0 }
snmpTlstmIdentities OBJECT IDENTIFIER ::= { snmpTlstmMIB 1 }
snmpTlstmObjects OBJECT IDENTIFIER ::= { snmpTlstmMIB 2 }
snmpTlstmConformance OBJECT IDENTIFIER ::= { snmpTlstmMIB 3 }
-- ************************************************
-- snmpTlstmObjects - Objects
-- ************************************************
snmpTLSTCPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over TLS via TCP transport domain. The corresponding transport address is of type SnmpTLSAddress.
snmptlstcpdomainオブジェクトアイデンティティステータス現在の説明 "TCPトランスポートドメインを介したTLS上のSNMP。対応する輸送アドレスは、SNMPTLSADDRESSのタイプです。
The securityName prefix to be associated with the snmpTLSTCPDomain is 'tls'. This prefix may be used by security models or other components to identify which secure transport infrastructure authenticated a securityName." REFERENCE "RFC 2579: Textual Conventions for SMIv2"
snmptlstcpdomainに関連付けられるセキュリティ名のプレフィックスは「TLS」です。このプレフィックスは、セキュリティモデルまたは他のコンポーネントで使用され、セキュリティインフラストラクチャがセキュリティ名を認証した安全なトランスポートインフラストラクチャを特定できます。
::= { snmpDomains 8 }
snmpDTLSUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over DTLS via UDP transport domain. The corresponding transport address is of type SnmpTLSAddress.
snmpdtlsudpdomainオブジェクトアイデンティティステータス現在の説明 "UDPトランスポートドメインを介したDTLのSNMP。対応するトランスポートアドレスは、SNMPTLSADDRESSのタイプです。
The securityName prefix to be associated with the snmpDTLSUDPDomain is 'dtls'. This prefix may be used by security models or other components to identify which secure transport infrastructure authenticated a securityName." REFERENCE "RFC 2579: Textual Conventions for SMIv2"
snmpdtlsudpdomainに関連付けられるセキュリティ名のプレフィックスは「dtls」です。このプレフィックスは、セキュリティモデルまたは他のコンポーネントで使用され、セキュリティインフラストラクチャがセキュリティ名を認証した安全なトランスポートインフラストラクチャを特定できます。
::= { snmpDomains 9 }
SnmpTLSAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents an IPv4 address, an IPv6 address, or a
US-ASCII-encoded hostname and port number.
An IPv4 address must be in dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII.
IPv4アドレスは、コロン '（us-ascii文字0x3a）とus-asciiの小数ポート番号が続く点線の小数形式である必要があります。
An IPv6 address must be a colon-separated format (as described in RFC 5952), surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII.
IPv6アドレスは、四角い括弧（ '['、us-ascii文字0x5b、 ''、us-ascii文字0x5d）に囲まれたコロン分離形式（RFC 5952で説明）でなければなりません。： '（us-ascii文字0x3a）およびus-asciiの小数ポート番号。
A hostname is always in US-ASCII (as per [RFC1033]); internationalized hostnames are encoded in US-ASCII as domain names after transformation via the ToASCII operation specified in [RFC3490]. The ToASCII operation MUST be performed with the UseSTD3ASCIIRules flag set. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible.
ホスト名は常にus-asciiにあります（[rfc1033]による）;国際化されたホスト名は、[RFC3490]で指定されたToascii操作を介した変換後のドメイン名としてUS-ASCIIでエンコードされます。Toascii操作は、UseStD3asciirulesフラグセットを使用して実行する必要があります。ホスト名の後には、コロン '：'（us-ascii文字0x3a）とus-asciiの小数ポート番号が続きます。名前は、可能な限り完全に資格を付ける必要があります。
Values of this textual convention may not be directly usable as transport-layer addressing information, and may require run-time resolution. As such, applications that write them must be prepared for handling errors if such values are not supported, or cannot be resolved (if resolution occurs at the time of the management operation).
このテキスト条約の値は、輸送層にアドレス指定された情報として直接使用できない場合があり、実行時間解決が必要になる場合があります。そのため、それらを記述するアプリケーションは、そのような値がサポートされていない場合、または解決できない場合（管理操作の時点で解決が発生した場合）、エラーを処理するために準備する必要があります。
The DESCRIPTION clause of TransportAddress objects that may have SnmpTLSAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa.
SNMPTLSADDRESS値を持つ可能性のあるTransportAddressオブジェクトの説明条項は、そのような名前をIPアドレスに解決する方法（およびいつ）を完全に説明する必要があります。
This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair.
このテキスト条約は、アドレスを特定の形式に制限するため、オブジェクト定義で直接使用すべきではありません。ただし、使用する場合は、単独で、またはTransportAddressTypeまたはTransportDomainと組み合わせて使用する場合があります。
When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED that all MIB documents using this textual convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation."
このテキスト規則がインデックスオブジェクトの構文として使用される場合、SMIV2（STD 58）で指定された128のサブ識別子の制限に関する問題がある場合があります。このテキスト条約を使用するすべてのMIBドキュメントは、管理ソフトウェアが観察しなければならないインデックスコンポーネントの長さの制限を明示的にすることをお勧めします。これは、インデックスコンポーネントにサイズの制約を含めるか、概念的行の説明節または周囲のドキュメントに該当する制約を指定することによって行われます。」
REFERENCE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE RFC 3490: Internationalizing Domain Names in Applications RFC 5952: A Recommendation for IPv6 Address Text Representation " SYNTAX OCTET STRING (SIZE (1..255))
リファレンス "RFC 1033：ドメイン管理者操作ガイドRFC 3490：アプリケーションの国際化ドメイン名RFC 5952：IPv6アドレステキスト表現の推奨"構文Octet String（Size（1..255）））
SnmpTLSFingerprint ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:1x"
STATUS current
DESCRIPTION
"A fingerprint value that can be used to uniquely reference
other data of potentially arbitrary length.
An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm identifier followed by the fingerprint value. The octet value encoded is taken from the IANA TLS HashAlgorithm Registry (RFC 5246). The remaining octets are filled using the results of the hashing algorithm.
SNMPTLSFINGERPRINT値は、1-OCTETハッシュアルゴリズム識別子で構成され、その後指紋値が続きます。エンコードされたオクテット値は、IANA TLSハスハルゴリズムレジストリ（RFC 5246）から取得されます。残りのオクテットは、ハッシュアルゴリズムの結果を使用して埋められます。
This TEXTUAL-CONVENTION allows for a zero-length (blank) SnmpTLSFingerprint value for use in tables where the fingerprint value may be optional. MIB definitions or implementations may refuse to accept a zero-length value as appropriate." REFERENCE "RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 http://www.iana.org/assignments/tls-parameters/ " SYNTAX OCTET STRING (SIZE (0..255))
このテキストコンベンションにより、指紋値がオプションになる可能性のあるテーブルで使用するためのゼロ長（空白）SNMPTLSFINGERPRINT値が可能になります。MIBの定義または実装は、必要に応じてゼロレングスの値を受け入れることを拒否する場合があります。 "Reference" RFC 5246：Transport Layer Security（TLS）Protocolバージョン1.2 http://www.iana.org/assignments/tls-parameters/ "syntaxオクテット文字列（サイズ（0..255））
-- Identities for use in the snmpTlstmCertToTSNTable
-SNMPTLSTMCERTTOTSNTABLEで使用するアイデンティティ
snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER
::= { snmpTlstmIdentities 1 }
snmpTlstmCertSpecified OBJECT-IDENTITY
STATUS current
DESCRIPTION "Directly specifies the tmSecurityName to be used for
this certificate. The value of the tmSecurityName
to use is specified in the snmpTlstmCertToTSNData
column. The snmpTlstmCertToTSNData column must
contain a non-zero length SnmpAdminString compliant
value or the mapping described in this row must be
considered a failure."
::= { snmpTlstmCertToTSNMIdentities 1 }
snmpTlstmCertSANRFC822Name OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a subjectAltName's rfc822Name to a tmSecurityName. The local part of the rfc822Name is passed unaltered but the host-part of the name must be passed in lowercase. This mapping results in a 1:1 correspondence between equivalent subjectAltName rfc822Name values and tmSecurityName values except that the host-part of the name MUST be passed in lowercase.
snmptlstmcertsanrfc822nameオブジェクトアイデンティティステータス現在の説明 "subjectaltnameのrfc822nameをtmsecurityNameにマップします。RFC822Nameのローカル部分は変更されていませんが、名前のホストパートは下位ケースで渡されなければなりません。subjectaltname rfc822name値とtmsecurityName値は、名前のホストパートを小文字で渡す必要があることを除きます。
Example rfc822Name Field: FooBar@Example.COM
is mapped to tmSecurityName: FooBar@example.com."
::= { snmpTlstmCertToTSNMIdentities 2 }
snmpTlstmCertSANDNSName OBJECT-IDENTITY
STATUS current
DESCRIPTION "Maps a subjectAltName's dNSName to a
tmSecurityName after first converting it to all
lowercase (RFC 5280 does not specify converting to
lowercase so this involves an extra step). This
mapping results in a 1:1 correspondence between
subjectAltName dNSName values and the tmSecurityName
values."
REFERENCE "RFC 5280 - Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile."
::= { snmpTlstmCertToTSNMIdentities 3 }
snmpTlstmCertSANIpAddress OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a subjectAltName's iPAddress to a tmSecurityName by transforming the binary encoded address as follows:
snmptlstmcertsanipaddressオブジェクトアイデンティティステータス現在の説明 "次のようにバイナリエンコードアドレスを変換することにより、subjectaltnameのIPアドレスをtmsecurityNameにマップします。
1) for IPv4, the value is converted into a decimal-dotted quad address (e.g., '192.0.2.1').
1) IPv4の場合、値は小数ドットのクアッドアドレス（例： '192.0.2.1'）に変換されます。
2) for IPv6 addresses, the value is converted into a 32-character all lowercase hexadecimal string without any colon separators.
2) IPv6アドレスの場合、値は、コロンセパレーターなしで32文字のすべての小文字の16進数に変換されます。
This mapping results in a 1:1 correspondence between subjectAltName iPAddress values and the tmSecurityName values.
このマッピングにより、subjectaltname iPaddress値とtmsecurityName値の間に1：1の対応が得られます。
The resulting length of an encoded IPv6 address is
the maximum length supported by the View-Based
Access Control Model (VACM). Using both the
Transport Security Model's support for transport
prefixes (see the SNMP-TSM-MIB's
snmpTsmConfigurationUsePrefix object for details)
will result in securityName lengths that exceed what
VACM can handle."
::= { snmpTlstmCertToTSNMIdentities 4 }
snmpTlstmCertSANAny OBJECT-IDENTITY STATUS current DESCRIPTION "Maps any of the following fields using the corresponding mapping algorithms:
snmptlstmcertsananyオブジェクトアイデンティティステータス現在の説明 "対応するマッピングアルゴリズムを使用して、次のフィールドのいずれかをマップします。
|------------+----------------------------|
| Type | Algorithm |
|------------+----------------------------|
| rfc822Name | snmpTlstmCertSANRFC822Name |
| dNSName | snmpTlstmCertSANDNSName |
| iPAddress | snmpTlstmCertSANIpAddress |
|------------+----------------------------|
The first matching subjectAltName value found in the certificate of the above types MUST be used when deriving the tmSecurityName. The mapping algorithm specified in the 'Algorithm' column MUST be used to derive the tmSecurityName.
上記のタイプの証明書にある最初の一致するsubjectaltname値は、tmsecurityNameを導出するときに使用する必要があります。「アルゴリズム」列で指定されているマッピングアルゴリズムを使用して、TMSECurityNameを導出する必要があります。
This mapping results in a 1:1 correspondence between
subjectAltName values and tmSecurityName values. The
three sub-mapping algorithms produced by this
combined algorithm cannot produce conflicting
results between themselves."
::= { snmpTlstmCertToTSNMIdentities 5 }
snmpTlstmCertCommonName OBJECT-IDENTITY STATUS current
snmptlstmcertcommonnameオブジェクトアイデンティティステータス電流
DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName
after converting it to a UTF-8 encoding. The usage
of CommonNames is deprecated and users are
encouraged to use subjectAltName mapping methods
instead. This mapping results in a 1:1
correspondence between certificate CommonName values
and tmSecurityName values."
::= { snmpTlstmCertToTSNMIdentities 6 }
-- The snmpTlstmSession Group
-Snmptlstmsessionグループ
snmpTlstmSession OBJECT IDENTIFIER ::= { snmpTlstmObjects 1 }
snmpTlstmSessionOpens OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an openSession() request has been executed
as a (D)TLS client, regardless of whether it succeeded or
failed."
::= { snmpTlstmSession 1 }
snmpTlstmSessionClientCloses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times a closeSession() request has been
executed as an (D)TLS client, regardless of whether it
succeeded or failed."
::= { snmpTlstmSession 2 }
snmpTlstmSessionOpenErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an openSession() request failed to open a
session as a (D)TLS client, for any reason."
::= { snmpTlstmSession 3 }
snmpTlstmSessionAccepts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times a (D)TLS server has accepted a new
connection from a client and has received at least one SNMP
message through it."
::= { snmpTlstmSession 4 }
snmpTlstmSessionServerCloses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times a closeSession() request has been
executed as an (D)TLS server, regardless of whether it
succeeded or failed."
::= { snmpTlstmSession 5 }
snmpTlstmSessionNoSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an outgoing message was dropped because
the session associated with the passed tmStateReference was no
longer (or was never) available."
::= { snmpTlstmSession 6 }
snmpTlstmSessionInvalidClientCertificates OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an incoming session was not established
on an (D)TLS server because the presented client certificate
was invalid. Reasons for invalidation include, but are not
limited to, cryptographic validation failures or lack of a
suitable mapping row in the snmpTlstmCertToTSNTable."
::= { snmpTlstmSession 7 }
snmpTlstmSessionUnknownServerCertificate OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an outgoing session was not established
on an (D)TLS client because the server certificate presented
by an SNMP over (D)TLS server was invalid because no
configured fingerprint or Certification Authority (CA) was
acceptable to validate it.
This may result because there was no entry in the
snmpTlstmAddrTable or because no path could be found to a
known CA."
::= { snmpTlstmSession 8 }
snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an outgoing session was not established on an (D)TLS client because the server certificate presented by an SNMP over (D)TLS server could not be validated even if the fingerprint or expected validation path was known. That is, a cryptographic validation error occurred during certificate validation processing.
snmptlstmsessioninvalidservercertificates object-type syntax counter32 max-access read-access read-ccess read-ccess only status current current "発信セッションの回数（d）TLSクライアントには確立されなかったため、（d）TLSサーバーはフィンガープリントまたは予想される検証パスがわかっていても検証されています。つまり、証明書の検証処理中に暗号化検証エラーが発生しました。
Reasons for invalidation include, but are not
limited to, cryptographic validation failures."
::= { snmpTlstmSession 9 }
snmpTlstmSessionInvalidCaches OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of outgoing messages dropped because the
tmStateReference referred to an invalid cache."
::= { snmpTlstmSession 10 }
-- Configuration Objects
- 構成オブジェクト
snmpTlstmConfig OBJECT IDENTIFIER ::= { snmpTlstmObjects 2 }
-- Certificate mapping
- 証明書マッピング
snmpTlstmCertificateMapping OBJECT IDENTIFIER ::= { snmpTlstmConfig 1 }
snmpTlstmCertToTSNCount OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of entries in the
snmpTlstmCertToTSNTable."
::= { snmpTlstmCertificateMapping 1 }
snmpTlstmCertToTSNTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime.0 when the snmpTlstmCertToTSNTable was
last modified through any means, or 0 if it has not been
modified since the command responder was started."
::= { snmpTlstmCertificateMapping 2 }
snmpTlstmCertToTSNTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTlstmCertToTSNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used by a (D)TLS server to map the (D)TLS client's presented X.509 certificate to a tmSecurityName.
snmptlstmcerttotsntableオブジェクトタイプの構文シーケンスSnmptlstmcerttttotsnentry max-access not-accessable current current current current current "
On an incoming (D)TLS/SNMP connection, the client's presented certificate must either be validated based on an established trust anchor, or it must directly match a fingerprint in this table. This table does not provide any mechanisms for configuring the trust anchors; the transfer of any needed trusted certificates for path validation is expected to occur through an out-of-band transfer.
着信（d）TLS/SNMP接続では、クライアントの提示された証明書は、確立された信頼アンカーに基づいて検証するか、この表の指紋を直接一致させる必要があります。このテーブルは、信頼のアンカーを構成するためのメカニズムを提供しません。パス検証に必要な信頼できる証明書の転送は、帯域外の転送を通じて発生すると予想されます。
Once the certificate has been found acceptable (either by path validation or directly matching a fingerprint in this table), this table is consulted to determine the appropriate tmSecurityName to identify with the remote connection. This is done by considering each active row from this table in prioritized order according to its snmpTlstmCertToTSNID value. Each row's snmpTlstmCertToTSNFingerprint value determines whether the row is a match for the incoming connection:
証明書が許容可能であることが判明したら（PATH検証またはこの表の指紋を直接一致させることにより）、このテーブルを参照して、リモート接続と識別するための適切なTMSECURTYNAMEを決定します。これは、SNMPTLSTMCERTTOTSNID値に従って、このテーブルから各アクティブな行を優先順位で検討することによって行われます。各行のSNMPTLSTMCERTTOTSNFINGERPRINT値は、行が着信接続と一致するかどうかを決定します。
1) If the row's snmpTlstmCertToTSNFingerprint value identifies the presented certificate, then consider the row as a successful match.
1) 行のsnmptlstmcertttotsnfingerprint値が提示された証明書を識別した場合、行を成功した一致と見なします。
2) If the row's snmpTlstmCertToTSNFingerprint value identifies a locally held copy of a trusted CA certificate and that CA certificate was used to validate the path to the presented certificate, then consider the row as a successful match.
2) Rowのsnmptlstmcertttotsnfingerprint値が、信頼できるCA証明書のローカルに保持されているコピーを識別し、そのCA証明書を使用して提示された証明書へのパスを検証する場合、行を一致したことを検討します。
Once a matching row has been found, the snmpTlstmCertToTSNMapType value can be used to determine how the tmSecurityName to associate with the session should be determined. See the snmpTlstmCertToTSNMapType column's DESCRIPTION for details on determining the tmSecurityName value. If it is impossible to determine a tmSecurityName from the row's data combined with the data presented in the certificate, then additional rows MUST be searched looking for another potential match. If a resulting tmSecurityName mapped from a given row is not compatible with the needed requirements of a tmSecurityName (e.g., VACM imposes a 32-octet-maximum length and the certificate derived securityName could be longer), then it must be considered an invalid match and additional rows MUST be searched looking for another potential match.
一致する行が見つかったら、SNMPTLSTMCERTTOTSNMAPTYPE値を使用して、セッションに関連するTMSECurityNameを決定する方法を決定できます。tmsecurityName値の決定に関する詳細については、SNMPTLSTMCERTTOTSNMAPTYPE列の説明を参照してください。証明書に提示されたデータと組み合わせた行のデータからTMSECURTYNAMEを決定することが不可能な場合は、別の潜在的な一致を探して追加の行を検索する必要があります。特定の行からマッピングされた結果のTMESECURITYNAMEがTMSECurityNameの必要な要件と互換性がない場合（たとえば、Vacmは32-OCTET-MAXIMUMの長さを課し、証明書由来のセキュリティ名が長くなる可能性があります）。別の潜在的な一致を探して、追加の行を検索する必要があります。
If no matching and valid row can be found, the connection MUST be closed and SNMP messages MUST NOT be accepted over it.
一致した行と有効な行を見つけられない場合、接続を閉じて、SNMPメッセージを受け入れてはならないでください。
Missing values of snmpTlstmCertToTSNID are acceptable and implementations should continue to the next highest numbered row. It is recommended that administrators skip index values to leave room for the insertion of future rows (for example, use values of 10 and 20 when creating initial rows).
snmptlstmcerttotsnidの欠損値は許容可能であり、実装は次の最高の数の行まで続く必要があります。管理者はインデックス値をスキップして、将来の行を挿入するためのスペースを残すことをお勧めします（たとえば、初期行を作成するときは10と20の値を使用します）。
Users are encouraged to make use of certificates with
subjectAltName fields that can be used as tmSecurityNames so
that a single root CA certificate can allow all child
certificate's subjectAltName to map directly to a
tmSecurityName via a 1:1 transformation. However, this table
is flexible to allow for situations where existing deployed
certificate infrastructures do not provide adequate
subjectAltName values for use as tmSecurityNames.
Certificates may also be mapped to tmSecurityNames using the
CommonName portion of the Subject field. However, the usage
of the CommonName field is deprecated and thus this usage is
NOT RECOMMENDED. Direct mapping from each individual
certificate fingerprint to a tmSecurityName is also possible
but requires one entry in the table per tmSecurityName and
requires more management operations to completely configure a
device."
::= { snmpTlstmCertificateMapping 3 }
snmpTlstmCertToTSNEntry OBJECT-TYPE SYNTAX SnmpTlstmCertToTSNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row in the snmpTlstmCertToTSNTable that specifies a mapping for an incoming (D)TLS certificate to a tmSecurityName to use for a connection."
snmptlstmcerttotsnentry object-type sntax snmptlstmcerttttotsnentry accessable accessable current current current current "snmptlstmcerttotstable" snmptlstmcerttotstable in snmptlstmcerttotsは、接続のためのTMSECURITYNAME（D）TLS証明書のマッピングを指定します。
INDEX { snmpTlstmCertToTSNID }
::= { snmpTlstmCertToTSNTable 1 }
SnmpTlstmCertToTSNEntry ::= SEQUENCE {
snmpTlstmCertToTSNID Unsigned32,
snmpTlstmCertToTSNFingerprint SnmpTLSFingerprint,
snmpTlstmCertToTSNMapType AutonomousType,
snmpTlstmCertToTSNData OCTET STRING,
snmpTlstmCertToTSNStorageType StorageType,
snmpTlstmCertToTSNRowStatus RowStatus
}
snmpTlstmCertToTSNID OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique, prioritized index for the given entry. Lower
numbers indicate a higher priority."
::= { snmpTlstmCertToTSNEntry 1 }
snmpTlstmCertToTSNFingerprint OBJECT-TYPE
SYNTAX SnmpTLSFingerprint (SIZE(1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A cryptographic hash of a X.509 certificate. The results of
a successful matching fingerprint to either the trusted CA in
the certificate validation path or to the certificate itself
is dictated by the snmpTlstmCertToTSNMapType column."
::= { snmpTlstmCertToTSNEntry 2 }
snmpTlstmCertToTSNMapType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the mapping type for deriving a tmSecurityName from a certificate. Details for mapping of a particular type SHALL be specified in the DESCRIPTION clause of the OBJECT-IDENTITY that describes the mapping. If a mapping succeeds it will return a tmSecurityName for use by the TLSTM model and processing stops.
snmptlstmcerttotsnmaptype object-type syntax autonomoustype max-access read-createステータス現在の説明 "証明書からtmsecurity名を導出するためのマッピングタイプを指定します。マッピング。マッピングが成功した場合、TLSTMモデルと処理停止で使用するためにTMSECurityNameを返します。
If the resulting mapped value is not compatible with the needed requirements of a tmSecurityName (e.g., VACM imposes a 32-octet-maximum length and the certificate derived securityName could be longer), then future rows MUST be searched for additional snmpTlstmCertToTSNFingerprint matches to look for a mapping that succeeds.
結果のマップされた値がTMSECurityNameの必要な要件と互換性がない場合（たとえば、Vacmが32-OCTET-MAXIMUMの長さを課し、証明書派生セキュリティ名が長くなる可能性があります）、将来の行を検索する必要があります。成功するマッピング。
Suitable values for assigning to this object that are defined
within the SNMP-TLS-TM-MIB can be found in the
snmpTlstmCertToTSNMIdentities portion of the MIB tree."
DEFVAL { snmpTlstmCertSpecified }
::= { snmpTlstmCertToTSNEntry 3 }
snmpTlstmCertToTSNData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Auxiliary data used as optional configuration information for
a given mapping specified by the snmpTlstmCertToTSNMapType
column. Only some mapping systems will make use of this
column. The value in this column MUST be ignored for any
mapping type that does not require data present in this
column."
DEFVAL { "" }
::= { snmpTlstmCertToTSNEntry 4 }
snmpTlstmCertToTSNStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row. Conceptual rows
having the value 'permanent' need not allow write-access to
any columnar objects in the row."
DEFVAL { nonVolatile }
::= { snmpTlstmCertToTSNEntry 5 }
snmpTlstmCertToTSNRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table.
snmptlstmcerttotsnrowstatus object-type syntax rowstatus max-access read-createステータス現在の説明 "この概念行のステータス。このオブジェクトは、このテーブルから行を作成または削除するために使用できます。
To create a row in this table, an administrator must set this object to either createAndGo(4) or createAndWait(5).
このテーブルに行を作成するには、管理者がこのオブジェクトをCreateandgo（4）またはCreateandWait（5）のいずれかに設定する必要があります。
Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the snmpTlstmParamsRowStatus column is notReady(3).
対応するすべての列のインスタンスが適切に構成されるまで、SNMPTLSTMPARAMSROWSTATUS列の対応するインスタンスの値は修正されていません（3）。
In particular, a newly created row cannot be made active until the corresponding snmpTlstmCertToTSNFingerprint, snmpTlstmCertToTSNMapType, and snmpTlstmCertToTSNData columns have been set.
特に、対応するsnmptlstmcertTotsnfingerprint、snmptlstmcertttotsnmaptype、およびsnmptlstmcertttotsndata列が設定されるまで、新しく作成された行をアクティブにすることはできません。
The following objects may not be modified while the
value of this object is active(1):
- snmpTlstmCertToTSNFingerprint
- snmpTlstmCertToTSNMapType
- snmpTlstmCertToTSNData
An attempt to set these objects while the value of
snmpTlstmParamsRowStatus is active(1) will result in
an inconsistentValue error."
::= { snmpTlstmCertToTSNEntry 6 }
-- Maps tmSecurityNames to certificates for use by the SNMP-TARGET-MIB
-SNMP-Target-Mibが使用するための証明書にtmsecurityNamesをマップ
snmpTlstmParamsCount OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of entries in the snmpTlstmParamsTable."
::= { snmpTlstmCertificateMapping 4 }
snmpTlstmParamsTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime.0 when the snmpTlstmParamsTable
was last modified through any means, or 0 if it has not been
modified since the command responder was started."
::= { snmpTlstmCertificateMapping 5 }
snmpTlstmParamsTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTlstmParamsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is used by a (D)TLS client when a (D)TLS
connection is being set up using an entry in the
SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's
snmpTargetParamsTable with a fingerprint of a certificate to
use when establishing such a (D)TLS connection."
::= { snmpTlstmCertificateMapping 6 }
snmpTlstmParamsEntry OBJECT-TYPE
SYNTAX SnmpTlstmParamsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row containing a fingerprint hash of a locally
held certificate for a given snmpTargetParamsEntry. The
values in this row should be ignored if the connection that
needs to be established, as indicated by the SNMP-TARGET-MIB
infrastructure, is not a certificate and (D)TLS based
connection. The connection SHOULD NOT be established if the
certificate fingerprint stored in this entry does not point to
a valid locally held certificate or if it points to an
unusable certificate (such as might happen when the
certificate's expiration date has been reached)."
INDEX { IMPLIED snmpTargetParamsName }
::= { snmpTlstmParamsTable 1 }
SnmpTlstmParamsEntry ::= SEQUENCE {
snmpTlstmParamsClientFingerprint SnmpTLSFingerprint,
snmpTlstmParamsStorageType StorageType,
snmpTlstmParamsRowStatus RowStatus
}
snmpTlstmParamsClientFingerprint OBJECT-TYPE
SYNTAX SnmpTLSFingerprint
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object stores the hash of the public portion of a
locally held X.509 certificate. The X.509 certificate, its
public key, and the corresponding private key will be used
when initiating a (D)TLS connection as a (D)TLS client."
::= { snmpTlstmParamsEntry 1 }
snmpTlstmParamsStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row. Conceptual rows
having the value 'permanent' need not allow write-access to
any columnar objects in the row."
DEFVAL { nonVolatile }
::= { snmpTlstmParamsEntry 2 }
snmpTlstmParamsRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table.
snmptlstmparamsrowstatus object-type syntax rowstatus max-access read-createステータス現在の説明 "この概念行のステータス。このオブジェクトは、このテーブルから行を作成または削除するために使用できます。
To create a row in this table, an administrator must set this object to either createAndGo(4) or createAndWait(5).
このテーブルに行を作成するには、管理者がこのオブジェクトをCreateandgo（4）またはCreateandWait（5）のいずれかに設定する必要があります。
Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the snmpTlstmParamsRowStatus column is notReady(3).
対応するすべての列のインスタンスが適切に構成されるまで、SNMPTLSTMPARAMSROWSTATUS列の対応するインスタンスの値は修正されていません（3）。
In particular, a newly created row cannot be made active until the corresponding snmpTlstmParamsClientFingerprint column has been set.
特に、対応するSNMPTLSTMPARAMSCLIENTFINGERPRINT列が設定されるまで、新しく作成された行をアクティブにすることはできません。
The snmpTlstmParamsClientFingerprint object may not be modified while the value of this object is active(1).
このオブジェクトの値がアクティブである間、SNMPTLSTMPARAMSCLIENTFINGERPRINTオブジェクトは変更されない場合があります（1）。
An attempt to set these objects while the value of
snmpTlstmParamsRowStatus is active(1) will result in
an inconsistentValue error."
::= { snmpTlstmParamsEntry 3 }
snmpTlstmAddrCount OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of entries in the snmpTlstmAddrTable."
::= { snmpTlstmCertificateMapping 7 }
snmpTlstmAddrTableLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime.0 when the snmpTlstmAddrTable
was last modified through any means, or 0 if it has not been
modified since the command responder was started."
::= { snmpTlstmCertificateMapping 8 }
snmpTlstmAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTlstmAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used by a (D)TLS client when a (D)TLS connection is being set up using an entry in the SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's snmpTargetAddrTable so that the client can verify that the correct server has been reached. This verification can use either a certificate fingerprint, or an identity authenticated via certification path validation.
snmptlstmaddrtableオブジェクトタイプの構文snmptlstmaddrentry max-access not-accessable current現在の説明 "このテーブルは、a（d）TLSクライアントによって使用されます。。SNMP-Target-Mibのsnmptargetaddrtableを拡張して、クライアントが正しいサーバーに到達したことを確認できるようにします。この検証は、証明書の指紋または認証パス検証を介して認証されたIDを使用できます。
If there is an active row in this table corresponding to the entry in the SNMP-TARGET-MIB that was used to establish the connection, and the row's snmpTlstmAddrServerFingerprint column has non-empty value, then the server's presented certificate is compared with the snmpTlstmAddrServerFingerprint value (and the snmpTlstmAddrServerIdentity column is ignored). If the fingerprint matches, the verification has succeeded. If the fingerprint does not match, then the connection MUST be closed.
このテーブルに、接続の確立に使用されたSNMPターゲット-MIBのエントリに対応するアクティブな行があり、行のSNMPTLSTMADDRSERVERFINGERPRINT列の値がない場合、サーバーの提示証明書はSNMPTLSTMADDRSERVERFINGERPRINT値と比較されます。（そして、snmptlstmaddrserveridentity列は無視されます）。指紋が一致する場合、検証は成功しました。指紋が一致しない場合、接続を閉じる必要があります。
If the server's presented certificate has passed certification path validation [RFC5280] to a configured trust anchor, and an active row exists with a zero-length snmpTlstmAddrServerFingerprint value, then the snmpTlstmAddrServerIdentity column contains the expected host name. This expected host name is then compared against the server's certificate as follows:
サーバーの提示された証明書が認定パス検証[RFC5280]を構成されたトラストアンカーに合格し、ゼロの長さのSNMPTLSTMADDRSERVERFINGERPRINT値を備えたアクティブな行が存在する場合、SNMPTLSTMADDRSERVERVERIDETY列には予想されるホスト名が含まれています。この予想ホスト名は、次のようにサーバーの証明書に対して比較されます。
- Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and MAY support checking the name against the CommonName portion of the subject distinguished name.
- 実装は、件名の拡張機能フィールドのDNSNameとの予想ホスト名の一致をサポートする必要があり、サブジェクトの著名な名前の共通名部分に対して名前をチェックすることをサポートする場合があります。
- The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them.
- '*'（ascii 0x2a）ワイルドカードの文字は、subjectaltname拡張機能のdnsnameで許可されています（およびホスト名を保存するために使用される場合は、一般名です）が、その値の左端（最も重要ではない）dnsラベルとしてのみです。このワイルドカードは、サーバー名の左端のDNSラベルと一致します。つまり、件名 *.example.comはサーバー名A.example.comおよびB.Example.comと一致しますが、example.comまたはA.B.example.comと一致しません。実装は、上記で指定されているように証明書のワイルドカードをサポートする必要がありますが、それらを無効にする構成オプションを提供する場合があります。
- If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [RFC5280].
- ローカルで構成された名前が国際化されたドメイン名である場合、適合実装は、[RFC5280]のセクション7で指定されているように、比較を実行するためにASCII互換エンコード（ACE）形式に変換する必要があります。
If the expected host name fails these conditions then the connection MUST be closed.
予想されるホスト名がこれらの条件に失敗した場合、接続を閉じる必要があります。
If there is no row in this table corresponding to the entry in the SNMP-TARGET-MIB and the server can be authorized by another, implementation-dependent means, then the connection MAY still proceed."
この表に、SNMPターゲット-MIBのエントリに対応する行がない場合、サーバーは実装依存の別の手段によって承認される可能性がある場合、接続は引き続き進行する場合があります。」
::= { snmpTlstmCertificateMapping 9 }
snmpTlstmAddrEntry OBJECT-TYPE
SYNTAX SnmpTlstmAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row containing a copy of a certificate's
fingerprint for a given snmpTargetAddrEntry. The values in
this row should be ignored if the connection that needs to be
established, as indicated by the SNMP-TARGET-MIB
infrastructure, is not a (D)TLS based connection. If an
snmpTlstmAddrEntry exists for a given snmpTargetAddrEntry, then
the presented server certificate MUST match or the connection
MUST NOT be established. If a row in this table does not
exist to match an snmpTargetAddrEntry row, then the connection
SHOULD still proceed if some other certificate validation path
algorithm (e.g., RFC 5280) can be used."
INDEX { IMPLIED snmpTargetAddrName }
::= { snmpTlstmAddrTable 1 }
SnmpTlstmAddrEntry ::= SEQUENCE {
snmpTlstmAddrServerFingerprint SnmpTLSFingerprint,
snmpTlstmAddrServerIdentity SnmpAdminString,
snmpTlstmAddrStorageType StorageType,
snmpTlstmAddrRowStatus RowStatus
}
snmpTlstmAddrServerFingerprint OBJECT-TYPE
SYNTAX SnmpTLSFingerprint
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A cryptographic hash of a public X.509 certificate. This
object should store the hash of the public X.509 certificate
that the remote server should present during the (D)TLS
connection setup. The fingerprint of the presented
certificate and this hash value MUST match exactly or the
connection MUST NOT be established."
DEFVAL { "" }
::= { snmpTlstmAddrEntry 1 }
snmpTlstmAddrServerIdentity OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The reference identity to check against the identity
presented by the remote system."
DEFVAL { "" }
::= { snmpTlstmAddrEntry 2 }
snmpTlstmAddrStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row. Conceptual rows
having the value 'permanent' need not allow write-access to
any columnar objects in the row."
DEFVAL { nonVolatile }
::= { snmpTlstmAddrEntry 3 }
snmpTlstmAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table.
snmptlstmaddrrowstatus object-type syntax rowstatus max-access read-createステータス現在の説明 "この概念行のステータス。このオブジェクトは、このテーブルから行を作成または削除するために使用できます。
To create a row in this table, an administrator must set this object to either createAndGo(4) or createAndWait(5).
このテーブルに行を作成するには、管理者がこのオブジェクトをCreateandgo（4）またはCreateandWait（5）のいずれかに設定する必要があります。
Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the snmpTlstmAddrRowStatus column is notReady(3).
対応するすべての列のインスタンスが適切に構成されるまで、SNMPTLSTMADDRROWSTATUS列の対応するインスタンスの値は修正されていません（3）。
In particular, a newly created row cannot be made active until the corresponding snmpTlstmAddrServerFingerprint column has been set.
特に、対応するSNMPTLSTMADDRSERVERFINGERPRINT列が設定されるまで、新しく作成された行をアクティブにすることはできません。
Rows MUST NOT be active if the snmpTlstmAddrServerFingerprint column is blank and the snmpTlstmAddrServerIdentity is set to '*' since this would insecurely accept any presented certificate.
snmptlstmaddrserverfingerprint列が空白であり、Snmptlstmaddrserveridentityは、提示された証明書を不安に受け入れるため、「*」に設定されている場合、行をアクティブにしないでください。
The snmpTlstmAddrServerFingerprint object may not be modified while the value of this object is active(1).
このオブジェクトの値がアクティブである間、SNMPTLSTMADDRSERVERFINGERPRINTオブジェクトは変更されない場合があります（1）。
An attempt to set these objects while the value of
snmpTlstmAddrRowStatus is active(1) will result in
an inconsistentValue error."
::= { snmpTlstmAddrEntry 4 }
-- ************************************************
-- snmpTlstmNotifications - Notifications Information
-- ************************************************
snmpTlstmServerCertificateUnknown NOTIFICATION-TYPE OBJECTS { snmpTlstmSessionUnknownServerCertificate } STATUS current DESCRIPTION "Notification that the server certificate presented by an SNMP over (D)TLS server was invalid because no configured fingerprint or CA was acceptable to validate it. This may be because there was no entry in the snmpTlstmAddrTable or because no path could be found to known Certification Authority.
snmptlstmservercertificateTificateunknown notification-type objects {snmptlstmssessionunknownServercertificate}ステータス現在の説明 "SNMPオーバー（D）TLSサーバーが提示したサーバー証明書が無効であるという通知snmptlstmaddrtableまたは既知の認証機関へのパスが見つからなかったためです。
To avoid notification loops, this notification MUST NOT be
sent to servers that themselves have triggered the
notification."
::= { snmpTlstmNotifications 1 }
snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE OBJECTS { snmpTlstmAddrServerFingerprint, snmpTlstmSessionInvalidServerCertificates} STATUS current DESCRIPTION "Notification that the server certificate presented by an SNMP over (D)TLS server could not be validated even if the fingerprint or expected validation path was known. That is, a cryptographic validation error occurred during certificate validation processing.
snmptlstmserverinvalidcertificate notification-type objects {snmptlstmaddrserverfingerprint、snmptlstlstlstmssessioninininingserververcertificates}ステータス現在の説明 "SNMPオーバー（D）TLSサーバーによって提示されたサーバー証明書が、羽毛の有効化または有効化されている場合でも有効化されていた場合でも有効化されていない場合でも検証されていない場合でも検証できなかった場合証明書の検証処理中にエラーが発生しました。
To avoid notification loops, this notification MUST NOT be
sent to servers that themselves have triggered the
notification."
::= { snmpTlstmNotifications 2 }
-- ************************************************
-- snmpTlstmCompliances - Conformance Information
-- ************************************************
snmpTlstmCompliances OBJECT IDENTIFIER ::= { snmpTlstmConformance 1 }
snmpTlstmGroups OBJECT IDENTIFIER ::= { snmpTlstmConformance 2 }
-- ************************************************
-- Compliance statements
-- ************************************************
snmpTlstmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines that support the
SNMP-TLS-TM-MIB"
MODULE
MANDATORY-GROUPS { snmpTlstmStatsGroup,
snmpTlstmIncomingGroup,
snmpTlstmOutgoingGroup,
snmpTlstmNotificationGroup }
::= { snmpTlstmCompliances 1 }
-- ************************************************
-- Units of conformance
-- ************************************************
snmpTlstmStatsGroup OBJECT-GROUP
OBJECTS {
snmpTlstmSessionOpens,
snmpTlstmSessionClientCloses,
snmpTlstmSessionOpenErrors,
snmpTlstmSessionAccepts,
snmpTlstmSessionServerCloses,
snmpTlstmSessionNoSessions,
snmpTlstmSessionInvalidClientCertificates,
snmpTlstmSessionUnknownServerCertificate,
snmpTlstmSessionInvalidServerCertificates,
snmpTlstmSessionInvalidCaches
}
STATUS current
DESCRIPTION
"A collection of objects for maintaining
statistical information of an SNMP engine that
implements the SNMP TLS Transport Model."
::= { snmpTlstmGroups 1 }
snmpTlstmIncomingGroup OBJECT-GROUP
OBJECTS {
snmpTlstmCertToTSNCount,
snmpTlstmCertToTSNTableLastChanged,
snmpTlstmCertToTSNFingerprint,
snmpTlstmCertToTSNMapType,
snmpTlstmCertToTSNData,
snmpTlstmCertToTSNStorageType,
snmpTlstmCertToTSNRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects for maintaining
incoming connection certificate mappings to
tmSecurityNames of an SNMP engine that implements the
SNMP TLS Transport Model."
::= { snmpTlstmGroups 2 }
snmpTlstmOutgoingGroup OBJECT-GROUP
OBJECTS {
snmpTlstmParamsCount,
snmpTlstmParamsTableLastChanged,
snmpTlstmParamsClientFingerprint,
snmpTlstmParamsStorageType,
snmpTlstmParamsRowStatus,
snmpTlstmAddrCount,
snmpTlstmAddrTableLastChanged,
snmpTlstmAddrServerFingerprint,
snmpTlstmAddrServerIdentity,
snmpTlstmAddrStorageType,
snmpTlstmAddrRowStatus
}
STATUS current
DESCRIPTION
"A collection of objects for maintaining
outgoing connection certificates to use when opening
connections as a result of SNMP-TARGET-MIB settings."
::= { snmpTlstmGroups 3 }
snmpTlstmNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
snmpTlstmServerCertificateUnknown,
snmpTlstmServerInvalidCertificate
}
STATUS current
DESCRIPTION
"Notifications"
::= { snmpTlstmGroups 4 }
END
終わり
This section discusses various operational aspects of deploying TLSTM.
このセクションでは、TLSTMの展開のさまざまな運用的側面について説明します。
A session is discussed throughout this document as meaning a security association between two TLSTM instances. State information for the sessions are maintained in each TLSTM implementation and this information is created and destroyed as sessions are opened and closed. A "broken" session (one side up and one side down) can result if one side of a session is brought down abruptly (i.e., reboot, power outage, etc.). Whenever possible, implementations SHOULD provide graceful session termination through the use of TLS disconnect messages. Implementations SHOULD also have a system in place for detecting "broken" sessions through the use of heartbeats [HEARTBEAT] or other detection mechanisms.
このドキュメント全体で、2つのTLSTMインスタンス間のセキュリティ関連を意味するものとしてセッションが議論されています。セッションの州情報は各TLSTM実装で維持され、この情報はセッションが開設され、閉鎖されると作成および破壊されます。セッションの片側が突然倒された場合（つまり、再起動、停電など）、「壊れた」セッション（片側が上にあり、片側）が生じる可能性があります。可能な限り、実装は、TLS切断メッセージを使用して優雅なセッション終了を提供する必要があります。また、実装には、ハートビート[ハートビート]またはその他の検出メカニズムを使用して「壊れた」セッションを検出するためのシステムが設置されている必要があります。
Implementations SHOULD limit the lifetime of established sessions depending on the algorithms used for generation of the master session secret, the privacy and integrity algorithms used to protect messages, the environment of the session, the amount of data transferred, and the sensitivity of the data.
実装は、マスターセッションの秘密の生成に使用されるアルゴリズム、メッセージを保護するために使用されるプライバシーと整合性アルゴリズム、セッションの環境、転送されるデータの量、およびデータの感度に応じて、確立されたセッションの寿命を制限する必要があります。
When an SNMP engine needs to establish an outgoing session for notifications, the snmpTargetParamsTable includes an entry for the snmpTargetParamsSecurityName of the target. Servers that wish to support multiple principals at a particular port SHOULD make use of the Server Name Indication extension defined in Section 3.1 of [RFC4366]. Without the Server Name Indication the receiving SNMP engine (server) will not know which (D)TLS certificate to offer to the client so that the tmSecurityName identity-authentication will be successful.
SNMPエンジンが通知のために発信セッションを確立する必要がある場合、SNMPTARGETPARAMSTABLEには、ターゲットのSNMPTARGETPARAMSSECURTYNAMEのエントリが含まれています。特定のポートで複数のプリンシパルをサポートしたいサーバーは、[RFC4366]のセクション3.1で定義されているサーバー名表示拡張機能を使用する必要があります。サーバー名の表示がないと、受信SNMPエンジン（サーバー）は、（d）TLS証明書をクライアントに提供する証明書を知りません。
Another solution is to maintain a one-to-one mapping between certificates and incoming ports for notification receivers. This can be handled at the notification originator by configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and snmpTargetAddrTAddress) and requiring the receiving SNMP engine to monitor multiple incoming static ports based on which principals are capable of receiving notifications.
別の解決策は、通知レシーバー用の証明書と着信ポート間の1対1のマッピングを維持することです。これは、SNMPTARGETADDRTABLE（SNMPTARGETADDRTDOMAINおよびSNMPTARGETADDRTADDRESS）を構成し、受信SNMPエンジンに複数の受信静的ポートを監視するように受信SNMPエンジンに、受信通知に基づいて複数の着信静的ポートを監視することを要求することにより、通知オリジネーターで処理できます。
Implementations MAY also choose to designate a single Notification Receiver Principal to receive all incoming notifications or select an implementation specific method of selecting a server certificate to present to clients.
実装は、すべての着信通知を受信するために単一の通知レシーバープリンシパルを指定するか、クライアントに提示するサーバー証明書を選択する実装固有の方法を選択することもできます。
SNMPv3 requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
SNMPV3では、リモートSNMPエンティティに維持されているオブジェクトを取得または操作するために、リモートSNMPプロトコルエンジンの識別子（SNMPENGINEID）をアプリケーションが把握する必要があります。
[RFC5343] introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. Implementations are RECOMMENDED to support and use the contextEngineID discovery mechanism defined in [RFC5343].
[RFC5343]は、リモートSNMPプロトコルエンジンのSNMPENGINEIDを学習するために使用できる有名なローカルエンジンと発見メカニズムを導入します。[RFC5343]で定義されているContextEngineID発見メカニズムをサポートおよび使用するには、実装が推奨されます。
This document defines how SNMP messages can be transmitted over the TLS- and DTLS-based protocols. Each of these protocols are additionally based on other transports (TCP and UDP). These two base protocols also have operational considerations that must be taken into consideration when selecting a (D)TLS-based protocol to use such as its performance in degraded or limited networks. It is beyond the scope of this document to summarize the characteristics of these transport mechanisms. Please refer to the base protocol documents for details on messaging considerations with respect to MTU size, fragmentation, performance in lossy networks, etc.
このドキュメントでは、TLSおよびDTLSベースのプロトコルを介してSNMPメッセージを送信する方法を定義しています。これらの各プロトコルは、他のトランスポート（TCPおよびUDP）にさらに基づいています。これらの2つのベースプロトコルには、（d）TLSベースのプロトコルを選択して、劣化したネットワークまたは限られたネットワークでのパフォーマンスなどを使用する際に考慮する必要がある運用上の考慮事項もあります。これらの輸送メカニズムの特性を要約することは、このドキュメントの範囲を超えています。MTUサイズ、断片化、損失ネットワークのパフォーマンスなどに関するメッセージングに関する考慮事項の詳細については、ベースプロトコルドキュメントを参照してください。
This document describes a transport model that permits SNMP to utilize (D)TLS security services. The security threats and how the (D)TLS transport model mitigates these threats are covered in detail throughout this document. Security considerations for DTLS are covered in [RFC4347] and security considerations for TLS are described in Section 11 and Appendices D, E, and F of TLS 1.2 [RFC5246]. When run over a connectionless transport such as UDP, DTLS is more vulnerable to denial-of-service attacks from spoofed IP addresses; see Section 4.2 for details how the cookie exchange is used to address this issue.
このドキュメントでは、SNMPが（d）TLSセキュリティサービスを利用できるようにするトランスポートモデルについて説明しています。セキュリティの脅威と（d）TLS輸送モデルがこれらの脅威を緩和する方法は、このドキュメント全体で詳細にカバーされています。DTLのセキュリティ上の考慮事項は[RFC4347]でカバーされており、TLSのセキュリティ上の考慮事項については、セクション11および付録D、E、およびTLS 1.2 [RFC5246]の付録に記載されています。UDPなどのコネクションレストランスポートを介して実行すると、DTLSはスプーフィングされたIPアドレスからのサービス拒否攻撃に対してより脆弱です。この問題に対処するためにCookie Exchangeを使用する方法については、セクション4.2を参照してください。
Implementations are responsible for providing a security certificate installation and configuration mechanism. Implementations SHOULD support certificate revocation lists.
実装は、セキュリティ証明書のインストールと構成メカニズムを提供する責任があります。実装は、証明書の取り消しリストをサポートする必要があります。
(D)TLS provides for authentication of the identity of both the (D)TLS server and the (D)TLS client. Access to MIB objects for the authenticated principal MUST be enforced by an access control subsystem (e.g., the VACM).
（d）TLSは、（d）TLSサーバーと（d）TLSクライアントの両方のIDの認証を提供します。認証されたプリンシパルのMIBオブジェクトへのアクセスは、アクセス制御サブシステム（例：VACM）によって実施する必要があります。
Authentication of the command generator principal's identity is important for use with the SNMP access control subsystem to ensure that only authorized principals have access to potentially sensitive data. The authenticated identity of the command generator principal's certificate is mapped to an SNMP model-independent securityName for use with SNMP access control.
コマンドジェネレータープリンシパルのアイデンティティの認証は、SNMPアクセス制御サブシステムで使用するために重要であり、承認されたプリンシパルのみが潜在的に機密データにアクセスできるようにします。コマンドジェネレータープリンシパルの証明書の認証されたIDは、SNMPアクセスコントロールで使用するためのSNMPモデルに依存しないセキュリティ名にマッピングされます。
The (D)TLS handshake only provides assurance that the certificate of the authenticated identity has been signed by a configured accepted Certification Authority. (D)TLS has no way to further authorize or reject access based on the authenticated identity. An Access Control Model (such as the VACM) provides access control and authorization of a command generator's requests to a command responder and a notification receiver's authorization to receive Notifications from a notification originator. However, to avoid man-in-the-middle attacks, both ends of the (D)TLS-based connection MUST check the certificate presented by the other side against what was expected. For example, command generators must check that the command responder presented and authenticated itself with a X.509 certificate that was expected. Not doing so would allow an impostor, at a minimum, to present false data, receive sensitive information and/or provide a false belief that configuration was actually received and acted upon. Authenticating and verifying the identity of the (D)TLS server and the (D)TLS client for all operations ensures the authenticity of the SNMP engine that provides MIB data.
（d）TLSハンドシェイクは、認証されたIDの証明書が設定された認定認定機関によって署名されたという保証のみを提供します。（d）TLSには、認証されたアイデンティティに基づいてアクセスをさらに承認または拒否する方法はありません。アクセス制御モデル（VACMなど）は、コマンドジェネレーターの要求のアクセス制御と承認をコマンドレスポンダーに提供し、通知オリジネーターから通知を受信する通知受信者の許可を提供します。ただし、中間の攻撃を避けるために、（d）TLSベースの接続の両端は、予想されるものに対して反対側が提示した証明書を確認する必要があります。たとえば、コマンドジェネレーターは、コマンドレスポンダーが提示され、予想されるX.509証明書で自らを認証したことを確認する必要があります。そうしないと、詐欺師が少なくとも誤ったデータを提示し、機密情報を受け取ること、および/または構成が実際に受信され、行動したという誤った信念を提供することができます。すべての操作の（d）TLSサーバーと（d）TLSクライアントのIDを認証および検証することにより、MIBデータを提供するSNMPエンジンの信頼性が保証されます。
The instructions found in the DESCRIPTION clause of the snmpTlstmCertToTSNTable object must be followed exactly. It is also important that the rows of the table be searched in prioritized order starting with the row containing the lowest numbered snmpTlstmCertToTSNID value.
SNMPTLSTMCERTTOTSNTABLEオブジェクトの説明条項にある命令に正確に従う必要があります。また、テーブルの行を、最低番号のSNMPTLSTMCERTTOTSNID値を含む行から始まる優先順位で検索することも重要です。
This section discusses security considerations specific to the usage of (D)TLS.
このセクションでは、（d）TLSの使用に固有のセキュリティ上の考慮事項について説明します。
Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details.
TLSの実装は通常、Transport Layer Security Protocolの複数のバージョンと古いSecure Socketsレイヤー（SSL）プロトコルをサポートします。既知のセキュリティの脆弱性のため、TLSTMクライアントとサーバーはSSL 2.0を要求、提供、または使用してはなりません。詳細については、[RFC5246]の付録E.2を参照してください。
The use of Perfect Forward Secrecy is RECOMMENDED and can be provided by (D)TLS with appropriately selected cipher_suites, as discussed in Appendix F of [RFC5246].
完全な前方秘密の使用が推奨され、[RFC5246]の付録Fで説明されているように、適切に選択されたCIPHER_SUITESを使用して（d）TLSによって提供できます。
The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP 74) always selects the SNMPv1 or SNMPv2c Security Models, respectively. Both of these and the User-based Security Model typically used with SNMPv3 derive the securityName and securityLevel from the SNMP message received, even when the message was received over a secure transport. Access control decisions are therefore made based on the contents of the SNMP message, rather than using the authenticated identity and securityLevel provided by the TLS Transport Model. It is RECOMMENDED that only SNMPv3 messages using the Transport Security Model (TSM) or another secure-transport aware security model be sent over the TLSTM transport.
[RFC3584]（BCP 74）で説明されているSNMPV1およびSNMPV2Cメッセージ処理は、常にSNMPV1またはSNMPV2Cセキュリティモデルをそれぞれ選択します。これらとユーザーベースのセキュリティモデルの両方が、通常、SNMPV3で使用されているセキュリティモデルは、受信したSNMPメッセージからSecurityNameとSecurityLevelを導き出します。したがって、アクセス制御の決定は、TLSトランスポートモデルによって提供される認証されたIDとセキュリティレベルを使用するのではなく、SNMPメッセージの内容に基づいて行われます。TLSTMトランスポートを介して送信されるTransport Security Model（TSM）または別のSecure-Transport Awareセキュリティモデルを使用したSNMPV3メッセージのみを使用することをお勧めします。
Using a non-transport-aware Security Model with a secure Transport Model is NOT RECOMMENDED. See [RFC5590] Section 7.1 for additional details on the coexistence of security-aware transports and non-transport-aware security models.
安全な輸送モデルを使用して、輸送以外の認識セキュリティモデルを使用することは推奨されません。[RFC5590]セクション7.1を参照してください。セキュリティ認識輸送と非輸送対象セキュリティモデルの共存の詳細については。
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:
このMIBモジュールには、読み取りワイトおよび/またはread-Createの最大アクセス句を持つ多くの管理オブジェクトが定義されています。このようなオブジェクトは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしの非セクター環境でのセット操作のサポートは、ネットワーク操作に悪影響を与える可能性があります。これらはテーブルとオブジェクトであり、その感度/脆弱性です。
o The snmpTlstmParamsTable can be used to change the outgoing X.509 certificate used to establish a (D)TLS connection. Modification to objects in this table need to be adequately authenticated since modification to values in this table will have profound impacts to the security of outbound connections from the device. Since knowledge of authorization rules and certificate usage mechanisms may be considered sensitive, protection from disclosure of the SNMP traffic via encryption is also highly recommended.
o SNMPTLSTMPARAMSTABLEを使用して、（d）TLS接続を確立するために使用される発信X.509証明書を変更できます。このテーブルのオブジェクトの変更は、このテーブルの値の変更がデバイスからのアウトバウンド接続のセキュリティに大きな影響を与えるため、適切に認証される必要があります。許可ルールと証明書の使用メカニズムに関する知識は敏感であると見なされる可能性があるため、暗号化によるSNMPトラフィックの開示からの保護も強くお勧めします。
o The snmpTlstmAddrTable can be used to change the expectations of the certificates presented by a remote (D)TLS server. Modification to objects in this table need to be adequately authenticated since modification to values in this table will have profound impacts to the security of outbound connections from the device. Since knowledge of authorization rules and certificate usage mechanisms may be considered sensitive, protection from disclosure of the SNMP traffic via encryption is also highly recommended.
o SNMPTLSTMADDRTABLEを使用して、リモート（D）TLSサーバーによって提示された証明書の期待を変更できます。このテーブルのオブジェクトの変更は、このテーブルの値の変更がデバイスからのアウトバウンド接続のセキュリティに大きな影響を与えるため、適切に認証される必要があります。許可ルールと証明書の使用メカニズムに関する知識は敏感であると見なされる可能性があるため、暗号化によるSNMPトラフィックの開示からの保護も強くお勧めします。
o The snmpTlstmCertToTSNTable is used to specify the mapping of incoming X.509 certificates to tmSecurityNames, which eventually get mapped to a SNMPv3 securityName. Modification to objects in this table need to be adequately authenticated since modification to values in this table will have profound impacts to the security of incoming connections to the device. Since knowledge of authorization rules and certificate usage mechanisms may be considered sensitive, protection from disclosure of the SNMP traffic via encryption is also highly recommended. When this table contains a significant number of rows it may affect the system performance when accepting new (D)TLS connections.
o SNMPTLSTMCERTTOTSNTABLEは、最終的にSNMPV3 SecurityNameにマッピングされるTMSECURITYNAMESへの着信X.509証明書のマッピングを指定するために使用されます。このテーブルのオブジェクトの変更は、このテーブルの値の変更がデバイスへの着信接続のセキュリティに大きな影響を与えるため、適切に認証される必要があります。許可ルールと証明書の使用メカニズムに関する知識は敏感であると見なされる可能性があるため、暗号化によるSNMPトラフィックの開示からの保護も強くお勧めします。このテーブルにかなりの数の行が含まれている場合、新しい（d）TLS接続を受け入れると、システムのパフォーマンスに影響を与える可能性があります。
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 This MIB contains a collection of counters that monitor the (D)TLS connections being established with a device. Since knowledge of connection and certificate usage mechanisms may be considered sensitive, protection from disclosure of the SNMP traffic via encryption is highly recommended.
o このMIBには、デバイスで確立されている（d）TLS接続を監視するカウンターのコレクションが含まれています。接続および証明書の使用メカニズムに関する知識は敏感であると考えられる可能性があるため、暗号化によるSNMPトラフィックの開示からの保護を強くお勧めします。
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 SNMPv3 cryptographic mechanisms (for authentication and privacy).
実装者は、SNMPV3暗号化メカニズム（認証とプライバシー用）の完全なサポートを含む、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. Two TCP/UDP port numbers from the "Registered Ports" range of the Port Numbers registry, with the following keywords:
1. 次のキーワードを含む、ポート番号レジストリの「登録ポート」範囲からの2つのTCP/UDPポート番号：
Keyword Decimal Description References
------- ------- ----------- ----------
snmptls 10161/tcp SNMP-TLS [RFC5953]
snmpdtls 10161/udp SNMP-DTLS [RFC5953]
snmptls-trap 10162/tcp SNMP-Trap-TLS [RFC5953]
snmpdtls-trap 10162/udp SNMP-Trap-DTLS [RFC5953]
These are the default ports for receipt of SNMP command messages (snmptls and snmpdtls) and SNMP notification messages (snmptls- trap and snmpdtls-trap) over a TLS Transport Model as defined in this document.
これらは、このドキュメントで定義されているTLSトランスポートモデルを介したSNMPコマンドメッセージ（SNMPTLSおよびSNMPDTLS）およびSNMP通知メッセージ（SNMPTLS-TRAPおよびSNMPDTLS-TRAP）を受信するためのデフォルトポートです。
2. An SMI number (8) under snmpDomains for the snmpTLSTCPDomain object identifier
2. snmptlstcpdomainオブジェクト識別子のsnmpdomainsの下のSMI番号（8）
3. An SMI number (9) under snmpDomains for the snmpDTLSUDPDomain object identifier
3. snmpdtlsudpdomainオブジェクト識別子のsnmpdomainsの下のSMI番号（9）
4. An SMI number (198) under mib-2, for the MIB module in this document
4. このドキュメントのMIBモジュール用のMIB-2の下のSMI番号（198）
5. "tls" as the corresponding prefix for the snmpTLSTCPDomain in the SNMP Transport Domains registry
5. SNMPトランスポートドメインレジストリのSNMPTLSTCPDOMAINの対応するプレフィックスとしての「TLS」
6. "dtls" as the corresponding prefix for the snmpDTLSUDPDomain in the SNMP Transport Domains registry
6. SNMPトランスポートドメインレジストリのSNMPDTLSUDPDOMAINの対応するプレフィックスとしての「DTLS」
This document closely follows and copies the Secure Shell Transport Model for SNMP documented by David Harrington and Joseph Salowey in [RFC5592].
この文書は、[RFC5592]でDavid HarringtonとJoseph Saloweyが文書化したSNMPの安全なシェル輸送モデルを密接に追跡し、コピーします。
This document was reviewed by the following people who helped provide useful comments (in alphabetical order): Andy Donati, Pasi Eronen, David Harrington, Jeffrey Hutzelman, Alan Luchuk, Michael Peck, Tom Petch, Randy Presuhn, Ray Purvis, Peter Saint-Andre, Joseph Salowey, Juergen Schoenwaelder, Dave Shield, and Robert Story.
この文書は、（アルファベット順の順序で）有用なコメントの提供を支援した以下の人々によってレビューされました：アンディドナティ、パシエロネン、デビッドハリントン、ジェフリーハッツェルマン、アランルーチュク、マイケルペック、トムペック、ランディプレスン、レイパービス、ピーターサンアンドアンドレ、Joseph Salowey、Juergen Schoenwaelder、Dave Shield、およびRobert Story。
This work was supported in part by the United States Department of Defense. Large portions of this document are based on work by General Dynamics C4 Systems and the following individuals: Brian Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.
この作業は、米国国防総省によって部分的にサポートされていました。このドキュメントの大部分は、一般的なダイナミクスC4システムと次の個人による研究に基づいています：ブライアン・バリル、キム・ブライアント、ダナ・デルーカ、ダン・ハンソン、ティム・フエミラー、ジョン・ホルツハウアー、コリン・フーゲブーム、デイブ・コルバウ、クリス・クネアン、ダン・ナウル、チャールズLimoges、Steve Moccaldi、Gerardo Orlando、Brandon Yip。
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987.
[RFC1033] Lottor、M。、「ドメイン管理者オペレーションガイド」、RFC 1033、1987年11月。
[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月。
[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、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、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月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[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月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[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月。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591] Harrington、D。およびW. Hardaker、「Simple Network Management Protocol（SNMP）の輸送セキュリティモデル」、RFC 5591、2009年6月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952] Kawamura、S。およびM. Kawashima、「IPv6アドレステキスト表現の推奨」、RFC 5952、2010年8月。
[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月。
[RFC5343] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) Context EngineID Discovery", RFC 5343, September 2008.
[RFC5343] Schoenwaelder、J。、「Simple Network Management Protocol（SNMP）コンテキストEngineid Discovery」、RFC 5343、2008年9月。
[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月。
[HEARTBEAT] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security and Datagram Transport Layer Security Heartbeat Extension", Work in Progress, February 2010.
[Heartbeat] Seggelmann、R.、Tuexen、M。、およびM. Williams、「トランスポートレイヤーセキュリティおよびデータグラムトランスポートレイヤーセキュリティハートビートエクステンション」、2010年2月の作業。
The following sections describe example configuration for the SNMP-TLS-TM-MIB, the SNMP-TARGET-MIB, the NOTIFICATION-MIB, and the SNMP-VIEW-BASED-ACM-MIB.
次のセクションでは、SNMP-TLS-TM-MIB、SNMP-Target-MIB、通知MIB、およびSNMP-ViewベースのACM-MIBの構成の例について説明します。
The following row adds the "Joe Cool" user to the "administrators" group:
次の行は、「Joe Cool」ユーザーを「管理者」グループに追加します。
vacmSecurityModel = 4 (TSM) vacmSecurityName = "Joe Cool" vacmGroupName = "administrators" vacmSecurityToGroupStorageType = 3 (nonVolatile) vacmSecurityToGroupStatus = 4 (createAndGo)
vacmsecurityModel = 4（TSM）vacmsecurityName = "joe cool" vacmgroupName = "administrators" vacmsecuritytogroupStorageType = 3（lonvolatile）vacmsecuritytogroupStatus = 4（CreateAndgo）
The following row configures the snmpTlstmAddrTable to use certificate path validation and to require the remote notification receiver to present a certificate for the "server.example.org" identity.
次の行は、SNMPTLSTMADDRTABLEを設定して、証明書パス検証を使用し、リモート通知受信者に「server.example.org」IDの証明書を提示するように要求します。
snmpTargetAddrName = "toNRAddr" snmpTlstmAddrServerFingerprint = "" snmpTlstmAddrServerIdentity = "server.example.org" snmpTlstmAddrStorageType = 3 (nonVolatile) snmpTlstmAddrRowStatus = 4 (createAndGo)
snmptargetaddrname = "tonraddr" snmptlstmaddrserverfingerprint = "" snmptlstmaddrserveridentity = "server.example.org" snmptlstmaddrstorageType = 3（非揮発性）SNMPTLSTMADDRROWSTATUS = 4（CreateAndgo）
The following row configures the snmpTargetAddrTable to send notifications using TLS/TCP to the snmptls-trap port at 192.0.2.1:
次の行は、SNMPTARGETGETADDRTABLEを構成し、TLS/TCPを使用して192.0.2.1のSNMPTLS-TRAPポートに通知を送信します。
snmpTargetAddrName = "toNRAddr" snmpTargetAddrTDomain = snmpTLSTCPDomain snmpTargetAddrTAddress = "192.0.2.1:10162" snmpTargetAddrTimeout = 1500 snmpTargetAddrRetryCount = 3 snmpTargetAddrTagList = "toNRTag" snmpTargetAddrParams = "toNR" (MUST match below) snmpTargetAddrStorageType = 3 (nonVolatile) snmpTargetAddrColumnStatus = 4 (createAndGo)
snmpTargetAddrName = "toNRAddr" snmpTargetAddrTDomain = snmpTLSTCPDomain snmpTargetAddrTAddress = "192.0.2.1:10162" snmpTargetAddrTimeout = 1500 snmpTargetAddrRetryCount = 3 snmpTargetAddrTagList = "toNRTag" snmpTargetAddrParams = "toNR" (MUST match below) snmpTargetAddrStorageType = 3 (nonVolatile) snmpTargetAddrColumnStatus = 4 (createAndGo)
The following row configures the snmpTargetParamsTable to send the notifications to "Joe Cool", using authPriv SNMPv3 notifications through the TransportSecurityModel [RFC5591]:
次の行は、snmptargetparamstableを構成し、通知を「Joe cool」に送信し、transportSecurityModel [RFC5591]を介してAuthPRIV SNMPV3通知を使用して構成します。
snmpTargetParamsName = "toNR" (must match above) snmpTargetParamsMPModel = 3 (SNMPv3) snmpTargetParamsSecurityModel = 4 (TransportSecurityModel) snmpTargetParamsSecurityName = "Joe Cool" snmpTargetParamsSecurityLevel = 3 (authPriv) snmpTargetParamsStorageType = 3 (nonVolatile) snmpTargetParamsRowStatus = 4 (createAndGo0
snmpTargetParamsName = "toNR" (must match above) snmpTargetParamsMPModel = 3 (SNMPv3) snmpTargetParamsSecurityModel = 4 (TransportSecurityModel) snmpTargetParamsSecurityName = "Joe Cool" snmpTargetParamsSecurityLevel = 3 (authPriv) snmpTargetParamsStorageType = 3 (nonVolatile) snmpTargetParamsRowStatus = 4 (createAndGo0
The following row configures the snmpTlstmCertToTSNTable to map a validated client certificate, referenced by the client's public X.509 hash fingerprint, to a tmSecurityName using the subjectAltName component of the certificate.
次の行は、クライアントのpublic X.509ハッシュフィンガープリントが参照される検証済みのクライアント証明書をマップするようにSNMPTLSTMCERTTOTSNTABLEを構成します。
snmpTlstmCertToTSNID = 1 (chosen by ordering preference) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny snmpTlstmCertToTSNData = "" (not used) snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
snmpTlstmCertToTSNID = 1 (chosen by ordering preference) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny snmpTlstmCertToTSNData = "" (not used) snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
This type of configuration should only be used when the naming conventions of the (possibly multiple) Certification Authorities are well understood, so two different principals cannot inadvertently be identified by the same derived tmSecurityName.
このタイプの構成は、（おそらく複数の）認証当局の命名規則がよく理解されている場合にのみ使用する必要があるため、2つの異なるプリンシパルを誤って派生したtmsecurityNameによって誤って識別することはできません。
The following row configures the snmpTlstmCertToTSNTable to map a validated client certificate, referenced by the client's public X.509 hash fingerprint, to the directly specified tmSecurityName of "Joe Cool".
次の行は、クライアントのpublic X.509ハッシュフィンガープリントが参照される検証済みのクライアント証明書をマップするようにSNMPTLSTMCERTTOTSNTABLEを設定します。
snmpTlstmCertToTSNID = 2 (chosen by ordering preference) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNMapType = snmpTlstmCertSpecified snmpTlstmCertToTSNSecurityName = "Joe Cool" snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
snmpTlstmCertToTSNID = 2 (chosen by ordering preference) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNMapType = snmpTlstmCertSpecified snmpTlstmCertToTSNSecurityName = "Joe Cool" snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
Author's Address
著者の連絡先
Wes Hardaker SPARTA, Inc. P.O. Box 382 Davis, CA 95617 USA
Wes Hardaker Sparta、Inc。P.O.Box 382 Davis、CA 95617 USA
Phone: +1 530 792 1913
EMail: ietf@hardakers.net