Network Working Group L. Zhu
Request for Comments: 4556 Microsoft Corporation
Category: Standards Track B. Tung
Aerospace Corporation
June 2006
Network Working Group L. Zhu
Request for Comments: 4556 Microsoft Corporation
Category: Standards Track B. Tung
Aerospace Corporation
June 2006
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Kerberos中用于初始身份验证的公钥加密（PKINIT）
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields.
本文档描述Kerberos协议规范的协议扩展（以下称为PKINIT）。这些扩展提供了一种方法，通过在预认证数据字段中使用非对称密钥签名和/或加密算法，将公钥加密技术集成到初始认证交换中。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
3. Extensions ......................................................5
3.1. Definitions, Requirements, and Constants ...................6
3.1.1. Required Algorithms .................................6
3.1.2. Recommended Algorithms ..............................6
3.1.3. Defined Message and Encryption Types ................7
3.1.4. Kerberos Encryption Types Defined for CMS
Algorithm Identifiers ...............................8
3.2. PKINIT Pre-authentication Syntax and Use ...................9
3.2.1. Generation of Client Request ........................9
3.2.2. Receipt of Client Request ..........................14
3.2.3. Generation of KDC Reply ............................18
3.2.3.1. Using Diffie-Hellman Key Exchange .........21
3.2.3.2. Using Public Key Encryption ...............23
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
3. Extensions ......................................................5
3.1. Definitions, Requirements, and Constants ...................6
3.1.1. Required Algorithms .................................6
3.1.2. Recommended Algorithms ..............................6
3.1.3. Defined Message and Encryption Types ................7
3.1.4. Kerberos Encryption Types Defined for CMS
Algorithm Identifiers ...............................8
3.2. PKINIT Pre-authentication Syntax and Use ...................9
3.2.1. Generation of Client Request ........................9
3.2.2. Receipt of Client Request ..........................14
3.2.3. Generation of KDC Reply ............................18
3.2.3.1. Using Diffie-Hellman Key Exchange .........21
3.2.3.2. Using Public Key Encryption ...............23
3.2.4. Receipt of KDC Reply ...............................25
3.3. Interoperability Requirements .............................26
3.4. KDC Indication of PKINIT Support ..........................27
4. Security Considerations ........................................27
5. Acknowledgements ...............................................30
6. References .....................................................30
6.1. Normative References ......................................30
6.2. Informative References ....................................32
Appendix A. PKINIT ASN.1 Module ..................................33
Appendix B. Test Vectors .........................................38
Appendix C. Miscellaneous Information about Microsoft Windows
PKINIT Implementations ...............................40
3.2.4. Receipt of KDC Reply ...............................25
3.3. Interoperability Requirements .............................26
3.4. KDC Indication of PKINIT Support ..........................27
4. Security Considerations ........................................27
5. Acknowledgements ...............................................30
6. References .....................................................30
6.1. Normative References ......................................30
6.2. Informative References ....................................32
Appendix A. PKINIT ASN.1 Module ..................................33
Appendix B. Test Vectors .........................................38
Appendix C. Miscellaneous Information about Microsoft Windows
PKINIT Implementations ...............................40
The Kerberos V5 protocol [RFC4120] involves use of a trusted third party known as the Key Distribution Center (KDC) to negotiate shared session keys between clients and services and provide mutual authentication between them.
Kerberos V5协议[RFC4120]涉及到使用一个被称为密钥分发中心（KDC）的可信第三方来协商客户端和服务之间的共享会话密钥，并在它们之间提供相互身份验证。
The corner-stones of Kerberos V5 are the Ticket and the Authenticator. A Ticket encapsulates a symmetric key (the ticket session key) in an envelope (a public message) intended for a specific service. The contents of the Ticket are encrypted with a symmetric key shared between the service principal and the issuing KDC. The encrypted part of the Ticket contains the client principal name, among other items. An Authenticator is a record that can be shown to have been recently generated using the ticket session key in the associated Ticket. The ticket session key is known by the client who requested the ticket. The contents of the Authenticator are encrypted with the associated ticket session key. The encrypted part of an Authenticator contains a timestamp and the client principal name, among other items.
Kerberos V5的关键是票证和身份验证器。票证将对称密钥（票证会话密钥）封装在用于特定服务的信封（公共消息）中。票据的内容使用服务主体和发出KDC之间共享的对称密钥加密。票据的加密部分包含客户机主体名称以及其他项。使用最近生成的记录单可以在要关联的会话中显示。请求票证的客户端知道票证会话密钥。验证器的内容使用相关联的票证会话密钥加密。身份验证器的加密部分包含时间戳和客户机主体名称等项。
As shown in Figure 1, below, the Kerberos V5 protocol consists of the following message exchanges between the client and the KDC, and the client and the application service:
如下图1所示，Kerberos V5协议由客户端和KDC、客户端和应用程序服务之间的以下消息交换组成：
- The Authentication Service (AS) Exchange
- 身份验证服务（AS）交换
The client obtains an "initial" ticket from the Kerberos authentication server (AS), typically a Ticket Granting Ticket (TGT). The AS-REQ message and the AS-REP message are the request and the reply message, respectively, between the client and the AS.
客户端从Kerberos身份验证服务器（AS）获得“初始”票证，通常是票证授予票证（TGT）。AS-REQ消息和AS-REP消息分别是客户端和AS之间的请求和应答消息。
- The Ticket Granting Service (TGS) Exchange
- 票务授予服务（TGS）交换
The client subsequently uses the TGT to authenticate and request a service ticket for a particular service, from the Kerberos ticket-granting server (TGS). The TGS-REQ message and the TGS-REP message are the request and the reply message respectively between the client and the TGS.
客户端随后使用TGT从Kerberos票证授予服务器（TGS）验证并请求特定服务的服务票证。TGS-REQ消息和TGS-REP消息分别是客户端和TGS之间的请求和应答消息。
- The Client/Server Authentication Protocol (AP) Exchange
- 客户端/服务器身份验证协议（AP）交换
The client then makes a request with an AP-REQ message, consisting of a service ticket and an authenticator that certifies the client's possession of the ticket session key. The server may optionally reply with an AP-REP message. AP exchanges typically negotiate session-specific symmetric keys.
然后，客户端使用AP-REQ消息发出请求，该消息由服务票证和认证客户端拥有票证会话密钥的验证器组成。服务器可以选择使用AP-REP消息进行回复。AP交换通常协商特定于会话的对称密钥。
Usually, the AS and TGS are integrated in a single device also known as the KDC.
通常，AS和TGS集成在一个设备（也称为KDC）中。
+--------------+
+--------->| KDC |
AS-REQ / +-------| |
/ / +--------------+
/ / ^ |
/ |AS-REP / |
| | / TGS-REQ + TGS-REP
| | / /
| | / /
| | / +---------+
| | / /
| | / /
| | / /
| v / v
++-------+------+ +-----------------+
| Client +------------>| Application |
| | AP-REQ | Server |
| |<------------| |
+---------------+ AP-REP +-----------------+
+--------------+
+--------->| KDC |
AS-REQ / +-------| |
/ / +--------------+
/ / ^ |
/ |AS-REP / |
| | / TGS-REQ + TGS-REP
| | / /
| | / /
| | / +---------+
| | / /
| | / /
| | / /
| v / v
++-------+------+ +-----------------+
| Client +------------>| Application |
| | AP-REQ | Server |
| |<------------| |
+---------------+ AP-REP +-----------------+
Figure 1: The Message Exchanges in the Kerberos V5 Protocol
图1:Kerberos V5协议中的消息交换
In the AS exchange, the KDC reply contains the ticket session key, among other items, that is encrypted using a key (the AS reply key) shared between the client and the KDC. The AS reply key is typically derived from the client's password for human users. Therefore, for human users, the attack resistance strength of the Kerberos protocol is no stronger than the strength of their passwords.
在AS交换中，KDC应答包含票证会话密钥以及其他项，该密钥使用客户端和KDC之间共享的密钥（AS应答密钥）进行加密。AS应答密钥通常是从客户机的人工用户密码派生的。因此，对于人类用户来说，Kerberos协议的抗攻击强度并不比其密码的强度强。
The use of asymmetric cryptography in the form of X.509 certificates [RFC3280] is popular for facilitating data origin authentication and perfect secrecy. An established Public Key Infrastructure (PKI) provides key management and key distribution mechanisms that can be used to establish authentication and secure communication. Adding public-key cryptography to Kerberos provides a nice congruence to public-key protocols, obviates the human users' burden to manage strong passwords, and allows Kerberized applications to take advantage of existing key services and identity management.
X.509证书[RFC3280]形式的非对称加密技术的使用非常流行，以促进数据源身份验证和完全保密。已建立的公钥基础设施（PKI）提供了可用于建立身份验证和安全通信的密钥管理和密钥分发机制。将公钥加密添加到Kerberos中，可以很好地与公钥协议保持一致，避免了人类用户管理强密码的负担，并允许Kerberized应用程序利用现有的密钥服务和身份管理。
The advantage afforded by the Kerberos TGT is that the client exposes his long-term secrets only once. The TGT and its associated session key can then be used for any subsequent service ticket requests. One result of this is that all further authentication is independent of the method by which the initial authentication was performed. Consequently, initial authentication provides a convenient place to integrate public-key cryptography into Kerberos authentication. In addition, the use of symmetric cryptography after the initial exchange is preferred for performance.
Kerberos-TGT提供的优点是，客户机只公开其长期秘密一次。然后，TGT及其相关会话密钥可用于任何后续服务票证请求。这样做的一个结果是，所有进一步的身份验证都独立于执行初始身份验证的方法。因此，初始身份验证为将公钥加密集成到Kerberos身份验证中提供了一个方便的地方。此外，出于性能考虑，在初始交换之后使用对称加密是首选。
This document describes the methods and data formats using which the client and the KDC can use public and private key pairs to mutually authenticate in the AS exchange and negotiate the AS reply key, known only by the client and the KDC, to encrypt the AS-REP sent by the KDC.
本文档描述了客户机和KDC可以使用公钥和私钥对在AS交换中相互验证并协商AS应答密钥（只有客户机和KDC知道）以加密KDC发送的AS-REP的方法和数据格式。
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]中所述进行解释。
In this protocol, both the client and the KDC have a public-private key pair in order to prove their identities to each other over the open network. The term "signature key" is used to refer to the private key of the key pair being used.
在该协议中，客户机和KDC都有一个公私密钥对，以便在开放网络上相互证明其身份。术语“签名密钥”用于指正在使用的密钥对的私钥。
The encryption key used to encrypt the enc-part field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS reply key.
用于加密AS-REP[RFC4120]中KDC-REP的enc部分字段的加密密钥称为AS应答密钥。
An empty sequence in an optional field can be either included or omitted: both encodings are permitted and considered equivalent.
可选字段中的空序列可以包含或省略：两种编码都是允许的，并且被认为是等效的。
The term "Modular Exponential Diffie-Hellman" is used to refer to the Diffie-Hellman key exchange, as described in [RFC2631], in order to differentiate it from other equivalent representations of the same key agreement algorithm.
术语“模指数Diffie-Hellman”用于指Diffie-Hellman密钥交换，如[RFC2631]中所述，以区别于相同密钥协商算法的其他等效表示。
This section describes extensions to [RFC4120] for supporting the use of public-key cryptography in the initial request for a ticket.
本节介绍对[RFC4120]的扩展，以支持在初始票证请求中使用公钥加密。
Briefly, this document defines the following extensions to [RFC4120]:
简单地说，本文档定义了[RFC4120]的以下扩展：
1. The client indicates the use of public-key authentication by including a special preauthenticator in the initial request. This preauthenticator contains the client's public-key data and a signature.
1. 客户端通过在初始请求中包含特殊的预身份验证程序来指示公钥身份验证的使用。此预身份验证程序包含客户端的公钥数据和签名。
2. The KDC tests the client's request against its authentication policy and trusted Certification Authorities (CAs).
2. KDC根据其身份验证策略和可信证书颁发机构（CA）测试客户端的请求。
3. If the request passes the verification tests, the KDC replies as usual, but the reply is encrypted using either:
3. 如果请求通过了验证测试，KDC将照常回复，但回复将使用以下任一方式进行加密：
a. a key generated through a Diffie-Hellman (DH) key exchange [RFC2631] [IEEE1363] with the client, signed using the KDC's signature key; or
a. 通过与客户端的Diffie-Hellman（DH）密钥交换[RFC2631][IEEE1363]生成的密钥，使用KDC的签名密钥签名；或
b. a symmetric encryption key, signed using the KDC's signature key and encrypted using the client's public key.
b. 一种对称加密密钥，使用KDC的签名密钥签名，并使用客户端的公钥加密。
Any keying material required by the client to obtain the encryption key for decrypting the KDC reply is returned in a pre-authentication field accompanying the usual reply.
客户机获取用于解密KDC回复的加密密钥所需的任何密钥材料都会在通常回复的预验证字段中返回。
4. The client validates the KDC's signature, obtains the encryption key, decrypts the reply, and then proceeds as usual.
4. 客户端验证KDC的签名，获得加密密钥，解密回复，然后照常进行。
Section 3.1 of this document enumerates the required algorithms and necessary extension message types. Section 3.2 describes the extension messages in greater detail.
本文件第3.1节列举了所需的算法和必要的扩展消息类型。第3.2节更详细地描述了扩展消息。
All PKINIT implementations MUST support the following algorithms:
所有PKINIT实现必须支持以下算法：
o AS reply key enctypes: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 [RFC3962].
o 作为应答密钥加密类型：aes128-cts-hmac-sha1-96和aes256-cts-hmac-sha1-96[RFC3962]。
o Signature algorithm: sha-1WithRSAEncryption [RFC3370].
o 签名算法：使用RSA加密的sha-1[RFC3370]。
o AS reply key delivery method: the Diffie-Hellman key delivery method, as described in Section 3.2.3.1.
o AS应答密钥交付方法：Diffie-Hellman密钥交付方法，如第3.2.3.1节所述。
In addition, implementations of this specification MUST be capable of processing the Extended Key Usage (EKU) extension and the id-pkinit-san (as defined in Section 3.2.2) otherName of the Subject Alternative Name (SAN) extension in X.509 certificates [RFC3280].
此外，本规范的实现必须能够处理扩展密钥使用（EKU）扩展和X.509证书[RFC3280]中主体替代名称（san）扩展的id pkinit san（如第3.2.2节所定义）。
All PKINIT implementations SHOULD support the following algorithm:
所有PKINIT实现都应支持以下算法：
o AS reply key delivery method: the public key encryption key delivery method, as described in Section 3.2.3.2.
o AS应答密钥传递方法：公钥加密密钥传递方法，如第3.2.3.2节所述。
For implementations that support the public key encryption key delivery method, the following algorithms MUST be supported:
对于支持公钥加密密钥传递方法的实现，必须支持以下算法：
a) Key transport algorithms identified in the keyEncryptionAlgorithm field of the type KeyTransRecipientInfo [RFC3852] for encrypting the temporary key in the encryptedKey field [RFC3852] with a public key, as described in Section 3.2.3.2: rsaEncryption (this is the RSAES-PKCS1-v1_5 encryption scheme) [RFC3370] [RFC3447].
a) KeyTransRecipientInfo[RFC3852]类型的keyEncryptionAlgorithm字段中识别的密钥传输算法，用于使用公钥加密encryptedKey字段[RFC3852]中的临时密钥，如第3.2.3.2节：RSAEncyption（这是RSAES-PKCS1-v1_5加密方案）[RFC3370 RFC3447]所述。
b) Content encryption algorithms identified in the contentEncryptionAlgorithm field of the type EncryptedContentInfo [RFC3852] for encrypting the AS reply key with the temporary key contained in the encryptedKey field of the type KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2: des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
b) EncryptedContentInfo[RFC3852]类型的contentEncryptionAlgorithm字段中标识的内容加密算法，用于使用KeyTransRecipientInfo[RFC3852]类型的encryptedKey字段中包含的临时密钥加密AS应答密钥，如第3.2.3.2节：des-ede3-cbc（三密钥3DES，cbc模式）[RFC3370]所述。
PKINIT makes use of the following new pre-authentication types:
PKINIT使用以下新的预身份验证类型：
PA_PK_AS_REQ 16 PA_PK_AS_REP 17
PA_PK_AS_REQ 16 PA_PK_AS_REP 17
PKINIT also makes use of the following new authorization data type:
PKINIT还使用以下新的授权数据类型：
AD_INITIAL_VERIFIED_CAS 9
AD_初始\u验证\u CAS 9
PKINIT introduces the following new error codes:
PKINIT引入了以下新的错误代码：
KDC_ERR_CLIENT_NOT_TRUSTED 62 KDC_ERR_INVALID_SIG 64 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 KDC_ERR_INVALID_CERTIFICATE 71 KDC_ERR_REVOKED_CERTIFICATE 72 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 KDC_ERR_CLIENT_NAME_MISMATCH 75 KDC_ERR_INCONSISTENT_KEY_PURPOSE 77 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78 KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80 KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
KDC错误客户端不可信62 KDC错误无效签名64 KDC错误密钥参数不被接受65 KDC错误客户端无法验证证书70 KDC错误无效证书71 KDC错误撤销证书72 KDC错误撤销状态未知73 KDC错误客户端名称不匹配75 KDC错误不一致密钥目的77 KDC错误摘要未被接受KDC错误校验和必须包含79 KDC错误摘要数据不接受80 KDC错误公钥加密不支持81
PKINIT uses the following typed data types for errors:
PKINIT对错误使用以下类型化数据类型：
TD_TRUSTED_CERTIFIERS 104 TD_INVALID_CERTIFICATES 105 TD_DH_PARAMETERS 109
TD_可信证明人104 TD_无效证明105 TD_DH_参数109
The ASN.1 module for all structures defined in this document (plus IMPORT statements for all imported structures) is given in Appendix A.
附录A中给出了本文件中定义的所有结构的ASN.1模块（以及所有导入结构的导入声明）。
All structures defined in or imported into this document MUST be encoded using Distinguished Encoding Rules (DER) [X680] [X690] (unless otherwise noted). All data structures carried in OCTET STRINGs MUST be encoded according to the rules specified in the specifications defining each data structure; a reference to the appropriate specification is provided for each data structure.
本文件中定义或导入的所有结构必须使用可分辨编码规则（DER）[X680][X690]进行编码（除非另有说明）。必须根据定义每个数据结构的规范中规定的规则对八位字节字符串中的所有数据结构进行编码；每个数据结构都提供了相应规范的参考。
Interoperability note: Some implementations may not be able to decode wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded with BER; specifically, they may not be able to decode indefinite-length encodings. To maximize interoperability, implementers SHOULD encode CMS objects used in PKINIT with DER.
互操作性说明：某些实现可能无法解码用BER编码的包装加密消息语法（CMS）[RFC3852]对象；具体来说，他们可能无法解码无限长编码。为了最大限度地提高互操作性，实现者应该使用DER对PKINIT中使用的CMS对象进行编码。
PKINIT defines the following Kerberos encryption type numbers
[RFC3961], which can be used in the etype field of the AS-REQ
[RFC4120] message to indicate to the KDC the client's acceptance of
the corresponding algorithms (including key transport algorithms
[RFC3370], content encryption algorithms [RFC3370], and signature
algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
[RFC3370].
PKINIT defines the following Kerberos encryption type numbers
[RFC3961], which can be used in the etype field of the AS-REQ
[RFC4120] message to indicate to the KDC the client's acceptance of
the corresponding algorithms (including key transport algorithms
[RFC3370], content encryption algorithms [RFC3370], and signature
algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
[RFC3370].
Per [RFC4120], the encryption types in the etype field are in the decreasing preference order of the client. Note that there is no significance in the relative order between any two of different types of algorithms: key transport algorithms, content encryption algorithms, and signature algorithms.
根据[RFC4120]，etype字段中的加密类型按客户机的优先顺序递减。请注意，任何两种不同类型的算法（密钥传输算法、内容加密算法和签名算法）之间的相对顺序没有意义。
The presence of each of these encryption types in the etype field is equivalent to the presence of the corresponding algorithm Object Identifier (OID) in the supportedCMSTypes field as described in Section 3.2.1. And the preference order expressed in the supportedCMSTypes field would override the preference order listed in the etype field.
etype字段中出现的每种加密类型等同于supportedCMSTypes字段中出现的相应算法对象标识符（OID），如第3.2.1节所述。并且supportedCMSTypes字段中表示的优先顺序将覆盖etype字段中列出的优先顺序。
Kerberos Encryption Type Name Num Corresponding Algorithm OID
============================== === ===============================
id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3370]
md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3370]
sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3370]
rc2-cbc-EnvOID 12 rc2-cbc [RFC3370]
rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3370]
id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3560]
des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370]
Kerberos Encryption Type Name Num Corresponding Algorithm OID
============================== === ===============================
id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3370]
md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3370]
sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3370]
rc2-cbc-EnvOID 12 rc2-cbc [RFC3370]
rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3370]
id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3560]
des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370]
The above encryption type numbers are used only to indicate support for the use of the corresponding algorithms in PKINIT; they do not correspond to actual Kerberos encryption types [RFC3961] and MUST NOT be used in the etype field of the Kerberos EncryptedData type [RFC4120]. The practice of assigning Kerberos encryption type numbers to indicate support for CMS algorithms is considered deprecated, and new numbers should not be assigned for this purpose. Instead, the supportedCMSTypes field should be used to identify the algorithms supported by the client and the preference order of the client.
上述加密类型编号仅用于表示支持在PKINIT中使用相应的算法；它们与实际的Kerberos加密类型[RFC3961]不对应，并且不得在Kerberos EncryptedData类型[RFC4120]的etype字段中使用。分配Kerberos加密类型编号以表示支持CMS算法的做法被认为是不推荐的，因此不应为此目的分配新编号。相反，应使用supportedCMSTypes字段来标识客户端支持的算法和客户端的首选顺序。
For maximum interoperability, however, PKINIT clients wishing to indicate to the KDC the support for one or more of the algorithms listed above SHOULD include the corresponding encryption type number(s) in the etype field of the AS-REQ.
然而，为了实现最大的互操作性，希望向KDC指示对上述一种或多种算法的支持的PKINIT客户端应在AS-REQ的etype字段中包含相应的加密类型号。
This section defines the syntax and use of the various pre-authentication fields employed by PKINIT.
本节定义了PKINIT使用的各种预验证字段的语法和用法。
The initial authentication request (AS-REQ) is sent as per [RFC4120]; in addition, a pre-authentication data element, whose padata-type is PA_PK_AS_REQ and whose padata-value contains the DER encoding of the type PA-PK-AS-REQ, is included.
初始认证请求（AS-REQ）按照[RFC4120]发送；此外，还包括预认证数据元素，其padata类型为PA_PK_AS_REQ，其padata值包含PA-PK-AS-REQ类型的DER编码。
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the
-- type AuthPack.
-- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL,
-- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
-- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the
-- type AuthPack.
-- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL,
-- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
-- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as
-- hints to guide its selection of an appropriate
-- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852].
-- Identifies, if present, a particular KDC
-- public key that the client already has.
...
}
-- hints to guide its selection of an appropriate
-- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852].
-- Identifies, if present, a particular KDC
-- public key that the client already has.
...
}
DHNonce ::= OCTET STRING
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a PKIX type Name encoded according to
-- [RFC3280].
-- Identifies the certificate subject by the
-- distinguished subject name.
-- REQUIRED when there is a distinguished subject
-- name present in the certificate.
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a CMS type IssuerAndSerialNumber encoded
-- according to [RFC3852].
-- Identifies a certificate of the subject.
-- REQUIRED for TD-INVALID-CERTIFICATES and
-- TD-TRUSTED-CERTIFIERS.
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
-- Identifies the subject's public key by a key
-- identifier. When an X.509 certificate is
-- referenced, this key identifier matches the X.509
-- subjectKeyIdentifier extension value. When other
-- certificate formats are referenced, the documents
-- that specify the certificate format and their use
-- with the CMS must include details on matching the
-- key identifier to the appropriate certificate
-- field.
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
...
}
ExternalPrincipalIdentifier ::= SEQUENCE {
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a PKIX type Name encoded according to
-- [RFC3280].
-- Identifies the certificate subject by the
-- distinguished subject name.
-- REQUIRED when there is a distinguished subject
-- name present in the certificate.
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a CMS type IssuerAndSerialNumber encoded
-- according to [RFC3852].
-- Identifies a certificate of the subject.
-- REQUIRED for TD-INVALID-CERTIFICATES and
-- TD-TRUSTED-CERTIFIERS.
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
-- Identifies the subject's public key by a key
-- identifier. When an X.509 certificate is
-- referenced, this key identifier matches the X.509
-- subjectKeyIdentifier extension value. When other
-- certificate formats are referenced, the documents
-- that specify the certificate format and their use
-- with the CMS must include details on matching the
-- key identifier to the appropriate certificate
-- field.
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in
-- [RFC3280].
-- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363].
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in
-- [RFC3280].
-- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363].
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
-- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- Type AlgorithmIdentifier is defined in
-- [RFC3280].
-- List of CMS algorithm [RFC3370] identifiers
-- that identify key transport algorithms, or
-- content encryption algorithms, or signature
-- algorithms supported by the client in order of
-- (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it
-- wishes to reuse DH keys or to allow the KDC to
-- do so (see Section 3.2.3.1).
...
}
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
-- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- Type AlgorithmIdentifier is defined in
-- [RFC3280].
-- List of CMS algorithm [RFC3370] identifiers
-- that identify key transport algorithms, or
-- content encryption algorithms, or signature
-- algorithms supported by the client in order of
-- (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it
-- wishes to reuse DH keys or to allow the KDC to
-- do so (see Section 3.2.3.1).
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for
-- replay prevention.
nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present.
-- Contains the SHA1 checksum, performed over
-- KDC-REQ-BODY.
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for
-- replay prevention.
nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present.
-- Contains the SHA1 checksum, performed over
-- KDC-REQ-BODY.
...
}
The ContentInfo [RFC3852] structure contained in the signedAuthPack field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and is filled out as follows:
PA-PK-AS-REQ类型的signedAuthPack字段中包含的ContentInfo[RFC3852]结构根据[RFC3852]进行编码，并按如下方式填写：
1. The contentType field of the type ContentInfo is id-signedData (as defined in [RFC3852]), and the content field is a SignedData (as defined in [RFC3852]).
1. ContentInfo类型的contentType字段是id signedData（定义见[RFC3852]），而内容字段是signedData（定义见[RFC3852]）。
2. The eContentType field for the type SignedData is id-pkinit-authData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS implementers: the signed attribute content-type MUST be present in this SignedData instance, and its value is id-pkinit-authData according to [RFC3852].
2. SignedData类型的eContentType字段是id pkinit authData:{iso（1）org（3）dod（6）internet（1）security（5）kerberosv5（2）pkinit（3）authData（1）}。CMS实施者注意：根据[RFC3852]，签名属性内容类型必须存在于该SignedData实例中，其值为id pkinit authData。
3. The eContent field for the type SignedData contains the DER encoding of the type AuthPack.
3. SignedData类型的eContent字段包含AuthPack类型的DER编码。
4. The signerInfos field of the type SignedData contains a single signerInfo, which contains the signature over the type AuthPack.
4. SignedData类型的signerInfos字段包含单个signerInfo，其中包含AuthPack类型上的签名。
5. The AuthPack structure contains a PKAuthenticator, the client public key information, the CMS encryption types supported by the client, and a DHNonce. The pkAuthenticator field certifies to the KDC that the client has recent knowledge of the signing key that authenticates the client. The clientPublicValue field specifies Diffie-Hellman domain parameters and the client's public key value. The DH public key value is encoded as a BIT STRING according to [RFC3279]. The clientPublicValue field is present only if the client wishes to use the Diffie-Hellman key agreement method. The supportedCMSTypes field specifies the list of CMS algorithm identifiers that are supported by the client in order of (decreasing) preference, and can be used to identify a signature algorithm or a key transport algorithm [RFC3370] in the keyEncryptionAlgorithm field of the type KeyTransRecipientInfo, or a content encryption algorithm [RFC3370] in the contentEncryptionAlgorithm field of the type EncryptedContentInfo [RFC3852] when encrypting the AS reply key as described in Section 3.2.3.2. However, there is no significance in the relative order between any two of different types of algorithms: key transport algorithms, content encryption algorithms, and signature algorithms. The clientDHNonce field is described later in this section.
5. AuthPack结构包含PKAuthenticator、客户端公钥信息、客户端支持的CMS加密类型和DHONCE。pkAuthenticator字段向KDC证明客户端最近知道用于对客户端进行身份验证的签名密钥。clientPublicValue字段指定Diffie Hellman域参数和客户端的公钥值。DH公钥值根据[RFC3279]编码为位字符串。只有当客户端希望使用Diffie-Hellman密钥协商方法时，才会出现clientPublicValue字段。supportedCMSTypes字段指定客户端按（减少）偏好顺序支持的CMS算法标识符列表，可用于识别KeyTransRecipientInfo类型的keyEncryptionAlgorithm字段中的签名算法或密钥传输算法[RFC3370]，或内容加密算法[RFC3370]如第3.2.3.2节所述，加密AS应答密钥时，在EncryptedContentInfo[RFC3852]类型的contentEncryptionAlgorithm字段中。但是，任何两种不同类型的算法（密钥传输算法、内容加密算法和签名算法）之间的相对顺序都没有意义。ClientDhnoce字段将在本节后面介绍。
6. The ctime field in the PKAuthenticator structure contains the current time on the client's host, and the cusec field contains the microsecond part of the client's timestamp. The ctime and cusec fields are used together to specify a reasonably accurate timestamp [RFC4120]. The nonce field is chosen randomly. The paChecksum field MUST be present and it contains a SHA1 checksum that is performed over the KDC-REQ-BODY [RFC4120]. In order to ease future migration from the use of SHA1, the paChecksum field is made optional syntactically: when the request is extended to negotiate hash algorithms, the new client wishing not to use SHA1 will send the request in the extended message syntax without the paChecksum field. The KDC conforming to this specification MUST
6. PKAuthenticator结构中的ctime字段包含客户端主机上的当前时间，cusec字段包含客户端时间戳的微秒部分。ctime和cusec字段一起用于指定合理准确的时间戳[RFC4120]。nonce字段是随机选择的。paChecksum字段必须存在，并且它包含通过KDC-REQ-BODY[RFC4120]执行的SHA1校验和。为了便于将来从SHA1的使用中迁移，paChecksum字段在语法上是可选的：当请求扩展到协商哈希算法时，希望不使用SHA1的新客户端将以扩展消息语法发送请求，而不使用paChecksum字段。符合本规范的KDC必须
return a KRB-ERROR [RFC4120] message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3). That will allow a new client to retry with SHA1 if allowed by the local policy.
返回KRB-ERROR[RFC4120]消息，其中代码KDC_ERR_PA_CHECKSUM_必须包含在内（参见第3.2.3节）。这将允许新客户端在本地策略允许的情况下使用SHA1重试。
7. The certificates field of the type SignedData contains certificates intended to facilitate certification path construction, so that the KDC can verify the signature over the type AuthPack. For path validation, these certificates SHOULD be sufficient to construct at least one certification path from the client certificate to one trust anchor acceptable by the KDC [RFC4158]. The client MUST be capable of including such a set of certificates if configured to do so. The certificates field MUST NOT contain "root" CA certificates.
7. SignedData类型的certificates字段包含旨在促进证书路径构造的证书，以便KDC可以通过AuthPack类型验证签名。对于路径验证，这些证书应足以构造至少一条从客户端证书到KDC可接受的一个信任锚的认证路径[RFC4158]。如果配置为这样做，客户端必须能够包含这样一组证书。证书字段不能包含“根”CA证书。
8. The client's Diffie-Hellman public value (clientPublicValue) is included if and only if the client wishes to use the Diffie-Hellman key agreement method. The Diffie-Hellman domain parameters [IEEE1363] for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279], and the client's Diffie-Hellman public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279]. When using the Diffie-Hellman key agreement method, implementations MUST support Oakley 1024-bit Modular Exponential (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit MODP well-known group 16 [RFC3526].
8. 当且仅当客户希望使用Diffie-Hellman密钥协议方法时，才包括客户的Diffie-Hellman公共值（clientPublicValue）。客户机公钥的Diffie-Hellman域参数[IEEE1363]在SubjectPublicKeyInfo[RFC3279]类型的算法字段中指定，客户机的Diffie-Hellman公钥值根据[RFC3279]映射到subjectPublicKey（位字符串）。使用Diffie-Hellman密钥协商方法时，实现必须支持Oakley 1024位模块化指数（MODP）已知组2[RFC2412]和Oakley 2048位MODP已知组14[RFC3526]，并应支持Oakley 4096位MODP已知组16[RFC3526]。
The Diffie-Hellman field size should be chosen so as to provide sufficient cryptographic security [RFC3766].
应选择Diffie-Hellman字段大小，以便提供足够的加密安全性[RFC3766]。
When MODP Diffie-Hellman is used, the exponents should have at least twice as many bits as the symmetric keys that will be derived from them [ODL99].
当使用MODP Diffie-Hellman时，指数的位数应至少是从其派生的对称密钥的两倍[ODL99]。
9. The client may wish to reuse DH keys or to allow the KDC to do so (see Section 3.2.3.1). If so, then the client includes the clientDHNonce field. This nonce string MUST be as long as the longest key length of the symmetric key types that the client supports. This nonce MUST be chosen randomly.
9. 客户可能希望重用DH密钥或允许KDC这样做（见第3.2.3.1节）。如果是，则客户端包括clientDHNonce字段。此nonce字符串的长度必须与客户端支持的对称密钥类型的最长密钥长度相同。必须随机选择此nonce。
The ExternalPrincipalIdentifier structure is used in this document to identify the subject's public key thereby the subject principal. This structure is filled out as follows:
本文档中使用ExternalPrincipaliIdentifier结构来识别主体的公钥，从而识别主体主体。该结构填写如下：
1. The subjectName field contains a PKIX type Name encoded according to [RFC3280]. This field identifies the certificate subject by the distinguished subject name. This field is REQUIRED when
1. subjectName字段包含根据[RFC3280]编码的PKIX类型名称。此字段通过可分辨主题名称标识证书主题。在以下情况下，此字段为必填字段：
there is a distinguished subject name present in the certificate being used.
正在使用的证书中存在可分辨的使用者名称。
2. The issuerAndSerialNumber field contains a CMS type IssuerAndSerialNumber encoded according to [RFC3852]. This field identifies a certificate of the subject. This field is REQUIRED for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both structures are defined in Section 3.2.2).
2. issuerAndSerialNumber字段包含根据[RFC3852]编码的CMS类型issuerAndSerialNumber。此字段标识主题的证书。TD-INVALID-CERTIFICATES和TD-TRUSTED-certifier需要此字段（这两种结构在第3.2.2节中定义）。
3. The subjectKeyIdentifier [RFC3852] field identifies the subject's public key by a key identifier. When an X.509 certificate is referenced, this key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. This field is RECOMMENDED for TD-TRUSTED-CERTIFIERS (as defined in Section 3.2.2).
3. subjectKeyIdentifier[RFC3852]字段通过密钥标识符标识主题的公钥。引用X.509证书时，此密钥标识符与X.509 subjectKeyIdentifier扩展值匹配。当引用其他证书格式时，指定证书格式及其在CMS中的使用的文档必须包括有关将密钥标识符匹配到相应证书字段的详细信息。建议TD-TRUSTED-CERTIFIERS使用此字段（如第3.2.2节所定义）。
The trustedCertifiers field of the type PA-PK-AS-REQ contains a list of CAs, trusted by the client, that can be used to certify the KDC. Each ExternalPrincipalIdentifier identifies a CA or a CA certificate (thereby its public key).
PA-PK-AS-REQ类型的trustedCertifiers字段包含客户机信任的CA列表，可用于认证KDC。每个ExternalPrincipalIdentifier标识CA或CA证书（从而标识其公钥）。
The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type SignerIdentifier encoded according to [RFC3852]. This field identifies, if present, a particular KDC public key that the client already has.
PA-PK-AS-REQ类型的kdcPkId字段包含根据[RFC3852]编码的CMS类型签名标识符。此字段标识客户端已经拥有的特定KDC公钥（如果存在）。
Upon receiving the client's request, the KDC validates it. This section describes the steps that the KDC MUST (unless otherwise noted) take in validating the request.
收到客户机请求后，KDC将对其进行验证。本节描述KDC在验证请求时必须采取的步骤（除非另有说明）。
The KDC verifies the client's signature in the signedAuthPack field according to [RFC3852].
KDC根据[RFC3852]在signedAuthPack字段中验证客户端的签名。
If, while validating the client's X.509 certificate [RFC3280], the KDC cannot build a certification path to validate the client's certificate, it sends back a KRB-ERROR [RFC4120] message with the code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this error message is a TYPED-DATA (as defined in [RFC4120]) that contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data-value contains the DER encoding of the type TD-TRUSTED-CERTIFIERS:
如果在验证客户机的X.509证书[RFC3280]时，KDC无法构建验证客户机证书的证书路径，则会发回一条KRB-ERROR[RFC4120]消息，代码为KDC_ERR_CANT_VERIFY_certificate。此错误消息附带的电子数据是类型化数据（如[RFC4120]中定义），其中包含数据类型为TD_TRUSTED_CERTIFIERS的元素，其数据值包含TD-TRUSTED-CERTIFIERS类型的DER编码：
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate (thereby its public key) trusted by the KDC.
TD-TRUSTED-CERTIFIERS结构中的每个ExternalPrincipalIdentifier（定义见第3.2.1节）标识KDC信任的CA或CA证书（从而标识其公钥）。
Upon receiving this error message, the client SHOULD retry only if it has a different set of certificates (from those of the previous requests) that form a certification path (or a partial path) from one of the trust anchors acceptable by the KDC to its own certificate.
收到此错误消息后，只有当客户端具有不同的证书集（与以前请求的证书集不同）时，客户端才应重试，这些证书集形成了从KDC可接受的信任锚之一到其自己的证书的证书路径（或部分路径）。
If, while processing the certification path, the KDC determines that the signature on one of the certificates in the signedAuthPack field is invalid, it returns a KRB-ERROR [RFC4120] message with the code KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error message is a TYPED-DATA that contains an element whose data-type is TD_INVALID_CERTIFICATES, and whose data-value contains the DER encoding of the type TD-INVALID-CERTIFICATES:
如果在处理证书路径时，KDC确定signedAuthPack字段中一个证书上的签名无效，它将返回一条KRB-ERROR[RFC4120]消息，代码为KDC_ERR_invalid_CERTIFICATE。此错误消息附带的电子数据是类型化数据，其中包含数据类型为TD_INVALID_CERTIFICATES的元素，其数据值包含TD-INVALID-CERTIFICATES类型的DER编码：
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid
-- signature.
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid
-- signature.
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the TD-INVALID-CERTIFICATES structure identifies a certificate (that was sent by the client) with an invalid signature.
TD-INVALID-CERTIFICATES结构中的每个ExternalPrincipalIdentifier（如第3.2.1节中的定义）标识一个具有无效签名的证书（由客户端发送）。
If more than one X.509 certificate signature is invalid, the KDC MAY include one IssuerAndSerialNumber per invalid signature within the TD-INVALID-CERTIFICATES.
如果一个以上的X.509证书签名无效，KDC可能会在TD-invalid-CERTIFICATES中为每个无效签名包含一个IssuerAndSerialNumber。
The client's X.509 certificate is validated according to [RFC3280].
客户的X.509证书根据[RFC3280]进行验证。
Depending on local policy, the KDC may also check whether any X.509 certificates in the certification path validating the client's certificate have been revoked. If any of them have been revoked, the KDC MUST return an error message with the code KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the revocation status but is unable to do so, it SHOULD return an error message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or certificates affected are identified exactly as for the error code KDC_ERR_INVALID_CERTIFICATE (see above).
根据本地策略，KDC还可以检查验证客户端证书的证书路径中是否有任何X.509证书已被吊销。如果其中任何一个证书已被吊销，KDC必须返回一条错误消息，代码为KDC_ERR_reversed_CERTIFICATE；如果KDC试图确定吊销状态，但无法确定，则应返回一条错误消息，代码为KDC_ERR_revocation_status_UNKNOWN。受影响的一个或多个证书的标识与错误代码KDC_ERR_INVALID_certificate（见上文）的标识完全相同。
Note that the TD_INVALID_CERTIFICATES error data is only used to identify invalid certificates sent by the client in the request.
请注意，TD_INVALID_CERTIFICATES错误数据仅用于标识请求中客户端发送的无效证书。
The client's public key is then used to verify the signature. If the signature fails to verify, the KDC MUST return an error message with the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error message.
然后使用客户机的公钥来验证签名。如果签名无法验证，KDC必须返回一条错误消息，代码为KDC_ERR_INVALID_SIG。此错误消息没有附带的电子数据。
In addition to validating the client's signature, the KDC MUST also check that the client's public key used to verify the client's signature is bound to the client principal name specified in the AS-REQ as follows:
除了验证客户端签名外，KDC还必须检查用于验证客户端签名的客户端公钥是否绑定到AS-REQ中指定的客户端主体名称，如下所示：
1. If the KDC has its own binding between either the client's signature-verification public key or the client's certificate and the client's Kerberos principal name, it uses that binding.
1. 如果KDC在客户机的签名验证公钥或客户机的证书与客户机的Kerberos主体名称之间有自己的绑定，它将使用该绑定。
2. Otherwise, if the client's X.509 certificate contains a Subject Alternative Name (SAN) extension carrying a KRB5PrincipalName (defined below) in the otherName field of the type GeneralName [RFC3280], it binds the client's X.509 certificate to that name.
2. 否则，如果客户端的X.509证书包含一个Subject Alternative Name（SAN）扩展名，该扩展名在GeneralName[RFC3280]类型的otherName字段中包含一个Krb5 PrincipalName（定义如下），则它会将客户端的X.509证书绑定到该名称。
The type of the otherName field is AnotherName. The type-id field of the type AnotherName is id-pkinit-san:
otherName字段的类型为另一个名称。另一个名称类型的类型id字段是id pkinit san:
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
And the value field of the type AnotherName is a KRB5PrincipalName.
类型AnotherName的值字段是一个krb5 PrincipalName。
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
If the Kerberos client name in the AS-REQ does not match a name bound by the KDC (the binding can be in the certificate, for example, as described above), or if there is no binding found by the KDC, the KDC MUST return an error message with the code KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for this error message.
如果AS-REQ中的Kerberos客户端名称与KDC绑定的名称不匹配（绑定可以在证书中，例如，如上所述），或者如果KDC未找到绑定，KDC必须返回错误消息，代码为KDC_ERR_client_name_MISMATCH。此错误消息没有附带的电子数据。
Even if the certification path is validated and the certificate is mapped to the client's principal name, the KDC may decide not to accept the client's certificate, depending on local policy.
即使验证了证书路径并将证书映射到客户端的主体名称，KDC也可能决定不接受客户端的证书，具体取决于本地策略。
The KDC MAY require the presence of an Extended Key Usage (EKU) KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field of the client's X.509 certificate:
KDC可能要求在客户端的X.509证书的扩展字段中存在扩展密钥使用（EKU）KeyPurposeId[RFC3280]id pkinit KPClientAuth：
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeClientAuth(4) }
-- PKINIT client authentication.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeClientAuth(4) }
-- PKINIT client authentication.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
The digitalSignature key usage bit [RFC3280] MUST be asserted when the intended purpose of the client's X.509 certificate is restricted with the id-pkinit-KPClientAuth EKU.
当客户端X.509证书的预期用途受到id pkinit KPClientAuth EKU的限制时，必须断言数字签名密钥使用位[RFC3280]。
If this EKU KeyPurposeId is required but it is not present, or if the client certificate is restricted not to be used for PKINIT client authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There is no accompanying e-data for this error message. KDCs implementing this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a large number of X.509 client certificates deployed for use with PKINIT that have this EKU.
如果需要此EKU KeyPurposeId，但它不存在，或者根据[RFC3280]第4.2.1.13节，客户端证书被限制不用于PKINIT客户端身份验证，则KDC必须返回代码KDC_ERR_INCONSISTENT_KEY_PURPOSE的错误消息。此错误消息没有附带的电子数据。实现此要求的KDC还应接受EKU KeyPurposeId ms kp sc登录（1.3.6.1.4.1.311.20.2.2）以满足要求，因为有大量X.509客户端证书部署用于具有此EKU的PKINIT。
As a matter of local policy, the KDC MAY decide to reject requests on the basis of the absence or presence of other specific EKU OIDs.
根据当地政策，KDC可根据是否存在其他特定EKU OID决定拒绝请求。
If the digest algorithm used in generating the CA signature for the public key in any certificate of the request is not acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be encoded in TYPED-DATA, although none is defined at this point.
如果KDC不接受为请求的任何证书中的公钥生成CA签名时使用的摘要算法，KDC必须返回KRB-ERROR[RFC4120]消息，其中代码KDC_ERR_digest_in_CERT_not_ACCEPTED。随附的电子数据必须用类型化数据编码，尽管目前还没有定义。
If the client's public key is not accepted with reasons other than those specified above, the KDC returns a KRB-ERROR [RFC4120] message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no accompanying e-data currently defined for this error message.
如果客户机的公钥由于上述原因以外的原因而不被接受，KDC将返回一条KRB-ERROR[RFC4120]消息，代码为KDC_ERR_client_not_TRUSTED。当前没有为此错误消息定义的附带电子数据。
The KDC MUST check the timestamp to ensure that the request is not a replay, and that the time skew falls within acceptable limits. The recommendations for clock skew times in [RFC4120] apply here. If the check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.
KDC必须检查时间戳，以确保请求不是重播，并且时间偏差在可接受的范围内。[RFC4120]中关于时钟偏移时间的建议适用于此处。如果检查失败，KDC必须分别返回错误代码KRB_AP_ERR_REPEAT或KRB_AP_ERR_SKEW。
If the clientPublicValue is filled in, indicating that the client wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD check to see if the key parameters satisfy its policy. If they do
如果填写了clientPublicValue，表示客户端希望使用Diffie-Hellman密钥协商方法，KDC应该检查密钥参数是否满足其策略。如果是的话
not, it MUST return an error message with the code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a TYPED-DATA that contains an element whose data-type is TD_DH_PARAMETERS, and whose data-value contains the DER encoding of the type TD-DH-PARAMETERS:
否则，它必须返回一条错误消息，代码为KDC_ERR_DH_KEY_PARAMETERS_not_ACCEPTED。随附的电子数据是一种类型化数据，其中包含一个数据类型为TD_DH_参数的元素，其数据值包含TD-DH-PARAMETERS类型的DER编码：
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order.
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order.
TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters that the KDC supports in decreasing preference order, from which the client SHOULD pick one to retry the request.
TD-DH-PARAMETERS包含KDC以递减优先顺序支持的Diffie-Hellman域参数列表，客户端应从中选择一个参数重试请求。
The AlgorithmIdentifier structure is defined in [RFC3280] and is filled in according to [RFC3279]. More specifically, Section 2.3.3 of [RFC3279] describes how to fill in the AlgorithmIdentifier structure in the case where MODP Diffie-Hellman key exchange is used.
算法标识符结构在[RFC3280]中定义，并根据[RFC3279]填写。更具体地说，[RFC3279]第2.3.3节描述了在使用MODP Diffie-Hellman密钥交换的情况下如何填写算法标识符结构。
If the client included a kdcPkId field in the PA-PK-AS-REQ and the KDC does not possess the corresponding key, the KDC MUST ignore the kdcPkId field as if the client did not include one.
如果客户端在PA-PK-AS-REQ中包含kdcPkId字段，并且KDC不具有相应的密钥，则KDC必须忽略kdcPkId字段，就像客户端不包含kdcPkId字段一样。
If the digest algorithm used by the id-pkinit-authData is not acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. The accompanying e-data MUST be encoded in TYPED-DATA, although none is defined at this point.
如果KDC不接受id pkinit authData使用的摘要算法，KDC必须返回KRB-ERROR[RFC4120]消息，其中代码KDC_ERR_digest_IN_SIGNED_DATA_not_ACCEPTED。随附的电子数据必须用类型化数据编码，尽管目前还没有定义。
If the paChecksum filed in the request is not present, the KDC conforming to this specification MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. The accompanying e-data MUST be encoded in TYPED-DATA (no error data is defined by this specification).
如果请求中提交的paChecksum不存在，则符合本规范的KDC必须返回KRB-ERROR[RFC4120]消息，其中必须包含代码KDC_ERR_PA_CHECKSUM。随附的电子数据必须用类型化数据编码（本规范未定义错误数据）。
Assuming that the client's request has been properly validated, the KDC proceeds as per [RFC4120], except as follows.
假设客户机的请求已被正确验证，KDC将按照[RFC4120]进行，以下情况除外。
The KDC MUST set the initial flag and include an authorization data element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued ticket. The ad-data [RFC4120] field contains the DER encoding of the type AD-INITIAL-VERIFIED-CAS:
KDC必须设置初始标志，并在发出的票据中包含ad类型[RFC4120]ad_initial_VERIFIED_CAS的授权数据元素。ad数据[RFC4120]字段包含ad-INALITY-VERIFIED-CAS类型的DER编码：
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies the certification path with which
-- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies the certification path with which
-- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
The AD-INITIAL-VERIFIED-CAS structure identifies the certification path with which the client certificate was validated. Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate (thereby its public key).
AD-INITIAL-VERIFIED-CAS结构标识验证客户端证书的证书路径。AD-INITIAL-VERIFIED-CAS结构中的每个ExternalPrincipalIdentifier（定义见第3.2.1节）标识CA或CA证书（从而标识其公钥）。
Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization data does permit empty SEQUENCEs to be encoded. Such empty sequences may only be used if the KDC itself vouches for the user's certificate.
注意，AD-INITIAL-VERIFIED-CAS授权数据的语法允许对空序列进行编码。只有当KDC本身为用户的证书提供担保时，才可以使用这种空序列。
The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT containers if the list of CAs satisfies the AS' realm's local policy (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag [RFC4120]). Furthermore, any TGS MUST copy such authorization data from tickets used within a PA-TGS-REQ of the TGS-REQ into the resulting ticket. If the list of CAs satisfies the local KDC's realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT container; otherwise, it MAY unwrap the authorization data out of the AD-IF-RELEVANT container.
如果CA列表满足AS领域的本地策略（这对应于TRANSITED-policy-CHECKED票证标志[RFC4120]），AS将所有AD-INITIAL-VERIFIED-CAS数据包装在AD-IF相关容器中。此外，任何TGS必须将TGS-REQ的PA-TGS-REQ中使用的票据中的此类授权数据复制到生成的票据中。如果CA列表满足本地KDC领域的策略，TGS可以将数据包装到AD-If相关容器中；否则，它可能会将授权数据从AD-IF相关容器中展开。
Application servers that understand this authorization data type SHOULD apply local policy to determine whether a given ticket bearing such a type *not* contained within an AD-IF-RELEVANT container is acceptable. (This corresponds to the AP server's checking the transited field when the TRANSITED-POLICY-CHECKED flag has not been set [RFC4120].) If such a data type is contained within an AD-IF-RELEVANT container, AP servers MAY apply local policy to determine whether the authorization data is acceptable.
理解此授权数据类型的应用程序服务器应应用本地策略，以确定包含AD-IF相关容器中的此类类型*非*的给定票证是否可接受。（这对应于AP服务器在未设置transited-POLICY-CHECKED标志时检查transited字段[RFC4120]）如果此类数据类型包含在AD-If相关容器中，AP服务器可以应用本地策略来确定授权数据是否可接受。
A pre-authentication data element, whose padata-type is PA_PK_AS_REP and whose padata-value contains the DER encoding of the type PA-PK-AS-REP (defined below), is included in the AS-REP [RFC4120].
AS-REP[RFC4120]中包含预认证数据元素，其padata类型为PA_PK_AS_REP，其padata值包含PA-PK-AS-REP（定义如下）类型的DER编码。
PA-PK-AS-REP ::= CHOICE {
dhInfo [0] DHRepInfo,
-- Selected when Diffie-Hellman key exchange is
-- used.
encKeyPack [1] IMPLICIT OCTET STRING,
-- Selected when public key encryption is used.
-- Contains a CMS type ContentInfo encoded
PA-PK-AS-REP ::= CHOICE {
dhInfo [0] DHRepInfo,
-- Selected when Diffie-Hellman key exchange is
-- used.
encKeyPack [1] IMPLICIT OCTET STRING,
-- Selected when public key encryption is used.
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-envelopedData (1.2.840.113549.1.7.3).
-- The content field is an EnvelopedData.
-- The contentType field for the type EnvelopedData
-- is id-signedData (1.2.840.113549.1.7.2).
-- The eContentType field for the inner type
-- SignedData (when unencrypted) is
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-- eContent field contains the DER encoding of the
-- type ReplyKeyPack.
-- ReplyKeyPack is defined in Section 3.2.3.2.
...
}
-- according to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-envelopedData (1.2.840.113549.1.7.3).
-- The content field is an EnvelopedData.
-- The contentType field for the type EnvelopedData
-- is id-signedData (1.2.840.113549.1.7.2).
-- The eContentType field for the inner type
-- SignedData (when unencrypted) is
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-- eContent field contains the DER encoding of the
-- type ReplyKeyPack.
-- ReplyKeyPack is defined in Section 3.2.3.2.
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded according
-- to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL,
-- Present if and only if dhKeyExpiration is
-- present in the KDCDHKeyInfo.
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded according
-- to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL,
-- Present if and only if dhKeyExpiration is
-- present in the KDCDHKeyInfo.
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- The KDC's DH public key.
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the pkAuthenticator field
-- in the request if the DH keys are NOT reused,
-- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair,
-- present if and only if the DH keys are reused.
-- If present, the KDC's DH public key MUST not be
-- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- The KDC's DH public key.
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the pkAuthenticator field
-- in the request if the DH keys are NOT reused,
-- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair,
-- present if and only if the DH keys are reused.
-- If present, the KDC's DH public key MUST not be
-- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
-- field MUST also be omitted. ... }
--字段也必须省略…}
The content of the AS-REP is otherwise unchanged from [RFC4120]. The KDC encrypts the reply as usual, but not with the client's long-term key. Instead, it encrypts it with either a shared key derived from a Diffie-Hellman exchange or a generated encryption key. The contents of the PA-PK-AS-REP indicate which key delivery method is used.
AS-REP的内容在[RFC4120]中没有改变。KDC像往常一样加密回复，但不使用客户端的长期密钥。相反，它使用从Diffie-Hellman交换派生的共享密钥或生成的加密密钥对其进行加密。PA-PK-AS-REP的内容表明使用了哪种密钥传递方法。
If the client does not wish to use the Diffie-Hellman key delivery method (the clientPublicValue field is not present in the request) and the KDC does not support the public key encryption key delivery method, the KDC MUST return an error message with the code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. There is no accompanying e-data for this error message.
如果客户端不希望使用Diffie-Hellman密钥传递方法（请求中不存在clientPublicValue字段），并且KDC不支持公钥加密密钥传递方法，KDC必须返回错误消息，代码为KDC_ERR_public_key_encryption_not_SUPPORTED。此错误消息没有附带的电子数据。
In addition, the lifetime of the ticket returned by the KDC MUST NOT exceed that of the client's public-private key pair. The ticket lifetime, however, can be shorter than that of the client's public-private key pair. For the implementations of this specification, the lifetime of the client's public-private key pair is the validity period in X.509 certificates [RFC3280], unless configured otherwise.
此外，KDC返回的票证的生存期不得超过客户端的公私密钥对的生存期。但是，票证的生命周期可以短于客户端的公私密钥对的生命周期。对于本规范的实现，除非另有配置，否则客户机的公钥-私钥对的生存期为X.509证书[RFC3280]中的有效期。
In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
在这种情况下，PA-PK-AS-REP包含一个DHRepInfo结构。
The ContentInfo [RFC3852] structure for the dhSignedData field is filled in as follows:
dhSignedData字段的ContentInfo[RFC3852]结构填写如下：
1. The contentType field of the type ContentInfo is id-signedData (as defined in [RFC3852]), and the content field is a SignedData (as defined in [RFC3852]).
1. ContentInfo类型的contentType字段是id signedData（定义见[RFC3852]），而内容字段是signedData（定义见[RFC3852]）。
2. The eContentType field for the type SignedData is the OID value for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS implementers: the signed attribute content-type MUST be present in this SignedData instance, and its value is id-pkinit-DHKeyData according to [RFC3852].
2. SignedData类型的eContentType字段是id pkinit DHKeyData的OID值：{iso（1）组织（3）国防部（6）互联网（1）安全（5）kerberosv5（2）pkinit（3）DHKeyData（2）}。CMS实施者注意：根据[RFC3852]，签名属性内容类型必须存在于该SignedData实例中，其值为id pkinit DHKeyData。
3. The eContent field for the type SignedData contains the DER encoding of the type KDCDHKeyInfo.
3. SignedData类型的eContent字段包含KDCDHKeyInfo类型的DER编码。
4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce, and, optionally, the expiration time of the KDC's DH key being reused. The subjectPublicKey field of the type
4. KDCDHKeyInfo结构包含KDC的公钥、nonce以及（可选）重用的KDC的DH密钥的过期时间。类型的subjectPublicKey字段
KDCDHKeyInfo field identifies KDC's DH public key. This DH public key value is encoded as a BIT STRING according to [RFC3279]. The nonce field contains the nonce in the pkAuthenticator field in the request if the DH keys are NOT reused. The value of this nonce field is 0 if the DH keys are reused. The dhKeyExpiration field is present if and only if the DH keys are reused. If the dhKeyExpiration field is present, the KDC's public key in this KDCDHKeyInfo structure MUST NOT be used past the point of this expiration time. If this field is omitted, then the serverDHNonce field MUST also be omitted.
KDCDHKeyInfo字段标识KDC的DH公钥。该DH公钥值根据[RFC3279]编码为位字符串。如果未重用DH密钥，则nonce字段包含请求中pkAuthenticator字段中的nonce。如果重复使用DH键，则此nonce字段的值为0。当且仅当DH密钥被重用时，dhKeyExpiration字段才存在。如果存在dhKeyExpiration字段，则此KDCDHKeyInfo结构中的KDC公钥在过期时间点之后不得使用。如果省略此字段，则还必须省略serverDHNonce字段。
5. The signerInfos field of the type SignedData contains a single signerInfo, which contains the signature over the type KDCDHKeyInfo.
5. SignedData类型的signerInfos字段包含单个signerInfo，其中包含KDCDHKeyInfo类型上的签名。
6. The certificates field of the type SignedData contains certificates intended to facilitate certification path construction, so that the client can verify the KDC's signature over the type KDCDHKeyInfo. The information contained in the trustedCertifiers in the request SHOULD be used by the KDC as hints to guide its selection of an appropriate certificate chain to return to the client. This field may be left empty if the KDC public key specified by the kdcPkId field in the PA-PK-AS-REQ was used for signing. Otherwise, for path validation, these certificates SHOULD be sufficient to construct at least one certification path from the KDC certificate to one trust anchor acceptable by the client [RFC4158]. The KDC MUST be capable of including such a set of certificates if configured to do so. The certificates field MUST NOT contain "root" CA certificates.
6. SignedData类型的certificates字段包含用于促进证书路径构造的证书，以便客户端可以通过KDCDHKeyInfo类型验证KDC的签名。KDC应该使用请求中trustedCertifiers中包含的信息作为提示，指导其选择适当的证书链以返回到客户端。如果PA-PK-AS-REQ中kdcPkId字段指定的KDC公钥用于签名，则此字段可能为空。否则，对于路径验证，这些证书应足以构造至少一条从KDC证书到客户端可接受的一个信任锚点的证书路径[RFC4158]。如果配置为这样做，KDC必须能够包含这样一组证书。证书字段不能包含“根”CA证书。
7. If the client included the clientDHNonce field, then the KDC may choose to reuse its DH keys. If the server reuses DH keys, then it MUST include an expiration time in the dhKeyExpiration field. Past the point of the expiration time, the signature over the type DHRepInfo is considered expired/invalid. When the server reuses DH keys then, it MUST include a serverDHNonce at least as long as the length of keys for the symmetric encryption system used to encrypt the AS reply. Note that including the serverDHNonce changes how the client and server calculate the key to use to encrypt the reply; see below for details. The KDC SHOULD NOT reuse DH keys unless the clientDHNonce field is present in the request.
7. 如果客户端包含clientDHNonce字段，那么KDC可以选择重用其DH密钥。如果服务器重用DH密钥，则必须在dhKeyExpiration字段中包含过期时间。超过过期时间点时，DHRepInfo类型上的签名被视为过期/无效。当服务器重用DH密钥时，它必须包含一个至少与用于加密as应答的对称加密系统的密钥长度相同的serverDHNonce。注意，包括serverDHNonce会改变客户端和服务器计算用于加密回复的密钥的方式；详情见下文。除非请求中存在clientDHNonce字段，否则KDC不应重用DH密钥。
The AS reply key is derived as follows:
AS应答密钥的推导如下：
1. Both the KDC and the client calculate the shared secret value as follows:
1. KDC和客户端都按如下方式计算共享机密值：
a) When MODP Diffie-Hellman is used, let DHSharedSecret be the shared secret value. DHSharedSecret is the value ZZ, as described in Section 2.1.1 of [RFC2631].
a) 当使用MODP Diffie-Hellman时，让DHSharedSecret作为共享秘密值。DHSharedSecret是[RFC2631]第2.1.1节所述的值ZZ。
DHSharedSecret is first padded with leading zeros such that the size of DHSharedSecret in octets is the same as that of the modulus, then represented as a string of octets in big-endian order.
DHSharedSecret首先用前导零填充，使DHSharedSecret的大小（以八位字节为单位）与模的大小相同，然后以大端顺序表示为一组八位字节。
Implementation note: Both the client and the KDC can cache the triple (ya, yb, DHSharedSecret), where ya is the client's public key and yb is the KDC's public key. If both ya and yb are the same in a later exchange, the cached DHSharedSecret can be used.
实现说明：客户端和KDC都可以缓存三元组（ya、yb、DHSharedSecret），其中ya是客户端的公钥，yb是KDC的公钥。如果在以后的交换中ya和yb都相同，则可以使用缓存的DHSharedSecret。
2. Let K be the key-generation seed length [RFC3961] of the AS reply key whose enctype is selected according to [RFC4120].
2. 设K为根据[RFC4120]选择enctype的AS应答密钥的密钥生成种子长度[RFC3961]。
3. Define the function octetstring2key() as follows:
3. 定义函数octetstring2key（），如下所示：
octetstring2key(x) == random-to-key(K-truncate(
SHA1(0x00 | x) |
SHA1(0x01 | x) |
SHA1(0x02 | x) |
...
))
octetstring2key(x) == random-to-key(K-truncate(
SHA1(0x00 | x) |
SHA1(0x01 | x) |
SHA1(0x02 | x) |
...
))
where x is an octet string; | is the concatenation operator; 0x00, 0x01, 0x02, etc. are each represented as a single octet; random-to-key() is an operation that generates a protocol key from a bitstring of length K; and K-truncate truncates its input to the first K bits. Both K and random-to-key() are as defined in the kcrypto profile [RFC3961] for the enctype of the AS reply key.
其中x是八位组字符串；|是串联运算符；0x00、0x01、0x02等均表示为单个八位字节；random-to-key（）是一种从长度为K的位字符串生成协议密钥的操作；K-truncate将其输入截断为前K位。K和random-to-key（）都是在kcrypto配置文件[RFC3961]中为as应答密钥的enctype定义的。
4. When DH keys are reused, let n_c be the clientDHNonce and n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty octet strings.
4. 当重用DH密钥时，让n_c为clientDHNonce，n_k为serverDHNonce；否则，让n_c和n_k都是空的八位字节字符串。
5. The AS reply key k is: k = octetstring2key(DHSharedSecret | n_c | n_k)
5. AS应答密钥k为：k=octetstring2key（DHSharedSecret | n|c | n|k）
In this case, the PA-PK-AS-REP contains the encKeyPack field where the AS reply key is encrypted.
在这种情况下，PA-PK-AS-REP包含加密AS-reply密钥的encKeyPack字段。
The ContentInfo [RFC3852] structure for the encKeyPack field is filled in as follows:
encKeyPack字段的ContentInfo[RFC3852]结构填写如下：
1. The contentType field of the type ContentInfo is id-envelopedData (as defined in [RFC3852]), and the content field is an EnvelopedData (as defined in [RFC3852]).
1. ContentInfo类型的contentType字段是id envelopedData（定义见[RFC3852]），而内容字段是envelopedData（定义见[RFC3852]）。
2. The contentType field for the type EnvelopedData is id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }.
2. EnvelopedData类型的contentType字段是id signedData:{iso（1）成员体（2）us（840）rsadsi（113549）pkcs（1）pkcs7（7）signedData（2）}。
3. The eContentType field for the inner type SignedData (when decrypted from the encryptedContent field for the type EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. Notes to CMS implementers: the signed attribute content-type MUST be present in this SignedData instance, and its value is id-pkinit-rkeyData according to [RFC3852].
3. 内部类型SignedData的eContentType字段（当从encryptedContent字段解密类型EnvelopedData时）是id pkinit rkeyData:{iso（1）组织（3）国防部（6）互联网（1）安全（5）kerberosv5（2）pkinit（3）rkeyData（3）}。CMS实施者注意：根据[RFC3852]，签名属性内容类型必须存在于此SignedData实例中，其值为id pkinit rkeyData。
4. The eContent field for the inner type SignedData contains the DER encoding of the type ReplyKeyPack (as described below).
4. 内部类型SignedData的eContent字段包含类型ReplyKeyPack的DER编码（如下所述）。
5. The signerInfos field of the inner type SignedData contains a single signerInfo, which contains the signature for the type ReplyKeyPack.
5. 内部类型SignedData的signerInfos字段包含单个signerInfo，其中包含ReplyKeyPack类型的签名。
6. The certificates field of the inner type SignedData contains certificates intended to facilitate certification path construction, so that the client can verify the KDC's signature for the type ReplyKeyPack. The information contained in the trustedCertifiers in the request SHOULD be used by the KDC as hints to guide its selection of an appropriate certificate chain to return to the client. This field may be left empty if the KDC public key specified by the kdcPkId field in the PA-PK-AS-REQ was used for signing. Otherwise, for path validation, these certificates SHOULD be sufficient to construct at least one certification path from the KDC certificate to one trust anchor acceptable by the client [RFC4158]. The KDC MUST be capable of including such a set of certificates if configured to do so. The certificates field MUST NOT contain "root" CA certificates.
6. 内部类型SignedData的certificates字段包含用于促进证书路径构造的证书，以便客户端可以验证类型ReplyKeyPack的KDC签名。KDC应该使用请求中trustedCertifiers中包含的信息作为提示，指导其选择适当的证书链以返回到客户端。如果PA-PK-AS-REQ中kdcPkId字段指定的KDC公钥用于签名，则此字段可能为空。否则，对于路径验证，这些证书应足以构造至少一条从KDC证书到客户端可接受的一个信任锚点的证书路径[RFC4158]。如果配置为这样做，KDC必须能够包含这样一组证书。证书字段不能包含“根”CA证书。
7. The recipientInfos field of the type EnvelopedData is a SET that MUST contain exactly one member of type KeyTransRecipientInfo. The encryptedKey of this member contains the temporary key that is encrypted using the client's public key.
7. EnvelopedData类型的recipientInfos字段是一个集合，它必须仅包含一个KeyTransRecipientInfo类型的成员。此成员的encryptedKey包含使用客户端公钥加密的临时密钥。
8. The unprotectedAttrs or originatorInfo fields of the type EnvelopedData MAY be present.
8. 可能存在EnvelopedData类型的未受保护的TTR或originatorInfo字段。
If there is a supportedCMSTypes field in the AuthPack, the KDC must check to see if it supports any of the listed types. If it supports more than one of the types, the KDC SHOULD use the one listed first. If it does not support any of them, it MUST return an error message with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
如果AuthPack中有supportedCMSTypes字段，KDC必须检查是否支持列出的任何类型。如果KDC支持多个类型，那么它应该使用首先列出的类型。如果它不支持其中任何一个，它必须返回一条错误消息，代码为KDC_ERR_ETYPE_NOSUPP[RFC4120]。
Furthermore, the KDC computes the checksum of the AS-REQ in the client request. This checksum is performed over the type AS-REQ, and the protocol key [RFC3961] of the checksum operation is the replyKey, and the key usage number is 6. If the replyKey's enctype is "newer" [RFC4120] [RFC4121], the checksum operation is the required checksum operation [RFC3961] of that enctype.
此外，KDC计算客户端请求中AS-REQ的校验和。该校验和在AS-REQ类型上执行，校验和操作的协议密钥[RFC3961]为replyKey，密钥使用号为6。如果replyKey的enctype为“较新”[RFC4120][RFC4121]，则校验和操作是该enctype所需的校验和操作[RFC3961]。
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP, i.e., the
-- AS reply key.
asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ.
-- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6.
-- If the replyKey's enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt
-- of the AS-REP.
...
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP, i.e., the
-- AS reply key.
asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ.
-- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6.
-- If the replyKey's enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt
-- of the AS-REP.
...
}
Implementations of this RSA encryption key delivery method are RECOMMENDED to support RSA keys at least 2048 bits in size.
建议此RSA加密密钥传递方法的实现支持至少2048位大小的RSA密钥。
Upon receipt of the KDC's reply, the client proceeds as follows. If the PA-PK-AS-REP contains the dhSignedData field, the client derives the AS reply key using the same procedure used by the KDC, as defined in Section 3.2.3.1. Otherwise, the message contains the encKeyPack field, and the client decrypts and extracts the temporary key in the encryptedKey field of the member KeyTransRecipientInfo and then uses that as the AS reply key.
在收到KDC的回复后，客户进行如下操作。如果PA-PK-AS-REP包含dhSignedData字段，则客户端使用KDC使用的相同过程（如第3.2.3.1节所定义）获取AS应答密钥。否则，消息包含encKeyPack字段，客户端解密并提取成员KeyTransRecipientInfo的encryptedKey字段中的临时密钥，然后将其用作应答密钥。
If the public key encryption method is used, the client MUST verify the asChecksum contained in the ReplyKeyPack.
如果使用公钥加密方法，客户端必须验证ReplyKeyPack中包含的asChecksum。
In either case, the client MUST verify the signature in the SignedData according to [RFC3852]. The KDC's X.509 certificate MUST be validated according to [RFC3280]. In addition, unless the client can otherwise verify that the public key used to verify the KDC's signature is bound to the KDC of the target realm, the KDC's X.509 certificate MUST contain a Subject Alternative Name extension [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as defined in Section 3.2.2) and whose value is a KRB5PrincipalName that matches the name of the TGS of the target realm (as defined in Section 7.3 of [RFC4120]).
在这两种情况下，客户必须根据[RFC3852]验证签名数据中的签名。KDC的X.509证书必须根据[RFC3280]进行验证。此外，除非客户机可以验证用于验证KDC签名的公钥是否绑定到目标领域的KDC，否则KDC的X.509证书必须包含一个主题替代名称扩展[RFC3280]，其中包含一个类型id为id pkinit san（如第3.2.2节所定义）的另一个名称其值为与目标领域TGS名称匹配的KRB5 PrincipalName（定义见[RFC4120]第7.3节）。
Unless the client knows by some other means that the KDC certificate is intended for a Kerberos KDC, the client MUST require that the KDC certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
除非客户机通过其他方式知道KDC证书用于Kerberos KDC，否则客户机必须要求KDC证书包含EKU KeyPurposeId[RFC3280]id pkinit KPKdc：
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeKdc(5) }
-- Signing KDC responses.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeKdc(5) }
-- Signing KDC responses.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
The digitalSignature key usage bit [RFC3280] MUST be asserted when the intended purpose of the KDC's X.509 certificate is restricted with the id-pkinit-KPKdc EKU.
当KDC的X.509证书的预期用途受到id pkinit KPKdc EKU的限制时，必须断言数字签名密钥使用位[RFC3280]。
If the KDC certificate contains the Kerberos TGS name encoded as an id-pkinit-san SAN, this certificate is certified by the issuing CA as a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
如果KDC证书包含编码为id pkinit san san的Kerberos TGS名称，则颁发证书的CA会将此证书认证为KDC证书，因此不需要id pkinit KPKdc EKU。
If all applicable checks are satisfied, the client then decrypts the enc-part field of the KDC-REP in the AS-REP, using the AS reply key, and then proceeds as described in [RFC4120].
如果满足所有适用的检查，则客户端使用AS应答密钥解密AS-REP中KDC-REP的enc部分字段，然后按照[RFC4120]中的说明进行操作。
The client MUST be capable of sending a set of certificates sufficient to allow the KDC to construct a certification path for the client's certificate, if the correct set of certificates is provided through configuration or policy.
如果通过配置或策略提供了正确的证书集，则客户端必须能够发送一组足以允许KDC为客户端证书构造证书路径的证书。
If the client sends all the X.509 certificates on a certification path to a trust anchor acceptable by the KDC, and if the KDC cannot verify the client's public key otherwise, the KDC MUST be able to process path validation for the client's certificate based on the certificates in the request.
如果客户端将证书路径上的所有X.509证书发送给KDC可接受的信任锚点，并且如果KDC无法验证客户端的公钥，则KDC必须能够根据请求中的证书处理客户端证书的路径验证。
The KDC MUST be capable of sending a set of certificates sufficient to allow the client to construct a certification path for the KDC's certificate, if the correct set of certificates is provided through configuration or policy.
如果通过配置或策略提供了正确的证书集，则KDC必须能够发送一组足以允许客户端为KDC的证书构造证书路径的证书。
If the KDC sends all the X.509 certificates on a certification path to a trust anchor acceptable by the client, and the client can not verify the KDC's public key otherwise, the client MUST be able to process path validation for the KDC's certificate based on the certificates in the reply.
如果KDC将证书路径上的所有X.509证书发送给客户端可接受的信任锚点，并且客户端无法验证KDC的公钥，则客户端必须能够根据回复中的证书处理KDC证书的路径验证。
If pre-authentication is required but was not present in the request, per [RFC4120] an error message with the code KDC_ERR_PREAUTH_FAILED is returned, and a METHOD-DATA object will be stored in the e-data field of the KRB-ERROR message to specify which pre-authentication mechanisms are acceptable. The KDC can then indicate the support of PKINIT by including an empty element whose padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
如果需要预身份验证，但请求中不存在预身份验证，则根据[RFC4120]返回代码为KDC_ERR_PREAUTH_FAILED的错误消息，并且将在KRB-error消息的e-DATA字段中存储一个METHOD-DATA对象，以指定可接受的预身份验证机制。然后，KDC可以通过在该方法数据对象中包含padata类型为PA_PK_AS_REQ的空元素来指示对PKINIT的支持。
Otherwise if it is required by the KDC's local policy that the client must be pre-authenticated using the pre-authentication mechanism specified in this document, but no PKINIT pre-authentication was present in the request, an error message with the code KDC_ERR_PREAUTH_FAILED SHOULD be returned.
否则，如果KDC的本地策略要求必须使用本文档中指定的预身份验证机制对客户端进行预身份验证，但请求中不存在PKINIT预身份验证，则应返回代码为KDC_ERR_PREAUTH_FAILED的错误消息。
KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET STRING), and clients MUST ignore this and any other value. Future extensions to this protocol may specify other data to send instead of an empty OCTET STRING.
KDC必须将KRB-ERROR的METHOD-DATA中的PA_PK_AS_REQ元素的padata value字段保留为空（即，发送一个长度为零的八位字节字符串），客户端必须忽略此值和任何其他值。此协议的未来扩展可能指定要发送的其他数据，而不是空的八位字节字符串。
The security of cryptographic algorithms is dependent on generating secret quantities [RFC4086]. The number of truly random bits is extremely important in determining the attack resistance strength of the cryptosystem; for example, the secret Diffie-Hellman exponents must be chosen based on n truly random bits (where n is the system security requirement). The security of the overall system is significantly weakened by using insufficient random inputs: a sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
密码算法的安全性取决于生成秘密量[RFC4086]。真正随机比特的数量对于确定密码系统的抗攻击强度非常重要；例如，机密Diffie-Hellman指数必须基于n个真正随机的位（其中n是系统安全要求）来选择。使用不充分的随机输入会大大削弱整个系统的安全性：复杂的攻击者可能会发现，与在整个潜在数字空间中定位数量相比，更容易重现产生秘密数量的环境并搜索产生的一小组可能性。
Kerberos error messages are not integrity protected; as a result, the domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered with by an attacker so that the set of domain parameters selected could be either weaker or not mutually preferred. Local policy can configure sets of domain parameters acceptable locally, or disallow the negotiation of DH domain parameters.
Kerberos错误消息没有完整性保护；因此，KDC作为TD-DH-parameters发送的域参数可能会被攻击者篡改，因此所选域参数集可能较弱，或者不是双方都喜欢的。本地策略可以配置本地可接受的域参数集，或不允许协商DH域参数。
The symmetric reply key size and Diffie-Hellman field size or RSA modulus size should be chosen so as to provide sufficient cryptographic security [RFC3766].
应选择对称回复密钥大小和Diffie-Hellman字段大小或RSA模大小，以提供足够的加密安全性[RFC3766]。
When MODP Diffie-Hellman is used, the exponents should have at least twice as many bits as the symmetric keys that will be derived from them [ODL99].
当使用MODP Diffie-Hellman时，指数的位数应至少是从其派生的对称密钥的两倍[ODL99]。
PKINIT raises certain security considerations beyond those that can be regulated strictly in protocol definitions. We will address them in this section.
PKINIT提出了某些安全考虑因素，超出了协议定义中可以严格规定的安全考虑因素。我们将在本节中讨论这些问题。
PKINIT extends the cross-realm model to the public-key infrastructure. Users of PKINIT must understand security policies and procedures appropriate to the use of Public Key Infrastructures [RFC3280].
PKINIT将跨领域模型扩展到公钥基础设施。PKINIT用户必须了解适用于使用公钥基础设施的安全策略和程序[RFC3280]。
In order to trust a KDC certificate that is certified by a CA as a KDC certificate for a target realm (for example, by asserting the TGS name of that Kerberos realm as an id-pkinit-san SAN and/or restricting the certificate usage by using the id-pkinit-KPKdc EKU, as described in Section 3.2.4), the client MUST verify that the KDC certificate's issuing CA is authorized to issue KDC certificates for that target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established.
为了信任由CA认证为目标领域KDC证书的KDC证书（例如，通过将该Kerberos领域的TGS名称声明为id pkinit san san和/或使用id pkinit KPKdc EKU限制证书使用，如第3.2.4节所述），客户端必须验证KDC证书的颁发CA是否有权为该目标领域颁发KDC证书。否则，KDC证书和目标领域的KDC之间的绑定将不会建立。
How to validate this authorization is a matter of local policy. A way to achieve this is the configuration of specific sets of intermediary CAs and trust anchors, one of which must be on the KDC certificate's certification path [RFC3280], and, for each CA or trust anchor, the realms for which it is allowed to issue certificates.
如何验证此授权是本地策略的问题。实现这一点的一种方法是配置特定的中间CA和信任锚点集，其中一个必须位于KDC证书的证书路径[RFC3280]上，并且对于每个CA或信任锚点，允许其颁发证书的领域。
In addition, if any CA that is trusted to issue KDC certificates can also issue other kinds of certificates, then local policy must be able to distinguish between them; for example, it could require that KDC certificates contain the id-pkinit-KPKdc EKU or that the realm be specified with the id-pkinit-san SAN.
此外，如果任何受信任颁发KDC证书的CA也可以颁发其他类型的证书，则本地策略必须能够区分它们；例如，它可能要求KDC证书包含id pkinit KPKdc EKU，或者使用id pkinit san指定领域。
It is the responsibility of the PKI administrators for an organization to ensure that KDC certificates are only issued to KDCs, and that clients can ascertain this using their local policy.
组织的PKI管理员有责任确保KDC证书仅颁发给KDC，并且客户端可以使用其本地策略确定这一点。
Standard Kerberos allows the possibility of interactions between cryptosystems of varying strengths; this document adds interactions with public-key cryptosystems to Kerberos. Some administrative policies may allow the use of relatively weak public keys. When using such weak asymmetric keys to protect/exchange stronger symmetric Keys, the attack resistant strength of the overall system is no better than that of these weak keys [RFC3766].
标准Kerberos允许不同强度的密码系统之间进行交互；本文档将与公钥密码系统的交互添加到Kerberos中。某些管理策略可能允许使用相对较弱的公钥。当使用这种弱非对称密钥来保护/交换更强的对称密钥时，整个系统的抗攻击强度并不比这些弱密钥好[RFC3766]。
PKINIT requires that keys for symmetric cryptosystems be generated. Some such systems contain "weak" keys. For recommendations regarding these weak keys, see [RFC4120].
PKINIT要求生成对称密码系统的密钥。一些这样的系统包含“弱”键。有关这些弱密钥的建议，请参阅[RFC4120]。
PKINIT allows the use of the same RSA key pair for encryption and signing when doing RSA encryption-based key delivery. This is not recommended usage of RSA keys [RFC3447]; by using DH-based key delivery, this is avoided.
PKINIT允许在执行基于RSA加密的密钥传递时使用相同的RSA密钥对进行加密和签名。不建议使用RSA密钥[RFC3447]；通过使用基于DH的密钥传递，可以避免这种情况。
Care should be taken in how certificates are chosen for the purposes of authentication using PKINIT. Some local policies may require that key escrow be used for certain certificate types. Deployers of PKINIT should be aware of the implications of using certificates that have escrowed keys for the purposes of authentication. Because signing-only certificates are normally not escrowed, by using DH-based key delivery this is avoided.
为了使用PKINIT进行身份验证，应注意如何选择证书。某些本地策略可能要求对某些证书类型使用密钥托管。PKINIT的部署人员应该了解使用具有托管密钥的证书进行身份验证的含义。由于仅签名证书通常不托管，因此通过使用基于DH的密钥传递可以避免这种情况。
PKINIT does not provide for a "return routability" test to prevent attackers from mounting a denial-of-service attack on the KDC by causing it to perform unnecessary and expensive public-key operations. Strictly speaking, this is also true of standard Kerberos, although the potential cost is not as great, because standard Kerberos does not make use of public-key cryptography. By using DH-based key delivery and reusing DH keys, the necessary crypto processing cost per request can be minimized.
PKINIT不提供“返回可路由性”测试，以防止攻击者通过使KDC执行不必要且昂贵的公钥操作，在KDC上发起拒绝服务攻击。严格地说，标准Kerberos也是如此，尽管潜在成本没有那么高，因为标准Kerberos不使用公钥加密。通过使用基于DH的密钥传递和重用DH密钥，每个请求所需的加密处理成本可以最小化。
When the Diffie-Hellman key exchange method is used, additional pre-authentication data [RFC4120] (in addition to the PA_PK_AS_REQ, as defined in this specification) is not bound to the AS_REQ by the mechanisms discussed in this specification (meaning it may be dropped or added by attackers without being detected by either the client or the KDC). Designers of additional pre-authentication data should take that into consideration if such additional pre-authentication data can be used in conjunction with the PA_PK_AS_REQ. The future work of the Kerberos working group is expected to update the hash algorithms specified in this document and provide a generic mechanism to bind additional pre-authentication data with the accompanying AS_REQ.
当使用Diffie-Hellman密钥交换方法时，额外的预认证数据[RFC4120]（除了本规范中定义的PA_PK_AS_REQ之外）不会通过本规范中讨论的机制绑定到AS_REQ（这意味着攻击者可能会丢弃或添加该数据，而不会被客户端或KDC检测到）。如果附加预认证数据可与PA_PK_AS_REQ一起使用，则附加预认证数据的设计者应考虑到这一点。Kerberos工作组的未来工作预计将更新本文档中指定的哈希算法，并提供一种通用机制，将附加的预认证数据与随附的AS_REQ绑定。
The key usage number 6 used by the asChecksum field is also used for the authenticator checksum (cksum field of AP-REQ) contained in the PA-TGS-REQ preauthentication data contained in a TGS-REQ [RFC4120]. This conflict is present for historical reasons; the reuse of key usage numbers is strongly discouraged.
asChecksum字段使用的密钥使用编号6也用于TGS-REQ[RFC4120]中包含的PA-TGS-REQ预验证数据中包含的验证器校验和（AP-REQ的校验和字段）。这种冲突的存在是有历史原因的；强烈反对重用密钥使用编号。
The following people have made significant contributions to this document: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M Grundman, and Jeffrey Altman.
以下人士对本文件做出了重大贡献：保罗·利奇、斯特凡·桑特森、萨姆·哈特曼、洛夫·霍恩奎斯特·阿斯特兰、肯·雷伯恩、尼古拉斯·威廉姆斯、约翰·雷伊、汤姆·余、杰弗里·哈泽尔曼、大卫·克罗斯、丹·西蒙、卡蒂克·贾加纳桑、查斯基尔·格朗德曼和杰弗里·奥尔特曼。
Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay, and Chris Walstad discovered a binding issue between the AS-REQ and AS-REP in draft -26; the asChecksum field was added as the result.
安德烈·谢德罗夫、亚伦·贾加德、伊利亚诺·塞尔维萨托、乔·凯·蔡和克里斯·沃尔斯塔德在草案26中发现了AS-REQ和AS-REP之间的约束问题；结果添加了asChecksum字段。
Special thanks to Clifford Neuman, Matthew Hur, Ari Medvinsky, Sasha Medvinsky, and Jonathan Trostle who wrote earlier versions of this document.
特别感谢Clifford Neuman、Matthew Hur、Ari Medvinsky、Sasha Medvinsky和Jonathan Trostle，他们编写了本文档的早期版本。
The authors are indebted to the Kerberos working group chair, Jeffrey Hutzelman, who kept track of various issues and was enormously helpful during the creation of this document.
作者要感谢Kerberos工作组主席Jeffrey Hutzelman，他跟踪了各种问题，并在本文档的创建过程中提供了巨大帮助。
Some of the ideas on which this document is based arose during discussions over several years between members of the SAAG, the IETF CAT working group, and the PSRG, regarding integration of Kerberos and SPX. Some ideas have also been drawn from the DASS system. These changes are by no means endorsed by these groups. This is an attempt to revive some of the goals of those groups, and this document approaches those goals primarily from the Kerberos perspective.
在SAAG、IETF CAT工作组和PSRG成员之间关于Kerberos和SPX集成的几年讨论中，出现了本文档所基于的一些想法。还从DASS系统中得出了一些想法。这些改变并没有得到这些团体的认可。这是试图恢复这些小组的一些目标，本文档主要从Kerberos的角度来实现这些目标。
Lastly, comments from groups working on similar ideas in DCE have been invaluable.
最后，在DCE中从事类似想法工作的小组的评论非常宝贵。
[IEEE1363] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000.
[IEEE1363]IEEE，“公钥加密的标准规范”，IEEE 1363，2000。
[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月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
2002年4月，福特公司发布了《公共基础设施许可证》和《公共基础设施许可证撤销许可证》（RFC.3280），并于2002年4月发布。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RFC3560]Housley，R.，“在加密消息语法（CMS）中使用RSAES-OAEP密钥传输算法”，RFC 3560，2003年7月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852]Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[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月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[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月。
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002，信息技术-抽象语法符号1（ASN.1）：基本符号规范。
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X690]ITU-T建议X.690（2002）| ISO/IEC 8825-1:2002，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
[ODL99] Odlyzko, A., "Discrete logarithms: The past and the future, Designs, Codes, and Cryptography (1999)". April 1999.
[ODL99]Odlyzko，A.，“离散对数：过去和未来，设计，代码和密码学（1999）”。1999年4月。
[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月。
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005.
[RFC4158]Cooper，M.，Dzambasow，Y.，Hesse，P.，Joseph，S.，和R.Nicholas，“互联网X.509公钥基础设施：认证路径构建”，RFC 4158，2005年9月。
KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
进口
SubjectPublicKeyInfo, AlgorithmIdentifier FROM PKIX1Explicit88 { iso (1) identified-organization (3) dod (6) internet (1) security (5) mechanisms (5) pkix (7) id-mod (0) id-pkix1-explicit (18) } -- As defined in RFC 3280.
SubjectPublicKeyInfo，来自PKIX1Explicit88的算法标识符{iso（1）已识别组织（3）国防部（6）互联网（1）安全（5）机制（5）pkix（7）id mod（0）id-pkix1-explicit（18）}——如RFC 3280中所定义。
KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum FROM KerberosV5Spec2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) }; -- as defined in RFC 4120.
KerberosTime、PrincipalName、Realm、EncryptionKey、来自KerberosV5Spec2的校验和{iso（1）已识别组织（3）国防部（6）互联网（1）安全（5）kerberosV5（2）模块（4）krb5spec2（2）}；--如RFC 4120中所定义。
id-pkinit OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit (3) }
id-pkinit OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit (3) }
id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
pa-pk-as-req INTEGER ::= 16
pa-pk-as-rep INTEGER ::= 17
pa-pk-as-req INTEGER ::= 16
pa-pk-as-rep INTEGER ::= 17
ad-initial-verified-cas INTEGER ::= 9
ad-initial-verified-cas INTEGER ::= 9
td-trusted-certifiers INTEGER ::= 104
td-invalid-certificates INTEGER ::= 105
td-dh-parameters INTEGER ::= 109
td-trusted-certifiers INTEGER ::= 104
td-invalid-certificates INTEGER ::= 105
td-dh-parameters INTEGER ::= 109
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the
-- type AuthPack.
-- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL,
-- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
-- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as
-- hints to guide its selection of an appropriate
-- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852].
-- Identifies, if present, a particular KDC
-- public key that the client already has.
...
}
-- according to [RFC3852].
-- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the
-- type AuthPack.
-- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL,
-- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
-- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as
-- hints to guide its selection of an appropriate
-- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852].
-- Identifies, if present, a particular KDC
-- public key that the client already has.
...
}
DHNonce ::= OCTET STRING
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a PKIX type Name encoded according to
-- [RFC3280].
-- Identifies the certificate subject by the
-- distinguished subject name.
-- REQUIRED when there is a distinguished subject
-- name present in the certificate.
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a CMS type IssuerAndSerialNumber encoded
-- according to [RFC3852].
-- Identifies a certificate of the subject.
-- REQUIRED for TD-INVALID-CERTIFICATES and
-- TD-TRUSTED-CERTIFIERS.
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
-- Identifies the subject's public key by a key
-- identifier. When an X.509 certificate is
-- referenced, this key identifier matches the X.509
ExternalPrincipalIdentifier ::= SEQUENCE {
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a PKIX type Name encoded according to
-- [RFC3280].
-- Identifies the certificate subject by the
-- distinguished subject name.
-- REQUIRED when there is a distinguished subject
-- name present in the certificate.
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a CMS type IssuerAndSerialNumber encoded
-- according to [RFC3852].
-- Identifies a certificate of the subject.
-- REQUIRED for TD-INVALID-CERTIFICATES and
-- TD-TRUSTED-CERTIFIERS.
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
-- Identifies the subject's public key by a key
-- identifier. When an X.509 certificate is
-- referenced, this key identifier matches the X.509
-- subjectKeyIdentifier extension value. When other
-- certificate formats are referenced, the documents
-- that specify the certificate format and their use
-- with the CMS must include details on matching the
-- key identifier to the appropriate certificate
-- field.
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
...
}
-- subjectKeyIdentifier extension value. When other
-- certificate formats are referenced, the documents
-- that specify the certificate format and their use
-- with the CMS must include details on matching the
-- key identifier to the appropriate certificate
-- field.
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in
-- [RFC3280].
-- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363].
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
-- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- Type AlgorithmIdentifier is defined in
-- [RFC3280].
-- List of CMS algorithm [RFC3370] identifiers
-- that identify key transport algorithms, or
-- content encryption algorithms, or signature
-- algorithms supported by the client in order of
-- (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it
-- wishes to reuse DH keys or to allow the KDC to
-- do so.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in
-- [RFC3280].
-- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363].
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
-- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- Type AlgorithmIdentifier is defined in
-- [RFC3280].
-- List of CMS algorithm [RFC3370] identifiers
-- that identify key transport algorithms, or
-- content encryption algorithms, or signature
-- algorithms supported by the client in order of
-- (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it
-- wishes to reuse DH keys or to allow the KDC to
-- do so.
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for
-- replay prevention.
nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present.
-- Contains the SHA1 checksum, performed over
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for
-- replay prevention.
nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present.
-- Contains the SHA1 checksum, performed over
-- KDC-REQ-BODY. ... }
--KDC-REQ-BODY…}
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid
-- signature.
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid
-- signature.
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies the certification path based on which
-- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies the certification path based on which
-- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
PA-PK-AS-REP ::= CHOICE {
dhInfo [0] DHRepInfo,
-- Selected when Diffie-Hellman key exchange is
-- used.
encKeyPack [1] IMPLICIT OCTET STRING,
-- Selected when public key encryption is used.
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-envelopedData (1.2.840.113549.1.7.3).
-- The content field is an EnvelopedData.
-- The contentType field for the type EnvelopedData
-- is id-signedData (1.2.840.113549.1.7.2).
-- The eContentType field for the inner type
-- SignedData (when unencrypted) is
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-- eContent field contains the DER encoding of the
-- type ReplyKeyPack.
-- ReplyKeyPack is defined below.
...
PA-PK-AS-REP ::= CHOICE {
dhInfo [0] DHRepInfo,
-- Selected when Diffie-Hellman key exchange is
-- used.
encKeyPack [1] IMPLICIT OCTET STRING,
-- Selected when public key encryption is used.
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-envelopedData (1.2.840.113549.1.7.3).
-- The content field is an EnvelopedData.
-- The contentType field for the type EnvelopedData
-- is id-signedData (1.2.840.113549.1.7.2).
-- The eContentType field for the inner type
-- SignedData (when unencrypted) is
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-- eContent field contains the DER encoding of the
-- type ReplyKeyPack.
-- ReplyKeyPack is defined below.
...
}
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded according
-- to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL,
-- Present if and only if dhKeyExpiration is
-- present.
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded according
-- to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL,
-- Present if and only if dhKeyExpiration is
-- present.
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- The KDC's DH public key.
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the pkAuthenticator field
-- in the request if the DH keys are NOT reused,
-- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair,
-- present if and only if the DH keys are reused.
-- If present, the KDC's DH public key MUST not be
-- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
-- field MUST also be omitted.
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- The KDC's DH public key.
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the pkAuthenticator field
-- in the request if the DH keys are NOT reused,
-- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair,
-- present if and only if the DH keys are reused.
-- If present, the KDC's DH public key MUST not be
-- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
-- field MUST also be omitted.
...
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP, i.e., the
-- AS reply key.
asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ.
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP, i.e., the
-- AS reply key.
asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ.
-- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6.
-- If the replyKey's enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt
-- of the AS-REP.
...
}
-- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6.
-- If the replyKey's enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt
-- of the AS-REP.
...
}
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order.
END
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order.
END
Function octetstring2key() is defined in Section 3.2.3.1. This section describes a few sets of test vectors that would be useful for implementers of octetstring2key().
函数octetstring2key（）在第3.2.3.1节中定义。本节描述了几组测试向量，这些测试向量对octetstring2key（）的实现者很有用。
Set 1:
=====
Input octet string x is:
Set 1:
=====
Input octet string x is:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Output of K-truncate() when the key size is 32 octets:
密钥大小为32个八位字节时K-truncate（）的输出：
5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
Set 2:
=====
Input octet string x is:
Set 2:
=====
Input octet string x is:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Output of K-truncate() when the key size is 32 octets:
密钥大小为32个八位字节时K-truncate（）的输出：
ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
Set 3:
======
Input octet string x is:
Set 3:
======
Input octet string x is:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0e 0f 10 00 01 02 04 05 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 03 04 05 06 07 08 09 0a 0b 0c 0e 0f 10 00 01 02 03 04 05 06 08 09 0a 0b 0c 0e 0f 10 00 01 03 03 04 04 04 05 06 08 0c 0e 0a 0b 0b 0c 0d 0f 10 00 00 01 03 03 03 03 03 03 03 04 04 05 05 05 08 0c 0d0e 0f 10 00 01 02 03 04 05 06 07 08
Output of K-truncate() when the key size is 32 octets:
密钥大小为32个八位字节时K-truncate（）的输出：
c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
C442 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
Set 4:
=====
Input octet string x is:
Set 4:
=====
Input octet string x is:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 08
Output of K-truncate() when the key size is 32 octets:
密钥大小为32个八位字节时K-truncate（）的输出：
00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 59 0e d6 ff ad ca 6f f6 4f 47 eb 8d 78 0f fc
Appendix C. Miscellaneous Information about Microsoft Windows PKINIT Implementations
附录C.有关Microsoft Windows PKINIT实施的其他信息
Earlier revisions of the PKINIT I-D were implemented in various releases of Microsoft Windows and deployed in fairly large numbers. To enable the community to interoperate better with systems running those releases, the following information may be useful.
早期版本的PKINIT I-D已在各种Microsoft Windows版本中实施，并大量部署。为了使社区能够更好地与运行这些版本的系统进行互操作，以下信息可能很有用。
KDC certificates issued by Windows 2000 Enterprise CAs contain a dNSName SAN with the DNS name of the host running the KDC, and the id-kp-serverAuth EKU [RFC3280].
Windows 2000企业CA颁发的KDC证书包含一个dNSName SAN，其中包含运行KDC的主机的DNS名称和id kp serverAuth EKU[RFC3280]。
KDC certificates issued by Windows 2003 Enterprise CAs contain a dNSName SAN with the DNS name of the host running the KDC, the id-kp-serverAuth EKU, and the id-ms-kp-sc-logon EKU.
Windows 2003企业CA颁发的KDC证书包含一个dNSName SAN，其中包含运行KDC的主机的DNS名称、id kp serverAuth EKU和id ms kp sc logon EKU。
It is anticipated that the next release of Windows is already too far along to allow it to support the issuing KDC certificates with id-pkinit-san SAN as specified in this RFC. Instead, they will have a dNSName SAN containing the domain name of the KDC, and the intended purpose of these KDC certificates will be restricted by the presence of the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
预计Windows的下一个版本已经太长，无法支持此RFC中指定的id为pkinit san san san的KDC证书的颁发。相反，它们将具有包含KDC域名的dNSName SAN，并且这些KDC证书的预期用途将受到id pkinit KPKdc EKU和id kp serverAuth EKU的限制。
In addition to checking that the above are present in a KDC certificate, Windows clients verify that the issuer of the KDC certificate is one of a set of allowed issuers of such certificates, so those wishing to issue KDC certificates need to configure their Windows clients appropriately.
除了检查KDC证书中是否存在上述内容外，Windows客户端还会验证KDC证书的颁发者是否是此类证书的一组允许颁发者之一，因此希望颁发KDC证书的用户需要适当配置其Windows客户端。
Client certificates accepted by Windows 2000 and Windows 2003 Server KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN contains a UTF8-encoded string whose value is that of the Directory Service attribute UserPrincipalName of the client account object, and the purpose of including the id-ms-san-sc-logon-upn SAN in the client certificate is to validate the client mapping (in other words, the client's public key is bound to the account that has this UserPrincipalName value).
Windows 2000和Windows 2003 Server KDC接受的客户端证书必须包含id ms san sc logon upn（1.3.6.1.4.1.311.20.2.3）san和id ms kp sc logon EKU。id ms san sc logon upn san包含一个UTF8编码字符串，其值为客户端帐户对象的目录服务属性UserPrincipalName的值，在客户端证书中包含id ms san sc logon upn san的目的是验证客户端映射（换句话说，客户端的公钥绑定到具有此UserPrincipalName值的帐户）。
It should be noted that all Microsoft Kerberos realm names are domain-style realm names and strictly in uppercase. In addition, the UserPrincipalName attribute is globally unique in Windows 2000 and Windows 2003.
应该注意的是，所有Microsoft Kerberos域名都是域名样式的域名，并且严格使用大写字母。此外，UserPrincipalName属性在Windows 2000和Windows 2003中是全局唯一的。
Authors' Addresses
作者地址
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: lzhu@microsoft.com
EMail: lzhu@microsoft.com
Brian Tung Aerospace Corporation 2350 E. El Segundo Blvd. El Segundo, CA 90245 US
布莱恩东航空航天公司，塞贡多大道东2350号。埃尔塞贡多，加利福尼亚州90245美国
EMail: brian@aero.org
EMail: brian@aero.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。