Network Working Group M. Eisler
Request for Comments: 2623 Sun Microsystems, Inc.
Category: Standards Track June 1999
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.
版权所有（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
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
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）原语实现的。网络文件系统协议规范[RFC1094]中指定了NFS协议版本2。初始实现的描述可在[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]中指定。外部数据表示标准[RFC1832]中规定了XDR协议。
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。本文档还将描述NFS如何通过RPCSEC_GSS在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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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风格提供空身份验证，即不传递任何身份验证信息。
* The AUTH_SYS flavor provides a UNIX-style user identifier, group identifier, and an array of supplemental group identifiers with each call.
* AUTH_SYS flavor为每个调用提供一个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加密的身份验证参数，会话密钥通过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的主体标识符）提供DES加密的身份验证参数，会话密钥通过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服务器将要求客户机从UDP或TCP源端口发送其值小于1024的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操作系统的单用户桌面主机，用户可能知道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.
* 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服务器都不应拒绝对NULL过程（过程编号0）的NFS请求。完整解释见第2.3.1小节“无效程序”。
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加密和公钥，以及在AUTH_KERB4情况下使用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协议仅限于使用这五种风格。
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:
NFS客户端通常使用NULL过程来确定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发送请求。这似乎没有任何价值，因为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.
* 不要求空过程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
不需要身份验证的原因如下所述。当NFS客户端装载NFS服务器的文件系统时，客户端上调用方的标识通常是一个管理实体（在UNIX操作系统中，这通常是“root”用户）。通常情况下，对于与自动装载机[Callaghan]协同进行的无人值守操作，与自动装载机关联的管理实体的AUTH_DH、AUTH_KERB4或RPCSEC_GSS凭据不可用。如果是这样，NFS客户端将使用AUTH_NONE或AUTH_SYS执行用于装载文件系统的初始NFS操作。虽然攻击者可以利用此实现工件进行攻击，但暴露仅限于获取文件的属性
or a file system's characteristics. This OPTIONAL trade off favors the opportunity for improved ease of use.
或文件系统的特征。这种可选的权衡有利于提高易用性。
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服务器实现可能会：
* 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不附带任何用户标识。为了允许请求，在许多操作系统上，服务器将分配用户标识。通常，此分配将是对系统具有有限访问权限的用户，例如UNIX系统上的用户“nobody”。
The following passage is excerpted verbatim from RFC 1813, section 4.4 "Permission Issues" (except that "may" has been changed to "MAY"):
以下段落逐字摘自RFC1813第4.4节“许可问题”（除了“可能”已改为“可能”）：
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映射到一个可分辨值（uid\u 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文件系统的初始文件句柄。通过MOUNT协议强制执行访问控制将有一点用处。诚然，一些WebNFS服务器实现通过将公共文件句柄的使用限制在导出到Internet上每个客户端的文件系统上来解决这一问题。
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
与NFS版本3关联的MOUNT版本3协议通过让对MNT过程的响应在MNT过程中包含一个风格列表来解决这个问题。请注意，因为某些NFS服务器将文件系统导出到特定的客户机列表，具有不同的访问权限（只读与读写），并且具有不同的
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.
安全风格，客户端可能会在MNT响应中返回的列表中返回多个安全风格。使用一种风格而不是另一种风格可能意味着只读访问而不是读写访问，或者可能是访问的其他降级。因此，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 NONE AUTH_SYS AUTH_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_服务名称类型在GSS-API中标识自己。GSS_C_NT_基于主机的_服务名称的形式如下：
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
RPCSEC_GSS是一种单一的安全风格，不同的安全机制可以在其上多路复用。在一种机制中，GSS-API提供了对多质量保护（QOP）的支持，QOP是一对加密算法。QOP中的每个算法包括
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允许通过简单的头验证、消息完整性和消息隐私来保护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添加到MOUNT Version 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.
解决方案是创建一个称为“伪风格”的概念。伪风格是从与常规RPC安全风格相同的数字空间中分配的32位整数，如AUTH_NONE、AUTH_SYS、AUTH_DH、AUTH_KERB4和RPCSEC_GSS。其思想是，每种伪风格都将映射到特定的三重安全机制、保护质量和服务。该服务将是一个身份验证、完整性和隐私的服务。请注意，完整性包括身份验证，隐私包括完整性。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.
因此，如果NFS服务器支持RPCSEC_GSS，并且文件系统已使用一个或多个<mechanism，QOP，service>三元组导出，则装载版本3服务器将返回一个或多个伪风格，而不是返回RPCSEC_GSS。有关伪风格到三重映射的示例，请参见第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控制过程），NFS服务器可以在会话期间锁定<mechanism，QOP，service>三重。虽然RPCSEC_GSS允许在每条消息上使用不同的QoP和服务，但NFS服务器重新查阅其导出的文件系统表以查看是否允许使用三重QoP和服务会很昂贵。此外，当到达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的数据交换阶段开始，他们将被允许更改<mechanism，QOP，service>triple。
Pseudo flavor numbers MUST be registered via same method as regular RPC security flavor numbers via iana@iana.org.
伪风格编号必须通过与常规RPC安全风格编号相同的方法注册，方法为iana@iana.org.
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分配了“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允许机制在映射默认保护质量中使用的算法时有很大的自由度（有关详细讨论，请参阅第4.1小节“Kerberos V5 QOP的问题”）。有了一些机制，三元组的第二个组成部分将是QOP。在内部，在NFS实现上，预计triple将为第二个组件使用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.
* 对RFC的引用，描述NFS协议如何在伪香精上工作，包括伪香精编号、香精的字符串名称，以及任何其他问题，包括注册人如何解释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协议使用Kerberos V5安全性，使用RPCSEC_GSS安全特性。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描述定义了三种完整性算法：
* 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完整性算法。
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完整性算法。RFC1964列出了一种隐私算法：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具有默认QOP为零的概念，这意味着针对不同GSS-API机制的不同完整性和隐私算法。在Kerberos V5中，默认的QOP为零意味着使用56位DES算法（在conf_req_标志设置为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]的至少一个参考实现始终返回零的QOP，而与令牌中编码的完整性算法无关。对于此类实现，这意味着GSS_Unwrap（）和GSS_VerifyMIC（）的调用方无法知道实际使用的完整性算法。鉴于每个完整性算法具有不同程度的安全性，GSS-API用户可能无法接受这种情况。GSS-API下用于NFS的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 MAC MD5完整性，并且在使用GSS_VerifyMIC（）和GSS_Unwrap（）时，始终映射指定给QOP 0的DES MAC MD5完整性。
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 == 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.
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 == 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
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协议头中未出现的伪风格。该备忘录还鼓励向triple注册ASCII字符串名称。
Thus there are five different kinds of objects to consider guidelines for.
因此，有五种不同类型的对象来考虑指南。
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由国际标准组织和国际电信联盟分配。两个组织都已将OID编号空间子集的分配权限委托给其他组织。据推测，IANA已获得授权将OID分配给GSS-API机制。由于本备忘录未规定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
本备忘录假设给定GSS-API机制的算法值已经分配。算法值由GSS-API机制的所有者控制，尽管所有者可以委托
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).
将算法值分配给实体，如IANA。由于本备忘录未规定GSS-API机制，如[RFC1964]，因此在分配机制的算法值时指导IANA超出了本备忘录的范围。
There are only three security services and they are enumerated and described in [RFC2203]. No guideline to IANA is necessary.
只有三种安全服务，它们在[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: Network File System
Protocol Specification", RFC 1094, March 1989.
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）。“Sun网络文件系统的设计和实现”，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
Version 3 Protocol Specification", RFC 1813, June 1995.
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] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
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: External Data Representation
Standard", RFC 1832, August 1995.
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设计和实现”，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] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
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., "Generic Security Service Application
Program Interface, Version 2", RFC 2078, January 1997.
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”，RFC1057，1988年6月。此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] 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
[Callaghan] Callaghan, B., Singh, S. (1993). "The Autofs Automounter," Proceedings of the 1993 Summer USENIX Technical Conference.
[Callaghan]Callaghan，B.，Singh，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] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", RFC 1964, June 1996.
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] Callaghan, B., "WebNFS Client Specification", RFC
2054, October 1996.
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] 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
Acknowledgments
致谢
The author thanks:
作者感谢：
* Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve Nahm, Joyce Reynolds, and David Robinson for their review comments.
* Brent Callaghan、John Hawkinson、Jack Kabat、Lin Ling、Steve Nahm、Joyce Reynolds和David Robinson感谢他们的评论。
* 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 Microsystems，Inc.科罗拉多州斯普林斯威尔逊路5565号，邮编：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.
版权所有（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.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
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编辑功能的资金目前由互联网协会提供。