[要約] 要約：RFC 2623は、NFSバージョン2およびバージョン3のセキュリティ問題と、NFSプロトコルのRPCSEC_GSSおよびKerberos V5の使用に関する情報を提供しています。 目的：このRFCの目的は、NFSのセキュリティに関する問題を明確にし、RPCSEC_GSSおよびKerberos V5の使用によるセキュリティ強化の方法を提案することです。
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セキュリティの問題とNFSプロトコルがRPCSEC_GSSと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.
Copyright（c）The Internet Society（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プロトコルは、マシン、オペレーティングシステム、ネットワークアーキテクチャ、セキュリティメカニズム、および輸送プロトコルが独立しているように設計されています。この独立性は、外部データ表現（XDR）の上に構築されたONCリモートプロシージャコール（RPC）プリミティブを使用することで達成されます。NFSプロトコルバージョン2は、ネットワークファイルシステムプロトコル仕様[RFC1094]で指定されています。最初の実装の説明は[Sandberg]にあります。NFSプロトコルバージョン3は、NFSバージョン3プロトコル仕様[RFC1813]で指定されています。いくつかの最初の実装の説明は、[Pawlowski]にあります。
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を介してKerberos V5を介してNFSの仕組みについても説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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]と呼ばれることもあります）フレーバーは、ネットワーク全体の文字列名に基づいて暗号化された認証パラメーターを提供し、セッションキーはdiffie-hellman公開キースキームを介して交換されます。
* 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.
* auth_kerb4フレーバーは、ネットワーク全体の文字列名（名前はkerberosバージョン4プリンシパル識別子）に基づいて暗号化された認証パラメーターを提供し、セッションキーはKerberosバージョン4シークレットキーを介して交換されます。
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を持つUDPまたはTCPソースポートからNFS要求を送信することを要求します。理論は、ポート<1024への拘束力がクライアントの特権操作であるため、クライアントはファイルアクセス権限を強制していることです。その終わり。理論は：
* 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オペレーティングシステムを実行しているシングルユーザーのデスクトップホストでは、ユーザーはルートユーザーパスワードの知識を持っている場合があります。そして、彼がその知識を持っていなくても、デスクトップマシンに物理的にアクセスできる場合でも、ルートの特権は簡単に取得されます。
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.
* NFSクライアントは、ポート<1024にバインドしようとする必要があります。場合によっては、バインドに失敗した場合（ユーザーがそうする特権がないか、無料ポート<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サーバーはNFS要求をnullプロシージャに拒否してはなりません（手順番号0）。完全な説明については、サブセクション2.3.1、「null手順」を参照してください。
The port monitoring issues and recommendations apply to the MOUNT protocol as well.
ポート監視の問題と推奨事項は、マウントプロトコルにも適用されます。
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の認証フレーバーを使用して、サーバーは、各コールでクライアントの効果的なユーザー識別子、効果的なグループ識別子、および補足グループ識別子を取得し、それらを使用してアクセスを確認します。ユーザー識別子とグループ識別子を使用すると、クライアントとサーバーが同じ識別子名スペースを共有するか、ローカルユーザーとグループ識別子マッピングを行うことを意味します。
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_dhの場合、des encryption and public Keysを使用することにより、Auth_kerb4ケースでdes encryptionとkerberosのシークレットキー（およびチケット）を使用することにより、より大きなセキュリティを提供します。繰り返しますが、サーバーとクライアントはネットワーク上の特定の名前の識別に同意する必要がありますが、IDの名前は、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サーバーを「ping」するために）に応答しているかどうかを判断するために使用されます。一部の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?
* TCPまたはUDPポート<1024からリクエストを送信します。これには、ヌル手順が非常に低く、ヌル手順を処理して認証エラーを返すコストよりもオーバーヘッドではないため、これには価値がないようです。さらに、認証エラーを送信することにより、サーバーはクライアントが関心を持っている情報を確認しました。サーバーは動作していますか？
* 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手順を受け入れ、
* NOT require that the source port be < 1024 on a NULL procedure 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およびstatfです。バージョン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サーバーのファイルシステムをマウントすると、クライアント上の発信者のIDは通常、管理エンティティです（UNIXオペレーティングシステムでは、これは通常「ルート」ユーザーです）。多くの場合、自動車に関連する管理エンティティのAuth_DH、auth_kerb4、またはRPCSEC_GSS資格情報を自動車と協調して、自動車に関連する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サーバーは、特定のセキュリティフレーバーがエクスポートにバインドされたファイルシステムをエクスポートする場合があります。クライアントがファイルシステムがエクスポートされたフレーバーの1つではないセキュリティフレーバーを使用している場合、NFSサーバーの実装は次のとおりです。
* 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システムのユーザー「Nobody」など、システムへのアクセスが制限されているユーザーです。
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がないことを除きます。リクエストを許可するために、多くのオペレーティングシステムで、サーバーはユーザーIDを割り当てます。通常、この割り当ては、UNIXシステムのユーザー「Nobody」など、システムへのアクセスが制限されているユーザーになります。
The following passage is excerpted verbatim from RFC 1813, section 4.4 "Permission Issues" (except that "may" has been changed to "MAY"):
次の箇所は、RFC 1813からの抜粋された逐語、セクション4.4「許可の問題」（「5月」が「5月」に変更されたことを除く）：
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 0をDistinguished値（uid_nobody）にマップし、グループリストをマッピングする前に、アクセスチェックを行う前にマッピングします。サーバーの実装は、このマッピングを変更するメカニズムを提供する場合があります。これは、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サーバーの実装では、ホストベースのアクセス制御方法が使用され、ファイルシステムをクライアントのリストにエクスポートできます。ファイルシステムは、読み取り専用または読み取りワイトアクセスのためにエクスポートすることもできます。これらの実装のいくつかは、マウントプロトコルハンドシェイクを介してファイルハンドルを要求するときに、マウント時にのみアクセスをチェックします。後続の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.
* 攻撃者は、マウントサーバーのアクセス制御を回避して、攻撃者が許可されていないファイルシステムへのアクセスを取得できます。回避は、ファイルハンドルを盗むこと（通常、正当なクライアントとサーバー間のネットワークトラフィックをスヌーピングすることによって）またはファイルハンドルを推測することによって達成されます。この攻撃が成功するためには、攻撃者はまだユーザーの資格情報になりすましている必要があります。これはauth_sysにとっては簡単ですが、auth_dh、auth_kerb4、およびrpcsec_gssの場合は難しいです。
* 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.
* パブリックファイルハンドルルックアップ[RFC2054]を使用するWebNFSクライアントは、マウントプロトコルを通過してNFSファイルシステムの初期ファイルハンドルを取得しません。マウントプロトコルを介したアクセス制御の実施は少し役に立ちます。確かに、一部の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に関連付けられたマウントバージョン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:
新しい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_HOSTBASET_SERVICE NAME NAME NAMEタイプを介してGSS-APIで自分自身を識別する必要があります。gss_c_nt_hostbased_service名は形式です。
service@hostname
service@hostname
For NFS, the "service" element is
NFSの場合、「サービス」要素はです
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は、暗号化アルゴリズムのペアである複数の保護品質（QOPS）のサポートを提供します。QOPの各アルゴリズムは、プライバシーのための暗号化アルゴリズムと、整合性のためのチェックサムアルゴリズムで構成されています。RPCSEC_GSSでは、RPCリクエスト/応答ペアをプレーンヘッダー認証、メッセージの整合性、およびメッセージプライバシーを使用して保護できます。したがって、RPCSEC_GSSはM * Q * 3の異なるスタイルのセキュリティを効果的にサポートします。Mはサポートされるメカニズムの数、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は多くのスタイルのセキュリティをエンコードするため、RPCSEC_GSSをマウントバージョン3のMNT応答で返されるフレーバーのリストに追加するだけで、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ビット整数です。アイデアは、各擬似フレーバーが、セキュリティメカニズム、保護の質、およびサービスの特定のトリプルにマッピングされるということです。このサービスは、認証、整合性、プライバシーの1つになります。整合性には認証が含まれ、プライバシーには整合性が含まれることに注意してください。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.
したがって、RPCSEC_GSSを返す代わりに、NFSサーバーがRPCSEC_GSSをサポートし、ファイルシステムが1つ以上の<メカニズム、QOP、サービス>トリプルでエクスポートされている場合、マウントバージョン3サーバーは代わりに1つ以上の擬似フレーバーを返します。トリプルマッピングへの擬似フレーバーの例については、セクション4「Kerberos 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_INITおよびRPCSEC_GSS_CONTINUE_INIT RPCSEC_GSSの制御手順を介して）、NFSサーバーは、セッションの期間中に<メカニズム、QOP、サービス>トリプルをロックすることができます。RPCSEC_GSSは各メッセージで異なるQOPSとサービスを使用することを可能にしますが、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）で識別する必要があります。トリプルの2番目のコンポーネントが必ずしもQOP値ではない理由は、GSS-APIがデフォルトの保護品質で使用されるアルゴリズムのマッピングに大きな緯度を許可するためです（サブセクション4.1、「Kerberos V5 Qopsの問題」を参照してください。詳細な議論のために）。いくつかのメカニズムを使用すると、トリプルの2番目のコンポーネントはQOPになります。内部的には、NFSの実装では、トリプルが2番目のコンポーネントに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.
* NFSプロトコルが擬似フレーバー数を介してどのように機能するかを説明する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."
完全な登録の例は、サブセクション4.2「Kerberos v5擬似フレーバー登録エントリをめぐるNFSプロトコル」に記載されています。
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セキュリティフレーバーを使用してKerberos V5セキュリティを使用します。NFS/RPCSEC_GSSプロトコルスタックが使用するKerberos V5のGSS-APIセキュリティメカニズムは、Kerberos V5 GSS-API説明[RFC1964]で説明されています。
The Kerberos V5 GSS-API description defines three algorithms for integrity:
Kerberos V5 GSS-API説明は、整合性のための3つのアルゴリズムを定義します。
* DES MAC MD5
* DES MAC MD5
* 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.
したがって、Kerberos V5を介したNFSクライアントとサーバーの操作の説明は、DES MAC MD5 Integrity Algorithmに限定されます。
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.
Kerberos V5を介して動作するNFSクライアントとサーバーは、DES Mac Md5 Integrity Algorithmをサポートする必要があります。RFC 1964には、プライバシーに関する単一のアルゴリズムがリストされています：56ビットDES。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の概念があります。Kerberos v5では、ゼロのデフォルトのQOPは、56ビットDESアルゴリズムを使用することを意味します（conf_req_flagを1に設定してgss_wrap（）操作を実行する場合）。
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.
Kerberos V5の場合、ゼロのデフォルトのQOPは、Kerberos V5の異なる実装と異なる完全性アルゴリズムを意味します。さらに、gss_unwrap（）およびgss_verifymic（）でのトークンの処理中に、kerberos v5 gss-apiメカニズム[mit]の少なくとも1つの参照実装は、トークンでエンコードされた整合性アルゴリズムに関係なく、常にゼロの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メカニズムは、QOP 0を常にDES MAD MD5の整合性を意味するようにマッピングし、GSS_VerifyMic（）およびGSS_UNWRAP（）を使用する場合、指定されたDES MAC MD5の整合性を常にマッピングする場合があります。qop 0に。
Here are the pseudo flavor mappings for the NFS protocol using
NFSプロトコルの擬似フレーバーマッピングは次のとおりです。
Kerberos V5 security:
Kerberos 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
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:
デフォルトのQOPをDES MAC MD5にマップするRPCSEC_GSS/GSS-API/Kerberos V5を介したNFSの実装（およびその逆）は、次のマッピングを実装します。
columns:
列：
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == QOP
5 == RPCSEC_GSS service
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:
マウントプロトコルのバージョン3は、NFSバージョン3クライアントが使用するセキュリティフレーバーをネゴシエートするために使用されます。NFSクライアントがauth_sysのような弱いセキュリティフレーバーを使用してバージョン3マウントサーバーを照会する場合、次の攻撃が中央の攻撃者によって可能です。
* 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クライアントはより強力なセキュリティフレーバーを使用してマウントサーバーに連絡することができますが、これには、マウントサーバーがサポートするセキュリティフレーバーがどのようなセキュリティがサポートするかをクライアントが事前に知る必要があります。
* 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.
* クライアントとサーバーがセキュリティフレーバーの共通セットをサポートしている場合、クライアントがマウントプロトコルクエリで強力なセキュリティフレーバーを使用しない限り、クライアントが他のものよりも好ましいと見なす（たとえば、プライバシーなどがない場合がある場合）真ん中の攻撃者は、クライアントがより弱い形式のセキュリティを使用する可能性があります。繰り返しますが、クライアントは、より強力なセキュリティを使用してマウントサーバーに連絡することができます。
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.
この覚書は、NFSバージョン2とバージョン3がRPCのRPCSEC_GSSセキュリティフレーバーに対してどのように機能するかを説明しています。この覚書には、{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、GSS-APIの保護品質、RPCSEC_GSSセキュリティサービス、フレーバー番号をフレーバー名を要求することを要求することです。登録者がフレーバー番号を持っていない場合、フレーバー番号の割り当てのガイドラインは、フレーバー名の割り当てを間接的に制限します。
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番号スペースのサブセットの割り当て権限を他の組織に委任しました。おそらく、IANAはGSS-APIメカニズムにOIDを割り当てる権限を受けています。この覚書はGSS-APIプロトコルを指定していないため（[RFC2078]を参照）、GSS-APIメカニズムOIDの割り当てでIANAを導くことはこの覚書の範囲を超えています。
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メカニズムのアルゴリズム値がすでに割り当てられていることを前提としています。アルゴリズム値は、GSS-APIメカニズムの所有者によって制御されますが、所有者はアルゴリズム値の割り当てをIANAなどのボディに委任する場合があります。この覚書は[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] Sun Microsystems、Inc。、「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.
[Sandberg] Sandberg、R.、Goldberg、D.、Kleiman、S.、Walsh、D.、Lyon、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] Callaghan、B.、Pawlowski、B。and P. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、1995年6月。http：//www.ietf.org/rfc/rfc1813.txtxt
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995. http://www.ietf.org/rfc/rfc1831.txt
[RFC1831] Srinivasan、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] Srinivasan、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.
[Pawlowski] Pawlowski、B.、Juszczak、C.、Staubach、P.、Smith、C.、Lebel、D。、およびD. Hitz、「NFSバージョン3の設計と実装」、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] Eisler、M.、Chiu、A。and L. Ling、「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] Linn、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] Sun Microsystems、Inc。、「RPC：リモート手順コールプロトコル仕様バージョン2」、RFC 1057、1988年6月。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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
[Callaghan] Callaghan、B.、Singh、S。（1993）。「The Autofs Automounter」、1993年の夏のUSENIX技術会議の議事録。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. http://www.ietf.org/rfc/rfc1964.txt
[RFC1964] Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。http：//www.ietf.org/rfc/rfc1964.txt.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996. http://www.ietf.org/rfc/rfc2054.txt
[RFC2054] Callaghan、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）。「Kerberos：ネットワーク認証プロトコル。」RFC 1510およびRFC 1964の実装を含む、MITのKerberos V5の実装をダウンロードするためのWebサイト。http：//web.mit.edu/kerberos/www/index.html
Acknowledgments
謝辞
The author thanks:
著者のありがとう：
* Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve Nahm, Joyce Reynolds, and David Robinson for their review comments.
* ブレント・キャラハン、ジョン・ホーキンソン、ジャック・カバット、リン・リン、スティーブ・ナーム、ジョイス・レイノルズ、デビッド・ロビンソンのレビューコメント。
* John Linn, for his explanation of QOP handling in RFC 1964.
* John Linn、RFC 1964でのQOPハンドリングの説明について。
Author's Address
著者の連絡先
Address comments related to this memorandum to:
この覚書に関連するコメントに対応してください。
nfsv4-wg@sunroof.eng.sun.com
nfsv4-wg@sunroof.eng.sun.com
Mike Eisler Sun Microsystems, Inc. 5565 Wilson Road Colorado Springs, CO 80919
Mike Eisler Sun Systems、Inc。5565 Wilson Road Colorado Springs、Co 80919
Phone: 1-719-599-9026 EMail: mre@eng.sun.com
電話：1-719-599-9026メール：mre@eng.sun.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、配布されます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。