Network Working Group L. Zhu
Request for Comments: 4121 K. Jaganathan
Updates: 1964 Microsoft
Category: Standards Track S. Hartman
MIT
July 2005
Network Working Group L. Zhu
Request for Comments: 4121 K. Jaganathan
Updates: 1964 Microsoft
Category: Standards Track S. Hartman
MIT
July 2005
The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本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) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism.
本文档定义了当使用Kerberos版本5机制时，实现通用安全服务应用程序接口（GSS-API）的对等方将采用的协议、过程和约定。
RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles.
RFC1964进行了更新，并提出了增量更改，以响应最近的发展，如Kerberos密码系统框架的引入。这些更改通过定义新的每消息令牌及其基于密码系统配置文件的加密和校验和算法，支持包含新的密码系统。
Table of Contents
目录
1. Introduction ....................................................2
2. Key Derivation for Per-Message Tokens ...........................4
3. Quality of Protection ...........................................4
4. Definitions and Token Formats ...................................5
4.1. Context Establishment Tokens ...............................5
4.1.1. Authenticator Checksum ..............................6
4.2. Per-Message Tokens .........................................9
4.2.1. Sequence Number .....................................9
4.2.2. Flags Field .........................................9
4.2.3. EC Field ...........................................10
4.2.4. Encryption and Checksum Operations .................10
4.2.5. RRC Field ..........................................11
4.2.6. Message Layouts ....................................12
4.3. Context Deletion Tokens ...................................13
4.4. Token Identifier Assignment Considerations ................13
5. Parameter Definitions ..........................................14
5.1. Minor Status Codes ........................................14
5.1.1. Non-Kerberos-specific Codes ........................14
5.1.2. Kerberos-specific Codes ............................15
5.2. Buffer Sizes ..............................................15
6. Backwards Compatibility Considerations .........................15
7. Security Considerations ........................................16
8. Acknowledgements................................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
1. Introduction ....................................................2
2. Key Derivation for Per-Message Tokens ...........................4
3. Quality of Protection ...........................................4
4. Definitions and Token Formats ...................................5
4.1. Context Establishment Tokens ...............................5
4.1.1. Authenticator Checksum ..............................6
4.2. Per-Message Tokens .........................................9
4.2.1. Sequence Number .....................................9
4.2.2. Flags Field .........................................9
4.2.3. EC Field ...........................................10
4.2.4. Encryption and Checksum Operations .................10
4.2.5. RRC Field ..........................................11
4.2.6. Message Layouts ....................................12
4.3. Context Deletion Tokens ...................................13
4.4. Token Identifier Assignment Considerations ................13
5. Parameter Definitions ..........................................14
5.1. Minor Status Codes ........................................14
5.1.1. Non-Kerberos-specific Codes ........................14
5.1.2. Kerberos-specific Codes ............................15
5.2. Buffer Sizes ..............................................15
6. Backwards Compatibility Considerations .........................15
7. Security Considerations ........................................16
8. Acknowledgements................................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
[RFC3961] defines a generic framework for describing encryption and checksum types to be used with the Kerberos protocol and associated protocols.
[RFC3961]定义了一个通用框架，用于描述用于Kerberos协议和相关协议的加密和校验和类型。
[RFC1964] describes the GSS-API mechanism for Kerberos Version 5. It defines the format of context establishment, per-message and context deletion tokens, and uses algorithm identifiers for each cryptosystem in per-message and context deletion tokens.
[RFC1964]描述了Kerberos版本5的GSS-API机制。它定义了上下文建立、每条消息和上下文删除令牌的格式，并在每条消息和上下文删除令牌中使用每个密码系统的算法标识符。
The approach taken in this document obviates the need for algorithm identifiers. This is accomplished by using the same encryption algorithm, specified by the crypto profile [RFC3961] for the session key or subkey that is created during context negotiation, and its required checksum algorithm. Message layouts of the per-message tokens are therefore revised to remove algorithm indicators and to add extra information to support the generic crypto framework [RFC3961].
本文档中采用的方法消除了对算法标识符的需要。这是通过使用加密配置文件[RFC3961]为上下文协商期间创建的会话密钥或子密钥指定的相同加密算法及其所需的校验和算法来实现的。因此，修改了每消息令牌的消息布局，以删除算法指示符，并添加额外信息以支持通用加密框架[RFC3961]。
Tokens transferred between GSS-API peers for security context establishment are also described in this document. The data elements exchanged between a GSS-API endpoint implementation and the Kerberos Key Distribution Center (KDC) [RFC4120] are not specific to GSS-API usage and are therefore defined within [RFC4120] rather than this specification.
本文档还描述了GSS-API对等方之间为建立安全上下文而传输的令牌。GSS-API端点实现和Kerberos密钥分发中心（KDC）[RFC4120]之间交换的数据元素不特定于GSS-API使用，因此在[RFC4120]中定义，而不是在本规范中定义。
The new token formats specified in this document MUST be used with all "newer" encryption types [RFC4120] and MAY be used with encryption types that are not "newer", provided that the initiator and acceptor know from the context establishment that they can both process these new token formats.
本文档中指定的新令牌格式必须与所有“较新”的加密类型一起使用[RFC4120]，并且可以与非“较新”的加密类型一起使用，前提是发起方和接受方从上下文建立中知道它们都可以处理这些新令牌格式。
"Newer" encryption types are those which have been specified along with or since the new Kerberos cryptosystem specification [RFC3961], as defined in section 3.1.3 of [RFC4120]. The list of not-newer encryption types is as follows [RFC3961]:
“较新”的加密类型是指与新的Kerberos密码系统规范[RFC3961]一起指定的加密类型，或自该规范[RFC4120]第3.1.3节中定义的加密类型。不更新的加密类型列表如下[RFC3961]：
Encryption Type Assigned Number
----------------------------------------------
des-cbc-crc 1
des-cbc-md4 2
des-cbc-md5 3
des3-cbc-md5 5
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID 13
rsaES-OAEP-ENV-OID 14
des-ede3-cbc-Env-OID 15
des3-cbc-sha1-kd 16
rc4-hmac 23
Encryption Type Assigned Number
----------------------------------------------
des-cbc-crc 1
des-cbc-md4 2
des-cbc-md5 3
des3-cbc-md5 5
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID 13
rsaES-OAEP-ENV-OID 14
des-ede3-cbc-Env-OID 15
des3-cbc-sha1-kd 16
rc4-hmac 23
Conventions used in this document
本文件中使用的公约
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 term "little-endian order" is used for brevity to refer to the least-significant-octet-first encoding, while the term "big-endian order" is for the most-significant-octet-first encoding.
术语“小端顺序”用于简洁，以表示最低有效八位字节优先编码，而术语“大端顺序”用于最高有效八位字节优先编码。
To limit the exposure of a given key, [RFC3961] adopted "one-way" "entropy-preserving" derived keys, from a base key or protocol key, for different purposes or key usages.
为了限制给定密钥的公开，[RFC3961]采用了基于基本密钥或协议密钥的“单向”“保熵”派生密钥，用于不同的目的或密钥使用。
This document defines four key usage values below that are used to derive a specific key for signing and sealing messages from the session key or subkey [RFC4120] created during the context establishment.
本文档在下面定义了四个密钥使用值，用于从上下文建立期间创建的会话密钥或子密钥[RFC4120]派生用于签名和密封消息的特定密钥。
Name Value
-------------------------------------
KG-USAGE-ACCEPTOR-SEAL 22
KG-USAGE-ACCEPTOR-SIGN 23
KG-USAGE-INITIATOR-SEAL 24
KG-USAGE-INITIATOR-SIGN 25
Name Value
-------------------------------------
KG-USAGE-ACCEPTOR-SEAL 22
KG-USAGE-ACCEPTOR-SIGN 23
KG-USAGE-INITIATOR-SEAL 24
KG-USAGE-INITIATOR-SIGN 25
When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is used as the usage number in the key derivation function for deriving keys to be used in MIC tokens (as defined in section 4.2.6.1). KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens (as defined in section 4.2.6.2). Similarly, when the sender is the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage number in the key derivation function for MIC tokens, while KG-USAGE-INITIATOR-SEAL is used for Wrap tokens. Even if the Wrap token does not provide for confidentiality, the same usage values specified above are used.
当发送方是上下文接受者时，KG-USAGE-acceptor-SIGN用作密钥派生函数中的使用编号，用于派生MIC令牌中使用的密钥（定义见第4.2.6.1节）。KG-USAGE-ACCEPTOR-SEAL用于包裹代币（定义见第4.2.6.2节）。类似地，当发送方是上下文发起方时，KG-USAGE-initiator-SIGN用作MIC令牌的密钥派生函数中的用法编号，而KG-USAGE-initiator-SEAL用于Wrap令牌。即使Wrap令牌不提供机密性，也会使用上面指定的相同使用值。
During the context initiation and acceptance sequence, the acceptor MAY assert a subkey in the AP-REP message. If the acceptor asserts a subkey, the base key is the acceptor-asserted subkey and subsequent per-message tokens MUST be flagged with "AcceptorSubkey", as described in section 4.2.2. Otherwise, if the initiator asserts a subkey in the AP-REQ message, the base key is this subkey; if the initiator does not assert a subkey, the base key is the session key in the service ticket.
在上下文初始化和接受序列期间，接受者可以在AP-REP消息中断言子密钥。如果接受者声明子密钥，则基本密钥是接受者声明的子密钥，后续每条消息令牌必须标记为“接受者子密钥”，如第4.2.2节所述。否则，如果发起者在AP-REQ消息中断言子密钥，则基本密钥就是该子密钥；如果启动器未断言子密钥，则基本密钥是服务票证中的会话密钥。
The GSS-API specification [RFC2743] provides Quality of Protection (QOP) values that can be used by applications to request a certain type of encryption or signing. A zero QOP value is used to indicate the "default" protection; applications that do not use the default QOP are not guaranteed to be portable across implementations, or even to inter-operate with different deployment configurations of the same implementation. Using a different algorithm than the one for which the key is defined may not be appropriate. Therefore, when the new method in this document is used, the QOP value is ignored.
GSS-API规范[RFC2743]提供了保护质量（QOP）值，应用程序可以使用这些值来请求某种类型的加密或签名。零QOP值用于表示“默认”保护；不使用默认QOP的应用程序不能保证跨实现移植，甚至不能与同一实现的不同部署配置交互操作。使用与定义密钥的算法不同的算法可能不合适。因此，当使用本文档中的新方法时，QOP值将被忽略。
The encryption and checksum algorithms in per-message tokens are now implicitly defined by the algorithms associated with the session key or subkey. Therefore, algorithm identifiers as described in [RFC1964] are no longer needed and are removed from the new token headers.
每消息令牌中的加密和校验和算法现在由与会话密钥或子密钥关联的算法隐式定义。因此，不再需要[RFC1964]中所述的算法标识符，并将其从新的令牌头中删除。
This section provides terms and definitions, as well as descriptions for tokens specific to the Kerberos Version 5 GSS-API mechanism.
本节提供特定于Kerberos版本5 GSS-API机制的令牌的术语和定义以及描述。
All context establishment tokens emitted by the Kerberos Version 5 GSS-API mechanism SHALL have the framing described in section 3.1 of [RFC2743], as illustrated by the following pseudo-ASN.1 structures:
Kerberos版本5 GSS-API机制发出的所有上下文建立令牌应具有[RFC2743]第3.1节中描述的帧，如以下伪ASN.1结构所示：
GSS-API DEFINITIONS ::=
GSS-API DEFINITIONS ::=
BEGIN
开始
MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism
MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
终止
The innerToken field starts with a two-octet token-identifier (TOK_ID) expressed in big-endian order, followed by a Kerberos message.
innerToken字段以一个两个八位字节的令牌标识符（TOK_ID）开始，以大端顺序表示，后跟一条Kerberos消息。
Following are the TOK_ID values used in the context establishment tokens:
以下是上下文建立令牌中使用的TOK_ID值：
Token TOK_ID Value in Hex
-----------------------------------------
KRB_AP_REQ 01 00
KRB_AP_REP 02 00
KRB_ERROR 03 00
Token TOK_ID Value in Hex
-----------------------------------------
KRB_AP_REQ 01 00
KRB_AP_REP 02 00
KRB_ERROR 03 00
Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR are defined in [RFC4120].
其中Kerberos消息KRB_AP_请求、KRB_AP_回复和KRB_错误在[RFC4120]中定义。
If an unknown token identifier (TOK_ID) is received in the initial context establishment token, the receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the returned output token MUST contain a KRB_ERROR message with the error code KRB_AP_ERR_MSG_TYPE [RFC4120].
如果在初始上下文建立令牌中接收到未知令牌标识符（TOK_ID），则接收方必须返回GSS_S_CONTINUE_Required Main status，并且返回的输出令牌必须包含错误代码为KRB_AP_ERR_MSG_TYPE[RFC4120]的KRB_错误消息。
The authenticator in the KRB_AP_REQ message MUST include the optional sequence number and the checksum field. The checksum field is used to convey service flags, channel bindings, and optional delegation information.
KRB_AP_REQ消息中的验证器必须包括可选序列号和校验和字段。校验和字段用于传递服务标志、通道绑定和可选的委派信息。
The checksum type MUST be 0x8003. When delegation is used, a ticket-granting ticket will be transferred in a KRB_CRED message. This ticket SHOULD have its forwardable flag set. The EncryptedData field of the KRB_CRED message [RFC4120] MUST be encrypted in the session key of the ticket used to authenticate the context.
校验和类型必须为0x8003。使用委派时，将在KRB_CRED消息中传输票据授予票据。此票证应设置可转发标志。KRB_CRED消息[RFC4120]的EncryptedData字段必须在用于验证上下文的票据的会话密钥中加密。
The authenticator checksum field SHALL have the following format:
验证器校验和字段应具有以下格式：
Octet Name Description
-----------------------------------------------------------------
0..3 Lgth Number of octets in Bnd field; Represented
in little-endian order; Currently contains
hex value 10 00 00 00 (16).
4..19 Bnd Channel binding information, as described in
section 4.1.1.2.
20..23 Flags Four-octet context-establishment flags in
little-endian order as described in section
4.1.1.1.
24..25 DlgOpt The delegation option identifier (=1) in
little-endian order [optional]. This field
and the next two fields are present if and
only if GSS_C_DELEG_FLAG is set as described
in section 4.1.1.1.
26..27 Dlgth The length of the Deleg field in
little-endian order [optional].
28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28)
[optional].
n..last Exts Extensions [optional].
Octet Name Description
-----------------------------------------------------------------
0..3 Lgth Number of octets in Bnd field; Represented
in little-endian order; Currently contains
hex value 10 00 00 00 (16).
4..19 Bnd Channel binding information, as described in
section 4.1.1.2.
20..23 Flags Four-octet context-establishment flags in
little-endian order as described in section
4.1.1.1.
24..25 DlgOpt The delegation option identifier (=1) in
little-endian order [optional]. This field
and the next two fields are present if and
only if GSS_C_DELEG_FLAG is set as described
in section 4.1.1.1.
26..27 Dlgth The length of the Deleg field in
little-endian order [optional].
28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28)
[optional].
n..last Exts Extensions [optional].
The length of the checksum field MUST be at least 24 octets when GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set. When
未设置GSS_C_DELEG_标志时（如第4.1.1.1节所述），校验和字段的长度必须至少为24个八位字节；设置GSS_C_DELEG_标志时，校验和字段的长度必须至少为28个八位字节加上Dlgth八位字节。什么时候
GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth, and Deleg fields of the checksum data MUST immediately follow the Flags field. The optional trailing octets (namely the "Exts" field) facilitate future extensions to this mechanism. When delegation is not used, but the Exts field is present, the Exts field starts at octet 24 (DlgOpt, Dlgth and Deleg are absent).
设置GSS_C_DELEG_标志后，校验和数据的DlgOpt、Dlgth和DELEG字段必须紧跟在标志字段之后。可选的尾部八位字节（即“Exts”字段）便于将来扩展此机制。如果未使用委派，但存在Exts字段，则Exts字段从八位字节24开始（不存在DlgOpt、Dlgth和Deleg）。
Initiators that do not support the extensions MUST NOT include more than 24 octets in the checksum field (when GSS_C_DELEG_FLAG is not set) or more than 28 octets plus the KRB_CRED in the Deleg field (when GSS_C_DELEG_FLAG is set). Acceptors that do not understand the
不支持扩展的启动器不得在校验和字段中包含超过24个八位字节（未设置GSS_C_DELEG_标志时），或在DELEG字段中包含超过28个八位字节加上KRB_CRED（设置GSS_C_DELEG_标志时）。不理解
Extensions MUST ignore any octets past the Deleg field of the checksum data (when GSS_C_DELEG_FLAG is set) or past the Flags field of the checksum data (when GSS_C_DELEG_FLAG is not set).
扩展必须忽略超过校验和数据的Deleg字段（当设置了GSS_C_Deleg_标志时）或超过校验和数据的Flags字段（当未设置GSS_C_Deleg_标志时）的任何八位字节。
The checksum "Flags" field is used to convey service options or extension negotiation information.
校验和“标志”字段用于传递服务选项或扩展协商信息。
The following context establishment flags are defined in [RFC2744].
[RFC2744]中定义了以下上下文建立标志。
Flag Name Value
---------------------------------
GSS_C_DELEG_FLAG 1
GSS_C_MUTUAL_FLAG 2
GSS_C_REPLAY_FLAG 4
GSS_C_SEQUENCE_FLAG 8
GSS_C_CONF_FLAG 16
GSS_C_INTEG_FLAG 32
Flag Name Value
---------------------------------
GSS_C_DELEG_FLAG 1
GSS_C_MUTUAL_FLAG 2
GSS_C_REPLAY_FLAG 4
GSS_C_SEQUENCE_FLAG 8
GSS_C_CONF_FLAG 16
GSS_C_INTEG_FLAG 32
Context establishment flags are exposed to the calling application. If the calling application desires a particular service option, then it requests that option via GSS_Init_sec_context() [RFC2743]. If the corresponding return state values [RFC2743] indicate that any of the above optional context level services will be active on the context, the corresponding flag values in the table above MUST be set in the checksum Flags field.
上下文建立标志向调用应用程序公开。如果调用应用程序需要特定的服务选项，那么它会通过GSS_Init_sec_context（）[RFC2743]请求该选项。如果相应的返回状态值[RFC2743]指示任何上述可选上下文级别服务将在上下文中处于活动状态，则必须在校验和标志字段中设置上表中的相应标志值。
Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use with legacy vendor-specific extensions to this mechanism.
标记值4096..524288（2^12，2^13，…，2^19）保留用于此机制的传统供应商特定扩展。
All other flag values not specified herein are reserved for future use. Future revisions of this mechanism may use these reserved flags and may rely on implementations of this version to not use such flags in order to properly negotiate mechanism versions. Undefined flag values MUST be cleared by the sender, and unknown flags MUST be ignored by the receiver.
此处未指定的所有其他标志值保留供将来使用。此机制的未来版本可能会使用这些保留标志，并且可能依赖此版本的实现不使用这些标志，以便正确协商机制版本。发送方必须清除未定义的标志值，接收方必须忽略未知标志。
These tags are intended to be used to identify the particular communications channel for which the GSS-API security context establishment tokens are intended, thus limiting the scope within which an intercepted context establishment token can be reused by an attacker (see [RFC2743], section 1.1.6).
这些标记旨在用于识别GSS-API安全上下文建立令牌所针对的特定通信信道，从而限制攻击者可重用截获上下文建立令牌的范围（请参见[RFC2743]，第1.1.6节）。
When using C language bindings, channel bindings are communicated to the GSS-API using the following structure [RFC2744]:
使用C语言绑定时，通道绑定使用以下结构[RFC2744]与GSS-API通信：
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype;
gss_buffer_desc initiator_address;
OM_uint32 acceptor_addrtype;
gss_buffer_desc acceptor_address;
gss_buffer_desc application_data;
} *gss_channel_bindings_t;
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype;
gss_buffer_desc initiator_address;
OM_uint32 acceptor_addrtype;
gss_buffer_desc acceptor_address;
gss_buffer_desc application_data;
} *gss_channel_bindings_t;
The member fields and constants used for different address types are defined in [RFC2744].
[RFC2744]中定义了用于不同地址类型的成员字段和常量。
The "Bnd" field contains the MD5 hash of channel bindings, taken over all non-null components of bindings, in order of declaration. Integer fields within channel bindings are represented in little-endian order for the purposes of the MD5 calculation.
“Bnd”字段包含通道绑定的MD5散列，按声明顺序接管绑定的所有非空组件。为了进行MD5计算，通道绑定中的整数字段以小尾数顺序表示。
In computing the contents of the Bnd field, the following detailed points apply:
在计算Bnd字段的内容时，以下详细点适用：
(1) For purposes of MD5 hash computation, each integer field and input length field SHALL be formatted into four octets, using little-endian octet ordering.
(1) 为了进行MD5哈希计算，每个整数字段和输入长度字段应使用小端八位字节顺序格式化为四个八位字节。
(2) All input length fields within gss_buffer_desc elements of a gss_channel_bindings_struct even those which are zero-valued, SHALL be included in the hash calculation. The value elements of gss_buffer_desc elements SHALL be dereferenced, and the resulting data SHALL be included within the hash computation, only for the case of gss_buffer_desc elements having non-zero length specifiers.
(2) gss_channel_bindings_结构的gss_buffer_desc元素中的所有输入长度字段（即使是零值字段）都应包含在哈希计算中。gss_buffer_desc元素的值元素应被取消引用，结果数据应包含在哈希计算中，仅适用于具有非零长度说明符的gss_buffer_desc元素的情况。
(3) If the caller passes the value GSS_C_NO_BINDINGS instead of a valid channel binding structure, the Bnd field SHALL be set to 16 zero-valued octets.
(3) 如果调用方传递值GSS_C_NO_BINDINGS而不是有效的通道绑定结构，则Bnd字段应设置为16个零值八位字节。
If the caller to GSS_Accept_sec_context [RFC2743] passes in GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the acceptor MAY ignore any channel bindings supplied by the initiator, returning success even if the initiator did pass in channel bindings.
如果GSS_Accept_sec_context[RFC2743]的调用者将GSS_C_NO_CHANNEL_绑定[RFC2744]作为通道绑定传递，那么接受者可能会忽略启动器提供的任何通道绑定，即使启动器确实传递了通道绑定，也会返回成功。
If the application supplies, in the channel bindings, a buffer with a length field larger than 4294967295 (2^32 - 1), the implementation of this mechanism MAY choose to reject the channel bindings altogether, using major status GSS_S_BAD_BINDINGS [RFC2743]. In any case, the size of channel-binding data buffers that can be used (interoperable, without extensions) with this specification is limited to 4294967295 octets.
如果应用程序在通道绑定中提供长度字段大于4294967295（2^32-1）的缓冲区，则此机制的实现可能会选择使用主要状态GSS_S_BAD_绑定完全拒绝通道绑定[RFC2743]。在任何情况下，可与本规范一起使用（可互操作，无需扩展）的通道绑定数据缓冲区的大小限制为4294967295个八位字节。
Two classes of tokens are defined in this section: (1) "MIC" tokens, emitted by calls to GSS_GetMIC() and consumed by calls to GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to GSS_Wrap() and consumed by calls to GSS_Unwrap().
本节定义了两类令牌：（1）通过调用GSS_GetMIC（）发出并被调用GSS_VerifyMIC（）消耗的“MIC”令牌，以及（2）通过调用GSS_Wrap（）发出并被调用GSS_Unwrap（）消耗的“Wrap”令牌。
These new per-message tokens do not include the generic GSS-API token framing used by the context establishment tokens. These new tokens are designed to be used with newer crypto systems that can have variable-size checksums.
这些新的每消息令牌不包括上下文建立令牌使用的通用GSS-API令牌帧。这些新令牌设计用于具有可变大小校验和的较新加密系统。
To distinguish intentionally-repeated messages from maliciously-replayed ones, per-message tokens contain a sequence number field, which is a 64 bit integer expressed in big-endian order. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence numbers SHALL be incremented by one.
为了区分有意重复的消息和恶意重播的消息，每条消息令牌包含一个序列号字段，该字段是以大端顺序表示的64位整数。发送GSS_GetMIC（）或GSS_Wrap（）令牌后，发送方的序列号应增加1。
The "Flags" field is a one-octet integer used to indicate a set of attributes for the protected message. For example, one flag is allocated as the direction-indicator, thus preventing the acceptance of the same message sent back in the reverse direction by an adversary.
“标志”字段是一个八位整数，用于指示受保护消息的一组属性。例如，分配一个标志作为方向指示器，从而防止敌方接受反向发送的相同消息。
The meanings of bits in this field (the least significant bit is bit 0) are as follows:
该字段中的位（最低有效位为位0）的含义如下：
Bit Name Description
--------------------------------------------------------------
0 SentByAcceptor When set, this flag indicates the sender
is the context acceptor. When not set,
it indicates the sender is the context
initiator.
1 Sealed When set in Wrap tokens, this flag
indicates confidentiality is provided
for. It SHALL NOT be set in MIC tokens.
2 AcceptorSubkey A subkey asserted by the context acceptor
is used to protect the message.
Bit Name Description
--------------------------------------------------------------
0 SentByAcceptor When set, this flag indicates the sender
is the context acceptor. When not set,
it indicates the sender is the context
initiator.
1 Sealed When set in Wrap tokens, this flag
indicates confidentiality is provided
for. It SHALL NOT be set in MIC tokens.
2 AcceptorSubkey A subkey asserted by the context acceptor
is used to protect the message.
The rest of available bits are reserved for future use and MUST be cleared. The receiver MUST ignore unknown flags.
其余可用位保留供将来使用，必须清除。接收器必须忽略未知标志。
The "EC" (Extra Count) field is a two-octet integer field expressed in big-endian order.
“EC”（额外计数）字段是以大端顺序表示的两个八位整数字段。
In Wrap tokens with confidentiality, the EC field SHALL be used to encode the number of octets in the filler, as described in section 4.2.4.
如第4.2.4节所述，在保密包装令牌中，应使用EC字段对填充符中的八位字节数进行编码。
In Wrap tokens without confidentiality, the EC field SHALL be used to encode the number of octets in the trailing checksum, as described in section 4.2.4.
如第4.2.4节所述，在无保密性的包装令牌中，EC字段应用于编码尾随校验和中的八位字节数。
The encryption algorithms defined by the crypto profiles provide for integrity protection [RFC3961]. Therefore, no separate checksum is needed.
加密配置文件定义的加密算法提供完整性保护[RFC3961]。因此，不需要单独的校验和。
The result of decryption can be longer than the original plaintext [RFC3961] and the extra trailing octets are called "crypto-system residue" in this document. However, given the size of any plaintext data, one can always find a (possibly larger) size, such that when padding the to-be-encrypted text to that size, there will be no crypto-system residue added [RFC3961].
解密的结果可能比原始明文[RFC3961]更长，在本文档中，额外的尾随八位字节称为“密码系统剩余”。然而，考虑到任何明文数据的大小，总是可以找到一个（可能更大的）大小，这样当填充要加密的文本到该大小时，就不会添加任何密码系统残留物[RFC3961]。
In Wrap tokens that provide for confidentiality, the first 16 octets of the Wrap token (the "header", as defined in section 4.2.6), SHALL be appended to the plaintext data before encryption. Filler octets MAY be inserted between the plaintext data and the "header." The
在提供保密性的Wrap令牌中，在加密之前，应将Wrap令牌的前16个八位字节（第4.2.6节中定义的“头”）附加到明文数据中。可以在明文数据和“标题”之间插入填充八位字节
values and size of the filler octets are chosen by implementations, such that there SHALL be no crypto-system residue present after the decryption. The resulting Wrap token is {"header" | encrypt(plaintext-data | filler | "header")}, where encrypt() is the encryption operation (which provides for integrity protection) defined in the crypto profile [RFC3961], and the RRC field (as defined in section 4.2.5) in the to-be-encrypted header contains the hex value 00 00.
填充八位字节的值和大小由实现选择，这样在解密后就不会有密码系统残留。生成的换行标记是{“header”| encrypt（明文数据| filler |“header”）}，其中encrypt（）是加密配置文件[RFC3961]中定义的加密操作（提供完整性保护），并且待加密头中的RRC字段（如第4.2.5节中定义）包含十六进制值00。
In Wrap tokens that do not provide for confidentiality, the checksum SHALL be calculated first over the to-be-signed plaintext data, and then over the first 16 octets of the Wrap token (the "header", as defined in section 4.2.6). Both the EC field and the RRC field in the token header SHALL be filled with zeroes for the purpose of calculating the checksum. The resulting Wrap token is {"header" | plaintext-data | get_mic(plaintext-data | "header")}, where get_mic() is the checksum operation for the required checksum mechanism of the chosen encryption mechanism defined in the crypto profile [RFC3961].
在不提供保密性的Wrap令牌中，应首先在待签名的明文数据上计算校验和，然后在Wrap令牌的前16个八位字节上计算校验和（如第4.2.6节所定义的“报头”）。为了计算校验和，令牌报头中的EC字段和RRC字段均应填入零。生成的换行标记是{“header”|明文数据| get| mic（明文数据|“header”）}，其中get|mic（）是加密配置文件[RFC3961]中定义的所选加密机制的所需校验和机制的校验和操作。
The parameters for the key and the cipher-state in the encrypt() and get_mic() operations have been omitted for brevity.
为简洁起见，已省略encrypt（）和get_mic（）操作中的密钥和密码状态参数。
For MIC tokens, the checksum SHALL be calculated as follows: the checksum operation is calculated first over the to-be-signed plaintext data, and then over the first 16 octets of the MIC token, where the checksum mechanism is the required checksum mechanism of the chosen encryption mechanism defined in the crypto profile [RFC3961].
对于MIC令牌，校验和应按如下方式计算：校验和操作首先在待签名明文数据上计算，然后在MIC令牌的前16个八位字节上计算，其中校验和机制是加密配置文件[RFC3961]中定义的所选加密机制的所需校验和机制。
The resulting Wrap and MIC tokens bind the data to the token header, including the sequence number and the direction indicator.
生成的Wrap和MIC令牌将数据绑定到令牌头，包括序列号和方向指示器。
The "RRC" (Right Rotation Count) field in Wrap tokens is added to allow the data to be encrypted in-place by existing SSPI (Security Service Provider Interface) [SSPI] applications that do not provide an additional buffer for the trailer (the cipher text after the in-place-encrypted data) in addition to the buffer for the header (the cipher text before the in-place-encrypted data). Excluding the first 16 octets of the token header, the resulting Wrap token in the previous section is rotated to the right by "RRC" octets. The net result is that "RRC" octets of trailing octets are moved toward the header.
Wrap令牌中的“RRC”（右旋转计数）字段被添加，以允许现有SSPI（安全服务提供商接口）[SSPI]应用程序对数据进行就地加密，这些应用程序除了标头的缓冲区外，不为尾部提供额外缓冲区（就地加密数据后的密码文本）（就地加密数据之前的密码文本）。除去令牌头的前16个八位字节，上一节中生成的换行令牌向右旋转“RRC”八位字节。最终结果是，尾随八位字节的“RRC”八位字节向报头移动。
Consider the following as an example of this rotation operation: Assume that the RRC value is 3 and the token before the rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}. The token after
考虑下面的旋转操作的一个例子：假设RRC值为3，旋转前的令牌为{“报头”αAB bc} dd{ee } fgggHH}}。后面的代币
rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb | cc |...| hh} would be used to indicate the octet sequence.
轮换将是{“header”| ff | gg | hh | aa | bb | cc | dd | ee}，其中{aa | bb | cc | cc | hh}将用于指示八位组序列。
The RRC field is expressed as a two-octet integer in big-endian order.
RRC字段以大端顺序表示为两个八位整数。
The rotation count value is chosen by the sender based on implementation details. The receiver MUST be able to interpret all possible rotation count values, including rotation counts greater than the length of the token.
发送方根据实现细节选择旋转计数值。接收器必须能够解释所有可能的旋转计数值，包括大于令牌长度的旋转计数。
Per-message tokens start with a two-octet token identifier (TOK_ID) field, expressed in big-endian order. These tokens are defined separately in the following sub-sections.
每消息令牌以两个八位组令牌标识符（TOK_ID）字段开始，以大端顺序表示。这些标记在以下小节中分别定义。
Use of the GSS_GetMIC() call yields a token (referred as the MIC token in this document), separate from the user data being protected, which can be used to verify the integrity of that data as received. The token has the following format:
使用GSS_GetMIC（）调用将生成一个令牌（在本文档中称为MIC令牌），该令牌与受保护的用户数据分开，可用于验证接收到的数据的完整性。令牌具有以下格式：
Octet no Name Description
--------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_GetMIC() contain the hex value 04 04
expressed in big-endian order in this
field.
2 Flags Attributes field, as described in section
4.2.2.
3..7 Filler Contains five octets of hex value FF.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big-endian order.
16..last SGN_CKSUM Checksum of the "to-be-signed" data and
octet 0..15, as described in section 4.2.4.
Octet no Name Description
--------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_GetMIC() contain the hex value 04 04
expressed in big-endian order in this
field.
2 Flags Attributes field, as described in section
4.2.2.
3..7 Filler Contains five octets of hex value FF.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big-endian order.
16..last SGN_CKSUM Checksum of the "to-be-signed" data and
octet 0..15, as described in section 4.2.4.
The Filler field is included in the checksum calculation for simplicity.
为简单起见，校验和计算中包含了Filler字段。
Use of the GSS_Wrap() call yields a token (referred as the Wrap token in this document), which consists of a descriptive header, followed by a body portion that contains either the input user data in plaintext concatenated with the checksum, or the input user data encrypted. The GSS_Wrap() token SHALL have the following format:
使用GSS_Wrap（）调用将生成一个令牌（在本文档中称为Wrap令牌），该令牌由一个描述性标头组成，后跟一个正文部分，其中包含与校验和相连的明文输入用户数据或加密的输入用户数据。GSS_Wrap（）令牌应具有以下格式：
Octet no Name Description
--------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_Wrap() contain the hex value 05 04
expressed in big-endian order in this
field.
2 Flags Attributes field, as described in section
4.2.2.
3 Filler Contains the hex value FF.
4..5 EC Contains the "extra count" field, in big-
endian order as described in section 4.2.3.
6..7 RRC Contains the "right rotation count" in big-
endian order, as described in section
4.2.5.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big-endian order.
16..last Data Encrypted data for Wrap tokens with
confidentiality, or plaintext data followed
by the checksum for Wrap tokens without
confidentiality, as described in section
4.2.4.
Octet no Name Description
--------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_Wrap() contain the hex value 05 04
expressed in big-endian order in this
field.
2 Flags Attributes field, as described in section
4.2.2.
3 Filler Contains the hex value FF.
4..5 EC Contains the "extra count" field, in big-
endian order as described in section 4.2.3.
6..7 RRC Contains the "right rotation count" in big-
endian order, as described in section
4.2.5.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big-endian order.
16..last Data Encrypted data for Wrap tokens with
confidentiality, or plaintext data followed
by the checksum for Wrap tokens without
confidentiality, as described in section
4.2.4.
Context deletion tokens are empty in this mechanism. Both peers to a security context invoke GSS_Delete_sec_context() [RFC2743] independently, passing a null output_context_token buffer to indicate that no context_token is required. Implementations of GSS_Delete_sec_context() should delete relevant locally-stored context information.
在此机制中，上下文删除标记为空。安全上下文的两个对等方分别调用GSS_Delete_sec_context（）[RFC2743]，传递空输出_context_令牌缓冲区，以指示不需要上下文_令牌。GSS_Delete_sec_context（）的实现应该删除本地存储的相关上下文信息。
Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF inclusive are reserved and SHALL NOT be assigned. Thus, by examining the first two octets of a token, one can tell unambiguously if it is wrapped with the generic GSS-API token framing.
从0x60 0x00到0x60 0xFF（含0x60 0xFF）的令牌标识符（TOK_ID）是保留的，不应分配。因此，通过检查令牌的前两个八位字节，可以清楚地知道它是否用通用GSS-API令牌帧包装。
This section defines parameter values used by the Kerberos V5 GSS-API mechanism. It defines interface elements that support portability, and assumes use of C language bindings per [RFC2744].
本节定义Kerberos V5 GSS-API机制使用的参数值。它定义了支持可移植性的接口元素，并根据[RFC2744]假设使用C语言绑定。
This section recommends common symbolic names for minor_status values to be returned by the Kerberos V5 GSS-API mechanism. Use of these definitions will enable independent implementers to enhance application portability across different implementations of the mechanism defined in this specification. (In all cases, implementations of GSS_Display_status() will enable callers to convert minor_status indicators to text representations.) Each implementation should make available, through include files or other means, a facility to translate these symbolic names into the concrete values that a particular GSS-API implementation uses to represent the minor_status values specified in this section.
本节为Kerberos V5 GSS-API机制返回的次要_状态值推荐通用符号名。使用这些定义将使独立的实现者能够跨本规范中定义的机制的不同实现增强应用程序的可移植性。（在所有情况下，GSS_Display_status（）的实现都将允许调用方将次要_状态指示器转换为文本表示形式。）每个实现都应通过包含文件或其他方式提供，将这些符号名称转换为具体值的工具，特定GSS-API实现使用这些具体值来表示本节中指定的次要_状态值。
This list may grow over time and the need for additional minor_status codes, specific to particular implementations, may arise. However, it is recommended that implementations should return a minor_status value as defined on a mechanism-wide basis within this section when that code accurately represents reportable status rather than using a separate, implementation-defined code.
此列表可能会随着时间的推移而增加，并且可能会出现特定于特定实现的附加次要_状态代码的需求。但是，如果代码准确地表示可报告的状态，而不是使用单独的、实现定义的代码，则建议实现应返回本节中在整个机制基础上定义的次要_状态值。
GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_NOUSER
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_KRB5_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */
GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_NOUSER
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_KRB5_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Client principal in credentials does not match
specified name" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No key available for specified service
principal" */
GSS_KRB5_S_KG_TGT_MISSING
/* "No Kerberos ticket-granting ticket available" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Client principal in credentials does not match
specified name" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No key available for specified service
principal" */
GSS_KRB5_S_KG_TGT_MISSING
/* "No Kerberos ticket-granting ticket available" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
All implementations of this specification MUST be capable of accepting buffers of at least 16K octets as input to GSS_GetMIC(), GSS_VerifyMIC(), and GSS_Wrap(). They MUST also be capable of accepting the output_token generated by GSS_Wrap() for a 16K octet input buffer as input to GSS_Unwrap(). Implementations SHOULD support 64K octet input buffers, and MAY support even larger input buffer sizes.
本规范的所有实现必须能够接受至少16K个八位字节的缓冲区作为GSS_GetMIC（）、GSS_VerifyMIC（）和GSS_Wrap（）的输入。它们还必须能够接受GSS_Wrap（）为16K八位组输入缓冲区生成的输出_令牌作为GSS_Unwrap（）的输入。实现应该支持64K八位输入缓冲区，并且可能支持更大的输入缓冲区大小。
The new token formats defined in this document will only be recognized by new implementations. To address this, implementations can always use the explicit sign or seal algorithm in [RFC1964] when the key type corresponds to not "newer" enctypes. As an alternative, one might retry sending the message with the sign or seal algorithm explicitly defined as in [RFC1964]. However, this would require either the use of a mechanism such as [RFC2478] to securely negotiate the method, or the use of an out-of-band mechanism to choose the appropriate mechanism. For this reason, it is RECOMMENDED that the new token formats defined in this document SHOULD be used only if both peers are known to support the new mechanism during context negotiation because of, for example, the use of "new" enctypes.
本文档中定义的新令牌格式只能由新的实现识别。为了解决这个问题，当密钥类型对应于非“较新”的加密类型时，实现总是可以使用[RFC1964]中的显式签名或盖章算法。或者，可以使用[RFC1964]中明确定义的签名或盖章算法重试发送消息。但是，这需要使用[RFC2478]等机制来安全协商方法，或者使用带外机制来选择适当的机制。因此，建议仅当已知两个对等方在上下文协商期间都支持新机制时，才使用本文档中定义的新令牌格式，例如，由于使用了“新”类型。
GSS_Unwrap() or GSS_VerifyMIC() can process a message token as follows: it can look at the first octet of the token header, and if it is 0x60, then the token must carry the generic GSS-API pseudo ASN.1 framing. Otherwise, the first two octets of the token contain the TOK_ID that uniquely identify the token message format.
GSS_Unwrap（）或GSS_VerifyMIC（）可以按如下方式处理消息令牌：它可以查看令牌头的第一个八位字节，如果是0x60，则令牌必须携带通用GSS-API伪ASN.1帧。否则，令牌的前两个八位字节包含唯一标识令牌消息格式的TOK_ID。
Channel bindings are validated by the acceptor. The acceptor can ignore the channel bindings restriction supplied by the initiator and carried in the authenticator checksum, if (1) channel bindings are not used by GSS_Accept_sec_context [RFC2743], and (2) the acceptor does not prove to the initiator that it has the same channel bindings as the initiator (even if the client requested mutual authentication). This limitation should be considered by designers of applications that would use channel bindings, whether to limit the use of GSS-API contexts to nodes with specific network addresses, to authenticate other established, secure channels using Kerberos Version 5, or for any other purpose.
通道绑定由接受者验证。如果（1）GSS_Accept_sec_上下文[RFC2743]未使用通道绑定，并且（2）接受方未向发起方证明其具有与发起方相同的通道绑定，则接受方可以忽略发起方提供并在验证器校验和中携带的通道绑定限制（即使客户端请求相互身份验证）。使用通道绑定的应用程序的设计者应考虑此限制，无论是将GSS-API上下文的使用限制为具有特定网络地址的节点，还是使用Kerberos版本5对其他已建立的安全通道进行身份验证，还是出于任何其他目的。
Session key types are selected by the KDC. Under the current mechanism, no negotiation of algorithm types occurs, so server-side (acceptor) implementations cannot request that clients not use algorithm types not understood by the server. However, administrators can control what enctypes can be used for session keys for this mechanism by controlling the set of the ticket session key enctypes which the KDC is willing to use in tickets for a given acceptor principal. Therefore, the KDC could be given the task of limiting session keys for a given service to types actually supported by the Kerberos and GSSAPI software on the server. This has a drawback for cases in which a service principal name is used for both GSSAPI-based and non-GSSAPI-based communication (most notably the "host" service key), if the GSSAPI implementation does not understand (for example) AES [RFC3962], but the Kerberos implementation does. This means that AES session keys cannot be issued for that service principal, which keeps the protection of non-GSSAPI services weaker than necessary. KDC administrators desiring to limit the session key types to support interoperability with such GSSAPI implementations should carefully weigh the reduction in protection offered by such mechanisms against the benefits of interoperability.
会话密钥类型由KDC选择。在当前机制下，不会发生算法类型协商，因此服务器端（接受者）实现不能请求客户端不使用服务器不理解的算法类型。但是，管理员可以通过控制KDC愿意在给定接受者主体的票证中使用的票证会话密钥enctypes集合，来控制该机制的会话密钥可以使用哪些enctypes。因此，KDC可以被赋予将给定服务的会话密钥限制为服务器上Kerberos和GSSAPI软件实际支持的类型的任务。如果GSSAPI实现不理解（例如）AES[RFC3962]，但Kerberos实现不理解，则在基于GSSAPI和非基于GSSAPI的通信（最明显的是“主机”服务密钥）中同时使用服务主体名称的情况下，这有一个缺点。这意味着无法为该服务主体颁发AES会话密钥，这使得非GSSAPI服务的保护比必要时更弱。希望限制会话密钥类型以支持与此类GSSAPI实现的互操作性的KDC管理员应仔细权衡此类机制提供的保护减少与互操作性的好处。
Ken Raeburn and Nicolas Williams corrected many of our errors in the use of generic profiles and were instrumental in the creation of this document.
肯·雷伯恩（Ken Raeburn）和尼古拉斯·威廉姆斯（Nicolas Williams）纠正了我们在使用通用配置文件时的许多错误，并在本文档的创建过程中发挥了重要作用。
The text for security considerations was contributed by Nicolas Williams and Ken Raeburn.
出于安全考虑的文本由Nicolas Williams和Ken Raeburn提供。
Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, namely the encoding of the RRC field.
Sam Hartman和Ken Raeburn提出了“浮动拖车”的想法，即RRC字段的编码。
Sam Hartman and Nicolas Williams recommended the replacing our earlier key derivation function for directional keys with different key usage numbers for each direction as well as retaining the directional bit for maximum compatibility.
Sam Hartman和Nicolas Williams建议使用不同的方向键使用编号替换我们早期的方向键派生函数，并保留方向位以实现最大兼容性。
Paul Leach provided numerous suggestions and comments.
Paul Leach提供了许多建议和评论。
Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon Josefsson also provided valuable inputs on this document.
Scott Field、Richard Ward、Dan Simon、Kevin Damour和Simon Josefsson也为本文档提供了宝贵的信息。
Jeffrey Hutzelman provided comments and clarifications for the text related to the channel bindings.
Jeffrey Hutzelman为与通道绑定相关的文本提供了评论和澄清。
Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
Jeffrey Hutzelman和Russ Housley提出了许多编辑上的修改。
Luke Howard provided implementations of this document for the Heimdal code base, and helped inter-operability testing with the Microsoft code base, together with Love Hornquist Astrand. These experiments formed the basis of this document.
Luke Howard为Heimdal代码库提供了本文档的实现，并与Love Hornquist Astrand一起帮助进行了与Microsoft代码库的互操作性测试。这些实验构成了本文件的基础。
Martin Rex provided suggestions of TOK_ID assignment recommendations, thus the token tagging in this document is unambiguous if the token is wrapped with the pseudo ASN.1 header.
Martin Rex提供了TOK_ID分配建议，因此，如果令牌使用伪ASN.1头包装，则本文档中的令牌标记是明确的。
John Linn wrote the original Kerberos Version 5 mechanism specification [RFC1964], of which some text has been retained.
John Linn编写了最初的Kerberos第5版机制规范[RFC1964]，其中保留了一些文本。
[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月。
[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月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[SSPI] Leach, P., "Security Service Provider Interface", Microsoft Developer Network (MSDN), April 2003.
[SSPI]Leach，P.，“安全服务提供商接口”，微软开发者网络（MSDN），2003年4月。
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962]Raeburn，K.，“Kerberos 5的高级加密标准（AES）加密”，RFC 3962，2005年2月。
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478]Baize，E.和D.Pinkas，“简单和受保护的GSS-API协商机制”，RFC 2478，1998年12月。
Authors' Addresses
作者地址
Larry Zhu One Microsoft Way Redmond, WA 98052 - USA
Larry Zhu One Microsoft Way Redmond，WA 98052-美国
EMail: LZhu@microsoft.com
EMail: LZhu@microsoft.com
Karthik Jaganathan One Microsoft Way Redmond, WA 98052 - USA
Karthik Jaganather One微软Way Redmond，WA 98052-美国
EMail: karthikj@microsoft.com
EMail: karthikj@microsoft.com
Sam Hartman Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 - USA
Sam Hartman麻省理工学院马萨诸塞大道77号剑桥，马萨诸塞州02139-美国
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。