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)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.
このメモは、セキュアシェル（SSH）プロトコルを使用して、簡易ネットワーク管理プロトコル（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のためのSecure Shell輸送モデルを監視し、管理するためにオブジェクトを定義します。
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]を使用して、簡易ネットワーク管理プロトコルのための輸送モデルを説明しています。このメモで指定された輸送モデルは、セキュアシェル輸送モデル（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のためのSecure Shell輸送モデルを監視し、管理するためにオブジェクトを定義します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Lowercase versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context that relates to compatibility with the RFC 3411 architecture or the subsystem defined here but that might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage.
キーワードの小文字バージョンは、通常、英語のように読まれるべきです。彼らは通常、常にではないが、RFC 3411のアーキテクチャや、ここで定義されたサブシステムとの互換性のためにそれがオン・ワイヤーの互換性に影響を与えないかもしれない関係のコンテキストで使用されます。これらの用語は、RFC 3411個のサブシステムと抽象サービスインターフェイス（ASIを）とデザインが両立させるために提案されているIETFモデルのデザイナーのための指針として使用されています。実装者は、異なる自由に実装できます。これらの小文字の用語のいくつかの用途は、単に通常の英語の使用状況です。
For consistency with SNMP-related specifications, this document favors terminology as defined in STD 62, rather than favoring terminology that is consistent with non-SNMP specifications. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard.
むしろ非SNMPの仕様と一致している用語を好むよりも、STD 62で定義されているSNMP関連の仕様との整合性については、このドキュメントには、専門用語を好みます。これは、SNMPv3のは、全規格に進められたときのSNMPv3の用語は、他の非SNMP仕様の使用を一致するように変更する必要がないためにIESGの決定と一致しています。
"Authentication" in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication.
このドキュメントの「認証」は、典型的にはメッセージではなく、データソース認証またはピアのアイデンティティ認証「の信憑性を証明するのに役立つ」の英語の意味を指します。
The terms "manager" and "agent" are not used in this document because, in the RFC 3411 architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP 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.
RFC 3411のアーキテクチャでは、すべての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] SSHおよびUSM仕様はしばしばユーザを参照しながらSTD 62に強制的に実装セキュリティモデルである、[RFC3411]にし、このメモで好ましい用語が "主要な"。校長は、「誰が」その代理としてサービスを提供しているか、処理には行われています。校長は、とりわけ、特定のロール内の個々の演技、それぞれ特定の役割は、アプリケーションまたはアプリケーションのセット、または管理ドメイン内のこれらの組み合わせで働く個人の集合とすることができます。
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アーキテクチャの説明を理解していると予想され、[RFC5590]「簡易ネットワーク管理プロトコル（SNMP）のための輸送サブシステム」に指定されたトランスポート・サブシステム・アーキテクチャの拡張機能。
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のためのSecure Shell輸送モデル、特定の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のためのSecure Shell輸送モデルを処理するために必要な関連する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.
簡易ネットワーク管理プロトコル（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輸送モデルは、「公開」、「パスワード」、「ホストベース」、「なし」、「キーボードインタラクティブ」、「GSSAPI-と-MIC」を含むSSH-USERAUTH方法、のいずれかで動作するはずです。」GSSAPI -keyex」、 『GSSAPI』、および 『外部keyx』（IANAによって維持SSHプロトコル・パラメータのレジストリを参照してください）。このドキュメントのセキュリティの考慮事項で説明したように「なし」の認証方式の使用は、推奨されません。ローカルアカウントは、公開鍵、ホストベース、またはパスワードの方法の使用を介してサポートすることができます。パスワード方式は、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）の管理、セキュリティ、および他の管理インターフェイスのためのアプローチを統一する可能性のメカニズムを使用することが望ましいです。セキュアシェルによって提供されるセキュリティサービスの使用は、一般的にCLIのために使用されるアプローチであり、NETCONF [RFC4742]で使用するために採用されるアプローチです。このメモはSSHサブシステムとしてセキュアシェル（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.
このメモはSNMPはSSHトランスポートプロトコルを介してSSH接続プロトコル[RFC4254]を使用して、認証のためにSSH-USERAUTH [RFC4252]を使用して、セキュアシェル（SSH）セッション内で使用することができる方法について説明します。
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. A輸送モデルは、SNMPアーキテクチャへの変更を要求すべきではありません。
5. A Transport Model SHOULD NOT require changes to the underlying security protocol.
5. A輸送モデルは、基本的なセキュリティプロトコルへの変更を要求すべきではありません。
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「ジェネリックセキュリティーサービス適用業務プログラムインタフェース（GSS-API）の認証とセキュアシェル（SSH）プロトコルのための鍵交換」[RFC4462]は、認証およびSSHでの鍵交換のためのGSS-APIを使用する方法を説明しています。これは、ユーザを認証するために、指定されたGSS-API機構を使用してSSHユーザ認証方法を定義します。それはまたのDiffie-Hellman鍵交換を認証するためにGSS-APIを使用して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にディスパッチャから暗号化されていないメッセージを渡し、受信輸送モデルは、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メッセージDispatcherに1 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.マスカレード - SSHは、SSHサーバおよびSSHクライアントのアイデンティティの身元の確認のために用意されています。
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 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クライアント側プリンシパルのアイデンティティを検証するための多くのメカニズムを提供します。これらは、公開鍵、パスワード、およびホストベースのメカニズムが含まれます。これが唯一認可プリンシパルが潜在的に機密データへのアクセス権を持っていることを確認するために、SNMPのアクセス制御サブシステムを可能にします。
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のユーザー識別情報は輸送モデルに提供されるので、SNMPのアクセス制御および通知の設定で使用するためのSNMPモデルに依存しないセキュリティ名にマップするために使用することができます。 （それはセキュリティ名にマップする前に、アイデンティティは、さまざまな変換を受けることがあります。）
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から認証されたプリンシパル、着信メッセージに関連付けられたタイプおよびアドレスの識別を決定し、送信メッセージのためのSSHにこの情報を提供します。認証、データの整合性、および暗号化を提供するために使用されるSSHトランスポート層のアルゴリズムは、SSH輸送モデル層にさらされるべきではありません。 SNMPv3のWGは、故意にこれを回避してたsecurityLevelの要件が満たされたセキュリティモデルによってアサーションのために定住します。 SSHトランスポートモデルは、基礎となるSSH接続はAUTHまたは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トランスポートモデルに準拠した実装は、SNMPセキュリティ（authPrivの）の最高レベルを満たし、認証、データの整合性、および暗号化を提供してSSH接続を使用する必要があります。 noAuthNoPrivというかauthNoPrivのたsecurityLevelで指定された送信メッセージは、実際にはauthPrivのレベルの保護とSSH輸送モデルによって送信されます。
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でサポートされている任意のサーバ - またはクライアントの認証メカニズムをサポートする必要があります。これは、3つの認証SSH認証プロトコルドキュメント[RFC4252]（公開鍵、パスワード、およびホストベース）に記載された方法、キーボード対話などを含みます。
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]のように異なるパスワード検証プロトコルを使用するか、RADIUSまたはDIAMETERと統合するための認証[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の使用量が別個にするためにSNMPのためのSSHサブシステムの使用を記載しています。
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クライアント・ソフトウェア・パッケージは、ユーザ@ホスト名をサポートしています。ポートは、オペレータが非同等のアカウント名を揃えるために使用できる構文に取り組みます。 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ユーザ名で確立されなければなりません。ユーザ名は、（[RFC4252]あたり）UTF-8でエンコードされなければなりません。 「ユーザー」の部分は、またはセキュリティモデルから渡されたtmSecurityNameパラメータと一致しない場合があります。ない「ユーザー@」部分をSnmpSSHAddressに指定されていない場合、SSH接続は、リモートSSHサーバーとのセッションを確立するときにSSHのユーザー名としてtmSecurityNameを使用して確立されなければなりません。
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値個々の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によって参照キャッシュで、認証された識別を含む輸送関連およびSSH-セキュリティ関連情報を、記録し、receiveMessageを（使用してDispatcherにWholeMsgとtmStateReferenceを渡します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でDispatcherによって提供される入力をとります。 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接続は、コマンド発生器によってまたは通知オリジネーターによって開始することができます。コマンド・ジェネレータは、しばしば人間によって運営されているが、通知の発信者は、通常の無人自動化プロセスです。エンジンが正常に通知受信機を含むエンジンに認証できるようにその結果、通知の発信またはKerberosなどのサードパーティのキープロバイダを使用することを含むSNMPエンジンのプロビジョニング認証証明書に必要であってもよいです。
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輸送モデルの場合は、トランスポート・タイプとアドレスがsnmpTargetAddrTableのように構成されており、セキュリティ名およびたsecurityLevelパラメータがたsnmpTargetParamsTableで設定されています。管理者が静的に通知または受信プロキシメッセージを受信することを許可標的を同定するためにこの情報を事前設定するためのデフォルトのアプローチがあります。ローカルaccess-制御処理は、通知が実際に送信される前に通知創始者によって実行される必要があり、この処理は、設定されセキュリティ名を使用して行われます。これの重要な特徴は、承認前の接続が成功するかどうかを判断するために行われていることです。このように、ローカルに設定されたセキュリティ名は完全に通知創始者の中に信頼されています。
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はtmSecurityNameがSSHTMセッションを通過するすべてのトラフィックに対して一定でなければならない第5の手順に従って設定されたIDを表す（れるSnmpAdminString形式）人間可読な名前でなければなりません。メッセージは異なる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.
このようGSSAPI認証を使用したものなどいくつかの実装のために、tmSecurityNameにSSHのアイデンティティを変換したり、変換するマッピングアルゴリズムを使用する必要があるかもしれないので、SSHプロトコルでは、ユーザー名フィールドを記入しなければならないかどうかについては必ずしも明確ではありませんSSHのアイデンティティに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は（おそらくSNMP-TARGET-MIBで指定された構成の）アプリケーションによってSSH輸送モデルに提示されます。
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.
セキュリティ名は、セキュリティモデルによってtmSecurityNameから誘導することができるとMIBモジュールに通知し、アクセス制御を設定するために使用されるかもしれません。事業者はtmSecurityNames由来securityNamesを使用するMIBモジュールを設定するときに使用するものを知っているだろうので、輸送モデルは、予測可能なtmSecurityNameを生成する必要があります。
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は、領収書の時点でメッセージごとに記録されなければなりません。 tmSameSecurityが設定されている場合、記録tmSessionIDは、対応する送信メッセージを送信するために利用可能な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]で定義され、さらにSNMPエンティティ内の様々なサブシステム間を流れる概念的なデータを記述するために[RFC5590]によって拡張されてきました。セキュアシェル輸送モデルは、サブシステム間の通信時に、これらの概念のデータの一部が流入する使用します。
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.
statusInformationを中にエラー表示は、典型的には、オブジェクト識別子（OID）と増分エラーカウンタの値を含むであろう。これは、要求されたsecurityLevelとtmStateReferenceを伴うことがあります。返されたカウンタOIDと値のため、contextEngineはエラーカウンタのデフォルトのコンテキストへのsnmpEngineIDとのcontextNameのローカル値に設定されますので、メッセージごとのコンテキスト情報は、モデルを輸送するためにアクセスできません。
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.
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.
これは、サーバー側のSSHセッションがあり、これはセッションを介して受信された最初のメッセージである場合B.、次いで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).
これは、サーバー側のSSHセッションであり、これはセッションを介して受信された最初のメッセージでない場合C.は、次いでtmTransportAddressは、セッションのために以前に確立tmTransportAddress（以前の着信メッセージから決定工程Bからの値）に設定されています。
3. Determine the tmSecurityName to be associated with the incoming message:
前記着信メッセージに関連付けられるtmSecurityNameを決定します。
A. If this is a client-side SSH session, then the tmSecurityName
MUST be set to the tmSecurityName used to establish the
session.
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.
これは、サーバー側のSSHセッションがあり、これはセッションを介して受信された最初のメッセージである場合B.、次いで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).
これは、サーバー側のSSHセッションであり、これはセッションを介して受信された最初のメッセージでない場合C.は、次いでtmSecurityNameは、セッションのために以前に確立tmSecurityName（以前の着信メッセージから決定工程Bからの値）に設定されています。
4. Create a tmStateReference cache for subsequent reference to the information.
4.情報へのその後の参照のためtmStateReferenceキャッシュを作成します。
tmTransportDomain = snmpSSHDomain
TM交通ドメイン= SNMP SSHドメイン
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 )
wholeMessageLength IN SSHからの全SNMPメッセージ - - の長さwholeMessage INメッセージをtmTransportAddress - transportAddress IN snmpSSHDomain - statusInformationを= receiveMessage（transportDomain IN：次いで輸送モデルは、次のASIを使用して、ディスパッチャにメッセージを渡しますtmStateReferenceでのSNMPメッセージ - （NEW）交通情報）
The Dispatcher passes the information to the Transport Model using the ASI defined in the Transport Subsystem:
Dispatcherは輸送サブシステムで定義された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 )
statusInformationを=のsendMessage（destTransportDomain IN - 輸送ドメインがdestTransportAddressで使用する - トランスポートアドレスのoutgoingMessageで使用する - outgoingMessageLengthで送信するメッセージ - tmStateReferenceでの長さ - （NEW）が情報を運びます）
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、及びtmSameSecurityの値を含むキャッシュを参照して、次にsnmpSshtmSessionInvalidCachesカウンタをインクリメント、メッセージを破棄し、そしてstatusInformationを中にエラー表示が返されない場合。このメッセージの処理が停止します。
2. Extract the tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and tmSessionID from the tmStateReference.
2. tmStateReferenceからtmTransportDomain、tmTransportAddress、tmSecurityName、tmRequestedSecurityLevel、tmSameSecurity、及びtmSessionIDを抽出します。
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.
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.
上記の手順は、使用するセッションを選択しなかった場合には、パラメータとしてtmStateReferenceとのOpenSessionを（）D.を呼び出します。
+ 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.
+ 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が成功した場合、実装依存的にdestTransportDomain、destTransportAddress、tmSecurityname、及びtmSessionIDを記録します。受信メッセージを処理するときにこれが必要になります。
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.
前記識別されたSSHセッションを通じてSSHメッセージ内のデータとしてカプセル化のためにSSHにwholeMessageを渡します。必要な追加の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.
セキュアシェル輸送モデルは、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 )
statusInformationを=のOpenSession（tmStateReference、IN - 交通情報tmStateReferenceをOUTに使用される - maxMessageSizeに使用するトランスポート情報 - 送信するSNMPエンティティの）
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アプリケーションのために自動的に行われます。
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セッションの存続期間中、一定のままでなければなりません。実装は（セクション5.1を参照）、着信メッセージの処理を実行する際に後で使用するためのOpenSessionのAPIに渡されたtransportAddressをキャッシュする必要があるかもしれません。
1. To authenticate the server, the client usually stores pairs
(tmTransportAddress, server host public key) in an
implementation-dependent manner.
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.接続を確立しようとする試みが失敗したか、サーバー認証が失敗した場合、その後、snmpSshtmSessionOpenErrorsはのOpenSessionのエラー表示が返され、インクリメントされ、のOpenSession処理が停止した場合。
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認証プロトコル[RFC4252]に記載されているように、プリンシパルを認証するためにSSH認証サービスを呼び出します。
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.
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.は、次いで、輸送接続は、閉じられsnmpSshtmSessionUserAuthFailuresカウンタがインクリメントされ、エラー表示が呼び出し側モジュールに戻され、処理がこのメッセージに停止します。
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接続プロトコル[RFC4254]として知られている）「SSH接続」サービスを起動し、そして型「セッション」のチャネルを要求すべきです。失敗した場合、トランスポート接続が閉じられるsnmpSshtmSessionNoChannelsカウンタがインクリメントされ、エラー表示が呼び出し側モジュールに戻され、処理は、このメッセージのために停止されます。
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.クライアントは、「サブシステム」パラメータで示されているように、SSHサブシステムとして「SNMP」を起動します。失敗した場合、トランスポート接続が閉じられるsnmpSshtmSessionNoSubsystemsカウンタがインクリメントされ、エラー表示が呼び出し側モジュールに戻され、処理は、このメッセージのために停止されます。
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.
6. Set tmSessionID in the tmStateReference cache to an implementation-dependent value to identify the session.
セッションを識別するために実装依存の値にtmStateReferenceキャッシュ6.設定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セッションを確立するために使用tmSecurityNameは、セッションで使用される唯一の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を= closeSession（tmSessionID、IN - クローズするセッションのセッションID）
The following describes the procedure to follow to close a session between a client and server. This process is followed by any SNMP engine to close an SSH session. It is implementation-dependent when a session should be closed. The calling code should release the associated tmStateReference.
以下は、クライアントとサーバー間のセッションを閉じるには従うべき手順を説明します。このプロセスは、SSHセッションを閉じるには、任意のSNMPエンジンが続いています。セッションが終了しなければならないときには実装依存です。呼び出し元のコードは、関連するtmStateReferenceを解放する必要があります。
2. If there is no session corresponding to tmSessionID, then closeSession processing is complete.
2. tmSessionIDに対応するセッションがない場合には、closeSession処理が完了しています。
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].
[RFC2578]、[RFC2579]及び[RFC2580]から次のMIBモジュールの輸入アイテム。
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の内部モジュールののTDomainテキストの表記法を使用しています。
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 ;
SNMPv2-CONF FROM RFC 2579 MODULE-COMPLIANCE、オブジェクト・グループ - のSNMPv2-TC FROM RFC 2578テキストの表記法 - のSNMPv2-SMIからの輸入MODULE-IDENTITY、OBJECT-TYPE、OBJECT-IDENTITY、MIB-2、snmpDomains、Counter32の - 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 MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMSワーキンググループ" CONTACT-INFO「WG-Eメール：isms@lists.ietf.org購読：isms-request@lists.ietf.org
Chairs:
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
+49 6221 90511-15
quittek@netlab.nec.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de
ユルゲンSchoenwaelderジェイコブス大学ブレーメンキャンパスリング1 28725ブレーメンドイツ+49 421 200から3587 j.schoenwaelder@jacobs-university.de
Co-editors: David Harrington Huawei Technologies USA 1700 Alma Drive Plano Texas 75075
共同編集者：デヴィッド・ハリントン華為技術USA 1700アルマドライブプラノ、テキサス75075
USA +1 603-436-8634 ietfdbh@comcast.net
USA +1 603-436-8634 ietfdbh@comcast.net
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com
ジョセフSaloweyシスコシステムズ2901年第三アベニューシアトル、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.
ウェスHardakerコブハム分析ソリューション私書箱382デイビス、CA 95617 USA +1 530 792 1913 ietf@hardakers.net "DESCRIPTION" セキュアシェル輸送モデルMIBをボックスです。
Copyright (c) 2009 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, 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,
このソフトウェアは、著作権所有者によって提供され、貢献者AS IS 'AND明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証を放棄されています。 NO EVENTの著作権所有者または貢献者は、偶発的、間接的、直接的、間接的、
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.
、SPECIAL例示的、または間接的損害が（INCLUDINGは、なく、代替商品またはサービスの調達、これらに限定されるもので、使用、データ、または利益の損失、または事業の中断）いかなる責任の理論、それが契約、厳格責任、（過失またはその他を含む）不法行為そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失。
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."
"RFC 5592.に掲載された最初のバージョン、" REVISION "200906090000Z" DESCRIPTION
::= { 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 OBJECT-IDENTITYステータス現在の説明「SNMPオーバー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.
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.
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.
ホスト名は、（RFC1033による）US-ASCIIに常にあります。 「：」（US-ASCII文字0x3A）とUS-ASCIIで10進数のポート番号ホスト名はコロンが続いているRFC 3490に指定されている国際化ホスト名は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.
「：」（US-ASCII文字0x3A）とUS-ASCIIで10進数のポート番号IPv4アドレスは、コロンが後に続くドット10進形式でなければなりません。
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.
'：'（US-ASCII文字のIPv6アドレスは、コロン（、US-ASCII文字0x5D '['、US-ASCII文字0x5B、および ']'）、角括弧に囲まれた、コロン区切りの形式でなければなりません0x3A）とUS-ASCIIで10進数のポート番号。
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の指定された128のサブ識別子（STD 58）の限界の問題があってもよいです。このテキストの表記法を使用して、すべてのMIBの文書がインデックスコンポーネントの明示的な制限事項は、管理ソフトウェアが守らなければならないことを長することをお勧めします。これは、インデックスコンポーネントのサイズの制約を含めることによって、または概念的な行の記述節内または周囲のドキュメントに適用可能な制約を指定することによってのいずれかで行うことができます。 「REFERENCE "RFC 1033：ドメイン管理者操作ガイドのRFC 3490：アプリケーションRFC 3986で国際化ドメイン名：統一資源識別子（URI）：汎用構文RFC 4252：セキュアシェル（SSH）認証プロトコル" 構文オクテットSTRING（SIZE（1。 0.255））
-- The snmpSshtmSession Group
- snmpSshtmSessionグループ
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
snmpSshtmSessionOpenErrorsのOBJECT-TYPE SYNTAXカウンタACCESS read-onlyステータス現在
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
snmpSshtmSessionInvalidCachesのOBJECT-TYPE SYNTAXカウンタ
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 -- ************************************************
- ************************************************ - snmpSshtmMIB - 適合情報 - ****************************************** ******
snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 }
snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 }
-- ************************************************ -- Compliance statements -- ************************************************
- ************************************************ - コンプライアンスステートメント - ******************************************** ****
snmpSshtmCompliance MODULE-COMPLIANCE STATUS current
snmpSshtmCompliance MODULE-COMPLIANCEステータス電流
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. "
snmpSshtmGroupオブジェクト・グループオブジェクト{snmpSshtmSessionOpens、snmpSshtmSessionCloses、snmpSshtmSessionOpenErrors、snmpSshtmSessionUserAuthFailures、snmpSshtmSessionNoChannels、snmpSshtmSessionNoSubsystems、snmpSshtmSessionNoSessions、snmpSshtmSessionInvalidCaches}ステータス現在の説明「SNMPセキュアシェル輸送モデルを実装するSNMPエンジンの情報を維持するためのオブジェクトの収集」。
::= { 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 [RFC5591]のためのトランスポート・セキュリティ・モデルとして、tmStateReferenceを処理する方法を知っているセキュリティモデルを使用しなければなりません。
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プロトコルは、SSHの仕様は、ウィンドウ調整メッセージを作成する必要があるとき、それは開いたままRFC 4254.で定義された独自のウィンドウメカニズムを有し、受信したデータがアプリケーションに渡された時はいつでもいくつかの実装では、これらを送信します。あまり頻繁にそれらを送信することで回避することができ、このようなウィンドウ調整メッセージを、取り扱いに目立つ帯域幅と処理のオーバーヘッドがあります。
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.
このメモはSSHのセキュリティサービスを利用するためにSNMPを許可する輸送モデルを説明しています。 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は、「なし」USERAUTH方法を提供します。 SSH輸送モデルは、「なし」USERAUTH法による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.
このようGSSAPI認証を使用したものなどいくつかの実装のために、tmSecurityNameにSSHのアイデンティティを変換したり、変換するマッピングアルゴリズムを使用する必要があるかもしれないので、SSHプロトコルでは、ユーザー名フィールドを記入しなければならないかどうかについては必ずしも明確ではありませんSSHのアイデンティティに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を認証することができます。しかし、公開鍵によって署名されたディフィー・ヘルマン（DH）の一般的な場合のために、これはホストの公開鍵を先験的に知るために、正しいキーが使用されていることを確認するためにクライアントが必要です。このステップはスキップされている場合は、SSHクライアントのSSHサーバの認証は行われません。サーバーへのデータの機密性と完全性の保護にはまだ存在しますが、攻撃者がクライアントと実際のSSHサーバー間で自分自身を挿入することができたときにこれらが疑わしい価値があります。いくつかのUSERAUTH方法は、このような状況から身を守ることがありますが、（パスワードとキーボードインタラクティブを含む）一般的なものの多くは、と、実際には、サーバの身元が確認されたという事実に依存しない（ので、パスワードはに開示されていません攻撃者）。
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エンジンで使用されるセキュリティ名に基づいて受信機に送信することを許可されています。この権限は、メッセージが実際に送信される前に実行され、リモート受信機の資格情報が検証されている前に。したがって、通知受信部によって提示資格情報が与えられたトランスポートアドレスの期待値（S）と一致しなければならない、とクレデンシャルの所有権が適切に暗号的に検証されなければなりません。
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.
「ユーザー@」プレフィックスが認証に使用するSSHのユーザー名を指定するには、SnmpSSHAddress値内で使用されている場合は、リモートエンティティに提示キーは、「ユーザー」のために、サーバによって期待されるキーでなければなりません。これは、セキュリティ名値によって識別されるローカルにキャッシュされたキーと異なる場合があります。
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テキストの表記法のオプションの「ユーザー@」接頭コンポーネントは、クライアント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は、SSH輸送モデルで使用するために、「なし」MACアルゴリズムを使用して設定しないでください。
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メッセージからセキュリティ名とたsecurityLevelを導き出します。アクセス制御の決定は、そのためではなくSSH輸送モデルにより提供される認証されたIDとたsecurityLevelを使用するよりも、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.
読み書きおよび/またはリード作成のMAX-ACCESS節を持っているこのMIBモジュールで定義された管理オブジェクトがありません。このMIBモジュールが正しく実装されているのであれば、その後、侵入者が変更またはダイレクトSNMP SET操作を経て、この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モジュールで読み取り可能なオブジェクトの一部（すなわち、アクセス可能ではない以外MAX-ACCESS持つオブジェクト）は、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。 GETおよび/またはこれらのオブジェクトへのアクセスを通知し、おそらく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を使用して、例えば）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）オブジェクトが存在しませんこのMIBモジュールインチ
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for 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.
このようなユーザベースセキュリティモデルに見られるような認証とプライバシーのために暗号化メカニズムのためのフルサポートを含む、（[RFC3410]、セクション8を参照）SNMPv3フレームワークで提供するように実装は、セキュリティ機能を考える[RFC3414]を推奨されます、トランスポート・セキュリティモデル[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実体が適切にのみプリンシパル（ユーザ）にオブジェクトへのアクセスを提供するように設定されていることを確認するために、顧客/オペレータ責任実際にGETまたはSET（変化への正当な権利を有することです/）/削除、それらを作成します。
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).
この文書で定義されている通知のため、この文書で定義されているSNMPオーバーSSH輸送モデルのデフォルトポート、およびSNMPオーバーSSH輸送モデルになるのポート番号のレジストリに1つのTCPポート番号。割り当てられたキーワードとポート番号は「snmpssh」（5161）と「snmpsshトラップ」（5162）です。
2. An SMI number (189) under mib-2, for the MIB module in this document.
この文書に記載されているMIBモジュールのMIB-2の下で2アンSMI番号（189）。
4. "ssh" as the corresponding prefix for the snmpSSHDomain in the SNMP Transport Domains registry; defined in [RFC5590].
SNMP交通ドメインレジストリでsnmpSSHDomainに対応する接頭辞として4.「SSH」。 [RFC5590]で定義されます。
5. "snmp" as a Connection Protocol Subsystem Name in the SSH Protocol Parameters registry.
SSHプロトコル・パラメータレジストリ内の接続プロトコルサブシステム名など5.「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.
編集者は、組織と明瞭度を改善するために、既存の文書をwordsmithing優れた仕事のための彼のSSHの洞察を共有するためのジェフリーHutzelman、とDave盾に感謝したいと思います。
Additionally, helpful document reviews were received from Juergen Schoenwaelder.
また、役立つ文書のレビューは、ユルゲン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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、エド。、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]レビ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル（SNMP）アプリケーション"、STD 62、RFC 3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
、STD 62、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
、STD 62、RFC 3418、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）" [RFC3418] Presuhn、R.、。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（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]フライ、R.、レヴィ、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、 "セキュアシェル（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、 "セキュアシェル（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、 "セキュアシェル（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、 "セキュアシェル（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]ハリントン、D.とJ. Schoenwaelder、RFC 5590、2009年6月 "簡易ネットワーク管理プロトコル（SNMP）のための輸送サブシステム"。
[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.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル" [RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]バーナーズ - リー、T.、フィールディング、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]キューザック、F.およびM. Forssen、 "セキュアシェルプロトコル（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.、ガルブレイス、J.、およびV.ウェルチ、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース（GSS-API）の認証とセキュアシェル（SSH）プロトコルのための鍵交換"、RFC 4462、2006年5月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742]ワッサーマン、M.とT.ゴダード、 "セキュアシェル上でNETCONF構成プロトコルを使用して（SSH）"、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.、シュワルツ、D.、ウィリアムズ、D.、およびW.ベック、 "ダイジェスト認証のためのRADIUS拡張"、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]ハリントン、D.およびW. Hardaker、RFC 5591、2009年6月 "簡易ネットワーク管理プロトコル（SNMP）のためのトランスポート・セキュリティモデル"。
Authors' Addresses
著者のアドレス
David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
デヴィッド・ハリントン華為技術（USA）1700アルマ博士スイート100プラノ、TX 75075 USA
Phone: +1 603 436 8634 EMail: ietfdbh@comcast.net
電話：+1 603 436 8634 Eメール：ietfdbh@comcast.net
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA
ジョセフSaloweyシスコシステムズ2901年第三アベニューシアトル、WA 98121 USA
EMail: jsalowey@cisco.com
メールアドレス：jsalowey@cisco.com
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US
ウェス・ハードフィールドコブハム分析ソリューション私書箱382デイビス、CA 95617米国箱
Phone: +1 530 792 1913 EMail: ietf@hardakers.net
電話：+1 530 792 1913 Eメール：ietf@hardakers.net