[要約] RFC 5608は、SNMPトランスポートモデルのためのRADIUSの使用方法についての規格です。このRFCの目的は、SNMPエージェントの認証とアクセス制御をRADIUSサーバーを介して行うためのガイドラインを提供することです。
Network Working Group K. Narayan
Request for Comments: 5608 Cisco Systems, Inc.
Category: Standards Track D. Nelson
Elbrys Networks, Inc.
August 2009
Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models
リモート認証ダイヤルインユーザーサービス（RADIUS）シンプルなネットワーク管理プロトコル（SNMP）トランスポートモデルの使用
Abstract
概要
This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model.
このメモでは、リモート認証ダイヤルインユーザーサービス（RADIUS）認証および認証サービスの使用について説明します。シンプルなネットワーク管理プロトコル（SNMP）セキュアトランスポートモデルを使用して、ユーザーを認証し、安全なトランスポートセッションの作成を承認します。このメモの推奨事項は一般に、SNMP輸送モデルの広範なクラスに適用されますが、例は安全なシェル（SSH）輸送モデルに焦点を当てています。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................2
1.1. General ....................................................2
1.2. Requirements Language ......................................3
1.3. System Block Diagram .......................................3
1.4. RADIUS Operational Model ...................................3
1.5. RADIUS Usage with Secure Transports ........................5
1.6. Domain of Applicability ....................................5
1.7. SNMP Transport Models ......................................6
2. RADIUS Usage for SNMP Transport Models ..........................7
2.1. RADIUS Authentication for Transport Protocols ..............8
2.2. RADIUS Authorization for Transport Protocols ...............8
2.3. SNMP Service Authorization .................................9
3. Table of Attributes ............................................11
4. Security Considerations ........................................12
5. Acknowledgements ...............................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service by Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model.
このメモは、リモート認証ダイヤルインユーザーサービス（RADIUS）認証および認証サービスの使用について説明します。シンプルなネットワーク管理プロトコル（SNMP）セキュアトランスポートモデルにより、ユーザーを認証し、安全なトランスポートセッションの作成を承認します。このメモの推奨事項は一般に、SNMP輸送モデルの広範なクラスに適用できますが、例は安全なシェル輸送モデルに焦点を当てています。
In the context of this document, a Network Access Server (NAS) is a network device or host that contains an SNMP engine implementation, utilizing SNMP Transport Models. It is customary in SNMP documents to indicate which subsystem performs specific processing tasks. In this document, we leave such decisions to the implementer, as is customary for RADIUS documents, and simply specify NAS behavior. Such processing would quite likely be implemented in the secure transport module.
このドキュメントのコンテキストでは、ネットワークアクセスサーバー（NAS）は、SNMPトランスポートモデルを利用したSNMPエンジンの実装を含むネットワークデバイスまたはホストです。SNMPドキュメントでは、特定の処理タスクを実行するサブシステムを示すことが慣習的です。このドキュメントでは、RADIUSドキュメントの慣習であるように、そのような決定を実装者に任せ、NASの動作を単純に指定します。このような処理は、安全な輸送モジュールに実装される可能性が非常に高いです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
A block diagram of the major system components referenced in this document may be useful to understanding the text that follows.
このドキュメントで参照されている主要なシステムコンポーネントのブロック図は、次のテキストを理解するのに役立つ場合があります。
+--------+
+......................... |RADIUS |....+
. |Server | .
Shared +--------+ .
User | .
Credentials RADIUS | Shared
. | RADIUS
. | Secret
. | .
+-------------+ +-----------------+
| Network | | RADIUS Client / |
| Management | SNMP | SNMP Engine / |
| Application |------------------| Network Device |
+-------------+ SSH +-----------------+
Block Diagram
ブロック図
This diagram illustrates that a network management application communicates with a network device, the managed entity, using SNMP over SSH. The network devices uses RADIUS to communicate with a RADIUS server to authenticate the network management application (or the user whose credentials that application provides) and to obtain authorization information related to access via SNMP for purpose of device management. Other secure transport protocols might be used instead of SSH.
この図は、ネットワーク管理アプリケーションがSSHを介してSNMPを使用して、ネットワークデバイスであるマネージドエンティティと通信することを示しています。ネットワークデバイスは、RADIUSを使用してRADIUSサーバーと通信して、ネットワーク管理アプリケーション（またはそのアプリケーションが提供する資格情報）を認証し、デバイス管理の目的でSNMPを介したアクセスに関連する認証情報を取得します。他の安全な輸送プロトコルは、SSHの代わりに使用される場合があります。
The RADIUS protocol [RFC2865] provides authentication and authorization services for network access devices, usually referred to as a Network Access Server (NAS). The RADIUS protocol operates, at the most simple level, as a request-response mechanism. RADIUS clients, within the NAS, initiate a transaction by sending a RADIUS Access-Request message to a RADIUS server, with which the client shares credentials. The RADIUS server will respond with either an Access-Accept message or an Access-Reject message.
RADIUSプロトコル[RFC2865]は、通常はネットワークアクセスサーバー（NAS）と呼ばれるネットワークアクセスデバイスに認証と認証サービスを提供します。RADIUSプロトコルは、リクエスト応答メカニズムとして最も単純なレベルで動作します。NAS内のRADIUSクライアントは、RADIUS Access-RequestメッセージをRADIUSサーバーに送信してトランザクションを開始し、クライアントが資格情報を共有します。RADIUSサーバーは、アクセスアクセプトメッセージまたはAccess-rejectメッセージのいずれかで応答します。
RADIUS supports authentication methods compatible with plaintext username and password mechanisms, MD5 Challenge/Response mechanisms, Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest mechanisms. Upon presentation of identity and credentials, the user is either accepted or rejected. RADIUS servers indicate a successful authentication by returning an Access-Accept message. An Access-Reject message indicates unsuccessful authentication.
RADIUSは、プレーンテキストのユーザー名とパスワードメカニズム、MD5チャレンジ/応答メカニズム、拡張可能な認証プロトコル（EAP）メカニズム、およびHTTPダイジェストメカニズムと互換性のある認証方法をサポートします。アイデンティティと資格情報を提示すると、ユーザーは受け入れられるか拒否されます。RADIUSサーバーは、アクセスアクセプトメッセージを返すことにより、認証が成功することを示します。アクセス拒否メッセージは、認証の失敗を示します。
Access-Accept messages are populated with one or more service provisioning attributes, which control the type and extent of service provided to the user at the NAS. The authorization portion may be thought of as service provisioning. Based on the configuration of the user's account on the RADIUS server, upon authentication, the NAS is provided with instructions as to what type of service to provide to the user. When that service provisioning does not match the capabilities of the NAS, or of the particular interface to the NAS over which the user is requesting access, RFC 2865 [RFC2865] requires that the NAS MUST reject the access request. RFC 2865 describes service provisioning attributes for management access to a NAS, as well as various terminal emulation and packet forwarding services on the NAS. This memo describes specific RADIUS service provisioning attributes that are useful with secure transports and SNMP Transport Models.
Access-Accceptメッセージには、NASのユーザーに提供されるサービスの種類と範囲を制御する1つ以上のサービスプロビジョニング属性が入力されます。承認部分は、サービスプロビジョニングと考えられる場合があります。RADIUSサーバー上のユーザーアカウントの構成に基づいて、認証時に、NASにはユーザーに提供するサービスの種類に関する指示が提供されます。そのサービスの提供がNASの機能、またはユーザーがアクセスを要求しているNASへの特定のインターフェースの機能と一致しない場合、RFC 2865 [RFC2865]は、NASがアクセス要求を拒否する必要があることを要求します。RFC 2865は、NASへの管理アクセスのためのサービスプロビジョニング属性、およびNASのさまざまな端末エミュレーションおよびパケット転送サービスについて説明しています。このメモは、安全な輸送とSNMP輸送モデルに役立つ特定のRADIUSサービスプロビジョニング属性について説明します。
RADIUS servers are often deployed on an enterprise-wide or organization-wide basis, covering a variety of disparate use cases. In such deployments, all NASes and all users are serviced by a common pool of RADIUS servers. In many deployments, the RADIUS server will handle requests from many different types of NASes with different capabilities, and different types of interfaces, services, and protocol support.
RADIUSサーバーは、多くの場合、企業全体または組織全体で展開され、さまざまな異なるユースケースをカバーします。このような展開では、すべてのNASEとすべてのユーザーが、RADIUSサーバーの共通プールでサービスを提供します。多くの展開では、RADIUSサーバーは、さまざまな機能を備えたさまざまなタイプのNaseからのリクエスト、およびさまざまな種類のインターフェイス、サービス、およびプロトコルサポートを処理します。
In order for a RADIUS server to make the correct authorization decision in all cases, the server will often need to know something about the type of NAS at which the user is requesting access, the type of service that the user is requesting, and the role of the user in the organization. For example, many users may be authorized to receive network access via a Remote Access Server (RAS), Virtual Private Network (VPN) server, or LAN access switch. Typically only a small sub-set of all users are authorized to access the administrative interfaces of network infrastructure devices, e.g., the Command Line Interface (CLI) or SNMP engine of switches and routers.
RADIUSサーバーがすべての場合に正しい承認決定を下すために、サーバーはユーザーがアクセスを要求しているNASのタイプ、ユーザーが要求しているサービスの種類、および役割について何かを知る必要があることがよくあります。組織内のユーザーの。たとえば、多くのユーザーは、リモートアクセスサーバー（RAS）、仮想プライベートネットワーク（VPN）サーバー、またはLANアクセススイッチを介してネットワークアクセスを受信することを許可される場合があります。通常、すべてのユーザーの小さなサブセットのみが、ネットワークインフラストラクチャデバイスの管理インターフェイスにアクセスする権限があります。たとえば、コマンドラインインターフェイス（CLI）またはスイッチとルーターのSNMPエンジン。
In order for the RADIUS server to have information regarding the type of access being requested, it is common for the NAS (i.e., the RADIUS client) to include "hint" attributes in the RADIUS Access-Request message, describing the NAS and the type of service being requested.
RADIUSサーバーが要求されているアクセスの種類に関する情報を持つためには、NAS（つまり、RADIUSクライアント）がRADIUSアクセスリケストメッセージに「ヒント」属性を含めることが一般的です。要求されているサービスの。
This document recommends appropriate "hint" attributes for the SNMP service type.
このドキュメントは、SNMPサービスタイプに適切な「ヒント」属性を推奨しています。
Some secure transport protocols that can be used with SNMP Transport Models have defined authentication protocols supporting several authentication methods. For example, the Secure Shell (SSH) Authentication protocol [RFC4252] supports multiple methods (including public key, password, and host-based) to authenticate SSH clients.
SNMPトランスポートモデルで使用できるいくつかの安全な輸送プロトコルは、いくつかの認証方法をサポートする認証プロトコルを定義しています。たとえば、Secure Shell（SSH）認証プロトコル[RFC4252]は、SSHクライアントを認証するための複数の方法（公開キー、パスワード、ホストベースを含む）をサポートしています。
SSH Server integration with RADIUS traditionally uses the username and password mechanism.
RADIUSとのSSHサーバーの統合は、従来、ユーザー名とパスワードのメカニズムを使用しています。
Secure transport protocols do not, however, specify how the transport interfaces to authentication clients, leaving such as implementation specific. For example, the "password" method of SSH authentication primarily describes how passwords are acquired from the SSH client and transported to the SSH server, the interpretation of the password and validation against password databases is left to SSH server implementations. SSH server implementations often use the Pluggable Authentication Modules [PAM] interface provided by operating systems such as Linux and Solaris to integrate with password-based network authentication mechanisms such as RADIUS, TACACS+ (Terminal Access Controller Access-Control System Plus), Kerberos, etc.
ただし、安全な輸送プロトコルでは、実装固有のような輸送インターフェイスが認証クライアントにどのように留められているかを指定しません。たとえば、SSH認証の「パスワード」メソッドは、主にSSHクライアントからパスワードが取得され、SSHサーバーに輸送される方法を説明しています。パスワードの解釈とパスワードデータベースに対する検証は、SSHサーバーの実装に任されています。SSHサーバーの実装では、LinuxやSolarisなどのオペレーティングシステムが提供するプラグ可能な認証モジュール[PAM]インターフェイスを使用して、RADIUS、TACACS（ターミナルアクセスコントローラーアクセス制御システムプラス）、Kerberosなどのパスワードベースのネットワーク認証メカニズムと統合することがよくあります。。
Secure transports do not typically specify how to utilize authorization information obtained from a AAA service, such as RADIUS. More often, user authentication is sufficient to cause the secure transport server to begin delivering service to the user. Access control in these situations is supplied by the application to which the secure transport server session is attached. For example, if the application is a Linux shell, the user's access rights are controlled by that user account's group membership and the file system access protections. This behavior does not closely follow the traditional service provisioning model of AAA systems, such as RADIUS.
セキュアトランスポートは通常、RADIUSなどのAAAサービスから取得した認証情報を利用する方法を指定しません。より多くの場合、ユーザー認証は、安全なTransport Serverがユーザーへのサービスの提供を開始するのに十分です。これらの状況でのアクセス制御は、安全なトランスポートサーバーセッションが添付されているアプリケーションによって提供されます。たとえば、アプリケーションがLinuxシェルの場合、ユーザーのアクセス権はそのユーザーアカウントのグループメンバーシップとファイルシステムアクセス保護によって制御されます。この動作は、RADIUSなどのAAAシステムの従来のサービスプロビジョニングモデルに密接に従っていません。
Most of the RADIUS Attributes referenced in this document have broad applicability for provisioning remote management access to NAS devices using SNMP. However, the selection of secure transport protocols has special considerations. This document does not specify details of the integration of secure transport protocols with a RADIUS client in the NAS implementation. However, there are functional requirements for correct application of framed management protocols and secure transport protocols that will limit the selection of such protocols that can be considered for use with RADIUS. Since the RADIUS user credentials are obtained by the RADIUS client from the secure transport protocol server, or in some cases directly from the SNMP engine, the secure transport protocol, and its implementation in the NAS, MUST support forms of credentials that are compatible with the authentication methods supported by RADIUS.
このドキュメントで参照されているRADIUS属性のほとんどは、SNMPを使用してNASデバイスへのリモート管理アクセスをプロビジョニングするために幅広い適用性を備えています。ただし、安全な輸送プロトコルの選択には特別な考慮事項があります。このドキュメントでは、NASの実装におけるRADIUSクライアントとの安全な輸送プロトコルの統合の詳細を指定していません。ただし、Framed Management Protocolsと安全な輸送プロトコルを正しく適用するための機能的要件があり、そのようなプロトコルの選択を制限して、半径で使用することを考慮しています。RADIUSユーザーの資格情報は、Secure Transport Protocol ServerからRADIUSクライアントによって取得されるため、または場合によってはSNMPエンジン、安全な輸送プロトコル、およびNASでのその実装から直接取得されるため、NASにおけるその実装は、互換性のある資格情報の形式をサポートする必要があります。半径でサポートされている認証方法。
RADIUS currently supports the following user authentication methods, although others may be added in the future:
RADIUSは現在、次のユーザー認証方法をサポートしていますが、他のユーザーは将来追加される可能性があります。
o Password - RFC 2865
o パスワード-RFC2865
o CHAP (Challenge Handshake Authentication Protocol) - RFC 2865
o chap（チャレンジハンドシェイク認証プロトコル）-RFC2865
o ARAP (Apple Remote Access Protocol) - RFC 2869
o ARAP（Appleリモートアクセスプロトコル）-RFC2869
o EAP (Extensible Authentication Protocol) - RFC 2869, RFC 3579
o EAP（拡張可能な認証プロトコル）-RFC2869、RFC 3579
o HTTP Digest - RFC 5090
o HTTP Digest -RFC 5090
The secure transport protocols selected for use with RADIUS and SNMP obviously need to support user authentication methods that are compatible with those that exist in RADIUS. The RADIUS authentication methods most likely usable with these protocols are Password, CHAP, and possibly HTTP Digest, with Password being the distinct common denominator. There are many secure transports that support other, more robust, authentication mechanisms, such as public key. RADIUS has no support for public key authentication, except within the context of an EAP Method. The applicability statement for EAP indicates that it is not intended for use as an application-layer authentication mechanism, so its use with the mechanisms described in this document is NOT RECOMMENDED. In some cases, Password may be the only compatible RADIUS authentication method available.
RADIUSおよびSNMPで使用するために選択された安全な輸送プロトコルは、明らかにRADIUSに存在するものと互換性のあるユーザー認証方法をサポートする必要があります。これらのプロトコルで使用可能なRADIUS認証方法は、パスワード、CHAP、および場合によってはHTTPダイジェストであり、パスワードは明確な一般的な分母です。公開鍵など、他の、より堅牢な認証メカニズムをサポートする多くの安全なトランスポートがあります。RADIUSは、EAPメソッドのコンテキスト内を除き、公開キー認証をサポートしていません。EAPの適用性ステートメントは、アプリケーション層認証メカニズムとして使用することを意図していないことを示しているため、このドキュメントで説明されているメカニズムでの使用は推奨されません。場合によっては、パスワードが利用可能な唯一の互換性のあるRADIUS認証方法である場合があります。
The Transport Subsystem for SNMP [RFC5590] defines a mechanism for providing transport layer security (TLS) for SNMP, allowing protocols such as SSH and TLS to be used to secure SNMP communication. The Transport Subsystem allows the modular definition of Transport Models for multiple secure transport protocols. Transport Models rely upon the underlying secure transport for user authentication services. The Transport Model (TM) then maps the authenticated identity to a model-independent principal, which it stores in the tmStateReference. When the selected security model is the Transport Security Model (TSM), the expected behavior is for the securityName to be set by the TSM from the authenticated principal information stored in the tmStateReference by the TM.
SNMPのトランスポートサブシステム[RFC5590]は、SNMPに輸送層セキュリティ（TLS）を提供するメカニズムを定義し、SSHやTLSなどのプロトコルを使用してSNMP通信を保護することができます。トランスポートサブシステムにより、複数の安全な輸送プロトコルの輸送モデルのモジュラー定義が可能になります。輸送モデルは、ユーザー認証サービスの基礎となる安全な輸送に依存しています。トランスポートモデル（TM）は、認証されたアイデンティティをモデルに依存しないプリンシパルにマッピングし、TMSTATEREFENERTで保存します。選択されたセキュリティモデルがTransport Security Model（TSM）である場合、予想される動作は、TMSTATEREFENECTに保存されている認証された主要な情報からTSMによってTSMによって設定されることです。
The Secure Shell protocol provides a secure transport channel with support for channel authentication via local accounts and integration with various external authentication and authorization services such as RADIUS, Kerberos, etc. The Secure Shell Transport Model [RFC5592] defines the use of the Secure Shell protocol as the basis for a Transport Model.
Secure Shellプロトコルは、ローカルアカウントを介したチャネル認証をサポートし、RADIUS、Kerberosなどのさまざまな外部認証および承認サービスとの統合を備えた安全なトランスポートチャネルを提供します。安全なシェル輸送モデル[RFC5592]は、安全なシェルプロトコルの使用を定義します。輸送モデルの基礎として。
There are two use cases for RADIUS support of management access via SNMP. These are (a) service authorization and (b) access control authorization. RADIUS almost always involves user authentication as prerequisite to authorization, and there is a user authentication phase for each of these two use cases. The first use case is discussed in detail in this memo, while the second use case is a topic of current research, and beyond the scope of this document. This document describes the way in which RADIUS attributes and messages are applied to the specific application area of SNMP Transport Models. User authentication and service authorization via RADIUS are undertaken by the secure transport module, that underlies the SNMP Transport Model.
SNMPを介した管理アクセスの半径サポートのための2つのユースケースがあります。これらは、（a）サービス承認と（b）アクセス制御承認です。RADIUSは、ほとんどの場合、許可の前提条件としてユーザー認証を伴い、これら2つのユースケースのそれぞれにユーザー認証フェーズがあります。最初のユースケースについては、このメモで詳細に説明しますが、2番目のユースケースは現在の研究のトピックであり、このドキュメントの範囲を超えています。このドキュメントでは、半径属性とメッセージがSNMP輸送モデルの特定のアプリケーション領域に適用される方法について説明します。RADIUSを介したユーザー認証とサービスの承認は、SNMPトランスポートモデルの根底にある安全な輸送モジュールによって行われます。
User authentication for SNMP Transport Models has the same syntax and semantics as user authentication for any other network service. In the context of SNMP, the "user" is thought of as a "principal" and may represent a host, an application, or a human.
SNMPトランスポートモデルのユーザー認証には、他のネットワークサービスのユーザー認証と同じ構文とセマンティクスがあります。SNMPのコンテキストでは、「ユーザー」は「プリンシパル」と考えられており、ホスト、アプリケーション、または人間を表す場合があります。
Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP, optionally over a secure transport, typically using an SNMP Transport Model. This memo describes mechanisms by which such information can be requested from a RADIUS server and enforced within the NAS. An SNMP architecture, [RFC3411], does not make a distinction between user authentication and service authorization. In the case of existing, deployed security models, such as the User-based Security Model (USM), this distinction is not significant. For SNMP Transport Models, this distinction is relevant and important.
サービス承認により、RADIUSサーバーは、通常はSNMPトランスポートモデルを使用して、オプションで安全なトランスポートを使用して、認証されたプリンシパルがSNMPを使用するように許可します。このメモは、そのような情報をRADIUSサーバーから要求し、NAS内で実施できるメカニズムについて説明しています。SNMPアーキテクチャ[RFC3411]は、ユーザー認証とサービス承認を区別しません。ユーザーベースのセキュリティモデル（USM）などの既存の展開されたセキュリティモデルの場合、この区別は重要ではありません。SNMP輸送モデルの場合、この区別は関連性があり、重要です。
It is relevant because of the way in which SSH implementations have traditionally integrated with RADIUS clients. Those SSH implementations traditionally seek to obtain user authentication (e.g., validation of a username and password) from an outside authentication service, often via a PAM-style interface. The service authorization in traditional SSH server implementations comes via the restrictions that the operating system (OS) shell (and file system, etc.) place on the user by means of access controls tied to the username or the username's membership in various user groups. These OS-style access controls are distinct from the service provisioning features of RADIUS. If we wish to use existing SSH server implementations, or slightly adapt them, for use with SNMP Transport Models, and we wish to support RADIUS-provisioned service authorization, we need to be aware that the RADIUS service authorization information will need to be obtained by the relevant SNMP models from the SSH module.
これは、SSHの実装が伝統的にRADIUSクライアントと統合されてきた方法のために関連しています。これらのSSH実装は、従来、多くの場合、PAMスタイルのインターフェイスを介して、外部認証サービスからユーザー認証（例：ユーザー名とパスワードの検証）を取得しようとしています。従来のSSHサーバーの実装におけるサービス承認は、さまざまなユーザーグループのユーザー名またはユーザー名のメンバーシップに関連するアクセスコントロールによってユーザーに配置されるオペレーティングシステム（OS）シェル（およびファイルシステムなど）がユーザーに配置する制限を介して行われます。これらのOSスタイルのアクセスコントロールは、RADIUSのサービスプロビジョニング機能とは異なります。既存のSSHサーバーの実装を使用するか、SNMPトランスポートモデルで使用するためにそれらをわずかに適応させ、半径がプロビジョニングされたサービス承認をサポートしたい場合は、RADIUSサービス承認情報を取得する必要があることに注意する必要があります。SSHモジュールからの関連するSNMPモデル。
One reason that RADIUS-provisioned service authorization is important is that in many deployments, the RADIUS server's back-end authentication database contains credentials for many classes of users, only a small portion of which may be authorized to access the management interfaces of managed entities (NASes) via SNMP. This is in contrast to the way USM for SNMP works, in which all principals entered to the local configuration data-store are authorized for access to the managed entity. In the absence of RADIUS-provisioned service authorization, network management access may be granted to unauthorized, but properly authenticated, users. With SNMPv3, an appropriately configured Access Control Model would serve to alleviate the risk of unauthorized access.
RADIUSがプロビジョニングされたサービス承認が重要である理由の1つは、多くの展開において、RADIUSサーバーのバックエンド認証データベースに多くのクラスのユーザーの資格情報が含まれていることです。nase）SNMP経由。これは、SNMPのUSMの仕組みとは対照的であり、ローカル構成データストアに入力されたすべてのプリンシパルがマネージドエンティティへのアクセスを許可されています。Radiusがプロビジョニングしたサービス承認がない場合、ネットワーク管理アクセスは、不正であるが適切に認証されたユーザーに付与される場合があります。SNMPV3を使用すると、適切に構成されたアクセス制御モデルが、不正アクセスのリスクを軽減するのに役立ちます。
This document will rely on implementation specific integration of the transport protocols with RADIUS clients for user authentication.
このドキュメントは、ユーザー認証のために、トランスポートプロトコルとRADIUSクライアントの実装固有の統合に依存します。
It is REQUIRED that the integration of RADIUS clients with transport protocols utilize appropriate "hint" attributes in RADIUS Access-Request messages, to signal to the RADIUS server the type of service being requested over the transport session. Specific attributes for use with SNMP Transport Models are recommended in this document.
RADIUSクライアントとトランスポートプロトコルを統合すると、RADIUS Access-Requestメッセージの適切な「ヒント」属性を使用して、RADIUSサーバーにトランスポートセッションで要求されるサービスのタイプを信号に合わせてください。このドキュメントでは、SNMP輸送モデルで使用する特定の属性を推奨しています。
RADIUS servers, compliant to this specification, MAY use RADIUS "hint" attributes, as described herein, to inform the decision whether to accept or reject the authentication request.
この仕様に準拠したRADIUSサーバーは、本明細書に記載されているように、RADIUS「ヒント」属性を使用して、認証要求を受け入れるか拒否するかどうかを決定に通知することができます。
In compliance with RFC 2865, NASes MUST enforce implicitly mandatory attributes, such as Service-Type, within an Access-Accept message. NASes MUST treat Access-Accept messages that attempt to provision unsupported services as if they were an Access-Reject. NASes SHOULD treat unknown attributes as if they were provisioning unsupported services. See [RFC5080] for additional details.
RFC 2865に準拠して、NASESは、アクセスアクセプトメッセージ内で、サービスタイプなどの暗黙的に必須の属性を実施する必要があります。NASEは、サポートされていないサービスをアクセス拒否であるかのようにプロビジョニングしようとするアクセスアクセプトメッセージを扱う必要があります。NASEは、サポートされていないサービスをプロビジョニングしているかのように、未知の属性を扱う必要があります。詳細については、[RFC5080]を参照してください。
A NAS that is compliant to this specification MUST treat any RADIUS Access-Accept message that provisions a level of transport protection (e.g., SSH) that cannot be provided, and/or application service (e.g., SNMP) that cannot be provided over that transport, as if an Access-Reject message had been received instead. The RADIUS Service-Type Attribute is the primary indicator of the service being provisioned, although other attributes may also convey service provisioning information.
この仕様に準拠したNASは、提供できないレベルの輸送保護（SSHなど）および/またはアプリケーションサービス（SNMPなど）をその輸送で提供できないアプリケーションサービス（SSH）を提供する半径アクセスacceptメッセージを扱う必要があります。、あたかもアクセス拒否メッセージが代わりに受信されたかのように。RADIUS Service-Type属性は、プロビジョニングされているサービスの主要な指標ですが、他の属性もサービスプロビジョニング情報を伝える場合があります。
For traditional SSH usage, RADIUS servers typically provision management access service, as SSH is often used to access the command line shell of a host system, e.g., the NAS. RFC 2865 defines two types of management access service attributes, one for privileged access to the Command Line Interface (CLI) of the NAS and one for non-privileged CLI access. These traditional management access services are not used with SNMP. [RFC5607] describes further RADIUS service provisioning attributes for management access to the NAS, including SNMP access.
従来のSSHの使用については、SSHがホストシステムのコマンドラインシェル、たとえばNASにアクセスするためによく使用されるため、RADIUSサーバーは通常、管理アクセスサービスを提供します。RFC 2865は、2種類の管理アクセスサービス属性を定義します。1つは、NASのコマンドラインインターフェイス（CLI）への特権アクセス、もう1つは特権のないCLIアクセス用です。これらの従来の管理アクセスサービスは、SNMPで使用されません。[RFC5607]は、SNMPアクセスを含むNASへの管理アクセスのためのさらなるRADIUSサービスプロビジョニング属性を説明しています。
The Transport Subsystem for SNMP [RFC5590] defines the notion of a session, although the specifics of how sessions are managed is left to Transport Models. The Transport Subsystem defines some basic requirements for transport protocols around creation and deletion of sessions. This memo specifies additional requirements for transport protocols during session creation and for session termination.
SNMPのトランスポートサブシステム[RFC5590]はセッションの概念を定義しますが、セッションの管理方法の詳細はモデルの輸送に残されています。トランスポートサブシステムは、セッションの作成と削除に関する輸送プロトコルの基本的な要件を定義します。このメモは、セッションの作成中およびセッション終了時の輸送プロトコルの追加要件を指定します。
RADIUS servers compliant to this specification MUST use RADIUS service provisioning attributes, as described herein, to specify SNMP access over a secure transport. Such RADIUS servers MAY use RADIUS "hint" attributes included in the Access-Request message, as described herein, in determining what, if any, service to provision.
この仕様に準拠したRADIUSサーバーは、本明細書に記載されているように、RADIUSサービスプロビジョニング属性を使用して、安全なトランスポート上のSNMPアクセスを指定する必要があります。このようなRADIUSサーバーは、ここで説明するように、プロビジョニングへのサービスを決定する際に、Access-Requestメッセージに含まれるRADIUS「ヒント」属性を使用する場合があります。
NASes compliant to this specification MUST use RADIUS service provisioning attributes, as described in this section, when they are present in a RADIUS Access-Accept message, to determine whether the session can be created, and they MUST enforce the service provisioning decisions of the RADIUS server.
この仕様に準拠したNASEは、このセクションで説明されているように、RADIUS Access-Acceptメッセージに存在する場合、セッションを作成できるかどうかを判断するために、RADIUSサービスプロビジョニング属性を使用する必要があります。サーバ。
The following RADIUS attributes MUST be used, as "hint" attributes included in the Access-Request message to signal use of SNMP over a secure transport (i.e., authPriv) to the RADIUS server:
Access-Requestメッセージに含まれる「ヒント」属性として、次のRADIUS属性を使用する必要があります。
1. Service-Type with a value of Framed-Management.
1. 額入り管理の価値を持つサービスタイプ。
2. Framed-Management-Protocol with a value of SNMP.
2. SNMPの値を持つフレームマネージメントプロトコル。
3. Management-Transport-Protection with a value of Integrity-Confidentiality-Protection.
3. 整合性自信のある保護の価値を伴う管理輸送保護。
The following RADIUS attributes MUST be used in an Access-Accept message to provision SNMP over a secure transport that provides both integrity and confidentiality (i.e., authPriv):
次のRADIUS属性は、整合性と機密性の両方を提供する安全なトランスポート（つまり、AuthPRIV）を提供するSNMPをプロビジョニングするためのアクセスacceptメッセージで使用する必要があります。
1. Service-Type with a value of Framed-Management.
1. 額入り管理の価値を持つサービスタイプ。
2. Framed-Management-Protocol with a value of SNMP.
2. SNMPの値を持つフレームマネージメントプロトコル。
3. Management-Transport-Protection with a value of Integrity-Confidentiality-Protection.
3. 整合性自信のある保護の価値を伴う管理輸送保護。
The following RADIUS attributes MUST be optionally used, to authorize use of SNMP without protection (i.e., authNoPriv):
保護なしでSNMPの使用を許可するために、次の半径属性をオプションで使用する必要があります（つまり、authnopriv）：
1. Service-Type with a value of Framed-Management.
1. 額入り管理の価値を持つサービスタイプ。
2. Framed-Management-Protocol with a value of SNMP.
2. SNMPの値を持つフレームマネージメントプロトコル。
3. Management-Transport-Protection with a value of No-Protection.
3. 無保護の値を伴う管理輸送保護。
There are no combinations of RADIUS attributes that denote the equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the authentication of a user (i.e., a principal) as a prerequisite for authorization. RADIUS can be used to provide an "Authorize-Only" service, but only when the request contains a "cookie" from a previous successful authentication with the same RADIUS server (i.e., the RADIUS State Attribute).
radiusには、認可の前提条件としてのユーザー（すなわち、プリンシパル）の認証が常に含まれるため、SNMP noauthnoprivアクセスに相当するradius属性の組み合わせはありません。RADIUSを使用して、「Authorizeのみの」サービスを提供できますが、リクエストに同じRADIUSサーバー（つまり、RADIUS状態属性）を使用した以前の成功した認証からの「Cookie」が含まれている場合にのみです。
The following RADIUS attributes are used to limit the extent of a secure transport session carrying SNMP traffic, in conjunction with an SNMP Transport Model:
SNMP輸送モデルと併せて、SNMPトラフィックを運ぶ安全なトランスポートセッションの範囲を制限するために、次の半径属性を使用してください。
1. Session-Timeout
1. セッションタイムアウト
2. Inactivity-Timeout.
2. 非アクティブタイムアウト。
Refer to [RFC2865] for a detailed description of these attributes. The Session-Timeout Attribute indicates the maximum number of seconds that a session may exist before it is unconditionally disconnected. The Inactivity-Timeout Attribute indicates the maximum number of seconds that a transport session may exist without any protocol activity (messages sent or received) before the session is disconnected. These timeouts are enforced by the NAS.
これらの属性の詳細な説明については、[RFC2865]を参照してください。セッション時間アウト属性は、セッションが無条件に切断される前に存在する可能性のある秒数を示します。非アクティブタイムアウト属性は、セッションが切断される前にプロトコルアクティビティ（送信されたメッセージまたは受信）なしで輸送セッションが存在する可能性がある最大秒数を示します。これらのタイムアウトはNASによって実施されます。
Table 1 provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
表1に、どの種類のパケットとどのような量の属性が見つかるかについてのガイドを示します。
Access-
Request Accept Reject Challenge # Attribute
---------------------------------------------------------------------
0-1 0 0 0 1 User-Name [RFC2865]
0-1 0 0 0 2 User-Password [RFC2865]
0-1 * 0 0 0 4 NAS-IP-Address [RFC2865]
0-1 * 0 0 0 95 NAS-IPv6-Address [RFC3162]
0-1 * 0 0 0 32 NAS-Identifier [RFC2865]
0-1 0-1 0 0 6 Service-Type [RFC2865]
0-1 0-1 0 0-1 24 State [RFC2865]
0 0-1 0 0 27 Session-Timeout [RFC2865]
0 0-1 0 0 28 Idle-Timeout [RFC2865]
0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579]
0-1 0-1 0 0 133 Framed-Management-Protocol
[RFC5607]
0-1 0-1 0 0 134 Management-Transport-Protection
[RFC5607]
Table 1
表1
Table 2 defines the meaning of the entries in Table 1.
表2は、表1のエントリの意味を定義しています。
0 This attribute MUST NOT be present in a packet. 0+ Zero or more instances of this attribute MAY be present in a packet. 0-1 Zero or one instance of this attribute MAY be present in a packet. 1 Exactly one instance of this attribute MUST be present in a packet. * Only one of these attribute options SHOULD be included.
0この属性をパケットに存在してはなりません。この属性の0ゼロ以上のインスタンスがパケットに存在する場合があります。この属性の0-1インスタンスまたは1つのインスタンスがパケットに存在する場合があります。1この属性の1つのインスタンスがパケットに存在する必要があります。*これらの属性オプションのいずれかを含める必要があります。
Table 2
表2
SSH integration with RADIUS traditionally uses usernames and passwords (with the User-Password Attribute), but other secure transports could use other authentication mechanisms, and would include RADIUS authentication attributes appropriate for that mechanism instead of User-Password.
RADIUSとのSSH統合は従来、ユーザー名とパスワード（ユーザーパスワード属性を使用）を使用していますが、他の安全なトランスポートは他の認証メカニズムを使用でき、ユーザーパスワードの代わりにそのメカニズムに適したRADIUS認証属性を含めることができます。
This document does not describe the usage of RADIUS Accounting or Dynamic RADIUS Re-Authorization. Such RADIUS usages are not currently envisioned for SNMP, and are beyond the scope of this document.
このドキュメントでは、半径の会計または動的半径の再承認の使用については説明していません。このような半径使用は現在、SNMPについては想定されておらず、このドキュメントの範囲を超えています。
This specification describes the use of RADIUS for purposes of authentication and authorization. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607].
この仕様では、認証と承認の目的での半径の使用について説明します。このアプリケーションの脅威とセキュリティの問題は、[RFC3579]および[RFC3580]で説明されています。ローミングで発生したセキュリティの問題は、[RFC2607]で説明されています。
Additional security considerations for use of SNMP with secure Transport Models [RFC5590] and the Transport Security Model [RFC5591] are found in the "Security Considerations" sections of the respective documents.
安全な輸送モデル[RFC5590]および輸送セキュリティモデル[RFC5591]を使用してSNMPを使用するための追加のセキュリティ上の考慮事項は、それぞれの文書の「セキュリティ上の考慮事項」セクションにあります。
If the SNMPv1 or SNMPv2c Security Model is used, then securityName comes from the community name, as per RFC 3584. If the User-based Security Model is selected, then securityName is determined using USM. This may not be what is expected when using an SNMP secure Transport Model with an external authentication service, such as RADIUS.
SNMPV1またはSNMPV2Cセキュリティモデルを使用する場合、RFC 3584によると、SecurityNameがコミュニティ名から来ます。ユーザーベースのセキュリティモデルが選択されている場合、SecurityNameはUSMを使用して決定されます。これは、RADIUSなどの外部認証サービスを使用してSNMPセキュアトランスポートモデルを使用する場合に予想されるものではない場合があります。
Simultaneously using a secure transport with RADIUS authentication and authorization, and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. See the "Coexistence, Security Parameters, and Access Control" section of [RFC5590].
同時に、RADIUS認証と承認を伴う安全なトランスポートを使用し、SNMPV1またはSNMPV2CまたはUSMセキュリティモデルを推奨しません。[RFC5590]の「共存、セキュリティパラメーター、およびアクセス制御」セクションを参照してください。
There are good reasons to provision USM access to supplement AAA-based access, however. When the network is under duress, or the AAA-service is unreachable, for any reason, it is important to have access credentials stored in the local configuration data-store of the managed entity. USM credentials are a likely way to fulfill this requirement. This is analogous to configuring a local "root" password in the "/etc/passwd" file of a UNIX workstation, to be used as a backup means of login, for times when the Network Information Service (NIS) authentication service is unreachable.
ただし、AAAベースのアクセスをサプリメントするためにUSMアクセスを提供する正当な理由があります。ネットワークが強迫下にある場合、またはAAAサービスが到達できない場合、何らかの理由で、マネージドエンティティのローカル構成データストアに保存されている資格情報にアクセスすることが重要です。USM資格情報は、この要件を満たす可能性のある方法です。これは、Network Information Service（NIS）認証サービスが到達不可能な場合に、ログインのバックアップ手段として使用するUNIXワークステーションの「/etc/passwd」ファイルにローカル「ルート」パスワードを構成することに類似しています。
The Message-Authenticator (80) Attribute [RFC3579] SHOULD be used with RADIUS messages that are described in this memo. This is useful because the Message-Authenticator Attribute is the best available mechanism in RADIUS as it stands today to provide tamper-evident integrity protection of the service provisioning attributes in an Access-Accept packet. It is slightly less important for Access-Request packets, although it may be desirable to protect any "hint" attributes contained in those messages. This protection mitigates the fact that RADIUS messages are not encrypted and that attributes could be added, deleted or modified by an adversary in a position to intercept the packet.
Message-authenticator（80）属性[RFC3579]は、このメモで説明されているRADIUSメッセージで使用する必要があります。これは、メッセージと認識者の属性が、アクセスacceptパケットでのサービスプロビジョニング属性の改ざんされた整合性の保護を提供するために、今日のradiusで利用可能な最良のメカニズムであるため有用です。Access-Requestパケットにとっては少し重要ではありませんが、これらのメッセージに含まれる「ヒント」属性を保護することが望ましい場合があります。この保護は、RADIUSメッセージが暗号化されておらず、パケットを傍受する立場の敵によって属性を追加、削除、または変更できるという事実を軽減します。
The authors would like to acknowledge the contributions of David Harrington and Juergen Schoenwaelder for numerous helpful discussions in this space, and Wes Hardaker for his thoughtful review comments.
著者は、この分野での多くの有益な議論のために、デビッド・ハリントンとジュエルゲン・シェーンワエルダーの貢献と、彼の思慮深いレビューコメントのためにウェス・ハーデイカーの貢献を認めたいと考えています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080] Nelson、D。およびA. Dekok、「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）実装の問題と提案された修正」、RFC 5080、2007年12月。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590] Harrington、D。およびJ. Schoenwaelder、「Simple Network Management Protocol（SNMP）の輸送サブシステム」、RFC 5590、2009年6月。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591] Harrington、D。およびW. Hardaker、「Simple Network Management Protocol（SNMP）の輸送セキュリティモデル」、RFC 5591、2009年6月。
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009.
[RFC5607] Nelson、D。およびG. Weber、「ネットワークアクセスサーバー（NAS）管理のためのリモート認証ダイヤルインユーザーサービス（RADIUS）認証」、RFC 5607、2009年7月。
[PAM] Samar, V. and R. Schemers, "UNIFIED LOGIN WITH PLUGGABLE AUTHENTICATION MODULES (PAM)", Open Group RFC 86.0, October 1995, <http://www.opengroup.org/rfc/mirror-rfc/rfc86.0.txt>.
[Pam] Samar、V。およびR. Schemers、「Pluggable認証モジュール（PAM）による統一ログイン（PAM）」、Open Group RFC 86.0、1995年10月、<http://www.opengroup.org/rfc/mirror-rfc/rfc866.0.txt>。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B。およびJ. Vollbrecht、「ローミングにおけるプロキシチェーンと政策の実施」、RFC 2607、1999年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon、P.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、2003年9月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）認証プロトコル」、RFC 4252、2006年1月。
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
[RFC5592] Harrington、D.、Salowey、J。、およびW. Hardaker、「Secure Shell Transport Model for Simple Network Management Protocol（SNMP）」、RFC 5592、2009年6月。
Authors' Addresses
著者のアドレス
Kaushik Narayan Cisco Systems, Inc. 10 West Tasman Drive San Jose, CA 95134 USA
Kaushik Narayan Cisco Systems、Inc。10 West Tasman Drive San Jose、CA 95134 USA
Phone: +1.408.526.8168
EMail: kaushik_narayan@yahoo.com
David Nelson Elbrys Networks, Inc. 282 Corporate Drive Portsmouth, NH 03801 USA
David Nelson Elbrys Networks、Inc。282 Corporate Drive Portsmouth、NH 03801 USA
Phone: +1.603.570.2636
EMail: dnelson@elbrysnetworks.com