Network Working Group A. Chiu
Request for Comments: 2695 Sun Microsystems
Category: Informational September 1999
Network Working Group A. Chiu
Request for Comments: 2695 Sun Microsystems
Category: Informational September 1999
Authentication Mechanisms for ONC RPC
ONC-RPC的身份验证机制
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
ABSTRACT
摘要
This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol.
本文档描述了Sun Microsystems创建的两种身份验证机制，它们通常与ONC远程过程调用（ONC RPC版本2）协议结合使用。
WARNING
警告
The DH authentication as defined in Section 2 in this document refers to the authentication mechanism with flavor AUTH_DH currently implemented in ONC RPC. It uses the underlying Diffie-Hellman algorithm for key exchange. The DH authentication defined in this document is flawed due to the selection of a small prime for the BASE field (Section 2.5). To avoid the flaw a new DH authentication mechanism could be defined with a larger prime. However, the new DH authentication would not be interoperable with the existing DH authentication.
本文件第2节中定义的DH认证是指目前在ONC RPC中实现的带有flavor AUTH_DH的认证机制。它使用底层Diffie-Hellman算法进行密钥交换。本文件中定义的DH认证存在缺陷，因为为基本字段选择了一个小素数（第2.5节）。为了避免该漏洞，可以使用更大的素数定义新的DH身份验证机制。但是，新的DH身份验证将无法与现有的DH身份验证进行互操作。
As illustrated in [10], a large number of attacks are possible on ONC RPC system services that use non-secure authentication mechanisms. Other secure authentication mechanisms need to be developed for ONC RPC. RFC 2203 describes the RPCSEC_GSS ONC RPC security flavor, a secure authentication mechanism that enables RPC protocols to use Generic Security Service Application Program Interface (RFC 2078) to provide security services, integrity and privacy, that are independent of the underlying security mechanisms.
如[10]所示，在使用非安全身份验证机制的ONC RPC系统服务上可能会发生大量攻击。需要为ONC-RPC开发其他安全身份验证机制。RFC 2203描述了RPCSEC_GSS ONC RPC security flavor，这是一种安全身份验证机制，使RPC协议能够使用通用安全服务应用程序接口（RFC 2078）来提供独立于底层安全机制的安全服务、完整性和隐私。
Table of Contents
目录
1. Introduction ............................................... 2
2. Diffie-Hellman Authentication .............................. 2
2.1 Naming .................................................... 3
2.2 DH Authentication Verifiers ............................... 3
2.3 Nicknames and Clock Synchronization ....................... 5
2.4 DH Authentication Protocol Specification .................. 5
2.4.1 The Full Network Name Credential and Verifier (Client) .. 6
2.4.2 The Nickname Credential and Verifier (Client) ........... 8
2.4.3 The Nickname Verifier (Server) .......................... 9
2.5 Diffie-Hellman Encryption ................................. 9
3. Kerberos-based Authentication ............................. 10
3.1 Naming ................................................... 11
3.2 Kerberos-based Authentication Protocol Specification ..... 11
3.2.1 The Full Network Name Credential and Verifier (Client) . 12
3.2.2 The Nickname Credential and Verifier (Client) .......... 14
3.2.3 The Nickname Verifier (Server) ......................... 15
3.2.4 Kerberos-specific Authentication Status Values ......... 15
4. Security Considerations ................................... 16
5. REFERENCES ................................................ 16
6. AUTHOR'S ADDRESS .......................................... 17
7. FULL COPYRIGHT STATEMENT ...................................18
1. Introduction ............................................... 2
2. Diffie-Hellman Authentication .............................. 2
2.1 Naming .................................................... 3
2.2 DH Authentication Verifiers ............................... 3
2.3 Nicknames and Clock Synchronization ....................... 5
2.4 DH Authentication Protocol Specification .................. 5
2.4.1 The Full Network Name Credential and Verifier (Client) .. 6
2.4.2 The Nickname Credential and Verifier (Client) ........... 8
2.4.3 The Nickname Verifier (Server) .......................... 9
2.5 Diffie-Hellman Encryption ................................. 9
3. Kerberos-based Authentication ............................. 10
3.1 Naming ................................................... 11
3.2 Kerberos-based Authentication Protocol Specification ..... 11
3.2.1 The Full Network Name Credential and Verifier (Client) . 12
3.2.2 The Nickname Credential and Verifier (Client) .......... 14
3.2.3 The Nickname Verifier (Server) ......................... 15
3.2.4 Kerberos-specific Authentication Status Values ......... 15
4. Security Considerations ................................... 16
5. REFERENCES ................................................ 16
6. AUTHOR'S ADDRESS .......................................... 17
7. FULL COPYRIGHT STATEMENT ...................................18
The ONC RPC protocol provides the fields necessary for a client to identify itself to a service, and vice-versa, in each call and reply message. Security and access control mechanisms can be built on top of this message authentication. Several different authentication protocols can be supported.
ONC-RPC协议在每个调用和应答消息中提供客户机向服务标识自身所需的字段，反之亦然。安全和访问控制机制可以建立在该消息身份验证之上。可以支持几种不同的身份验证协议。
This document specifies two authentication protocols created by Sun Microsystems that are commonly used: Diffie-Hellman (DH) authentication and Kerberos (Version 4) based authentication.
本文档指定了Sun Microsystems创建的两个常用身份验证协议：Diffie-Hellman（DH）身份验证和基于Kerberos（版本4）的身份验证。
As a prerequisite to reading this document, the reader is expected to be familiar with [1] and [2]. This document uses terminology and definitions from [1] and [2].
作为阅读本文件的先决条件，读者应熟悉[1]和[2]。本文件使用[1]和[2]中的术语和定义。
System authentication (defined in [1]) suffers from some problems. It is very UNIX oriented, and can be easily faked (there is no attempt to provide cryptographically secure authentication).
系统身份验证（定义见[1]）存在一些问题。它非常面向UNIX，并且很容易伪造（没有提供加密安全身份验证的尝试）。
DH authentication was created to address these problems. However, it has been compromised [9] due to the selection of a small length for the prime in the ONC RPC implementation. While the information provided here will be useful for implementors to ensure interoperability with existing applications that use DH authentication, it is strongly recommended that new applications use more secure authentication, and that existing applications that currently use DH authentication migrate to more robust authentication mechanisms.
创建DH身份验证是为了解决这些问题。然而，由于在ONC-RPC实现中为prime选择了较小的长度，它已经受到了影响[9]。虽然此处提供的信息将有助于实施者确保与使用DH身份验证的现有应用程序的互操作性，但强烈建议新应用程序使用更安全的身份验证，并且当前使用DH身份验证的现有应用程序迁移到更强健的身份验证机制。
The client is addressed by a simple string of characters instead of by an operating system specific integer. This string of characters is known as the "netname" or network name of the client. The server is not allowed to interpret the contents of the client's name in any other way except to identify the client. Thus, netnames should be unique for every client in the Internet.
客户端由一个简单的字符串寻址，而不是由操作系统特定的整数寻址。此字符串称为客户端的“网络名”或网络名。不允许服务器以任何其他方式解释客户机名称的内容，除非用于识别客户机。因此，网络名称对于Internet中的每个客户端都应该是唯一的。
It is up to each operating system's implementation of DH authentication to generate netnames for its users that insure this uniqueness when they call upon remote servers. Operating systems already know how to distinguish users local to their systems. It is usually a simple matter to extend this mechanism to the network. For example, a UNIX(tm) user at Sun with a user ID of 515 might be assigned the following netname: "unix.515@sun.com". This netname contains three items that serve to insure it is unique. Going backwards, there is only one naming domain called "sun.com" in the Internet. Within this domain, there is only one UNIX(tm) user with user ID 515. However, there may be another user on another operating system, for example VMS, within the same naming domain that, by coincidence, happens to have the same user ID. To insure that these two users can be distinguished we add the operating system name. So one user is "unix.515@sun.com" and the other is "vms.515@sun.com". The first field is actually a naming method rather than an operating system name. It happens that today there is almost a one-to-one correspondence between naming methods and operating systems. If the world could agree on a naming standard, the first field could be the name of that standard, instead of an operating system name.
由每个操作系统实现DH身份验证来为其用户生成网络名，以确保用户在调用远程服务器时的唯一性。操作系统已经知道如何区分本地用户。将这种机制扩展到网络通常是一件简单的事情。例如，Sun上用户ID为515的UNIX（tm）用户可能被分配以下网络名：“UNIX。515@sun.com". 此网络名包含三项，用于确保其唯一性。回顾过去，互联网上只有一个名为“sun.com”的命名域。在此域中，只有一个用户ID为515的UNIX（tm）用户。但是，在同一命名域中，另一个操作系统（例如VM）上可能有另一个用户碰巧具有相同的用户ID。为了确保可以区分这两个用户，我们添加了操作系统名称。因此，一个用户是“unix”。515@sun.com另一个是“虚拟机”。515@sun.com". 第一个字段实际上是命名方法，而不是操作系统名称。今天，命名方法和操作系统之间几乎是一一对应的。如果世界各国能够就命名标准达成一致，那么第一个字段可以是该标准的名称，而不是操作系统名称。
Unlike System authentication, DH authentication does have a verifier so the server can validate the client's credential (and vice-versa). The contents of this verifier are primarily an encrypted timestamp. The server can decrypt this timestamp, and if it is within an accepted range relative to the current time, then the client must have encrypted it correctly. The only way the client could encrypt
与系统身份验证不同，DH身份验证具有验证器，因此服务器可以验证客户端的凭据（反之亦然）。此验证器的内容主要是加密的时间戳。服务器可以解密此时间戳，如果它在相对于当前时间的可接受范围内，则客户端必须正确加密它。客户端可以加密的唯一方法
it correctly is to know the "conversation key" of the RPC session, and if the client knows the conversation key, then it must be the real client.
正确的做法是知道RPC会话的“会话密钥”，如果客户机知道会话密钥，那么它必须是真正的客户机。
The conversation key is a DES [5] key which the client generates and passes to the server in the first RPC call of a session. The conversation key is encrypted using a public key scheme in this first transaction. The particular public key scheme used in DH authentication is Diffie-Hellman [3] with 192-bit keys. The details of this encryption method are described later.
会话密钥是DES[5]密钥，客户端在会话的第一次RPC调用中生成并传递给服务器。在第一个事务中，使用公钥方案对会话密钥进行加密。DH认证中使用的特定公钥方案是Diffie-Hellman[3]，具有192位密钥。此加密方法的详细信息将在后面描述。
The client and the server need the same notion of the current time in order for all of this to work, perhaps by using the Network Time Protocol [4]. If network time synchronization cannot be guaranteed, then the client can determine the server's time before beginning the conversation using a time request protocol.
客户机和服务器需要相同的当前时间概念，以便所有这些都能工作，可能是通过使用网络时间协议[4]。如果无法保证网络时间同步，则客户端可以在使用时间请求协议开始对话之前确定服务器的时间。
The way a server determines if a client timestamp is valid is somewhat complicated. For any other transaction but the first, the server just checks for two things:
服务器确定客户机时间戳是否有效的方式有些复杂。对于除第一个事务外的任何其他事务，服务器只检查两件事：
(1) the timestamp is greater than the one previously seen from the same client. (2) the timestamp has not expired.
(1) 时间戳大于以前从同一客户端看到的时间戳。（2） 时间戳尚未过期。
A timestamp is expired if the server's time is later than the sum of the client's timestamp plus what is known as the client's "ttl" (standing for "time-to-live" - you can think of this as the lifetime for the client's credential). The "ttl" is a number the client passes (encrypted) to the server in its first transaction.
如果服务器的时间晚于客户机的时间戳加上客户机的“ttl”（代表“生存时间”-您可以将其视为客户机凭据的生存期）之和，则时间戳将过期。“ttl”是客户端在其第一个事务中传递（加密）到服务器的数字。
In the first transaction, the server checks only that the timestamp has not expired. Also, as an added check, the client sends an encrypted item in the first transaction known as the "ttl verifier" which must be equal to the time-to-live minus 1, or the server will reject the credential. If either check fails, the server rejects the credential with an authentication status of AUTH_BADCRED, however if the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
在第一个事务中，服务器只检查时间戳是否未过期。此外，作为附加检查，客户端在第一个事务中发送一个加密项，称为“ttl验证器”，它必须等于生存时间减去1，否则服务器将拒绝凭证。如果任一检查失败，服务器将拒绝身份验证状态为AUTH_REJECTEDCRED的凭据，但是如果时间戳早于之前看到的时间戳，服务器将返回身份验证状态AUTH_REJECTEDCRED。
The client too must check the verifier returned from the server to be sure it is legitimate. The server sends back to the client the timestamp it received from the client, minus one second, encrypted with the conversation key. If the client gets anything different than this, it will reject it, returning an AUTH_INVALIDRESP authentication status to the user.
客户端也必须检查从服务器返回的验证器，以确保其合法性。服务器将从客户端接收到的时间戳（减去1秒）发送回客户端，并使用会话密钥加密。如果客户机得到与此不同的任何内容，它将拒绝它，并向用户返回AUTH_INVALIDRESP身份验证状态。
After the first transaction, the server's DH authentication subsystem returns in its verifier to the client an integer "nickname" which the client may use in its further transactions instead of passing its netname. The nickname could be an index into a table on the server which stores for each client its netname, decrypted conversation key and ttl.
在第一个事务之后，服务器的DH认证子系统在其验证器中向客户端返回一个整数“昵称”，客户端可以在其进一步的事务中使用该昵称，而不是传递其网络名。昵称可以是服务器上一个表的索引，该表为每个客户端存储其网络名、解密的会话密钥和ttl。
Though they originally were synchronized, the client's and server's clocks can get out of synchronization again. When this happens the server returns to the client an authentication status of AUTH_REJECTEDVERF at which point the client should attempt to resynchronize.
虽然它们最初是同步的，但客户端和服务器的时钟可能会再次失去同步。发生这种情况时，服务器将向客户端返回身份验证状态AUTH_REJECTEDVERF，此时客户端应尝试重新同步。
A client may also get an AUTH_BADCRED error when using a nickname that was previously valid. The reason is that the server's nickname table is a limited size, and it may flush entries whenever it wants. A client should resend its original full name credential in this case and the server will give it a new nickname. If a server crashes, the entire nickname table gets flushed, and all clients will have to resend their original credentials.
客户机在使用以前有效的昵称时也可能会出现AUTH_BADCRED错误。原因是服务器的昵称表大小有限，它可以随时刷新条目。在这种情况下，客户端应重新发送其原始全名凭据，服务器将给它一个新的昵称。如果服务器崩溃，将刷新整个昵称表，所有客户端都必须重新发送其原始凭据。
There are two kinds of credentials: one in which the client uses its full network name, and one in which it uses its "nickname" (just an unsigned integer) given to it by the server. The client must use its fullname in its first transaction with the server, in which the server will return to the client its nickname. The client may use its nickname in all further transactions with the server. There is no requirement to use the nickname, but it is wise to use it for performance reasons.
有两种凭据：一种是客户端使用其完整的网络名称，另一种是使用服务器提供给它的“昵称”（仅为无符号整数）。客户端必须在与服务器的第一个事务中使用其全名，在该事务中，服务器将向客户端返回其昵称。客户端可以在与服务器的所有后续事务中使用其昵称。没有使用昵称的要求，但出于性能原因使用昵称是明智的。
The following definitions are used for describing the protocol:
以下定义用于描述协议：
enum authdh_namekind {
ADN_FULLNAME = 0,
ADN_NICKNAME = 1
};
enum authdh_namekind {
ADN_FULLNAME = 0,
ADN_NICKNAME = 1
};
typedef opaque des_block[8]; /* 64-bit block of encrypted data */
typedef opaque des_block[8]; /* 64-bit block of encrypted data */
const MAXNETNAMELEN = 255; /* maximum length of a netname */
const MAXNETNAMELEN = 255; /* maximum length of a netname */
The flavor used for all DH authentication credentials and verifiers is "AUTH_DH", with the numerical value 3. The opaque data constituting the client credential encodes the following structure:
用于所有DH身份验证凭据和验证器的样式为“AUTH_DH”，数值为3。构成客户端凭据的不透明数据编码以下结构：
union authdh_cred switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname fullname;
case ADN_NICKNAME:
authdh_nickname nickname;
};
union authdh_cred switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname fullname;
case ADN_NICKNAME:
authdh_nickname nickname;
};
The opaque data constituting a verifier that accompanies a client credential encodes the following structure:
与客户端凭证一起构成验证器的不透明数据编码以下结构：
union authdh_verf switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname_verf fullname_verf;
case ADN_NICKNAME:
authdh_nickname_verf nickname_verf;
};
union authdh_verf switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname_verf fullname_verf;
case ADN_NICKNAME:
authdh_nickname_verf nickname_verf;
};
The opaque data constituting a verifier returned by a server in response to a client request encodes the following structure:
服务器响应客户端请求返回的构成验证器的不透明数据编码以下结构：
struct authdh_server_verf;
结构authd_server_verf；
These structures are described in detail below.
下文详细描述了这些结构。
First, the client creates a conversation key for the session. Next, the client fills out the following structure:
首先，客户端为会话创建会话密钥。接下来，客户机填写以下结构：
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
The fields are stored in XDR (external data representation) format. The timestamp encodes the time since midnight, January 1, 1970. These 128 bits of data are then encrypted in the DES CBC mode, using the conversation key for the session, and with an initialization vector of 0. This yields:
字段以XDR（外部数据表示）格式存储。时间戳对1970年1月1日午夜后的时间进行编码。然后，在DES CBC模式下，使用会话密钥和初始化向量0对这128位数据进行加密。这将产生：
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
where T1, T2, W1, and W2 are all 32-bit quantities, and have some correspondence to the original quantities occupying their positions, but are now interdependent on each other for proper decryption. The 64 bit sequence comprising T1 and T2 is denoted by T.
其中T1、T2、W1和W2都是32位量，并且与占据其位置的原始量有一些对应关系，但是现在为了正确解密，它们相互依赖。包括T1和T2的64位序列由T表示。
The full network name credential is represented as follows using XDR notation:
完整的网络名称凭据使用XDR表示法表示如下：
struct authdh_fullname {
string name<MAXNETNAMELEN>; /* netname of client */
des_block key; /* encrypted conversation key */
opaque w1[4]; /* W1 */
};
struct authdh_fullname {
string name<MAXNETNAMELEN>; /* netname of client */
des_block key; /* encrypted conversation key */
opaque w1[4]; /* W1 */
};
The conversation key is encrypted using the "common key" using the ECB mode. The common key is a DES key that is derived from the Diffie-Hellman public and private keys, and is described later.
对话密钥使用ECB模式的“公共密钥”进行加密。公共密钥是从Diffie-Hellman公钥和私钥派生的DES密钥，稍后将对其进行描述。
The verifier is represented as follows:
验证者的代表如下：
struct authdh_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
struct authdh_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
Note that all of the encrypted quantities (key, w1, w2, timestamp) in the above structures are opaque.
注意，上述结构中的所有加密量（key、w1、w2、timestamp）都是不透明的。
The fullname credential and its associated verifier together contain the network name of the client, an encrypted conversation key, the ttl, a timestamp, and a ttl verifier that is one less than the ttl. The ttl is actually the lifetime for the credential. The server will accept the credential if the current server time is "within" the time indicated in the timestamp plus the ttl. Otherwise, the server rejects the credential with an authentication status of AUTH_BADCRED. One way to insure that requests are not replayed would be for the server to insist that timestamps are greater than the previous one seen, unless it is the first transaction. If the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
全名凭据及其关联的验证器一起包含客户端的网络名称、加密的会话密钥、ttl、时间戳和比ttl少一个的ttl验证器。ttl实际上是凭证的生存期。如果当前服务器时间在时间戳加上ttl中指示的时间内，则服务器将接受凭据。否则，服务器将拒绝身份验证状态为AUTH_BADCRED的凭据。确保请求不被重放的一种方法是服务器坚持时间戳大于之前看到的时间戳，除非它是第一个事务。如果时间戳早于之前看到的时间戳，服务器将返回身份验证状态AUTH_REJECTEDCRED。
The server returns a authdh_server_verf structure, which is described in detail below. This structure contains a "nickname", which may be used for subsequent requests in the current conversation.
服务器返回authdh_server_verf结构，详细描述如下。此结构包含一个“昵称”，可用于当前会话中的后续请求。
In transactions following the first, the client may use the shorter nickname credential and verifier for efficiency. First, the client fills out the following structure:
在第一个之后的事务中，为了提高效率，客户端可以使用较短的昵称凭证和验证器。首先，客户机填写以下结构：
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
The fields are stored in XDR (external data representation) format. These 64 bits of data are then encrypted in the DES ECB mode, using the conversation key for the session. This yields:
字段以XDR（外部数据表示）格式存储。然后使用会话密钥在DES ECB模式下对这64位数据进行加密。这将产生：
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
The nickname credential is represented as follows using XDR notation:
昵称凭证使用XDR表示法表示如下：
struct authdh_nickname {
unsigned int nickname; /* nickname returned by server */
};
struct authdh_nickname {
unsigned int nickname; /* nickname returned by server */
};
The nickname verifier is represented as follows using XDR notation:
昵称验证器使用XDR符号表示如下：
struct authdh_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
struct authdh_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
The nickname credential may be reject by the server for several reasons. An authentication status of AUTH_BADCRED indicates that the nickname is no longer valid. The client should retry the request using the fullname credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not valid. Again, the client should retry the request using the fullname credential.
服务器可能会出于多种原因拒绝昵称凭据。身份验证状态为AUTH_BADCRED表示昵称不再有效。客户端应使用全名凭据重试请求。AUTH_REJECTEDVERF表示昵称验证程序无效。同样，客户端应该使用全名凭据重试请求。
The server never returns a credential. It returns only one kind of verifier, i.e., the nickname verifier. This has the following XDR representation:
服务器从不返回凭据。它只返回一种验证器，即昵称验证器。它具有以下XDR表示形式：
struct authdh_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
struct authdh_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
The timestamp verifier is constructed in exactly the same way as the client nickname credential. The server sets the timestamp value to the value the client sent minus one second and encrypts it in DES ECB mode using the conversation key. The server also sends the client a nickname to be used in future transactions (unencrypted).
时间戳验证器的构造方式与客户端昵称凭据完全相同。服务器将时间戳值设置为客户端发送的值减去1秒，并使用会话密钥在DES ECB模式下对其进行加密。服务器还向客户端发送一个昵称，以便在将来的事务中使用（未加密）。
In this scheme, there are two constants "BASE" and "MODULUS" [3]. The particular values Sun has chosen for these for the DH authentication protocol are:
在这个方案中，有两个常数“基”和“模”[3]。Sun为DH认证协议选择的特定值为：
const BASE = 3;
const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";
const BASE = 3;
const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";
Note that the modulus is represented above as a hexadecimal string.
请注意，上面的模数表示为十六进制字符串。
The way this scheme works is best explained by an example. Suppose there are two people "A" and "B" who want to send encrypted messages to each other. So, A and B both generate "secret" keys at random which they do not reveal to anyone. Let these keys be represented as SK(A) and SK(B). They also publish in a public directory their "public" keys. These keys are computed as follows:
这个方案的工作方式最好用一个例子来解释。假设有两个人“A”和“B”想要互相发送加密消息。因此，A和B都随机生成“秘密”密钥，不会泄露给任何人。让这些密钥表示为SK（A）和SK（B）。它们还将其“公共”密钥发布到公共目录中。这些关键点的计算如下：
PK(A) = ( BASE ** SK(A) ) mod MODULUS
PK(B) = ( BASE ** SK(B) ) mod MODULUS
PK(A) = ( BASE ** SK(A) ) mod MODULUS
PK(B) = ( BASE ** SK(B) ) mod MODULUS
The "**" notation is used here to represent exponentiation. Now, both A and B can arrive at the "common" key between them, represented here as CK(A, B), without revealing their secret keys.
此处使用“**”符号表示幂运算。现在，A和B都可以得到它们之间的“公共”密钥，在这里表示为CK（A，B），而不暴露它们的秘密密钥。
A computes:
A计算：
CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS
CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS
while B computes:
B计算：
CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS
CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS
These two can be shown to be equivalent:
这两者可以被证明是等效的：
(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS
(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS
We drop the "mod MODULUS" parts and assume modulo arithmetic to simplify things:
我们去掉“模-模”部分，采用模运算来简化事情：
PK(B) ** SK(A) = PK(A) ** SK(B)
PK(B) ** SK(A) = PK(A) ** SK(B)
Then, replace PK(B) by what B computed earlier and likewise for PK(A).
然后，将PK（B）替换为B先前计算的值，同样替换PK（A）。
(BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)
(BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)
which leads to:
这导致：
BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))
BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))
This common key CK(A, B) is not used to encrypt the timestamps used in the protocol. Rather, it is used only to encrypt a conversation key which is then used to encrypt the timestamps. The reason for doing this is to use the common key as little as possible, for fear that it could be broken. Breaking the conversation key is a far less damaging, since conversations are relatively short-lived.
此公共密钥CK（A，B）不用于加密协议中使用的时间戳。相反，它仅用于加密会话密钥，然后用于加密时间戳。这样做的原因是尽可能少地使用公共密钥，以免它被破坏。破坏会话密钥的破坏性要小得多，因为会话的寿命相对较短。
The conversation key is encrypted using 56-bit DES keys, yet the common key is 192 bits. To reduce the number of bits, 56 bits are selected from the common key as follows. The middle-most 8-bytes are selected from the common key, and then parity is added to the lower order bit of each byte, producing a 56-bit key with 8 bits of parity.
会话密钥使用56位DES密钥加密，而公共密钥为192位。为了减少位数，从公共密钥中选择56位，如下所示。从公共密钥中选择最中间的8个字节，然后将奇偶校验添加到每个字节的低位，生成一个具有8位奇偶校验的56位密钥。
Only 48 bits of the 8-byte conversation key are used in the DH Authentication scheme. The least and most significant bits of each byte of the conversation key are unused.
DH身份验证方案中仅使用8字节对话密钥的48位。会话密钥每个字节的最低和最高有效位未使用。
Conceptually, Kerberos-based authentication is very similar to DH authentication. The major difference is, Kerberos-based authentication takes advantage of the fact that Kerberos tickets have
从概念上讲，基于Kerberos的身份验证与DH身份验证非常相似。主要区别在于，基于Kerberos的身份验证利用了Kerberos票证具有
encoded in them the client name and the conversation key. This RFC does not describe Kerberos name syntax, protocols and ticket formats. The reader is referred to [6], [7], and [8].
将客户端名称和会话密钥编码在其中。此RFC不描述Kerberos名称语法、协议和票证格式。读者参考[6]、[7]和[8]。
A Kerberos name contains three parts. The first is the principal name, which is usually a user's or service's name. The second is the instance, which in the case of a user is usually NULL. Some users may have privileged instances, however, such as root or admin. In the case of a service, the instance is the name of the machine on which it runs; that is, there can be an NFS service running on the machine ABC, which is different from the NFS service running on the machine XYZ. The third part of a Kerberos name is the realm. The realm corresponds to the Kerberos service providing authentication for the principal. When writing a Kerberos name, the principal name is separated from the instance (if not NULL) by a period, and the realm (if not the local realm) follows, preceded by an "@" sign. The following are examples of valid Kerberos names:
Kerberos名称包含三个部分。第一个是主体名称，通常是用户或服务的名称。第二个是实例，在用户的情况下，该实例通常为NULL。但是，有些用户可能具有特权实例，例如root或admin。对于服务，实例是它运行的机器的名称；也就是说，机器ABC上可能运行NFS服务，这与机器XYZ上运行的NFS服务不同。Kerberos名称的第三部分是领域。领域对应于为主体提供身份验证的Kerberos服务。在编写Kerberos名称时，主体名称与实例（如果不是NULL）之间用句点分隔，域（如果不是本地域）后跟“@”符号。以下是有效Kerberos名称的示例：
billb jis.admin srz@lcs.mit.edu treese.root@athena.mit.edu
billb jis.adminsrz@lcs.mit.edu特雷斯。root@athena.mit.edu
The Kerberos-based authentication protocol described is based on Kerberos version 4.
描述的基于Kerberos的身份验证协议基于Kerberos版本4。
There are two kinds of credentials: one in which the client uses its full network name, and one in which it uses its "nickname" (just an unsigned integer) given to it by the server. The client must use its fullname in its first transaction with the server, in which the server will return to the client its nickname. The client may use its nickname in all further transactions with the server. There is no requirement to use the nickname, but it is wise to use it for performance reasons.
有两种凭据：一种是客户端使用其完整的网络名称，另一种是使用服务器提供给它的“昵称”（仅为无符号整数）。客户端必须在与服务器的第一个事务中使用其全名，在该事务中，服务器将向客户端返回其昵称。客户端可以在与服务器的所有后续事务中使用其昵称。没有使用昵称的要求，但出于性能原因使用昵称是明智的。
The following definitions are used for describing the protocol:
以下定义用于描述协议：
enum authkerb4_namekind {
AKN_FULLNAME = 0,
AKN_NICKNAME = 1
};
enum authkerb4_namekind {
AKN_FULLNAME = 0,
AKN_NICKNAME = 1
};
The flavor used for all Kerberos-based authentication credentials and verifiers is "AUTH_KERB4", with numerical value 4. The opaque data constituting the client credential encodes the following structure:
用于所有基于Kerberos的身份验证凭据和验证器的风格是“AUTH_KERB4”，数值为4。构成客户端凭据的不透明数据编码以下结构：
union authkerb4_cred switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname fullname;
case AKN_NICKNAME:
authkerb4_nickname nickname;
};
union authkerb4_cred switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname fullname;
case AKN_NICKNAME:
authkerb4_nickname nickname;
};
The opaque data constituting a verifier that accompanies a client credential encodes the following structure:
与客户端凭证一起构成验证器的不透明数据编码以下结构：
union authkerb4_verf switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname_verf fullname_verf;
case AKN_NICKNAME:
authkerb4_nickname_verf nickname_verf;
};
union authkerb4_verf switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname_verf fullname_verf;
case AKN_NICKNAME:
authkerb4_nickname_verf nickname_verf;
};
The opaque data constituting a verifier returned by a server in response to a client request encodes the following structure:
服务器响应客户端请求返回的构成验证器的不透明数据编码以下结构：
struct authkerb4_server_verf;
结构authkerb4\u服务器\u版本；
These structures are described in detail below.
下文详细描述了这些结构。
First, the client must obtain a Kerberos ticket from the Kerberos Server. The ticket contains a Kerberos session key, which will become the conversation key. Next, the client fills out the following structure:
首先，客户端必须从Kerberos服务器获取Kerberos票证。票证包含一个Kerberos会话密钥，该密钥将成为会话密钥。接下来，客户机填写以下结构：
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
The fields are stored in XDR (external data representation) format. The timestamp encodes the time since midnight, January 1, 1970. "ttl" is identical in meaning to the corresponding field in Diffie-Hellman authentication: the credential "time-to-live" for the
字段以XDR（外部数据表示）格式存储。时间戳对1970年1月1日午夜后的时间进行编码。“ttl”在含义上与Diffie-Hellman身份验证中的相应字段相同：证书的“生存时间”
conversation being initiated. These 128 bits of data are then encrypted in the DES CBC mode, using the conversation key, and with an initialization vector of 0. This yields:
正在启动对话。然后，在DES CBC模式下，使用会话密钥和0的初始化向量对这128位数据进行加密。这将产生：
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
where T1, T2, W1, and W2 are all 32-bit quantities, and have some correspondence to the original quantities occupying their positions, but are now interdependent on each other for proper decryption. The 64 bit sequence comprising T1 and T2 is denoted by T.
其中T1、T2、W1和W2都是32位量，并且与占据其位置的原始量有一些对应关系，但是现在为了正确解密，它们相互依赖。包括T1和T2的64位序列由T表示。
The full network name credential is represented as follows using XDR notation:
完整的网络名称凭据使用XDR表示法表示如下：
struct authkerb4_fullname {
opaque ticket<>; /* kerberos ticket for the server */
opaque w1[4]; /* W1 */
};
struct authkerb4_fullname {
opaque ticket<>; /* kerberos ticket for the server */
opaque w1[4]; /* W1 */
};
The verifier is represented as follows:
验证者的代表如下：
struct authkerb4_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
struct authkerb4_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
Note that all of the client-encrypted quantities (w1, w2, timestamp) in the above structures are opaque. The client does not encrypt the Kerberos ticket for the server.
请注意，上述结构中的所有客户端加密量（w1、w2、时间戳）都是不透明的。客户端不加密服务器的Kerberos票证。
The fullname credential and its associated verifier together contain the Kerberos ticket (which contains the client name and the conversation key), the ttl, a timestamp, and a ttl verifier that is one less than the ttl. The ttl is actually the lifetime for the credential. The server will accept the credential if the current server time is "within" the time indicated in the timestamp plus the ttl. Otherwise, the server rejects the credential with an authentication status of AUTH_BADCRED. One way to insure that requests are not replayed would be for the server to insist that timestamps are greater than the previous one seen, unless it is the first transaction. If the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
全名凭据及其关联的验证器一起包含Kerberos票证（其中包含客户端名称和会话密钥）、ttl、时间戳和比ttl少一个的ttl验证器。ttl实际上是凭证的生存期。如果当前服务器时间在时间戳加上ttl中指示的时间内，则服务器将接受凭据。否则，服务器将拒绝身份验证状态为AUTH_BADCRED的凭据。确保请求不被重放的一种方法是服务器坚持时间戳大于之前看到的时间戳，除非它是第一个事务。如果时间戳早于之前看到的时间戳，服务器将返回身份验证状态AUTH_REJECTEDCRED。
The server returns a authkerb4_server_verf structure, which is described in detail below. This structure contains a "nickname", which may be used for subsequent requests in the current session.
服务器返回一个authkerb4\u server\u verf结构，下面将详细描述该结构。此结构包含一个“昵称”，可用于当前会话中的后续请求。
In transactions following the first, the client may use the shorter nickname credential and verifier for efficiency. First, the client fills out the following structure:
在第一个之后的事务中，为了提高效率，客户端可以使用较短的昵称凭证和验证器。首先，客户机填写以下结构：
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
The fields are stored in XDR (external data representation) format. These 64 bits of data are then encrypted in the DES ECB mode, using the conversation key for the session. This yields:
字段以XDR（外部数据表示）格式存储。然后使用会话密钥在DES ECB模式下对这64位数据进行加密。这将产生：
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
The nickname credential is represented as follows using XDR notation:
昵称凭证使用XDR表示法表示如下：
struct authkerb4_nickname {
unsigned int nickname; /* nickname returned by server */
};
struct authkerb4_nickname {
unsigned int nickname; /* nickname returned by server */
};
The nickname verifier is represented as follows using XDR notation:
昵称验证器使用XDR符号表示如下：
struct authkerb4_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
struct authkerb4_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
The nickname credential may be reject by the server for several reasons. An authentication status of AUTH_BADCRED indicates that the nickname is no longer valid. The client should retry the request using the fullname credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not valid. Again, the client should retry the
服务器可能会出于多种原因拒绝昵称凭据。身份验证状态为AUTH_BADCRED表示昵称不再有效。客户端应使用全名凭据重试请求。AUTH_REJECTEDVERF表示昵称验证程序无效。同样，客户端应该重试
request using the fullname credential. AUTH_TIMEEXPIRE indicates that the session's Kerberos ticket has expired. The client should initiate a new session by obtaining a new Kerberos ticket.
使用全名凭据请求。AUTH_TIMEEXPIRE表示会话的Kerberos票证已过期。客户端应通过获取新的Kerberos票证来启动新会话。
The server never returns a credential. It returns only one kind of verifier, i.e., the nickname verifier. This has the following XDR representation:
服务器从不返回凭据。它只返回一种验证器，即昵称验证器。它具有以下XDR表示形式：
struct authkerb4_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
struct authkerb4_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
The timestamp verifier is constructed in exactly the same way as the client nickname credential. The server sets the timestamp value to the value the client sent minus one second and encrypts it in DES ECB mode using the conversation key. The server also sends the client a nickname to be used in future transactions (unencrypted).
时间戳验证器的构造方式与客户端昵称凭据完全相同。服务器将时间戳值设置为客户端发送的值减去1秒，并使用会话密钥在DES ECB模式下对其进行加密。服务器还向客户端发送一个昵称，以便在将来的事务中使用（未加密）。
The server may return to the client one of the following errors in the authentication status field:
服务器可能会在“身份验证状态”字段中向客户端返回以下错误之一：
enum auth_stat {
...
/*
* kerberos errors
*/
AUTH_KERB_GENERIC = 8, /* Any Kerberos-specific error other
than the following */
AUTH_TIMEEXPIRE = 9, /* The client's ticket has expired */
AUTH_TKT_FILE = 10, /* The server was unable to find the
ticket file. The client should
create a new session by obtaining a
new ticket */
AUTH_DECODE = 11, /* The server is unable to decode the
authenticator of the client's ticket */
AUTH_NET_ADDR = 12 /* The network address of the client
does not match the address contained
in the ticket */
enum auth_stat {
...
/*
* kerberos errors
*/
AUTH_KERB_GENERIC = 8, /* Any Kerberos-specific error other
than the following */
AUTH_TIMEEXPIRE = 9, /* The client's ticket has expired */
AUTH_TKT_FILE = 10, /* The server was unable to find the
ticket file. The client should
create a new session by obtaining a
new ticket */
AUTH_DECODE = 11, /* The server is unable to decode the
authenticator of the client's ticket */
AUTH_NET_ADDR = 12 /* The network address of the client
does not match the address contained
in the ticket */
/* and more to be defined */
};
/* and more to be defined */
};
The DH authentication mechanism and the Kerberos V4 authentication mechanism are described in this document only for informational purposes.
本文档中描述的DH身份验证机制和Kerberos V4身份验证机制仅供参考。
In addition to the weakness pointed out earlier in this document (see WARNING on page 1), the two security mechanisms described herein lack the support for integrity and privacy data protection. It is strongly recommended that new applications use more secure mechanisms, and that existing applications migrate to more robust mechanisms.
除了本文档前面指出的弱点（参见第1页的警告），本文描述的两种安全机制缺乏对完整性和隐私数据保护的支持。强烈建议新应用程序使用更安全的机制，并建议现有应用程序迁移到更健壮的机制。
The RPCSEC_GSS ONC RPC security flavor, specified in RFC 2203, allows applications built on top of RPC to access security mechanisms that adhere to the GSS-API specification. It provides a GSS-API based security framework that allows for strong security mechanisms. RFC 1964 describes the Kerberos Version 5 GSS-API security mechanism which provides integrity and privacy, in addition to authentication. RFC 2623 [14] describes how Kerberos V5 is pluggued into RPCSEC_GSS, and how the Version 2 and Version 3 of the NFS protocol use Kerberos V5 via RPCSEC_GSS. The RPCSEC_GSS/GSS-API/Kerberos-V5 stack provides a robust security mechanism for applications that require strong protection.
RFC 2203中指定的RPCSEC_GSS ONC RPC安全特性允许在RPC之上构建的应用程序访问符合GSS-API规范的安全机制。它提供了一个基于GSS-API的安全框架，支持强大的安全机制。RFC1964描述了Kerberos版本5 GSS-API安全机制，该机制除了提供身份验证外，还提供完整性和隐私。RFC 2623[14]描述了如何将Kerberos V5插入RPCSEC_GSS，以及NFS协议的版本2和版本3如何通过RPCSEC_GSS使用Kerberos V5。RPCSEC_GSS/GSS-API/Kerberos-V5堆栈为需要强大保护的应用程序提供了强健的安全机制。
[1] Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC 1831, August 1995.
[1] Srinivasan，R.，“远程过程调用协议版本2”，RFC 18311995年8月。
[2] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[2] Srinivasan，R.，“XDR：外部数据表示标准”，RFC 1832，1995年8月。
[3] Diffie & Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory IT-22, November 1976.
[3] Diffie&Hellman，“密码学的新方向”，IEEE信息论交易IT-22，1976年11月。
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992.
[4] Mills，D.，“网络时间协议（版本3）”，RFC13051992年3月。
[5] National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standards Publication 46, January 1977.
[5] 国家标准局，“数据加密标准”，联邦信息处理标准出版物46，1977年1月。
[6] Miller, S., Neuman, C., Schiller, J. and J. Saltzer, "Section E.2.1: Kerberos Authentication and Authorization System", December 1987.
[6] Miller，S.，Neuman，C.，Schiller，J.和J.Saltzer，“第E.2.1节：Kerberos身份验证和授权系统”，1987年12月。
[7] Steiner, J., Neuman, C. and J. Schiller, "Kerberos: An Authentication Service for Open Network Systems", pp. 191-202 in Usenix Conference Proceedings, Dallas, Texas, February, 1988.
[7] Steiner，J.，Neuman，C.和J.Schiller，“Kerberos：开放网络系统的身份验证服务”，第191-202页，Usenix会议记录，德克萨斯州达拉斯，1988年2月。
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[8] Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[9] La Macchia, B.A., and Odlyzko, A.M., "Computation of Discrete Logarithms in Prime Fields", pp. 47-62 in "Designs, Codes and Cryptography", Kluwer Academic Publishers, 1991.
[9] La Macchia，B.A.和Odlyzko，A.M.，“素域中离散对数的计算”，Kluwer学术出版社，1991年，“设计、编码和密码学”第47-62页。
[10] Cheswick, W.R., and Bellovin, S.M., "Firewalls and Internet Security," Addison-Wesley, 1995.
[10] Cheswick，W.R.和Bellovin，S.M.，“防火墙和互联网安全”，Addison-Wesley，1995年。
[11] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[11] 林恩，J.，“Kerberos版本5 GSS-API机制”，RFC1964，1996年6月。
[12] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[12] 林恩，J.，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。
[13] Eisler, M., Chiu, A., and Ling, L., "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[13] Eisler，M.，Chiu，A.，和Ling，L.，“RPCSEC_GSS协议规范”，RFC 2203，1997年9月。
[14] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[14] Eisler，M.，“NFS版本2和版本3的安全问题以及NFS协议对RPCSEC_GSS和Kerberos V5的使用”，RFC 2623，1999年6月。
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
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 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编辑功能的资金目前由互联网协会提供。