Network Working Group M. Eisler
Request for Comments: 2623 Sun Microsystems, Inc.
Category: Standards Track June 1999
NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
NFSバージョン2およびバージョン3のセキュリティ問題とRPCSEC_GSSのNFSプロトコルの使用とKerberos V5
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) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations.
この覚書は、NFSプロトコル（バージョン2およびバージョン3のみ）を含むさまざまなセキュリティ上の問題を明確にして、NFSプロトコルのバージョン2とバージョン3は、RPCSEC_GSSセキュリティ風味プロトコルとKerberos V5を使用する方法について説明します。人々は互換性のある実装を書くことができるように、このメモが設けられています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of RPC Security Architecture . . . . . . . . . . . 3
2. Overview of NFS Security . . . . . . . . . . . . . . . . . . . 3
2.1. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 4
2.2. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 4
2.2.1. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5
2.2.3. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Authentication for NFS Procedures . . . . . . . . . . . . . 6
2.3.1. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. NFS Procedures Used at Mount Time . . . . . . . . . . . . 6
2.4. Binding Security Flavors to Exports . . . . . . . . . . . . 7
2.5. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . 7
2.6. Host-based Access Control . . . . . . . . . . . . . . . . . 8
2.7. Security Flavor Negotiation . . . . . . . . . . . . . . . . 8
2.8. Registering Flavors . . . . . . . . . . . . . . . . . . . . 9
3. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . 9
3.1. Server Principal . . . . . . . . . . . . . . . . . . . . . 9
3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . 10
3.4. Registering Pseudo Flavors and Mappings . . . . . . . . . 11
4. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . 11
4.1. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . 12
4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor
Registration Entry . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations [RFC2434] . . . . . . . . . . . . . . . 14
6.1. Pseudo Flavor Number . . . . . . . . . . . . . . . . . . . 14
6.2. String Name of Pseudo Flavor . . . . . . . . . . . . . . . 15
6.2.1. Name Space Size . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Delegation . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. Outside Review . . . . . . . . . . . . . . . . . . . . . 15
6.3. GSS-API Mechanism OID . . . . . . . . . . . . . . . . . . 15
6.4. GSS-API Mechanism Algorithm Values . . . . . . . . . . . . 15
6.5. RPCSEC_GSS Security Service . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 19
The NFS protocol provides transparent remote access to shared file systems across networks. The NFS protocol is designed to be machine, operating system, network architecture, and security mechanism, and transport protocol independent. This independence is achieved through the use of ONC Remote Procedure Call (RPC) primitives built on top of an eXternal Data Representation (XDR). NFS protocol Version 2 is specified in the Network File System Protocol Specification [RFC1094]. A description of the initial implementation can be found in [Sandberg]. NFS protocol Version 3 is specified in the NFS Version 3 Protocol Specification [RFC1813]. A description of some initial implementations can be found in [Pawlowski].
NFSプロトコルは、ネットワークを介した共有ファイルシステムへの透過的なリモートアクセスを提供します。 NFSプロトコルは、マシン、オペレーティングシステム、ネットワークアーキテクチャ、およびセキュリティメカニズム、およびトランスポート・プロトコルに依存しないように設計されています。この独立性は、ONCリモートプロシージャコール（RPC）外部データ表現（XDR）の上に構築されたプリミティブを使用することによって達成されます。 NFSプロトコルのバージョン2は、ネットワークファイルシステムプロトコル仕様[RFC1094]で指定されています。初期の実装の説明は、[サンドバーグ]に見出すことができます。 NFSプロトコルバージョン3は、NFSバージョン3プロトコル仕様[RFC1813]で指定されています。いくつかの初期の実装の説明は[ポロウスキー]に見出すことができます。
For the remainder of this document, whenever it refers to the NFS protocol, it means NFS Version 2 and Version 3, unless otherwise stated.
それはNFSプロトコルを意味するたびに、特に断らない限り、本明細書の残りの部分については、それは、NFSバージョン2及びバージョン3を意味します。
The RPC protocol is specified in the Remote Procedure Call Protocol Specification Version 2 [RFC1831]. The XDR protocol is specified in External Data Representation Standard [RFC1832].
RPCプロトコルは、リモートプロシージャコールプロトコル仕様バージョン2 [RFC1831]で指定されています。 XDRプロトコルは、外部データ表現規格[RFC1832]で指定されています。
A new RPC security flavor, RPCSEC_GSS, has been specified [RFC2203]. This new flavor allows application protocols built on top of RPC to access security mechanisms that adhere to the GSS-API specification
新しいRPCセキュリティ風味、RPCSEC_GSSは、[RFC2203]を指定されています。この新しい味は、RPCの上に構築されたアプリケーションプロトコルは、GSS-API仕様に準拠したセキュリティ・メカニズムにアクセスすることができます
[RFC2078].
[RFC2078]。
The purpose of this document is to clarify NFS security issues and to specify how the NFS protocol uses RPCSEC_GSS. This document will also describe how NFS works over Kerberos V5, via RPCSEC_GSS.
このドキュメントの目的は、NFSのセキュリティ上の問題を明らかにし、NFSプロトコルはRPCSEC_GSSを使用する方法を指定することです。また、このドキュメントでは、RPCSEC_GSSを経由して、NFSは、Kerberos V5上でどのように動作するかを説明します。
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]に記載されているように解釈されます。
The RPC protocol includes a slot for security parameters (referred to as an authentication flavor in the RPC specification [RFC1831]) on every call. The contents of the security parameters are determined by the type of authentication used by the server and client. A server may support several different flavors of authentication at once. Some of the better known flavors are summarized as follows:
RPCプロトコルは、すべての呼び出しに（RPC仕様[RFC1831]での認証フレーバーと呼ばれる）、セキュリティパラメータのスロットを含みます。セキュリティパラメータの内容は、サーバーとクライアントが使用する認証の種類によって決定されます。サーバは一度の認証のいくつかの異なる味をサポートすることができます。次のように良く知られている味の一部が要約されています。
* The AUTH_NONE flavor provides null authentication, that is, no authentication information is passed.
* AUTH_NONEの風味がnull認証を提供する、つまり、何の認証情報が渡されません。
* The AUTH_SYS flavor provides a UNIX-style user identifier, group identifier, and an array of supplemental group identifiers with each call.
* AUTH_SYSフレーバーはUNIXスタイルのユーザ識別子、グループ識別子、及び各呼び出しで補足グループ識別子のアレイを提供します。
* The AUTH_DH (sometimes referred to as AUTH_DES [RFC1057]) flavor provides DES-encrypted authentication parameters based on a network-wide string name, with session keys exchanged via the Diffie-Hellman public key scheme.
セッション鍵は、ディフィー - ヘルマン公開鍵方式を介して交換して* AUTH_DH（時々AUTH_DES [RFC1057]と称する）フレーバーは、ネットワーク全体の文字列名に基づいて、DES暗号化認証パラメータを提供します。
* The AUTH_KERB4 flavor provides DES encrypted authentication parameters based on a network-wide string name (the name is a Kerberos Version 4 principal identifier) with session keys exchanged via Kerberos Version 4 secret keys.
セッションキーは、Kerberosバージョン4つの秘密鍵を介して交換して* AUTH_KERB4味は（名前はKerberosバージョン4主要な識別子である）ネットワーク全体の文字列名に基づいてDES暗号化された認証パラメータを提供します。
The NFS protocol is not limited to the above list of security flavors.
NFSプロトコルは、セキュリティ風味の上記のリストに限定されるものではありません。
Many NFS servers will require that the client send its NFS requests from UDP or TCP source ports with values < 1024. The theory is that binding to ports < 1024 is a privileged operation on the client, and so the client is enforcing file access permissions on its end. The theory breaks down because:
多くのNFSサーバは、理論は、ポート<1024への結合は、クライアント上の特権操作であり、そのクライアントがファイルアクセス権限を執行していることである1024 <クライアントが値でUDPまたはTCPの送信元ポートからのNFS要求を送信することを要求しますその終わり。理論があるため破壊します：
* On many operating systems, there are no constraints on what port what user can bind to.
*多くのオペレーティングシステムでは、どのようなユーザーにバインドすることができますどのようなポートには何の制約はありません。
* Just because the client host enforces the privilege on binding to ports < 1024 does not necessarily mean that a non-privileged user cannot gain access to the port binding privilege. For example with a single-user desk-top host running a UNIX operating system, the user may have knowledge of the root user password. And even if he does not have that knowledge, with physical access to the desk-top machine, root privileges are trivially acquired.
クライアントホストがポートへの結合に対する権限を強制するという理由だけ* <1024は、必ずしも非特権ユーザがポートバインディング特権へのアクセスを得ることができないという意味ではありません。 UNIXオペレーティングシステムを実行しているシングルユーザーのデスク・トップ・ホストと例えば、ユーザがrootユーザのパスワードの知識を有することができます。そして彼はその知識を持っていなくても、デスクトップマシンに物理的にアクセスして、root権限が自明取得されています。
In some rare cases, when the system administrator can be certain that the clients are trusted and under control (in particular, protected from physical attack), relying of trusted ports MAY be a reliable form of security.
まれに、ときに、システム管理者は、クライアントがセキュリティの信頼性の高い形かもしれ信頼されたポートの頼って、（特に、物理的な攻撃から保護）、信頼と制御下にあることを確信することができます。
In most cases, the use of privileged ports and port monitoring for security is at best an inconvenience to the attacker and SHOULD NOT be depended on.
ほとんどの場合、セキュリティのための特権ポートとポートの監視の使用は、せいぜい、攻撃者に不便で、頼りれるべきではありません。
To maximize interoperability:
相互運用性を最大化するには：
* NFS clients SHOULD attempt to bind to ports < 1024. In some cases, if they fail to bind (because either the user does not have the privilege to do so, or there is no free port < 1024), the NFS client MAY wish to attempt the NFS operation over a port >= 1024.
*それらが結合に失敗した場合（ユーザーのどちらかがそうする権限を持っていないため、または空きポート<1024はありません）NFSクライアントは、<ポートにバインドするためにいくつかのケースでは1024を試みるべきで、NFSクライアントが望むかもしれません> = 1024ポート経由のNFS操作を試みます。
* NFS servers that implement port monitoring SHOULD provide a method to turn it off.
*ポート監視を実装するNFSサーバーでは、それをオフにする方法を提供する必要があります。
* Whether port monitoring is enabled or not, NFS servers SHOULD NOT reject NFS requests to the NULL procedure (procedure number 0). See subsection 2.3.1, "NULL procedure" for a complete explanation.
*ポート監視が有効かどうか、NFSサーバは、NULL手続き（プロシージャ番号0）にNFS要求を拒否すべきではありません。完全な説明については、サブセクション2.3.1、「NULLの手順」を参照してください。
The port monitoring issues and recommendations apply to the MOUNT protocol as well.
ポート監視の問題および推奨事項は、同様MOUNTプロトコルに適用されます。
The NFS server checks permissions by taking the credentials from the RPC security information in each remote request. Each flavor packages credentials differently.
NFSサーバは、各リモート要求でRPCセキュリティ情報から資格証明書を取ることによって権限をチェックします。それぞれ異なるフレーバーパッケージの資格情報。
Using the AUTH_SYS flavor of authentication, the server gets the client's effective user identifier, effective group identifier and supplemental group identifiers on each call, and uses them to check access. Using user identifiers and group identifiers implies that the client and server either share the same identifier name space or do local user and group identifier mapping.
認証のAUTH_SYS風味を使用して、サーバーは呼び出しごとに、クライアントの実効ユーザーID、実効グループIDと補足グループIDを取得し、アクセスをチェックするためにそれらを使用しています。ユーザ識別子とグループ識別子を使用することで、クライアントとサーバのどちらかが同じ識別子の名前空間を共有したり、ローカルユーザーとグループ識別子のマッピングを行うことを意味します。
For those sites that do not implement a consistent user identifier and group identifier space, NFS implementations must agree on the mapping of user and group identifiers between NFS clients and servers.
一貫したユーザ識別子とグループ識別子空間を実装していないこれらのサイトについては、NFSの実装では、NFSクライアントとサーバの間でユーザーとグループ識別子のマッピングに同意しなければなりません。
The AUTH_DH and AUTH_KERB4 styles of security are based on a network-wide name. They provide greater security through the use of DES encryption and public keys in the case of AUTH_DH, and DES encryption and Kerberos secret keys (and tickets) in the AUTH_KERB4 case. Again, the server and client must agree on the identity of a particular name on the network, but the name to identity mapping is more operating system independent than the user identifier and group identifier mapping in AUTH_SYS. Also, because the authentication parameters are encrypted, a malicious user must know another user's network password or private key to masquerade as that user. Similarly, the server returns a verifier that is also encrypted so that masquerading as a server requires knowing a network password.
セキュリティのAUTH_DHとAUTH_KERB4スタイルは、ネットワーク全体の名前に基づいています。彼らはAUTH_KERB4ケースにAUTH_DHの場合、DESの暗号化と公開鍵を使用してより高いセキュリティを提供し、DESの暗号化とKerberosの秘密鍵（チケット）。ここでも、サーバーとクライアントは、ネットワーク上の特定の名前のアイデンティティに同意する必要がありますが、アイデンティティへのマッピング名はAUTH_SYSにおけるユーザ識別子とグループ識別子マッピングよりも独立した多くのオペレーティングシステムです。認証パラメータが暗号化されるので、また、悪意のあるユーザーは、そのユーザーになりすましするために、別のユーザーのネットワークパスワードや秘密鍵を知っている必要があります。同様に、サーバは、サーバになりすまして、ネットワークパスワードを知る必要がようにも暗号化された検証を返します。
The RPCSEC_GSS style of security is based on a security-mechanism-specific principal name. GSS-API mechanisms provide security through the use of cryptography. The cryptographic protections are used in the construction of the credential on calls, and in the verifiers on replies. Optionally, cryptographic protections will be in the body of the calls and replies.
セキュリティのRPCSEC_GSSスタイルは、セキュリティ・メカニズム固有のプリンシパル名に基づいています。 GSS-APIメカニズムは、暗号化を使用してセキュリティを提供します。暗号保護が呼び出しで資格の建設で、と応答の検証に使用されています。必要に応じて、暗号化保護は通話と応答の本文になります。
Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS does not imply that the NFS protocol is limited to using those five flavors.
AUTH_NONE、AUTH_SYS、AUTH_DH、AUTH_KERB4、およびRPCSEC_GSSの議論はNFSプロトコルは、これら5種類の使用に限定されていることを意味するものではないことに注意してください。
The NULL procedure is typically used by NFS clients to determine if an NFS server is operating and responding to requests (in other words, to "ping" the NFS server). Some NFS servers require that a client using the NULL procedure:
NULL手順は、典型的には、NFSサーバが（「ピング」NFSサーバに、他の言葉で）動作し、リクエストに応答しているかどうかを決定するためにNFSクライアントによって使用されます。いくつかのNFSサーバーは、クライアントがNULLの手順を使用していることが必要です。
* send the request from TCP or UDP port < 1024. There does not seem to be any value in this because the NULL procedure is of very low overhead and certainly no more overhead than the cost of processing a NULL procedure and returning an authentication error. Moreover, by sending back an authentication error, the server has confirmed the information that the client was interested in: is the server operating?
* 1024 <TCPやUDPポートからのリクエストを送信するNULL手続きは非常に低いオーバーヘッドとNULL手続きを処理し、認証エラーを返すのコストよりも、確かにこれ以上のオーバーヘッドであるため、この内の任意の値があるように思えません。また、認証エラーを送り返すことで、サーバーは、クライアントがに興味があったとの情報を確認しました：サーバが動作していますか？
* be authenticated with a flavor stronger than AUTH_SYS. This is a problem because the RPCSEC_GSS protocol uses NULL for control messages.
* AUTH_SYSよりも強い香りで認証します。 RPCSEC_GSSプロトコルが制御メッセージのためのNULL使用していますので、これは問題です。
NFS servers SHOULD:
NFSサーバーの必要があります。
* accept the NULL procedure ping over AUTH_NONE and AUTH_SYS, in addition to other RPC security flavors, and
*他のRPCセキュリティ風味に加えて、AUTH_NONEおよびAUTH_SYSオーバーNULL手続きのpingを受け入れ、
* NOT require that the source port be < 1024 on a NULL procedure ping.
*送信元ポートは、NULL手続きのpingに1024 <されている必要はありませ。
Certain NFS procedures are used at the time the NFS client mounts a file system from the server. Some NFS server implementations will not require authentication for these NFS procedures. For NFS protocol Version 2, these procedures are GETATTR and STATFS. For Version 3, the procedure is FSINFO.
特定のNFS手順は、NFSクライアントがサーバーからファイルシステムをマウントする時に使用されています。いくつかのNFSサーバの実装は、これらのNFSの手続きのために認証を必要としません。 NFSプロトコルバージョン2の場合、これらの手順は、GETATTRとstatfsのです。バージョン3の場合は、手順がFSINFOです。
The reason for not requiring authentication is described as follows. When the NFS client mounts a NFS server's file system, the identity of the caller on the client is typically an administrative entity (in UNIX operating systems, this is usually the "root" user). It is often the case that, for unattended operation in concert with an automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS credentials for the administrative entity associated with an automounter are not available. If so, the NFS client will use AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount a file system. While an attacker could exploit this implementation artifact, the exposure is limited to gaining the attributes of a file or a file system's characteristics. This OPTIONAL trade off favors the opportunity for improved ease of use.
次のように認証を必要としない理由を説明します。 NFSクライアントがNFSサーバのファイルシステムをマウントすると、クライアント上で、発信者の身元は、（UNIXオペレーティング・システムでは、これは通常、「ルート」ユーザーです）一般的に行政法人です。これは、マウンタに関連する管理エンティティのマウンタ[キャラハン]、AUTH_DH、AUTH_KERB4、またはRPCSEC_GSS資格と協調して無人運転のために利用できないことが多い場合です。その場合、NFSクライアントは、ファイルシステムをマウントするために使用される初期NFS操作に対してAUTH_NONEかAUTH_SYSを使用します。攻撃者はこの実装成果物を利用することもできますが、露出は、ファイルやファイルシステムの特性の属性を得るに限定されています。このオプショントレードオフ使用の容易さを改善する機会を好みます。
NFS servers MAY export file systems with specific security flavors bound to the export. In the event a client uses a security flavor that is not the one of the flavors the file system was exported with, NFS server implementations MAY:
NFSサーバは、輸出にバインドされた特定のセキュリティ風味を使用してファイル・システムをエクスポートできます。イベントでは、クライアントは、ファイルシステムは、NFSサーバの実装がMAYでエクスポートされた味の一つではないセキュリティ風味を使用しています。
* reject the request with an error (either an NFS error or an RPC level authentication error), or
*エラー（NFSエラーまたはRPCレベル認証エラーのいずれか）を用いて要求を拒否し、又は
* allow the request, but map the user's credentials to a user other than the one the client intended. Typically the user that is the result of this mapping is a user with limited access on the system, such as user "nobody" on UNIX systems.
*要求を許可しますが、クライアントが意図したもの以外のユーザーにユーザーの資格情報をマッピングします。典型的には、このマッピングの結果であるユーザは、UNIXシステム上のユーザ「誰」などのシステム上の限られたアクセス権を持つユーザです。
If a client uses AUTH_NONE, the server's options are the same as the above, except that AUTH_NONE carries with it no user identity. In order to allow the request, on many operating systems the server will assign a user identity. Typically this assignment will be a user with limited access on the system, such as user "nobody" on UNIX systems.
クライアントがAUTH_NONEを使用している場合はそのAUTH_NONEがない、アイデンティティ、それを運ぶ以外、サーバーのオプションは、上記と同様です。リクエストを可能にするためには、多くのオペレーティングシステム上のサーバーは、ユーザーIDが割り当てられます。典型的には、この割り当ては、UNIXシステム上のユーザ「誰」などのシステム上の限られたアクセス権を持つユーザ、あろう。
The following passage is excerpted verbatim from RFC 1813, section 4.4 "Permission Issues" (except that "may" has been changed to "MAY"):
次の一節は、セクション4.4「権限の問題は、」（「MAY」に変更されている「かもしれ」ことを除いて）、RFC 1813からそのまま抜粋されています。
In most operating systems, a particular user (on UNIX, the uid 0) has access to all files, no matter what permission and ownership they have. This superuser permission MAY not be allowed on the server, since anyone who can become superuser on their client could gain access to all remote files. A UNIX server by default maps uid 0 to a distinguished value (UID_NOBODY), as well as mapping the groups list, before doing its access checking. A server implementation MAY provide a mechanism to change this mapping. This works except for NFS version 3 protocol root file systems (required for diskless NFS version 3 protocol client support), where superuser access cannot be avoided. Export options are used, on the server, to restrict the set of clients allowed superuser access.
ほとんどのオペレーティングシステムでは、（UNIX上で、UID 0）特定のユーザーには関係なく、彼らが持っているものの権限と所有権、すべてのファイルへのアクセス権を持っていません。彼らのクライアント上でスーパーユーザーになることができ、誰もがすべてのリモートファイルへのアクセスを得る可能性があるので、このスーパーユーザー権限は、サーバー上で許可されないことがあります。デフォルトのマップによるUNIXサーバは、そのアクセス検査を行う前に、グループのリストをマッピングするだけでなく、区別値（UID_NOBODY）に0をUIDです。サーバーの実装は、このマッピングを変更するためのメカニズムを提供することができます。これは、スーパーユーザーのアクセスを回避することはできません（ディスクレスNFSバージョン3プロトコルクライアントのサポートに必要な）NFSバージョン3プロトコルルートファイルシステムを除き、動作します。エクスポートオプションは、スーパーユーザのアクセスを許可するクライアントのセットを制限するために、サーバー上で、使用されています。
The issues identified as applying to NFS protocol Version 3 in the above passage also apply to Version 2.
上記通路にNFSプロトコルバージョン3に印加するように特定された問題は、また、第2版にも適用されます。
In some NFS server implementations, a host-based access control method is used whereby file systems can be exported to lists of clients. File systems may also be exported for read-only or read-write access. Several of these implementations will check access only at mount time, during the request for the file handle via the MOUNT protocol handshake. The lack of authorization checking during subsequent NFS requests has the following consequences:
ファイルシステムは、クライアントのリストにエクスポートすることができるいくつかのNFSサーバの実装では、ホストベースのアクセス制御方法が使用されています。ファイルシステムは、読み取り専用または読み書きアクセスのためにエクスポートすることができます。これらの実装のいくつかは、MOUNTプロトコルハンドシェイクを経由してファイルハンドルの要求時に、マウント時だけアクセスをチェックします。その後のNFS要求時に許可検査の欠如は、以下のような結果になります：
* NFS servers are not able to repudiate access to the file system by an NFS client after the client has mounted the file system.
* NFSサーバは、クライアントがファイルシステムをマウントした後、NFSクライアントによるファイルシステムへのアクセスを否認することができません。
* An attacker can circumvent the MOUNT server's access control to gain access to a file system that the attacker is not authorized for. The circumvention is accomplished by either stealing a file handle (usually by snooping the network traffic between an legitimate client and server) or guessing a file handle. For this attack to succeed, the attacker must still be able impersonate a user's credentials, which is simple for AUTH_SYS, but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS.
*攻撃者は、攻撃者がのために許可されていないファイルシステムへのアクセスを得るためにMOUNTサーバのアクセス制御を回避することができます。迂回は、ファイルハンドルを推測する（通常は、正当なクライアントとサーバ間のネットワークトラフィックをスヌーピングして）ファイルハンドルを盗むのいずれかによって達成されます。成功するためにこの攻撃では、攻撃者がまだAUTH_DH、AUTH_KERB4、およびRPCSEC_GSSのためAUTH_SYSのための単純である、ユーザーの資格情報を偽装ますが、難しいことができなければなりません。
* WebNFS clients that use the public file handle lookup [RFC2054] will not go through the MOUNT protocol to acquire initial file handle of the NFS file system. Enforcing access control via the MOUNT protocol is going to be a little use. Granted, some WebNFS server implementations cope with this by limiting the use of the public file handle to file systems exported to every client on the Internet.
公開ファイルハンドルのルックアップを使用* WebNFSのクライアント[RFC2054]はNFSファイルシステムの初期ファイルハンドルを取得するためにMOUNTプロトコルを介して行くことはありません。 MOUNTプロトコルを介してアクセス制御を強制することはほとんど使用になるだろう。確かに、いくつかのWebNFSのサーバの実装は、インターネット上のすべてのクライアントにエクスポートファイルシステムへの公開ファイルハンドルの使用を制限することにより、これに対処します。
Thus, NFS server implementations SHOULD check the client's authorization on each NFS request.
このように、NFSサーバの実装では、各NFS要求に、クライアントの許可を確認する必要があります。
Any application protocol that supports multiple styles of security will have the issue of negotiating the security method to be used. NFS Version 2 had no support for security flavor negotiation. It was up to the client to guess, or depend on prior knowledge. Often the prior knowledge would be available in the form of security options specified in a directory service used for the purpose of automounting.
セキュリティの複数のスタイルをサポートする任意のアプリケーションプロトコルを使用するセキュリティ方法を交渉の問題を持っています。 NFSバージョン2は、セキュリティ風味交渉のためのサポートがありませんでした。これは推測する、または事前の知識に依存するクライアント次第でした。多くの場合、事前の知識は、自動マウントの目的のために使用されるディレクトリ・サービスで指定されたセキュリティオプションの形で利用できるようになります。
The MOUNT Version 3 protocol, associated with NFS Version 3, solves the problem by having the response to the MNT procedure include a list of flavors in the MNT procedure. Note that because some NFS servers will export file systems to specific lists of clients, with different access (read-only versus read-write), and with different security flavors, it is possible a client might get back multiple security flavors in the list returned in the MNT response. The use of one flavor instead of another might imply read-only instead of read-write access, or perhaps some other degradation of access. For this reason, a NFS client SHOULD use the first flavor in the list that it supports, on the assumption that the best access is provided by the first flavor. NFS servers that support the ability to export file systems with multiple security flavors SHOULD either present the best accessing flavor first to the client, or leave the order under the control of the system administrator.
NFSバージョン3に関連付けられたMOUNTバージョン3プロトコルは、MNT手順に対する応答がMNT手順において味のリストを含んで有することによって問題を解決します。いくつかのNFSサーバは（読み取り専用読み書きに対して）異なるアクセスで、クライアントの特定のリストにファイル・システムをエクスポートし、異なるセキュリティ味で、それが可能であるクライアントが返されたリスト内の複数のセキュリティ風味を取り戻す可能性があるためということに注意してくださいMNT応答インチ代わりに、別の1種のフレーバーの使用は読み取り専用の代わりに、読み書きアクセス、またはアクセスのおそらくいくつかの他の劣化を意味するものではありかもしれません。このため、NFSクライアントは、最良のアクセスが最初の味で提供されていることを前提に、それがサポートしているリストの最初の味を使用すべきです。複数のセキュリティ風味を使用してファイルシステムをエクスポートする機能をサポートするNFSサーバは、クライアントに最初の最良のアクセスの風味を提示、またはシステム管理者の管理下に順番を残すべきであるのいずれか。
When one develops a new RPC security flavor, iana@iana.org MUST be contacted to get a unique flavor assignment. To simplify NFS client and server administration, having a simple ASCII string name for the flavor is useful. Currently, the following assignments exist:
1が新しいRPCセキュリティ風味を開発する場合、iana@iana.orgは独特の風味の割り当てを取得するために接触させなければなりません。 NFSクライアントとサーバの管理を簡素化するために、味のための単純なASCII文字列名を持つことは有用です。現在、以下の割り当てが存在します。
flavor string name
味の文字列名
AUTH_NONE none AUTH_SYS sys AUTH_DH dh AUTH_KERB4 krb4
AUTH_NONEなしAUTH_SYS SYS AUTH_DHのDH AUTH_KERB4のKRB4
A string name for a new flavor SHOULD be assigned. String name assignments can be registered by contacting iana@iana.org.
新しい味のための文字列名を割り当てる必要があります。文字列名の割り当てはiana@iana.org接触させることにより、登録することができます。
When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE names are of the form:
RPCSEC_GSSを使用する場合は、NFSサーバーがGSS_C_NT_HOSTBASED_SERVICE名のタイプを経由してGSS-API自体を特定しなければなりません。 GSS_C_NT_HOSTBASED_SERVICE名の形式は次のとおりです。
service@hostname
サービス@ホスト名
For NFS, the "service" element is
NFSの場合は、「サービス」の要素があります
nfs
同じ
RPCSEC_GSS is a single security flavor over which different security mechanisms can be multiplexed. Within a mechanism, GSS-API provides for the support of multiple quality of protections (QOPs), which are pairs of cryptographic algorithms. Each algorithm in the QOP consists of an encryption algorithm for privacy and a checksum algorithm for integrity. RPCSEC_GSS lets one protect the RPC request/response pair with plain header authentication, message integrity, and message privacy. Thus RPCSEC_GSS effectively supports M * Q * 3 different styles of security, where M is the number of mechanisms supported, Q is the average number of QOPs supported for each mechanism, and 3 enumerates authentication, integrity, and privacy.
RPCSEC_GSSは、異なるセキュリティ・メカニズムを多重化することができ、その上、単一のセキュリティ風味です。機構内に、GSS-APIは、暗号アルゴリズムのペアで保護（のQOP）、複数の品質のサポートを提供します。 QOP内の各アルゴリズムは、プライバシーのために暗号化アルゴリズムと整合性のチェックサムアルゴリズムで構成されています。 RPCSEC_GSSは1つが、プレーンヘッダ認証、メッセージの整合性、およびメッセージのプライバシーをRPCリクエスト/レスポンスのペアを保護することができます。したがって、RPCSEC_GSSが効果的にMがサポート機構の数あるセキュリティのM * Q * 3つの異なるスタイルをサポートする、Qは、各機構のためのサポートのQOPの平均数であり、3は、認証、整合性、およびプライバシーを列挙します。
Because RPCSEC_GSS encodes many styles of security, just adding RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's MNT response is not going to be of much use to the NFS client.
RPCSEC_GSSは単なるMOUNTバージョン3のMNT応答で返された味のリストにRPCSEC_GSSの追加セキュリティの多くのスタイルをコードするのでNFSクライアントに多くの使用であることを行っていません。
The solution is the creation of a concept called "pseudo flavors." Pseudo flavors are 32 bit integers that are allocated out of the same number space as regular RPC security flavors like AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. The idea is that each pseudo flavor will map to a specific triple of security mechanism, quality of protection, and service. The service will be one of authentication, integrity, and privacy. Note that integrity includes authentication, and privacy includes integrity. RPCSEC_GSS uses constants named rpc_gss_svc_none, rpc_gss_svc_integrity, and rpc_gss_svc_privacy, for authentication, integrity, and privacy respectively.
解決策は、と呼ばれる概念の創造である「疑似味。」擬似フレーバーはAUTH_NONE、AUTH_SYS、AUTH_DH、AUTH_KERB4、およびRPCSEC_GSSなどの定期的なRPCセキュリティ風味と同じ数の空間から割り当てられた32ビットの整数です。アイデアは、各疑似風味は、セキュリティ・メカニズム、保護の品質、及びサービスの特定のトリプルにマッピングすることです。このサービスは、認証、整合性、およびプライバシーのいずれかになります。整合性が認証を含み、そしてプライバシーが整合性が含まれていることに注意してください。 RPCSEC_GSSは、それぞれの認証、整合性、およびプライバシーのためrpc_gss_svc_none、rpc_gss_svc_integrity、およびrpc_gss_svc_privacyを、名前付き定数を使用しています。
Thus, instead of returning RPCSEC_GSS, a MOUNT Version 3 server will instead return one or more pseudo flavors if the NFS server supports RPCSEC_GSS and if the file system has been exported with one or more <mechanism, QOP, service> triples. See section 4, "The NFS Protocol over Kerberos V5" for an example of pseudo flavor to triple mapping.
ファイルシステムは、1つまたは複数の<メカニズム、QOP、サービス>トリプルでエクスポートされている場合は、NFSサーバがRPCSEC_GSSをサポートしている場合このように、代わりにRPCSEC_GSSを返すので、MOUNTバージョン3サーバーではなく、一の以上の擬似味を返します。三重マッピング疑似風味の例えば第4章、「ケルベロスV5上NFSプロトコル」を参照。
Once an RPCSEC_GSS session or context has been set up (via the RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT control procedures of RPCSEC_GSS), the NFS server MAY lock the <mechanism, QOP, service> triple for the duration of the session. While RPCSEC_GSS allows for the use of different QOPs and services on each message, it would be expensive for the NFS server to re-consult its table of exported file systems to see if the triple was allowed. Moreover, by the time the NFS server's dispatch routine was reached, the typical RPC subsystem would already have performed the appropriate GSS-API operation, GSS_VerifyMIC() or GSS_Unwrap(), if the respective integrity or privacy services were selected. If the file system being accessed were not exported with integrity or privacy, or with the particular QOP used to perform the integrity or privacy service, then it would be possible to execute a denial of service attack, whereby the objective of the caller is to deny CPU service to legitimate users of the NFS server's machine processors.
RPCSEC_GSSセッションまたはコンテキストが（RPCSEC_GSSのRPCSEC_GSS_INITとRPCSEC_GSS_CONTINUE_INIT制御手順を介して）設定されたら、NFSサーバは、セッションの間三重<機構、QOP、サービス>をロックすることができます。 RPCSEC_GSSは、各メッセージに異なるのQOPやサービスの利用が可能になりますが、それはトリプルが許可されたかどうかを確認するためにエクスポートされたファイルシステムの再協議のテーブルにNFSサーバのための高価です。それぞれの整合性やプライバシサービスを選択した場合また、NFSサーバのディスパッチルーチンに達した時点で、典型的なRPCサブシステムはすでに、適切なGSS-API操作、GSS_VerifyMIC（）やはgss_unwrap（）を実行しているだろう。アクセスされているファイルシステムは整合性やプライバシーを持つ、または整合性やプライバシーサービスを実行するために使用される特定のQOPでエクスポートされていない場合、発信者の目的は拒否することができる、サービス拒否攻撃を実行することは可能であろうNFSサーバーのマシン・プロセッサの正当なユーザーにCPUサービス。
Thus, in general, clients SHOULD NOT assume that they will be permitted to alter the <mechanism, QOP, service> triple once the data exchange phase of RPCSEC_GSS has started.
このように、一般的には、クライアントはRPCSEC_GSSのデータ交換フェーズが開始した後、彼らは<メカニズム、QOP、サービスを>変更するトリプル許可されることを仮定するべきではありません。
Pseudo flavor numbers MUST be registered via same method as regular RPC security flavor numbers via iana@iana.org.
疑似風味番号はiana@iana.orgを経由して、通常のRPCセキュリティ風味番号と同じ方法を経由して登録しなければなりません。
Once the pseudo flavor number has been assigned, registrants SHOULD register the mapping with iana@iana.org. The mapping registration MUST contain:
疑似風味番号が割り当てられると、登録者はiana@iana.orgとのマッピングを登録する必要があります。マッピングの登録は含まれていなければなりません：
* the pseudo flavor number, an ASCII string name for the flavor (for example "none" has been assigned for AUTH_NONE), and
*疑似風味番号、味のASCII文字列名（例えば「なし」はAUTH_NONEのために割り当てられていない）、および
* the <mechanism, algorithm(s), service> triple. As per the GSS-API specification, the mechanism MUST be identified with a unique ISO object identifier (OID). The reason why the second component of the triple is not necessarily a QOP value is that GSS-API allows mechanisms much latitude in the mapping of the algorithm used in the default quality of protection (See subsection 4.1, "Issues with Kerberos V5 QOPs," for a detailed discussion). With some mechanisms, the second component of the triple will be a QOP. Internally, on the NFS implementation, it is expected that the triple would use a QOP for the second component.
* <メカニズム、アルゴリズム（複数可）、サービス>トリプル。 GSS-API仕様に従って、機構は、固有のISOオブジェクト識別子（OID）で識別されなければなりません。三重の第二の成分は、必ずしもQOP値でない理由は、GSS-APIは、保護のデフォルトの品質に使用されるアルゴリズムのマッピングにおけるメカニズム多くの自由度を可能にすること（「ケルベロスV5のQOPの問題」を、サブセクション4.1を参照され詳細な議論のため）。いくつかの機構を、三重の第二の成分はQOPあろう。内部的には、NFSの実装には、三重第二コンポーネントのQOPを使用することが予想されます。
The mapping registration SHOULD also contain:
マッピングの登録も含まれている必要があります。
* A reference to an RFC describing how the NFS protocol works over the pseudo flavor(s), including the pseudo flavor number(s), string name(s) for the flavor(s), and any other issues, including how the registrant is interpreting the GSS-API mechanism.
疑似風味番号（複数可）、フレーバー（S）のための文字列名（複数可）、及びどのように登録者を含む任意の他の問題を含む、NFSプロトコルは擬似風味（S）上にどのように動作するかを説明するRFCに*参照、 GSS-APIメカニズムを解釈しています。
* A reference to the GSS-API mechanism used.
*使用GSS-APIメカニズムへの参照。
An example of a complete registration is provided in subsection 4.2, "The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry."
完全な登録の例は、「NFSプロトコルのKerberos V5疑似フレーバー登録エントリの上に。」サブセクション4.2に提供され
The NFS protocol uses Kerberos V5 security using the RPCSEC_GSS security flavor. The GSS-API security mechanism for Kerberos V5 that the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos V5 GSS-API description [RFC1964].
NFSプロトコルは、RPCSEC_GSSセキュリティ風味を使用してケルベロスV5セキュリティを使用しています。 NFS / RPCSEC_GSSプロトコルスタックが使用するケルベロスV5用GSS-APIセキュリティ機構がケルベロスV5 GSS-API説明[RFC1964]に記載されています。
The Kerberos V5 GSS-API description defines three algorithms for integrity:
ケルベロスV5 GSS-APIの記述は、整合性のための3つのアルゴリズムを定義しています。
* DES MAC MD5
* DES MD5 MAC
* MD2.5
* MD2.5
* DES-MAC
* DES-MAC
RFC 1964 states that MD2.5 "may be significantly weaker than DES MAC MD5." RFC 1964 also states that DES-MAC "may not be present in all implementations."
RFC 1964 MD2.5は「DES MAC MD5よりもかなり弱いかもしれません。」と述べていますRFC 1964も、DES-MAC「は、すべての実装では存在しないかもしれない。」と述べています
Thus the description of operation of NFS clients and servers over Kerberos V5 is limited to the DES MAC MD5 integrity algorithm.
したがって、NFSクライアントとKerberos V5以上のサーバーの動作の説明は、DES MAC MD5整合性アルゴリズムに限定されています。
NFS clients and servers operating over Kerberos V5 MUST support the DES MAC MD5 integrity algorithm. RFC 1964 lists a single algorithm for privacy: 56 bit DES. NFS clients and servers SHOULD support the 56 bit DES privacy algorithm.
ケルベロスV5上で動作するNFSクライアントとサーバはDES MAC MD5整合性アルゴリズムをサポートしなければなりません。 56ビットDES：RFC 1964には、プライバシーのために単一のアルゴリズムを示しています。 NFSクライアントとサーバは、56ビットDESプライバシーアルゴリズムをサポートする必要があります。
GSS-API has the concept of a default QOP of zero which means different integrity and privacy algorithms to different GSS-API mechanisms. In Kerberos V5, the default QOP of zero means to use the 56 bit DES algorithm (when doing a GSS_Wrap() operation with the conf_req_flag set to 1).
GSS-APIは、異なるGSS-APIメカニズムの異なる整合性とプライバシーのアルゴリズムを意味ゼロのデフォルトQOPの概念を持っています。ケルベロスV5では、ゼロのデフォルトQOP（1に設定conf_req_flagとにGSS_Wrap（）操作を行うとき）56ビットDESアルゴリズムを使用することを意味します。
For Kerberos V5, the default QOP of zero means different integrity algorithms to different implementations of Kerberos V5. Furthermore, during the processing of a token in GSS_Unwrap(), and GSS_VerifyMIC(), at least one reference implementation of the Kerberos V5 GSS-API mechanism [MIT], always returns a QOP of zero, regardless of integrity algorithm encoded in the token. For such implementations, it means that the caller of GSS_Unwrap() and GSS_VerifyMIC() cannot know the actual integrity algorithm used. Given that each integrity algorithm has a different degree of security, this situation may not be acceptable to the user of GSS-API. An implementation of Kerberos V5 under GSS-API for use under NFS MUST NOT do this.
ケルベロスV5の場合は、ゼロのデフォルトのQOPは、Kerberos V5の異なる実装に異なる整合性アルゴリズムを意味しています。また、はgss_unwrap（）、及びGSS_VerifyMIC（）内のトークンの処理中に、ケルベロスV5 GSS-API機構の少なくとも一つのリファレンス実装[MIT]は、常に関係なく、完全性アルゴリズムのトークンに符号化、ゼロのQOPを返します。そのような実装のために、それははgss_unwrap（）とGSS_VerifyMIC（）の呼び出し側が使用される実際の整合性アルゴリズムを知ることができないことを意味します。各整合性アルゴリズムは、セキュリティの異なる程度を持っていることを考えると、このような状況は、GSS-APIのユーザーに受け入れられないかもしれません。 NFSでの使用のためのGSS-APIの下でのKerberos V5の実装では、これを実行してはなりません。
For the purposes of NFS, as a simplification, some Kerberos V5 GSS-API mechanisms MAY map QOP 0 to always mean DES MAC MD5 integrity, and when using GSS_VerifyMIC() and GSS_Unwrap(), always map the DES MAC MD5 integrity that is specified to QOP 0.
NFSの目的のために、簡素化など、いくつかのKerberos V5 GSS-APIメカニズムは常にDES MAC MD5の整合性を意味するQOP 0をマッピングすることができる、とGSS_VerifyMIC（）とはgss_unwrap（）を使用する場合、必ず指定されたDES MAC MD5の整合性をマッピングQOPを0に。
Here are the pseudo flavor mappings for the NFS protocol using
ここで使用してNFSプロトコルの疑似風味のマッピングは、
Kerberos V5 security:
ケルベロスV5セキュリティ：
columns:
コラム：
1 == number of pseudo flavor 2 == name of pseudo flavor 3 == mechanism's OID 4 == mechanism's algorithm(s) 5 == RPCSEC_GSS service
疑似風味3 ==機構のOID 4 ==機構のアルゴリズム（複数可）5 == RPCSEC_GSSサービスの疑似風味2 ==名前の1つの==数
1 2 3 4 5
-----------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy
for integrity,
and 56 bit DES
for privacy.
An implementation of NFS over RPCSEC_GSS/GSS-API/Kerberos V5 that maps the default QOP to DES MAC MD5 (and vice versa), would implement a mapping of:
DES MAC MD5（およびその逆）へのデフォルトのQOPをマップRPCSEC_GSS / GSS-API /ケルベロスV5を超えるNFSの実装は、のマッピングを実装します：
columns:
コラム：
1 == number of pseudo flavor 2 == name of pseudo flavor 3 == mechanism's OID 4 == QOP 5 == RPCSEC_GSS service
疑似風味3 ==機構のOID 4 == QOP 5 == RPCSEC_GSSサービスの疑似風味2 ==名前の1つの==数
1 2 3 4 5
-----------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy
The reference for the GSS-API mechanism with the above OID is [RFC1964].
上記OIDとGSS-API機構のための基準は、[RFC1964]です。
The reference for how the NFS protocol MUST work over Kerberos V5 is this document.
NFSプロトコルは、Kerberos V5上で動作する必要がありますどのようにするための参照は、この文書です。
Version 3 of the MOUNT protocol is used to negotiate the security flavor to be used by the NFS Version 3 client. If the NFS client uses a weak security flavor like AUTH_SYS to query a Version 3 MOUNT server, then the following attacks are possible by an attacker in the middle:
MOUNTプロトコルのバージョン3は、NFSバージョン3クライアントによって使用されるセキュリティ風味を交渉するために使用されます。 NFSクライアントは、バージョン3 MOUNTサーバーを照会するAUTH_SYSのような弱いセキュリティ風味を使用する場合は、次の攻撃が中央に攻撃者によって考えられます。
* The attacker in the middle can coax the NFS client into using a weaker form of security than what the real NFS server requires. However, once the NFS client selects a security flavor when it sends a request to real NFS server, if the flavor is unacceptable, the NFS client's NFS request will be rejected. So at worst, a denial of service attack is possible. In theory, the NFS client could contact the MOUNT server using a stronger security flavor, but this would require that the client know in advance what security flavors the MOUNT server supports.
*真ん中の攻撃者は、実際のNFSサーバが必要とするよりも、セキュリティの弱いフォームを使用してにNFSクライアントを同軸ことができます。 NFSクライアントは、それが本当のNFSサーバに要求を送信し、セキュリティの味を選択すると味が受け入れられない場合は、、NFSクライアントのNFS要求は拒否されます。だから、最悪の場合、サービス拒否攻撃が可能です。理論的には、NFSクライアントは、より強力なセキュリティ風味を使用して、MOUNTサーバーに接続できますが、これは、クライアントがセキュリティ風味MOUNTサーバーがサポートしているものを事前に知っていることが必要であろう。
* If the client and server support a common set of security flavors, such that the client considers one preferable to the other (for example, one might have privacy and other not), unless the client uses a strong security flavor in the MOUNT protocol query, an attacker in the middle could cause the client to use the weaker form of security. Again, a client could contact the MOUNT server using a stronger form of security.
*クライアントとサーバは、クライアントが（例えば、1、プライバシーや他のではないのかもしれない）他に好適なものと考えるようにセキュリティ風味の共通セットをサポートしている場合、クライアントは、MOUNTプロトコルクエリで強力なセキュリティ風味を使用しない限り、 、真ん中の攻撃者は、クライアントがセキュリティの弱いフォームを使用する可能性があります。ここでも、クライアントは、セキュリティの強力なフォームを使用してMOUNTサーバーに接続できます。
This memorandum describes how NFS Version 2 and Version 3 work over RPC's RPCSEC_GSS security flavor. This memorandum requires that triples of { GSS-API mechanism OID, GSS-API mechanism algorithm, RPCSEC_GSS security service } be mapped to a unique RPC security flavor number, which is a pseudo flavor that does not appear in an RPC protocol header. This memorandum also encourages that an ASCII string name be registered with the triple.
この覚書は、RPCのRPCSEC_GSSセキュリティ風味の上にどのようにNFSバージョン2およびバージョン3の作業について説明します。このメモは、{GSS-API機構のOID、GSS-API機構アルゴリズム、RPCSEC_GSSセキュリティサービス}のトリプルは、RPCプロトコルヘッダに表示されない疑似風味で一意RPCセキュリティ風味番号にマッピングされることを必要とします。この覚書はまた、ASCII文字列名はトリプルに登録することを奨励しています。
Thus there are five different kinds of objects to consider guidelines for.
このようにするためのガイドラインを検討するオブジェクトの5種類があります。
The considerations of assignment, allocation, and delegation of pseudo flavor numbers are no different than that the considerations for RPC security flavors, as both are assigned from the same number space. IANA is already responsible for the assigned of RPC security flavors, and because this memorandum does not specify the RPC protocol [RFC1831], it is beyond the scope of this memorandum to guide IANA in the assignment of flavor numbers.
両方が同じ数の空間から割り当てられるように疑似風味番号の割り当て、割り当て、および委任の考察は、RPCセキュリティ風味のための考慮事項とは異なる全くありません。 IANAは既にRPCセキュリティ風味の割り当てを担当し、この覚書は、RPCプロトコル[RFC1831]を指定していないので、それが味番号の割り当てでIANAを導くために、この覚書の範囲を超えています。
This memorandum introduces the concept of a string name to be associated with the RPC pseudo flavor number, and so it is within the scope of this memorandum to provide guidance to IANA.
この覚書は、RPC疑似風味番号に関連付けられる列名の概念を導入し、そしてそれは、IANAへの指導を提供するために、この覚書の範囲内です。
There are no limits placed on the length of the unique string name by this memorandum, so the size of the name space is infinite. However, IANA may want to prevent the hoarding or reservation of names. The simplest way to do this is by requiring the registrant to provide the GSS-API mechanism OID, GSS-API quality of protection, the RPCSEC_GSS security service, and flavor number, with the request for a flavor name. If the registrant does not have a flavor number, then guidelines for flavor number assignments will indirectly limit the assignment of flavor names.
そここの覚書により、一意の文字列名の長さに置か制限はありませんので、名前空間の大きさは無限大です。しかし、IANAは名前の買いだめや予約を防止することがあります。これを実行する最も簡単な方法は、フレーバー名の要求で、GSS-API機構のOID、保護、RPCSEC_GSSセキュリティサービス、および風味数のGSS-APIの品質を提供するために、登録者に要求することによってです。登録者は、風味番号を持っていない場合は、風味番号の割り当てのためのガイドラインは、間接的にフレーバー名の割り当てを制限します。
The simplest way to handle delegation is to delegate portions of the RPC security flavor number space with the RPC flavor name space. The guidelines for delegation of the flavor name space are thus equivalent to guidelines for delegations of the flavor number space.
委任を処理するための最も簡単な方法は、RPC風味の名前空間を持つRPCセキュリティ風味番号空間の一部を委任することです。味の名前空間の委任のためのガイドラインは、このような風味番号空間の代表団のためのガイドラインと同等です。
Because string names can be trademarks, IANA may want to seek legal counsel to review a proposed pseudo flavor name. Other than that, no outside review is necessary.
文字列名は商標である可能性があるため、IANAは、提案された疑似風味名を確認するために弁護士を追求することをお勧めします。それ以外は、何も外見直しは必要ありません。
This memorandum assumes that the mechanism OID associated with the pseudo flavor has already been allocated. OIDs are allocated by the International Standards Organization and the International Telecommunication Union. Both organizations have delegated assignment authority for subsets of the OID number space to other organizations. Presumably, IANA has received authority to assign OIDs to GSS-API mechanisms. Because this memorandum does not specify the GSS-API protocol (see [RFC2078]) it is beyond the scope of this memorandum to guide IANA in the assignment of GSS-API mechanism OIDs.
このメモは、擬似味に関連付けられた機構OIDが既に割り当てられていることを前提としています。 OIDは、国際標準化機構及び国際電気通信連合によって割り当てられています。両組織は他の組織へのOID番号空間のサブセットの割り当て権限を委任しています。おそらく、IANAは、GSS-APIメカニズムにOIDを割り当てる認証を受けています。このメモは、GSS-APIプロトコルを指定しないので、それはGSS-API機構のOIDの割り当てでIANAを案内するために、このメモの範囲を超えている（[RFC2078]を参照）。
This memorandum assumes that the algorithm value for a given GSS-API mechanism has already been allocated. Algorithm values are controlled by the owner of the GSS-API mechanism, though the owner may delegate assignment of algorithm values to a body such as IANA. Because this memorandum does not specify GSS-API mechanisms, such as [RFC1964], it is beyond the scope of this memorandum to guide IANA in the assignment of a mechanism's algorithm value(s).
この覚書は、指定されたGSS-APIメカニズムのためのアルゴリズム値が既に割り当てられていることを前提としています。所有者は、IANAとして身体にアルゴリズム値の割り当てを委任することができるものの、アルゴリズム値は、GSS-API機構の所有者によって制御されます。このメモは、[RFC1964]としてGSS-APIメカニズムを、指定されていないので、機構のアルゴリズム値（単数または複数）の割り当てにIANAを案内するために、このメモの範囲を超えています。
There are only three security services and they are enumerated and described in [RFC2203]. No guideline to IANA is necessary.
そこだけ3つのセキュリティサービスがあり、それらが列挙して、[RFC2203]で説明されています。 IANAに何ガイドラインは必要ありません。
References
リファレンス
[RFC1094] Sun Microsystems, Inc., "NFS: Network File System Protocol Specification", RFC 1094, March 1989. http://www.ietf.org/rfc/rfc1094.txt
[RFC1094]サン・マイクロシステムズ社は、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月http://www.ietf.org/rfc/rfc1094.txt
[Sandberg] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, B. (1985). "Design and Implementation of the Sun Network Filesystem," Proceedings of the 1985 Summer USENIX Technical Conference.
【サンドバーグ]サンドバーグ、R.、ゴールドバーグ、D.、クレイマン、S.、ウォルシュ、D.、リヨン、B.（1985）。 「日ネットワークファイルシステムの設計と実装、」1985年夏のUSENIX技術会議の議事。
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. http://www.ietf.org/rfc/rfc1813.txt
[RFC1813]キャラハン、B.、ポロウスキー、B.およびP.ストーバック、 "NFSバージョン3プロトコル仕様"、RFC 1813、1995年6月http://www.ietf.org/rfc/rfc1813.txt
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995. http://www.ietf.org/rfc/rfc1831.txt
[RFC1831]スリニバサン、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 1831、1995年8月http://www.ietf.org/rfc/rfc1831.txt
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995. http://www.ietf.org/rfc/rfc1832.txt
[RFC1832]スリニバサン、R.、 "XDR：外部データ表現標準"、RFC 1832、1995年8月http://www.ietf.org/rfc/rfc1832.txt
[Pawlowski] Pawlowski, B., Juszczak, C., Staubach, P., Smith, C., Lebel, D. and D. Hitz, "NFS Version 3 Design and Implementation", Proceedings of the USENIX Summer 1994 Technical Conference.
[ポロウスキー]ポロウスキー、B.、Juszczak、C.、ストーバック、P.、スミス、C.、ルベル、D.とD.ヒッツ、 "NFSバージョン3の設計と実装"、USENIX夏1994のテクニカル会議の議事。
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997. http://www.ietf.org/rfc/rfc2203.txt
[RFC2203]アイスラー、M.、チウ、A.及びL.リン、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1997年9月http://www.ietf.org/rfc/rfc2203.txt
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. http://www.ietf.org/rfc/rfc2078.txt
[RFC2078]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース、バージョン2"、RFC 2078、1997年1月http://www.ietf.org/rfc/rfc2078.txt
[RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1057, June 1988. This RFC is being referenced for its description of the AUTH_DH (AUTH_DES) RPC security flavor. http://www.ietf.org/rfc/rfc1057.txt
[RFC1057]サン・マイクロシステムズ社、「RPC：リモートプロシージャコールプロトコル仕様バージョン2」、RFC 1057、6月1988このRFCはAUTH_DH（AUTH_DES）RPCセキュリティ風味のその説明のために参照されています。 http://www.ietf.org/rfc/rfc1057.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月http://www.ietf.org/rfc/rfc2119.txt
[Callaghan] Callaghan, B., Singh, S. (1993). "The Autofs Automounter," Proceedings of the 1993 Summer USENIX Technical Conference.
【キャラハン]キャラハン、B.、シン、S.（1993）。 「autofsのオートマウンタ、」1993年夏のUSENIX技術会議の議事。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. http://www.ietf.org/rfc/rfc1964.txt
[RFC1964]リン、J.、 "ケルベロスバージョン5 GSS-API機構"、RFC 1964、1996年6月http://www.ietf.org/rfc/rfc1964.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996. http://www.ietf.org/rfc/rfc2054.txt
[RFC2054]キャラハン、B.、 "WebNFSのクライアント仕様"、RFC 2054、1996年10月http://www.ietf.org/rfc/rfc2054.txt
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. http://www.ietf.org/rfc/rfc2434.txt
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月http://www.ietf.org/rfc/rfc2434.txt
[MIT] Massachusetts Institute of Technology (1998). "Kerberos: The Network Authentication Protocol." The Web site for downloading MIT's implementation of Kerberos V5, including implementations of RFC 1510 and RFC 1964. http://web.mit.edu/kerberos/www/index.html
テクノロジーの[MIT]マサチューセッツ工科大学（1998）。 「ケルベロス：ネットワーク認証プロトコル。」 RFC 1510およびRFC 1964 http://web.mit.edu/kerberos/www/index.htmlの実装を含む、ケルベロスV5のMITの実装をダウンロードするためのWebサイト
Acknowledgments
謝辞
The author thanks:
著者のおかげで：
* Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve Nahm, Joyce Reynolds, and David Robinson for their review comments.
自分のレビューコメント用*ブレントキャラハン、ジョン・ホーキンソン、ジャック・カバット、リン・リング、スティーブ・Nahm、ジョイスレイノルズ、とデビッド・ロビンソン。
* John Linn, for his explanation of QOP handling in RFC 1964.
*ジョン・リン、QOPは、RFC 1964で扱うの彼の説明のために。
Author's Address
著者のアドレス
Address comments related to this memorandum to:
この覚書に関連するコメントを住所：
nfsv4-wg@sunroof.eng.sun.com
んｆｓｖ４ーｗｇ＠すんろおｆ。えんｇ。すん。こｍ
Mike Eisler Sun Microsystems, Inc. 5565 Wilson Road Colorado Springs, CO 80919
マイク・アイスラーサン・マイクロシステムズ株式会社5565ウィルソン道路コロラドスプリングス、CO 80919
Phone: 1-719-599-9026 EMail: mre@eng.sun.com
電話：1-719-599-9026 Eメール：mre@eng.sun.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of eveloping Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、そのimplmentationを支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合にはインターネット標準をevelopingの目的のために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。