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
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.
このメモは、簡易ネットワーク管理プロトコル（SNMP）とリモート認証ダイヤルインユーザーサービス（RADIUS）認証および承認サービスの利用ユーザーを認証し、セキュアなトランスポートセッションの作成を許可する安全な輸送モデルを説明しています。このメモの推奨事項は、一般的に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.
著作権（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として、英語以外の言語に翻訳します。
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.
このメモは、ユーザーを認証し、セキュアなトランスポートセッションの作成を許可するために簡易ネットワーク管理プロトコル（SNMP）は、安全な輸送モデルによるリモート認証ダイヤルインユーザーサービス（RADIUS）認証および承認サービスの使用を記載しています。このメモの推奨事項は、一般的に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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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を使用して、ネットワークデバイス、管理エンティティと通信することを示しています。ネットワークデバイスは、ネットワーク管理アプリケーション（またはそのクレデンシャルアプリケーションが提供するユーザ）を認証し、デバイス管理の目的のためにSNMPを介したアクセスに関連する認証情報を取得するためにRADIUSサーバと通信するためにRADIUSを使用します。その他のセキュアなトランスポートプロトコルの代わりに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プロトコルは、要求 - 応答メカニズムとして、最も単純なレベルで、動作します。 RADIUSクライアントは、NAS内、どのクライアント株式の資格情報を使用して、RADIUSサーバにRADIUS Access-Requestメッセージを送信することによって、トランザクションを開始します。 RADIUSサーバはAccess-Acceptメッセージまたはアクセス拒否メッセージのいずれかで応答します。
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メッセージを返すことによって、認証の成功を示しています。アクセス拒否のメッセージが認証失敗を示しています。
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.
アクセス受諾メッセージは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サーバは、多くの場合、異なるユースケースの多様性をカバーし、企業全体または組織全体に配備されています。このような展開では、すべてのNASおよびすべてのユーザは、RADIUSサーバの共通プールによってサービスされています。多くの配備で、RADIUSサーバは、異なる機能を備えたNASの多くの異なる種類、およびインタフェース、サービス、およびプロトコルサポートの異なる種類からの要求を処理します。
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クライアント）「ヒント」を含むようにNASとタイプを記述する、RADIUS Access-Requestメッセージの属性サービスの要求されています。
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輸送モデルで使用することができますいくつかのセキュアなトランスポートプロトコルには、いくつかの認証方法をサポートする認証プロトコルを定義しています。例えば、セキュア・シェル（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サーバの実装には、多くの場合、などRADIUS、TACACS +（ターミナルアクセスコントローラアクセス制御システムプラス）、ケルベロス、などパスワードベースのネットワーク認証メカニズムと統合するために、このようなLinuxおよびSolarisなどのオペレーティングシステムが提供するプラグイン可能な認証モジュール[PAM]インターフェースを使用します。
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サービスから取得した認証情報を利用する方法を指定しないでください。多くの場合、ユーザ認証は、ユーザーにサービスを提供開始するために、安全なトランスポートサーバーを引き起こすのに十分です。このような状況でのアクセス制御は、セキュアトランスポートサーバーのセッションが接続されているアプリケーションによって供給されています。アプリケーションは、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クライアントとの安全なトランスポートプロトコルの統合の詳細を指定しません。しかし、RADIUSで使用するために考慮することができるようなプロトコルの選択を制限する枠管理プロトコルとセキュアトランスポートプロトコルの正しい適用のための機能要件があります。 RADIUSので、ユーザー資格情報は、安全なトランスポート・プロトコル・サーバからのRADIUSクライアントによって得られる、またはSNMPエンジン、セキュアトランスポートプロトコル、およびNASでの実装に直接いくつかのケースでは、と互換性のある資格情報の形式をサポートしなければなりませんRADIUSによってサポートされている認証方法。
RADIUS currently supports the following user authentication methods, although others may be added in the future:
他の人が将来的に添加してもよいが、RADIUSは現在、次のユーザ認証方式をサポートしています。
o Password - RFC 2865
Oパスワード - RFC 2865
o CHAP (Challenge Handshake Authentication Protocol) - RFC 2865
入出力CHAP（チャレンジハンドシェイク認証プロトコル） - RFC 2865
o ARAP (Apple Remote Access Protocol) - RFC 2869
OのARAP（アップルリモートアクセスプロトコル） - RFC 2869
o EAP (Extensible Authentication Protocol) - RFC 2869, RFC 3579
RFC 2869、RFC 3579 - EAP（拡張認証プロトコル）O-
o HTTP Digest - RFC 5090
RFC 5090 - HTTPダイジェストO
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
SNMP [RFC5590]のためのトランスポート・サブシステムは、SNMP通信を保護するために使用される、SNMPのためのトランスポート層セキュリティ（TLS）を提供するようSSHおよびTLSなどのプロトコルを可能にするメカニズムを定義しています。交通サブシステムは、複数のセキュアなトランスポートプロトコルのための輸送モデルのモジュラー定義することができます。輸送モデルは、ユーザ認証サービスのための基盤となる安全な輸送に依存しています。輸送モデル（TM）は、それがtmStateReferenceに格納モデルに依存しない校長に認証されたIDをマッピングします。選択されたセキュリティモデルは、トランスポート・セキュリティモデル（TSM）である場合には、予想される動作は、によって設定されるセキュリティ名のためであります
TSM from the authenticated principal information stored in the tmStateReference by the TM.
TMによってtmStateReferenceに記憶された認証された主情報から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、ケルベロス、セキュアシェル輸送モデル[RFC5592]などの様々な外部認証および認可サービスとの統合を介してチャネル認証をサポートする安全なトランスポートチャネルを提供するSecure Shellプロトコルの使用を定義します輸送モデルの基礎として。
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を介して管理アクセスのRADIUSをサポートするための2つの使用例があります。これらは、（a）はサービス認可および（b）は、アクセス制御、認可されています。 RADIUSは、ほとんど常に認可の前提条件として、ユーザー認証を必要とし、これらの2つの使用例ごとに、ユーザ認証フェーズがあります。第2の使用ケースは、現在の研究の主題であり、この文書の範囲を超えつつ、第1のユースケースは、このメモで詳細に説明されています。このドキュメントでは、RADIUS属性とメッセージを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プロビジョニングサービス認証をサポートしたい場合、我々は、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プロビジョニングサービス認可が重要であることの一つの理由は、（の小さい部分のみが管理対象エンティティの管理インタフェースにアクセスすることを許可することができる、多くの展開で、RADIUSサーバのバックエンド認証データベースは、ユーザーの多くのクラスのための資格情報が含まれていることですSNMP経由のNAS）。これは、管理対象エンティティへのアクセスを許可されているすべてのプリンシパルは、ローカルコンフィギュレーション・データ・ストアに入っている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サーバに通知するために、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に準拠して、NASのは、Access-Acceptメッセージ内のこのようなサービスタイプとして暗黙的に必須属性を、施行しなければなりません。 NASは、彼らが拒否アクセスであるかのように規定サポートされていないサービスにしようとし、接続許可メッセージを扱わなければなりません。彼らはサポートされていないサービスをプロビジョニングしているかのようにNASのは、未知の属性を扱うべきです。詳細については、[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）任意のRADIUS Access-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の使用方法については、RADIUSサーバ一般的に提供管理アクセスサービス、SSHは、多くの場合、NAS、例えば、ホストシステムのコマンドラインシェルにアクセスするために使用されます。 RFC 2865には、管理アクセスサービスの2種類の属性、NASのコマンドラインインタフェース（CLI）への特権アクセス用と非特権CLIアクセスのための1つを定義します。これらの伝統的な管理アクセスサービスは、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サーバは、セキュアなトランスポート上のSNMPアクセスを指定するには、RADIUSサービスのプロビジョニング属性を使用しなければなりません。このような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.
このセクションで説明するように、それらがRADIUSアクセス - 受け入れ、メッセージをセッションを作成することができるかどうかを決定するために、それらはRADIUSのサービスプロビジョニングの決定を施行しなければならないで存在するときに、この仕様に準拠のNASは、属性をプロビジョニング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:
「ヒント」属性はRADIUSサーバへの安全な輸送（即ち、authPrivの）上にSNMPを使用することを通知するAccess-Requestメッセージに含まれる次のRADIUS属性を使用する必要があります。
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メッセージをアクセス - 受け入れ：
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):
次のRADIUS属性は、必要に応じて（即ち、authNoPriv）保護なしSNMPの使用を許可するために、使用しなければなりません。
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は、「認可のみ」サービスを提供するために使用することができますが、要求は同じRADIUSサーバとの前回の認証が成功（すなわち、RADIUS州属性）から「クッキー」が含まれている場合にのみ。
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:
次のRADIUS属性は、SNMP輸送モデルと連動して、SNMPトラフィックを運ぶの安全な輸送セッションの範囲を制限するために使用されています。
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.
このドキュメントでは、RADIUSアカウンティングまたはダイナミックRADIUS再認証の使用法を説明していません。このようなRADIUSの使用法は、現在、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].
この仕様は、認証と承認の目的のためにRADIUSを使用することを記述しています。このアプリケーションの脅威とセキュリティ問題は[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のセキュリティモデルを使用する場合、セキュリティ名は、ユーザベースセキュリティモデルが選択されている場合は、セキュリティ名はUSMを使用して決定されたRFC 3584で規定に従って、コミュニティ名に由来しています。これは、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の資格情報は、この要件を満たすために可能性の高い方法です。これは、ネットワーク情報サービス（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.
メッセージ認証（80）項目[RFC3579]このメモに記載されているRADIUSメッセージで使用されてください。 Message-Authenticatorアトリビュートは、それがアクセス-受け入れパケット内のサービスプロビジョニングの不正開封防止完全性保護の属性を提供するために、今日のスタンドとしてRADIUSで利用可能な最善のメカニズムがあるので、これは便利です。これらのメッセージに含まれる任意の「ヒント」の属性を保護することが望ましいが、それは、アクセス要求パケットのためのわずかに少ないことが重要です。この保護は、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.
作者は彼の思いやりのレビューコメントのために、このスペースでは、多くの有益な議論のためのデビッド・ハリントンとユルゲンSchoenwaelderの貢献に感謝し、そしてウェスHardakerでしょう。
[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月。
[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.シンプソン、。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]ネルソン、D.とA. DeKok、RFC 5080、2007年12月 "ユーザーサービス（RADIUS）の実装の問題と推奨修正に共通のリモート認証ダイヤル"。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590]ハリントン、D.とJ. Schoenwaelder、RFC 5590、2009年6月 "簡易ネットワーク管理プロトコル（SNMP）のための輸送サブシステム"。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591]ハリントン、D.およびW. Hardaker、 "簡易ネットワーク管理プロトコルのためのトランスポート・セキュリティモデル（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]ネルソン、D.とG.ウェーバー、 "リモート認証ダイヤルインユーザーサービス（RADIUS）ネットワークアクセスサーバ（NAS）管理のための許可"、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]サマール、V.およびR. Schemers、 "プラグイン可能な認証モジュール（PAM）と一体化LOGIN"、Open GroupのRFC 86.0、1995年10月、<http://www.opengroup.org/rfc/mirror-rfc/rfc86 .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.、ゾルン、G.、およびD.ミットン、 "RADIUSと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]ハリントン、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.カルフーン、 "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.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "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、 "セキュアシェル（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]ハリントン、D.、Salowey、J.、およびW. Hardakerは、RFC 5592、2009年6月 "簡易ネットワーク管理プロトコル（SNMP）用シェル輸送モデルを固定します"。
Authors' Addresses
著者のアドレス
Kaushik Narayan Cisco Systems, Inc. 10 West Tasman Drive San Jose, CA 95134 USA
Kaushikによるナラヤンシスコシステムズ社10西タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1.408.526.8168 EMail: kaushik_narayan@yahoo.com
電話：+1.408.526.8168電子メール：kaushik_narayan@yahoo.com
David Nelson Elbrys Networks, Inc. 282 Corporate Drive Portsmouth, NH 03801 USA
デビッド・ネルソンElbrysネットワークス株式会社282コーポレート・ドライブポーツマス、ニューハンプシャー03801 USA
Phone: +1.603.570.2636 EMail: dnelson@elbrysnetworks.com
電話：+1.603.570.2636電子メール：dnelson@elbrysnetworks.com