Internet Engineering Task Force (IETF) W. Adamson
Request for Comments: 7861 NetApp
Updates: 5403 N. Williams
Category: Standards Track Cryptonector
ISSN: 2070-1721 November 2016
Internet Engineering Task Force (IETF) W. Adamson
Request for Comments: 7861 NetApp
Updates: 5403 N. Williams
Category: Standards Track Cryptonector
ISSN: 2070-1721 November 2016
Remote Procedure Call (RPC) Security Version 3
远程过程调用（RPC）安全版本3
Abstract
摘要
This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings. This document updates RFC 5403.
本文档指定了远程过程调用（RPC）安全协议（RPCSEC_GSS）的版本3。此协议支持客户端主机和用户主体到服务器的多主体身份验证（由泛型组合构造）、用于多级安全和类型强制的安全标签断言、结构化权限断言和通道绑定。本文档更新了RFC 5403。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7861.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7861.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Motivation .....................................2
1.1. Requirements Language ......................................3
1.2. Added Functionality ........................................4
1.3. XDR Code Extraction ........................................5
2. The RPCSEC_GSSv3 Protocol .......................................6
2.1. Compatibility with RPCSEC_GSSv2 ............................6
2.2. Version Negotiation ........................................6
2.3. New Reply Verifier .........................................7
2.4. XDR Code Preliminaries .....................................8
2.5. RPCSEC_GSS_BIND_CHANNEL Operation .........................10
2.6. New auth_stat Values ......................................10
2.7. New Control Procedures ....................................10
2.7.1. New Control Procedure - RPCSEC_GSS_CREATE ..........12
2.7.2. New Control Procedure - RPCSEC_GSS_LIST ............20
2.8. Extensibility .............................................21
3. Operational Recommendation for Deployment ......................21
4. Security Considerations ........................................21
5. IANA Considerations ............................................22
5.1. New RPC Authentication Status Numbers .....................22
5.2. Structured Privilege Name Definitions .....................23
5.2.1. Initial Registry ...................................24
5.2.2. Updating Registrations .............................24
6. References .....................................................25
6.1. Normative References ......................................25
6.2. Informative References ....................................26
Acknowledgments ...................................................26
Authors' Addresses ................................................26
1. Introduction and Motivation .....................................2
1.1. Requirements Language ......................................3
1.2. Added Functionality ........................................4
1.3. XDR Code Extraction ........................................5
2. The RPCSEC_GSSv3 Protocol .......................................6
2.1. Compatibility with RPCSEC_GSSv2 ............................6
2.2. Version Negotiation ........................................6
2.3. New Reply Verifier .........................................7
2.4. XDR Code Preliminaries .....................................8
2.5. RPCSEC_GSS_BIND_CHANNEL Operation .........................10
2.6. New auth_stat Values ......................................10
2.7. New Control Procedures ....................................10
2.7.1. New Control Procedure - RPCSEC_GSS_CREATE ..........12
2.7.2. New Control Procedure - RPCSEC_GSS_LIST ............20
2.8. Extensibility .............................................21
3. Operational Recommendation for Deployment ......................21
4. Security Considerations ........................................21
5. IANA Considerations ............................................22
5.1. New RPC Authentication Status Numbers .....................22
5.2. Structured Privilege Name Definitions .....................23
5.2.1. Initial Registry ...................................24
5.2.2. Updating Registrations .............................24
6. References .....................................................25
6.1. Normative References ......................................25
6.2. Informative References ....................................26
Acknowledgments ...................................................26
Authors' Addresses ................................................26
The original Remote Procedure Call (RPC) security protocol (RPCSEC_GSS) [RFC2203] provided for authentication of RPC clients and servers to each other using the Generic Security Service Application Programming Interface (GSS-API) [RFC2743]. The second version of RPCSEC_GSS [RFC5403] added support for channel bindings [RFC5056].
原始远程过程调用（RPC）安全协议（RPCSEC_GSS）[RFC2203]用于使用通用安全服务应用程序编程接口（GSS-API）[RFC2743]相互验证RPC客户端和服务器。RPCSEC_GSS[RFC5403]的第二个版本增加了对通道绑定[RFC5056]的支持。
Existing GSS-API mechanisms are insufficient for communicating certain authorization and authentication information to a server. The GSS-API and its mechanisms certainly could be extended to address this shortcoming. However, it is addressed here at the application layer, i.e., in RPCSEC_GSS.
现有的GSS-API机制不足以将某些授权和身份验证信息传递给服务器。GSS-API及其机制当然可以扩展以解决这一缺陷。然而，它在这里是在应用层解决的，即在RPCSEC_GSS中。
A major motivation for version 3 of RPCSEC_GSS (RPCSEC_GSSv3) is to add support for multi-level (labeled) security and server-side copy for NFSv4.
RPCSEC_GSS（RPCSEC_GSSv3）版本3的一个主要动机是为NFSv4添加对多级（标记）安全性和服务器端拷贝的支持。
Multi-Level Security (MLS) is a traditional model where subjects (processes) are given a security level (Unclassified, Secret, Top Secret, etc.) and objects (files) are given security labels that mandate the access of the subject to the object (see Section 9.1 of [RFC7862]).
多级安全（MLS）是一种传统模式，其中主体（流程）被赋予安全级别（非机密、机密、绝密等），对象（文件）被赋予安全标签，要求主体访问对象（见[RFC7862]第9.1节）。
Labeled NFS (see Section 9 of [RFC7862]) uses an MLS policy with Mandatory Access Control (MAC) systems as defined in [RFC4949]. Labeled NFS stores MAC file object labels on the NFS server and enables client Guest Mode MAC as described in Section 9.5.3 of [RFC7862]. RPCSEC_GSSv3 label assertions assert client MAC process subject labels to enable Full Mode MAC when combined with Labeled NFS as described in Section 9.5.1 of [RFC7862].
带标签的NFS（参见[RFC7862]第9节）使用MLS策略和[RFC4949]中定义的强制访问控制（MAC）系统。带标签的NFS将MAC文件对象标签存储在NFS服务器上，并按照[RFC7862]第9.5.3节所述启用客户端来宾模式MAC。如[RFC7862]第9.5.1节所述，RPCSEC_GSSv3标签断言断言客户端MAC进程主题标签，以在与带标签的NFS组合时启用全模式MAC。
A traditional inter-server file copy entails the user gaining access to a file on the source, reading it, and writing it to a file on the destination. In secure NFSv4 inter-server server-side copy (see Section 4 of [RFC7862]), the user first secures access to both source and destination files and then uses NFSv4.2-defined RPCSEC_GSSv3 structured privileges to authorize the destination to copy the file from the source on behalf of the user.
传统的服务器间文件拷贝要求用户访问源上的文件，读取该文件，然后将其写入目标上的文件。在安全的NFSv4服务器间服务器端拷贝（参见[RFC7862]第4节）中，用户首先保护对源文件和目标文件的访问，然后使用NFSv4.2定义的RPCSEC_GSSv3结构化权限授权目标代表用户从源复制文件。
Multi-principal authentication can be used to address shared cache poisoning attacks (see Section 9 of [AFS-RXGK]) on the client cache by a user. As described in Section 7 of [AFS-RXGK], multi-user machines with a single cache manager can fetch and cache data on a user's behalf and re-display it for another user from the cache without refetching the data from the server. The initial data acquisition is authenticated by the first user's credentials, and if only that user's credentials are used, it may be possible for a malicious user or users to "poison" the cache for other users by introducing bogus data into the cache.
多主体身份验证可用于解决用户对客户端缓存的共享缓存中毒攻击（参见[AFS-RXGK]第9节）。如[AFS-RXGK]第7节所述，具有单个缓存管理器的多用户机器可以代表用户获取和缓存数据，并从缓存中为另一用户重新显示数据，而无需从服务器重新读取数据。初始数据采集由第一个用户的凭据进行身份验证，如果仅使用该用户的凭据，则恶意用户可能通过将虚假数据引入缓存来“毒害”其他用户的缓存。
Another use of the multi-principal assertion is the secure conveyance of privilege information for processes running with more (or even with less) privilege than the user normally would be accorded.
多主体断言的另一个用途是安全地为运行的进程传递权限信息，这些进程的权限比用户通常获得的权限更多（甚至更少）。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
RPCSEC_GSS version 3 (RPCSEC_GSSv3) is the same as RPCSEC_GSSv2 [RFC5403], except that the following assertions of authority have been added:
RPCSEC_GSS版本3（RPCSEC_GSSv3）与RPCSEC_GSSv2[RFC5403]相同，只是添加了以下权限声明：
o Security labels for Full Mode security type enforcement, and other labeled security models (see Section 9.5.1 of [RFC7862]).
o 全模式安全类型实施的安全标签，以及其他标记的安全模型（见[RFC7862]第9.5.1节）。
o Application-specific structured privileges. These allow an RPC application client to pass structured information to the corresponding application code in a server to control the use of the privilege and/or the conditions in which the privilege may be exercised. For an example, see server-side copy as described in [RFC7862].
o 特定于应用程序的结构化权限。这些允许RPC应用程序客户端将结构化信息传递给服务器中的相应应用程序代码，以控制权限的使用和/或可能行使权限的条件。有关示例，请参见[RFC7862]中所述的服务器端副本。
o Multi-principal authentication of the client host and user to the server, done by binding two RPCSEC_GSS handles.
o 客户端主机和用户到服务器的多主体身份验证，通过绑定两个RPCSEC_GSS句柄完成。
o Simplified channel binding.
o 简化的通道绑定。
Assertions of labels and privileges are evaluated by the server, which may then map the asserted values to other values, all according to server-side policy. See [RFC7862].
标签和权限的断言由服务器进行评估，然后服务器可以根据服务器端策略将断言的值映射到其他值。见[RFC7862]。
An option for enumerating server-supported Label Format Specifiers (LFSs) is provided. See Section 9.1 of [RFC7862].
提供了一个枚举服务器支持的标签格式说明符（LFS）的选项。见[RFC7862]第9.1节。
Note that there is no RPCSEC_GSS_CREATE payload that is REQUIRED to implement. RPCSEC_GSSv3 implementations are feature driven. Besides implementing the RPCSEC_GSS_CREATE operation and payloads for the desired features, all RPCSEC_GSSv3 implementations MUST implement:
请注意，没有实现所需的RPCSEC_GSS_创建有效负载。RPCSEC_GSSv3实现是功能驱动的。除了为所需功能实现RPCSEC_GSS_创建操作和有效载荷外，所有RPCSEC_GSSv3实现必须实现：
o The new RPCSEC_GSS version number (Section 2.2).
o 新的RPCSEC_GSS版本号（第2.2节）。
o The new reply verifier (Section 2.3).
o 新的回复验证程序（第2.3节）。
o The new auth_stat values (Section 2.6).
o 新的auth_stat值（第2.6节）。
RPCSEC_GSSv3 targets implementing a desired feature MUST also implement the RPCSEC_GSS_LIST operation, and the RPCSEC_GSS_CREATE operation replies for unsupported features as follows:
实现所需功能的RPCSEC_GSSv3目标还必须实现RPCSEC_GSS_列表操作，并且RPCSEC_GSS_创建操作对不支持的功能的回复如下：
o For label assertions, the target indicates no support by returning the new RPCSEC_GSS_LABEL_PROBLEM auth_stat value (see Section 2.7.1.3).
o 对于标签断言，目标通过返回新的RPCSEC_GSS_label_PROBLEM auth_stat值表示不支持（参见第2.7.1.3节）。
o For structured privilege assertions, the target indicates no support by returning the new RPCSEC_GSS_UNKNOWN_MESSAGE auth_stat value (see Section 2.7.1.4).
o 对于结构化权限断言，目标通过返回新的RPCSEC_GSS_UNKNOWN_消息auth_stat值表示不支持（请参见第2.7.1.4节）。
o For multi-principal authentication (Section 2.7.1.1), the target indicates no support by not including an rgss3_gss_mp_auth value in the rgss3_create_res.
o 对于多主体身份验证（第2.7.1.1节），目标通过在rgss3_创建_res中不包含rgss3_gss_mp_auth值表示不支持。
o For channel bindings (Section 2.7.1.2), the target indicates no support by not including an rgss3_chan_binding value in the rgss3_create_res.
o 对于通道绑定（第2.7.1.2节），目标通过在rgss3_create_res中不包含rgss3_chan_绑定值表示不支持。
This document contains the External Data Representation (XDR) [RFC4506] definitions for the RPCSEC_GSSv3 protocol. The XDR description is provided in this document in a way that makes it simple for the reader to extract it into a form that is ready to compile. The reader can feed this document in the following shell script to produce the machine-readable XDR description of RPCSEC_GSSv3:
本文档包含RPCSEC_GSSv3协议的外部数据表示（XDR）[RFC4506]定义。本文档中提供了XDR描述，使读者能够轻松地将其提取到可编译的表单中。读者可以在以下shell脚本中输入此文档，以生成RPCSEC_GSSv3的机器可读XDR描述：
<CODE BEGINS>
<代码开始>
#!/bin/sh
grep "^ *///" | sed 's?^ */// ??' | sed 's?^ *///$??'
#!/bin/sh
grep "^ *///" | sed 's?^ */// ??' | sed 's?^ *///$??'
<CODE ENDS>
<代码结束>
That is, if the above script is stored in a file called "extract.sh" and this document is in a file called "spec.txt", then the reader can do:
也就是说，如果上述脚本存储在一个名为“extract.sh”的文件中，而此文档存储在一个名为“spec.txt”的文件中，则读者可以执行以下操作：
<CODE BEGINS>
<代码开始>
sh extract.sh < spec.txt > rpcsec_gss_v3.x
sh extract.sh<spec.txt>rpcsec_gss_v3.x
<CODE ENDS>
<代码结束>
The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///".
脚本的作用是删除每行的前导空格，以及“//”的哨兵序列。
RPCSEC_GSS version 3 (RPCSEC_GSSv3) is very similar to RPCSEC_GSS version 2 (RPCSEC_GSSv2) [RFC5403]. The difference is that the new support for assertions and channel bindings is implemented via a different mechanism.
RPCSEC_GSS版本3（RPCSEC_GSSv3）与RPCSEC_GSS版本2（RPCSEC_GSSv2）[RFC5403]非常相似。不同之处在于，对断言和通道绑定的新支持是通过不同的机制实现的。
The entire RPCSEC_GSSv3 protocol is not presented here. Only the differences between RPCSEC_GSSv3 and RPCSEC_GSSv2 are shown.
这里不介绍整个RPCSEC_GSSv3协议。仅显示了RPCSEC_GSSv3和RPCSEC_GSSv2之间的差异。
RPCSEC_GSSv3 is implemented as follows:
RPCSEC_GSSv3的实施如下：
o A client uses an existing RPCSEC_GSSv3 context handle established in the usual manner (see Section 5.2 of [RFC2203]) to protect RPCSEC_GSSv3 exchanges; this will be termed the "parent" handle.
o 客户端使用以通常方式建立的现有RPCSEC_GSSv3上下文句柄（参见[RFC2203]第5.2节）来保护RPCSEC_GSSv3交换；这将被称为“父”句柄。
o The server issues a "child" RPCSEC_GSSv3 handle in the RPCSEC_GSS_CREATE response, which uses the underlying GSS-API security context of the parent handle in all subsequent exchanges that use the child handle.
o 服务器在RPCSEC_GSS_CREATE响应中发出一个“child”RPCSEC_GSSv3句柄，该句柄在使用子句柄的所有后续交换中使用父句柄的底层GSS-API安全上下文。
o An RPCSEC_GSSv3 child handle MUST NOT be used as the parent handle in an RPCSEC_GSS3_CREATE control message.
o RPCSEC_GSSv3子句柄不得用作RPCSEC_GSS3_CREATE控制消息中的父句柄。
The functionality of RPCSEC_GSSv2 [RFC5403] is fully supported by RPCSEC_GSSv3, with the exception of the RPCSEC_GSS_BIND_CHANNEL operation, which is not supported when RPCSEC_GSSv3 is in use (see Section 2.5).
RPCSEC_GSSv3完全支持RPCSEC_GSSv2[RFC5403]的功能，但RPCSEC_GSS_BIND_通道操作除外，在使用RPCSEC_GSSv3时不支持该操作（见第2.5节）。
An initiator that supports version 3 of RPCSEC_GSS simply issues an RPCSEC_GSS request with the rgc_version field set to RPCSEC_GSS_VERS_3. If the target does not recognize RPCSEC_GSS_VERS_3, the target will return an RPC error per Section 5.1 of [RFC2203].
支持RPCSEC_GSS版本3的启动器只需发出RPCSEC_GSS请求，并将rgc_版本字段设置为RPCSEC_GSS_VERS_3。如果目标无法识别RPCSEC_GSS_VERS_3，则目标将根据[RFC2203]第5.1节返回RPC错误。
The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 3 of a target with version 1 or version 2 of the same target. The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 1 or version 2 of a target with version 3 of the same target.
启动器不得尝试使用目标版本3返回的RPCSEC_GSS句柄，该句柄的版本1或版本2为同一目标。启动器不得尝试使用目标版本1或版本2返回的RPCSEC_GSS句柄，该句柄与同一目标的版本3相同。
A new reply verifier is needed for RPCSEC_GSSv3 because of a situation that arises from the use of the same GSS context by child and parent handles. Because the RPCSEC_GSSv3 child handle uses the same GSS context as the parent handle, a child and parent RPCSEC_GSSv3 handle could have the same RPCSEC_GSS sequence numbers. Since the reply verifier of previous versions of RPCSEC_GSS computes a Message Integrity Code (MIC) on just the sequence number, this provides opportunities for man-in-the-middle attacks.
RPCSEC_GSSv3需要一个新的应答验证器，因为子句柄和父句柄使用相同的GSS上下文时会出现这种情况。由于RPCSEC_GSSv3子句柄使用与父句柄相同的GSS上下文，因此子和父RPCSEC_GSSv3句柄可以具有相同的RPCSEC_GSS序列号。由于以前版本的RPCSEC_GSS的应答验证器仅在序列号上计算消息完整性代码（MIC），因此这为中间人攻击提供了机会。
This issue is addressed in RPCSEC_GSS version 3 by computing the verifier using exactly the same input as the information used to compute the request verifier, except that the mtype is changed from CALL to REPLY. The new reply verifier computes a MIC over the following RPC reply header data:
RPCSEC_GSS版本3通过使用与用于计算请求验证器的信息完全相同的输入计算验证器来解决此问题，但mtype从调用更改为应答。新的应答验证器通过以下RPC应答头数据计算MIC：
unsigned int xid;
msg_type mtype; /* set to REPLY */
unsigned int rpcvers;
unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred; /* binds the RPCSEC_GSS handle */
unsigned int xid;
msg_type mtype; /* set to REPLY */
unsigned int rpcvers;
unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred; /* binds the RPCSEC_GSS handle */
The following code fragment replaces the corresponding preliminary code shown in Figure 1 of [RFC5403]. The values in the code fragment in Section 2.6 are additions to the auth_stat enumeration. Subsequent code fragments are additions to the code for version 2 that support the new procedures defined in version 3.
以下代码片段替换了[RFC5403]图1所示的相应初步代码。第2.6节中代码片段中的值是auth_stat枚举的附加值。后续代码片段是对版本2的代码的添加，支持版本3中定义的新过程。
<CODE BEGINS>
<代码开始>
/// /*
/// * Copyright (c) 2016 IETF Trust and the persons
/// * identified as the authors. All rights reserved.
/// *
/// * The authors of the code are identified in RFC 2203,
/// * RFC 5403, and RFC 7861.
/// *
/// * Redistribution and use in source and binary forms,
/// * with or without modification, are permitted
/// * provided that the following conditions are met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the
/// * above copyright notice, this list of
/// * conditions and the following disclaimer in
/// * the documentation and/or other materials
/// * provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// /*
/// * Copyright (c) 2016 IETF Trust and the persons
/// * identified as the authors. All rights reserved.
/// *
/// * The authors of the code are identified in RFC 2203,
/// * RFC 5403, and RFC 7861.
/// *
/// * Redistribution and use in source and binary forms,
/// * with or without modification, are permitted
/// * provided that the following conditions are met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the
/// * above copyright notice, this list of
/// * conditions and the following disclaimer in
/// * the documentation and/or other materials
/// * provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// */
///
/// /*
/// * This code was derived from RFC 2203, RFC 5403,
/// * and RFC 7861. Please reproduce this note if possible.
/// */
///
/// enum rpc_gss_service_t {
/// /* Note: The enumerated value for 0 is reserved. */
/// rpc_gss_svc_none = 1,
/// rpc_gss_svc_integrity = 2,
/// rpc_gss_svc_privacy = 3,
/// rpc_gss_svc_channel_prot = 4
/// };
///
/// enum rpc_gss_proc_t {
/// RPCSEC_GSS_DATA = 0,
/// RPCSEC_GSS_INIT = 1,
/// RPCSEC_GSS_CONTINUE_INIT = 2,
/// RPCSEC_GSS_DESTROY = 3,
/// RPCSEC_GSS_BIND_CHANNEL = 4, /* Not used */
/// RPCSEC_GSS_CREATE = 5, /* New */
/// RPCSEC_GSS_LIST = 6 /* New */
/// };
///
/// struct rpc_gss_cred_vers_1_t {
/// rpc_gss_proc_t gss_proc; /* Control procedure */
/// unsigned int seq_num; /* Sequence number */
/// rpc_gss_service_t service; /* Service used */
/// opaque handle<>; /* Context handle */
/// };
///
/// const RPCSEC_GSS_VERS_1 = 1;
/// const RPCSEC_GSS_VERS_2 = 2;
/// const RPCSEC_GSS_VERS_3 = 3; /* New */
///
/// union rpc_gss_cred_t switch (unsigned int rgc_version) {
/// case RPCSEC_GSS_VERS_1:
/// case RPCSEC_GSS_VERS_2:
/// case RPCSEC_GSS_VERS_3: /* New */
/// rpc_gss_cred_vers_1_t rgc_cred_v1;
/// };
///
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// */
///
/// /*
/// * This code was derived from RFC 2203, RFC 5403,
/// * and RFC 7861. Please reproduce this note if possible.
/// */
///
/// enum rpc_gss_service_t {
/// /* Note: The enumerated value for 0 is reserved. */
/// rpc_gss_svc_none = 1,
/// rpc_gss_svc_integrity = 2,
/// rpc_gss_svc_privacy = 3,
/// rpc_gss_svc_channel_prot = 4
/// };
///
/// enum rpc_gss_proc_t {
/// RPCSEC_GSS_DATA = 0,
/// RPCSEC_GSS_INIT = 1,
/// RPCSEC_GSS_CONTINUE_INIT = 2,
/// RPCSEC_GSS_DESTROY = 3,
/// RPCSEC_GSS_BIND_CHANNEL = 4, /* Not used */
/// RPCSEC_GSS_CREATE = 5, /* New */
/// RPCSEC_GSS_LIST = 6 /* New */
/// };
///
/// struct rpc_gss_cred_vers_1_t {
/// rpc_gss_proc_t gss_proc; /* Control procedure */
/// unsigned int seq_num; /* Sequence number */
/// rpc_gss_service_t service; /* Service used */
/// opaque handle<>; /* Context handle */
/// };
///
/// const RPCSEC_GSS_VERS_1 = 1;
/// const RPCSEC_GSS_VERS_2 = 2;
/// const RPCSEC_GSS_VERS_3 = 3; /* New */
///
/// union rpc_gss_cred_t switch (unsigned int rgc_version) {
/// case RPCSEC_GSS_VERS_1:
/// case RPCSEC_GSS_VERS_2:
/// case RPCSEC_GSS_VERS_3: /* New */
/// rpc_gss_cred_vers_1_t rgc_cred_v1;
/// };
///
<CODE ENDS>
<代码结束>
As seen above, the RPCSEC_GSSv3 credential has the same format as the RPCSEC_GSSv1 [RFC2203] and RPCSEC_GSSv2 [RFC5403] credential. Setting the rgc_version field to 3 indicates that the initiator and target support the new RPCSEC_GSSv3 control procedures.
如上所述，RPCSEC_GSSv3凭证的格式与RPCSEC_GSSv1[RFC2203]和RPCSEC_GSSv2[RFC5403]凭证的格式相同。将rgc_version字段设置为3表示启动器和目标支持新的RPCSEC_GSSv3控制过程。
RPCSEC_GSSv3 provides a channel-binding assertion that replaces the RPCSEC_GSSv2 RPCSEC_GSS_BIND_CHANNEL operation.
RPCSEC_GSSv3提供了一个通道绑定断言，该断言替换了RPCSEC_GSSv2 RPCSEC_GSS_BIND_通道操作。
The RPCSEC_GSS_BIND_CHANNEL operation is not supported on RPCSEC_GSS version 3 handles. If a server receives an RPCSEC_GSS_BIND_CHANNEL operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of MSG_ACCEPTED with an accept_stat of PROC_UNAVAIL [RFC5531].
RPCSEC_GSS_BIND_通道操作在RPCSEC_GSS版本3句柄上不受支持。如果服务器在RPCSEC_GSSv3句柄上接收到RPCSEC_GSS_BIND_通道操作，则它必须返回回复状态MSG_ACCEPTED，接受状态为PROC_UNAVAIL[RFC5531]。
RPCSEC_GSSv3 requires the addition of several values to the auth_stat enumerated type definition. The use of these new auth_stat values is explained throughout this document.
RPCSEC_GSSv3需要向auth_stat枚举类型定义添加几个值。这些新的auth_stat值的使用在本文档中进行了说明。
enum auth_stat {
...
/*
* RPCSEC_GSSv3 errors
*/
RPCSEC_GSS_INNER_CREDPROBLEM = 15,
RPCSEC_GSS_LABEL_PROBLEM = 16,
RPCSEC_GSS_PRIVILEGE_PROBLEM = 17,
RPCSEC_GSS_UNKNOWN_MESSAGE = 18
};
enum auth_stat {
...
/*
* RPCSEC_GSSv3 errors
*/
RPCSEC_GSS_INNER_CREDPROBLEM = 15,
RPCSEC_GSS_LABEL_PROBLEM = 16,
RPCSEC_GSS_PRIVILEGE_PROBLEM = 17,
RPCSEC_GSS_UNKNOWN_MESSAGE = 18
};
There are two new RPCSEC_GSSv3 control procedures: RPCSEC_GSS_CREATE and RPCSEC_GSS_LIST.
有两个新的RPCSEC_GSSv3控制程序：RPCSEC_GSS_创建和RPCSEC_GSS_列表。
The RPCSEC_GSS_CREATE procedure binds any combination of assertions -- multi-principal authentication, labels, structured privileges, or channel bindings -- to a new RPCSEC_GSSv3 context returned in the rgss3_create_res rcr_handle field.
RPCSEC_GSS_CREATE过程将断言的任意组合（多主体身份验证、标签、结构化权限或通道绑定）绑定到在rgss3_CREATE_res rcr_handle字段中返回的新RPCSEC_GSSv3上下文。
The RPCSEC_GSS_LIST procedure queries the target for supported assertions.
RPCSEC_GSS_LIST过程向目标查询支持的断言。
RPCSEC_GSS version 3 control messages are similar to the RPCSEC_GSS version 1 and version 2 RPCSEC_GSS_DESTROY control message (see Section 5.4 of [RFC2203]) in that the sequence number in the request must be valid and the header checksum in the verifier must be valid. As in RPCSEC_GSS version 1 and version 2, the RPCSEC_GSS version 3 control messages may contain call data following the verifier in the body of the NULLPROC procedure. In other words, they look a lot like an RPCSEC_GSS data message with the header procedure set to NULLPROC.
RPCSEC_GSS第3版控制消息类似于RPCSEC_GSS第1版和第2版RPCSEC_GSS_销毁控制消息（参见[RFC2203]第5.4节），因为请求中的序列号必须有效，验证器中的报头校验和必须有效。与RPCSEC_GSS版本1和版本2一样，RPCSEC_GSS版本3控制消息可能包含NULLPROC过程主体中验证器之后的调用数据。换句话说，它们看起来很像RPCSEC_GSS数据消息，头过程设置为NULLPROC。
The client MUST use one of the following security services to protect the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message:
客户端必须使用以下安全服务之一来保护RPCSEC_GSS_创建或RPCSEC_GSS_列表控制消息：
o rpc_gss_svc_integrity
o rpc\U gss\U svc\U完整性
o rpc_gss_svc_privacy
o rpc_gss_svc_隐私
Specifically, the client MUST NOT use rpc_gss_svc_none.
具体而言，客户端不得使用rpc\u gss\u svc\u none。
RPCSEC_GSS_LIST can also use rpc_gss_svc_channel_prot (see RPCSEC_GSSv2 [RFC5403]) if the request is sent using an RPCSEC_GSSv3 child handle with channel bindings enabled as described in Section 2.7.1.2.
RPCSEC_GSS_列表也可以使用rpc_GSS_svc_channel_prot（请参阅RPCSEC_GSSv2[RFC5403]），如果请求是使用RPCSEC_GSSv3子句柄发送的，并且如第2.7.1.2节所述启用了通道绑定。
<CODE BEGINS>
<代码开始>
/// struct rgss3_create_args {
/// rgss3_gss_mp_auth *rca_mp_auth;
/// rgss3_chan_binding *rca_chan_bind_mic;
/// rgss3_assertion_u rca_assertions<>;
/// };
///
/// struct rgss3_create_res {
/// opaque rcr_handle<>;
/// rgss3_gss_mp_auth *rcr_mp_auth;
/// rgss3_chan_binding *rcr_chan_bind_mic;
/// rgss3_assertion_u rcr_assertions<>;
/// };
///
/// enum rgss3_assertion_type {
/// LABEL = 0,
/// PRIVS = 1
/// };
///
/// union rgss3_assertion_u
/// switch (rgss3_assertion_type atype) {
/// case LABEL:
/// rgss3_label rau_label;
/// case PRIVS:
/// rgss3_privs rau_privs;
/// default:
/// opaque rau_ext<>;
/// };
///
/// struct rgss3_create_args {
/// rgss3_gss_mp_auth *rca_mp_auth;
/// rgss3_chan_binding *rca_chan_bind_mic;
/// rgss3_assertion_u rca_assertions<>;
/// };
///
/// struct rgss3_create_res {
/// opaque rcr_handle<>;
/// rgss3_gss_mp_auth *rcr_mp_auth;
/// rgss3_chan_binding *rcr_chan_bind_mic;
/// rgss3_assertion_u rcr_assertions<>;
/// };
///
/// enum rgss3_assertion_type {
/// LABEL = 0,
/// PRIVS = 1
/// };
///
/// union rgss3_assertion_u
/// switch (rgss3_assertion_type atype) {
/// case LABEL:
/// rgss3_label rau_label;
/// case PRIVS:
/// rgss3_privs rau_privs;
/// default:
/// opaque rau_ext<>;
/// };
///
<CODE ENDS>
<代码结束>
The call data for an RPCSEC_GSS_CREATE request consists of an rgss3_create_args, which binds one or more items of several kinds to the returned rcr_handle RPCSEC_GSSv3 context handle (the child handle):
RPCSEC_GSS_CREATE请求的调用数据由rgss3_CREATE_参数组成，该参数将多种类型的一个或多个项绑定到返回的rcr_句柄RPCSEC_GSSv3上下文句柄（子句柄）：
o Multi-principal authentication: another RPCSEC_GSS context handle
o 多主体身份验证：另一个RPCSEC_GSS上下文句柄
o A channel binding
o 通道绑定
o Authorization assertions: labels and/or privileges
o 授权断言：标签和/或权限
The reply to this message consists of either an error or an rgss3_create_res structure. As noted in Sections 2.7.1.3 and 2.7.1.4, successful rgss3_assertions are enumerated in rcr_assertions and are REQUIRED to be enumerated in the same order as they appeared in the rca_assertions argument.
对此消息的答复包含错误或rgss3_create_res结构。如第2.7.1.3节和第2.7.1.4节所述，成功的rgss3_断言在rcr_断言中枚举，并且要求按照rca_断言参数中出现的相同顺序枚举。
Upon a successful RPCSEC_GSS_CREATE, both the client and the server need to associate the resultant child rcr_handle context handle with the parent context handle in their GSS context caches so as to be able to reference the parent context given the child context handle.
成功创建RPCSEC_GSS_后，客户端和服务器都需要将生成的子rcr_句柄上下文句柄与其GSS上下文缓存中的父上下文句柄相关联，以便能够引用给定子上下文句柄的父上下文。
RPCSEC_GSSv3 child handles MUST be destroyed upon the destruction of the associated parent handle.
RPCSEC_GSSv3子句柄必须在销毁关联的父句柄后销毁。
Server implementation and policy MAY result in labels, privileges, and identities being mapped to concepts and values that are local to the server. Server policies should take into account the identity of the client and/or user as authenticated via the GSS-API.
服务器实现和策略可能导致标签、权限和标识映射到服务器本地的概念和值。服务器策略应考虑通过GSS-API进行身份验证的客户端和/或用户的身份。
<CODE BEGINS>
<代码开始>
///
/// struct rgss3_gss_mp_auth {
/// opaque rgmp_handle<>; /* Inner handle */
/// opaque rgmp_rpcheader_mic<>;
/// };
///
///
/// struct rgss3_gss_mp_auth {
/// opaque rgmp_handle<>; /* Inner handle */
/// opaque rgmp_rpcheader_mic<>;
/// };
///
<CODE ENDS>
<代码结束>
RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of the RPC client host principal and a user principal. This feature is needed, for example, when an RPC client host wishes to use authority assertions that the server may only grant if a user and an RPC client host are authenticated together to the server. Thus, a server may refuse to grant requested authority to a user acting alone (e.g., via an unprivileged user-space program) or to an RPC client host acting alone (e.g., when an RPC client host is acting on behalf of a user) but may grant requested authority to an RPC client host acting on behalf of a user if the server identifies the user and trusts the RPC client host.
RPCSEC_GSSv3客户端可以断言RPC客户端主机主体和用户主体的多主体身份验证。例如，当RPC客户机主机希望使用权限断言时，需要此功能。只有当用户和RPC客户机主机一起通过服务器身份验证时，服务器才能授予权限断言。因此，服务器可以拒绝将请求的权限授予单独行动的用户（例如，通过非特权用户空间程序）或单独行动的RPC客户端主机（例如，当RPC客户端主机代表用户行动时）但如果服务器识别用户并信任RPC客户端主机，则可以将请求的权限授予代表用户的RPC客户端主机。
It is assumed that an unprivileged user-space program would not have access to RPC client host credentials needed to establish a GSS-API security context authenticating the RPC client host to the server; therefore, an unprivileged user-space program could not create an RPCSEC_GSSv3 RPCSEC_GSS_CREATE message that successfully binds an RPC client host and a user security context.
假定未经授权的用户空间程序将无法访问建立GSS-API安全上下文以向服务器验证RPC客户端主机所需的RPC客户端主机凭据；因此，非特权用户空间程序无法创建成功绑定RPC客户端主机和用户安全上下文的RPCSEC_GSSv3 RPCSEC_GSS_create消息。
In addition to the parent handle (Section 2), the multi-principal authentication call data has an RPCSEC_GSS version 3 handle referenced via the rgmp_handle field termed the "inner" handle. Clients using RPCSEC_GSSv3 multi-principal authentication MUST use an RPCSEC_GSSv3 context handle that corresponds to a GSS-API security context that authenticates the RPC client host for the parent handle. The inner context handle of the multi-principal authentication assertion MUST use an RPCSEC_GSSv3 context handle that corresponds to a GSS-API security context that authenticates the user. The reverse (parent handle authenticates user, inner context handle authenticates an RPC client host) MUST NOT be used. Other multi-principal parent and inner context handle uses might eventually make sense, but they would need to be introduced in a new revision of the RPCSEC_GSS protocol.
除了父句柄（第2节），多主体身份验证调用数据还有一个RPCSEC_GSS版本3句柄，该句柄通过名为“内部”句柄的rgmp_句柄字段引用。使用RPCSEC_GSSv3多主体身份验证的客户端必须使用RPCSEC_GSSv3上下文句柄，该句柄对应于为父句柄验证RPC客户端主机的GSS-API安全上下文。多主体身份验证断言的内部上下文句柄必须使用RPCSEC_GSSv3上下文句柄，该句柄对应于对用户进行身份验证的GSS-API安全上下文。不能使用相反的方式（父句柄验证用户，内部上下文句柄验证RPC客户端主机）。其他多主体父级和内部上下文句柄的使用最终可能会有意义，但它们需要在RPCSEC_GSS协议的新版本中引入。
The child context handle returned by a successful multi-principal assertion binds the inner RPCSEC_GSSv3 context handle to the parent RPCSEC_GSS context handle and MUST be treated by servers as authenticating the GSS-API initiator principal authenticated by the inner context handle's GSS-API security context. This principal may be mapped to a server-side notion of user or principal.
成功的多主体断言返回的子上下文句柄将内部RPCSEC_GSSv3上下文句柄绑定到父RPCSEC_GSS上下文句柄，并且服务器必须将其视为验证由内部上下文句柄的GSS-API安全上下文验证的GSS-API启动器主体。这个主体可以映射到用户或主体的服务器端概念。
Multi-principal binding is done by including an assertion of type rgss3_gss_mp_auth in the RPCSEC_GSS_CREATE rgss3_create_args call data. The inner context handle is placed in the rgmp_handle field. A MIC of the RPC header, up to and including the credential, is computed using the GSS-API security context associated with the inner context handle and is placed in the rgmp_rpcheader_mic field. Note that the rgmp_rpcheader_mic only identifies the client host GSS context by its context handle (the parent context handle) in the RPC header.
多主体绑定通过在RPCSEC_gss_CREATE rgss3_CREATE_args调用数据中包含类型为rgss3_gss_mp_auth的断言来完成。内部上下文句柄位于rgmp_句柄字段中。使用与内部上下文句柄关联的GSS-API安全上下文计算RPC标头（包括凭据）的MIC，并将其放置在rgmp_rpcheader_MIC字段中。请注意，rgmp_rpcheader_mic仅通过RPC头中的上下文句柄（父上下文句柄）来标识客户机主机GSS上下文。
An RPCSEC_GSS_CREATE control procedure with a multi-principal authentication payload MUST use the rpc_gss_svc_privacy security service for protection. This prevents an attacker from intercepting the RPCSEC_GSS_CREATE control procedure, reassigning the (parent) context handle, and stealing the user's identity.
具有多主体身份验证有效负载的RPCSEC_GSS_CREATE控制过程必须使用rpc_GSS_svc_隐私安全服务进行保护。这可防止攻击者拦截RPCSEC_GSS_创建控制过程、重新分配（父）上下文句柄以及窃取用户身份。
The target verifies the multi-principal authentication by first confirming that the parent context used is an RPC client host context; the target then verifies the rgmp_rpcheader_mic using the GSS-API security context associated with the rgmp_handle field.
目标通过首先确认所使用的父上下文是RPC客户端主机上下文来验证多主体身份验证；然后，目标使用与rgmp_句柄字段关联的GSS-API安全上下文验证rgmp_rpcheader_mic。
On successful verification, the rgss3_gss_mp_auth field in the rgss3_create_res reply MUST be filled in with the inner RPCSEC_GSSv3 context handle as the rgmp_handle and a MIC computed over the RPC reply header (see Section 2.3) using the GSS-API security context associated with the inner handle.
验证成功后，必须使用内部RPCSEC_GSSv3上下文句柄作为rgmp_句柄填写rgss3_gss_mp_auth字段，并使用与内部句柄关联的gss-API安全上下文通过RPC应答头（见第2.3节）计算MIC。
On failure, the rgss3_gss_mp_auth field is not sent (rgss3_gss_mp_auth is an optional field). A MSG_DENIED reply to the RPCSEC_GSS_CREATE call is formulated as usual.
失败时，不发送rgss3\U gss\U mp\U auth字段（rgss3\U gss\U mp\U auth是可选字段）。对RPCSEC_GSS_CREATE调用的MSG_DENIED回复与往常一样。
As described in Section 5.3.3.3 of [RFC2203], the server maintains a list of contexts for the clients that are currently in session with it. When a client request comes in, there may not be a context corresponding to its handle. When this occurs on an RPCSEC_GSS3_CREATE request processing of the parent handle, the server rejects the request with a reply status of MSG_DENIED with the reject_stat of AUTH_ERROR and with an auth_stat value of RPCSEC_GSS_CREDPROBLEM.
如[RFC2203]第5.3.3.3节所述，服务器维护当前与其会话的客户端的上下文列表。当客户端请求进入时，可能没有与其句柄对应的上下文。当在父句柄的RPCSEC_GSS3_CREATE请求处理中发生这种情况时，服务器将拒绝请求，回复状态为MSG_DENIED，拒绝状态为reject_stat of AUTH_ERROR，AUTH_stat值为RPCSEC_GSS_CREDPROBLEM。
A new value, RPCSEC_GSS_INNER_CREDPROBLEM, has been added to the auth_stat type. With a multi-principal authorization request, the server must also have a context corresponding to the inner context handle. When the server does not have a context handle corresponding to the inner context handle of a multi-principal authorization request, the server sends a reply status of MSG_DENIED with the reject_stat of AUTH_ERROR and with an auth_stat value of RPCSEC_GSS_INNER_CREDPROBLEM.
在auth_stat类型中添加了一个新值RPCSEC_GSS_internal_CREDPROBLEM。对于多主体授权请求，服务器还必须具有与内部上下文句柄对应的上下文。当服务器没有与多主体授权请求的内部上下文句柄相对应的上下文句柄时，服务器将发送一个回复状态MSG_DENIED，其中reject_stat为AUTH_ERROR，AUTH_stat值为RPCSEC_GSS_internal_CREDPROBLEM。
When processing the multi-principal authentication request, if the GSS_VerifyMIC() call on the rgmp_rpcheader_mic fails to return GSS_S_COMPLETE, the server sends a reply status of MSG_DENIED with the reject_stat of AUTH_ERROR and with an auth_stat value of RPCSEC_GSS_INNER_CREDPROBLEM.
在处理多主体身份验证请求时，如果rgmp_rpcheader_mic上的GSS_VerifyMIC（）调用未能返回GSS_S_COMPLETE，则服务器将发送一个回复状态MSG_DENIED，其中reject_stat为AUTH_ERROR，AUTH_stat值为RPCSEC_GSS_internal_CREDPROBLEM。
<CODE BEGINS>
<代码开始>
///
/// typedef opaque rgss3_chan_binding<>;
///
///
/// typedef opaque rgss3_chan_binding<>;
///
<CODE ENDS>
<代码结束>
RPCSEC_GSSv3 provides a different way to do channel binding than RPCSEC_GSSv2 [RFC5403]. Specifically:
RPCSEC_GSSv3提供了与RPCSEC_GSSv2不同的通道绑定方式[RFC5403]。明确地：
a. RPCSEC_GSSv3 builds on RPCSEC_GSSv1 by reusing existing, established context handles rather than providing a different RPC security flavor for establishing context handles.
a. RPCSEC_GSSv3构建在RPCSEC_GSSv1的基础上，通过重用现有的、已建立的上下文句柄，而不是为建立上下文句柄提供不同的RPC安全风格。
b. Channel-bindings data is not hashed because there is now general agreement that it is the secure channel's responsibility to produce channel-bindings data of manageable size.
b. 通道绑定数据没有散列，因为现在普遍认为安全通道负责生成可管理大小的通道绑定数据。
(a) is useful in keeping RPCSEC_GSSv3 simple in general, not just for channel binding. (b) is useful in keeping RPCSEC_GSSv3 simple specifically for channel binding.
(a) 在保持RPCSEC_GSSv3的简单性方面非常有用，而不仅仅是在通道绑定方面。（b） 在保持RPCSEC_GSSv3的简单性方面非常有用，特别是在通道绑定方面。
Channel binding is accomplished as follows. The client prefixes the channel-bindings data octet string with the channel type as described in [RFC5056]; then, the client calls GSS_GetMIC() to get a MIC of the resulting octet string, using the parent RPCSEC_GSSv3 context handle's GSS-API security context. The MIC is then placed in the rca_chan_bind_mic field of RPCSEC_GSS_CREATE arguments (rgss3_create_args).
通道绑定按如下方式完成。客户端使用[RFC5056]中所述的通道类型作为通道绑定数据八位字节字符串的前缀；然后，客户端使用父RPCSEC_GSSv3上下文句柄的GSS-API安全上下文调用GSS_GetMIC（）以获取结果八位字节字符串的MIC。然后将麦克风放入RPCSEC\u GSS\u CREATE参数（rgss3\u CREATE\u参数）的rca\u chan\u bind\u麦克风字段中。
If the rca_chan_bind_mic field of the arguments of an RPCSEC_GSS_CREATE control message is set, then the server MUST verify the client's channel-binding MIC if the server supports this feature. If channel-binding verification succeeds, then the server MUST generate a new MIC of the same channel bindings and place it in the rcr_chan_bind_mic field of the RPCSEC_GSS_CREATE rgss3_create_res results. If channel-binding verification fails or the server doesn't support channel binding, then the server MUST indicate this in its reply by not including an rgss3_chan_binding value in rgss3_create_res (rgss3_chan_binding is an optional field).
如果设置了RPCSEC_GSS_CREATE控制消息参数的rca_chan_bind_mic字段，则如果服务器支持此功能，则服务器必须验证客户端的通道绑定mic。如果通道绑定验证成功，则服务器必须生成相同通道绑定的新MIC，并将其放入RPCSEC_GSS_CREATE rgss3_CREATE_res结果的rcr_chan_bind_MIC字段中。如果通道绑定验证失败或服务器不支持通道绑定，则服务器必须通过在rgss3_创建_res中不包含rgss3_chan_绑定值（rgss3_chan_binding是可选字段）在其答复中指出这一点。
The client MUST verify the result's rcr_chan_bind_mic value by calling GSS_VerifyMIC() with the given MIC and the channel-bindings data (including the channel-type prefix). If client-side channel-binding verification fails, then the client MUST call
客户端必须使用给定的mic和通道绑定数据（包括通道类型前缀）调用GSS_VerifyMIC（），以验证结果的rcr_chan_bind_mic值。如果客户端通道绑定验证失败，则客户端必须调用
RPCSEC_GSS_DESTROY. If the client requested channel binding but the server did not include an rcr_chan_binding_mic field in the results, then the client MAY continue to use the resulting context handle as though channel binding had never been requested. If the client considers channel binding critical, it MUST call RPCSEC_GSS_DESTROY.
RPCSEC_GSS_销毁。如果客户端请求了通道绑定，但服务器未在结果中包含rcr_chan_binding_mic字段，则客户端可以继续使用生成的上下文句柄，就像从未请求过通道绑定一样。如果客户端认为通道绑定至关重要，则必须调用RPCSEC_GSS_DESTROY。
As per RPCSEC_GSSv2 [RFC5403]:
根据RPCSEC_GSSv2[RFC5403]：
Once a successful [channel-binding] procedure has been performed on an [RPCSEC_GSSv3] context handle, the initiator's implementation may map application requests for rpc_gss_svc_none and rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And if the secure channel has privacy enabled, requests for rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot.
一旦在[RPCSEC_GSSv3]上下文句柄上成功执行了[channel binding]过程，发起方的实现可能会将rpc_gss_svc_none和rpc_gss_svc_完整性的应用程序请求映射到rpc_gss_svc_channel_prot凭据。如果安全通道启用了隐私，则对rpc_gss_svc_隐私的请求也可以映射到rpc_gss_svc_channel_prot。
Any RPCSEC_GSSv3 child context handle that has been bound to a secure channel in this way SHOULD be used only with the rpc_gss_svc_channel_prot and SHOULD NOT be used with rpc_gss_svc_none or rpc_gss_svc_integrity -- if the secure channel does not provide privacy protection, then the client MAY use rpc_gss_svc_privacy where privacy protection is needed or desired.
以这种方式绑定到安全通道的任何RPCSEC_GSSv3子上下文句柄应仅与rpc_gss_svc_channel_prot一起使用，而不应与rpc_gss_svc_none或rpc_gss_svc_integrity一起使用——如果安全通道不提供隐私保护，然后，客户机可以在需要或期望隐私保护的地方使用rpc_gss_svc_隐私。
<CODE BEGINS>
<代码开始>
/// struct rgss3_label {
/// rgss3_lfs rl_lfs;
/// opaque rl_label<>;
/// };
///
/// struct rgss3_lfs {
/// unsigned int rlf_lfs_id;
/// unsigned int rlf_pi_id;
/// };
///
/// struct rgss3_label {
/// rgss3_lfs rl_lfs;
/// opaque rl_label<>;
/// };
///
/// struct rgss3_lfs {
/// unsigned int rlf_lfs_id;
/// unsigned int rlf_pi_id;
/// };
///
<CODE ENDS>
<代码结束>
The client discovers, via the RPCSEC_GSS_LIST control message, which LFSs the server supports. Full Mode MAC is enabled when an RPCSEC_GSS version 3 process subject label assertion is combined with a file object label provided by the NFSv4.2 sec_label attribute.
客户端通过RPCSEC_GSS_列表控制消息发现服务器支持的LFSs。当RPCSEC_GSS版本3过程主题标签断言与NFSv4.2 sec_标签属性提供的文件对象标签组合时，启用完整模式MAC。
Label encoding is specified to mirror the NFSv4.2 sec_label attribute described in Section 12.2.4 of [RFC7862]. The LFS is an identifier used by the client to establish the syntactic format of the security
指定标签编码以镜像[RFC7862]第12.2.4节中描述的NFSv4.2 sec_标签属性。LFS是客户端用来建立安全性语法格式的标识符
label and the semantic meaning of its components. The Policy Identifier (PI) is an optional part of the definition of an LFS that allows clients and the server to identify specific security policies. The opaque label field (rgss3_label) is dependent on the MAC model to interpret and enforce.
标签及其组成部分的语义。策略标识符（PI）是LFS定义的可选部分，它允许客户端和服务器识别特定的安全策略。不透明标签字段（rgss3_标签）取决于MAC模型来解释和实施。
If a label itself requires privacy protection (i.e., requires that the user can assert that the label is a secret), then the client MUST use the rpc_gss_svc_privacy protection service for the RPCSEC_GSS_CREATE request.
如果标签本身需要隐私保护（即，要求用户可以断言标签是秘密的），则客户端必须为RPCSEC_gss_svc_创建请求使用rpc_gss_隐私保护服务。
RPCSEC_GSSv3 clients MAY assert a set of subject security labels in some LFS by binding a label assertion to the RPCSEC_GSSv3 child context handle. This is done by including an assertion of type rgss3_label in the RPCSEC_GSS_CREATE rgss3_create_args rca_assertions call data. The label assertion payload is the set of subject labels asserted by the calling NFS client process. The resultant child context is used for NFS requests asserting the client process subject labels. The NFS server process that handles such requests then asserts the (client) process subject label(s) as it attempts to access a file that has associated Labeled NFS object labels.
RPCSEC_GSSv3客户端可以通过将标签断言绑定到RPCSEC_GSSv3子上下文句柄，在某些LFS中断言一组主题安全标签。这是通过在RPCSEC_GSS_CREATE rgss3_CREATE_args rca_断言调用数据中包含类型为rgss3_label的断言来实现的。标签断言负载是由调用NFS客户端进程断言的主题标签集。生成的子上下文用于断言客户端进程主题标签的NFS请求。然后，处理此类请求的NFS服务器进程在尝试访问具有相关标记的NFS对象标签的文件时断言（客户端）进程主题标签。
Servers that support labeling in the requested LFS MAY map the requested subject label to a different subject label as a result of server-side policy evaluation.
作为服务器端策略评估的结果，支持所请求LFS中的标签的服务器可以将所请求的主题标签映射到不同的主题标签。
The labels that are accepted by the target and bound to the RPCSEC_GSSv3 context MUST be enumerated in the rcr_assertions field of the rgss3_create_res RPCSEC_GSS_CREATE reply.
目标接受并绑定到RPCSEC_GSSv3上下文的标签必须在rgss3_create_res RPCSEC_GSS_create reply的rcr_断言字段中枚举。
Servers that do not support labeling or that do not support the requested LFS reject the label assertion with a reply status of MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of RPCSEC_GSS_LABEL_PROBLEM.
不支持标签或不支持请求的LFS的服务器拒绝标签断言，回复状态为MSG_DENIED，拒绝状态为AUTH_ERROR，AUTH_stat为RPCSEC_GSS_label_PROBLEM。
<CODE BEGINS>
<代码开始>
///
/// typedef opaque utf8string<>; /* UTF-8 encoding */
/// typedef utf8string utf8str_cs; /* Case-sensitive UTF-8 */
///
/// struct rgss3_privs {
/// utf8str_cs rp_name<>;
/// opaque rp_privilege<>;
/// };
///
/// typedef opaque utf8string<>; /* UTF-8 encoding */
/// typedef utf8string utf8str_cs; /* Case-sensitive UTF-8 */
///
/// struct rgss3_privs {
/// utf8str_cs rp_name<>;
/// opaque rp_privilege<>;
/// };
<CODE ENDS>
<代码结束>
A structured privilege is a capability defined by a specific RPC application. To support the assertion of this privilege, by a client using the application, in a server that also supports the application, the application may define a private data structure that is understood by clients and servers implementing the RPC application.
结构化权限是由特定RPC应用程序定义的功能。为了支持由使用该应用程序的客户端在也支持该应用程序的服务器中断言该特权，该应用程序可以定义一个私有数据结构，该私有数据结构由实现RPC应用程序的客户端和服务器理解。
RPCSEC_GSSv3 clients MAY assert a structured privilege by binding the privilege to the RPCSEC_GSSv3 context handle. This is done by including an assertion of type rgss3_privs in the RPCSEC_GSS_CREATE rgss3_create_args rca_assertions call data.
RPCSEC_GSSv3客户端可以通过将权限绑定到RPCSEC_GSSv3上下文句柄来声明结构化权限。这是通过在RPCSEC_GSS_CREATE rgss3_CREATE_args rca_断言调用数据中包含类型为rgss3_privs的断言来实现的。
The privilege is identified by the description string that is used by RPCSEC_GSSv3 to identify the privilege and communicate the private data between the relevant RPC application-specific code without needing to be aware of the details of the structure used. Thus, as far as RPCSEC_GSSv3 is concerned, the defined structure is passed between client and server as opaque data encoded in the rpc_gss3_privs rp_privilege field.
特权由描述字符串标识，RPCSEC_GSSv3使用该字符串标识特权，并在相关RPC应用程序特定代码之间传递私有数据，而无需了解所用结构的详细信息。因此，就RPCSEC_GSSv3而言，定义的结构作为编码在rpc_gss3_privs rp_privilege字段中的不透明数据在客户端和服务器之间传递。
Encoding, server verification, and any server policies for structured privileges are described by the RPC application definition. The rp_name field of rpc_gss3_privs carries the description string used to identify and list the privilege. The utf8str_cs definition is from [RFC7530].
结构化权限的编码、服务器验证和任何服务器策略由RPC应用程序定义描述。rpc_gss3_privs的rp_name字段包含用于标识和列出权限的描述字符串。utf8str_cs定义来自[RFC7530]。
A successful structured privilege assertion MUST be enumerated in the rcr_assertions field of the rgss3_create_res RPCSEC_GSS_CREATE reply.
必须在rgss3_create_res RPCSEC_GSS_create reply的rcr_assertions字段中枚举成功的结构化权限断言。
If a server receives a structured privilege assertion that it does not recognize, the assertion is rejected with a reply status of MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of RPCSEC_GSS_UNKNOWN_MESSAGE.
如果服务器接收到它无法识别的结构化特权断言，则该断言将被拒绝，回复状态为MSG_DENIED，拒绝状态为AUTH_ERROR，并且AUTH_stat为RPCSEC_GSS_UNKNOWN_MESSAGE。
It is assumed that a client asserting more than one structured privilege to be bound to a context handle would not require all the privilege assertions to succeed.
假定一个客户端断言多个结构化特权将绑定到上下文句柄，则不需要所有特权断言都成功。
The server MUST NOT reject RPCSEC_GSS_CREATE requests containing supported structured privilege assertions, even if some of those assertions are rejected (e.g., for local policy reasons).
服务器不得拒绝包含受支持的结构化权限断言的RPCSEC_GSS_CREATE请求，即使其中一些断言被拒绝（例如，出于本地策略原因）。
If a server receives an RPCSEC_GSS_CREATE request containing one or more unsupported structured privilege assertions, the request MUST be rejected with a reply status of MSG_DENIED, a reject_status of AUTH_ERROR, and an auth_stat of RPCSEC_GSS_PRIVILEGE_PROBLEM.
如果服务器收到包含一个或多个不受支持的结构化特权断言的RPCSEC_GSS_CREATE请求，则必须拒绝该请求，回复状态为MSG_DENIED，拒绝状态为AUTH_ERROR，验证状态为RPCSEC_GSS_privilege_PROBLEM。
Section 4.9.1.1 of [RFC7862] ("Inter-Server Copy via ONC RPC with RPCSEC_GSSv3") shows an example of structured privilege definition and use.
[RFC7862]的第4.9.1.1节（“通过ONC RPC与RPCSEC_GSSv3进行服务器间复制”）显示了结构化权限定义和使用的示例。
<CODE BEGINS>
<代码开始>
/// enum rgss3_list_item {
/// LABEL = 0,
/// PRIVS = 1
/// };
///
/// struct rgss3_list_args {
/// rgss3_list_item rla_list_what<>;
/// };
///
/// union rgss3_list_item_u
/// switch (rgss3_list_item itype) {
/// case LABEL:
/// rgss3_label rli_labels<>;
/// case PRIVS:
/// rgss3_privs rli_privs<>;
/// default:
/// opaque rli_ext<>;
/// };
///
/// typedef rgss3_list_item_u rgss3_list_res<>;
///
/// enum rgss3_list_item {
/// LABEL = 0,
/// PRIVS = 1
/// };
///
/// struct rgss3_list_args {
/// rgss3_list_item rla_list_what<>;
/// };
///
/// union rgss3_list_item_u
/// switch (rgss3_list_item itype) {
/// case LABEL:
/// rgss3_label rli_labels<>;
/// case PRIVS:
/// rgss3_privs rli_privs<>;
/// default:
/// opaque rli_ext<>;
/// };
///
/// typedef rgss3_list_item_u rgss3_list_res<>;
///
<CODE ENDS>
<代码结束>
The call data for an RPCSEC_GSS_LIST request consists of a list of integers (rla_list_what) indicating what assertions are to be listed, and the reply consists of an error or the requested list.
RPCSEC_GSS_LIST请求的调用数据由一个整数列表（rla_LIST_what）组成，指示要列出哪些断言，而应答由错误或请求的列表组成。
The result of requesting a list of rgss3_list_item LABEL objects is a list of LFSs supported by the server. The client can then use the LFS list to assert labels via the RPCSEC_GSS_CREATE label assertions. See Section 2.7.1.3.
请求rgss3_list_item LABEL对象列表的结果是服务器支持的LFS列表。然后，客户端可以使用LFS列表通过RPCSEC_GSS_创建标签断言来断言标签。见第2.7.1.3节。
Assertion types may be added in the future by adding arms to the "rgss3_assertion_u" union (Section 2.7.1) and the "rgss3_list_item_u" union (Section 2.7.2). Examples of other potential assertion types include:
将来可以通过向“rgss3_断言_”联合（第2.7.1节）和“rgss3_列表_项目_”联合（第2.7.2节）添加ARM来添加断言类型。其他潜在断言类型的示例包括：
o Client-side assertions of identity:
o 客户端身份声明：
* Primary client/user identity.
* 主客户端/用户标识。
* Supplementary group memberships of the client/user, including support for specifying deltas to the membership list as seen on the server.
* 客户端/用户的补充组成员身份，包括支持在服务器上为成员列表指定增量。
RPCSEC_GSSv3 is a superset of RPCSEC_GSSv2 [RFC5403], which in turn is a superset of RPCSEC_GSSv1 [RFC2203], and so can be used in all situations where RPCSEC_GSSv2 is used, or where RPCSEC_GSSv1 is used and channel-bindings functionality is not needed. RPCSEC_GSSv3 should be used when the new functionality is needed.
RPCSEC_GSSv3是RPCSEC_GSSv2[RFC5403]的超集，而RPCSEC_GSSv1[RFC2203]又是RPCSEC_GSSv1[RFC2203]的超集，因此可以在使用RPCSEC_GSSv2的所有情况下使用，或者在使用RPCSEC_GSSv1且不需要通道绑定功能的情况下使用。当需要新功能时，应使用RPCSEC_GSSv3。
This entire document deals with security issues.
整个文档涉及安全问题。
The RPCSEC_GSSv3 protocol allows for client-side assertions of data that is relevant to server-side authorization decisions. These assertions must be evaluated by the server in the context of whether the client and/or user are authenticated, whether multi-principal authentication was used, whether the client is trusted, what ranges of assertions are allowed for the client and the user (separately or together), and any relevant server-side policy.
RPCSEC_GSSv3协议允许客户端断言与服务器端授权决策相关的数据。服务器必须在客户端和/或用户是否经过身份验证、是否使用了多主体身份验证、客户端是否可信、客户端和用户（单独或一起）允许的断言范围以及任何相关的服务器端策略的上下文中评估这些断言。
The security semantics of assertions carried by RPCSEC_GSSv3 are application protocol-specific.
RPCSEC_GSSv3所承载的断言的安全语义是特定于应用程序协议的。
Note that RPCSEC_GSSv3 is not a complete solution for labeling: it conveys the labels of actors but not the labels of objects. RPC application protocols may require extending in order to carry object label information.
请注意，RPCSEC_GSSv3并不是一个完整的标签解决方案：它传递的是参与者的标签，而不是对象的标签。RPC应用程序协议可能需要扩展以携带对象标签信息。
There may be interactions with NFSv4's callback security scheme and NFSv4.1's [RFC5661] GSS SSV (Secret State Verifier) mechanisms. Specifically, the NFSv4 callback scheme requires that the server initiate GSS-API security contexts, which does not work well in practice; in the context of client-side processes running as the same user but with different privileges and security labels, the NFSv4 callback security scheme seems particularly unlikely to work well. NFSv4.1 has the server use an existing, client-initiated RPCSEC_GSS context handle to protect server-initiated callback RPCs. The NFSv4.1 callback security scheme lacks all the problems of the NFSv4 scheme; however, it is important that the server pick an appropriate RPCSEC_GSS context handle to protect any callbacks. Specifically, it is important that the server use RPCSEC_GSS context handles that authenticate the client to protect any callbacks related to server state initiated by RPCs protected by RPCSEC_GSSv3 contexts.
可能与NFSv4的回调安全方案和NFSv4.1的[RFC5661]GSS SSV（秘密状态验证器）机制存在交互。具体来说，NFSv4回调方案要求服务器启动GSS-API安全上下文，这在实践中效果不佳；在客户端进程作为同一用户运行但具有不同权限和安全标签的上下文中，NFSv4回调安全方案似乎不太可能正常工作。NFSv4.1让服务器使用现有的、客户端启动的RPCSEC_GSS上下文句柄来保护服务器启动的回调RPC。NFSv4.1回调安全方案缺少NFSv4方案的所有问题；但是，服务器选择适当的RPCSEC_GSS上下文句柄来保护任何回调是很重要的。具体来说，服务器必须使用RPCSEC_GSS上下文句柄对客户端进行身份验证，以保护由受RPCSEC_GSSv3上下文保护的RPC启动的与服务器状态相关的任何回调。
As described in Section 2.10.10 of [RFC5661], the client is permitted to associate multiple RPCSEC_GSS handles with a single SSV GSS context. RPCSEC_GSSv3 handles will work well with SSV in that the man-in-the-middle attacks described in Section 2.10.10 of [RFC5661] are solved by the new reply verifier (Section 2.3). Using an RPCSEC_GSSv3 handle backed by a GSS-SSV mechanism context as a parent handle in an RPCSEC_GSS_CREATE call, while permitted, is complicated by the lifetime rules of SSV contexts and their associated RPCSEC_GSS handles.
如[RFC5661]第2.10.10节所述，允许客户将多个RPCSEC_GSS句柄与单个SSV GSS上下文关联。RPCSEC_GSSv3句柄将与SSV配合使用，因为[RFC5661]第2.10.10节中描述的中间人攻击由新的应答验证器（第2.3节）解决。在RPCSEC_GSS_CREATE调用中使用GSS-SSV机制上下文支持的RPCSEC_GSSv3句柄作为父句柄（虽然允许），但SSV上下文及其关联的RPCSEC_GSS句柄的生存期规则会使其复杂化。
This section uses terms that are defined in [RFC5226].
本节使用[RFC5226]中定义的术语。
The following new RPC Authentication Status Numbers have been added to the IANA registry:
以下新的RPC身份验证状态号已添加到IANA注册表中：
o RPCSEC_GSS_INNER_CREDPROBLEM (15) "No credentials for multi-principal assertion inner context user". See Section 2.7.1.1.
o RPCSEC_GSS_internal_CREDPROBLEM（15）“多主体断言内部上下文用户没有凭据”。见第2.7.1.1节。
o RPCSEC_GSS_LABEL_PROBLEM (16) "Problem with label assertion". See Section 2.7.1.3.
o RPCSEC_GSS_标签问题（16）“标签断言问题”。见第2.7.1.3节。
o RPCSEC_GSS_PRIVILEGE_PROBLEM (17) "Problem with structured privilege assertion". See Section 2.7.1.4.
o RPCSEC_GSS_特权问题（17）“结构化特权断言问题”。见第2.7.1.4节。
o RPCSEC_GSS_UNKNOWN_MESSAGE (18) "Unknown structured privilege assertion". See Section 2.7.1.4.
o RPCSEC_GSS_未知_消息（18）“未知结构化权限断言”。见第2.7.1.4节。
IANA has created a registry called the "RPCSEC_GSS Structured Privilege Names Registry".
IANA创建了一个名为“RPCSEC_GSS结构化特权名称注册表”的注册表。
Structured privilege assertions (Section 2.7.1.4) are defined by a specific RPC application. The namespace identifiers for these assertions (the rp_name) are defined as string names. The RPCSEC_GSSv3 protocol does not define the specific assignment of the namespace for these structured privilege assertion names. The IANA registry promotes interoperability where common interests exist. While RPC application developers are allowed to define and use structured privileges as needed, they are encouraged to register structured privilege assertion names with IANA.
结构化特权断言（第2.7.1.4节）由特定RPC应用程序定义。这些断言的名称空间标识符（rp_名称）被定义为字符串名称。RPCSEC_GSSv3协议没有为这些结构化特权断言名称定义命名空间的特定分配。IANA注册中心在存在共同利益的地方促进互操作性。虽然允许RPC应用程序开发人员根据需要定义和使用结构化权限，但鼓励他们向IANA注册结构化权限断言名称。
The registry is to be maintained using the Standards Action policy as defined in Section 4.1 of [RFC5226].
使用[RFC5226]第4.1节中定义的标准行动政策维护注册表。
Under the RPCSEC_GSS version 3 specification, the name of a structured privilege can in theory be up to 2^32 - 1 bytes in length, but in practice RPC application clients and servers will be unable to handle a string that long. IANA should reject any assignment request with a structured privilege name that exceeds 128 UTF-8 characters. To give the IESG the flexibility to set up bases of assignment of Experimental Use, the prefix "EXPE" is Reserved. The structured privilege with a zero-length name is Reserved.
根据RPCSEC_GSS version 3规范，结构化权限的名称在理论上最多可以有2^32-1字节的长度，但在实践中，RPC应用程序客户端和服务器将无法处理这么长的字符串。IANA应拒绝任何具有超过128个UTF-8字符的结构化权限名称的分配请求。为使IESG能够灵活设置实验使用分配依据，保留前缀“EXPE”。保留具有零长度名称的结构化权限。
The prefix "PRIV" is allocated for Private Use. A site that wants to make use of unregistered named attributes without risk of conflicting with an assignment in IANA's registry should use the prefix "PRIV" in all of its structured privilege assertion names.
前缀“PRIV”分配给私人使用。如果站点希望使用未注册的命名属性而不存在与IANA注册表中的分配冲突的风险，则应在其所有结构化特权断言名称中使用前缀“PRIV”。
Because some RPC application clients and servers have case-insensitive semantics, the fifteen additional lower-case and mixed-case permutations of each of "EXPE" and "PRIV" are Reserved (e.g., "expe", "expE", and "exPe" are Reserved). Similarly, IANA must not allow two assignments that would conflict if both structured privilege names were converted to a common case.
由于某些RPC应用程序客户端和服务器具有不区分大小写的语义，因此保留了“EXPE”和“PRIV”的15个额外的小写和混合大小写排列（例如，“EXPE”、“EXPE”和“EXPE”）。类似地，如果两个结构化特权名称都转换为通用情况，IANA不得允许两个分配发生冲突。
The registry of structured privilege names is a list of assignments, each containing three fields for each assignment.
结构化特权名称的注册表是一个分配列表，每个分配包含三个字段。
1. A US-ASCII string name that is the actual name of the structured privilege. This name must be unique. This string name can be 1 to 128 UTF-8 characters long.
1. US-ASCII字符串名称，它是结构化权限的实际名称。此名称必须是唯一的。此字符串名称的长度可以是1到128个UTF-8字符。
2. A reference to the specification of the RPC-application-defined structured privilege. The reference can consume up to 256 bytes (or more if IANA permits).
2. 对RPC应用程序定义的结构化权限的规范的引用。该引用最多可以消耗256字节（如果IANA允许，则可以消耗更多字节）。
3. The point of contact of the registrant. The point of contact can consume up to 256 bytes (or more if IANA permits).
3. 注册人的联系人。接触点最多可以消耗256个字节（如果IANA允许，可以消耗更多字节）。
The initial registry consists of the three structured privileges defined in [RFC7862].
初始注册表由[RFC7862]中定义的三个结构化权限组成。
1. NAME: copy_to_auth, REFERENCE: RFC 7862, CONTACT: William A.(Andy) Adamson, andros@netapp.com
1. 姓名：抄送作者，参考号：RFC 7862，联系人：William A.（Andy）Adamson，andros@netapp.com
2. NAME: copy_from_auth, REFERENCE: RFC 7862, CONTACT: William A.(Andy) Adamson, andros@netapp.com
2. 姓名：从作者处复制，参考号：RFC 7862，联系人：William A.（Andy）Adamson，andros@netapp.com
3. NAME: copy_confirm_auth, REFERENCE: RFC 7862, CONTACT: William A.(Andy) Adamson, andros@netapp.com
3. 姓名：复印件确认书，参考号：RFC 7862，联系人：William A.（Andy）Adamson，andros@netapp.com
The registrant is always permitted to update the point of contact field. To make any other change will require Expert Review or IESG Approval.
注册人始终被允许更新联系人字段。进行任何其他变更都需要专家审查或IESG批准。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, DOI 10.17487/RFC2203, September 1997, <http://www.rfc-editor.org/info/rfc2203>.
[RFC2203]Eisler，M.，Chiu，A.，和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，DOI 10.17487/RFC2203，1997年9月<http://www.rfc-editor.org/info/rfc2203>.
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，DOI 10.17487/RFC2743，2000年1月<http://www.rfc-editor.org/info/rfc2743>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006, <http://www.rfc-editor.org/info/rfc4506>.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，DOI 10.17487/RFC4506，2006年5月<http://www.rfc-editor.org/info/rfc4506>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, <http://www.rfc-editor.org/info/rfc5056>.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，DOI 10.17487/RFC5056，2007年11月<http://www.rfc-editor.org/info/rfc5056>.
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, DOI 10.17487/RFC5403, February 2009, <http://www.rfc-editor.org/info/rfc5403>.
[RFC5403]艾斯勒，M.“RPCSEC_GSS版本2”，RFC 5403，DOI 10.17487/RFC5403，2009年2月<http://www.rfc-editor.org/info/rfc5403>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>.
[RFC5661]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 5661，DOI 10.17487/RFC5661，2010年1月<http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<http://www.rfc-editor.org/info/rfc7530>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <http://www.rfc-editor.org/info/rfc7862>.
[RFC7862]Haynes，T.，“网络文件系统（NFS）版本4次要版本2协议”，RFC 7862，DOI 10.17487/RFC7862，2016年11月<http://www.rfc-editor.org/info/rfc7862>.
[AFS-RXGK] Wilkinson, S. and B. Kaduk, "Integrating rxgk with AFS", Work in Progress, draft-wilkinson-afs3-rxgk-afs-08, May 2015.
[AFS-RXGK]Wilkinson，S.和B.Kaduk，“RXGK与AFS的整合”，正在进行的工作，草稿-Wilkinson-afs3-RXGK-AFS-082015年5月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5531]Thurlow，R.，“RPC：远程过程调用协议规范版本2”，RFC 5531，DOI 10.17487/RFC5531，2009年5月<http://www.rfc-editor.org/info/rfc5531>.
Acknowledgments
致谢
Andy Adamson would like to thank NetApp, Inc. for its funding of his time on this project.
Andy Adamson感谢NetApp，Inc.为他在该项目上花费的时间提供资金。
We thank Lars Eggert, Mike Eisler, Ben Kaduk, Bruce Fields, Tom Haynes, and Dave Noveck for their most helpful reviews.
我们感谢Lars Eggert、Mike Eisler、Ben Kaduk、Bruce Fields、Tom Haynes和Dave Noveck提供的最有帮助的评论。
Authors' Addresses
作者地址
William A. (Andy) Adamson NetApp 3629 Wagner Ridge Ct. Ann Arbor, MI 48103 United States of America
威廉A.（安迪）亚当森-内塔普3629瓦格纳岭Ct。美国密歇根州安阿伯48103
Phone: +1 734 665 1204
Email: andros@netapp.com
Phone: +1 734 665 1204
Email: andros@netapp.com
Nico Williams cryptonector.com 13115 Tamayo Dr. Austin, TX 78729 United States of America
Nico Williams cryptonector.com 13115 Tamayo Austin博士，德克萨斯州78729美利坚合众国
Email: nico@cryptonector.com
Email: nico@cryptonector.com