[要約] RFC 5592は、SNMPのためのSecure Shellトランスポートモデルに関する規格です。このRFCの目的は、SNMPのセキュリティを向上させるために、SSHを使用したトランスポートモデルを提供することです。
Network Working Group D. Harrington
Request for Comments: 5592 Huawei Technologies (USA)
Category: Standards Track J. Salowey
Cisco Systems
W. Hardaker
Cobham Analytic Solutions
June 2009
Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
シンプルなネットワーク管理プロトコル（SNMP）のセキュアシェル輸送モデル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.
このメモは、Secure Shell（SSH）プロトコルを使用した、Simple Network Management Protocol（SNMP）のトランスポートモデルについて説明しています。
This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP.
このメモは、TCP/IPベースのインターネットのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義しています。特に、SNMPの安全なシェル輸送モデルを監視および管理するためのオブジェクトを定義します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................5
1.4. Motivation .................................................5
1.5. Constraints ................................................6
2. The Secure Shell Protocol .......................................7
3. How SSHTM Fits into the Transport Subsystem .....................8
3.1. Security Capabilities of this Model ........................8
3.1.1. Threats .............................................8
3.1.2. Message Authentication ..............................9
3.1.3. Authentication Protocol Support ....................10
3.1.4. SSH Subsystem ......................................11
3.2. Security Parameter Passing ................................12
3.3. Notifications and Proxy ...................................12
4. Cached Information and References ..............................13
4.1. Secure Shell Transport Model Cached Information ...........13
4.1.1. tmSecurityName .....................................13
4.1.2. tmSessionID ........................................14
4.1.3. Session State ......................................14
5. Elements of Procedure ..........................................14
5.1. Procedures for an Incoming Message ........................15
5.2. Procedures for Sending an Outgoing Message ................17
5.3. Establishing a Session ....................................18
5.4. Closing a Session .........................................20
6. MIB Module Overview ............................................21
6.1. Structure of the MIB Module ...............................21
6.2. Textual Conventions .......................................21
6.3. Relationship to Other MIB Modules .........................21
6.3.1. MIB Modules Required for IMPORTS ...................21
7. MIB Module Definition ..........................................22
8. Operational Considerations .....................................29
9. Security Considerations ........................................30
9.1. Skipping Public Key Verification ..........................31
9.2. Notification Authorization Considerations .................31
9.3. SSH User and Key Selection ................................31
9.4. Conceptual Differences between USM and SSHTM ..............31
9.5. The 'none' MAC Algorithm ..................................32
9.6. Use with SNMPv1/v2c Messages ..............................32
9.7. MIB Module Security .......................................32
10. IANA Considerations ...........................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................35
This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell (SSH) protocol [RFC4251] within a Transport Subsystem [RFC5590]. The Transport Model specified in this memo is referred to as the Secure Shell Transport Model (SSHTM).
このメモは、トランスポートサブシステム[RFC5590]内のSecure Shell（SSH）プロトコル[RFC4251]を使用して、単純なネットワーク管理プロトコルのトランスポートモデルを説明しています。このメモで指定されている輸送モデルは、Secure Shell Transport Model（SSHTM）と呼ばれます。
This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP.
このメモは、TCP/IPベースのインターネットのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義しています。特に、SNMPの安全なシェル輸送モデルを監視および管理するためのオブジェクトを定義します。
It is important to understand the SNMP architecture [RFC3411] and the terminology of the architecture to understand where the Transport Model described in this memo fits into the architecture and interacts with other subsystems within the architecture.
SNMPアーキテクチャ[RFC3411]とアーキテクチャの用語を理解して、このメモに記載されている輸送モデルがアーキテクチャに適合し、アーキテクチャ内の他のサブシステムと相互作用する場所を理解することが重要です。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準管理フレームワークを説明するドキュメントの詳細な概要については、RFC 3410 [RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアからアクセスされます。MIBオブジェクトは通常、単純なネットワーク管理プロトコル（SNMP）からアクセスされます。MIBのオブジェクトは、管理情報の構造（SMI）で定義されたメカニズムを使用して定義されます。このメモは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]およびSTD 58、RFC 2580 [RFC2580]に記載されているSMIV2に準拠したMIBモジュールを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Lowercase versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context that relates to compatibility with the RFC 3411 architecture or the subsystem defined here but that might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage.
キーワードの小文字バージョンは、通常の英語のように読み取る必要があります。通常ではありませんが、常にではありませんが、ここで定義されているRFC 3411アーキテクチャまたはサブシステムとの互換性に関連するコンテキストで使用されますが、それはワイヤの互換性に影響を与えないかもしれません。これらの用語は、提案されたIETFモデルの設計者がRFC 3411サブシステムと抽象サービスインターフェイス（ASIS）と互換性のあるものにするためのガイダンスとして使用されます。実装者の実装は異なる方法で自由に実装できます。これらの小文字の用語のいくつかの使用法は、単に通常の英語の使用です。
For consistency with SNMP-related specifications, this document favors terminology as defined in STD 62, rather than favoring terminology that is consistent with non-SNMP specifications. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard.
SNMP関連の仕様との一貫性のために、このドキュメントは、非SNMP仕様と一致する用語を支持するのではなく、STD 62で定義されている用語を好みます。これは、SNMPV3がSNMPV3が完全な標準に昇格したときに、他の非SNMP仕様の使用に一致するように変更されるように変更されないというIESGの決定と一致しています。
"Authentication" in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication.
このドキュメントの「認証」とは、通常、データソース認証やピアアイデンティティ認証ではなく、メッセージの信ity性を証明するために「役立つ」という英語の意味を指します。
The terms "manager" and "agent" are not used in this document because, in the RFC 3411 architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP 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]を参照してください。
The User-based Security Model (USM) [RFC3414] is a mandatory-to-implement Security Model in STD 62. While the SSH and USM specifications frequently refer to a user, the terminology preferred in [RFC3411] and in this memo is "principal". A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role, a set of individuals each acting in a particular role, an application or a set of applications, or a combination of these within an administrative domain.
ユーザーベースのセキュリティモデル（USM）[RFC3414]は、STD 62の義務的なセキュリティモデルです。SSHおよびUSM仕様は頻繁にユーザーを指しますが、[RFC3411]およびこのメモで好まれる用語は "主要"。校長とは、「WHO」に代わって提供されるか、処理が行われます。プリンシパルは、とりわけ、特定の役割で行動する個人、それぞれが特定の役割で行動する個人のセット、アプリケーションまたはアプリケーションのセット、または管理領域内のこれらの組み合わせです。
Throughout this document, the terms "client" and "server" are used to refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming SSH connection. Either SNMP entity may act as client or as server, as discussed further below.
このドキュメント全体で、「クライアント」と「サーバー」という用語を使用して、SSH輸送接続の両端を参照します。クライアントはSSH接続を積極的に開き、サーバーは着信SSH接続のために受動的に耳を傾けます。以下でさらに説明するように、SNMPエンティティはクライアントとして、またはサーバーとして機能する場合があります。
The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411], and the Transport Subsystem architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590].
読者は、[RFC3411]で定義されているSNMPアーキテクチャの説明と、「シンプルネットワーク管理プロトコル（SNMP）のトランスポートサブシステム」で指定されたトランスポートサブシステムアーキテクチャ拡張を読み取り、理解することが期待されています[RFC5590]。
This memo describes the Secure Shell Transport Model for SNMP, a specific SNMP Transport Model to be used within the SNMP Transport Subsystem to provide authentication, encryption, and integrity checking of SNMP messages.
このメモは、SNMPトランスポートサブシステム内で使用される特定のSNMPトランスポートモデルであるSNMPの安全なシェル輸送モデルについて説明し、SNMPメッセージの認証、暗号化、および整合性チェックを提供します。
In keeping with the RFC 3411 design decision to use self-contained documents, this document defines the elements of procedure and associated MIB module objects that are needed for processing the Secure Shell Transport Model for SNMP.
自己完結型ドキュメントを使用するRFC 3411の設計決定に沿って、このドキュメントでは、SNMPの安全なシェル輸送モデルを処理するために必要な手順と関連するMIBモジュールオブジェクトの要素を定義します。
This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation.
この仕様のモジュール性は、実装に特定の要件を課すものとして解釈されることを意図したものではありません。
Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the protocol. The User-based Security Model (USM) [RFC3414] was designed to be independent of other existing security infrastructures to ensure it could function when third-party authentication services were not available, such as in a broken network. As a result, USM utilizes a separate user and key-management infrastructure. Operators have reported that having to deploy another user and key-management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3.
Simple Network Management Protocol（SNMPV3）のバージョン3は、プロトコルにセキュリティを追加しました。ユーザーベースのセキュリティモデル（USM）[RFC3414]は、他の既存のセキュリティインフラストラクチャから独立して、壊れたネットワークなどのサードパーティ認証サービスが利用できない場合に機能できるようにするように設計されています。その結果、USMは別のユーザーとキー管理インフラストラクチャを利用します。オペレーターは、SNMPV3を使用するために別のユーザーとキー管理インフラストラクチャを展開する必要があることが、SNMPV3を展開しない理由であると報告しています。
This memo describes a Transport Model that will make use of the existing and commonly deployed Secure Shell security infrastructure. This Transport Model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success, and at the same time minimize implementation and deployment costs to minimize deployment time.
このメモは、既存および一般的に展開されている安全なシェルセキュリティインフラストラクチャを利用するトランスポートモデルについて説明しています。このトランスポートモデルは、ネットワーク管理者のセキュリティと運用上のニーズを満たし、運用環境でのユーザビリティを最大化して高い展開の成功を達成するように設計されており、同時に実装と展開コストを最小限に抑えて展開時間を最小限に抑えます。
This document addresses the requirement for the SSH client to authenticate the SSH server and for the SSH server to authenticate the SSH client, and describes how SNMP can make use of the authenticated identities in authorization policies for data access, in a manner that is independent of any specific Access Control Model.
このドキュメントでは、SSHクライアントがSSHサーバーを認証する要件とSSHサーバーがSSHクライアントを認証する要件に対応し、SNMPがデータアクセスの認証ポリシーで認証されたアイデンティティを使用して、それに依存しない方法で説明します。特定のアクセス制御モデル。
This document addresses the requirement to utilize client-authentication and key-exchange methods that support different security infrastructures and provide different security properties. This document describes how to use client authentication as described in "The Secure Shell (SSH) Authentication Protocol" [RFC4252]. The SSH Transport Model should work with any of the ssh-userauth methods, including the "publickey", "password", "hostbased", "none", "keyboard-interactive", "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx" (see the SSH Protocol Parameters registry maintained by IANA). The use of the "none" authentication method is NOT RECOMMENDED, as described in this document's Security Considerations. Local accounts may be supported through the use of the publickey, hostbased, or password methods. The password method allows for integration with a deployed password infrastructure, such as Authentication, Authorization, and Accounting (AAA) servers using the RADIUS protocol [RFC2865]. The SSH Transport Model SHOULD be able to take advantage of future-defined ssh-userauth methods, such as those that might make use of X.509 certificate credentials.
このドキュメントは、さまざまなセキュリティインフラストラクチャをサポートし、さまざまなセキュリティプロパティを提供するクライアント認証とキー交換方法を利用するための要件に対応しています。このドキュメントでは、「セキュアシェル（SSH）認証プロトコル」[RFC4252]で説明されているように、クライアント認証を使用する方法について説明します。SSHトランスポートモデルは、「publickey」、「パスワード」、「ホストベース」、「なし」、「キーボードインタラクティブ」、「gssapi-with-mic "、。" gssapiなど、SSH-Userauthメソッドのいずれかで動作する必要があります。-keyex "、" gssapi "、および" external-keyx "（IANAが管理するSSHプロトコルパラメーターレジストリを参照）。このドキュメントのセキュリティに関する考慮事項で説明されているように、「なし」認証方法の使用は推奨されません。ローカルアカウントは、publicKey、ホストベース、またはパスワードメソッドを使用してサポートされる場合があります。パスワード方法により、RADIUSプロトコル[RFC2865]を使用して、認証、承認、会計（AAA）サーバーなど、展開されたパスワードインフラストラクチャと統合できます。SSHトランスポートモデルは、X.509証明書資格情報を使用する可能性のある将来のSSH-USERAUTHメソッドを利用できるはずです。
It is desirable to use mechanisms that could unify the approach for administrative security for SNMPv3 and command line interfaces (CLI) and other management interfaces. The use of security services provided by Secure Shell is the approach commonly used for the CLI and is the approach being adopted for use with NETCONF [RFC4742]. This memo describes a method for invoking and running the SNMP protocol within a Secure Shell (SSH) session as an SSH Subsystem.
SNMPV3およびコマンドラインインターフェイス（CLI）およびその他の管理インターフェイスの管理セキュリティのアプローチを統合できるメカニズムを使用することが望ましいです。Secure Shellが提供するセキュリティサービスの使用は、CLIに一般的に使用されるアプローチであり、NetConf [RFC4742]で使用するために採用されているアプローチです。このメモは、SSHサブシステムとしてSECUREシェル（SSH）セッション内でSNMPプロトコルを呼び出して実行する方法について説明します。
This memo describes how SNMP can be used within a Secure Shell (SSH) session, using the SSH connection protocol [RFC4254] over the SSH transport protocol, and using ssh-userauth [RFC4252] for authentication.
このメモでは、SSH接続プロトコル[RFC4254]をSSH輸送プロトコルで使用し、認証のためにSSH-USERAUTH [RFC4252]を使用して、SSH Connection Protocol [RFC4254]を使用して、STHIRE SHELL（SSH）セッション内でSNMPを使用する方法を説明しています。
There are a number of challenges to be addressed to map Secure Shell authentication method parameters into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below.
SNMPが驚きなく動作し続けるように、安全なシェル認証方法パラメーターをSNMPアーキテクチャにマッピングするために対処すべき多くの課題があります。これらについては、以下で詳しく説明します。
The design of this SNMP Transport Model is influenced by the following constraints:
このSNMP輸送モデルの設計は、次の制約の影響を受けます。
1. In times of network stress, the transport protocol and its underlying security mechanisms SHOULD NOT depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or AAA protocols).
1. ネットワークストレスの時点では、トランスポートプロトコルとその基礎となるセキュリティメカニズムは、他のネットワークサービス（ネットワークタイムプロトコル（NTP）またはAAAプロトコルなどの準備が整った可用性に依存してはなりません。
2. When the network is not under stress, the Transport Model and its underlying security mechanisms MAY depend upon the ready availability of other network services.
2. ネットワークがストレスにさらされていない場合、輸送モデルとその基礎となるセキュリティメカニズムは、他のネットワークサービスの準備が整った可用性に依存する可能性があります。
3. It may not be possible for the Transport Model to determine when the network is under stress.
3. トランスポートモデルがネットワークがいつストレスにさらされているかを判断することは不可能かもしれません。
4. A Transport Model SHOULD NOT require changes to the SNMP architecture.
4. 輸送モデルは、SNMPアーキテクチャの変更を必要としないでください。
5. A Transport Model SHOULD NOT require changes to the underlying security protocol.
5. 輸送モデルは、基礎となるセキュリティプロトコルの変更を必要としないはずです。
SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major protocol components and add-on methods for user authentication:
SSHは、安全でないネットワーク上の安全なリモートログインおよびその他の安全なネットワークサービスのプロトコルです。これは、3つの主要なプロトコルコンポーネントとユーザー認証のためのアドオン方法で構成されています。
o The Transport Layer Protocol [RFC4253] provides server authentication and message confidentiality and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection but might also be used on top of any other reliable data stream.
o トランスポートレイヤープロトコル[RFC4253]は、サーバー認証とメッセージの機密性と整合性を提供します。オプションで圧縮を提供する場合があります。輸送層は通常、TCP/IP接続の上で実行されますが、他の信頼できるデータストリームの上にも使用される場合があります。
o The User Authentication Protocol [RFC4252] authenticates the client-side principal to the server. It runs over the Transport Layer Protocol.
o ユーザー認証プロトコル[RFC4252]は、クライアント側のプリンシパルをサーバーに認証します。輸送層プロトコルを介して実行されます。
o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel into several logical channels. It runs over the transport after successfully authenticating the principal.
o 接続プロトコル[RFC4254]は、暗号化されたトンネルをいくつかの論理チャネルに多重化します。プリンシパルを正常に認証した後、輸送を走ります。
o Generic Message Exchange Authentication [RFC4256] is a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard.
o 一般的なメッセージ交換認証[RFC4256]は、SSHプロトコルの汎用認証方法であり、キーボードを介して認証データを入力するインタラクティブ認証に適しています。
o "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol" [RFC4462] describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user-authentication method that uses a specified GSS-API mechanism to authenticate a user; it also defines a family of SSH key-exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.
o 「Secure Shell（SSH）プロトコルの一般的なセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）認証とキー交換」[RFC4462]は、SSHの認証とキー交換にGSS-APIを使用する方法を説明しています。指定されたGSS-APIメカニズムを使用してユーザーを認証するSSHユーザー認証方法を定義します。また、GSS-APIを使用してdiffie-hellmanキーエクスチェンジを認証するSSHキー交換方法のファミリーを定義します。
The client sends a service request once a secure, transport-layer connection has been established. A second service request is sent after client authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above.
クライアントは、安全な輸送層接続が確立されると、サービスリクエストを送信します。クライアント認証が完了した後、2番目のサービス要求が送信されます。これにより、新しいプロトコルを定義し、上記のプロトコルと共存できます。
The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections.
接続プロトコルは、幅広い目的に使用できるチャネルを提供します。安全なインタラクティブなシェルセッションをセットアップし、転送（「トンネリング」）任意のTCP/IPポートとX11接続のための標準的な方法が提供されています。
A Transport Model is a component of the Transport Subsystem [RFC5590] within the SNMP architecture. The SSH Transport Model thus fits between the underlying SSH transport layer and the Message Dispatcher [RFC3411].
トランスポートモデルは、SNMPアーキテクチャ内のトランスポートサブシステム[RFC5590]のコンポーネントです。したがって、SSH輸送モデルは、基礎となるSSH輸送層とメッセージディスパッチャー[RFC3411]の間に適合します。
The SSH Transport Model will establish a channel between itself and the SSH Transport Model of another SNMP engine. The sending Transport Model passes unencrypted messages from the Dispatcher to SSH to be encrypted, and the receiving Transport Model accepts decrypted incoming messages from SSH and passes them to the Dispatcher.
SSH輸送モデルは、それ自体と別のSNMPエンジンのSSH輸送モデルとの間にチャネルを確立します。送信輸送モデルは、暗号化されて暗号化されて暗号化されていないメッセージを暗号化して暗号化し、受信輸送モデルはSSHからの復号化された受信メッセージを受け入れ、それらをディスパッチャーに渡します。
After an SSH Transport Model channel is established, then SNMP messages can conceptually be sent through the channel from one SNMP Message Dispatcher to another SNMP Message Dispatcher. Multiple SNMP messages MAY be passed through the same channel.
SSHトランスポートモデルチャネルが確立された後、SNMPメッセージは、あるSNMPメッセージディスパッチャーから別のSNMPメッセージディスパッチャーにチャンネルを介して概念的に送信できます。複数のSNMPメッセージが同じチャネルに渡される場合があります。
The SSH Transport Model of an SNMP engine will perform the translation between SSH-specific security parameters and SNMP-specific, model-independent parameters.
SNMPエンジンのSSH輸送モデルは、SSH固有のセキュリティパラメーターとSNMP固有のモデル非依存パラメーターとの間の翻訳を実行します。
The Secure Shell Transport Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411]:
安全なシェル輸送モデルは、RFC 3411アーキテクチャ[RFC3411]によって特定された脅威に対する保護を提供します。
1. Modification of Information - SSH provides for verification that the contents of each message have not been modified during its transmission through the network by digitally signing each SSH packet.
1. 情報の変更-SSHは、各SSHパケットにデジタル的に署名することにより、ネットワークを介した送信中に各メッセージの内容が変更されていないことを検証します。
2. Masquerade - SSH provides for verification of the identity of the SSH server and the identity of the SSH client.
2. Masquerade -SSHは、SSHサーバーのIDとSSHクライアントのIDの確認を提供します。
SSH provides for verification of the identity of the SSH server through the SSH transport protocol server authentication [RFC4253]. This allows an operator or management station to ensure the authenticity of the SNMP engine that provides MIB data.
SSHは、SSH Transport Protocol Server認証[RFC4253]を介したSSHサーバーのIDの確認を提供します。これにより、オペレーターまたは管理ステーションは、MIBデータを提供するSNMPエンジンの信頼性を確保できます。
SSH provides a number of mechanisms for verification of the identity of the SSH client-side principal using the Secure Shell Authentication Protocol [RFC4252]. These include public key, password, and host-based mechanisms. This allows the SNMP Access Control Subsystem to ensure that only authorized principals have access to potentially sensitive data.
SSHは、安全なシェル認証プロトコル[RFC4252]を使用して、SSHクライアント側のプリンシパルのIDを検証するための多くのメカニズムを提供します。これらには、公開キー、パスワード、ホストベースのメカニズムが含まれます。これにより、SNMP Access Controlサブシステムが承認されたプリンシパルのみが潜在的に機密データにアクセスできるようにすることができます。
Verification of the client's principal identity is important for use with the SNMP Access Control Subsystem to ensure that only authorized principals have access to potentially sensitive data.
クライアントの主要なアイデンティティの検証は、SNMPアクセス制御サブシステムで使用するために重要であり、承認されたプリンシパルのみが潜在的に機密性の高いデータにアクセスできるようにします。
The SSH user identity is provided to the Transport Model, so it can be used to map to an SNMP model-independent securityName for use with SNMP access control and notification configuration. (The identity may undergo various transforms before it maps to the securityName.)
SSHユーザーIDはトランスポートモデルに提供されるため、SNMPアクセス制御と通知構成で使用するために、SNMPモデルに依存しないセキュリティ名にマッピングするために使用できます。（IDは、SecurityNameにマップする前にさまざまな変換を受けることがあります。）
3. Message Stream Modification - SSH protects against malicious re-ordering or replaying of messages within a single SSH session by using sequence numbers and integrity checks. SSH protects against replay of messages across SSH sessions by ensuring that the cryptographic keys used for encryption and integrity checks are generated afresh for each session.
3. メッセージストリームの変更-SSHは、シーケンス番号と整合性チェックを使用して、単一のSSHセッション内のメッセージの悪意のある再注文またはリプレイから保護します。SSHは、暗号化と整合性チェックに使用される暗号化キーが各セッションで新たに生成されるようにすることにより、SSHセッション全体のメッセージのリプレイから保護します。
4. Disclosure - SSH provides protection against the disclosure of information to unauthorized recipients or eavesdroppers by allowing for encryption of all traffic between SNMP engines.
4. 開示-SSHは、SNMPエンジン間のすべてのトラフィックの暗号化を許可することにより、不正な受信者または盗聴者への情報の開示に対する保護を提供します。
The RFC 3411 architecture recognizes three levels of security:
RFC 3411アーキテクチャは、3つのレベルのセキュリティを認識しています。
- without authentication and without privacy (noAuthNoPriv)
- 認証がなく、プライバシーなし（noauthnopriv）
- with authentication but without privacy (authNoPriv)
- 認証付きが、プライバシーがない（authnopriv）
- with authentication and with privacy (authPriv)
- 認証とプライバシー付き（AuthPRIV）
The Secure Shell protocol provides support for encryption and data integrity. While it is technically possible to support no authentication and no encryption in SSH, it is NOT RECOMMENDED by [RFC4253].
Secure Shellプロトコルは、暗号化とデータの整合性をサポートします。SSHの認証も暗号化もサポートできないことは技術的には可能ですが、[RFC4253]では推奨されません。
The SSH Transport Model determines from SSH the identity of the authenticated principal and the type and address associated with an incoming message, and provides this information to SSH for an outgoing message. The SSH transport-layer algorithms used to provide authentication, data integrity, and encryption SHOULD NOT be exposed to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided this and settled for an assertion by the Security Model that the requirements of securityLevel were met. The SSH Transport Model has no mechanisms by which it can test whether an underlying SSH connection provides auth or priv, so the SSH Transport Model trusts that the underlying SSH connection has been properly configured to support authPriv security characteristics.
SSH輸送モデルは、SSHから認証されたプリンシパルのIDと、着信メッセージに関連付けられたタイプとアドレスを決定し、発信メッセージのSSHにこの情報を提供します。認証、データの整合性、暗号化を提供するために使用されるSSH輸送層アルゴリズムは、SSH輸送モデル層にさらされるべきではありません。SNMPV3 WGはこれを故意に回避し、セキュリティモデルによるSecurityLevelの要件が満たされたという主張を解決しました。SSH輸送モデルには、基礎となるSSH接続が認証またはPRIVを提供するかどうかをテストできるメカニズムはないため、SSH輸送モデルは、基礎となるSSH接続がAuthPRIVセキュリティ特性をサポートするように適切に構成されていると信頼しています。
An SSH Transport-Model-compliant implementation MUST use an SSH connection that provides authentication, data integrity, and encryption that meets the highest level of SNMP security (authPriv). Outgoing messages specified with a securityLevel of noAuthNoPriv or authNoPriv are actually sent by the SSH Transport Model with authPriv-level protection.
SSH Transport-Modelに準拠した実装は、SNMPセキュリティの最高レベル（AUTHPRIV）を満たす認証、データの整合性、および暗号化を提供するSSH接続を使用する必要があります。Noauthnoprivまたはauthnoprivのセキュリティレベルで指定された発信メッセージは、実際にはSSH輸送モデルによってAuthPRIVレベルの保護を伴う送信されます。
The security protocols used in the Secure Shell Authentication Protocol [RFC4252] and the Secure Shell Transport Layer Protocol [RFC4253] are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises.
Secure Shell認証プロトコル[RFC4252]および安全なシェル輸送層プロトコル[RFC4253]で使用されるセキュリティプロトコルは、執筆時点で許容できる安全性と見なされます。ただし、この手順により、必要性が発生した場合、将来的に新しい認証方法とプライバシー方法を指定することができます。
The SSH Transport Model should support any server- or client-authentication mechanism supported by SSH. This includes the three authentication methods described in the SSH Authentication Protocol document [RFC4252] (publickey, password, and host-based), keyboard interactive, and others.
SSH輸送モデルは、SSHによってサポートされるサーバーまたはクライアントの認証メカニズムをサポートする必要があります。これには、SSH認証プロトコルドキュメント[RFC4252]（PublicKey、パスワード、およびホストベース）、キーボードインタラクティブなどで説明されている3つの認証方法が含まれます。
The password-authentication mechanism allows for integration with deployed password-based infrastructure. It is possible to hand a password to a service such as RADIUS [RFC2865] or Diameter [RFC3588] for validation. The validation could be done using the user name and user password attributes. It is also possible to use a different password-validation protocol such as the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or digest authentication [RFC5090] to integrate with RADIUS or Diameter. At some point in the processing, these mechanisms require the password to be made available as cleartext on the device that is authenticating the password, which might introduce threats to the authentication infrastructure.
パスワード認証メカニズムにより、展開されたパスワードベースのインフラストラクチャとの統合が可能になります。検証のために、RADIUS [RFC2865]や直径[RFC3588]などのサービスにパスワードを渡すことができます。検証は、ユーザー名とユーザーパスワードの属性を使用して実行できます。また、チャレンジハンドシェイク認証プロトコル（Chap）[RFC1994]やDigest Authentication [RFC5090]など、さまざまなパスワード検証プロトコルを使用して、半径または直径と統合することもできます。処理のある時点で、これらのメカニズムは、パスワードを認証しているデバイス上のクリアテキストとしてパスワードを利用可能にする必要があり、認証インフラストラクチャに脅威をもたらす可能性があります。
GSS-API key exchange [RFC4462] provides a framework for the addition of client-authentication mechanisms that support different security infrastructures and provide different security properties. Additional authentication mechanisms, such as one that supports X.509 certificates, may be added to SSH in the future.
GSS-APIキーエクスチェンジ[RFC4462]は、さまざまなセキュリティインフラストラクチャをサポートし、さまざまなセキュリティプロパティを提供するクライアント認証メカニズムを追加するためのフレームワークを提供します。X.509証明書をサポートするものなどの追加の認証メカニズムは、将来SSHに追加される場合があります。
This document describes the use of an SSH Subsystem for SNMP to make SNMP usage distinct from other usages.
このドキュメントでは、SNMPのSSHサブシステムを使用して、SNMPの使用を他の使用法とは異なるものにします。
An SSH Subsystem of type "snmp" is opened by the SSH Transport Model during the elements of procedure for an outgoing SNMP message. Since the sender of a message initiates the creation of an SSH session if needed, the SSH session will already exist for an incoming message; otherwise, the incoming message would never reach the SSH Transport Model.
タイプ「SNMP」のSSHサブシステムは、発信SNMPメッセージの手順要素中にSSH輸送モデルによって開かれます。メッセージの送信者は、必要に応じてSSHセッションの作成を開始するため、SSHセッションは既に着信メッセージのために存在します。それ以外の場合、着信メッセージはSSH輸送モデルに到達することはありません。
Implementations may choose to instantiate SSH sessions in anticipation of outgoing messages. This approach might be useful to ensure that an SSH session to a given target can be established before it becomes important to send a message over the SSH session. Of course, there is no guarantee that a pre-established session will still be valid when needed.
実装は、発信メッセージを見越してSSHセッションをインスタンス化することを選択する場合があります。このアプローチは、SSHセッションでメッセージを送信することが重要になる前に、特定のターゲットへのSSHセッションを確立できるようにするのに役立つかもしれません。もちろん、事前に確立されたセッションが必要に応じて有効であるという保証はありません。
SSH sessions are uniquely identified within the SSH Transport Model by the combination of tmTransportAddress and tmSecurityName associated with each session.
SSHセッションは、各セッションに関連付けられたTMTransportAddressとTMSECurityNameの組み合わせにより、SSH輸送モデル内で独自に識別されます。
Because naming policies might differ between administrative domains, many SSH client software packages support a user@hostname:port addressing syntax that operators can use to align non-equivalent account names. The SnmpSSHAddress Textual Convention echos this common SSH notation.
命名ポリシーは管理ドメイン間で異なる可能性があるため、多くのSSHクライアントソフトウェアパッケージはユーザー@hostName：ポートアドレス指定の構文をサポートしています。SNMPSSHADDRESSテキストコンベンションは、この一般的なSSH表記を反映しています。
When this notation is used in an SnmpSSHAddress, the SSH connection should be established with an SSH user name matching the "user" portion of the notation when establishing a session with the remote SSH server. The user name must be encoded in UTF-8 (per [RFC4252]). The "user" portion may or may not match the tmSecurityName parameter passed from the Security Model. If no "user@" portion is specified in the SnmpSSHAddress, then the SSH connection should be established using the tmSecurityName as the SSH user name when establishing a session with the remote SSH server.
この表記はSNMPSShaddressで使用される場合、SSH接続は、リモートSSHサーバーでセッションを確立するときに表記の「ユーザー」部分に一致するSSHユーザー名で確立する必要があります。ユーザー名はUTF-8（[RFC4252]ごとに）でエンコードする必要があります。「ユーザー」部分は、セキュリティモデルから渡されたTMSECurityNameパラメーターと一致する場合と一致しない場合があります。snmpsshaddressで「user@」部分が指定されていない場合、リモートSSHサーバーとのセッションを確立する際に、tmsecurityNameをSSHユーザー名として使用してSSH接続を確立する必要があります。
The SnmpSSHAddress and tmSecurityName associated with an SSH session MUST remain constant during the life of the session. Different SnmpSSHAddress values (with different hostnames, "user@" prefix names, and/or port numbers) will each result in individual SSH sessions.
SSHセッションに関連付けられたSNMPSSHADDRESSおよびTMSECURITYNAMEは、セッションの存続期間中は一定のままでなければなりません。異なるsnmpsshaddress値（異なるホスト名、 "user@" prefix名、および/またはポート番号）は、それぞれ個々のSSHセッションになります。
For incoming messages, SSH-specific security parameters are translated by the Transport Model into security parameters independent of the Transport and Security Models. The Transport Model accepts messages from the SSH Subsystem, records the transport-related and SSH-security-related information, including the authenticated identity, in a cache referenced by tmStateReference, and passes the WholeMsg and the tmStateReference to the Dispatcher using the receiveMessage() ASI (Abstract Service Interface).
着信メッセージの場合、SSH固有のセキュリティパラメーターは、トランスポートモデルによって輸送モデルとセキュリティモデルとは無関係にセキュリティパラメーターに翻訳されます。トランスポートモデルは、SSHサブシステムからのメッセージを受け入れ、TMSTateReferenceが参照されているキャッシュに、認証されたIDを含むトランスポート関連およびSSHセキュリティ関連の情報を記録し、ReceiveMessage（ASI（要約サービスインターフェイス）。
For outgoing messages, the Transport Model takes input provided by the Dispatcher in the sendMessage() ASI. The SSH Transport Model converts that information into suitable security parameters for SSH, establishes sessions as needed, and passes messages to the SSH Subsystem for sending.
発信メッセージの場合、トランスポートモデルは、sendmessage（）asiでディスパッチャーが提供する入力を受け取ります。SSHトランスポートモデルは、その情報をSSHの適切なセキュリティパラメーターに変換し、必要に応じてセッションを確立し、送信のためにSSHサブシステムにメッセージを渡します。
SSH connections may be initiated by command generators or by notification originators. Command generators are frequently operated by a human, but notification originators are usually unmanned automated processes. As a result, it may be necessary to provision authentication credentials on the SNMP engine containing the notification originator or to use a third-party key provider, such as Kerberos, so the engine can successfully authenticate to an engine containing a notification receiver.
SSH接続は、コマンドジェネレーターまたは通知オリジネーターによって開始される場合があります。コマンドジェネレーターは頻繁に人間によって操作されますが、通知オリジネーターは通常、無人の自動化されたプロセスです。その結果、通知オリジネーターを含むSNMPエンジンに認証資格情報をプロビジョニングするか、Kerberosなどのサードパーティのキープロバイダーを使用して、エンジンが通知レシーバーを含むエンジンに正常に認証できるようにする必要がある場合があります。
The targets to whom notifications or proxy requests should be sent is typically determined and configured by a network administrator. The SNMP-NOTIFICATION-MIB contains a list of targets to which notifications should be sent. The SNMP-TARGET-MIB module [RFC3413] contains objects for defining these management targets, including transport domains and addresses and security parameters, for applications such as notification generators and proxy forwarders.
通知またはプロキシリクエストを送信するターゲットは、通常、ネットワーク管理者によって決定および構成されます。SNMP-notification-mibには、通知を送信するターゲットのリストが含まれています。SNMP-Target-MIBモジュール[RFC3413]には、通知ジェネレーターやプロキシ転送業者などのアプリケーション用に、トランスポートドメインやアドレス、セキュリティパラメーターなどのこれらの管理目標を定義するオブジェクトが含まれています。
For the SSH Transport Model, transport type and address are configured in the snmpTargetAddrTable, and the securityName and securityLevel parameters are configured in the snmpTargetParamsTable. The default approach is for an administrator to statically preconfigure this information to identify the targets authorized to receive notifications or received proxied messages. Local access- control processing needs to be performed by a notification originator before notifications are actually sent, and this processing is done using the configured securityName. An important characteristic of this is that authorization is done prior to determining if the connection can succeed. Thus, the locally configured securityName is entirely trusted within the notification originator.
SSH輸送モデルの場合、輸送タイプとアドレスはSNMPTARGETGETADDRTABLEで構成され、SECULDENAMEおよびSECURETLEVELパラメーターはSNMPTARGETPARAMSTABLEで構成されています。デフォルトのアプローチは、管理者がこの情報を静的に事前に設定して、通知を受信または受信した承認されたターゲットを特定するか、プロキシメッセージを受信することです。ローカルアクセス制御処理は、通知が実際に送信される前に通知オリジネーターが実行する必要があり、この処理は設定されたセキュリティ名を使用して行われます。これの重要な特徴は、接続が成功できるかどうかを判断する前に承認が行われることです。したがって、ローカルで構成されたSecurityNameは、通知オリジネーター内で完全に信頼されています。
The SNMP-TARGET-MIB and NOTIFICATION-MIB MIB modules may be configured using SNMP or other implementation-dependent mechanisms, such as CLI scripting or loading a configuration file. It may be necessary to provide additional implementation-specific configuration of SSH parameters.
SNMP-Target-MIBおよびNotification-MIB MIBモジュールは、SNMPまたはCLIスクリプティングや構成ファイルのロードなどのその他の実装依存メカニズムを使用して構成できます。SSHパラメーターの追加の実装固有の構成を提供する必要がある場合があります。
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 a potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol" [RFC5590] defines general requirements for caches and references.
SNMP処理を実行する場合、保持する必要がある状態情報には2つのレベルがあります。リクエスト応答ペアをリンクする即時状態と、輸送とセキュリティに関連する潜在的に長期的な状態です。「シンプルネットワーク管理プロトコルのサブシステムを輸送」[RFC5590]は、キャッシュと参照の一般的な要件を定義します。
This document defines additional cache requirements related to the Secure Shell Transport Model.
このドキュメントでは、安全なシェル輸送モデルに関連する追加のキャッシュ要件を定義します。
The Secure Shell 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 SSH Transport Model.
安全なシェル輸送モデルには、キャッシュされた情報に関する具体的な責任があります。SSH輸送モデルによる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 an SSHTM session. Messages MUST NOT be sent through an existing SSH session that was established using a different tmSecurityName.
TMSECURITYNAMEは、セクション5の手順に従って設定されたIDを表す人間が読み取れる名前（SNMPADMINSTRING形式）である必要があります。TMSECURITYNAMEは、SSHTMセッションを通過するすべてのトラフィックに対して一定でなければなりません。メッセージを、別のTMSECurityNameを使用して確立された既存のSSHセッションを通じて送信してはなりません。
On the SSH server side of a connection:
接続のSSHサーバー側に：
The tmSecurityName should be the SSH user name. How the SSH user name is extracted from the SSH layer is implementation-dependent.
tmsecurityNameはSSHユーザー名である必要があります。SSHレイヤーからSSHユーザー名が抽出される方法は、実装依存です。
The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform an SSH identity to a tmSecurityName or to transform a tmSecurityName to an SSH identity.
SSHプロトコルは、ユーザー名フィールドを入力する必要があるかどうかについて必ずしも明確ではないため、GSSAPI認証を使用しているようないくつかの実装では、マッピングアルゴリズムを使用してSSH IDをTMESECURTYNAMEに変換するか、変換する必要がある場合があります。SSH IDへのtmsecurityName。
In other cases, the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange.
他の場合には、ユーザー名がサーバーによって検証されない場合があるため、これらの実装では、SSH交換中に交換された他の資格情報からユーザー名を取得する必要がある場合があります。
On the SSH client side of a connection:
接続のSSHクライアント側で：
The tmSecurityName is presented to the SSH Transport Model by the application (possibly because of configuration specified in the SNMP-TARGET-MIB).
TMSECurityNameは、アプリケーションによってSSHトランスポートモデルに提示されます（おそらくSNMP-Target-MIBで指定された構成のため）。
The securityName MAY be derived from the tmSecurityName by a Security Model and MAY be used to configure notifications and access controls in MIB modules. Transport Models SHOULD generate a predictable tmSecurityName so operators will know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames.
SecurityNameは、セキュリティモデルによってTMSECurityNameから派生している場合があり、MIBモジュールの通知とアクセスコントロールの構成に使用できます。トランスポートモデルは予測可能なTMESECURITYNAMEを生成する必要があるため、オペレーターはTMSECURITYNAMESから派生したSecurityNamesを使用するMIBモジュールを構成するときに何を使用するかを知ります。
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 SSH session available for sending a corresponding outgoing message is the same SSH session as was used when receiving the incoming message (e.g., a response to a request).
TMSESSIONIDは、領収書の時点でメッセージごとに記録する必要があります。TMSAMESECURTYが設定されると、記録されたTMESSESSIODIDを使用して、対応する発信メッセージの送信に利用できるSSHセッションが、着信メッセージを受信するときに使用されたのと同じSSHセッションであるかどうかを判断できます（例：リクエストへの応答）。
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 Secure Shell Transport Model uses some of these conceptual data flows when communicating between subsystems.
抽象サービスインターフェイスは[RFC3411]によって定義され、[RFC5590]によってさらに補強され、SNMPエンティティ内のさまざまなサブシステム間の概念データフローを説明しています。Secure Shell Transport Modelは、サブシステム間で通信するときにこれらの概念データフローの一部を使用します。
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, and if state information is available when a session is closed, the session-state information should also be released.
手順の要素を簡素化するために、状態情報のリリースが必ずしも明示的に指定されているとは限りません。原則として、メッセージが破棄されたときに状態情報が利用可能な場合、メッセージ状態情報もリリースされ、セッションが閉じられているときに状態情報が利用可能な場合、セッション状態情報もリリースされる必要があります。
An error indication in statusInformation will typically include the Object Identifier (OID) and value for an incremented error counter. This may be accompanied by the requested securityLevel and the tmStateReference. Per-message context information is not accessible to Transport Models, so for the returned counter OID and value, contextEngine would be set to the local value of snmpEngineID and contextName to the default context for error counters.
ステータス情報のエラー表示には、通常、オブジェクト識別子（OID）と増分エラーカウンターの値が含まれます。これには、要求されたSecurityLevelとTMStateReferenceが伴う場合があります。輸送モデルには、輸送モデルがアクセスできないため、返されたカウンターOIDと値の場合、コンテキストエンジンはSNMPENGINEIDのローカル値に設定され、コンテキスト名はエラーカウンターのデフォルトコンテキストに設定されます。
1. The SSH Transport Model queries the SSH engine, in an implementation-dependent manner, to determine the address the message originated from, the user name authenticated by SSH, and a session identifier.
1. SSHトランスポートモデルは、実装依存的にSSHエンジンを照会して、由来するメッセージ、SSHによって認証されたユーザー名、およびセッション識別子を決定するアドレスを決定します。
2. Determine the tmTransportAddress to be associated with the incoming message:
2. TMTRANSPORTADDRESSを決定するメッセージに関連付けられるようにします。
A. If this is a client-side SSH session, then the tmTransportAddress is set to the tmTransportAddress used to establish the session. It MUST exactly include any "user@" prefix associated with the address provided to the openSession() ASI.
A.これがクライアント側のSSHセッションである場合、TMTransportAddressはセッションの確立に使用されるTMTransportAddressに設定されます。opensession（）asiに提供されるアドレスに関連付けられた「user@」プレフィックスを正確に含める必要があります。
B. If this is a server-side SSH session and this is the first message received over the session, then the tmTransportAddress is set to the address the message originated from, determined in an implementation-dependent way. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmTransportAddress being set to the same value.
B.これがサーバー側のSSHセッションであり、これがセッションで受信された最初のメッセージである場合、TMTransportAddressは、実装依存の方法で決定されたメッセージのアドレスに設定されます。この値はSSHセッション全体で一定でなければならず、受信した将来のメッセージはTMTransportAddressが同じ値に設定されることになる必要があります。
C. If this is a server-side SSH session and this is not the first message received over the session, then the tmTransportAddress is set to the previously established tmTransportAddress for the session (the value from step B, determined from a previous incoming message).
C.これがサーバー側のSSHセッションであり、これがセッションで受信された最初のメッセージではない場合、TMTRANSPORTADDRESSはセッションの以前に確立されたTMTRANSPORTADDRESSに設定されます（以前の着信メッセージから決定されたステップBからの値）。
3. Determine the tmSecurityName to be associated with the incoming message:
3. 着信メッセージに関連付けられるtmsecurityNameを決定します。
A. If this is a client-side SSH session, then the tmSecurityName MUST be set to the tmSecurityName used to establish the session.
A.これがクライアント側のSSHセッションである場合、TMSECURITYNAMEを使用してセッションを確立するために使用されるTMSECurityNameに設定する必要があります。
B. If this is a server-side SSH session and this is the first message received over the session, then the tmSecurityName is set to the SSH user name. How the SSH user name is extracted from the SSH layer is implementation-dependent. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmSecurityName being set to the same value.
B.これがサーバー側のSSHセッションであり、これがセッションで受信された最初のメッセージである場合、TMSECURITYNAMEはSSHユーザー名に設定されます。SSHレイヤーからSSHユーザー名が抽出される方法は、実装依存です。この値はSSHセッション全体で一定でなければならず、受信した将来のメッセージはTMSECurityNameを同じ値に設定する必要があります。
C. If this is a server-side SSH session and this is not the first message received over the session, then the tmSecurityName is set to the previously established tmSecurityName for the session (the value from step B, determined from a previous incoming message).
C.これがサーバー側のSSHセッションであり、これがセッションで受信された最初のメッセージではない場合、TMSECURTYNAMEはセッションの以前に確立されたTMSECURITYNAMEに設定されます（以前の着信メッセージから決定されたステップBからの値）。
4. Create a tmStateReference cache for subsequent reference to the information.
4. 情報をその後参照するために、tmStateReferenceキャッシュを作成します。
tmTransportDomain = snmpSSHDomain
tmTransportAddress = the derived tmTransportAddress from step 2.
tmtransportaddress =ステップ2から派生したtmtransportaddress。
tmSecurityName = the derived tmSecurityName from step 3.
tmsecurityName =ステップ3の派生tmsecurityName。
tmTransportSecurityLevel = "authPriv" (authentication and confidentiality MUST be used to comply with this Transport Model.)
tmtransportsecuritylevel = "authpriv"（この輸送モデルに準拠するために、認証と機密性を使用する必要があります。）
tmSessionID = an implementation-dependent value that can be used to detect when a session has closed and been replaced by another session. The value in tmStateReference MUST uniquely identify the session over which the message was received. This session identifier MUST NOT be reused until there are no references to it remaining.
TMSESSIONID =セッションが閉じられたときに別のセッションに置き換えられたときに検出するために使用できる実装依存の値。tmStateReferenceの値は、メッセージが受信されたセッションを一意に識別する必要があります。このセッション識別子は、残りの参照がないまで再利用してはなりません。
Then the Transport Model passes the message to the Dispatcher using
the following ASI:
statusInformation =
receiveMessage(
IN transportDomain -- snmpSSHDomain
IN transportAddress -- the tmTransportAddress for the message
IN wholeMessage -- the whole SNMP message from SSH
IN wholeMessageLength -- the length of the SNMP message
IN tmStateReference -- (NEW) transport info
)
The Dispatcher passes the information to the Transport Model using the ASI defined in the Transport Subsystem:
ディスパッチャーは、トランスポートサブシステムで定義されているASIを使用して、情報を輸送モデルに渡します。
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 -- (NEW) transport info
)
The SSH Transport Model performs the following tasks.
SSH輸送モデルは、次のタスクを実行します。
1. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity, then increment the snmpSshtmSessionInvalidCaches counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops.
1. tmStateReferenceがtmtransportdomain、tmtransportaddress、tmsecurityName、tmrequestedsecuritylevel、およびtmesamesecurityの値を含むキャッシュを参照しない場合、snmpsshtssessioninvalidcachesを削除し、メッセージを捨て、誤差を返します。このメッセージの処理は停止します。
2. Extract the tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and tmSessionID from the tmStateReference.
2. tmStateReferenceからtmtransportdomain、tmtransportaddress、tmsecurityname、tmrequestedsecuritylevel、tmsamesecurity、およびtmsessionidを抽出します。
3. Identify an SSH session over which to send the messages:
3. メッセージを送信するSSHセッションを特定します。
A. If tmSameSecurity is true and there is no existing session with a matching tmSessionID, tmSecurityName, and tmTransportAddress, then increment the snmpSshtmSessionNoSessions counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops.
A. TMSAMESECURTYが真であり、TMSESSIONID、TMSECURITYNAME、およびTMTRANSPORTADDRESSを備えた既存のセッションがない場合、SNMPSSHTMSESTIONNOSESIONSカウンターをインクリメントし、メッセージを破棄し、ステータス情報のエラー表示を返します。このメッセージの処理は停止します。
B. If there is a session with a matching tmSessionID, tmTransportAddress, and tmSecurityName, then select that session.
B.一致するTMSESSIONID、TMTRANSPORTADDRESS、およびTMSECURITYNAMEを使用したセッションがある場合は、そのセッションを選択します。
C. If there is a session that matches the tmTransportAddress and tmSecurityName, then select that session.
C. tmtransportaddressとtmsecurityNameに一致するセッションがある場合は、そのセッションを選択します。
D. If the above steps failed to select a session to use, then call openSession() with the tmStateReference as a parameter.
D.上記の手順で使用するセッションの選択に失敗した場合は、tmStateReferenceをパラメーターとしてopensession（）を呼び出します。
+ If openSession fails, then discard the message, release tmStateReference, and pass the error indication returned by openSession back to the calling module. Processing of this message stops.
+ Opensessionが失敗した場合、メッセージを破棄し、tmStateReferenceをリリースし、Opensessionによって返されるエラー表示を通話モジュールに戻します。このメッセージの処理は停止します。
+ If openSession succeeds, then record the destTransportDomain, destTransportAddress, tmSecurityname, and tmSessionID in an implementation-dependent manner. This will be needed when processing an incoming message.
+ Opensessionが成功した場合は、Dest Transportdomain、Dest TransportAddress、TMSEcurityName、およびTMESSESSIODを実装依存的に記録します。これは、着信メッセージを処理するときに必要です。
4. Pass the wholeMessage to SSH for encapsulation as data in an SSH message over the identified SSH session. Any necessary additional SSH-specific parameters should be provided in an implementation-dependent manner.
4. 識別されたSSHセッションでSSHメッセージのデータとしてカプセル化のために、wholemessageをSSHに渡します。必要な追加のSSH固有のパラメーターは、実装依存的に提供する必要があります。
The Secure Shell Transport Model provides the following Abstract Service Interface (ASI) to describe the data passed between the SSH Transport Model and the SSH service. It is an implementation decision how such data is passed.
Secure Shell Transport Modelは、SSH輸送モデルとSSHサービスの間で渡されたデータを記述するために、次の抽象サービスインターフェイス（ASI）を提供します。これは、そのようなデータがどのように渡されるかを実装する決定です。
statusInformation =
openSession(
IN tmStateReference -- transport information to be used
OUT tmStateReference -- transport information to be used
IN maxMessageSize -- of the sending SNMP entity
)
The following describes the procedure to follow to establish a session between a client and server to run SNMP over SSH. This process is used by any SNMP engine establishing a session for subsequent use.
以下は、SSHを介してSNMPを実行するためにクライアントとサーバーの間のセッションを確立するための手順について説明します。このプロセスは、その後の使用のためのセッションを確立するSNMPエンジンによって使用されます。
This will 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. Increment the snmpSshtmSessionOpens counter.
1. snmpsshtmsセッションペンズカウンターをインクリメントします。
2. Using tmTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server, and exchange keys for message integrity and encryption. The transportAddress associated with a session MUST remain constant during the lifetime of the SSH session. Implementations may need to cache the transportAddress passed to the openSession API for later use when performing incoming message processing (see Section 5.1).
2. TMTransportAddressを使用して、クライアントはSSHトランスポートプロトコルを使用してSSHトランスポート接続を確立し、サーバーを認証し、キーをメッセージの整合性と暗号化と交換します。セッションに関連付けられたTransportAddressは、SSHセッションの寿命の間、一定のままでなければなりません。実装は、着信メッセージ処理を実行するときに後で使用するためにOpenSession APIに渡されたTransportAddressをキャッシュする必要がある場合があります（セクション5.1を参照）。
1. To authenticate the server, the client usually stores pairs (tmTransportAddress, server host public key) in an implementation-dependent manner.
1. サーバーを認証するために、クライアントは通常、実装依存的にペア（TMTransportAddress、サーバーホスト公開キー）を保存します。
2. The other parameters of the transport connection are provided in an implementation-dependent manner.
2. 輸送接続の他のパラメーターは、実装依存的に提供されます。
3. If the attempt to establish a connection is unsuccessful or if server-authentication fails, then snmpSshtmSessionOpenErrors is incremented, an openSession error indication is returned, and openSession processing stops.
3. 接続を確立しようとする試みが失敗した場合、またはサーバーと認証が失敗した場合、snmpsshtssossionopenerrorsが増加し、オープンセッションエラーの表示が返され、オープンセッション処理が停止します。
3. The client will then invoke an SSH authentication service to authenticate the principal, such as that described in the SSH authentication protocol [RFC4252].
3. その後、クライアントはSSH認証サービスを呼び出して、SSH認証プロトコル[RFC4252]に記載されているようなプリンシパルを認証します。
1. If the tmTransportAddress field contains a user name followed by an '@' character (US-ASCII 0x40), that user name string should be presented to the SSH server as the "user name" for user-authentication purposes. If there is no user name in the tmTransportAddress, then the tmSecurityName should be used as the user name.
1. TMTRANSPORTADDRESSフィールドにユーザー名が含まれている場合、「@」文字（US-ASCII 0x40）が続く場合、ユーザー名の文字列をユーザー認証のために「ユーザー名」としてSSHサーバーに提示する必要があります。tmtransportaddressにユーザー名がない場合は、TMSECURITYNAMEをユーザー名として使用する必要があります。
2. The credentials used to authenticate the SSH principal are determined in an implementation-dependent manner.
2. SSHプリンシパルの認証に使用される資格情報は、実装依存的に決定されます。
3. In an implementation-specific manner, invoke the SSH user-authentication service using the calculated user name.
3. 実装固有の方法で、計算されたユーザー名を使用してSSHユーザー認証サービスを呼び出します。
4. If the user authentication is unsuccessful, then the transport connection is closed, the snmpSshtmSessionUserAuthFailures counter is incremented, an error indication is returned to the calling module, and processing stops for this message.
4. ユーザー認証が失敗した場合、トランスポート接続が閉じられ、SNMPSSHTSSESSIONSERAUTHFAILURESカウンターが増加し、エラー表示が呼び出しモジュールに返され、このメッセージの処理停止が停止します。
4. The client should invoke the "ssh-connection" service (also known as the SSH connection protocol [RFC4254]), and request a channel of type "session". If unsuccessful, the transport connection is closed, the snmpSshtmSessionNoChannels counter is incremented, an error indication is returned to the calling module, and processing stops for this message.
4. クライアントは、「SSH接続」サービス（SSH Connection Protocol [RFC4254]とも呼ばれる）を呼び出し、タイプ「セッション」のチャネルを要求する必要があります。失敗した場合、トランスポート接続が閉じられている場合、SNMPSSHTSSESTIONNOCHANNELSカウンターが増加し、呼び出しモジュールにエラー表示が返され、このメッセージの処理停止が停止します。
5. The client invokes "snmp" as an SSH Subsystem, as indicated in the "subsystem" parameter. If unsuccessful, the transport connection is closed, the snmpSshtmSessionNoSubsystems counter is incremented, an error indication is returned to the calling module, and processing stops for this message.
5. クライアントは、「サブシステム」パラメーターに示されているように、「SNMP」をSSHサブシステムとして呼び出します。失敗した場合、トランスポート接続が閉じられている場合、SNMPSSHTSSESTIONNOSUBSYSTEMSカウンターが増加し、エラー表示が呼び出しモジュールに返され、このメッセージの処理停止が停止します。
In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Transport Model MUST default to providing access to the "snmp" SSH Subsystem if the SSH session is established using the IANA-assigned TCP ports (5161 and 5162). Servers SHOULD be configurable to allow access to the SNMP SSH Subsystem over other ports.
SNMPトラフィックをファイアウォールやその他のネットワークデバイスによって簡単に識別およびフィルタリングできるようにするために、SCUREシェルトランスポートモデルを使用してSNMPエンティティに関連するサーバーがデフォルトで「SNMP」SSHサブシステムへのアクセスを提供する必要があります。IANAが割り当てられたTCPポート（5161および5162）。サーバーは、他のポートを介してSNMP SSHサブシステムにアクセスできるように構成可能である必要があります。
6. Set tmSessionID in the tmStateReference cache to an implementation-dependent value to identify the session.
6. TMStateReferenceキャッシュのTMSESSIONIDを実装依存の値に設定して、セッションを識別します。
7. The tmSecurityName used to establish the SSH session must be the only tmSecurityName used with the session. Incoming messages for the session MUST be associated with this tmSecurityName value. How this is accomplished is implementation-dependent.
7. SSHセッションを確立するために使用されるTMESECURITYNAMEは、セッションで使用される唯一のTMSECURITYNAMEでなければなりません。セッションの着信メッセージは、このtmsecurityName値に関連付けられている必要があります。これがどのように達成されるかは、実装依存です。
The Secure Shell Transport Model provides the following ASI to close a session:
安全なシェル輸送モデルは、セッションを閉じるために次のASIを提供します。
statusInformation = closeSession( IN tmSessionID -- session ID of session to be closed )
StatusInformation = closessession（TMSESSIONIDで - 閉じるセッションのセッションID）
The following describes the procedure to follow to close a session between a client and server. This process is followed by any SNMP engine to close an SSH session. It is implementation-dependent when a session should be closed. The calling code should release the associated tmStateReference.
以下は、クライアントとサーバー間のセッションを閉じるために従う手順について説明します。このプロセスに続いて、SNMPエンジンがSSHセッションを終了します。セッションを閉じる場合、実装依存です。呼び出しコードは、関連するtmStateReferenceをリリースする必要があります。
1. Increment the snmpSshtmSessionCloses counter.
1. snmpsshtmssessionclosesカウンターをインクリメントします。
2. If there is no session corresponding to tmSessionID, then closeSession processing is complete.
2. TMESSESSIONIDに対応するセッションがない場合、閉鎖処理が完了します。
3. Have SSH close the session associated with tmSessionID.
3. SSHにTMSESSIONIDに関連付けられたセッションを閉じてもらいます。
This MIB module provides management of the Secure Shell Transport Model. It defines an OID to identify the SNMP-over-SSH transport domain, a Textual Convention for SSH Addresses, and several statistics counters.
このMIBモジュールは、安全なシェル輸送モデルの管理を提供します。SNMPオーバーSSHトランスポートドメイン、SSHアドレスのテキスト条約、およびいくつかの統計カウンターを特定するOIDを定義します。
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 document can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html
このドキュメントで使用される一般的で一般的なテキストの規則は、http：//www.ops.ietf.org/mib-common-tcs.htmlにまとめられています。
Some management objects defined in other MIB modules are applicable to an entity implementing the SSH Transport Model. In particular, it is assumed that an entity implementing the SNMP-SSH-TM-MIB will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK-MIB [RFC3411]. It is expected that an entity implementing this MIB will also support the Transport Security Model [RFC5591] and, therefore, implement the SNMP-TSM-MIB.
他のMIBモジュールで定義されている一部の管理オブジェクトは、SSH輸送モデルを実装するエンティティに適用できます。特に、SNMP-SSH-TM-MIBを実装するエンティティがSNMPV2-MIB [RFC3418]とSNMP-Framework-MIB [RFC3411]を実装すると想定されています。このMIBを実装するエンティティは、輸送セキュリティモデル[RFC5591]もサポートし、したがってSNMP-TSM-MIBを実装することが期待されています。
This MIB module is for monitoring SSH Transport Model information.
このMIBモジュールは、SSH輸送モデル情報を監視するためのものです。
The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580].
次のMIBモジュールは、[RFC2578]、[RFC2579]、および[RFC2580]からアイテムをインポートします。
This MIB module also references [RFC1033], [RFC4252], [RFC3490], and [RFC3986].
このMIBモジュールは、[RFC1033]、[RFC4252]、[RFC3490]、および[RFC3986]も参照しています。
This document uses TDomain Textual Conventions for the SNMP-internal MIB modules defined here for compatibility with the RFC 3413 MIB modules and the RFC 3411 Abstract Service Interfaces.
このドキュメントでは、RFC 3413 MIBモジュールとRFC 3411抽象サービスインターフェイスとの互換性について、ここで定義されているSNMP内部MIBモジュールのテキストコンベンションを使用します。
SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, snmpDomains, Counter32 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 ;
インポートモジュールアイデンティティ、オブジェクトタイプ、オブジェクトアイデンティティ、MIB-2、SNMPDomains、SNMPV2-SMIからのCounter32-RFC 2578 SNMPV2-TCからのテキストコンベンション-RFC 2579モジュールコンプライアンス、SNMPV2-CONFからオブジェクトグループ-RFC 2580;
snmpSshtmMIB MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org
snmpsshtmmibモジュールのアイデンティティ最後の「2009060900z」組織「ISMSワーキンググループ」ワーキンググループ「連絡先」wg-email：isms@lists.ietf.org subscribe：isms-request@lists.ietf.org
Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de
椅子：Juergen Quittek Nec Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany 49 6221 90511-15 quittek@netlab.nec.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany 49 421 200-3587 j.schoenwaelder@jacobs-university.de
Co-editors: David Harrington Huawei Technologies USA 1700 Alma Drive Plano Texas 75075 USA +1 603-436-8634 ietfdbh@comcast.net
共同編集者：David Harrington Huawei Technologies USA 1700 Alma Drive Plano Texas 75075 USA 1 603-436-8634 ietfdbh@comcast.net
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle、WA 98121 USA jsalowey@cisco.com
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 USA +1 530 792 1913 ietf@hardakers.net " DESCRIPTION "The Secure Shell Transport Model MIB.
Wes Hardaker Cobham Analytic Solutions P.O.Box 382 Davis、CA 95617 USA 1 530 792 1913 ietf@hardakers.net "説明"安全なシェル輸送モデルMIB。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
変更とバイナリ形式での再配布と使用は、変更を伴うまたは伴わない場合、次の条件が満たされている場合が許可されています。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布は、上記の著作権通知、この条件リスト、および次の免責事項を保持する必要があります。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式の再配布は、上記の著作権通知、この条件のリスト、および分布に提供されたドキュメントおよび/またはその他の資料の次の免責事項を再現する必要があります。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- インターネット社会、IETFまたはIETFトラストの名前も、特定の貢献者の名前も、特定の事前の書面による許可なしにこのソフトウェアから派生した製品を支持または宣伝するために使用することはできません。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
このソフトウェアは、著作権所有者と貢献者が「現状のまま」と、特定の目的に対する黙示の保証と黙示的または黙示的な保証が提供されますが、これらに限定されない保証が提供されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
This version of this MIB module is part of RFC 5592; see the RFC itself for full legal notices."
このMIBモジュールのこのバージョンは、RFC 5592の一部です。完全な法的通知については、RFC自体を参照してください。」
REVISION "200906090000Z" DESCRIPTION "The initial version, published in RFC 5592."
リビジョン「200906090000Z」説明「RFC 5592で公開されている初期バージョン。」
::= { mib-2 189 }
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-SSH-TM-MIB
-- ---------------------------------------------------------- --
snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 }
snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 }
snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
snmpSSHDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP-over-SSH transport domain. The corresponding transport address is of type SnmpSSHAddress.
snmpsshdomainオブジェクトアイデンティティステータス現在の説明 "Snmp-over-sshトランスポートドメイン。対応する輸送アドレスは、snmpsshaddressのタイプです。
When an SNMP entity uses the snmpSSHDomain Transport Model, it must be capable of accepting messages up to and including 8192 octets in size. Implementation of larger values is encouraged whenever possible.
SNMPエンティティがSNMPSSHDomainトランスポートモデルを使用する場合、サイズが8192オクテットまでメッセージを受け入れることができなければなりません。可能な限り、より大きな値の実装が奨励されます。
The securityName prefix to be associated with the
snmpSSHDomain is 'ssh'. This prefix may be used by Security
Models or other components to identify which secure transport
infrastructure authenticated a securityName."
::= { snmpDomains 7 }
SnmpSSHAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents either a hostname or IP address, along with a port
number and an optional user name.
The beginning of the address specification may contain a user name followed by an '@' (US-ASCII character 0x40). This portion of the address will indicate the user name that should be used when authenticating to an SSH server. The user name must be encoded in UTF-8 (per [RFC4252]). If missing, the SNMP securityName should be used. After the optional user name field and '@' character comes the hostname or IP address.
アドレス仕様の開始には、ユーザー名が含まれていて、その後に「@」（US-ASCII文字0x40）が含まれます。アドレスのこの部分は、SSHサーバーを認証するときに使用する必要があるユーザー名を示します。ユーザー名はUTF-8（[RFC4252]ごとに）でエンコードする必要があります。欠落している場合は、SNMP SecurityNameを使用する必要があります。オプションのユーザー名フィールドと「@」文字がホスト名またはIPアドレスに登場します。
The hostname is always in US-ASCII (as per RFC1033); internationalized hostnames are encoded in US-ASCII as specified in RFC 3490. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible.
ホスト名は常にUS-ASCII（RFC1033に従って）です。国際化されたホスト名は、RFC 3490で指定されているUS-ASCIIでエンコードされています。ホスト名の後には、コロン '：'（US-ASCII文字0x3a）およびUS-ASCIIの小数ポート番号が続きます。名前は、可能な限り完全に資格を付ける必要があります。
An IPv4 address must be in dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII.
IPv4アドレスは、コロン '（us-ascii文字0x3a）とus-asciiの小数ポート番号が続く点線の小数形式である必要があります。
An IPv6 address must be in colon-separated format, surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII.
IPv6アドレスは、正方形の括弧（ '['、us-ascii文字0x5b、 ']、us-ascii文字0x5d）に囲まれたコロン分離形式でなければなりません。0x3a）およびus-asciiの小数ポート番号。
Values of this Textual Convention might not be directly usable as transport-layer addressing information and may require runtime 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 snmpSSHAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa.
SNMPSShaddressの値を持つ可能性のある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, which is 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 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE RFC 3490: Internationalizing Domain Names in Applications RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 4252: The Secure Shell (SSH) Authentication Protocol" SYNTAX OCTET STRING (SIZE (1..255))
このテキスト規則がインデックスオブジェクトの構文として使用される場合、SMIV2（STD 58）で指定されている128のサブ識別子の制限に問題がある可能性があります。このテキスト条約を使用して、すべてのMIBドキュメントは、管理ソフトウェアが観察しなければならないインデックスコンポーネントの長さに関する制限を明示的にすることをお勧めします。これは、インデックスコンポーネントにサイズの制約を含めるか、概念的行の説明条項または周囲のドキュメントに該当する制約を指定することによって行われます。"Reference" RFC 1033：ドメイン管理者操作ガイドRFC 3490：アプリケーションの国際化ドメイン名RFC 3986：ユニフォームリソース識別子（URI）：ジェネリック構文RFC 4252：セキュアシェル（SSH）認証プロトコル "Syntax Octet String（1。.255））
-- The snmpSshtmSession Group
- snmpsshtmssessionグループ
snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 }
snmpSshtmSessionOpens OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 1 }
snmpSshtmSessionCloses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times a closeSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 2 }
snmpSshtmSessionOpenErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a transport connection or failed to
authenticate the server.
"
::= { snmpSshtmSession 3 }
snmpSshtmSessionUserAuthFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
user-authentication failures.
"
::= { snmpSshtmSession 4 }
snmpSshtmSessionNoChannels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
channel-open failures.
"
::= { snmpSshtmSession 5 }
snmpSshtmSessionNoSubsystems OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
inability to connect to the requested subsystem.
"
::= { snmpSshtmSession 6 }
snmpSshtmSessionNoSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an outgoing message was
dropped because the same session was no longer
available.
"
::= { snmpSshtmSession 7 }
snmpSshtmSessionInvalidCaches 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.
"
::= { snmpSshtmSession 8 }
-- ************************************************
-- snmpSshtmMIB - Conformance Information
-- ************************************************
snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 }
snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 }
-- ************************************************
-- Compliance statements
-- ************************************************
snmpSshtmCompliance MODULE-COMPLIANCE STATUS current
snmpsshtmcomplianceモジュールコンプライアンスステータス電流
DESCRIPTION "The compliance statement for SNMP engines that
support the SNMP-SSH-TM-MIB."
MODULE
MANDATORY-GROUPS { snmpSshtmGroup }
::= { snmpSshtmCompliances 1 }
-- ************************************************
-- Units of conformance
-- ************************************************
snmpSshtmGroup OBJECT-GROUP
OBJECTS {
snmpSshtmSessionOpens,
snmpSshtmSessionCloses,
snmpSshtmSessionOpenErrors,
snmpSshtmSessionUserAuthFailures,
snmpSshtmSessionNoChannels,
snmpSshtmSessionNoSubsystems,
snmpSshtmSessionNoSessions,
snmpSshtmSessionInvalidCaches
}
STATUS current
DESCRIPTION "A collection of objects for maintaining information
of an SNMP engine that implements the SNMP Secure
Shell Transport Model.
"
::= { snmpSshtmGroups 2 }
END
終わり
The SSH Transport Model will likely not work in conditions where remote access to the CLI has stopped working. The SSH Transport Model assumes that TCP and IP continue to operate correctly between the communicating nodes. Failures in either node, death of the deamon serving the communication, routing problems in the network between, firewalls that block the traffic, and other problems can prevent the SSH Transport Model from working. In situations where management access has to be very reliable, operators should consider mitigating measures. These measures may include dedicated management-only networks, point-to-point links, and the ability to use alternate protocols and transports.
SSH輸送モデルは、CLIへのリモートアクセスが機能しなくなった条件では機能しない可能性があります。SSH輸送モデルは、TCPとIPが通信ノード間で正しく動作し続けることを想定しています。いずれかのノードの障害、コミュニケーションにサービスを提供するディーモンの死、ネットワークのルーティングの問題、トラフィックをブロックするファイアウォール、およびその他の問題は、SSH輸送モデルの動作を防ぐことができます。管理アクセスが非常に信頼できる状況では、オペレーターは測定の緩和を検討する必要があります。これらの手段には、専用の管理専用ネットワーク、ポイントツーポイントリンク、および代替プロトコルとトランスポートを使用する機能が含まれます。
To have SNMP properly utilize the security services provided by SSH, the SSH Transport Model MUST be used with a Security Model that knows how to process a tmStateReference, such as the Transport Security Model for SNMP [RFC5591].
SNMPがSSHが提供するセキュリティサービスを適切に利用できるようにするには、SSH輸送モデルを、SNMPの輸送セキュリティモデルなどのTMSTATEREFFERECEを処理する方法を知っているセキュリティモデルで使用する必要があります[RFC5591]。
If the SSH Transport Model is configured to utilize AAA services, operators should consider configuring support for local authentication mechanisms, such as local passwords, so SNMP can continue operating during times of network stress.
SSHトランスポートモデルがAAAサービスを利用するように構成されている場合、オペレーターはローカルパスワードなどのローカル認証メカニズムのサポートの構成を検討する必要があります。そうすれば、SNMPはネットワークストレスの時代に動作を続けることができます。
The SSH protocol has its own window mechanism, defined in RFC 4254. The SSH specifications leave it open when window adjustment messages should be created, and some implementations send these whenever received data has been passed to the application. There are noticeable bandwidth and processing overheads to handling such window adjustment messages, which can be avoided by sending them less frequently.
SSHプロトコルには、RFC 4254で定義された独自のウィンドウメカニズムがあります。SSH仕様は、ウィンドウ調整メッセージを作成する必要がある場合に開いたままにし、受信したデータがアプリケーションに渡されるたびにこれらを送信します。このようなウィンドウ調整メッセージの処理には顕著な帯域幅と処理オーバーヘッドがあります。これは、頻繁に送信することで回避できます。
The SSH protocol requires the execution of CPU-intensive calculations to establish a session key during session establishment. This means that short-lived sessions become computationally expensive compared to USM, which does not have a notion of a session key. Other transport security protocols such as TLS support a session-resumption feature that allows reusing a cached session key. Such a mechanism does not exist for SSH and thus SNMP applications should keep SSH sessions for longer time periods.
SSHプロトコルでは、セッションの確立中にセッションキーを確立するために、CPU集約型計算の実行が必要です。これは、短命のセッションがUSMに比べて計算上高価になることを意味します。これには、セッションキーの概念がありません。TLSなどのその他の輸送セキュリティプロトコルは、キャッシュされたセッションキーを再利用できるセッション再開機能をサポートしています。このようなメカニズムはSSHには存在しないため、SNMPアプリケーションはSSHセッションをより長い期間維持する必要があります。
To initiate SSH connections, an entity must be configured with SSH client credentials plus information to authenticate the server. While hosts are often configured to be SSH clients, most internetworking devices are not. To send notifications over SSHTM, the internetworking device will need to be configured as an SSH client. How this credential configuration is done is implementation-and deployment-specific.
SSH接続を開始するには、エンティティをSSHクライアント資格情報と情報で構成してサーバーを認証する必要があります。ホストは多くの場合、SSHクライアントとして構成されていますが、ほとんどのインターネットワークデバイスはそうではありません。SSHTMを介して通知を送信するには、インターネットワーキングデバイスをSSHクライアントとして構成する必要があります。この資格設定の実行方法は、実装と展開固有です。
This memo describes a Transport Model that permits SNMP to utilize SSH security services. The security threats and how the SSH Transport Model mitigates those threats is covered in detail throughout this memo.
このメモは、SNMPがSSHセキュリティサービスを利用できるようにするトランスポートモデルについて説明しています。セキュリティの脅威とSSH輸送モデルがこれらの脅威をどのように軽減するかは、このメモ全体で詳細にカバーされています。
The SSH Transport Model relies on SSH mutual authentication, binding of keys, confidentiality, and integrity. Any authentication method that meets the requirements of the SSH architecture will provide the properties of mutual authentication and binding of keys.
SSH輸送モデルは、SSH相互認証、キーの拘束力、機密性、および完全性に依存しています。SSHアーキテクチャの要件を満たす認証方法は、キーの相互認証と結合の特性を提供します。
SSHv2 provides perfect forward secrecy (PFS) for encryption keys. PFS is a major design goal of SSH, and any well-designed key-exchange algorithm will provide it.
SSHV2は、暗号化キーに完全な前方秘密（PFS）を提供します。PFSはSSHの主要な設計目標であり、適切に設計されたキー交換アルゴリズムはそれを提供します。
The security implications of using SSH are covered in [RFC4251].
SSHを使用することのセキュリティへの影響は、[RFC4251]でカバーされています。
The SSH Transport Model has no way to verify that server authentication was performed, to learn the host's public key in advance, or to verify that the correct key is being used. The SSH Transport Model simply trusts that these are properly configured by the implementer and deployer.
SSHトランスポートモデルには、サーバー認証が実行されたことを確認したり、ホストの公開キーを事前に学習したり、正しいキーが使用されていることを確認する方法がありません。SSH輸送モデルは、これらが実装者と展開者によって適切に構成されていることを単に信頼しています。
SSH provides the "none" userauth method. The SSH Transport Model MUST NOT be used with an SSH connection with the "none" userauth method. While SSH does support turning off confidentiality and integrity, they MUST NOT be turned off when used with the SSH Transport Model.
SSHは「none」userauthメソッドを提供します。SSHトランスポートモデルは、「なし」ユーザーAuthメソッドとのSSH接続で使用してはなりません。SSHは機密性と整合性の電源を切ることをサポートしていますが、SSH輸送モデルで使用した場合はオフにしてはなりません。
The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform an SSH identity to a tmSecurityName or to transform a tmSecurityName to an SSH identity.
SSHプロトコルは、ユーザー名フィールドを入力する必要があるかどうかについて必ずしも明確ではないため、GSSAPI認証を使用しているようないくつかの実装では、マッピングアルゴリズムを使用してSSH IDをTMESECURTYNAMEに変換するか、変換する必要がある場合があります。SSH IDへのtmsecurityName。
In other cases, the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange.
他の場合には、ユーザー名がサーバーによって検証されない場合があるため、これらの実装では、SSH交換中に交換された他の資格情報からユーザー名を取得する必要がある場合があります。
Most key-exchange algorithms are able to authenticate the SSH server's identity to the client. However, for the common case of Diffie-Hellman (DH) signed by public keys, this requires the client to know the host's public key a priori and to verify that the correct key is being used. If this step is skipped, then authentication of the SSH server to the SSH client is not done. Data confidentiality and data integrity protection to the server still exist, but these are of dubious value when an attacker can insert himself between the client and the real SSH server. Note that some userauth methods may defend against this situation, but many of the common ones (including password and keyboard-interactive) do not and, in fact, depend on the fact that the server's identity has been verified (so passwords are not disclosed to an attacker).
ほとんどのキー交換アルゴリズムは、SSHサーバーのIDをクライアントに認証できます。ただし、パブリックキーで署名されたDiffie-Hellman（DH）の一般的なケースの場合、これにより、クライアントはホストの公開キーを先験的に知り、正しいキーが使用されていることを確認する必要があります。このステップがスキップされている場合、SSHサーバーのSSHクライアントへの認証は行われません。サーバーへのデータの機密性とデータの整合性保護はまだ存在しますが、攻撃者がクライアントと実際のSSHサーバーの間に自分自身を挿入できる場合、これらは疑わしい価値があります。一部のuserauthメソッドはこの状況から防御する可能性がありますが、一般的な方法の多く（パスワードとキーボードインタラクティブを含む）はそうではなく、実際、サーバーのIDが検証されているという事実に依存しています（パスワードはに開示されていません攻撃者）。
SSH MUST NOT be configured to skip public-key verification for use with the SSH Transport Model.
SSHは、SSH輸送モデルで使用するためにパブリックキー検証をスキップするように構成してはなりません。
SNMP Notifications are authorized to be sent to a receiver based on the securityName used by the notification originator's SNMP engine. This authorization is performed before the message is actually sent and before the credentials of the remote receiver have been verified. Thus, the credentials presented by a notification receiver MUST match the expected value(s) for a given transport address, and ownership of the credentials MUST be properly cryptographically verified.
SNMP通知は、通知オリジネーターのSNMPエンジンで使用されているセキュリティ名に基づいて、受信機に送信されることが許可されています。この承認は、メッセージが実際に送信される前およびリモートレシーバーの資格情報が検証される前に実行されます。したがって、通知レシーバーによって提示された資格情報は、特定の輸送アドレスの期待値と一致する必要があり、資格情報の所有権は適切に暗号化されている必要があります。
If a "user@" prefix is used within an SnmpSSHAddress value to specify an SSH user name to use for authentication, then the key presented to the remote entity MUST be the key expected by the server for the "user". This may be different than a locally cached key identified by the securityName value.
「ユーザー@」プレフィックスがSNMPSSHADDRESS値内で使用され、認証に使用するSSHユーザー名を指定する場合、リモートエンティティに提示されたキーが「ユーザー」にサーバーが期待するキーでなければなりません。これは、SecurityName値によって識別されるローカルにキャッシュされたキーとは異なる場合があります。
The User-based Security Model [RFC3414] employed symmetric cryptography and user-naming conventions. SSH employs an asymmetric cryptography and naming model. Unlike USM, cryptographic keys will be different on both sides of the SSH connection. Both sides are responsible for verifying that the remote entity presents the right key. The optional "user@" prefix component of the SnmpSSHAddress Textual Convention allows the client SNMP stack to associate the connection with a securityName that may be different than the SSH user name presented to the SSH server.
ユーザーベースのセキュリティモデル[RFC3414]は、対称的な暗号化とユーザーネーミングコンベンションを採用しました。SSHは、非対称の暗号化モデルと命名モデルを採用しています。USMとは異なり、暗号化キーはSSH接続の両側で異なります。双方は、リモートエンティティが正しいキーを提示することを確認する責任があります。SNMPSSHADDRESSテキストコンベンションのオプションの「user@」プレフィックスコンポーネントにより、クライアントSNMPスタックは、SSHサーバーに提示されたSSHユーザー名とは異なる可能性のあるセキュリティ名と接続を関連付けることができます。
SSH provides the "none" Message Authentication Code (MAC) algorithm, which would allow you to turn off data integrity while maintaining confidentiality. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication.
SSHは、「なし」メッセージ認証コード（MAC）アルゴリズムを提供します。これにより、機密性を維持しながらデータの整合性をオフにすることができます。ただし、これを行うと、攻撃者は飛行中のデータを変更できる場合があります。つまり、効果的に認証がないことを意味します。
SSH MUST NOT be configured using the "none" MAC algorithm for use with the SSH Transport Model.
SSH輸送モデルで使用するために、「なし」MACアルゴリズムを使用してSSHを構成してはなりません。
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 SSH Transport Model.
[RFC3584]（BCP 74）で説明されているSNMPV1およびSNMPV2Cメッセージ処理は、常にSNMPV1またはSNMPV2Cセキュリティモデルをそれぞれ選択します。これらとユーザーベースのセキュリティモデルの両方が、通常、SNMPV3で使用されているセキュリティモデルは、受信したSNMPメッセージからSecurityNameとSecurityLevelを導き出します。したがって、アクセス制御の決定は、SSH輸送モデルによって提供される認証されたIDとセキュリティレベルを使用するのではなく、SNMPメッセージの内容に基づいて行われます。
There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations.
このMIBモジュールには、読み取りワイトおよび/またはread-Createの最大アクセス句を持つ管理オブジェクトはありません。したがって、このMIBモジュールが正しく実装されている場合、侵入者が直接SNMPセット操作を介してこのMIBモジュールの管理オブジェクトを変更または作成できるリスクはありません。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュールの読み取り可能なオブジェクトのいくつか（つまり、アクセスできないこと以外に最大アクセスを備えたオブジェクト）は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのオブジェクトへのアクセスを取得および/または通知することさえ制御し、SNMPを介してネットワーク上に送信するときにこれらのオブジェクトの値を暗号化することも重要です。これらはテーブルとオブジェクトであり、その感度/脆弱性です。
o The information in the snmpSshtmSession group is generated locally when a client session is being opened or closed. This information can reflect the configured capabilities of a remote SSH server, which could be helpful to an attacker for focusing an attack.
o SNMPSSHTMSESSIONグループの情報は、クライアントセッションが開設または閉じられているときにローカルで生成されます。この情報は、リモートSSHサーバーの構成された機能を反映しています。これは、攻撃者が攻撃を集中するために役立つ可能性があります。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec or SSH), 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またはSSHを使用して）安全である場合でも、それでもセキュアネットワークで誰がアクセスして取得/セット（読み取り/変更/作成/削除/削除）を制御できません。このMIBモジュールで。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for cryptographic mechanisms for authentication and privacy, such as those found in the User-based Security Model [RFC3414], the Transport Security Model [RFC5591], and the SSH Transport Model described in this document.
実装者は、ユーザーベースのセキュリティモデル[RFC3414]で見つかったものなど、認証とプライバシーの暗号化メカニズムの完全なサポートを含む、SNMPV3フレームワーク（[RFC3410]、セクション8を参照）で提供されるセキュリティ機能を考慮することをお勧めします。、輸送セキュリティモデル[RFC5591]、およびこのドキュメントで説明されているSSH輸送モデル。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPV3より前のSNMPバージョンの展開は推奨されません。代わりに、SNMPV3を展開し、暗号化セキュリティを有効にすることをお勧めします。その場合、このMIBモジュールのインスタンスへのアクセスを提供するSNMPエンティティが、実際に取得または設定する正当な権利を持つプリンシパル（ユーザー）にのみオブジェクトにアクセスできるように適切に構成されていることを保証するのは、顧客/オペレーターの責任です（変更を変更します（変更）/作成/削除）それら。
IANA has assigned:
IANAが割り当てました：
1. Two TCP port numbers in the Port Numbers registry that will be the default ports for the SNMP-over-SSH Transport Model as defined in this document, and the SNMP-over-SSH Transport Model for notifications as defined in this document. The assigned keywords and port numbers are "snmpssh" (5161) and "snmpssh-trap" (5162).
1. このドキュメントで定義されているSNMPオーバーSSH輸送モデルのデフォルトポートと、このドキュメントで定義されている通知のSNMPオーバーSSHトランスポートモデルとなるポート番号レジストリの2つのTCPポート番号。割り当てられたキーワードとポート番号は、「snmpssh」（5161）と「snmpssh-trap」（5162）です。
2. An SMI number (189) under mib-2, for the MIB module in this document.
2. このドキュメントのMIBモジュールのMIB-2の下のSMI番号（189）。
3. An SMI number (7) under snmpDomains, for the snmpSSHDomain.
3. snmpsshdomainのsnmpdomainsの下のSMI番号（7）。
4. "ssh" as the corresponding prefix for the snmpSSHDomain in the SNMP Transport Domains registry; defined in [RFC5590].
4. SNMPトランスポートドメインレジストリのSNMPSSHDomainの対応するプレフィックスとしての「SSH」。[RFC5590]で定義されています。
5. "snmp" as a Connection Protocol Subsystem Name in the SSH Protocol Parameters registry.
5. SSHプロトコルパラメーターレジストリの接続プロトコルサブシステム名としての「SNMP」。
The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights, and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity.
編集者は、SSHの洞察を共有してくれたJeffrey Hutzelmanに感謝し、Dave Shieldが既存のドキュメントを単語に委ねて組織と明確さを改善してくれたことに感謝します。
Additionally, helpful document reviews were received from Juergen Schoenwaelder.
さらに、Juergen Schoenwaelderから有用なドキュメントレビューが受け取られました。
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987.
[RFC1033] Lottor、M。、「ドメイン管理者オペレーションガイド」、RFC 1033、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「Smiv2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2の適合ステートメント」、STD 58、RFC 2580、1999年4月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413] Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（SNMP）アプリケーション」、STD 62、RFC 3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414] Blumenthal、U.およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R。、「単純なネットワーク管理プロトコル（SNMP）の管理情報基盤（MIB）」、STD 62、RFC 3418、2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584] Frye、R.、Levi、D.、Routhier、S。、およびB. Wijnen、「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存」、BCP 74、RFC 3584、2003年8月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）認証プロトコル」、RFC 4252、2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）輸送層プロトコル」、RFC 4253、2006年1月。
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[RFC4254] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）接続プロトコル」、RFC 4254、2006年1月。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590] Harrington、D。およびJ. Schoenwaelder、「Simple Network Management Protocol（SNMP）の輸送サブシステム」、RFC 5590、2009年6月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4256] Cusack, F. and M. Forssen, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", RFC 4256, January 2006.
[RFC4256] Cusack、F。およびM. Forssen、「Secure Shell Protocol（SSH）の一般的なメッセージ交換認証」、RFC 4256、2006年1月。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4462] Hutzelman、J.、Salowey、J.、Galbraith、J.、およびV. Welch、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）認証とセキュアシェル（SSH）プロトコルの主要な交換」、RFC4462、2006年5月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742] Wasserman、M。およびT. Goddard、「Secure Shell（SSH）を介したNetConf構成プロトコルを使用」、RFC 4742、2006年12月。
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008.
[RFC5090] Sterman、B.、Sadolevsky、D.、Schwartz、D.、Williams、D.、およびW. Beck、「Digest Authentication for Digest Authentication for Digest Extension」、RFC 5090、2008年2月。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591] Harrington、D。およびW. Hardaker、「Simple Network Management Protocol（SNMP）の輸送セキュリティモデル」、RFC 5591、2009年6月。
Authors' Addresses
著者のアドレス
David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
David Harrington Huawei Technologies（USA）1700 Alma Dr. Suite 100 Plano、TX 75075 USA
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA
ジョセフ・サロウィ・シスコ・システム2901 3番目のアベニュー・シアトル、ワシントン州98121 USA
EMail: jsalowey@cisco.com
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US
Wes Hardaker Cobham Analytic Solutions P.O.Box 382 Davis、CA 95617 US
Phone: +1 530 792 1913
EMail: ietf@hardakers.net