Network Working Group A. Chiu
Request for Comments: 2755 M. Eisler
Category: Informational B. Callaghan
Sun Microsystems
January 2000
Network Working Group A. Chiu
Request for Comments: 2755 M. Eisler
Category: Informational B. Callaghan
Sun Microsystems
January 2000
Security Negotiation for WebNFS
WebNFS的安全协商
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes a protocol for a WebNFS client [RFC2054] to negotiate the desired security mechanism with a WebNFS server [RFC2055] before the WebNFS client falls back to the MOUNT v3 protocol [RFC1813]. This document is provided so that people can write compatible implementations.
本文档描述了WebNFS客户端[RFC2054]在WebNFS客户端退回到MOUNT v3协议[RFC1813]之前与WebNFS服务器[RFC2055]协商所需安全机制的协议。提供此文档是为了让人们能够编写兼容的实现。
Table of Contents
目录
1. Introduction .............................................. 2
2. Security Negotiation Multi-component LOOKUP ............... 3
3 Overloaded Filehandle ..................................... 4
3.1 Overloaded NFS Version 2 Filehandle ..................... 5
3.2 Overloaded NFS Version 3 Filehandle ..................... 6
4. WebNFS Security Negotiation ............................... 6
5. Security Considerations ................................... 10
6. References ................................................ 10
7. Acknowledgements .......................................... 10
8. Authors' Addresses ........................................ 11
9. Full Copyright Statement .................................. 12
1. Introduction .............................................. 2
2. Security Negotiation Multi-component LOOKUP ............... 3
3 Overloaded Filehandle ..................................... 4
3.1 Overloaded NFS Version 2 Filehandle ..................... 5
3.2 Overloaded NFS Version 3 Filehandle ..................... 6
4. WebNFS Security Negotiation ............................... 6
5. Security Considerations ................................... 10
6. References ................................................ 10
7. Acknowledgements .......................................... 10
8. Authors' Addresses ........................................ 11
9. Full Copyright Statement .................................. 12
The MOUNT protocol is used by an NFS client to obtain the necessary filehandle for data access. MOUNT versions 1 and 2 [RFC1094] return NFS version 2 filehandles, whereas MOUNT version 3 [RFC1813] returns NFS version 3 filehandles.
NFS客户端使用装载协议来获取数据访问所需的文件句柄。装载版本1和2[RFC1094]返回NFS版本2文件句柄，而装载版本3[RFC1813]返回NFS版本3文件句柄。
Among the existing versions of the MOUNT protocol, only the MOUNT v3 provides an RPC procedure (MOUNTPROC3_MNT) which facilitates security negotiation between an NFS v3 client and an NSF v3 server. When this RPC procedure succeeds (MNT3_OK) the server returns to the client an array of security mechanisms it supports for the specified pathname, in addition to an NFS v3 filehandle.
在MOUNT协议的现有版本中，只有MOUNT v3提供了一个RPC过程（MOUNTPROC3_MNT），它促进了NFS v3客户端和NSF v3服务器之间的安全协商。当此RPC过程成功（MNT3_OK）时，服务器将向客户端返回它为指定路径名支持的一系列安全机制，以及NFS v3文件句柄。
A security mechanism referred to in this document is a generalized security flavor which can be an RPC authentication flavor [RFC1831] or a security flavor referred to in the RPCSEC_GSS protocol [RFC2203]. A security mechanism is represented as a four-octet integer.
本文档中提到的安全机制是一种通用安全风格，可以是RPC身份验证风格[RFC1831]或RPCSEC_GSS协议[RFC2203]中提到的安全风格。安全机制表示为四个八位整数。
No RPC procedures are available for security negotiation in versions 1 or 2 of the MOUNT protocol.
在装载协议的版本1或2中，没有RPC过程可用于安全协商。
The NFS mount command provides a "sec=" option for an NFS client to specify the desired security mechanism to use for NFS transactions. If this mount option is not specified, the default action is to use the default security mechanism over NFS v2 mounts, or to negotiate a security mechanism via the MOUNTPROC3_MNT procedure of MOUNT v3 and use it over NFS v3 mounts. In the latter, the client picks the first security mechanism in the array returned from the server that is also supported on the client.
NFS mount命令为NFS客户端提供了一个“sec=”选项，用于指定用于NFS事务的所需安全机制。如果未指定此装载选项，则默认操作是在NFS v2装载上使用默认安全机制，或者通过mount v3的MOUNTPROC3 MNT过程协商安全机制，并在NFS v3装载上使用它。在后者中，客户端在从服务器返回的阵列中选择客户端也支持的第一个安全机制。
As specified in RFC 2054, a WebNFS client first assumes that the server supports WebNFS and uses the publsc filehandle as the initial filehandle for data access, eliminating the need for the MOUNT protocol. The WebNFS client falls back to MOUNT if the server does not support WebNFS.
如RFC 2054中所述，WebNFS客户端首先假定服务器支持WebNFS，并使用publsc filehandle作为数据访问的初始filehandle，从而消除了对装载协议的需要。如果服务器不支持WebNFS，WebNFS客户端将返回装载。
Since a WebNFS client does not use MOUNT initially, the MOUNTPROC3_MNT procedure of MOUNT v3 is not available for security negotiation until the WebNFS client falls back to MOUNT. A viable protocol needs to be devised for the WebNFS client to negotiate security mechanisms with the server in the absence of the MOUNTPROC3_MNT procedure.
由于WebNFS客户端最初不使用MOUNT，因此MOUNT v3的MOUNTPROC3\u MNT过程在WebNFS客户端返回到MOUNT之前不可用于安全协商。需要为WebNFS客户端设计一个可行的协议，以便在没有MOUNTPROC3_MNT过程的情况下与服务器协商安全机制。
The WebNFS security negotiation protocol must meet the following requirements:
WebNFS安全协商协议必须满足以下要求：
- Must work seamlessly with NFS v2 and v3, and the WebNFS protocols
- 必须与NFS v2和v3以及WebNFS协议无缝配合
- Must be backward compatible with servers that do not support this negotiation
- 必须与不支持此协商的服务器向后兼容
- Minimum number of network turnarounds (latency)
- 最小网络周转次数（延迟）
This document describes the WebNFS security negotiation protocol developed by Sun Microsystems, Inc. Terminology and definitions from RFCs 2054 and 2055 are used in this document. The reader is expected to be familiar with them.
本文档描述了Sun Microsystems，Inc.开发的WebNFS安全协商协议。本文档使用RFCs 2054和2055中的术语和定义。读者应该熟悉它们。
The goal of the WebNFS security negotiation is to allow a WebNFS client to identify a security mechanism which is used by the WebNFS server to protect a specified path and is also supported by the client. The WebNFS client initiates the negotiation by sending the WebNFS server the path. The WebNFS server responds with the array of security mechanisms it uses to secure the specified path. From the array of security mechanisms the WebNFS client selects the first one that it also supports.
WebNFS安全协商的目标是允许WebNFS客户端识别WebNFS服务器用于保护指定路径的安全机制，该机制也受客户端支持。WebNFS客户端通过向WebNFS服务器发送路径来启动协商。WebNFS服务器使用它用来保护指定路径的一系列安全机制进行响应。WebNFS客户端从一系列安全机制中选择它也支持的第一个。
Without introducing a new WebNFS request, the WebNFS security negotiation is achieved by modifying the request and response of the existing multi-component LOOKUP (MCL) operation [RFC2055]. Note that the MCL operation is accomplished using the LOOKUP procedure (NFSPROC3_LOOKUP for NFS v3 and NFSPROC_LOOKUP for NFS v2). This and the next sections describe how the MCL request and response are modified to facilitate WebNFS security negotiation.
在不引入新的WebNFS请求的情况下，WebNFS安全协商是通过修改现有多组件查找（MCL）操作的请求和响应来实现的[RFC2055]。请注意，MCL操作是使用查找过程完成的（NFS v3的NFSPROC3_查找和NFS v2的NFSPROC_查找）。本节和下一节将介绍如何修改MCL请求和响应以促进WebNFS安全协商。
For ease of reference, the modified MCL request is henceforth referred to as SNEGO-MCL (security negotiation multi-component LOOKUP) request.
为了便于参考，修改后的MCL请求从此被称为SNEGO-MCL（安全协商多组件查找）请求。
A multi-component LOOKUP request [RFC2055] is composed of a public filehandle and a multi-component path:
多组件查找请求[RFC2055]由公共文件句柄和多组件路径组成：
For Canonical Path:
对于规范路径：
LOOKUP FH=0x0, "/a/b/c"
LOOKUP FH=0x0, "/a/b/c"
For Native Path:
对于本机路径：
LOOKUP FH=0x0, 0x80 "a:b:c"
LOOKUP FH=0x0, 0x80 "a:b:c"
A multi-component path is either an ASCII string of slash separated components or a 0x80 character followed by a native path. Note that a multi-component LOOKUP implies the use of the public filehandle in the LOOKUP.
多组件路径是由斜杠分隔的组件组成的ASCII字符串或后跟本机路径的0x80字符。请注意，多组件查找意味着在查找中使用公共文件句柄。
Similar to the MCL request, a SNEGO-MCL request consists of a public filehandle and a pathname. However, the pathname is uniquely composed, as described below, to distinguish it from other pathnames.
与MCL请求类似，SNEGO-MCL请求由公共文件句柄和路径名组成。但是，路径名是唯一组合的，如下所述，以区别于其他路径名。
The pathname used in a SNEGO-MCL is the regular WebNFS multi-component path prefixed with two octets. The first prefixed octet is the 0x81 non-ascii character, similar to the 0x80 non-ascii character for the native paths. This octet represents client's indication to negotiate security mechanisms. It is followed by the security index octet which stores the current value of the index into the array of security mechanisms to be returned from the server. The security index always starts with one and gets incremented as negotiation continues. It is then followed by the pathname, either an ASCII string of slash separated canonical components or 0x80 and a native path.
SNEGO-MCL中使用的路径名是以两个八位字节为前缀的常规WebNFS多组件路径。第一个带前缀的八位字节是0x81非ascii字符，类似于本机路径的0x80非ascii字符。此八位字节表示客户端指示协商安全机制。然后是安全索引八位字节，它将索引的当前值存储到从服务器返回的安全机制数组中。安全索引始终以1开头，并随着协商的继续而递增。随后是路径名，或者是斜杠分隔的规范组件的ASCII字符串，或者是0x80和本机路径。
A security negotiation multi-component LOOKUP request looks like this:
安全协商多组件查找请求如下所示：
For Canonical Path:
对于规范路径：
LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"
LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"
For Native Path:
对于本机路径：
LOOKUP FH=0x0, 0x81 <sec-index> 0x80 "a:b:c"
LOOKUP FH=0x0, 0x81 <sec-index> 0x80 "a:b:c"
In the next section we will see how the MCL response is modified for WebNFS security negotiation.
在下一节中，我们将看到如何为WebNFS安全协商修改MCL响应。
As described in RFC2054, if a multi-component LOOKUP request succeeds, the server responds with a valid filehandle:
如RFC2054所述，如果多组件查找请求成功，服务器将使用有效的文件句柄进行响应：
LOOKUP FH=0x0, "a/b/c"
----------->
<-----------
FH=0x3
LOOKUP FH=0x0, "a/b/c"
----------->
<-----------
FH=0x3
NFS filehandles are used to uniquely identify a particular file or directory on the server and are opaque to the client. The client neither examines a filehandle nor has any knowledge of its contents. Thus, filehandles make an ideal repository for the server to return the array of security mechanisms to the client in response to a SNEGO-MCL request.
NFS文件句柄用于唯一标识服务器上的特定文件或目录，对客户端来说是不透明的。客户端既不检查文件句柄，也不知道其内容。因此，filehandles为服务器提供了一个理想的存储库，用于响应SNEGO-MCL请求，将安全机制数组返回给客户端。
To a successful SNEGO-MCL request the server responds, in place of the filehandle, with an array of integers that represents the valid security mechanisms the client must use to access the given path. A length field is introduced to store the size (in octets) of the array of integers.
对于一个成功的SNEGO-MCL请求，服务器用一个整数数组代替filehandle进行响应，该数组表示客户端访问给定路径必须使用的有效安全机制。引入长度字段来存储整数数组的大小（以八位字节为单位）。
As the filehandles are limited in size (32 octets for NFS v2 and up to 64 octets for NFS v3), it can happen that there are more security mechanisms than the filehandles can accommodate. To circumvent this problem, a one-octet status field is introduced which indicates whether there are more security mechanisms (1 means yes, 0 means no) that require the client to perform another SNEGO-MCL to get them.
由于文件句柄的大小有限（NFS v2为32个八位字节，NFS v3为64个八位字节），因此可能会出现文件句柄无法容纳的安全机制。为了避免这个问题，引入了一个单八位组状态字段，它指示是否有更多的安全机制（1表示是，0表示否）需要客户端执行另一个SNEGO-MCL来获取它们。
To summarize, the response to a SNEGO-MCL request contains, in place of the filehandle, the length field, the status field, and the array of security mechanisms:
总之，对SNEGO-MCL请求的响应包含长度字段、状态字段和安全机制数组，而不是文件句柄：
FH: length, status, {sec_1 sec_2 ... sec_n}
FH: length, status, {sec_1 sec_2 ... sec_n}
The next two sub-sections describe how NFS v2 and v3 filehandles are "overloaded" to carry the length and status fields and the array of security mechanisms.
接下来的两小节将描述NFS v2和v3文件句柄如何“重载”以承载长度和状态字段以及安全机制数组。
A regular NFS v2 filehandle is defined in RFC1094 as an opaque value occupying 32 octets:
RFC1094中将常规NFS v2文件句柄定义为占用32个八位字节的不透明值：
1 2 3 4 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
| | | | | | | | | ... | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
1 2 3 4 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
| | | | | | | | | ... | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
An overloaded NFS v2 filehandle looks like this:
重载的NFS v2文件句柄如下所示：
1 2 3 4 5 8 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
| l | s | | | sec_1 | ... | sec_n | ... | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
1 2 3 4 5 8 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
| l | s | | | sec_1 | ... | sec_n | ... | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
Note that the first four octets of an overloaded NFS v2 filehandle contain the length octet, the status octet, and two padded octets to make them XDR four-octet aligned. The length octet l = 4 * n, where n is the number of security mechanisms sent in the current overloaded filehandle. Apparently, an overloaded NFS v2 filehandle can carry up to seven security mechanisms.
请注意，重载NFS v2文件句柄的前四个八位字节包含长度八位字节、状态八位字节和两个填充八位字节，以使它们与XDR四个八位字节对齐。长度八位组l=4*n，其中n是在当前重载文件句柄中发送的安全机制数。显然，一个重载的NFS v2文件句柄最多可以携带七种安全机制。
A regular NFS v3 filehandle is defined in RFC1813 as a variable length opaque value occupying up to 64 octets. The length of the filehandle is indicated by an integer value contained in a four octet value which describes the number of valid octets that follow:
RFC1813中将常规NFS v3文件句柄定义为可变长度不透明值，最多占用64个八位字节。文件句柄的长度由四个八位字节值中包含的整数值表示，该值描述了以下有效八位字节的数量：
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4 up to 64
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
| | | | | | | | | | | | | ... | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
1 4 up to 64
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
| | | | | | | | | | | | | ... | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
An overloaded NFS v3 filehandle looks like the following:
重载的NFS v3文件句柄如下所示：
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4 5 8
+---+---+---+---+---+---+---+---+ +---+---+---+---+
| s | | | | sec_1 | ... | sec_n |
+---+---+---+---+---+---+---+---+ +---+---+---+---+
1 4 5 8
+---+---+---+---+---+---+---+---+ +---+---+---+---+
| s | | | | sec_1 | ... | sec_n |
+---+---+---+---+---+---+---+---+ +---+---+---+---+
Here, len = 4 * (n+1). Again, n is the number of security mechanisms contained in the current overloaded filehandle. Three octets are padded after the status octet to meet the XDR four-octet alignment requirement. An overloaded NFS v3 filehandle can carry up to fifteen security mechanisms.
这里，len=4*（n+1）。同样，n是当前重载文件句柄中包含的安全机制的数量。状态八位字节后填充三个八位字节，以满足XDR四位八位字节对齐要求。一个重载的NFS v3文件句柄最多可以携带15种安全机制。
With the SNEGO-MCL request and the overloaded NFS v2 and v3 filehandles defined above, the following diagram depicts the WebNFS security negotiation protocol:
使用上面定义的SNEGO-MCL请求和重载NFS v2和v3文件句柄，下图描述了WebNFS安全协商协议：
Client Server
------ ------
Client Server
------ ------
LOOKUP FH=0x0, 0x81 <sec-index> "path"
----------->
<-----------
FH: length, status, {sec_1 sec_2 ... sec_n}
LOOKUP FH=0x0, 0x81 <sec-index> "path"
----------->
<-----------
FH: length, status, {sec_1 sec_2 ... sec_n}
where 0x81 represents client's indication to negotiate security mechanisms with the server,
其中0x81表示客户端指示与服务器协商安全机制，
path is either an ASCII string of slash separated components or 0x80 and a native path,
路径是由斜杠分隔的组件组成的ASCII字符串或0x80和本机路径，
sec-index, one octet, contains the index into the array of security mechanisms the server uses to protect the specified path,
sec索引（一个八位字节）包含服务器用于保护指定路径的安全机制数组中的索引，
status, one octet, indicates whether there are more security mechanisms (1 means yes, 0 means no) that require the client to perform another SNEGO-MCL to get them,
状态，一个八位字节，表示是否有更多的安全机制（1表示是，0表示否）需要客户端执行另一个SNEGO-MCL来获取它们，
length (one octet for NFS v2 and four octets for NFS v3) describes the number of valid octets that follow,
长度（NFS v2为一个八位字节，NFS v3为四个八位字节）描述了后面的有效八位字节数，
{sec_1 sec_2 ... sec_n} represents the array of security mechanisms. As noted earlier, each security mechanism is represented by a four-octet integer.
{sec_1 sec_2…sec_n}表示安全机制的数组。如前所述，每个安全机制由一个四个八位整数表示。
Here is an example showing the WebNFS security negotiation protocol with NFS v2. In the example it is assumed the server shares /export with 10 security mechanisms {0x3900 0x3901 0x3902 ... 0x3909} on the export, two SNEGO-MCL requests would be needed for the client to get the complete security information:
下面是一个示例，显示了使用NFS v2的WebNFS安全协商协议。在该示例中，假设服务器与10个安全机制共享/导出{0x3900 0x3901 0x3902…0x3909}在导出时，客户端需要两个SNEGO-MCL请求才能获得完整的安全信息：
LOOKUP FH=0x0, 0x81 0x01 "/export"
----------->
<-----------
0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906}
LOOKUP FH=0x0, 0x81 0x01 "/export"
----------->
<-----------
0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906}
LOOKUP FH=0x0, 0x81 0x08 "/export"
----------->
<-----------
0x0c, 0x00, {0x3907 0x3908 0x3909}
LOOKUP FH=0x0, 0x81 0x08 "/export"
----------->
<-----------
0x0c, 0x00, {0x3907 0x3908 0x3909}
The order of the security mechanisms returned in an overloaded filehandle implies preferences, i.e., one is more recommended than those following it. The ordering is the same as that returned by the MOUNT v3 protocol.
重载的filehandle中返回的安全机制的顺序意味着首选项，也就是说，建议使用一种安全机制，而不是使用下面的安全机制。顺序与mountv3协议返回的顺序相同。
The following shows a typical scenario which illustrates how the WebNFS security negotiation is accomplished in the course of accessing publicly shared filesystems.
下面显示了一个典型的场景，该场景演示了如何在访问公共共享文件系统的过程中完成WebNFS安全协商。
Normally, a WebNFS client first makes a regular multi-component LOOKUP request using the public filehandle to obtain the filehandle for the specified path. Since the WebNFS client does not have any prior knowledge as to how the path is protected by the server the default security mechanism is used in this first multi-component LOOKUP. If the default security mechanism does not meet server's requirements, the server replies with the AUTH_TOOWEAK RPC authentication error, indicating that the default security mechanism is not valid and the WebNFS client needs to use a stronger one.
通常，WebNFS客户端首先使用公共文件句柄发出常规的多组件查找请求，以获取指定路径的文件句柄。由于WebNFS客户端事先不知道服务器如何保护路径，因此在第一次多组件查找中使用了默认的安全机制。如果默认安全机制不满足服务器的要求，服务器将以AUTH_TOOWEAK RPC身份验证错误进行响应，这表明默认安全机制无效，WebNFS客户端需要使用更强大的安全机制。
Upon receiving the AUTH_TOOWEAK error, to find out what security mechanisms are required to access the specified path the WebNFS client sends a SNEGO-qMCL request, using the default security mechanism.
在收到AUTH_TOOWEAK错误后，为了找出访问指定路径所需的安全机制，WebNFS客户端使用默认安全机制发送SNEGO qMCL请求。
If the SNEGO-MCL request succeeds the server responds with the filehandle overloaded with the array of security mechanisms required for the specified path. If the server does not support WebNFS security negotiation, the SNEGO-MCL request fails with NFSERR_IO for NFS v2 or NFS3ERR_IO for NFS v3 [RFC2055].
如果SNEGO-MCL请求成功，服务器将使用指定路径所需的安全机制数组重载的文件句柄进行响应。如果服务器不支持WebNFS安全协商，则SNEGO-MCL请求将失败，NFS v2的NFSERR_IO或NFS v3的NFS3ERR_IO[RFC2055]。
Depending on the size of the array of security mechanisms, the WebNFS client may have to make more SNEGO-MCL requests to get the complete array.
根据安全机制阵列的大小，WebNFS客户端可能必须发出更多的SNEGO-MCL请求才能获得完整的阵列。
For successful SNEGO-MCL requests, the WebNFS client retrieves the array of security mechanisms from the overloaded filehandle, selects an appropriate one, and issues a regular multi-component LOOKUP using the selected security mechanism to acquire the filehandle.
对于成功的SNEGO-MCL请求，WebNFS客户端从重载的filehandle检索安全机制数组，选择适当的安全机制，并使用所选安全机制发出常规的多组件查找以获取filehandle。
All subsequent NFS requests are then made using the selected security mechanism and the filehandle.
然后使用所选的安全机制和文件句柄发出所有后续NFS请求。
The following depicts the scenario outlined above. It is assumed that the server shares /export/home as follows:
下面描述了上述场景。假设服务器共享/导出/主页，如下所示：
share -o sec=sec_1:sec_2:sec_3,public /export/home
share -o sec=sec_1:sec_2:sec_3,public /export/home
and AUTH_SYS is the client's default security mechanism and is not one of {sec_1, sec_2, sec_3}.
AUTH_SYS是客户端的默认安全机制，不是{secu_1，secu_2，secu_3}中的一个。
Client Server
------ ------
Client Server
------ ------
LOOKUP FH=0x0, "/export/home"
AUTH_SYS
----------->
<-----------
AUTH_TOOWEAK
LOOKUP FH=0x0, "/export/home"
AUTH_SYS
----------->
<-----------
AUTH_TOOWEAK
LOOKUP FH=0x0, 0x81 0x01 "/export/home"
AUTH_SYS
----------->
<-----------
overloaded FH: length, status, {sec_1 sec_2 sec_3}
LOOKUP FH=0x0, 0x81 0x01 "/export/home"
AUTH_SYS
----------->
<-----------
overloaded FH: length, status, {sec_1 sec_2 sec_3}
LOOKUP FH=0x0, "/export/home"
sec_n
----------->
<-----------
FH = 0x01
LOOKUP FH=0x0, "/export/home"
sec_n
----------->
<-----------
FH = 0x01
NFS request with FH=0x01
sec_n
----------->
<-----------
...
NFS request with FH=0x01
sec_n
----------->
<-----------
...
In the above scenario, the first request is a regular multi-component LOOKUP which fails with the AUTH_TOOWEAK error. The client then issues a SNEGO-MCL request to get the security information.
在上面的场景中，第一个请求是一个常规的多组件查找，该查找失败并出现AUTH_TOOWEAK错误。然后，客户端发出SNEGO-MCL请求以获取安全信息。
There are WebNFS implementations that allow the public filehandle to work with NFS protocol procedures other than LOOKUP. For those WebNFS implementations, if the first request is not a regular multi-component LOOKUP and it fails with AUTH_TOOWEAK, the client should issue a SNEGO-MCL with
有些WebNFS实现允许公共文件句柄与NFS协议过程一起工作，而不是查找。对于那些WebNFS实现，如果第一个请求不是常规的多组件查找，并且由于AUTH_TOOWEAK而失败，那么客户端应该发出一个带有
0x81 0x01 "."
0x81 0x01“
as the path to get the security information.
作为获取安全信息的路径。
The reader may note that no mandatory security mechanisms are specified in the protocol that the client must use in making SNEGO-MCL requests. Normally, the client uses the default security mechanism configured on his system in the first SNEGO-MCL request. If the default security mechanism is not valid the server replies with the AUTH_TOOWEAK error. In this case the server does not return the array of security mechanisms to the client. The client can then make another SNEGO-MCL request using a stronger security mechanism. This continues until the client hits a valid one or has exhausted all the supported security mechanisms.
读者可能会注意到，协议中没有规定客户端在发出SNEGO-MCL请求时必须使用的强制安全机制。通常，客户端在第一个SNEGO-MCL请求中使用在其系统上配置的默认安全机制。如果默认的安全机制无效，服务器将用AUTH_TOOWEAK错误进行回复。在这种情况下，服务器不会将安全机制数组返回给客户端。然后，客户端可以使用更强大的安全机制发出另一个SNEGO-MCL请求。这将一直持续到客户端找到有效的安全机制或用尽所有支持的安全机制。
[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
[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
[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
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. http://www.ietf.org/rfc/rfc2055.txt
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. http://www.ietf.org/rfc/rfc2055.txt
[RFC2203] Eisler, M., Chiu, A. and Ling, L., "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
http://www.ietf.org/rfc/rfc2203.txt
[RFC2203] Eisler, M., Chiu, A. and Ling, L., "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
http://www.ietf.org/rfc/rfc2203.txt
This specification was extensively brainstormed and reviewed by the NFS group of Solaris Software Division.
Solaris软件部门的NFS小组对该规范进行了广泛的头脑风暴讨论和审查。
Alex Chiu Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
加利福尼亚州帕洛阿尔托市圣安东尼奥路901号Alex Chiu Sun Microsystems，Inc.94303
Phone: +1 (650) 786-6465
EMail: alex.chiu@Eng.sun.com
Phone: +1 (650) 786-6465
EMail: alex.chiu@Eng.sun.com
Mike Eisler Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
Mike Eisler Sun Microsystems，Inc.加利福尼亚州帕洛阿尔托市圣安东尼奥路901号，邮编94303
Phone: +1 (719) 599-9026
EMail: michael.eisler@Eng.sun.com
Phone: +1 (719) 599-9026
EMail: michael.eisler@Eng.sun.com
Brent Callaghan Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
Brent Callaghan Sun Microsystems，Inc.加利福尼亚州帕洛阿尔托市圣安东尼奥路901号，邮编94303
Phone: +1 (650) 786-5067
EMail: brent.callaghan@Eng.sun.com
Phone: +1 (650) 786-5067
EMail: brent.callaghan@Eng.sun.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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 implementation 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 developing 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编辑功能的资金目前由互联网协会提供。