Internet Engineering Task Force (IETF) S. Josefsson
Request for Comments: 5801 SJD AB
Category: Standards Track N. Williams
ISSN: 2070-1721 Oracle
July 2010
Internet Engineering Task Force (IETF) S. Josefsson
Request for Comments: 5801 SJD AB
Category: Standards Track N. Williams
ISSN: 2070-1721 Oracle
July 2010
Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
在简单身份验证和安全层（SASL）中使用通用安全服务应用程序接口（GSS-API）机制：GS2机制系列
Abstract
摘要
This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported.
本文档描述了如何在简单身份验证和安全层（SASL）框架中使用通用安全服务应用程序接口（GSS-API）机制。这是通过定义一个新的SASL机制族（称为GS2）来实现的。与以前的“SASL/GSSAPI”机制相比，此机制系列提供了许多改进：它更通用，在某些情况下在身份验证阶段使用的消息更少，并且支持可协商使用通道绑定。仅支持支持通道绑定和相互身份验证的GSS-API机制。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc5801.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5801.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
3. Mechanism Name ..................................................5
3.1. Generating SASL Mechanism Names from GSS-API OIDs ..........5
3.2. Computing Mechanism Names Manually .........................6
3.3. Examples ...................................................6
3.4. Grandfathered Mechanism Names ..............................7
4. SASL Authentication Exchange Message Format .....................8
5. Channel Bindings ...............................................10
5.1. Content of GSS-CHANNEL-BINDINGS Structure .................11
5.2. Default Channel Binding ...................................12
6. Examples .......................................................12
7. Authentication Conditions ......................................14
8. GSS-API Parameters .............................................15
9. Naming .........................................................15
10. GSS_Inquire_SASLname_for_mech Call ............................15
10.1. gss_inquire_saslname_for_mech ............................16
11. GSS_Inquire_mech_for_SASLname Call ............................18
11.1. gss_inquire_mech_for_saslname ............................19
12. Security Layers ...............................................20
13. Interoperability with the SASL GSSAPI Mechanism ...............20
13.1. The Interoperability Problem .............................20
13.2. Resolving the Problem ....................................20
13.3. Additional Recommendations ...............................20
14. GSS-API Mechanisms That Negotiate Other Mechanisms ............21
14.1. The Interoperability Problem .............................21
14.2. Security Problem .........................................21
14.3. Resolving the Problems ...................................21
15. IANA Considerations ...........................................22
16. Security Considerations .......................................22
17. Acknowledgements ..............................................24
18. References ....................................................24
18.1. Normative References .....................................24
18.2. Informative References ...................................25
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
3. Mechanism Name ..................................................5
3.1. Generating SASL Mechanism Names from GSS-API OIDs ..........5
3.2. Computing Mechanism Names Manually .........................6
3.3. Examples ...................................................6
3.4. Grandfathered Mechanism Names ..............................7
4. SASL Authentication Exchange Message Format .....................8
5. Channel Bindings ...............................................10
5.1. Content of GSS-CHANNEL-BINDINGS Structure .................11
5.2. Default Channel Binding ...................................12
6. Examples .......................................................12
7. Authentication Conditions ......................................14
8. GSS-API Parameters .............................................15
9. Naming .........................................................15
10. GSS_Inquire_SASLname_for_mech Call ............................15
10.1. gss_inquire_saslname_for_mech ............................16
11. GSS_Inquire_mech_for_SASLname Call ............................18
11.1. gss_inquire_mech_for_saslname ............................19
12. Security Layers ...............................................20
13. Interoperability with the SASL GSSAPI Mechanism ...............20
13.1. The Interoperability Problem .............................20
13.2. Resolving the Problem ....................................20
13.3. Additional Recommendations ...............................20
14. GSS-API Mechanisms That Negotiate Other Mechanisms ............21
14.1. The Interoperability Problem .............................21
14.2. Security Problem .........................................21
14.3. Resolving the Problems ...................................21
15. IANA Considerations ...........................................22
16. Security Considerations .......................................22
17. Acknowledgements ..............................................24
18. References ....................................................24
18.1. Normative References .....................................24
18.2. Informative References ...................................25
Generic Security Service Application Program Interface (GSS-API) [RFC2743] is a framework that provides security services to applications using a variety of authentication mechanisms. Simple Authentication and Security Layer (SASL) [RFC4422] is a framework to provide authentication and security layers for connection-based protocols, also using a variety of mechanisms. This document describes how to use a GSS-API mechanism as though it were a SASL mechanism. This facility is called GS2 -- a moniker that indicates that this is the second GSS-API->SASL mechanism bridge. The original GSS-API->SASL mechanism bridge was specified by [RFC2222], now [RFC4752]; we shall sometimes refer to the original bridge as GS1 in this document.
通用安全服务应用程序接口（GSS-API）[RFC2743]是一个框架，它使用各种身份验证机制为应用程序提供安全服务。简单身份验证和安全层（SASL）[RFC4422]是一个为基于连接的协议提供身份验证和安全层的框架，也使用各种机制。本文档描述了如何像使用SASL机制一样使用GSS-API机制。这个工具称为GS2——一个名字，表示这是第二个GSS-API->SASL机制桥。原来的GSS-API->SASL机制桥由[RFC2222]指定，现在是[RFC4752]；在本文件中，我们有时将原始桥梁称为GS1。
All GSS-API mechanisms are implicitly registered for use within SASL by this specification. The SASL mechanisms defined in this document are known as the GS2 family of mechanisms.
根据本规范，所有GSS-API机制都隐式注册以在SASL中使用。本文件中定义的SASL机制称为GS2机制系列。
The GS1 bridge failed to gain wide deployment for any GSS-API mechanism other than "The Kerberos Version 5 GSS-API Mechanism" [RFC1964] [RFC4121], and has a number of problems that led us to desire a new bridge. Specifically, a) GS1 was not round-trip optimized and b) GS1 did not support channel binding [RFC5056]. These problems and the opportunity to create the next SASL password-based mechanism, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms" [RFC5802], as a GSS-API mechanism used by SASL applications via GS2, provide the motivation for GS2.
除了“Kerberos版本5 GSS-API机制”[RFC1964][RFC4121]之外，GS1网桥未能获得任何GSS-API机制的广泛部署，并且存在许多问题，导致我们需要一个新的网桥。具体而言，a）GS1未进行往返优化，b）GS1不支持通道绑定[RFC5056]。这些问题以及创建下一个基于SASL密码的机制的机会，“SALT质询响应认证机制（SCRAM）SASL和GSS-API机制”[RFC5802]，作为SASL应用程序通过GS2使用的GSS-API机制，为GS2提供了动力。
In particular, the current consensus of the SASL community appears to be that SASL "security layers" (i.e., confidentiality and integrity protection of application data after authentication) are too complex and redundant because SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel. Use of SASL security layers is best replaced with channel binding to a TLS channel.
特别是，SASL社区目前的共识似乎是，SASL“安全层”（即认证后应用程序数据的机密性和完整性保护）过于复杂和冗余，因为SASL应用程序往往可以选择在传输层安全（TLS）[RFC5246]通道上运行。SASL安全层的使用最好替换为与TLS通道的通道绑定。
GS2 is designed to be as simple as possible. It adds to GSS-API security context token exchanges only the bare minimum to support SASL semantics and negotiation of use of channel binding. Specifically, GS2 adds a small header (a few bytes plus the length of the client-requested SASL authorization identity) to the initial GSS-API context token and to the application channel binding data. GS2 uses SASL mechanism negotiation to implement channel binding negotiation. Security-relevant GS2 plaintext is protected via the use of GSS-API channel binding. Additionally, to simplify the
GS2设计得尽可能简单。它只向GSS-API安全上下文令牌交换添加了支持SASL语义和通道绑定使用协商的最小值。具体地说，GS2向初始GSS-API上下文令牌和应用程序通道绑定数据添加了一个小标头（几个字节加上客户端请求的SASL授权标识的长度）。GS2使用SASL协商机制来实现通道绑定协商。通过使用GSS-API通道绑定保护与安全相关的GS2明文。此外，为了简化
implementation of GS2 mechanisms for implementors who will not implement a GSS-API framework, we compress the initial security context token header required by [RFC2743], Section 3.1.
GS2机制的实现对于不实现GSS-API框架的实现者，我们压缩[RFC2743]第3.1节要求的初始安全上下文令牌头。
GS2 does not protect any plaintext exchanged outside GS2, such as SASL mechanism negotiation plaintext, or application messages following authentication. But using channel binding to a secure channel over which all SASL and application plaintext is sent will cause all that plaintext to be authenticated.
GS2不保护在GS2之外交换的任何明文，例如SASL机制协商明文或认证后的应用程序消息。但是，将通道绑定到发送所有SASL和应用程序明文的安全通道将导致对所有明文进行身份验证。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The document uses many terms and function names defined in [RFC2743], as updated by [RFC5554].
该文档使用了[RFC2743]中定义的许多术语和函数名，并由[RFC5554]更新。
There are two SASL mechanism names for any GSS-API mechanism used through this facility. One denotes that the server supports channel binding. The other denotes that it does not.
通过此工具使用的任何GSS-API机制都有两个SASL机制名称。一个表示服务器支持通道绑定。另一个表示它没有。
The SASL mechanism name for a GSS-API mechanism is that which is provided by that mechanism when it was specified, if one was specified. This name denotes that the server does not support channel binding. Add the suffix "-PLUS" and the resulting name denotes that the server does support channel binding. SASL implementations can use the GSS_Inquire_SASLname_for_mech call (see below) to query for the SASL mechanism name of a GSS-API mechanism.
GSS-API机制的SASL机制名称是该机制在指定时提供的名称（如果已指定）。此名称表示服务器不支持通道绑定。添加后缀“-PLUS”，结果名称表示服务器不支持通道绑定。SASL实现可以使用GSS_Inquire_SASLname_for_mech调用（见下文）来查询GSS-API机制的SASL机制名称。
If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 implementation needs some other mechanism to map mechanism Object Identifiers (OIDs) to SASL names internally. In this case, the implementation can only support the mechanisms for which it knows the SASL name. If GSS_Inquire_SASLname_for_mech() fails and the GS2 implementation cannot map the OID to a SASL mechanism name via some other means, then the GS2 implementation MUST NOT use the given GSS-API mechanism.
如果未使用GSS_Inquire_SASLname_for_mech接口，则GS2实现需要一些其他机制在内部将机制对象标识符（OID）映射到SASL名称。在这种情况下，实现只能支持它知道SASL名称的机制。如果GSS_Inquire_SASLname_for_mech（）失败，并且GS2实现无法通过其他方式将OID映射到SASL机制名称，则GS2实现不得使用给定的GSS-API机制。
For GSS-API mechanisms whose SASL names are not defined together with the GSS-API mechanism or in this document, the SASL mechanism name is concatenation of the string "GS2-" and the Base32 encoding [RFC4648] (with an uppercase alphabet) of the first 55 bits of the binary SHA-1
对于其SASL名称未与GSS-API机制一起定义的GSS-API机制或本文档中的GSS-API机制，SASL机制名称是字符串“GS2-”和二进制SHA-1前55位的Base32编码[RFC4648]（大写字母）的串联
hash [FIPS.180-1.1995] string computed over the ASN.1 DER encoding [CCITT.X690.2002], including the tag and length octets, of the GSS-API mechanism's Object Identifier. The Base32 rules on padding characters and characters outside of the Base32 alphabet are not relevant to this use of Base32. If any padding or non-alphabet characters are encountered, the name is not a GS2 family mechanism name. This name denotes that the server does not support channel binding. Add the suffix "-PLUS" and the resulting name denotes that the server does support channel binding.
通过ASN.1 DER编码[CCITT.X690.2002]计算的哈希[FIPS.180-1.1995]字符串，包括GSS-API机制对象标识符的标记和长度八位字节。有关填充字符和Base32字母表之外的字符的Base32规则与Base32的使用无关。如果遇到任何填充字符或非字母字符，则该名称不是GS2系列机构名称。此名称表示服务器不支持通道绑定。添加后缀“-PLUS”，结果名称表示服务器不支持通道绑定。
A GS2 mechanism that has a non-OID-derived SASL mechanism name is said to have a "user-friendly SASL mechanism name".
具有非OID派生的SASL机制名称的GS2机制称为具有“用户友好的SASL机制名称”。
The hash-derived GS2 SASL mechanism name may be computed manually. This is useful when the set of supported GSS-API mechanisms is known in advance. This eliminates the need to implement Base32, SHA-1, and DER in the SASL mechanism. The computed mechanism name can be used directly in the implementation, and the implementation need not be concerned if the mechanism is part of a mechanism family.
可以手动计算哈希派生的GS2 SASL机制名称。当预先知道支持的GSS-API机制集时，这非常有用。这样就不需要在SASL机制中实现Base32、SHA-1和DER。计算出的机制名称可以直接在实现中使用，如果该机制是机制族的一部分，则无需考虑实现。
The OID for the Simple Public-Key GSS-API Mechanism (SPKM-1) [RFC2025] is 1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID, including the tag and length, is (in hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad. Convert the first 7 octets to binary, drop the last bit, and re-group them in groups of 5, and convert them back to decimal, which results in these computations:
简单公钥GSS-API机制（SPKM-1）[RFC2025]的OID为1.3.6.1.5.5.1.1。OID的ASN.1 DER编码（包括标签和长度）为（十六进制）06 07 2b 06 01 05 01。ASN.1 DER编码的SHA-1散列为（十六进制）1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad。将前7个八位组转换为二进制，删除最后一位，并将其重新分组为5组，并将其转换回十进制，从而导致这些计算：
hex: 1c f8 f4 2b 5a 9f 80
六角：1c f8 f4 2b 5a 9f 80
binary: 00011100 11111000 11110100 00101011 01011010 10011111 1000000
二进制：0001111100111110011110100101011 01011010011111 1000000
binary in groups of 5: 00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000
以5为一组的二进制文件：00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000
decimal of each group: 3 19 28 15 8 10 26 26 19 30 0
每组小数点：3 19 28 15 8 10 26 19 30 0
base32 encoding: D T 4 P I K 2 2 T 6 A
base32编码：dt4pik2t6a
The last step translates each decimal value using table 3 in Base32 [RFC4648]. Thus, the SASL mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-DT4PIK22T6A".
最后一步使用Base32[RFC4648]中的表3转换每个十进制值。因此，SPKM-1 GSSAPI机构的SASL机构名称为“GS2-DT4PIK22T6A”。
The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60. Convert the 7 octets to binary, drop the last bit, and re-group them in groups of 5, and convert them back to decimal, which results in these computations:
Kerberos V5 GSS-API机制[RFC1964]的OID为1.2.840.113554.1.2.2，其DER编码为（十六进制）06 09 2A 86 48 86 F7 12 01 02。SHA-1散列是82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60。将7个八位字节转换为二进制，删除最后一位，并将其重新分组为5组，然后将其转换回十进制，这将导致以下计算：
hex: 82 d2 73 25 76 6b d6
十六进制：82 d2 73 25 76 6b d6
binary: 10000010 11010010 01110011 00100101 01110110 01101011 1101011
二进制代码：10000010 11010010 011110011 00100101 011101110 0110110111011
binary in groups of 5: 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011
以5为一组的二进制文件：10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011
decimal of each group: 16 11 9 7 6 9 11 22 13 15 11
每组小数点：161197769112131511
base32 encoding: Q L J H G J L W N P L
base32编码：Q L J H G J L W N P L
The last step translates each decimal value using table 3 in Base32 [RFC4648]. Thus, the SASL mechanism name for the Kerberos V5 GSS-API mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next section assigns the Kerberos V5 mechanism a non-hash-derived mechanism name.
最后一步使用Base32[RFC4648]中的表3转换每个十进制值。因此，Kerberos V5 GSS-API机制的SASL机制名称为“GS2-QLJHGJLWNPL”，并且（因为此机制支持通道绑定）“GS2-QLJHGJLWNPL-PLUS”。相反，下一节将为Kerberos V5机制分配一个非哈希派生的机制名称。
Some older GSS-API mechanisms were not specified with a SASL GS2 mechanism name. Using a shorter name can be useful, nonetheless. We specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5 mechanism, to be used as if the original specification documented it, see Section 15.
某些较旧的GSS-API机制未使用SASL GS2机制名称指定。尽管如此，使用较短的名称还是很有用的。我们为kerberosv5机制指定名称“GS2-KRB5”和“GS2-KRB5-PLUS”，就像原始规范记录了它一样使用，请参见第15节。
During the SASL authentication exchange for GS2, a number of messages following the following format are sent between the client and server. On success, this number is the same as the number of context tokens that the GSS-API mechanism would normally require in order to establish a security context. On failures, the exchange can be terminated early by any party.
在GS2的SASL身份验证交换过程中，在客户端和服务器之间发送以下格式的大量消息。成功时，该数量与GSS-API机制通常需要的上下文令牌数量相同，以便建立安全上下文。如果失败，任何一方都可以提前终止交换。
When using a GS2 mechanism the SASL client is always a GSS-API initiator and the SASL server is always a GSS-API acceptor. The client calls GSS_Init_sec_context and the server calls GSS_Accept_sec_context.
使用GS2机制时，SASL客户端始终是GSS-API启动器，SASL服务器始终是GSS-API接收器。客户端调用GSS_Init_sec_context，服务器调用GSS_Accept_sec_context。
All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS-API mechanism, except for the initial security context token.
除了初始安全上下文令牌外，交换的所有SASL身份验证消息与GSS-API机制的安全上下文令牌完全相同。
The client and server MAY send GSS-API error tokens (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context() when the major status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED). As this indicates an error condition, after sending the token, the sending side should fail the authentication.
客户端和服务器可能发送GSS-API错误令牌（当主要状态代码不是GSS_S_完成或GSS_继续时，由GSS_Init_sec_context（）或GSS_Accept_sec_context（）输出的令牌）。由于这表明存在错误情况，因此在发送令牌后，发送端应使身份验证失败。
The initial security context token is modified as follows:
初始安全上下文令牌修改如下：
o The initial context token header (see Section 3.1 of [RFC2743]) MUST be removed if present. If the header is not present, the client MUST send a "gs2-nonstd-flag" flag (see below). On the server side, this header MUST be recomputed and restored prior to passing the token to GSS_Accept_sec_context, except when the "gs2- nonstd-flag" is sent.
o 如果存在初始上下文令牌头（请参见[RFC2743]第3.1节），则必须将其删除。如果报头不存在，客户端必须发送“gs2 NONSD flag”标志（见下文）。在服务器端，在将令牌传递给GSS_Accept_sec_上下文之前，必须重新计算并还原此头，发送“gs2-NONSD标志”时除外。
o A GS2 header MUST be prefixed to the resulting initial context token. This header has the form "gs2-header" given below in ABNF [RFC5234].
o GS2头必须作为结果初始上下文标记的前缀。该标题的格式为ABNF[RFC5234]中给出的“gs2标题”。
The figure below describes the permissible attributes, their use, and the format of their values. All attribute names are single US-ASCII letters and are case sensitive.
下图描述了允许的属性、它们的使用及其值的格式。所有属性名称均为单个US-ASCII字母，区分大小写。
UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
;; As UTF8-1 in RFC 3629 except
;; NUL, "=", and ",".
UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <as defined in RFC 3629 (STD 63)>
UTF8-4 = <as defined in RFC 3629 (STD 63)>
UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
;; As UTF8-1 in RFC 3629 except
;; NUL, "=", and ",".
UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <as defined in RFC 3629 (STD 63)>
UTF8-4 = <as defined in RFC 3629 (STD 63)>
UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4
saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
gs2-authzid = "a=" saslname
;; GS2 has to transport an authzid since
;; the GSS-API has no equivalent
gs2-nonstd-flag = "F"
;; "F" means the mechanism is not a
;; standard GSS-API mechanism in that the
;; RFC 2743, Section 3.1 header was missing
cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056, Section 7.
gs2-cb-flag = ("p=" cb-name) / "n" / "y"
;; GS2 channel binding (CB) flag
;; "p" -> client supports and used CB
;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server
;; does not
gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
;; The GS2 header is gs2-header.
saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
gs2-authzid = "a=" saslname
;; GS2 has to transport an authzid since
;; the GSS-API has no equivalent
gs2-nonstd-flag = "F"
;; "F" means the mechanism is not a
;; standard GSS-API mechanism in that the
;; RFC 2743, Section 3.1 header was missing
cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056, Section 7.
gs2-cb-flag = ("p=" cb-name) / "n" / "y"
;; GS2 channel binding (CB) flag
;; "p" -> client supports and used CB
;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server
;; does not
gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
;; The GS2 header is gs2-header.
When the "gs2-nonstd-flag" flag is present, the client did not find/ remove a token header ([RFC2743], Section 3.1) from the initial token returned by GSS_Init_sec_context. This signals to the server that it MUST NOT re-add the data that is normally removed by the client.
当出现“gs2 NONSD flag”标志时，客户端没有从GSS_Init_sec_上下文返回的初始令牌中找到/删除令牌头（[RFC2743]，第3.1节）。这向服务器发出信号，表示它不能重新添加通常由客户端删除的数据。
The "gs2-cb-flag" signals the channel binding mode. One of "p", "n", or "y" is used. A "p" means the client supports and used a channel binding, and the name of the channel binding type is indicated. An "n" means that the client does not support channel binding. A "y" means the client supports channel binding, but believes the server does not support it, so it did not use a channel binding. See the next section for more details.
“gs2 cb标志”表示通道绑定模式。使用“p”、“n”或“y”中的一个。“p”表示客户端支持并使用通道绑定，并指示通道绑定类型的名称。“n”表示客户端不支持通道绑定。“y”表示客户端支持通道绑定，但认为服务器不支持，因此未使用通道绑定。有关更多详细信息，请参见下一节。
The "gs2-authzid" holds the SASL authorization identity. It is encoded using UTF-8 [RFC3629] with three exceptions:
“gs2 authzid”持有SASL授权标识。它使用UTF-8[RFC3629]编码，但有三个例外：
o The NUL character is forbidden as required by section 3.4.1 of [RFC4422].
o 根据[RFC4422]第3.4.1节的要求，禁止使用NUL字符。
o The server MUST replace any "," (comma) in the string with "=2C".
o 服务器必须将字符串中的任何“，”（逗号）替换为“=2C”。
o The server MUST replace any "=" (equals) in the string with "=3D".
o 服务器必须将字符串中的任何“=”（等于）替换为“=3D”。
Upon receipt of this value, the server verifies its correctness according to the used SASL protocol profile. Failed verification results in a failed authentication exchange.
收到此值后，服务器将根据使用的SASL协议配置文件验证其正确性。验证失败导致身份验证交换失败。
GS2 supports channel binding to external secure channels, such as TLS. Clients and servers may or may not support channel binding; therefore, the use of channel binding is negotiable. However, GS2 does not provide security layers; therefore, it is imperative that GS2 provide integrity protection for the negotiation of channel binding.
GS2支持与外部安全通道（如TLS）的通道绑定。客户端和服务器可能支持也可能不支持通道绑定；因此，使用通道绑定是可以协商的。但是，GS2不提供安全层；因此，GS2必须为通道绑定的协商提供完整性保护。
Use of channel binding is negotiated as follows:
通道绑定的使用协商如下：
o Servers that support the use of channel binding SHOULD advertise both the non-PLUS and PLUS-variant of each GS2 mechanism name. If the server cannot support channel binding, it SHOULD advertise only the non-PLUS-variant. If the server would never succeed in the authentication of the non-PLUS-variant due to policy reasons, it MUST advertise only the PLUS-variant.
o 支持使用通道绑定的服务器应该公布每个GS2机制名称的非加号和加号变体。如果服务器无法支持通道绑定，则应仅公布非PLUS变量。如果由于策略原因，服务器无法成功验证非加号变量，则必须仅公布加号变量。
o If the client supports channel binding and the server does not appear to (i.e., the client did not see the -PLUS name advertised by the server), then the client MUST NOT use an "n" gs2-cb-flag.
o 如果客户机支持通道绑定，而服务器似乎不支持（即，客户机没有看到服务器公布的-PLUS名称），则客户机不得使用“n”gs2 cb标志。
o Clients that support mechanism negotiation and channel binding MUST use a "p" gs2-cb-flag when the server offers the PLUS-variant of the desired GS2 mechanism.
o 当服务器提供所需gs2机制的加号变体时，支持机制协商和通道绑定的客户端必须使用“p”gs2 cb标志。
o If the client does not support channel binding, then it MUST use an "n" gs2-cb-flag. Conversely, if the client requires the use of channel binding then it MUST use a "p" gs2-cb-flag. Clients that do not support mechanism negotiation never use a "y" gs2-cb-flag, they use either "p" or "n" according to whether they require and support the use of channel binding or whether they do not, respectively.
o 如果客户端不支持通道绑定，则必须使用“n”gs2 cb标志。相反，如果客户机需要使用通道绑定，则必须使用“p”gs2 cb标志。不支持机制协商的客户端从不使用“y”gs2 cb标志，它们根据是否需要和支持使用通道绑定或是否不使用通道绑定，分别使用“p”或“n”。
o The client generates the chan_bindings input parameter for GSS_Init_sec_context as described below.
o 客户端为GSS_Init_sec_上下文生成chan_bindings输入参数，如下所述。
o Upon receipt of the initial authentication message, the server checks the gs2-cb-flag in the GS2 header and constructs a chan_bindings parameter for GSS_Accept_sec_context as described below. If the client channel binding flag was "y" and the server did advertise support for channel bindings (by advertising the
o 收到初始身份验证消息后，服务器检查gs2标头中的gs2 cb标志，并为GSS_Accept_sec_上下文构造一个chan_bindings参数，如下所述。如果客户端通道绑定标志为“y”，并且服务器确实公布了对通道绑定的支持（通过公布
PLUS-variant of the mechanism chosen by the client), then the server MUST fail authentication. If the client channel binding flag was "p" and the server does not support the indicated channel binding type, then the server MUST fail authentication.
加上客户端选择的机制的变体），则服务器的身份验证必须失败。如果客户端通道绑定标志为“p”，并且服务器不支持指定的通道绑定类型，则服务器的身份验证必须失败。
o If the client used an "n" gs2-cb-flag and the server requires the use of channel binding, then the server MUST fail authentication.
o 如果客户端使用了“n”gs2 cb标志，而服务器要求使用通道绑定，则服务器的身份验证必须失败。
FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION
---- ----------------- ----------------- -----------
FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION
---- ----------------- ----------------- -----------
n no support N/A If server disallows non-channel-bound authentication, then fail
n不支持n/A如果服务器不允许非通道绑定身份验证，则失败
y Yes, not required No Authentication may succeed; CB not used
y是，不需要，验证不可能成功；CB未使用
y Yes, not required Yes Authentication must fail
y是，不需要是身份验证必须失败
p Yes Yes Authentication may succeed, with CB used
p Yes认证可能成功，使用CB
p Yes No Authentication will fail
p是否身份验证将失败
N/A Yes, required No Client does not even try
不适用是，必需否客户端甚至不尝试
For more discussion of channel bindings, and the syntax of the channel binding data for various security protocols, see [RFC5056].
有关通道绑定以及各种安全协议的通道绑定数据语法的更多讨论，请参阅[RFC5056]。
The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS structure [RFC5554].
对GSS_Init_sec_context和GSS_Accept_sec_context的调用采用chan_bindings参数。该值是GSS-CHANNEL-BINDINGS结构[RFC5554]。
The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-address and acceptor-address fields MUST be the empty string.
GSS-CHANNEL-BINDINGS结构的启动器地址类型和接受方地址类型字段必须设置为0。发起方地址和接受方地址字段必须为空字符串。
The application-data field MUST be set to the gs2-header, excluding the initial [gs2-nonstd-flag ","] part, concatenated with, when a gs2-cb-flag of "p" is used, the application's channel binding data.
应用程序数据字段必须设置为gs2标头，不包括初始[gs2 NONSD flag”，“]部分，当使用gs2 cb标志“p”时，与应用程序的通道绑定数据连接。
A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows.
对于所有不提供自己的通道绑定类型协议的SASL应用程序协议，默认的通道绑定类型协议过程如下所示。
'tls-unique' is the default channel binding type for any application that doesn't specify one.
“tls unique”是任何未指定通道绑定类型的应用程序的默认通道绑定类型。
Servers MUST implement the "tls-unique" [RFC5929] channel binding type, if they implement any channel binding. Clients SHOULD implement the "tls-unique" channel binding type, if they implement any channel binding. Clients and servers SHOULD choose the highest-layer/innermost end-to-end TLS channel as the channel to which to bind.
如果服务器实现任何通道绑定，则必须实现“tls唯一”[RFC5929]通道绑定类型。如果客户机实现任何通道绑定，则应实现“tls唯一”通道绑定类型。客户端和服务器应选择最高层/最内层的端到端TLS通道作为要绑定的通道。
Servers MUST choose the channel binding type indicated by the client, or fail authentication if they don't support it.
服务器必须选择客户端指示的通道绑定类型，如果不支持，则验证失败。
Example #1: a one round-trip GSS-API context token exchange, no channel binding, optional authzid given.
示例#1：一个单程GSS-API上下文令牌交换，没有通道绑定，提供了可选的authzid。
C: Request authentication exchange
S: Empty Challenge
C: n,a=someuser,<initial context token with standard
header removed>
S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
C: Request authentication exchange
S: Empty Challenge
C: n,a=someuser,<initial context token with standard
header removed>
S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
Example #2: a one and one half round-trip GSS-API context token exchange, no channel binding.
示例#2：一个1.5往返GSS-API上下文令牌交换，无通道绑定。
C: Request authentication exchange
S: Empty Challenge
C: n,,<initial context token with standard
header removed>
S: Send reply context token as is
C: Send reply context token as is
S: Outcome of authentication exchange
C: Request authentication exchange
S: Empty Challenge
C: n,,<initial context token with standard
header removed>
S: Send reply context token as is
C: Send reply context token as is
S: Outcome of authentication exchange
Example #3: a two round-trip GSS-API context token exchange, no channel binding, no standard token header.
示例#3：两个往返GSS-API上下文令牌交换，无通道绑定，无标准令牌头。
C: Request authentication exchange
S: Empty Challenge
C: F,n,,<initial context token without
standard header>
S: Send reply context token as is
C: Send reply context token as is
S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
C: Request authentication exchange
S: Empty Challenge
C: F,n,,<initial context token without
standard header>
S: Send reply context token as is
C: Send reply context token as is
S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
Example #4: using channel binding, optional authzid given.
示例4：使用通道绑定，给出了可选的authzid。
C: Request authentication exchange
S: Empty Challenge
C: p=tls-unique,a=someuser,<initial context token with standard
header removed>
S: Send reply context token as is
...
C: Request authentication exchange
S: Empty Challenge
C: p=tls-unique,a=someuser,<initial context token with standard
header removed>
S: Send reply context token as is
...
Example #5: using channel binding.
示例5：使用通道绑定。
C: Request authentication exchange
S: Empty Challenge
C: p=tls-unique,,<initial context token with standard
header removed>
S: Send reply context token as is
...
C: Request authentication exchange
S: Empty Challenge
C: p=tls-unique,,<initial context token with standard
header removed>
S: Send reply context token as is
...
Example #6: using non-standard channel binding (requires out-of-band negotiation).
示例#6：使用非标准通道绑定（需要带外协商）。
C: Request authentication exchange
S: Empty Challenge
C: p=tls-server-end-point,,<initial context token with standard
header removed>
S: Send reply context token as is
...
C: Request authentication exchange
S: Empty Challenge
C: p=tls-server-end-point,,<initial context token with standard
header removed>
S: Send reply context token as is
...
Example #7: client supports channel bindings but server does not, optional authzid given.
示例#7：客户端支持通道绑定，但服务器不支持，提供了可选的authzid。
C: Request authentication exchange
S: Empty Challenge
C: y,a=someuser,<initial
context token with standard header removed>
S: Send reply context token as is
...
C: Request authentication exchange
S: Empty Challenge
C: y,a=someuser,<initial
context token with standard header removed>
S: Send reply context token as is
...
GSS-API authentication is always initiated by the client. The SASL framework allows either the client or the server to initiate authentication. In GS2, the server will send an initial empty challenge (zero-byte string) if it has not yet received a token from the client. See Section 3 of [RFC4422].
GSS-API身份验证始终由客户端启动。SASL框架允许客户端或服务器启动身份验证。在GS2中，如果服务器尚未从客户端接收到令牌，它将发送一个初始空质询（零字节字符串）。参见[RFC4422]第3节。
Authentication MUST NOT succeed if any one of the following conditions are true:
如果满足以下任一条件，则身份验证不得成功：
o If GSS_Init/Accept_sec_context returns anything other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
o 如果GSS_Init/Accept_sec_上下文返回除GSS_S_CONTINUE_NEEDED或GSS_COMPLETE之外的任何内容。
o If the client's initial GS2 header does not match the ABNF.
o 如果客户机的初始GS2标头与ABNF不匹配。
o In particular, if the initial character of the client message is anything except "F", "p", "n", or "y".
o 特别地，如果客户端消息的初始字符是除“F”、“p”、“n”或“y”之外的任何字符。
o If the client's GS2 channel binding flag was "y" and the server supports channel bindings.
o 如果客户端的GS2通道绑定标志为“y”，并且服务器支持通道绑定。
o If the client's GS2 channel binding flag was "p" and the server does not support the indicated channel binding.
o 如果客户端的GS2通道绑定标志为“p”，并且服务器不支持指定的通道绑定。
o If the client requires use of channel binding and the server did not advertise support for channel binding.
o 如果客户端需要使用通道绑定，而服务器没有公布对通道绑定的支持。
o If authorization of client principal (i.e., src_name in GSS_Accept_sec_context) to requested authzid failed.
o 如果客户端主体（即GSS_Accept_sec_上下文中的src_name）对请求的authzid的授权失败。
o If the client is not authorized to the requested authzid or an authzid could not be derived from the client's initiator principal name.
o 如果客户端未被授权使用请求的authzid，或者无法从客户端的启动器主体名称派生authzid。
GS2 does not use any GSS-API per-message tokens. Therefore, the per-message token ret_flags from GSS_Init_sec_context() and GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT set the per-message req_flags.
GS2不使用任何GSS-API每消息令牌。因此，来自GSS_Init_sec_context（）和GSS_Accept_sec_context（）的每消息令牌ret_标志是不相关的；实现不应设置每消息请求标志。
The mutual_req_flag MUST be set. Clients MUST check that the corresponding ret_flag is set when the context is fully established, else authentication MUST fail.
必须设置相互请求标志。客户端必须检查上下文完全建立时是否设置了相应的ret_标志，否则身份验证必须失败。
Use or non-use of deleg_req_flag and anon_req_flag is an implementation-specific detail. SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them. SASL and GS2 implementors are encouraged to provide programming interfaces that provide a good mapping of GSS-API naming options.
deleg_req_标志和anon_req_标志的使用或不使用是具体实现的细节。鼓励SASL和GS2实现者提供编程接口，通过这些接口，客户端可以选择委派凭据，服务器可以接收凭据。鼓励SASL和GS2实现者提供编程接口，以提供GSS-API命名选项的良好映射。
There is no requirement that any particular GSS-API name-types be used. However, typically, SASL servers will have host-based acceptor principal names (see [RFC2743], Section 4.1) and clients will typically have username initiator principal names (see [RFC2743], Section 4.2). When a host-based acceptor principal name is used ("service@hostname"), "service" is the service name specified in the protocol's profile and "hostname" is the fully qualified host name of the server.
不要求使用任何特定的GSS-API名称类型。但是，SASL服务器通常具有基于主机的接受器主体名称（请参见[RFC2743]，第4.1节），而客户端通常具有用户名启动器主体名称（请参见[RFC2743]，第4.2节）。使用基于主机的接受器主体名称时（“service@hostname“”，“服务”是协议配置文件中指定的服务名称，“主机名”是服务器的完全限定主机名。
We specify a new GSS-API utility function to allow SASL implementations to more efficiently identify the GSS-API mechanism to which a particular SASL mechanism name refers.
我们指定了一个新的GSS-API实用程序函数，以允许SASL实现更有效地识别特定SASL机制名称所引用的GSS-API机制。
Inputs:
投入：
o desired_mech OBJECT IDENTIFIER
o 所需的机械对象标识符
Outputs:
产出：
o major_status INTEGER
o 主状态整数
o minor_status INTEGER
o 次要状态整数
o sasl_mech_name UTF-8 STRING -- SASL name for this mechanism; caller must release with GSS_Release_buffer()
o sasl_机械名称UTF-8字符串——此机制的sasl名称；调用方必须使用GSS_release_buffer（）释放
o mech_name UTF-8 STRING -- name of this mechanism, possibly localized; caller must release with GSS_Release_buffer()
o mech_name UTF-8字符串——该机制的名称，可能已本地化；调用方必须使用GSS_release_buffer（）释放
o mech_description UTF-8 STRING -- possibly localized description of this mechanism; caller must release with GSS_Release_buffer()
o 机械描述UTF-8字符串——可能是该机构的本地化描述；调用方必须使用GSS_release_buffer（）释放
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates successful completion, and that output parameters holds correct information.
o GSS_S_COMPLETE表示成功完成，并且输出参数包含正确的信息。
o GSS_S_BAD_MECH indicates that a desired_mech was unsupported by the GSS-API implementation.
o GSS_S_BAD_MECH表示GSS-API实现不支持所需的_MECH。
o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示操作因GSS-API级别未指定的原因而失败。
The GSS_Inquire_SASLname_for_mech call is used to get the SASL mechanism name for a GSS-API mechanism. It also returns a name and description of the mechanism in user-friendly form.
GSS_Inquire_SASLname_for_mech调用用于获取GSS-API机制的SASL机制名称。它还以用户友好的形式返回机制的名称和描述。
The output variable sasl_mech_name will hold the IANA registered mechanism name for the GSS-API mechanism, or if none is registered, a mechanism name computed from the OID as described in Section 3.1 of this document.
输出变量sasl_mech_name将保存GSS-API机制的IANA注册机制名称，如果未注册，则保存根据本文件第3.1节所述OID计算的机制名称。
The C binding for the GSS_Inquire_SASLname_for_mech call is as follows.
GSS_Inquire_SASLname_for_mech调用的C绑定如下所示。
As mentioned in [RFC2744], routines may return GSS_S_FAILURE, indicating an implementation-specific or mechanism-specific error condition, further details of which are reported via the minor_status parameter.
如[RFC2744]中所述，例程可能返回GSS_S_故障，指示特定于实现或特定于机制的错误条件，其进一步细节通过次要_状态参数报告。
OM_uint32 gss_inquire_saslname_for_mech( OM_uint32 *minor_status, const gss_OID desired_mech, gss_buffer_t sasl_mech_name, gss_buffer_t mech_name, gss_buffer_t mech_description );
OM_uint32 gss_查询GSLname_机械（OM_uint32*次要状态、const gss_OID所需机械、gss_buffer_t sasl_机械名称、gss_buffer_机械名称、gss_buffer_机械描述）；
Purpose:
目的：
Output the SASL mechanism name of a GSS-API mechanism. It also returns a name and description of the mechanism in a user-friendly form.
输出GSS-API机制的SASL机制名称。它还以用户友好的形式返回机制的名称和描述。
Parameters:
参数：
minor_status Integer, modify Mechanism-specific status code.
次要_状态整数，修改机构特定状态代码。
desired_mech OID, read Identifies the GSS-API mechanism to query.
所需的\u mech OID，read标识要查询的GSS-API机制。
sasl_mech_name buffer, character-string, modify, optional Buffer to receive SASL mechanism name. The application must free storage associated with this name after use with a call to gss_release_buffer().
sasl_机械名称缓冲区、字符串、修改、可选缓冲区以接收sasl机械名称。在调用gss_release_buffer（）后，应用程序必须释放与此名称关联的存储。
mech_name buffer, character-string, modify, optional Buffer to receive human-readable mechanism name. The application must free storage associated with this name after use with a call to gss_release_buffer().
机械名称缓冲区、字符串、修改、可选缓冲区，用于接收人类可读的机械名称。在调用gss_release_buffer（）后，应用程序必须释放与此名称关联的存储。
mech_description buffer, character-string, modify, optional Buffer to receive description of mechanism. The application must free storage associated with this name after use with a call to gss_release_buffer().
机械描述缓冲区、字符串、修改、可选缓冲区，用于接收机构描述。在调用gss_release_buffer（）后，应用程序必须释放与此名称关联的存储。
Function value: GSS status code:
功能值：GSS状态代码：
GSS_S_COMPLETE Successful completion.
GSS__成功完成。
GSS_S_BAD_MECH The desired_mech OID is unsupported.
GSS_S_坏_机械不支持所需的机械ID。
To allow SASL clients to more efficiently identify to which GSS-API mechanism a particular SASL mechanism name refers, we specify a new GSS-API utility function for this purpose.
为了使SASL客户端能够更有效地识别特定SASL机制名称所指的GSS-API机制，我们为此指定了一个新的GSS-API实用程序函数。
Inputs:
投入：
o sasl_mech_name UTF-8 STRING -- SASL name of mechanism.
o sasl_机械名称UTF-8字符串——机构的sasl名称。
Outputs:
产出：
o major_status INTEGER
o 主状态整数
o minor_status INTEGER
o 次要状态整数
o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, and not "default" specifier. Caller should treat as read-only and should not attempt to release.
o mech_类型对象标识符——必须是显式机制，而不是“默认”说明符。调用方应视为只读，不应尝试释放。
Return major_status codes:
返回主要_状态代码：
o GSS_S_COMPLETE indicates successful completion, and that output parameters holds correct information.
o GSS_S_COMPLETE表示成功完成，并且输出参数包含正确的信息。
o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism had the indicated sasl_mech_name.
o GSS_S_BAD_MECH表示没有支持的GSS-API机制具有指示的sasl_MECH_名称。
o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.
o GSS_S_故障表示操作因GSS-API级别未指定的原因而失败。
The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API mechanism OID associated with a SASL mechanism name.
GSS_Inquire_mech_for_SASLname调用用于获取与SASL机制名称关联的GSS-API机制OID。
The C binding for the GSS_Inquire_mech_for_SASLname call is as follows.
GSS_Inquire_mech_for_SASLname调用的C绑定如下所示。
As mentioned in [RFC2744], routines may return GSS_S_FAILURE, indicating an implementation-specific or mechanism-specific error condition, further details of which are reported via the minor_status parameter.
如[RFC2744]中所述，例程可能返回GSS_S_故障，指示特定于实现或特定于机制的错误条件，其进一步细节通过次要_状态参数报告。
OM_uint32 gss_inquire_mech_for_saslname( OM_uint32 *minor_status, const gss_buffer_t sasl_mech_name, gss_OID *mech_type );
OM_uint32 gss_查询机械设备名称（OM_uint32*次要状态、const gss_buffer_t sasl_机械设备名称、gss_OID*机械设备类型）；
Purpose:
目的：
Output GSS-API mechanism OID of mechanism associated with given sasl_mech_name.
输出与给定sasl_mech_名称关联的机制的GSS-API机制OID。
Parameters:
参数：
minor_status Integer, modify Mechanism-specific status code.
次要_状态整数，修改机构特定状态代码。
sasl_mech_name buffer, character-string, read Buffer with SASL mechanism name.
sasl_机械名称缓冲区、字符串、具有sasl机械名称的读取缓冲区。
mech_type OID, modify, optional Actual mechanism used. The OID returned via this parameter will be a pointer to static storage that should be treated as read-only. In particular, the application should not attempt to free it. Specify NULL if not required.
机械类型OID，修改，可选实际使用的机构。通过此参数返回的OID将是指向应视为只读的静态存储的指针。特别是，应用程序不应尝试释放它。如果不需要，请指定NULL。
Function value: GSS status code:
功能值：GSS状态代码：
GSS_S_COMPLETE Successful completion.
GSS__成功完成。
GSS_S_BAD_MECH There is no GSS-API mechanism known as sasl_mech_name.
GSS_S_BAD_MECH没有被称为sasl_MECH_名称的GSS-API机制。
GS2 does not support SASL security layers. Applications that need integrity or confidentiality protection can use either channel binding to a secure external channel or another SASL mechanism that does provide security layers.
GS2不支持SASL安全层。需要完整性或机密性保护的应用程序可以使用到安全外部通道的通道绑定，也可以使用提供安全层的其他SASL机制。
The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL under the name GSSAPI, see [RFC4752]. The Kerberos V5 mechanism may also be used with the GS2 family. This causes an interoperability problem, which is discussed and resolved below.
Kerberos V5 GSS-API[RFC1964]机制目前在SASL中以GSSAPI的名义使用，请参见[RFC4752]。Kerberos V5机制也可用于GS2系列。这会导致互操作性问题，下面将讨论并解决该问题。
The SASL "GSSAPI" mechanism is not wire compatible with the Kerberos V GSS-API mechanism used as a SASL GS2 mechanism.
SASL“GSSAPI”机制与用作SASL GS2机制的Kerberos V GSS-API机制不兼容。
If a client (or server) only support Kerberos V5 under the "GSSAPI" name, and the server (or client) only support Kerberos V5 under the GS2 family, the mechanism negotiation will fail.
如果客户端（或服务器）仅支持“GSSAPI”名称下的Kerberos V5，而服务器（或客户端）仅支持GS2系列下的Kerberos V5，则机制协商将失败。
If the Kerberos V5 mechanism is supported under GS2 in a server, the server SHOULD also support Kerberos V5 through the "GSSAPI" mechanism, to avoid interoperability problems with older clients.
如果服务器中的GS2支持Kerberos V5机制，则服务器还应通过“GSSAPI”机制支持Kerberos V5，以避免与旧客户端的互操作性问题。
Reasons for violating this recommendation may include security considerations regarding the absent features in the GS2 mechanism. The SASL "GSSAPI" mechanism lacks support for channel bindings, which means that using an external secure channel may not be sufficient protection against active attackers (see [RFC5056] and [MITM]).
违反此建议的原因可能包括有关GS2机制中缺少功能的安全考虑。SASL“GSSAPI”机制缺乏对通道绑定的支持，这意味着使用外部安全通道可能不足以抵御主动攻击者（请参见[RFC5056]和[MITM]）。
If the application requires SASL security layers, then it MUST use the SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2- KRB5-PLUS".
如果应用程序需要SASL安全层，则必须使用SASL“GSSAPI”机制[RFC4752]，而不是“GS2-KRB5”或“GS2-KRB5-PLUS”。
If the application can use channel binding to an external channel, then it is RECOMMENDED that it select Kerberos V5 through the GS2 mechanism rather than the "GSSAPI" mechanism.
如果应用程序可以使用到外部通道的通道绑定，则建议它通过GS2机制而不是“GSSAPI”机制选择Kerberos V5。
A GSS-API mechanism that negotiates other mechanisms will interact badly with the SASL mechanism negotiation. There are two problems. The first is an interoperability problem and the second is a security concern. The problems are described and resolved below.
协商其他机制的GSS-API机制将与SASL协商机制产生严重的交互。有两个问题。第一个是互操作性问题，第二个是安全问题。下面描述并解决了这些问题。
If a client implements GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implements GSS-API mechanism X negotiated through a GSS-API mechanism Z, the authentication negotiation will fail.
如果客户端实现了GSS-API机制X（可能通过GSS-API机制Y协商），而服务器也实现了GSS-API机制X（通过GSS-API机制Z协商），则身份验证协商将失败。
If a client's policy is to first prefer GSSAPI mechanism X, then non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports mechanisms Y and Z but not X, then if the client attempts to negotiate mechanism X by using a GSS-API mechanism that negotiates other mechanisms (such as Simple and Protected GSS-API Negotiation (SPNEGO) [RFC4178]), it may end up using mechanism Z when it ideally should have used mechanism Y. For this reason, the use of GSS-API mechanisms that negotiate other mechanisms is disallowed under GS2.
如果客户机的策略是首先选择GSSAPI机制X，然后选择非GSSAPI机制Y，然后选择GSSAPI机制Z，如果服务器支持机制Y和Z但不支持X，那么如果客户机尝试使用协商其他机制的GSS-API机制协商机制X（例如简单和受保护的GSS-API协商（SPNEGO））[RFC4178]），它可能会在理想情况下使用机制Y时使用机制Z。因此，GS2不允许使用协商其他机制的GSS-API机制。
GSS-API mechanisms that negotiate other mechanisms MUST NOT be used with the GS2 SASL mechanism. Specifically, SPNEGO [RFC4178] MUST NOT be used as a GS2 mechanism. To make this easier for SASL implementations, we assign a symbolic SASL mechanism name to the SPNEGO GSS-API mechanism, "SPNEGO". SASL client implementations MUST NOT choose the SPNEGO mechanism under any circumstances.
协商其他机制的GSS-API机制不得与GS2 SASL机制一起使用。具体而言，SPNEGO[RFC4178]不得用作GS2机制。为了使SASL实现更容易，我们为SPNEGO GSS-API机制指定了一个符号SASL机制名“SPNEGO”。SASL客户端实现在任何情况下都不得选择SPNEGO机制。
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech [RFC5587] can be used to identify such mechanisms.
GSS_Inquire_attrs_for_MECH[RFC5587]的GSS_C_MA_MECH_NEGO属性可用于识别此类机构。
The IANA has registered a SASL mechanism family as per [RFC4422] using the following information.
IANA已根据[RFC4422]使用以下信息注册了SASL机制系列。
Subject: Registration of SASL mechanism family GS2-* SASL mechanism prefix: GS2- Security considerations: RFC 5801 Published specification: RFC 5801 Person & email address to contact for further information: Simon Josefsson <simon@josefsson.org> Intended usage: COMMON Owner/Change controller: iesg@ietf.org Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
主题：注册SASL机制系列GS2-*SASL机制前缀：GS2-安全注意事项：RFC 5801发布规范：RFC 5801联系人和电子邮件地址以获取更多信息：Simon Josefsson<simon@josefsson.org>预期用途：普通所有者/变更控制者：iesg@ietf.org注：与GSSAPI和GSS-SPNEGO机制。
The IANA is advised that SASL mechanism names starting with "GS2-" are reserved for SASL mechanisms that conform to this document. The IANA has placed a statement to that effect in the SASL Mechanisms registry.
IANA建议，以“GS2-”开头的SASL机制名称保留给符合本文件要求的SASL机制。IANA已经在SASL机制注册中心发布了一份声明。
The IANA is further advised that GS2 SASL mechanism names MUST NOT end in "-PLUS" except as a version of another mechanism name simply suffixed with "-PLUS".
IANA进一步建议，GS2 SASL机制名称不得以“-PLUS”结尾，除非是另一个机制名称的一个简单后缀“-PLUS”的版本。
The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121] [RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS".
通过GS2使用的Kerberos V5 GSS-API机制[RFC4121][RFC1964]的SASL名称应为“GS2-KRB5”和“GS2-KRB5-PLUS”。
The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be "SPNEGO" and "SPNEGO-PLUS". As described in Section 14, the SASL "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are provided as a convenience for SASL library implementors.
通过GS2使用的SPNEGO GSS-API机制的SASL名称应为“SPNEGO”和“SPNEGO-PLUS”。如第14节所述，不得使用SASL“SPNEGO”和“SPNEGO-PLUS”。提供这些名称是为了方便SASL库实现人员。
Security issues are also discussed throughout this memo.
本备忘录还讨论了安全问题。
The security provided by a GS2 mechanism depends on the security of the GSS-API mechanism. The GS2 mechanism family depends on channel binding support, so GSS-API mechanisms that do not support channel binding cannot be successfully used as SASL mechanisms via the GS2 bridge.
GS2机制提供的安全性取决于GSS-API机制的安全性。GS2机制系列依赖于通道绑定支持，因此不支持通道绑定的GSS-API机制无法通过GS2网桥成功用作SASL机制。
Because GS2 does not support security layers, it is strongly RECOMMENDED that channel binding to a secure external channel be used. Successful channel binding eliminates the possibility of man-in-the-middle (MITM) attacks, provided that the external channel and its channel binding data are secure and that the GSS-API mechanism used is secure. Authentication failure because of channel binding
由于GS2不支持安全层，因此强烈建议使用到安全外部通道的通道绑定。成功的通道绑定消除了中间人（MITM）攻击的可能性，前提是外部通道及其通道绑定数据是安全的，并且使用的GSS-API机制是安全的。由于通道绑定，身份验证失败
failure may indicate that an MITM attack was attempted, but note that a real MITM attacker would likely attempt to close the connection to the client or simulate network partition; thus, MITM attack detection is heuristic.
失败可能表示尝试了MITM攻击，但请注意，真正的MITM攻击者可能会试图关闭与客户端的连接或模拟网络分区；因此，MITM攻击检测是启发式的。
Use of channel binding will also protect the SASL mechanism negotiation -- if there is no MITM, then the external secure channel will have protected the SASL mechanism negotiation.
使用通道绑定还将保护SASL机制协商——如果没有MITM，则外部安全通道将保护SASL机制协商。
The channel binding data MAY be sent (by the actual GSS-API mechanism used) without confidentiality protection and knowledge of it is assumed to provide no advantage to an MITM (who can, in any case, compute the channel binding data independently). If the external channel does not provide confidentiality protection and the GSS-API mechanism does not provide confidentiality protection for the channel binding data, then passive attackers (eavesdroppers) can recover the channel binding data, see [RFC5056].
信道绑定数据可以（通过实际使用的GSS-API机制）在没有保密保护的情况下发送，并且假定知道该数据不会给MITM带来任何好处（在任何情况下，MITM都可以独立计算信道绑定数据）。如果外部通道不提供保密保护，且GSS-API机制不提供通道绑定数据的保密保护，则被动攻击者（窃听者）可以恢复通道绑定数据，请参见[RFC5056]。
When constructing the input_name_string for GSS_Import_name with the GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service, such as the Domain Name System [RFC1034] without DNS Security (DNSSEC) [RFC4033].
当使用GSS_C_NT_HOSTBASED_服务名称类型为GSS_Import_name构建输入_name_字符串时，客户端不应使用不安全或不受信任的目录服务规范化服务器的完全限定域名，例如没有DNS安全性（DNSSEC）[RFC4033]的域名系统[RFC1034]。
SHA-1 is used to derive SASL mechanism names, but no traditional cryptographic properties are required -- the required property is that the truncated output for distinct inputs are different for practical input values. GS2 does not use any other cryptographic algorithm. Therefore, GS2 is "algorithm agile", or, as agile as the GSS-API mechanisms that are available for use in SASL applications via GS2.
SHA-1用于派生SASL机制名称，但不需要传统的加密属性——所需的属性是不同输入的截断输出与实际输入值不同。GS2不使用任何其他加密算法。因此，GS2是“算法敏捷的”，或者与GSS-API机制一样敏捷，可通过GS2在SASL应用程序中使用。
GS2 does not protect against downgrade attacks of channel binding types. Negotiation of channel binding type was intentionally left out of scope for this document.
GS2不能防止通道绑定类型的降级攻击。通道绑定类型的协商被故意排除在本文件的范围之外。
The security considerations of SASL [RFC4422], the GSS-API [RFC2743], channel binding [RFC5056], any external channels (such as TLS, [RFC5246], channel binding types (see the IANA channel binding type registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism [RFC4121] [RFC1964]), also apply.
SASL[RFC4422]、GSS-API[RFC2743]、通道绑定[RFC5056]、任何外部通道（如TLS[RFC5246]、通道绑定类型（请参阅IANA通道绑定类型注册表）和GSS-API机制（如Kerberos V5机制[RFC4121][RFC1964]）的安全注意事项也适用。
The history of GS2 can be traced to the "GSSAPI" mechanism originally specified by RFC 2222. This document was derived from [SASL-GSSAPI], which was prepared by Alexey Melnikov with significant contributions from John G. Myers, although the majority of this document has been rewritten by the current authors.
GS2的历史可以追溯到RFC2222最初指定的“GSSAPI”机制。本文件来源于[SASL-GSSAPI]，该文件由Alexey Melnikov在John G.Myers的重要贡献下编写，尽管本文件大部分内容已由当前作者改写。
Contributions of many members of the SASL mailing list are gratefully acknowledged. In particular, ideas and feedback from Pasi Eronen, Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document and the protocol. Other suggestions to the documents were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert Sparks, and Glen Zorn.
感谢SASL邮件列表中许多成员的贡献。特别是，Pasi Eronen、Sam Hartman、Jeffrey Hutzelman、Alexey Melnikov和Tom Yu的想法和反馈改进了文件和协议。斯宾塞·道金斯（Spencer Dawkins）、拉尔夫·德罗姆斯（Ralph Droms）、阿德里安·法雷尔（Adrian Farrel）、罗伯特·斯帕克斯（Robert Sparks）和格伦·佐恩（Glen Zorn）对这些文件提出了其他建议。
[FIPS.180-1.1995] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[FIPS.180-1.1995]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-1，1995年4月<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.
[RFC5554]Williams，N.“用于通道绑定的通用安全服务应用程序接口（GSS-API）的澄清和扩展”，RFC 5554，2009年5月。
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.X690.2002]国际电话电报咨询委员会，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，CCITT建议X.690，2002年7月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929]Altman，J.，Williams，N.，和L.Zhu，“TLS的通道绑定”，RFC 59292010年7月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20252996年10月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744]Wray，J.，“通用安全服务API第2版：C-绑定”，RFC 2744，2000年1月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005.
[RFC4178]Zhu，L.，Leach，P.，Jaganathan，K.，和W.Ingersoll，“简单和受保护的通用安全服务应用程序接口（GSS-API）协商机制”，RFC 4178，2005年10月。
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[RFC4752]Melnikov，A.，“Kerberos V5（“GSSAPI”）简单身份验证和安全层（SASL）机制”，RFC 4752，2006年11月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism Inquiry APIs", RFC 5587, July 2009.
[RFC5587]Williams，N.，“扩展通用安全服务机制查询API”，RFC5587，2009年7月。
[RFC5802] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC5802]Menon Sen，A.，Melnikov，A.，Newman，C.，和N.Williams，“盐渍挑战响应认证机制（SCRAM）SASL和GSS-API机制”，RFC 5802，2010年7月。
[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunnelled Authentication", in 11th Security Protocols Workshop, 2002.
[MITM]Asokan，N.，Niemi，V.，和K.Nyberg，“隧道认证中的中间人”，第11届安全协议研讨会，2002年。
[SASL-GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism", Work in Progress, March 2005.
[SASL-GSSAPI]Melnikov，A.，“Kerberos V5（“GSSAPI”）SASL机制”，正在进行的工作，2005年3月。
Authors' Addresses
作者地址
Simon Josefsson SJD AB Hagagatan 24 Stockholm 113 47 SE
西蒙·约瑟夫松SJD AB哈加坦24斯德哥尔摩113 47东南
EMail: simon@josefsson.org
URI: http://josefsson.org/
EMail: simon@josefsson.org
URI: http://josefsson.org/
Nicolas Williams Oracle 5300 Riata Trace Ct Austin, TX 78727 USA
Nicolas Williams Oracle 5300 Riata Trace Ct德克萨斯州奥斯汀78727美国
EMail: Nicolas.Williams@oracle.com
EMail: Nicolas.Williams@oracle.com