Network Working Group M. Eisler
Request for Comments: 5403 NetApp
Updates: 2203 February 2009
Category: Standards Track
Network Working Group M. Eisler
Request for Comments: 5403 NetApp
Updates: 2203 February 2009
Category: Standards Track
RPCSEC_GSS Version 2
RPCSEC_GSS第2版
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API).
本文件描述了RPCSEC_GSS协议的第2版。版本2与版本1（在RFC 2203中指定）相同，只是增加了对通道绑定的支持。RPCSEC_GSS允许远程过程调用（RPC）协议访问通用安全服务应用程序编程接口（GSS-API）。
Table of Contents
目录
1. Introduction and Motivation .....................................2
1.1. Requirements Language ......................................3
2. Channel Bindings Explained ......................................3
3. The RPCSEC_GSSv2 Protocol .......................................4
3.1. Compatibility with RPCSEC_GSSv1 ............................4
3.2. New Version Number .........................................5
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL ....................7
3.4. New Security Service - rpc_gss_svc_channel_prot ...........10
4. Version Negotiation ............................................11
5. Native GSS Channel Bindings ....................................11
6. Operational Recommendation for Deployment ......................11
7. Implementation Notes ...........................................11
8. Acknowledgments ................................................11
9. Security Considerations ........................................11
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
1. Introduction and Motivation .....................................2
1.1. Requirements Language ......................................3
2. Channel Bindings Explained ......................................3
3. The RPCSEC_GSSv2 Protocol .......................................4
3.1. Compatibility with RPCSEC_GSSv1 ............................4
3.2. New Version Number .........................................5
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL ....................7
3.4. New Security Service - rpc_gss_svc_channel_prot ...........10
4. Version Negotiation ............................................11
5. Native GSS Channel Bindings ....................................11
6. Operational Recommendation for Deployment ......................11
7. Implementation Notes ...........................................11
8. Acknowledgments ................................................11
9. Security Considerations ........................................11
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
This document describes RPCSEC_GSS version 2 (RPCSEC_GSSv2). RPCSEC_GSSv2 is the same as RPCSEC_GSS version 1 (RPCSEC_GSSv1) [1] except that support for channel bindings [2] has been added. The primary motivation for channel bindings is to securely take advantage of hardware-assisted encryption that might exist at lower levels of the networking protocol stack, such as at the Internet Protocol (IP) layer in the form of IPsec (see [7] and [8] for information on IPsec channel bindings). The secondary motivation is that even if lower levels are not any more efficient at encryption than the RPCSEC_GSS layer, if encryption is occurring at the lower level, it can be redundant at the RPCSEC_GSS level.
本文档描述了RPCSEC_GSS版本2（RPCSEC_GSSv2）。RPCSEC_GSSv2与RPCSEC_GSS版本1（RPCSEC_GSSv1）[1]相同，只是增加了对通道绑定的支持[2]。通道绑定的主要动机是安全地利用可能存在于网络协议栈较低级别的硬件辅助加密，例如以IPsec形式存在于Internet协议（IP）层（有关IPsec通道绑定的信息，请参见[7]和[8]）。第二个动机是，即使较低级别的加密效率不比RPCSEC_GSS层高，但如果加密发生在较低级别，则在RPCSEC_GSS级别上可能是冗余的。
RPCSEC_GSSv2 and RPCSEC_GSSv1 are protocols that exchange tokens emitted by the Generic Security Services (GSS) framework, which is defined in [3], and differ only in the support for GSS channel bindings in RPCSEC_GSSv2. GSS itself supports channel bindings, and in theory RPCSEC_GSSv2 could use native GSS channel bindings to achieve the effects described in this section. However, as Section 1.1.6 of [3] states, not all implementations of all GSS mechanisms support channel bindings. This is sufficient justification for the approach taken in this document: modify the RPCSEC_GSS protocol to support channel bindings independent of the capabilities of the GSS mechanism being used.
RPCSEC_GSSv2和RPCSEC_GSSv1是交换通用安全服务（GSS）框架发出的令牌的协议，该框架在[3]中定义，不同之处在于RPCSEC_GSSv2中对GSS通道绑定的支持。GSS本身支持通道绑定，理论上RPCSEC_GSSv2可以使用本机GSS通道绑定来实现本节中描述的效果。然而，正如[3]第1.1.6节所述，并非所有GSS机制的所有实现都支持通道绑定。这是本文档中所采用方法的充分理由：修改RPCSEC_GSS协议，以支持独立于所用GSS机制功能的通道绑定。
Once an RPCSEC_GSS target and initiator are mutually assured that they are each using the same secure, end-to-end channel, the overhead of computing message integrity codes (MICs) for authenticating and integrity-protecting RPC requests and replies can be eliminated because the channel is performing the same function. Similarly, if the channel also provides confidentiality, the overhead of RPCSEC_GSS privacy protection can also be eliminated.
一旦RPCSEC_GSS目标和启动器相互确保各自使用相同的安全端到端通道，由于通道正在执行相同的功能，因此可以消除用于验证和完整性保护RPC请求和响应的计算消息完整性代码（MIC）的开销。类似地，如果通道也提供机密性，则RPCSEC_GSS隐私保护的开销也可以消除。
The External Data Representation (XDR) [4] description is provided in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The reader can feed this document into the following shell script to produce the machine-readable XDR description of RPCSEC_GSSv2:
本文档提供了外部数据表示（XDR）[4]说明，使读者能够轻松地提取到可编译的表单中。读者可以将此文档输入以下shell脚本，以生成RPCSEC_GSSv2的机器可读XDR描述：
<CODE BEGINS>
<代码开始>
#!/bin/sh
grep "^ *///" | sed 's?^ *///??'
#!/bin/sh
grep "^ *///" | 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_v2.x
sh extract.sh<spec.txt>rpcsec_gss_v2.x
<CODE ENDS>
<代码结束>
The effect of the script is to remove leading white space from each line of the specification, plus a sentinel sequence of "///".
脚本的作用是从规范的每一行中删除前导空格，再加上“//”的前哨序列。
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 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
If a channel between two parties is secure, there must be shared information between the two parties. This information might be secret or not. The requirement for secrecy depends on the specifics of the channel.
如果双方之间的通道是安全的，则双方之间必须共享信息。这些信息可能是秘密的，也可能不是。保密要求取决于通道的具体情况。
For example, the shared information could be the concatenation of the public key of the source and destination of the channel (where each public key has a corresponding private key). Suppose the channel is not end-to-end, i.e., a man-in-the-middle (MITM) exists, and there are two channels, one from the initiator to the MITM, and one from the MITM to the target. The MITM cannot simply force each channel to use the same public keys, because a public key derives from a private key, and the key management system for each node will surely assign unique or random private keys. At most, the MITM can force one end of each channel to use the same public key. The MIC of the public keys from the initiator will not be verified by the target, because at least one of the public keys will be different. Similarly, the MIC of the public keys from the target will not be verified by the initiator because at least one of the public keys will be different.
例如，共享信息可以是信道的源和目的地的公钥的串联（其中每个公钥具有相应的私钥）。假设通道不是端到端的，即中间人（MITM）存在，并且有两个通道，一个从启动器到MITM，另一个从MITM到目标。MITM不能简单地强制每个通道使用相同的公钥，因为公钥来自私钥，每个节点的密钥管理系统肯定会分配唯一或随机的私钥。最多，MITM可以强制每个通道的一端使用相同的公钥。目标将不会验证来自启动器的公钥的MIC，因为至少有一个公钥是不同的。类似地，来自目标的公钥的MIC将不会由发起方验证，因为至少一个公钥将不同。
A higher-layer protocol using the secure channel can safely exploit the channel to the mutual benefit of the higher-level parties if each higher-level party can prove:
使用安全通道的更高层协议可以安全地利用通道，以实现更高层方的互利，前提是每个更高层方能够证明：
o They each know the channel's shared information.
o 他们每个人都知道频道的共享信息。
o The proof of the knowledge of the shared information is in fact being conveyed by each of the higher-level parties, and not some other entities.
o 事实上，共享信息的知识证明是由每一个更高级别的当事方而不是某些其他实体传递的。
RPCSEC_GSSv2 simply adds an optional round-trip that has the initiator compute a GSS MIC on the channel binding's shared information, and sends the MIC to the target. The target verifies the MIC, and in turn sends its own MIC of the shared information to the initiator that then verifies the target's MIC. This accomplishes three things. First, the initiator and target are mutually authenticated. Second, the initiator and target prove they know the channel's shared information, and thus are using the same channel. Third, the first and second things are done simultaneously.
RPCSEC_GSSv2只是简单地添加了一个可选的往返过程，让启动器根据通道绑定的共享信息计算GSS MIC，并将MIC发送到目标。目标验证MIC，然后将其自己的共享信息MIC发送给启动器，然后启动器验证目标的MIC。这可以完成三件事。首先，启动器和目标是相互认证的。其次，发起者和目标证明他们知道通道的共享信息，因此使用相同的通道。第三，第一件事和第二件事同时进行。
The RPCSEC_GSSv2 protocol will now be explained. The entire protocol is not presented. Instead the differences between RPCSEC_GSSv2 and RPCSEC_GSSv1 are shown.
现在将解释RPCSEC_GSSv2协议。没有介绍整个协议。相反，显示了RPCSEC_GSSv2和RPCSEC_GSSv1之间的差异。
The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2.
RPCSEC_GSSv2完全支持RPCSEC_GSSv1的功能。
<CODE BEGINS>
<代码开始>
/// /*
/// * Copyright (c) 2009 IETF Trust and the persons identified
/// * as the document authors. All rights reserved.
/// *
/// * The document authors are identified in [RFC2203] and
/// * [RFC5403].
/// *
/// * 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 [RFC2203]. Please
/// * reproduce this note if possible.
/// /*
/// * Copyright (c) 2009 IETF Trust and the persons identified
/// * as the document authors. All rights reserved.
/// *
/// * The document authors are identified in [RFC2203] and
/// * [RFC5403].
/// *
/// * 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 [RFC2203]. 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 /* new */
/// };
///
/// 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 /* 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; /* new */
///
/// union rpc_gss_cred_t switch (unsigned int rgc_version) {
/// case RPCSEC_GSS_VERS_1:
/// case RPCSEC_GSS_VERS_2: /* new */
/// rpc_gss_cred_vers_1_t rgc_cred_v1;
/// };
///
/// */
///
/// 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 /* new */
/// };
///
/// 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 /* 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; /* new */
///
/// union rpc_gss_cred_t switch (unsigned int rgc_version) {
/// case RPCSEC_GSS_VERS_1:
/// case RPCSEC_GSS_VERS_2: /* new */
/// rpc_gss_cred_vers_1_t rgc_cred_v1;
/// };
///
<CODE ENDS>
<代码结束>
Figure 1
图1
As is apparent from the above, the RPCSEC_GSSv2 credential has the same format as the RPCSEC_GSSv1 credential (albeit corrected so that the definition is in legal XDR description language that is also compatible with [9]; hence, the field "version", a keyword in RFC 1831, is replaced with "rgc_version"). Setting the rgc_version field to 2 indicates that the initiator and target support channel bindings.
从上面可以明显看出，RPCSEC_GSSv2凭证的格式与RPCSEC_GSSv1凭证的格式相同（尽管进行了更正，以便定义采用与[9]兼容的合法XDR描述语言；因此，RFC 1831中的关键字“版本”字段被替换为“rgc_版本”）。将rgc_version字段设置为2表示启动器和目标支持通道绑定。
<CODE BEGINS>
<代码开始>
/// struct rgss2_bind_chan_MIC_in_args {
/// opaque rbcmia_bind_chan_hash<>;
/// };
///
/// typedef opaque rgss2_chan_pref<>;
/// typedef opaque rgss2_oid<>;
///
/// struct rgss2_bind_chan_verf_args {
/// rgss2_chan_pref rbcva_chan_bind_prefix;
/// rgss2_oid rbcva_chan_bind_oid_hash;
/// opaque rbcva_chan_mic<>;
/// };
///
/// struct rgss2_bind_chan_MIC_in_args {
/// opaque rbcmia_bind_chan_hash<>;
/// };
///
/// typedef opaque rgss2_chan_pref<>;
/// typedef opaque rgss2_oid<>;
///
/// struct rgss2_bind_chan_verf_args {
/// rgss2_chan_pref rbcva_chan_bind_prefix;
/// rgss2_oid rbcva_chan_bind_oid_hash;
/// opaque rbcva_chan_mic<>;
/// };
///
<CODE ENDS>
<代码结束>
Figure 2
图2
Once an RPCSEC_GSSv2 handle has been established over a secure channel, the initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 1). Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be used. Unlike those two requests, the arguments of the NULL procedure are not overloaded, because the verifier is of sufficient size for the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc were set to RPCSEC_GSS_DATA. The service field is set to rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT.
一旦在安全通道上建立了RPCSEC_GSSv2句柄，发起方可以发出RPCSEC_GSS_BIND_通道（图1）。目标必须支持RPCSEC\U GSS\U BIND\U通道。与RPCSEC_GSS_INIT和RPCSEC_GSS_CONTINUE_INIT请求一样，必须使用NULL RPC过程。与这两个请求不同，NULL过程的参数没有重载，因为验证器的大小足以满足RPCSEC_GSS_BIND_通道的需要。gss_proc字段设置为RPCSEC_gss_BIND_通道。seq_num字段设置为gss_proc设置为RPCSEC_gss_数据。服务字段设置为rpc\u gss\u svc\u none。句柄字段设置为RPCSEC_GSS_INIT或RPCSEC_GSS_CONTINUE_INIT返回的RPCSEC_GSS句柄字段。
The RPCSEC_GSS_BIND_CHANNEL request is similar to the RPCSEC_GSS_DATA request in that the verifiers of both contain MICs. As described in Section 5.3.1 of [1], when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is set to the output of GSS_GetMIC() on the RPC header. When gss_proc is RPCSEC_GSS_BIND_CHANNEL the verifier of an RPC request is set to the XDR encoding on a value of data type rgss2_bind_chan_verf_args, which includes a MIC as described below. The rgss2_bind_chan_verf_args data type consists of three fields:
RPCSEC_GSS_BIND_信道请求类似于RPCSEC_GSS_数据请求，因为两者的验证器都包含MIC。如[1]第5.3.1节所述，当gss_proc是RPCSEC_gss_数据时，RPC请求的验证器设置为RPC头上gss_GetMIC（）的输出。当gss_proc为RPCSEC_gss_BIND_chan_verf_args时，RPC请求的验证器被设置为数据类型为rgss2_BIND_chan_verf_args的值上的XDR编码，该值包括如下所述的MIC。rgss2_bind_chan_verf_args数据类型由三个字段组成：
o rbcva_chan_bind_prefix. This is the channel binding prefix as described in [2] up to, but excluding, the colon (ASCII 0x3A) that separates the prefix from the suffix.
o rbcva\u chan\u bind\u前缀。这是[2]中所述的通道绑定前缀，不包括将前缀与后缀分开的冒号（ASCII 0x3A）。
o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of the hash algorithm used to compute rbcmia_bind_chan_hash. This field contains an OID encoded in ASN.1 as used by GSS-API in the mech_type argument to GSS_Init_sec_context ([3]). See [6] for the OIDs of the SHA one-way hash algorithms.
o rbcva\u chan\u bind\u hash\u oid。这是用于计算rbcmia_bind_chan_散列的散列算法的对象标识符（OID）。此字段包含ASN.1中编码的OID，GSS-API在GSS_Init_sec_上下文（[3]）的mech_type参数中使用该OID。有关SHA单向哈希算法的OID，请参见[6]。
o rbcva_chan_mic. This is the output of GSS_GetMIC() on the concatenation of the XDR-encoded RPC header ("up to and including the credential" as per [1]) and the XDR encoding of an instance of type data rgss2_bind_chan_MIC_in_args. The data type rgss2_bind_chan_MIC_in_args consists of one field, rbcmia_bind_chan_hash, which is a hash of the channel bindings as defined in [2]. The channel bindings are a "canonical octet string encoding of the channel bindings", starting "with the channel bindings prefix followed by a colon (ASCII 0x3A)". The reason a hash of the channel bindings and not the actual channel bindings are used to compute rbcva_chan_mic is that some channel bindings, such as those composed of public keys, can be relatively large, and thus place a higher space burden on the implementations to manage. One way hashes consume less space.
o rbcva_chan_麦克风。这是GSS_GetMIC（）在XDR编码的RPC头（“根据[1]）和类型为rgss2_bind_chan_MIC_in_args的实例的XDR编码的串联上的输出。_args中的数据类型rgss2_bind_chan_MIC_由一个字段rbcmia_bind_chan_hash组成，它是[2]中定义的通道绑定的散列。通道绑定是“通道绑定的规范八位字节字符串编码”，以“通道绑定前缀后跟冒号（ASCII 0x3A）”开头。使用通道绑定哈希而不是实际通道绑定来计算rbcva_chan____mic的原因是，某些通道绑定（例如由公钥组成的绑定）可能相对较大，从而给要管理的实现带来更大的空间负担。单向散列占用更少的空间。
<CODE BEGINS>
<代码开始>
/// enum rgss2_bind_chan_status {
/// RGSS2_BIND_CHAN_OK = 0,
/// RGSS2_BIND_CHAN_PREF_NOTSUPP = 1,
/// RGSS2_BIND_CHAN_HASH_NOTSUPP = 2
/// };
///
/// union rgss2_bind_chan_res switch
/// (rgss2_bind_chan_status rbcr_stat) {
///
/// case RGSS2_BIND_CHAN_OK:
/// void;
///
/// case RGSS2_BIND_CHAN_PREF_NOTSUPP:
/// rgss2_chan_pref rbcr_pref_list<>;
///
/// case RGSS2_BIND_CHAN_HASH_NOTSUPP:
/// rgss2_oid rbcr_oid_list<>;
/// };
///
/// struct rgss2_bind_chan_MIC_in_res {
/// unsigned int rbcmr_seq_num;
/// opaque rbcmr_bind_chan_hash<>;
/// rgss2_bind_chan_res rbcmr_res;
/// };
///
/// enum rgss2_bind_chan_status {
/// RGSS2_BIND_CHAN_OK = 0,
/// RGSS2_BIND_CHAN_PREF_NOTSUPP = 1,
/// RGSS2_BIND_CHAN_HASH_NOTSUPP = 2
/// };
///
/// union rgss2_bind_chan_res switch
/// (rgss2_bind_chan_status rbcr_stat) {
///
/// case RGSS2_BIND_CHAN_OK:
/// void;
///
/// case RGSS2_BIND_CHAN_PREF_NOTSUPP:
/// rgss2_chan_pref rbcr_pref_list<>;
///
/// case RGSS2_BIND_CHAN_HASH_NOTSUPP:
/// rgss2_oid rbcr_oid_list<>;
/// };
///
/// struct rgss2_bind_chan_MIC_in_res {
/// unsigned int rbcmr_seq_num;
/// opaque rbcmr_bind_chan_hash<>;
/// rgss2_bind_chan_res rbcmr_res;
/// };
///
/// struct rgss2_bind_chan_verf_res {
/// rgss2_bind_chan_res rbcvr_res;
/// opaque rbcvr_mic<>;
/// };
///
/// struct rgss2_bind_chan_verf_res {
/// rgss2_bind_chan_res rbcvr_res;
/// opaque rbcvr_mic<>;
/// };
///
<CODE ENDS>
<代码结束>
Figure 3
图3
The RPCSEC_GSS_BIND_CHANNEL reply is similar to the RPCSEC_GSS_DATA reply in that the verifiers of both contain MICs. When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC reply is set to the output of GSS_GetMIC() on the seq_num of the credential of the corresponding request (as described in Section 5.3.3.2 of [1]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the XDR encoding of an instance of data type rgss2_bind_chan_verf_res, which includes a MIC as described below. The data type rgss2_bind_chan_verf_res consists of two fields.
RPCSEC_GSS_BIND_信道应答与RPCSEC_GSS_数据应答类似，因为两者的验证器都包含MIC。当gss_proc为RPCSEC_gss_DATA时，RPC应答的验证器设置为相应请求凭证序号上的gss_GetMIC（）输出（如[1]第5.3.3.2节所述）。当gss_proc是RPCSEC_gss_BIND_通道时，RPC应答的验证器被设置为数据类型为rgss2_BIND_chan_verf_res的实例的XDR编码，该实例包括如下所述的麦克风。数据类型rgss2_bind_chan_verf_res由两个字段组成。
o rbcvr_res. The data type of this field is rgss2_bind_chan_res. The rgss2_bind_chan_res data type is a switched union consisting of three cases switched on the status contained in the rbcr_stat field.
o rbcvr_res。此字段的数据类型为rgss2_bind_chan_res。rgss2_bind_chan_res数据类型是一个切换的并集，由rbcr_stat字段中包含的状态切换的三种情况组成。
* RGSS2_BIND_CHAN_OK. If this status is returned, the target accepted the channel bindings, and successfully verified rbcva_chan_mic in the request. No additional results will be in rbcvr_res.
* RGSS2_BIND_CHAN_OK。如果返回此状态，则目标接受通道绑定，并成功验证请求中的rbcva_chan_mic。rbcvr_res中不会有其他结果。
* RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the target did not support the prefix in the rbcva_chan_bind_prefix field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL request was rejected. The target returned a list of prefixes it does support in the field rbcr_pref_list. Note that a channel can have multiple channel bindings each with different prefixes. The initiator is free to pick its preferred prefix. If the target does not support the prefix, the status RGSS2_BIND_CHAN_PREF_NOTSUPP will be returned, and the initiator can select its next most preferred prefix among the prefixes the target does support.
* RGSS2\u BIND\u CHAN\u PREF\u NOTSUPP。如果返回此状态，则目标不支持参数的rbcva_chan_bind_前缀字段中的前缀，因此RPCSEC_GSS_bind_通道请求被拒绝。目标在字段rbcr\u pref\u list中返回了它确实支持的前缀列表。请注意，一个通道可以有多个通道绑定，每个绑定具有不同的前缀。启动器可以自由选择其首选前缀。如果目标不支持前缀，将返回状态RGSS2_BIND_CHAN_PREF_NOTSUPP，发起方可以在目标支持的前缀中选择下一个最首选的前缀。
* RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the target did not support the hash algorithm identified in the rbcva_chan_bind_hash_oid field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL request was rejected. The target
* RGSS2_BIND_CHAN_HASH_NOTSUPP。如果返回此状态，则目标不支持参数的rbcva_chan_bind_hash_oid字段中标识的哈希算法，因此RPCSEC_GSS_bind_通道请求被拒绝。目标
returned a list of OIDs of hash algorithms it does support in the field rbcr_oid_list. The array rbcr_oid_list MUST have one or more elements.
在rbcr_oid_列表字段中返回了它确实支持的哈希算法的oid列表。数组rbcr\u oid\u列表必须有一个或多个元素。
o rbcvr_mic. The value of this field is equal to the output of GSS_GetMIC() on the XDR encoding of an instance of data type rgss2_bind_chan_MIC_in_res. The data type rgss2_bind_chan_MIC_in_res consists of three fields.
o rbcvr_话筒。此字段的值等于数据类型rgss2_bind_chan_MIC_in_res实例的XDR编码上GSS_GetMIC（）的输出。数据类型rgss2_bind_chan_MIC_in_res由三个字段组成。
* rbcmr_seq_num. The value of this field is equal to the field seq_num in the RPCSEC_GSS credential (data type rpc_gss_cred_vers_1_t).
* rbcmr_seq_num。此字段的值等于RPCSEC_GSS凭据（数据类型为rpc_GSS_cred_versu 1_t）中的字段seq_num。
* rbcmr_bind_chan_hash. This is the result of the one way hash of the channel bindings (including the prefix). If rbcr_stat is not RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm that is used to compute rbcmr_bind_chan_hash is that identified by the rbcva_chan_bind_oid_hash field in the arguments to RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to compute rbcmr_bind_chan_hash is that identified by rbcr_oid_list[0] in the results.
* rbcmr\u bind\u chan\u hash。这是通道绑定（包括前缀）单向散列的结果。如果rbcr_stat不是RGSS2_BIND_CHAN_HASH_NOTSUPP，则用于计算rbcmr_BIND_CHAN_HASH的散列算法是由RPCSEC_GSS_BIND_通道参数中的rbcva_CHAN_BIND_oid_散列字段标识的散列算法。如果rbcr_stat是RGSS2_BIND_CHAN_HASH_NOTSUPP，则用于计算rbcmr_BIND_CHAN_HASH的哈希算法是由结果中的rbcr_oid_列表[0]标识的哈希算法。
* rbcmr_res. The value of this field is equal to the value of the rbcvr_res field.
* rbcmr_res。此字段的值等于rbcvr_res字段的值。
RPCSEC_GSSv2 targets MUST support rpc_gss_svc_channel_prot.
RPCSEC_GSSv2目标必须支持rpc_gss_svc_通道保护。
The rpc_gss_svc_channel_prot service (Figure 1) is valid only if RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed successfully, and the secure channel still exists. When rpc_gss_svc_channel_prot is used, the RPC requests and replies are similar to those of rpc_gss_svc_none except that the verifiers on the request and reply always have the flavor set to AUTH_NONE, and the contents are zero length.
rpc_gss_svc_channel_prot服务（图1）仅在使用RPCSEC_GSSv2、成功执行RPCSEC_gss_BIND_channel过程且安全通道仍然存在时有效。当使用rpc_gss_svc_channel_prot时，rpc请求和回复与rpc_gss_svc_none的请求和回复类似，只是请求和回复上的验证器始终具有设置为AUTH_none的风格，并且内容长度为零。
Note that even though NULL verifiers are used when rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are used. In order to identify the principal sending the request, the same credential is used as before, except that service field is set to rpc_gss_svc_channel_prot.
请注意，即使在使用rpc_gss_svc_channel_prot时使用空验证器，也会使用非空的RPCSEC_gss凭据。为了识别发送请求的主体，将使用与之前相同的凭证，但服务字段设置为rpc_gss_svc_channel_prot。
An initiator that supports version 2 of RPCSEC_GSS simply issues an RPCSEC_GSS request with the rgc_version field set to RPCSEC_GSS_VERS_2. If the target does not recognize RPCSEC_GSS_VERS_2, the target will return an RPC error per Section 5.1 of [1].
支持RPCSEC_GSS版本2的启动器只需发出RPCSEC_GSS请求，并将rgc_版本字段设置为RPCSEC_GSS_VERS_2。如果目标无法识别RPCSEC_GSS_VERS_2，则目标将根据[1]第5.1节返回RPC错误。
The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 2 of a target with version 1 of the same target. The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 1 of a target with version 2 of the same target.
启动器不得尝试使用目标版本2返回的RPCSEC_GSS句柄，该句柄与同一目标版本1相同。启动器不得尝试使用目标版本1返回的RPCSEC_GSS句柄和同一目标版本2返回的句柄。
To ensure interoperability, implementations of RPCSEC_GSSv2 SHOULD NOT transfer tokens between the initiator and target that use native GSS channel bindings (as defined in Section 1.1.6 of [3]).
为确保互操作性，RPCSEC_GSSv2的实现不应在使用本机GSS通道绑定（如[3]第1.1.6节所定义）的启动器和目标之间传输令牌。
RPCSEC_GSSv2 is a superset of RPCSEC_GSSv1, and so can be used in all situations where RPCSEC_GSSv1 is used. RPCSEC_GSSv2 should be used when the new functionality, channel bindings, is desired or needed.
RPCSEC_GSSv2是RPCSEC_GSSv1的超集，因此可以在使用RPCSEC_GSSv1的所有情况下使用。当需要或需要新功能（通道绑定）时，应使用RPCSEC_GSSv2。
Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been performed on an RPCSEC_GSSv2 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_GSSv2上下文句柄上成功执行了RPCSEC_GSS_BIND_通道过程，发起方的实现可能会将rpc_GSS_svc_none和rpc_GSS_svc_完整性的应用程序请求映射到rpc_GSS_svc_通道保护凭据。如果安全通道启用了隐私，则对rpc_gss_svc_隐私的请求也可以映射到rpc_gss_svc_channel_prot。
Nicolas Williams had the idea for extending RPCSEC_GSS to support channel bindings. Alex Burlyga, Lars Eggert, Pasi Eronen, and Dan Romascanu reviewed the document and gave valuable feedback for improving its readability.
Nicolas Williams提出了扩展RPCSEC_GSS以支持通道绑定的想法。Alex Burlyga、Lars Eggert、Pasi Eronen和Dan Romascanu审查了该文件，并为提高其可读性提供了宝贵的反馈。
The base security considerations consist of:
基本安全注意事项包括：
o All security considerations from [1].
o [1]中的所有安全注意事项。
o All security considerations from [2].
o [2]中的所有安全注意事项。
o All security considerations from the actual secure channel being used.
o 使用的实际安全通道的所有安全注意事项。
Even though RPCSEC_GSS_DATA requests that use rpc_gss_svc_channel_prot protection do not involve construction of more GSS tokens, the target SHOULD stop allowing RPCSEC_GSS_DATA requests with rpc_gss_svc_channel_prot protection once the GSS context expires.
即使使用rpc_GSS_svc_channel_prot保护的RPCSEC_GSS_数据请求不涉及构造更多的GSS令牌，但一旦GSS上下文过期，目标应停止允许带有rpc_GSS_svc_channel_prot保护的RPCSEC_GSS_数据请求。
With the use of channel bindings, it becomes extremely critical that the message integrity code (MIC) used by the GSS mechanism that RPCSEC_GSS is using be difficult to forge. While this requirement is true for RPCSEC_GSSv1, and indeed any protocol that uses GSS MICs, the distinction in the seriousness is that for RPCSEC_GSSv1, forging a single MIC at most allows the attacker to succeed in injecting one bogus request. Whereas, with RPCSEC_GSSv2 combined with channel bindings, by forging a single MIC the attacker will succeed in injecting bogus requests as long as the channel exists. An example illustrates. Suppose we have an RPCSEC_GSSv1 initiator, a man-in-the-middle (MITM), an RPCSEC_GSSv1 target, and an RPCSEC_GSSv2 target. The attack is as follows.
通过使用通道绑定，RPCSEC_GSS正在使用的GSS机制使用的消息完整性代码（MIC）很难伪造，这一点变得非常关键。虽然这一要求适用于RPCSEC_GSSv1，实际上适用于任何使用GSS MIC的协议，但严重性的区别在于，对于RPCSEC_GSSv1，伪造一个MIC最多允许攻击者成功注入一个伪造请求。然而，通过RPCSEC_GSSv2与通道绑定的结合，只要通道存在，攻击者就可以通过伪造单个MIC成功注入虚假请求。一个例子说明了这一点。假设我们有一个RPCSEC_GSSv1启动器、一个中间人（MITM）、一个RPCSEC_GSSv1目标和一个RPCSEC_GSSv2目标。攻击如下。
o The MITM intercepts the initiator's RPCSEC_GSSv1 RPCSEC_GSS_INIT message and changes the version number from 1 to 2 before forwarding to the RPCSEC_GSSv2 target, and changes the reply's version number from 2 to 1 before forwarding to the RPCSEC_GSSv1 initiator. Neither the client nor the server notice.
o MITM截获启动器的RPCSEC_GSSv1 RPCSEC_GSS_INIT消息，并在转发到RPCSEC_GSSv2目标之前将版本号从1更改为2，在转发到RPCSEC_GSSv1启动器之前将回复的版本号从2更改为1。客户端和服务器都没有注意到。
o Once the RPCSEC_GSS handle is in an established state, the initiator sends its first RPCSEC_GSS_DATA request. The MITM constructs an RPCSEC_GSS_BIND_CHANNEL request, using the message integrity code (MIC) of the RPCSEC_GSS_DATA request. It is likely the RPCSEC_GSSv2 target will reject the request. The MITM continues to reiterate each time the initiator sends another RPCSEC_GSS_DATA request. With enough iterations, the probability of a MIC from an RPCSEC_GSS_DATA being successfully verified in the forged RPCSEC_GSS_BIND_CHANNEL increases. Once the MITM succeeds, it can send RPCSEC_GSS_DATA requests with a security service of rpc_gss_svc_channel_prot, which does not have MICs in the RPC request's verifier.
o 一旦RPCSEC_GSS句柄处于已建立状态，启动器将发送其第一个RPCSEC_GSS_数据请求。MITM使用RPCSEC_GSS_数据请求的消息完整性代码（MIC）构造RPCSEC_GSS_绑定_通道请求。RPCSEC_GSSv2目标可能会拒绝该请求。每次启动器发送另一个RPCSEC_GSS_数据请求时，MITM都会继续重复。通过足够的迭代，来自RPCSEC_GSS_数据的MIC在伪造的RPCSEC_GSS_BIND_信道中成功验证的概率增加。一旦MITM成功，它可以使用rpc_GSS_svc_channel_prot安全服务发送RPCSEC_GSS_数据请求，rpc请求的验证器中没有MIC。
The implementation of RPCSEC_GSSv2 can use at least two methods to thwart these attacks.
RPCSEC_GSSv2的实现至少可以使用两种方法来阻止这些攻击。
o The target SHOULD require a stronger MIC when sending an RPCSEC_GSS_BIND_CHANNEL request instead of an RPCSEC_GSS_DATA request -- e.g., if HMACs are used for the MICs, require the widest possible HMAC (in terms of bit length) that the GSS
o 当发送RPCSEC_GSS_BIND_信道请求而不是RPCSEC_GSS_数据请求时，目标应要求更强的MIC——例如，如果HMAC用于MIC，则要求GSS具有尽可能宽的HMAC（以位长度计）
mechanism supports. If HMACs are being used, and the target expects N RPCSEC_GSS_DATA requests to be sent on the context before it expires, then the target SHOULD require an HMAC for RPCSEC_GSS_BIND_CHANNEL that is log base 2 N bits longer than what it normally requires for RPCSEC_GSS_DATA requests. If a long enough MIC is not available, then the target could artificially limit the number of RPCSEC_GSS_DATA requests it will allow on the context before deleting the context.
机制支持。如果正在使用HMAC，并且目标希望在过期之前在上下文上发送N个RPCSEC_GSS_数据请求，则目标应要求RPCSEC_GSS_绑定_通道的HMAC的对数基数为2 N位，比RPCSEC_GSS_数据请求通常需要的长度长。如果没有足够长的MIC可用，则目标可能会在删除上下文之前人为限制其在上下文上允许的RPCSEC_GSS_数据请求的数量。
o Each time an RPCSEC_GSSv2 target experiences a failure to verify the MIC of an RPCSEC_GSS_BIND_CHANNEL request, it SHOULD reduce the lifetime of the underlying GSS context, by a significant fraction, thereby preventing the MITM from using the established context for its attack. A possible heuristic is that if the target believes the possibility that failure to verify the MIC was because of an attack is X percent, then the context's lifetime would be reduced by X percent. For simplicity, an implementer might set X to be 50 percent, so that the context lifetime is halved on each failed verification of an RPCSEC_GSS_BIND_CHANNEL request and thus rapidly reduced to zero on subsequent requests. For example, with a context lifetime of 8 hours (or 28800 seconds), 15 failed attempts by the MITM would cause the context to be destroyed.
o 每次RPCSEC_GSSv2目标无法验证RPCSEC_GSS_BIND_通道请求的MIC时，它都应该将基础GSS上下文的生存期缩短一大部分，从而防止MITM使用已建立的上下文进行攻击。一种可能的启发式方法是，如果目标相信由于攻击导致无法验证MIC的可能性为X%，则上下文的生存期将减少X%。为简单起见，实现者可以将X设置为50%，这样，每次验证RPCSEC_GSS_BIND_通道请求失败时，上下文生存期都会减少一半，从而在后续请求中迅速减少为零。例如，当上下文生存期为8小时（或28800秒）时，MITM的15次失败尝试将导致上下文被破坏。
A method of mitigation that was considered was to protect the RPCSEC_GSS version number with RPCSEC_GSSv2's RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT tokens. Thus, the version number of RPCSEC_GSS would be in the tokens. This method does not completely mitigate the attack; it just moves the MIC guessing to the RPCSEC_GSS_INIT message. In addition, without changing GSS, or the GSS mechanism, there is no way to include the RPCSEC_GSS version number in the tokens. So for these reasons this method was not selected.
考虑的缓解方法是使用RPCSEC_GSSv2的RPCSEC_GSS_INIT和RPCSEC_GSS_CONTINUE_INIT令牌保护RPCSEC_GSS版本号。因此，RPCSEC_GSS的版本号将在令牌中。这种方法不能完全缓解攻击；它只是将麦克风猜测移动到RPCSEC_GSS_INIT消息。此外，如果不更改GSS或GSS机制，则无法在令牌中包含RPCSEC_GSS版本号。因此，出于这些原因，未选择此方法。
[1] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[1] Eisler，M.，Chiu，A.，和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，1997年9月。
[2] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[2] Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[3] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[3] 林恩，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[4] Eisler, M., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[4] 艾斯勒，M.，“XDR：外部数据表示标准”，STD 67，RFC 4506，2006年5月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[6] Schaad，J.，Kaliski，B.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[7] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, November 2008.
[7] Williams，N.，“IPsec通道：连接锁存”，正在进行的工作，2008年11月。
[8] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys", Work in Progress, April 2008.
[8] Williams，N.，“使用IKEv2和公钥的IPsec端点通道绑定”，正在进行的工作，2008年4月。
[9] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[9] Srinivasan，R.，“RPC：远程过程调用协议规范版本2”，RFC 18311995年8月。
Author's Address
作者地址
Mike Eisler NetApp 5765 Chase Point Circle Colorado Springs, CO 80919 US
Mike Eisler NetApp 5765 Chase Point Circle科罗拉多州斯普林斯市美国80919
Phone: +1-719-599-9026
EMail: mike@eisler.com
Phone: +1-719-599-9026
EMail: mike@eisler.com