Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 6353 SPARTA, Inc.
Obsoletes: 5953 July 2011
Category: Standards Track
ISSN: 2070-1721
Transport Layer Security (TLS) Transport Model for
the Simple Network Management Protocol (SNMP)
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 an 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とDTLSはどちらも既存の公共キーインフラストラクチャにうまく統合します。
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/rfc6353.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6353で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Changes Since RFC 5953 . . . . . . . . . . . . . . . . . . 8
2. The Transport Layer Security Protocol . . . . . . . . . . . . 8
3. How the TLSTM Fits into the Transport Subsystem . . . . . . . 8
3.1. Security Capabilities of This Model . . . . . . . . . . . 11
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12
3.1.3. (D)TLS Connections . . . . . . . . . . . . . . . . . . 13
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14
4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15
4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15
4.2. (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 18
4.3.2. SNMP Services for an Incoming Message . . . . . . . . 19
4.4. Cached Information and References . . . . . . . . . . . . 20
4.4.1. TLS Transport Model Cached Information . . . . . . . . 20
4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 20
4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 21
4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 21
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 21
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 21
5.1.1. DTLS over UDP Processing for Incoming Messages . . . . 22
5.1.2. Transport Processing for Incoming SNMP Messages . . . 23
5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 25
5.3. Establishing or Accepting a Session . . . . . . . . . . . 26
5.3.1. Establishing a Session as a Client . . . . . . . . . . 26
5.3.2. Accepting a Session as a Server . . . . . . . . . . . 28
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 29
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 30
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 30
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 30
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 30
6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 31
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 31
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 31
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 31
8. Operational Considerations . . . . . . . . . . . . . . . . . . 54
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.2. Notification Receiver Credential Selection . . . . . . . . 54
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 55
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 . . . . . . . . . . . . . . . 57
9.3. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 57
9.4. MIB Module Security . . . . . . . . . . . . . . . . . . . 57
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
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]で定義されているモジュラーSNMPv3アーキテクチャを理解することが重要であるとトランスポートサブシステム[RFC5590]によって強化します。他のアーキテクチャのサブシステムと対話する方法この文書で説明輸送モデルは、アーキテクチャに適合し、どこに理解するために、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とDTLSはどちらも既存の公共キーインフラストラクチャにうまく統合します。このドキュメントは、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）の構造で定義されたメカニズムを使用して定義されています。 [RFC2578]、[RFC2579]及び[RFC2580]：このメモは、STD 58に記載されている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輸送モデル（「TLSTM」として示される）を使用して通信する2つのSNMPエンティティの概念の概要を示します。一方のエンティティは、コマンド応答および通知発信アプリケーションを含み、他のコマンドジェネレータと通知受信機アプリケーション。アプリケーションタイプのこの特定の組み合わせは一例であり、他の組み合わせも同様に有効であることを理解すべきです。
Note: this diagram shows the Transport Security Model (TSM) being used as the security model that is defined in [RFC5591].
注：この図は、トランスポート・セキュリティ・モデル（TSM）は[RFC5591]で定義されたセキュリティモデルとして使用されて示しています。
+---------------------------------------------------------------------+
| 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の仕様と一致している用語を好むよりも、STD 62で定義されているSNMP関連の仕様との整合性については、このドキュメントには、専門用語を好みます。これは、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.
このドキュメントの「認証」は、典型的にはメッセージではなく、データソース認証またはピアのアイデンティティ認証「の信憑性を証明するのに役立つ」の英語の意味を指します。
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アプリケーション」[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とDTLSの両方を指します。 「（D）TLSは、」文を適宜いずれか、または両方のプロトコルに適用されることを示すために、これらの場所で使用されています。プロトコル間の区別が必要な場合、それらは独立して、「TLS」または「DTLS」を使用して呼ばれています。輸送モデルは、しかし、「TLS輸送モデル」という名前ではなく、TLSまたはDTLSプロトコルではなくTLSとDTLSの両方をサポートしていますこの文書に記載されている仕様、を意味しています。
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]（D）TLSとUSMながらSTD 62に強制的に実装セキュリティモデルで頻繁にユーザーを参照して、RFC 3411にこのメモで好ましい用語が "主要な"。校長は、「誰が」その代理としてサービスを提供しているか、処理には行われています。校長は、とりわけ、特定の役割には個人演技することができます。それぞれ特定の役割で行動すると個体の集合;アプリケーションまたはアプリケーションのセット、または管理ドメイン内のこれらの組み合わせ。
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プロトコルは、セッションの内部概念を有しており、セッションのこれら二つの概念が関連しているが、用語「セッション」が使用される場合、この文書は、（D）に直接ではなくTLSTMの特定のセッションを参照しています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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document obsoletes [RFC5953].
この文書では、[RFC5953]を廃止します。
Since the publication of RFC 5953, a few editorial errata have been noted. These errata are posted on the RFC Editor web site. These errors have been corrected in this document.
RFC 5953の出版以来、いくつかの社説正誤表が注目されています。これらの正誤表は、RFC EditorのWebサイトに掲載されています。これらのエラーは、このドキュメントで修正されました。
This document updates the references to RFC 3490 (IDNA 2003) to [RFC5890] (IDNA 2008), because RFC 3490 was obsoleted by RFC 5890.
RFC 3490は、RFC 5890で廃止されたため、この文書では、[RFC5890]（IDNA 2008）にRFC 3490（IDNA 2003）への参照を更新します。
References to RFC 1033 were replaced with references to [RFC1123].
RFC 1033への参照は、[RFC1123]への参照に置き換えられました。
Added informative reference to 5953.
5953に有益な参照を追加しました。
Updated MIB dates and revision date.
更新されたMIBの日付と改訂日。
(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エンティティ間のプライバシー、ピアのID認証、およびデータの整合性を提供することです。 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メッセージDispatcherに1 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:
（「（D）TLS TM」として示される）TLS輸送モデルは、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.
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.
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]).
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.
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]はサービス拒否（DoS）攻撃は、SNMPセキュリティプロトコルによって対処する必要はないと述べています。彼らは偽装されたIPアドレスに対してより脆弱であるため、しかし、（UDP上DTLSのような）コネクションレスのトランスポートは、DoS攻撃の様々な影響を受けやすいです。クッキーのメカニズムが使用されている方法の詳細については、セクション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)
認証付きとプライバシー（authPrivの）とO
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）から判断する認証されたプリンシパル、トランスポート・タイプ、および受信メッセージに関連付けられたトランスポート・アドレスのアイデンティティをTLS。 TLSトランスポートモデルは発信メッセージのための（D）TLSのアイデンティティおよび宛先タイプおよびアドレスを提供します。
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接続がセキュリティの要求されたレベルと少なくとも同じ高セキュリティを提供することを確実にしなければなりません。セキュリティレベルは、データの整合性とプライバシーを提供するために使用されるアルゴリズムに翻訳されてどのように実装依存です。しかし、NULL整合性および暗号化アルゴリズムは、認証やプライバシーのセキュリティレベルの要求を満たすために使用してはいけません。実装はこの主張を保証する認証とプライバシーの両方を提供cipher_suitesを許可する（D）TLSを強制するために選ぶかもしれません。
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上で使用される場合、一意のセッションに関連付けられたtransportDomain、transportAddress、tmSecurityName、及びrequestedSecurityLevelの組み合わせによってTLS輸送モデル内で識別されています。これらのパラメータはそれぞれユニークな組み合わせは、各アクティブ・セッションのローカルに選ばれたユニークなtlstmSessionIDを持たなければなりません。詳細については、TCPセッションに対して、第5節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内部セッションIDは、（例えば、再ネゴシエーション中）TLSTMによって見られるように、接続の寿命にわたって変化することができるので、これらの要件を満たしていない、必ずしも一意に識別しないことに注意してくださいTLSTMセッションが（同じD（TLS）内部セッションIDを共有する複数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）。輸送関連し、認証されたIDを含む（D）TLSセキュリティ関連情報は、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にディスパッチャ（）アブストラクトサービスインターフェイス（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 are typically determined and configured by a network administrator.
（D）TLS接続が（D）によって開始することができるが、そのようなコマンドジェネレータ、通知発信、プロキシフォワーダなどの通信を開始するSNMPアプリケーションに代わってクライアントを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に構成されています。この文書では、接続に使用する（D）TLSクライアント側の証明書を指定するためにSNMP-TARGET-MIBのたsnmpTargetParamsTableを拡張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 to 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ターゲットを構成する場合、snmpTargetAddrTableのsnmpTargetAddrTDomainとsnmpTargetAddrTAddressパラメータはsnmpTLSTCPDomain又はsnmpDTLSUDPDomain物体と適切なsnmpTLSAddress値に設定する必要があります。 SNMPv3のメッセージ処理モデルと共に使用した場合、たsnmpTargetParamsTableのsnmpTargetParamsMPModelカラムはsnmpTargetParamsSecurityNameが適切なのsecurityNameの値に設定する必要が3の値に設定する必要があり、そしてsnmpTlstmParamsTableのsnmpTlstmParamsClientFingerprintパラメータが指す値に設定する必要がありますローカルに保持証明書（および対応する秘密鍵）を使用します。例えば、他のパラメータは、使用する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.
snmpTargetParamsSecurityName列で定義されたセキュリティ名を送信する必要のあるすべての通知を許可するアクセス制御モデルで使用されます。
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証明書ベースの認証について説明し、認証の他の形態は、本明細書の範囲外です。 TLSTMの実装は、X.509証明書をサポートするために必要とされています。
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 an 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
tmSecurityNameに証明書ののsubjectAltNameかのCommonNameコンポーネントのマッピング、またはO
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.
展開はTLSTM特定tmSecurityNamesにX.509証明書の「のsubjectAltName」コンポーネントをマップする必要があります。認証されたIDは、ピアの証明書からの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 an 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は、後にセキュリティモデルによって、SNMPエンジンのsecurityNameにTLSTM特定tmSecurityNameから翻訳することができます。セキュリティモデルは、TSMのセキュリティモデル[RFC5591]のように、アイデンティティマッピングまたはTLS輸送モデルが提供するtmSecurityNameからセキュリティ名を導出するために、より複雑なマッピングを行うことができます。
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オクテット以下であることがsecurityNamesを制約します。 TLSTMはおそらくのsecurityNameの長さを増加させるメッセージまたはセキュリティモデルとの組み合わせで、tmSecurityNameを生成し、セキュリティ名の長さは32個のオクテットを超えて発生する可能性があります。例えば、TSMプレフィックスと対になってIPv6アドレスに由来する32オクテットのtmSecurityNameは、36オクテットのsecurityNameを生成します。そのようなセキュリティ名は、標準VACM又はTARGET MIBモジュールと共に使用することができなくなります。オペレータは、このような状況を回避するためのアルゴリズムとsubjectAltNamesをを選択するように注意する必要があります。
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証明書を使用して暗号_スイートを交渉しなければならない、そしてクライアントとサーバーの両方を認証する必要があります。強制的に実装暗号_スイートは、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サーバの実装は、（[RFC4347]はすでにクライアントがDTLS Cookieをサポートすることを要求する）DTLSクッキーをサポートしなければなりません。実装はすべてのDTLSハンドシェイクのためのクッキー交換を実行する必要はありません。ただし、デフォルトでそれを有効にすると、推奨されます。
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:
Dispatcherは輸送サブシステムで定義された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 )
statusInformationを=のsendMessage（destTransportDomain IN - 輸送ドメインがdestTransportAddressで使用する - のoutgoingMessageで使用するトランスポート・アドレス - outgoingMessageLengthで送信するメッセージ - tmStateReferenceその長さ - 状態を輸送する参照）
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.
destTransportDomain：関連するdestTransportAddressのための輸送ドメイン。輸送モデルは、関連するdestTransportAddressのトランスポート・タイプを決定するために、このパラメータを使用しています。この文書では、snmpTLSTCPDomainとsnmpDTLSUDPDomain輸送ドメインを指定します。
destTransportAddress: The transport address of the destination TLS Transport Model in a format specified by the SnmpTLSAddress TEXTUAL-CONVENTION.
destTransportAddress：SnmpTLSAddress TEXTUAL-CONVENTIONで指定された形式で宛先TLS輸送モデルのトランスポートアドレス。
outgoingMessage: The outgoing message to send to (D)TLS for encapsulation and transmission.
outgoingMessage：発信メッセージは、カプセル化及び送信のために（D）TLSに送信します。
outgoingMessageLength: The length of the outgoingMessage.
outgoingMessage長さ：のoutgoingMessageの長さ。
tmStateReference: A reference used to pass model-specific and mechanism-specific parameters between the Transport Subsystem and transport-aware Security Models.
tmStateReference：トランスポートサブシステムと輸送対応セキュリティモデルとの間のモデル固有の機構固有のパラメータを渡すために使用される参照。
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 )
statusInformationを= receiveMessage（transportDomain IN - transportAddress原点輸送ドメイン - incomingMessage原点輸送アドレス - incomingMessageLengthで受信したメッセージ - tmStateReferenceその長さ - 状態を輸送する参照）
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テキストの表記で指定された形式で受信されたメッセージの送信元のトランスポート・アドレス。
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.
tmStateReference：トランスポートサブシステムと輸送対応セキュリティモデルとの間のモデル固有の機構固有のパラメータを渡すために使用される参照。
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つのレベルがあります。 [RFC5590]「簡易ネットワーク管理プロトコル（SNMP）のためのトランスポートサブシステムは、」キャッシュおよび参照のための一般的な要件を定義します。
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輸送モデルによるtmStateReferenceフィールドの使用に関する詳細な処理手順については、第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はtmSecurityNameが単一TLSTMセッションを通過するすべてのトラフィックに対して一定でなければならない第5の手順に従って設定されたIDを表す（れるSnmpAdminString形式）人間可読な名前でなければなりません。メッセージは異なる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サーバ側で、tmSecurityNameは、第5.3.2節に記載の手順とSNMP-TLS-TM-MIBのsnmpTlstmCertToTSNTable説明句を使用して導出されます。
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クライアント側では、tmSecurityNameはtmStateReferenceを通じてセキュリティモデルによってTLS輸送モデルに提示されます。このtmSecurityNameは、典型的には、のコピーであるか（おそらくSNMP-TARGET-MIBで指定された構成の）アプリケーションによって渡されたセキュリティ名に由来します。セキュリティモデルは、おそらく（おそらくSNMP-TARGET-MIBで指定された構成の）アプリケーションによってセキュリティモデルに提示セキュリティ名からtmSecurityNameを導出しました。
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.
トランスポートモデル対応のセキュリティモデルは、おそらく通知およびアクセス制御のためのMIBモジュールで構成され、セキュリティ名からtmSecurityNameを導き出します。事業者はtmSecurityNames由来securityNamesを使用するMIBモジュールを設定するときに使用するものを知っているだろうので、輸送モデルは、予測可能なtmSecurityNamesを使用すべきです。 TLSTMは、SNMP-TLSTM-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は、領収書の時点でメッセージごとに記録されなければなりません。 tmSameSecurityが設定されている場合、記録tmSessionIDは、対応する送信メッセージを送信するために利用可能な（D）TLS接続は、着信メッセージ（例えば、への応答を受信したときに使用したのと同じ（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]で定義され、さらにSNMPエンティティ内の様々なサブシステム間を流れる概念的なデータを記述するために[RFC5590]によって拡張されてきました。 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.
statusInformationを中にエラー表示は、典型的には、オブジェクト識別子（OID）と増分エラーカウンタの値を含むであろう。これは、要求されたsecurityLevelとtmStateReferenceを伴うことがあります。返されたカウンタOIDと値のため、contextEngineはエラーカウンタのデフォルトのコンテキストへのsnmpEngineIDとのcontextNameのローカル値に設定されますので、メッセージごとのコンテキスト情報は、モデルを輸送するためにアクセスできません。
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項では、具体的UDPセッションでDTLSのために必要とされる逆多重化、複数のDTLS接続に必要な処理を記述しています。 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の場合、この分離はサポートされている場合、または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.
分離はDTLS接続状態にUDPデータグラムを受信した場合（代わりDTLS実装の）TLSTM実装によって行われ、以下の手順は、これを達成する一つの可能な方法を説明します。
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アドレスおよびポート）を使用して（[RFC3411]、セクション3.4.2を参照）ローカル設定データストア（LCD）を問い合わせます。
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.
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 are 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）のセッションは、DTLS接続ハンドル（実装依存の詳細）次に、LCDに存在し、その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）incomingMessage及びDTLSからincomingMessageLengthを取得します。これらの結果と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メッセージを通過することができ、部分的なSNMPメッセージは、TLSストリームから受信することができます。それは（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で説明しtlstmSessionIDに等しいです。 tmStateReferenceとtlstmSessionIDに格納されている場合tmSessionIDは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.
2) Create a tmStateReference cache for the subsequent reference and assign the following values within it:
2）その後の参照のためtmStateReferenceキャッシュを作成し、その中に次の値を割り当てます。
tmTransportDomain = snmpTLSTCPDomain or snmpDTLSUDPDomain as
appropriate.
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.
セクション3.1.2および5.3で説明したようにtmSecurityLevelは、セッションの由来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は= tlstmSessionIDは、上記のステップ1で説明しました。
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 )
statusInformationを= receiveMessage（transportDomain IN - transportAddress IN snmpTLSTCPDomain又はsnmpDTLSUDPDomain、 - incomingMessageで受信したメッセージのアドレス - tmStateReference IN SNMPメッセージの長さ - - トランスポート情報（D）incomingMessageLength IN TLSから全体SNMPメッセージ）
The Dispatcher sends a message to the TLS Transport Model using the following ASI:
Dispatcherは、以下の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 )
statusInformationを=のsendMessage（destTransportDomain IN - 輸送ドメインがdestTransportAddressで使用する - のoutgoingMessageに使用するトランスポート・アドレス - outgoingMessageLengthで送信するメッセージ - tmStateReferenceでの長さ - 交通情報）
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.
tmStateReferenceはtmTransportDomain、tmTransportAddress、tmSecurityName、tmRequestedSecurityLevel、及びtmSameSecurityの値を含むキャッシュを参照していない場合1）、次いで、snmpTlstmSessionInvalidCachesカウンタをインクリメントメッセージを破棄し、そしてstatusInformationを中にエラー表示を返します。このメッセージの処理が停止します。
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、tmSecurityName、tmRequestedSecurityLevel、及びtmSameSecurity値を抽出します。注：セッションがメッセージを送信することができる上にまだ存在しない場合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.
tmSameSecurityが真であるとtmSessionIDが未定義であるか、またはもはや開いているセッションを参照している場合3）、次いで、snmpTlstmSessionNoSessionsカウンタをインクリメントメッセージを破棄し、そしてstatusInformationを中にエラー表示を返します。このメッセージの処理が停止します。
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 an snmpTlstmSessionNoSessions error to the calling module and stop the processing of the message.
tmSameSecurityが偽であるとtmSessionIDが使用できなくなったセッションを参照している場合4）、次いで、実装はの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.
tmSessionIDが未定義の場合は5）、メッセージを介して送信するのに適したLCD内の対応するエントリがあるかどうかを確認するためにtmTransportDomain、tmTransportAddress、tmSecurityName、及びtmRequestedSecurityLevelを使用します。
5a) If there is a corresponding LCD entry, then this session
will be used to send the message.
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.
該当するLCDのエントリが存在しない場合は図5（b））、その後のOpenSession（）ASI（5.3.1節で詳しく説明する）を使用してセッションを開きます。実装は、（冗長のOpenSessionを防ぐために、メッセージバッファリングを提供することを望むかもしれない）同じキャッシュエントリのために呼び出します。エラーが（）のOpenSessionから返された場合、メッセージを破棄する、snmpTlstmSessionOpenErrorsをインクリメントし、tmStateReferenceを破棄呼ぶモジュールにエラー表示を返し、メッセージの処理を停止します。
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で示されるセッションのいずれかを使用して）、または前のステップ（4または起因するセッション5）、カプセル化および送信のための（D）TLSへのoutgoingMessageを渡します。
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 )
statusInformationを= - （tmStateReference、IN - tmStateReferenceをOUTに使用するトランスポート情報 - maxMessageSizeに使用するトランスポート情報 - 送信するSNMPエンティティの）errorIndicationや成功のOpenSession
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）snmpTlstmSessionOpensカウンタがインクリメントされます。
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に渡さまたは設定する必要があります。また、実装依存とおそらく政策に依存tmRequestedSecurityLevelは、（D）TLS接続によって提供されるセキュリティ機能に影響を与えるために使用される方法です。しかし、これが行われ、（D）TLSによって提供されるセキュリティ機能はtmRequestedSecurityLevelパラメータによって示されるセキュリティのレベルと少なくとも同程度に高くなければなりません。セッションの実際のセキュリティレベルがtmSecurityLevelとしてtmStateReferenceキャッシュで報告されます。強力な認証を提供するために、（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）destTransportDomainとdestTransportAddress値を使用して、クライアントは、メッセージの保全と暗号化のためのセッションキーを確立するために（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
include, but are not limited to, cryptographic validation
failures and an unexpected presented certificate identity.
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クライアントは、SNMPメッセージを送信してはならない、クライアント証明書が送られてきた、とTLS接続が完全に確立されています。
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).
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-TARGET-MIBに見出される構成以外の理由のために確立されている場合、この文書の範囲外の構成と手順に従わなければなりません。構成メカニズムは、管理構成システム全体の一貫性を確保するためsnmpTlstmAddrTableで定義されたものと本質的に類似していなければなりません。たとえば、SNMPを生成するためのコマンドラインツールは、サーバーの証明書のフィンガープリントまたはコマンドライン引数として期待されるホスト名のいずれかを指定してサポートする場合があります取得します。
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, and 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は、認証されたアイデンティティが信頼構成証明機関によって署名されていることの保証を提供します。サーバの証明書の検証は、（例えば、あるため、暗号化検証または提示アイデンティティの障害に期待されるという名前のエンティティと一致しませんでした）どのような方法で失敗した場合は、セッションの確立は失敗しなければなりません、とsnmpTlstmSessionInvalidServerCertificatesオブジェクトがインクリメントされます。セッションは、暗号化検証の失敗とsnmpTlstmCertToTSNTableルックアップの失敗を含め、すべて、何らかの理由で開くことができない場合は、snmpTlstmSessionOpenErrorsカウンタがインクリメントされ、処理が停止しています。
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）tmStateReferenceのtmSessionIDに設定されているTLSTM固有のセッション識別子（tlstmSessionID）は、セッションが正常に確立されていることを示すために、将来の使用のための特定の（D）TLS接続を指すように、TLS輸送モデルに渡されます。 tlstmSessionIDはまた、着信メッセージ（セクション5.1.2）の処理中に後で参照するためのLCDに格納されています。
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.
（D）TLSサーバは、クライアントの資格情報を確認することができたため、任意のクライアントからの新しいセッションの接続を受け入れる必要があります。これは、証明書パス検証処理（例えば、[RFC5280]）を介して、またはsnmpTlstmCertToTSNTableに構成された指紋を使用して、証明書の指紋照合を通じてクライアントの提示された証明書を認証することによって行われます。その後、サーバーは、次の手順を使用してリモートエンティティのアイデンティティを決定します。
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はtmSecurityNameとしてtmStateReferenceキャッシュに記録されています。ルックアップ・プロセスの詳細は、完全snmpTlstmCertToTSNTable MIBオブジェクトの記述節に記載されています。いずれかの検証（たとえば、なぜなら暗号検証の失敗のため、またはsnmpTlstmCertToTSNTableにおける適切な行の欠如）は、任意の方法で失敗した場合、セッション確立が失敗しなければならない、とsnmpTlstmSessionInvalidClientCertificatesオブジェクトがインクリメントされます。セッションは、暗号化検証の失敗を含め、すべて、何らかの理由で開くことができない場合は、snmpTlstmSessionOpenErrorsカウンタがインクリメントされ、処理が停止しています。
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を= closeSession（tmSessionID、IN - クローズするセッションのセッション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）必要に応じてカウンタsnmpTlstmSessionClientCloses又は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.
tmSessionIDに関連付けられているオープンセッションがない場合3）、次いでcloseSession処理を終了します。
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）TLSは、指定された接続を閉じます。これは、そのセッションのクリーンアップを実行することができる他の側に通知するためには、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.
一般的に、参照ポインタとして暗号ハッシュを使用して格納されたX.509証明書を参照するためにMIBモジュールオブジェクトを許可証明書のフィンガープリントO。
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証明書の使用およびSNMPv3 tmSecurityNamesに入ってくる（D）TLSクライアント証明書をマッピングするためのMIBテーブルを構成するためのSNMP-TARGET-MIBを拡張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は、（D）TLS接続が失敗したときに、サーバーの提示された証明書は、暗号化検証が失敗した期待値（snmpTlstmServerCertificateUnknown）またはので（snmpTlstmServerInvalidCertificate）を満たしていなかったので、管理ステーションに警告する通知を定義します。
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輸送モデルを実装するエンティティに適用されます。特に、想定されるのSNMPv2-MIB [RFC3418]、SNMP-FRAMEWORK-MIB [RFC3411]、SNMP-TARGET-MIB [RFC3413]、SNMPを実装するSNMP-TLS-TM-MIBを実装するエンティティ-NOTIFICATION-MIB [RFC3413]、およびSNMP-VIEW-BASED-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]、およびSNMPv2-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 ;
輸入MODULE-IDENTITY、OBJECT-TYPE、OBJECT-IDENTITY、MIB-2、snmpDomains、Counter32の、Unsigned32の、Gauge32、SNMPv2の-SMIからの通知-TYPE - RFC 2578またはテキストの表記、タイムスタンプ、RowStatusの、StorageTypeそれらの任意の更新、 AutonomousTypeのSNMPv2の-TC FROM - RFC 2579またはMODULE-COMPLIANCE、オブジェクト・グループ、のSNMPv2-CONF FROM NOTIFICATION-GROUPそれらの任意のアップデート - RFC 2580またはSNMP-FRAMEWORK-MIBかられるSnmpAdminStringそれらの任意のアップデート - RFC 3411、または任意の更新そのsnmpTargetParamsName、SNMP-TARGET-MIBからsnmpTargetAddrName - RFC 3413、またはそれらの任意のアップデート。
snmpTlstmMIB MODULE-IDENTITY LAST-UPDATED "201107190000Z"
snmpTlstmMIBのMODULE-IDENTITY LAST-UPDATED "201107190000Z"
ORGANIZATION "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
Russ Mundy SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 USA
ラス・マンディSPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046 USA
Editor: Wes Hardaker SPARTA, Inc. P.O. Box 382 Davis, CA 95617 USA ietf@hardakers.net "
編集者：ウェス・ハードフィールドSPARTA、Inc.の私書箱ボックス382デイビス、CA 95617 USA ietf@hardakers.net」
DESCRIPTION " The TLS Transport Model MIB
DESCRIPTION "TLS輸送モデルMIB
Copyright (c) 2010-2011 IETF Trust and the persons identified
as authors of the code. All rights reserved.
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)."
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。」
REVISION "201107190000Z" DESCRIPTION "This version of this MIB module is part of RFC 6353; see the RFC itself for full legal notices. The only change was to introduce new wording to reflect require changes for IDNA addresses in the SnmpTLSAddress TC."
REVISION「201107190000Z」DESCRIPTION「このMIBモジュールのこのバージョンはRFC 6353の一部です;完全な適法な通知についてはRFC自体を参照して唯一の変化はSnmpTLSAddress TCでIDNAアドレスの変更が必要に反映するために、新たな文言を導入することでした。」
REVISION "201005070000Z" DESCRIPTION "This version of this MIB module is part of RFC 5953; see the RFC itself for full legal notices."
REVISION「201005070000Z」DESCRIPTION「この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.
TCPトランスポートドメインを介してTLSオーバーOBJECT-IDENTITYステータス現在の説明」SNMPをsnmpTLSTCPDomain。対応するトランスポートアドレスはタイプ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"
::= { snmpDomains 8 }
snmpDTLSUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over DTLS via UDP transport domain. The corresponding transport address is of type SnmpTLSAddress.
UDP輸送ドメインを介してDTLS上OBJECT-IDENTITYステータス現在の説明」SNMPをsnmpDTLSUDPDomain。対応するトランスポートアドレスはタイプ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"
::= { 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.
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.
コロン '続く、角括弧（ '['、US-ASCII文字0x5B、および ']'、US-ASCII文字0x5D）によって囲まれ、（RFC 5952に記載されているように）IPv6アドレスは、コロンで区切られた形式でなければなりません：」（US-ASCII文字0x3A）とUS-ASCIIで10進数のポート番号。
A hostname is always in US-ASCII (as per RFC 1123); internationalized hostnames are encoded as A-labels as specified in RFC 5890. 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.
ホスト名は、（RFC 1123による）US-ASCIIに常にあります。 「：」（US-ASCII文字0x3A）とUS-ASCIIで10進数のポート番号ホスト名はコロンが続いているRFC 5890.に指定されている国際化ホスト名は、ラベルとしてエンコードされます。名前は、可能な限り完全指定する必要があります。
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." REFERENCE "RFC 1123: Requirements for Internet Hosts - Application and Support RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework RFC 5952: A Recommendation for IPv6 Address Text Representation " SYNTAX OCTET STRING (SIZE (1..255))
このテキストの表記法は、インデックスオブジェクトの構文として使用する場合、SMIv2の指定された128のサブ識別子（STD 58）の限界の問題があってもよいです。このテキストの表記法を使用して、すべてのMIBの文書がインデックスコンポーネントの明示的な制限事項は、管理ソフトウェアが守らなければならないことを長することをお勧めします。これは、インデックスコンポーネントのまたは概念的な行の記述節内または周囲のドキュメントに適用可能な制約を指定することにより、サイズの制約を含むいずれかによって行うことができる「基準」RFC 1123：インターネットホストのための要件 - アプリケーションとサポートRFC 5890：国際化ドメイン名を定義とドキュメントフレームワークRFC 5952：IPv6アドレスのテキスト表現」構文オクテットSTRING（SIZE（1 255））のための勧告のアプリケーション（IDNA）について
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.
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：トランスポート層セキュリティ（TLS）プロトコルバージョン1.2 http://www.iana.org/assignments/tls-parameters/』 SYNTAXオクテットSTRING（SIZE（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 OBJECT-IDENTITYステータス現在の説明は「tmSecurityNameへのsubjectAltNameのrfc822Nameでのマッピングrfc822Nameでのローカル部分は変更なしで渡されるが、名前のホスト部分は小文字で渡されなければならない1におけるこのマッピングの結果：。。同等の間の1の対応名前のホスト部分は小文字で渡さなければならないことを除いての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 OBJECT-IDENTITYステータス現在の説明は「次のようにバイナリエンコードされたアドレスを変換することによりtmSecurityNameへのsubjectAltNameのIPアドレスをマッピングします。
1) for IPv4, the value is converted into a
decimal-dotted quad address (e.g., '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.
IPアドレスのsubjectAltName値と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 OBJECT-IDENTITYステータス現在の説明は「対応するマッピングアルゴリズムを使用して、次のいずれかのフィールドをマッピングします。
|------------+----------------------------|
| 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.
tmSecurityNameを導出する際に、上記のタイプの証明書で最初に検出されたマッチングのsubjectAltName値を使用しなければなりません。 「アルゴリズム」列で指定されたマッピングアルゴリズムは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 OBJECT-IDENTITYステータス現在
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 a (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 a (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 a (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 a (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 a (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カウンタACCESS read-onlyステータス現在の説明「送信セッション（D）に設立されていなかった回数TLSクライアント上でSNMPによって提示されたサーバー証明書は、（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
snmpTlstmCertToTSNTableLastChanged OBJECT-TYPE構文タイムスタンプMAX-ACCESS read-onlyステータス電流
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.
SnmpTlstmCertToTSNEntry MAX-ACCESSステータス現在の説明のsnmpTlstmCertToTSNTable OBJECT-TYPE構文配列は「この表はtmSecurityNameに（D）TLSクライアントの提示X.509証明書をマッピングするために（D）TLSサーバで使用されています。
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.
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:
証明書は、（パス検証によって、または直接この表の指紋と一致するいずれか）に許容される発見された後、このテーブルは、リモート接続に識別するために適切なtmSecurityNameを決定するために調べられます。これは、そのsnmpTlstmCertToTSNID値に応じて優先順位順に、このテーブルから各アクティブ行を考慮することによって行われます。各行のsnmpTlstmCertToTSNFingerprint値は、行が着信接続のための一致であるか否かを判断します。
1) If the row's snmpTlstmCertToTSNFingerprint value
identifies the presented certificate, then consider the
row as a successful match.
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.
行のsnmpTlstmCertToTSNFingerprint値が信頼できるCA証明書のローカルに保持されたコピーを識別し、そのCA証明書が提示された証明書へのパスを検証するために使用された場合2）、次いで、成功一致として行を考えます。
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列の説明を参照してください。それは証明書に提示されたデータと組み合わせる行のデータからtmSecurityNameを決定することは不可能である場合、追加の行は、他の潜在的な一致を探して探索しなければなりません。得tmSecurityNameは、所与の行からマッピングされた場合tmSecurityNameの必要要件と互換性がありません（例えば、VACMは、32オクテットの最大長さを課し、証明書のsecurityNameが長くなる可能性が誘導される）、それは無効と一致考慮しなければならないと追加の行は、他の潜在的なマッチを探して検索しなければなりません。
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."
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 an 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はリード作成しますステータス現在の説明は「証明書からtmSecurityNameを導出するためのマッピングタイプを指定します。特定のタイプのマッピングの詳細については説明しOBJECT-IDENTITYの説明節に規定しますマッピング。マッピングは、それが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.
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構文RowStatus MAX-ACCESSはリード作成ステータス現在の説明「この概念的な列のステータス。このオブジェクトはこのテーブルから行を作成または除去するために使用されてもよいです。
To create a row in this table, an administrator must set this
object to either createAndGo(4) or 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、snmpTlstmCertToTSNMapType、及びsnmpTlstmCertToTSNData列が設定されるまで、特に、新しく作成された行をアクティブにすることができません。
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
snmpTlstmParamsEntryのOBJECT-TYPE SYNTAX SnmpTlstmParamsEntryアクセス不可能なMAX-ACCESS
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
snmpTlstmParamsRowStatusのOBJECT-TYPE構文RowStatus MAX-ACCESSはリード作成しますステータス現在の説明
"The status of this conceptual row. This object may be used
to create or remove rows from this table.
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.
SnmpTlstmAddrEntry MAX-ACCESSステータス現在の説明のsnmpTlstmAddrTable OBJECT-TYPE構文配列は「この表は、（D）TLS接続はSNMP-TARGET-MIBのエントリを使用して設定されている（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.
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値で存在する場合、snmpTlstmAddrServerIdentity列は予想ホスト名を含みます。これは、次のようにホスト名は、サーバの証明書と比較されると予想しました。
- 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.
- 実装はsubjectAltName拡張フィールド内のdNSNameに対して予期されているホスト名と一致するサポートしなければならないと被写体識別名のCommonName部に対して名前をチェックサポートするかもしれません。
- 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.
- 「*」（アスキー0x2a）ワイルドカード文字は、その中にsubjectAltName拡張（および一般名で、ホスト名を格納するために使用される場合）が、唯一のように、一番左の（最下位）DNSラベルののdNSNameで許可されています値。このワイルドカードは、サーバー名に任意の一番左の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-TARGET-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構文RowStatus MAX-ACCESSはリード作成ステータス現在の説明「この概念的な列のステータス。このオブジェクトはこのテーブルから行を作成または除去するために使用されてもよいです。
To create a row in this table, an administrator must set this
object to either createAndGo(4) or 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.
いかなる構成指紋またはCAがにエントリが存在しないため、これがあってもよい。それを検証するために許容されるなかったので、SNMPによって提示されたサーバー証明書上（D）TLSサーバが無効であったことをsnmpTlstmServerCertificateUnknown NOTIFICATION-TYPEオブジェクト{snmpTlstmSessionUnknownServerCertificate}ステータス現在の説明「通知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オブジェクト{snmpTlstmAddrServerFingerprint、snmpTlstmSessionInvalidServerCertificates}ステータス現在の説明「通知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切断メッセージを使用して優雅なセッション終了を提供する必要があります。実装はまた、ハートビート[HEARTBEAT]または他の検出機構の使用を介して、「壊れた」セッションを検出する代わりに、システムを持っているべきです。
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は、ターゲットのsnmpTargetParamsSecurityNameのためのエントリが含まれています。特定のポートで複数のプリンシパルをサポートしたいサーバーは、[RFC4366]のセクション3.1で定義されたサーバ名表示の拡張機能を利用するべきです。 tmSecurityNameのID認証が成功するように、サーバ名の表示のない受信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エンジンに要求することによって、通知元で処理することができます。
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]は周知localEngineIDとリモートSNMPプロトコルエンジンのsnmpEngineIDを学ぶために使用することができる検出メカニズムを導入します。実装は、[RFC5343]で定義されたcontextEngineID発見メカニズムをサポートし、使用することが推奨されます。
This document defines how SNMP messages can be transmitted over the TLS- and DTLS-based protocols. Each of these protocols is 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.
この文書では、SNMPメッセージがTLS-とDTLSベースのプロトコルを介して送信する方法を定義します。これらのプロトコルのそれぞれは、さらに、他のトランスポート（TCPおよびUDP）に基づいています。これら二つのベースプロトコルはまた、分解または制限されたネットワークにおいて、その性能として使用する（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.
この文書は、（D）TLSのセキュリティサービスを利用するためにSNMPを許可する輸送モデルを説明しています。セキュリティの脅威と（D）TLS輸送モデルは、これらの脅威は、本書で詳しく説明されている軽減する方法。セキュリティDTLSの考慮事項[RFC4347]でカバーされており、TLSのためのセキュリティ問題はセクション11及び付録Dに記載されており、E、およびTLS 1.2のF [RFC5246]。 UDPなどのコネクションレストランスポート上で実行すると、DTLSは、偽装されたIPアドレスからのサービス拒否攻撃に対して脆弱です。クッキー交換がこの問題に対処するために使用される方法の詳細については、セクション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 an 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ハンドシェイクは、認証されたアイデンティティの証明書を構成受け入れ証明機関によって署名されていることの保証を提供します。 （D）TLSは、さらに、認証されたIDに基づいてアクセスを許可または拒否する方法がありません。 （例えばVACMのような）アクセス制御モデルは、アクセス制御及びコマンド応答通知元から通知を受信する通知受信者の許可にコマンドジェネレータの要求の承認を提供します。しかしながら、man-in-the-middle攻撃を回避するために、（D）TLSベースの接続の両端が予想されたものに対して反対側が提示した証明書をチェックしなければなりません。たとえば、コマンド・ジェネレータは、コマンド応答者が提示され、期待されたX.509証明書を使用して自身を認証していることを確認しなければなりません。そうしないと、詐欺師は、最低でも、虚偽のデータを提示し、機密情報を受け取り、および/または構成は、実際に受信して作用して誤った信念を提供できるようになります。すべての操作（D）TLSサーバ及び（D）TLSクライアントのアイデンティティを認証し、検証する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の実装は通常、複数のトランスポート層セキュリティプロトコルのバージョンと同様に古いのSecure Sockets Layer（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メッセージからセキュリティ名とたsecurityLevelを導き出します。アクセス制御の決定は、そのためではなく、TLS輸送モデルにより提供される認証されたIDとたsecurityLevelを使用するよりも、SNMPメッセージの内容に基づいて作られています。交通セキュリティモデル（TSM）または別のセキュア輸送意識したセキュリティモデルを使用してのみSNMPv3メッセージがTLSTMトランスポートを介して送られることが推奨されます。
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:
読み書きおよび/またはリード作成のMAX-ACCESS句でこのMIBモジュールで定義された管理オブジェクトの数があります。そのようなオブジェクトは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響を与える可能性があります。これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です：
o The snmpTlstmParamsTable can be used to change the outgoing X.509 certificate used to establish a (D)TLS connection. Modifications to objects in this table need to be adequately authenticated since modifying the 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. Modifications to objects in this table need to be adequately authenticated since modifying the 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 an SNMPv3 securityName. Modifications to objects in this table need to be adequately authenticated since modifying the 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のセキュリティ名にマップされ得る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モジュールで読み取り可能なオブジェクトの一部（すなわち、アクセス可能ではない以外MAX-ACCESS持つオブジェクト）は、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。 GETおよび/またはこれらのオブジェクトへのアクセスを通知し、おそらく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を使用して）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）内のオブジェクトが存在しませんこのMIBモジュール。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for the 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実体が適切にのみプリンシパル（ユーザ）にオブジェクトへのアクセスを提供するように設定されていることを確認するために、顧客/オペレータ責任実際にGETまたはSET（変化への正当な権利を有することです/）/削除、それらを作成します。
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つのTCP / UDPポート番号、：
Keyword Decimal Description References
------- ------- ----------- ----------
snmptls 10161/tcp SNMP-TLS [RFC6353]
snmpdtls 10161/udp SNMP-DTLS [RFC6353]
snmptls-trap 10162/tcp SNMP-Trap-TLS [RFC6353]
snmpdtls-trap 10162/udp SNMP-Trap-DTLS [RFC6353]
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.
この文書で定義されるように、これらは、SNMPのコマンドメッセージ（snmptlsとsnmpdtls）とTLS輸送モデルを超えるSNMP通知メッセージ（snmptlsトラップとsnmpdtlsトラップ）を受け取るためのデフォルトポートです。
2. An SMI number (8) under snmpDomains for the snmpTLSTCPDomain object identifier
snmpTLSTCPDomainオブジェクト識別子のsnmpDomains下2.アンSMI番号（8）
3. An SMI number (9) under snmpDomains for the snmpDTLSUDPDomain object identifier
snmpDTLSUDPDomainオブジェクト識別子のsnmpDomains 3.アンSMI番号（9）
4. An SMI number (198) under mib-2, for the MIB module in this document
この文書に記載されているMIBモジュールのMIB-2 4.アンSMI番号（198）、
5. "tls" as the corresponding prefix for the snmpTLSTCPDomain in the SNMP Transport Domains registry
SNMP交通ドメインレジストリでsnmpTLSTCPDomainに対応する接頭辞として5.「TLS」
6. "dtls" as the corresponding prefix for the snmpDTLSUDPDomain in the SNMP Transport Domains registry
SNMP交通ドメインレジストリでsnmpDTLSUDPDomainに対応する接頭辞として6.「DTLS」
This document closely follows and copies the Secure Shell Transport Model for SNMP documented by David Harrington and Joseph Salowey in [RFC5592].
この文書では、密接に追随し、コピー[RFC5592]でデビッド・ハリントンとジョセフ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.
アンディ・ドナーティ、パシEronen、デヴィッド・ハリントン、ジェフリーHutzelman、アランLuchuk、マイケル・ペック、トム・ペッチ、ランディPresuhn、レイ・パーヴィス、ピーターサンアンドレ：この文書は（アルファベット順）有益なコメントを提供助け以下の人々によって検討されました、ジョセフSalowey、ユルゲンSchoenwaelder、デイブ盾、そしてロバート・ストーリー。
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システムと以下の個人での作業に基づいています：ブライアン・バリル、キム・ブライアント、ダナ・デルーカ、ダン・ハンソン、ティムHuemiller、ジョンHolzhauer、コリン・Hoogeboom、デイブKornbau、クリスKnaian、ダンKnaul、チャールズリモージュ、スティーブMoccaldi、ヘラルド・オーランド、ブランドン・イップ。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、エド。、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]レビ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル（SNMP）アプリケーション"、STD 62、RFC 3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
、STD 62、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnenの、B.、Presuhn、R.、およびK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、STD 62、RFC 3415、2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
、STD 62、RFC 3418、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）" [RFC3418] Presuhn、R.、。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]フライ、R.、レヴィ、D.、Routhier、S.、およびB. Wijnenの、 "バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、BCP 74、RFC 3584 、2003年8月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ハリントン、D.とJ. Schoenwaelder、RFC 5590、2009年6月 "簡易ネットワーク管理プロトコル（SNMP）のための輸送サブシステム"。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591]ハリントン、D.およびW. Hardaker、RFC 5591、2009年6月 "簡易ネットワーク管理プロトコル（SNMP）のためのトランスポート・セキュリティモデル"。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]川村、S.とM.川島、RFC 5952、2010年8月、 "IPv6アドレスのテキスト表現のための勧告"。
[HEARTBEAT] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", Work in Progress, July 2011.
[HEARTBEAT] Seggelmann、R.、Tuexen、M.、およびM.ウィリアムズ、 "トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）ハートビート拡張"、進歩、2011年7月での作業。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC5343] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) Context EngineID Discovery", RFC 5343, September 2008.
[RFC5343] Schoenwaelder、J.、 "簡易ネットワーク管理プロトコル（SNMP）コンテキストENGINEIDディスカバリー"、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]ハリントン、D.、Salowey、J.、およびW. Hardakerは、RFC 5592、2009年6月 "シェル輸送モデルは、簡易ネットワーク管理プロトコル（SNMP）のための安全な"。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J.、 "アプリケーション（IDNA）のための国際化ドメイン名：定義とドキュメントフレームワーク"、RFC 5890、2010年8月。
[RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5953, August 2010.
[RFC5953] Hardaker、W.、RFC 5953、2010年8月 "簡易ネットワーク管理プロトコル（SNMP）のためのトランスポート層セキュリティ（TLS）輸送モデル"。
Appendix A. Target and Notification Configuration Example
付録A.ターゲットと通知の設定例
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、NOTIFICATION-MIB、およびSNMP-VIEW-BASED-ACM-MIBのための構成例を記載しています。
A.1. Configuring a Notification Originator
A.1。通知の発信元を設定
The following row adds the "Joe Cool" user to the "administrators" group:
次の行は、「管理者」グループに「ジョー・クール」のユーザーを追加します。
vacmSecurityModel = 4 (TSM)
vacmSecurityName = "Joe Cool"
vacmGroupName = "administrators"
vacmSecurityToGroupStorageType = 3 (nonVolatile)
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.
次の行は、証明書パスの検証を使用すると「server.example.org」同一の証明書を提示する遠隔通知受信を要求するsnmpTlstmAddrTableを構成します。
snmpTargetAddrName = "toNRAddr"
snmpTlstmAddrServerFingerprint = ""
snmpTlstmAddrServerIdentity = "server.example.org"
snmpTlstmAddrStorageType = 3 (nonVolatile)
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:
次の行は、192.0.2.1でsnmptlsトラップポートにTLS / TCPを使用して通知を送信するためのsnmpTargetAddrTableを設定します。
snmpTargetAddrName = "toNRAddr"
snmpTargetAddrTDomain = snmpTLSTCPDomain
snmpTargetAddrTAddress = "192.0.2.1:10162"
snmpTargetAddrTimeout = 1500
snmpTargetAddrRetryCount = 3
snmpTargetAddrTagList = "toNRTag"
snmpTargetAddrParams = "toNR" (MUST match below)
snmpTargetAddrStorageType = 3 (nonVolatile)
snmpTargetAddrRowStatus = 4 (createAndGo)
The following row configures the snmpTargetParamsTable to send the notifications to "Joe Cool", using authPriv SNMPv3 notifications through the TransportSecurityModel [RFC5591]:
次の行はTransportSecurityModel [RFC5591]を介しauthPrivのSNMPv3の通知を使用して、「ジョー・クール」に通知を送信するたsnmpTargetParamsTableを設定します。
snmpTargetParamsName = "toNR" (must match above)
snmpTargetParamsMPModel = 3 (SNMPv3)
snmpTargetParamsSecurityModel = 4 (TransportSecurityModel)
snmpTargetParamsSecurityName = "Joe Cool"
snmpTargetParamsSecurityLevel = 3 (authPriv)
snmpTargetParamsStorageType = 3 (nonVolatile)
snmpTargetParamsRowStatus = 4 (createAndGo)
A.2. Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName
A.2。 tmSecurityNameの簡単な導出を利用するTLSTMの設定
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.
次の行は、証明書ののsubjectAltNameコンポーネントを使用tmSecurityNameに、クライアントの公開X.509ハッシュ指紋によって参照さ検証クライアント証明書をマッピングするsnmpTlstmCertToTSNTableを構成します。
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によって同定することができない。のときに命名規則を使用しなければなりません
A.3. Configuring TLSTM to Utilize Table-Driven Certificate Mapping
A.3。テーブル駆動証明書マッピングを利用するTLSTMの設定
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".
次の行は、「クールジョー」の直接指定tmSecurityNameに、クライアントの公開X.509のハッシュ指紋が参照する検証されたクライアント証明書を、マップするためにsnmpTlstmCertToTSNTableを設定します。
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
ウェスHardaker SPARTA、株式会社私書箱382デイビス、CA 95617 USA箱
Phone: +1 530 792 1913 EMail: ietf@hardakers.net
電話：+1 530 792 1913 Eメール：ietf@hardakers.net