Internet Engineering Task Force (IETF) L. Hornquist Astrand
Request for Comments: 8636 Apple, Inc
Updates: 4556 L. Zhu
Category: Standards Track Oracle Corporation
ISSN: 2070-1721 M. Cullen
Painless Security
G. Hudson
MIT
July 2019
Internet Engineering Task Force (IETF) L. Hornquist Astrand
Request for Comments: 8636 Apple, Inc
Updates: 4556 L. Zhu
Category: Standards Track Oracle Corporation
ISSN: 2070-1721 M. Cullen
Painless Security
G. Hudson
MIT
July 2019
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
Kerberos（PKINIT）算法中用于初始身份验证的公钥加密
Abstract
摘要
This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.
本文档更新了Kerberos（PKINIT）标准（RFC 4556）中用于初始身份验证的公钥加密，以删除与特定加密算法相关的协议结构。PKINIT密钥派生函数是可协商的，用于对预认证数据和客户端的X.509证书进行签名的摘要算法是可发现的。
These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms.
这些更改针对将来在任何特定加密算法中发现的漏洞提供了先发制人的保护，并允许增量部署新算法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8636.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8636.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束
(https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4
4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 5
5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5
6. KDF Agility . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11
8. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Test Vector for SHA-256, enctype 18 . . . . . . . . . . . 13
8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Test Vector for SHA-512, enctype 16 . . . . . . . . . . . 13
8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4
4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 5
5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5
6. KDF Agility . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11
8. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Test Vector for SHA-256, enctype 18 . . . . . . . . . . . 13
8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Test Vector for SHA-512, enctype 16 . . . . . . . . . . . 13
8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
The Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard [RFC4556] defines several protocol structures that are either tied to SHA-1 [RFC6234] or do not support negotiation or discovery but are instead based on local policy:
Kerberos（PKINIT）标准[RFC4556]中用于初始身份验证的公钥加密定义了几个协议结构，这些协议结构要么与SHA-1[RFC6234]绑定，要么不支持协商或发现，而是基于本地策略：
o The checksum algorithm in the authentication request is hardwired to use SHA-1.
o 身份验证请求中的校验和算法通过硬连线使用SHA-1。
o The acceptable digest algorithms for signing the authentication data are not discoverable.
o 无法发现用于签名身份验证数据的可接受摘要算法。
o The key derivation function in Section 3.2.3.1 of [RFC4556] is hardwired to use SHA-1.
o [RFC4556]第3.2.3.1节中的关键推导函数是硬连线的，以使用SHA-1。
o The acceptable digest algorithms for signing the client X.509 certificates are not discoverable.
o 无法发现可接受的客户端X.509证书签名摘要算法。
In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] collisions [WANG04], alongside attacks on later hash functions including MD5 [RFC1321] and SHA-1 [RFC6234]. These attacks and their consequences are discussed in [RFC6194]. These discoveries challenged the security of protocols relying on the collision-resistance properties of these hashes.
2004年8月，王晓云的研究小组报告了MD4[RFC6150]碰撞[WANG04]，以及对后来的散列函数的攻击，包括MD5[RFC1321]和SHA-1[RFC6234]。[RFC6194]中讨论了这些攻击及其后果。这些发现对依赖于这些散列的抗冲突特性的协议的安全性提出了挑战。
The Internet Engineering Task Force (IETF) called for action to update existing protocols to provide crypto algorithm agility so that protocols support multiple cryptographic algorithms (including hash functions) and provide clean, tested transition strategies between algorithms, as recommended by BCP 201 [RFC7696].
互联网工程任务组（IETF）呼吁采取行动更新现有协议，以提供加密算法灵活性，从而使协议支持多种加密算法（包括哈希函数），并按照BCP 201[RFC7696]的建议，在算法之间提供干净、经过测试的过渡策略。
To address these concerns, new key derivation functions (KDFs), identified by object identifiers, are defined. The PKINIT client provides a list of KDFs in the request, and the Key Distribution Center (KDC) picks one in the response. Thus, a mutually supported KDF is negotiated.
为了解决这些问题，定义了由对象标识符标识的新密钥派生函数（KDF）。PKINIT客户端在请求中提供KDF列表，密钥分发中心（KDC）在响应中选择一个。因此，可以协商一个相互支持的KDF。
Furthermore, structures are defined to allow the client to discover the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms supported by the KDC for signing the pre-authentication data and the client X.509 certificate.
此外，定义的结构允许客户端发现KDC支持的加密消息语法（CMS）[RFC5652]摘要算法，用于签署预认证数据和客户端X.509证书。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The paChecksum defined in Section 3.2.1 of [RFC4556] provides a cryptographic binding between the client's pre-authentication data and the corresponding Kerberos request body. This also prevents the KDC-REQ body from being tampered with. SHA-1 is the only allowed checksum algorithm defined in [RFC4556]. This facility relies on the collision-resistance properties of the SHA-1 checksum [RFC6234].
[RFC4556]第3.2.1节中定义的paChecksum在客户端的预身份验证数据和相应的Kerberos请求主体之间提供加密绑定。这还可以防止KDC-REQ主体被篡改。SHA-1是[RFC4556]中定义的唯一允许的校验和算法。此功能依赖于SHA-1校验和[RFC6234]的抗碰撞特性。
When the reply key delivery mechanism is based on public key encryption as described in Section 3.2.3.2 of [RFC4556], the asChecksum in the KDC reply provides integrity protection for the unauthenticated clear text in these messages and the binding between the pre-authentication and the ticket request and response messages. However, if the reply key delivery mechanism is based on the Diffie-Hellman key agreement as described in Section 3.2.3.1 of [RFC4556],
当回复密钥传递机制基于[RFC4556]第3.2.3.2节所述的公钥加密时，KDC回复中的asChecksum为这些消息中未经验证的明文以及预认证与票证请求和响应消息之间的绑定提供完整性保护。但是，如果回复密钥交付机制基于[RFC4556]第3.2.3.1节所述的Diffie-Hellman密钥协议，
the security provided by using SHA-1 in the paChecksum is weak, and nothing else cryptographically binds the Authentication Service (AS) request to the ticket response. In this case, the new KDF selected by the KDC, as described in Section 6, provides the cryptographic binding and integrity protection.
在paChecksum中使用SHA-1所提供的安全性很弱，没有其他加密方式将身份验证服务（AS）请求绑定到票证响应。在这种情况下，KDC选择的新KDF（如第6节所述）提供加密绑定和完整性保护。
Section 3.2.2 of [RFC4556] is updated to add optional typed data to the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. When a KDC implementation conforming to this specification returns this error code, it MAY include a list of supported CMS types signifying the digest algorithms supported by the KDC in decreasing order of preference. This is accomplished by including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data.
[RFC4556]第3.2.2节已更新，将可选类型数据添加到KDC_ERR_DIGEST_IN_SIGNED_data_NOT_ACCEPTED error中。当符合本规范的KDC实现返回此错误代码时，它可能包括一个支持的CMS类型列表，表示KDC支持的摘要算法（按优先顺序递减）。这是通过在错误数据中包含TD_CMS_DATA_DIGEST_算法类型的数据元素来实现的。
td-cms-digest-algorithms INTEGER ::= 111
td-cms-digest-algorithms INTEGER ::= 111
The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains the TD-CMS-DIGEST-ALGORITHMS-DATA structure, which is ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded and is defined as follows:
TD_CMS_data_DIGEST_算法的对应数据包含TD-CMS-DIGEST-ALGORITHMS-data结构，该结构为ASN.1可分辨编码规则（DER）[X680][X690]编码，定义如下：
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- acceptable to the KDC for signing CMS data in
-- decreasing order of preference.
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- acceptable to the KDC for signing CMS data in
-- decreasing order of preference.
The algorithm identifiers in TD-CMS-DIGEST-ALGORITHMS identify the digest algorithms supported by the KDC.
TD-CMS-DIGEST-ALGORITHMS中的算法标识符标识KDC支持的摘要算法。
This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS can facilitate troubleshooting when none of the digest algorithms supported by the client is supported by the KDC.
当KDC不支持客户机支持的摘要算法时，KDC通过TD_CMS_DATA_DIGEST_算法发送的此信息有助于故障排除。
Section 3.2.2 of [RFC4556] is updated to add optional typed data to the KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. When a KDC conforming to this specification returns this error, it MAY send a list of digest algorithms acceptable to the KDC for use by the certification authority (CA) in signing the client's X.509 certificate in decreasing order of preference. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The corresponding data contains the ASN.1 DER encoding of the TD-CERT-DIGEST-ALGORITHMS-DATA structure defined as follows:
更新了[RFC4556]的第3.2.2节，将可选类型数据添加到KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error中。当符合本规范的KDC返回此错误时，它可以发送KDC可接受的摘要算法列表，以供证书颁发机构（CA）在签署客户端的X.509证书时按优先顺序递减。这是通过在错误数据中包含TD_CERT_DIGEST_算法类型的数据元素来实现的。相应的数据包含TD-CERT-DIGEST-ALGORITHMS-data结构的ASN.1 DER编码，定义如下：
td-cert-digest-algorithms INTEGER ::= 112
td-cert-digest-algorithms INTEGER ::= 112
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- that are used by the CA to sign the client's
-- X.509 certificate and are acceptable to the KDC
-- in the process of validating the client's X.509
-- certificate in decreasing order of
-- preference.
rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-- This identifies the digest algorithm that was
-- used to sign the client's X.509 certificate and
-- has been rejected by the KDC in the process of
-- validating the client's X.509 certificate
-- [RFC5280].
...
}
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- that are used by the CA to sign the client's
-- X.509 certificate and are acceptable to the KDC
-- in the process of validating the client's X.509
-- certificate in decreasing order of
-- preference.
rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-- This identifies the digest algorithm that was
-- used to sign the client's X.509 certificate and
-- has been rejected by the KDC in the process of
-- validating the client's X.509 certificate
-- [RFC5280].
...
}
The KDC fills in the allowedAlgorithm field with the list of algorithm [RFC5652] identifiers indicating digest algorithms that are used by the CA to sign the client's X.509 certificate and are acceptable to the KDC in the process of validating the client's X.509 certificate in decreasing order of preference. The rejectedAlgorithm field identifies the signing algorithm for use in signing the client's X.509 certificate that has been rejected by the KDC in the process of validating the client's certificate [RFC5280].
KDC用算法[RFC5652]标识符列表填充allowedAlgorithm字段，该标识符指示CA用于签署客户机X.509证书的摘要算法，并且KDC在验证客户机X.509证书的过程中可以按偏好的降序接受该摘要算法。rejectedAlgorithm字段标识用于对KDC在验证客户端证书过程中拒绝的客户端X.509证书进行签名的签名算法[RFC5280]。
Section 3.2.3.1 of [RFC4556] is updated to define additional key derivation functions (KDFs) to derive a Kerberos protocol key based on the secret value generated by the Diffie-Hellman key exchange. Section 3.2.1 of [RFC4556] is updated to add a new field to the AuthPack structure to indicate which new KDFs are supported by the client. Section 3.2.3 of [RFC4556] is updated to add a new field to the DHRepInfo structure to indicate which KDF is selected by the KDC.
[RFC4556]的第3.2.3.1节已更新，以定义额外的密钥派生函数（KDF），根据Diffie-Hellman密钥交换生成的秘密值派生Kerberos协议密钥。[RFC4556]的第3.2.1节已更新，以向AuthPack结构添加一个新字段，以指示客户端支持哪些新KDF。[RFC4556]的第3.2.3节已更新，以向DHRepInfo结构添加一个新字段，以指示KDC选择的KDF。
The KDF algorithm described in this document (based on [SP80056A]) can be implemented using any cryptographic hash function.
本文档中描述的KDF算法（基于[SP80056A]）可以使用任何加密哈希函数实现。
A new KDF for PKINIT usage is identified by an object identifier. The following KDF object identifiers are defined:
PKINIT使用的新KDF由对象标识符标识。定义了以下KDF对象标识符：
id-pkinit OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit (3) }
-- Defined in RFC 4556 and quoted here for the reader.
id-pkinit OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit (3) }
-- Defined in RFC 4556 and quoted here for the reader.
id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
-- PKINIT KDFs
id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
-- PKINIT KDFs
id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha1(1) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-1
id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha1(1) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-1
id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha256(2) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-256
id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha256(2) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-256
id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha512(3) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-512
id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha512(3) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-512
id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha384(4) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-384
id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha384(4) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-384
Where id-pkinit is defined in [RFC4556]. All key derivation functions specified above use the one-step key derivation method described in Section 5.8.2.1 of [SP80056A], choosing the ASN.1 format for FixedInfo, and Section 4.1 of [SP80056C], choosing option 1 for the auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234] as the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-sha356, and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384 [RFC6234], and SHA-512 [RFC6234], respectively.
其中，[RFC4556]中定义了id pkinit。上面指定的所有密钥派生函数都使用[SP80056A]第5.8.2.1节中描述的一步密钥派生方法，为FixedInfo选择ASN.1格式，[SP80056C]第4.1节为辅助函数H选择选项1。id-pkinit-kdf-ah-sha1使用SHA-1[RFC6234]作为哈希函数。id-pkinit-kdf-ah-sha256、id-pkinit-kdf-ah-sha356和id-pkinit-kdf-ah-sha512分别使用SHA-256[RFC6234]、SHA-384[RFC6234]和SHA-512[RFC6234]。
To name the input parameters, an abbreviated version of the key derivation method is described below.
为了命名输入参数，下面描述了密钥派生方法的缩写版本。
1. reps = ceiling(L/H_outputBits)
1. 重复次数=上限（L/H_输出位）
2. Initialize a 32-bit, big-endian bit string counter as 1.
2. 将32位大端位字符串计数器初始化为1。
3. For i = 1 to reps by 1, do the following:
3. 对于i=1到1的重复次数，请执行以下操作：
1. Compute Hashi = H(counter || Z || OtherInfo).
1. 计算Hashi=H（计数器| | Z | |其他信息）。
2. Increment counter (not to exceed 2^32-1)
2. 增量计数器（不超过2^32-1）
4. Set key_material = Hash1 || Hash2 || ... so that the length of key_material is L bits, truncating the last block as necessary.
4. 设置键|material=Hash1 | | Hash2 | |。。。因此，key_材质的长度为L位，根据需要截断最后一个块。
5. The above KDF produces a bit string of length L in bits as the keying material. The AS reply key is the output of random-to-key() [RFC3961], using that keying material as the input.
5. 上述KDF生成一个长度为L的位字符串（以位为单位）作为键控材料。AS reply键是random-to-key（）[RFC3961]的输出，使用该键控材质作为输入。
The input parameters for these KDFs are provided as follows:
这些KDF的输入参数如下所示：
o H_outputBits is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and 512 bits for id-pkinit-kdf-ah-sha512.
o H_输出位对于id-pkinit-kdf-ah-sha1为160位，对于id-pkinit-kdf-ah-sha256为256位，对于id-pkinit-kdf-ah-sha384为384位，对于id-pkinit-kdf-ah-sha512为512位。
o max_H_inputBits is 2^64.
o 最大输入位为2^64。
o The secret value (Z) is the shared secret value generated by the Diffie-Hellman exchange. The Diffie-Hellman shared value is first padded with leading zeros such that the size of the secret value in octets is the same as that of the modulus, then represented as a string of octets in big-endian order.
o 秘密值（Z）是由Diffie-Hellman交换生成的共享秘密值。Diffie-Hellman共享值首先用前导零填充，以便以八位字节表示的秘密值的大小与模的大小相同，然后以大端顺序表示为八位字节字符串。
o The key data length (L) is the key-generation seed length in bits [RFC3961] for the Authentication Service (AS) reply key. The enctype of the AS reply key is selected according to [RFC4120].
o 密钥数据长度（L）是认证服务（AS）应答密钥的密钥生成种子长度，单位为位[RFC3961]。AS应答密钥的类型根据[RFC4120]选择。
o The algorithm identifier (algorithmID) input parameter is the identifier of the respective KDF. For example, this is id-pkinit-kdf-ah-sha1 if the KDF uses SHA-1 as the hash.
o 算法标识符（algorithmID）输入参数是相应KDF的标识符。例如，如果kdf使用SHA-1作为散列，则这是id-pkinit-kdf-ah-sha1。
o The initiator identifier (partyUInfo) contains the ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that identifies the client as specified in the AS-REQ [RFC4120] in the request.
o 启动器标识符（partyUInfo）包含KRB5 PrincipalName[RFC4556]的ASN.1 DER编码，该编码按照请求中as-REQ[RFC4120]中的规定标识客户机。
o The recipient identifier (partyVInfo) contains the ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that identifies the ticket-granting server (TGS) as specified in the AS-REQ [RFC4120] in the request.
o 接收方标识符（partyVInfo）包含Krb5 PrincipalName[RFC4556]的ASN.1 DER编码，该编码按照请求中as-REQ[RFC4120]中的规定标识票证授予服务器（TGS）。
o The supplemental public information (suppPubInfo) is the ASN.1 DER encoding of the PkinitSuppPubInfo structure, as defined later in this section.
o 补充公共信息（suppPubInfo）是PkinitSuppPubInfo结构的ASN.1 DER编码，如本节后面所定义。
o The supplemental private information (suppPrivInfo) is absent.
o 缺少补充的私人信息（supplivinfo）。
OtherInfo is the ASN.1 DER encoding of the following sequence:
OtherInfo是以下序列的ASN.1顺序编码：
OtherInfo ::= SEQUENCE {
algorithmID AlgorithmIdentifier,
partyUInfo [0] OCTET STRING,
partyVInfo [1] OCTET STRING,
suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL
}
OtherInfo ::= SEQUENCE {
algorithmID AlgorithmIdentifier,
partyUInfo [0] OCTET STRING,
partyVInfo [1] OCTET STRING,
suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL
}
The PkinitSuppPubInfo structure is defined as follows:
PkinitSuppPubInfo结构定义如下：
PkinitSuppPubInfo ::= SEQUENCE {
enctype [0] Int32,
-- The enctype of the AS reply key.
as-REQ [1] OCTET STRING,
-- The DER encoding of the AS-REQ [RFC4120] from the
-- client.
pk-as-rep [2] OCTET STRING,
-- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
-- KDC reply.
...
}
PkinitSuppPubInfo ::= SEQUENCE {
enctype [0] Int32,
-- The enctype of the AS reply key.
as-REQ [1] OCTET STRING,
-- The DER encoding of the AS-REQ [RFC4120] from the
-- client.
pk-as-rep [2] OCTET STRING,
-- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
-- KDC reply.
...
}
The PkinitSuppPubInfo structure contains mutually known public information specific to the authentication exchange. The enctype field is the enctype of the AS reply key as selected according to [RFC4120]. The as-REQ field contains the DER encoding of the AS-REQ type [RFC4120] in the request sent from the client to the KDC. Note that the as-REQ field does not include the wrapping 4-octet length when TCP is used. The pk-as-rep field contains the DER encoding of the PA-PK-AS-REP [RFC4556] type in the KDC reply. The PkinitSuppPubInfo provides a cryptographic binding between the pre-authentication data and the corresponding ticket request and response, thus addressing the concerns described in Section 3.
PkinitSuppPubInfo结构包含特定于身份验证交换的已知公共信息。enctype字段是根据[RFC4120]选择的AS应答密钥的enctype。as REQ字段包含从客户端发送到KDC的请求中as-REQ类型[RFC4120]的DER编码。请注意，使用TCP时，as REQ字段不包括包装4个八位字节的长度。pk as rep字段包含KDC应答中PA-pk-as-rep[RFC4556]类型的DER编码。PkinitSuppPubInfo在预认证数据和相应的票证请求和响应之间提供了加密绑定，从而解决了第3节中描述的问题。
The KDF is negotiated between the client and the KDC. The client sends an unordered set of supported KDFs in the request, and the KDC picks one from the set in the reply.
KDF在客户机和KDC之间协商。客户机在请求中发送一组无序的受支持KDF，KDC从应答中选择一个。
To accomplish this, the AuthPack structure in [RFC4556] is extended as follows:
为此，[RFC4556]中的AuthPack结构扩展如下：
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
clientDHNonce [3] DHNonce OPTIONAL,
...,
supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
-- Contains an unordered set of KDFs supported by the
-- client.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
clientDHNonce [3] DHNonce OPTIONAL,
...,
supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
-- Contains an unordered set of KDFs supported by the
-- client.
...
}
KDFAlgorithmId ::= SEQUENCE {
kdf-id [0] OBJECT IDENTIFIER,
-- The object identifier of the KDF
...
}
KDFAlgorithmId ::= SEQUENCE {
kdf-id [0] OBJECT IDENTIFIER,
-- The object identifier of the KDF
...
}
The new supportedKDFs field contains an unordered set of KDFs supported by the client.
新的supportedKDFs字段包含客户端支持的无序KDF集。
The KDFAlgorithmId structure contains an object identifier that identifies a KDF. The algorithm of the KDF and its parameters are defined by the corresponding specification of that KDF.
KDFAlgorithmId结构包含标识KDF的对象标识符。KDF的算法及其参数由该KDF的相应规范定义。
The DHRepInfo structure in [RFC4556] is extended as follows:
[RFC4556]中的DHRepInfo结构扩展如下：
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL,
...,
kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC.
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL,
...,
kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC.
...
}
The new kdf field in the extended DHRepInfo structure identifies the KDF picked by the KDC. If the supportedKDFs field is present in the request, a KDC conforming to this specification MUST choose one of the KDFs supported by the client and indicate its selection in the kdf field in the reply. If the supportedKDFs field is absent in the request, the KDC MUST omit the kdf field in the reply and use the key
扩展DHRepInfo结构中的新kdf字段标识KDC拾取的kdf。如果请求中存在supportedKDFs字段，则符合本规范的KDC必须选择客户端支持的kdf之一，并在回复中的kdf字段中指出其选择。如果请求中缺少supportedKDFs字段，KDC必须在应答中省略kdf字段并使用密钥
derivation function from Section 3.2.3.1 of [RFC4556]. If none of the KDFs supported by the client is acceptable to the KDC, the KDC MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF:
[RFC4556]第3.2.3.1节中的衍生函数。如果KDC不接受客户端支持的KDF，KDC必须使用新的错误代码KDC_ERR_NO_acceptable_KDF进行回复：
o KDC_ERR_NO_ACCEPTABLE_KDF 100
o KDC_错误_否_可接受_KDF 100
If the client fills the supportedKDFs field in the request but the kdf field in the reply is not present, the client can deduce that the KDC is not updated to conform with this specification, or that the exchange was subjected to a downgrade attack. It is a matter of local policy on the client whether to reject the reply when the kdf field is absent in the reply; if compatibility with non-updated KDCs is not a concern, the reply should be rejected.
如果客户端在请求中填写supportedKDFs字段，但答复中的kdf字段不存在，则客户端可以推断KDC未更新以符合此规范，或者exchange受到降级攻击。当回复中缺少kdf字段时，是否拒绝回复是客户端的本地策略问题；如果与未更新的KDC的兼容性不是问题，则应拒绝回复。
Implementations conforming to this specification MUST support id-pkinit-kdf-ah-sha256.
符合本规范的实现必须支持id-pkinit-kdf-ah-sha256。
An old client interoperating with a new KDC will not recognize a TD-CMS-DIGEST-ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error or a TD-CERT-DIGEST-ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. Because the error data is encoded as typed data, the client will ignore the unrecognized elements.
与新KDC互操作的旧客户端将无法识别KDC_ERR_DIGEST_in_SIGNED_DATA_not_ACCEPTED error_或KDC_ERR_DIGEST_in_CERT_not_ACCEPTED error_中的TD-CMS-DIGEST-ALGORITHMS-DATA元素或KDC_ERR_DIGEST_中的TD-CERT-DIGEST-ALGORITHMS-DATA元素。由于错误数据被编码为类型化数据，客户端将忽略无法识别的元素。
An old KDC interoperating with a new client will not include a TD-CMS-DIGEST-ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error or a TD-CERT-DIGEST-ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. To the client, this appears just as if a new KDC elected not to include a list of digest algorithms.
与新客户端交互的旧KDC不会在KDC_ERR_DIGEST_in_SIGNED_DATA_not_ACCEPTED error_中包含TD-CMS-DIGEST-ALGORITHMS-DATA元素，也不会在KDC_ERR_DIGEST_in_CERT_not_ACCEPTED error中包含TD-CERT-DIGEST-ALGORITHMS-DATA元素。对于客户机来说，这就像一个新的KDC选择不包含摘要算法列表一样。
An old client interoperating with a new KDC will not include the supportedKDFs field in the request. The KDC MUST omit the kdf field in the reply and use the [RFC4556] KDF as expected by the client or reject the request if local policy forbids use of the old KDF.
与新KDC互操作的旧客户端将不会在请求中包含supportedKDFs字段。KDC必须在回复中省略kdf字段，并按照客户机的预期使用[RFC4556]kdf，或者在本地策略禁止使用旧kdf的情况下拒绝请求。
A new client interoperating with an old KDC will include the supportedKDFs field in the request; this field will be ignored as an unknown extension by the KDC. The KDC will omit the kdf field in the reply and will use the [RFC4556] KDF. The client can deduce from the omitted kdf field that the KDC is not updated to conform to this specification or that the exchange was subjected to a downgrade attack. The client MUST use the [RFC4556] KDF or reject the reply if local policy forbids the use of the old KDF.
与旧KDC互操作的新客户端将在请求中包含supportedKDFs字段；KDC将忽略此字段作为未知扩展。KDC将在应答中省略kdf字段，并使用[RFC4556]kdf。客户机可以从省略的kdf字段推断KDC未更新以符合此规范，或者exchange受到降级攻击。如果本地策略禁止使用旧KDF，则客户端必须使用[RFC4556]KDF或拒绝回复。
This section contains test vectors for the KDF defined above.
本节包含上面定义的KDF的测试向量。
Z: Length = 256 bytes, Hex Representation = (All Zeros)
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
Z: Length = 256 bytes, Hex Representation = (All Zeros)
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
client: Length = 9 bytes, ASCII Representation = lha@SU.SE
client: Length = 9 bytes, ASCII Representation = lha@SU.SE
server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE
server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE
as-req: Length = 10 bytes, Hex Representation = AAAAAAAA AAAAAAAA AAAA
as req:Length=10字节，十六进制表示法=AAAAAAAA AAAAA
pk-as-rep: Length = 9 bytes, Hex Representation = BBBBBBBB BBBBBBBB BB
pk作为代表：长度=9字节，十六进制表示法=bbbbbbbbbbbbbbbb
ticket: Length = 55 bytes, Hex Representation = 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 036C6861 A311300F A0030201 12A20804 0668656A 68656A
票证：长度=55字节，十六进制表示=61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 036C6861 A311300F A0030201 12A20804 0668656A 68656A
algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex Representation = 2B060105 02030601
算法id：（id-pkinit-kdf-ah-sha1）长度=8字节，十六进制表示=2B060102030601
enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal Representation = 18
enctype：（aes256-cts-hmac-sha1-96）长度=1字节，十进制表示=18
key-material: Length = 32 bytes, Hex Representation = E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
关键材料：长度=32字节，十六进制表示法=E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A73C04E E6649614 206F73AD
key: Length = 32 bytes, Hex Representation = E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
键：长度=32字节，十六进制表示法=E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A73C04E E6649614 206F73AD
algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex Representation = 2B060105 02030602
算法id：（id-pkinit-kdf-ah-sha256）长度=8字节，十六进制表示=2B060105020306602
enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal Representation = 18
enctype：（aes256-cts-hmac-sha1-96）长度=1字节，十进制表示=18
key-material: Length = 32 bytes, Hex Representation = 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
关键材料：长度=32字节，十六进制表示法=77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
key: Length = 32 bytes, Hex Representation = 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
键：长度=32字节，十六进制表示法=77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex Representation = 2B060105 02030603
算法id：（id-pkinit-kdf-ah-sha512）长度=8字节，十六进制表示=2B060105020306
enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16
enctype：（des3-cbc-sha1-kd）长度=1字节，十进制表示=16
key-material: Length = 24 bytes, Hex Representation = D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
关键材料：长度=24字节，十六进制表示法=D3C78A79 D6521EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
key: Length = 32 bytes, Hex Representation = D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
键：长度=32字节，十六进制表示法=D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB6 FB01DAD6
This document describes negotiation of checksum types, key derivation functions, and other cryptographic functions. If a given negotiation is unauthenticated, care must be taken to accept only secure values; to do otherwise allows an active attacker to perform a downgrade attack.
本文档描述校验和类型、密钥派生函数和其他加密函数的协商。如果给定的协商未经验证，则必须注意只接受安全值；否则将允许活动攻击者执行降级攻击。
The discovery method described in Section 4 uses a Kerberos error message, which is unauthenticated in a typical exchange. An attacker may attempt to downgrade a client to a weaker CMS type by forging a KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is a matter of
第4节中描述的发现方法使用Kerberos错误消息，该消息在典型的exchange中未经身份验证。攻击者可能试图通过伪造KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED错误，将客户端降级为较弱的CMS类型。这是个问题
local policy whether a client accepts a downgrade to a weaker CMS type and whether the KDC accepts the weaker CMS type. A client may reasonably assume that the real KDC implements all hash functions used in the client's X.509 certificate, and so the client may refuse attempts to downgrade to weaker hash functions.
本地策略—客户端是否接受降级为较弱的CMS类型，KDC是否接受较弱的CMS类型。客户机可以合理地假设真正的KDC实现了客户机的X.509证书中使用的所有哈希函数，因此客户机可以拒绝降级为较弱的哈希函数的尝试。
The discovery method described in Section 5 also uses a Kerberos error message. An attacker may attempt to downgrade a client to a certificate using a weaker signing algorithm by forging a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local policy whether a client accepts a downgrade to a weaker certificate and whether the KDC accepts the weaker certificate. This attack is only possible if the client device possesses multiple client certificates of varying strengths.
第5节中描述的发现方法也使用Kerberos错误消息。攻击者可能试图通过伪造KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED错误，使用较弱的签名算法将客户端降级为证书。客户端是否接受降级为较弱的证书以及KDC是否接受较弱的证书是本地策略的问题。只有当客户端设备拥有多个不同强度的客户端证书时，才可能发生此攻击。
In the KDF negotiation method described in Section 6, the client supportedKDFs value is protected by the signature on the signedAuthPack field in the request. If this signature algorithm is vulnerable to collision attacks, an attacker may attempt to downgrade the negotiation by substituting an AuthPack with a different or absent supportedKDFs value, using a PKINIT freshness token [RFC8070] to partially control the legitimate AuthPack value. A client that is performing anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker can easily remove the supportedKDFs value in this case. Finally, the kdf field in the DHRepInfo of the KDC response is unauthenticated and could be altered or removed by an attacker, although this alteration will likely result in a decryption failure by the client rather than a successful downgrade. It is a matter of local policy whether a client accepts a downgrade to the old KDF and whether the KDC allows the use of the old KDF.
在第6节描述的KDF协商方法中，客户端支持的KDFS值受请求中signedAuthPack字段上的签名保护。如果此签名算法易受冲突攻击，则攻击者可尝试通过使用不同或不存在的supportedKDFs值替换AuthPack，并使用PKINIT新鲜度令牌[RFC8070]部分控制合法的AuthPack值来降级协商。执行匿名PKINIT[RFC8062]的客户端不会对AuthPack进行签名，因此在这种情况下，攻击者可以轻松删除supportedKDFs值。最后，KDC响应的DHRepInfo中的kdf字段未经身份验证，攻击者可能会更改或删除该字段，尽管此更改可能会导致客户端解密失败，而不是成功降级。客户机是否接受降级到旧KDF以及KDC是否允许使用旧KDF是本地策略的问题。
The paChecksum field, which binds the client pre-authentication data to the Kerberos request body, remains fixed at SHA-1. If an attacker substitutes a different request body using an attack against SHA-1 (a second preimage attack is likely required as the attacker does not control any part of the legitimate request body), the KDC will not detect the substitution. Instead, if a new KDF is negotiated, the client will detect the substitution by failing to decrypt the reply.
将客户端预身份验证数据绑定到Kerberos请求主体的paChecksum字段保持固定在SHA-1。如果攻击者使用针对SHA-1的攻击替换不同的请求正文（由于攻击者不控制合法请求正文的任何部分，因此可能需要第二次前映像攻击），KDC将不会检测到替换。相反，如果协商了一个新的KDF，客户机将通过无法解密回复来检测替换。
An attacker may attempt to impersonate the KDC to the client via an attack on the hash function used in the dhSignedData signature, substituting the attacker's subjectPublicKey for the legitimate one without changing the hash value. It is a matter of local policy which hash function the KDC uses in its signature and which hash functions the client will accept in the KDC signature. A KDC may reasonably assume that the client implements all hash functions used in the KDF algorithms listed the supportedKDFs field of the request.
攻击者可能试图通过攻击dhSignedData签名中使用的哈希函数向客户端模拟KDC，用攻击者的subjectPublicKey替换合法密钥，而不更改哈希值。KDC在其签名中使用哪个哈希函数以及客户端在KDC签名中接受哪个哈希函数是本地策略的问题。KDC可以合理地假设客户端实现请求的supportedKDFs字段中列出的KDF算法中使用的所有哈希函数。
IANA has made the following assignments in the Kerberos "Pre-authentication and Typed Data" registry created by Section 7.1 of RFC 6113.
IANA在RFC 6113第7.1节创建的Kerberos“预验证和类型化数据”注册表中进行了以下分配。
TD-CMS-DIGEST-ALGORITHMS 111 [RFC8636] TD-CERT-DIGEST-ALGORITHMS 112 [RFC8636]
TD-CMS-DIGEST-ALGORITHMS 111[RFC8636]TD-CERT-DIGEST-ALGORITHMS 112[RFC8636]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 2005, <https://www.rfc-editor.org/info/rfc3961>.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，DOI 10.17487/RFC3961，2005年2月<https://www.rfc-editor.org/info/rfc3961>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC 4120，DOI 10.17487/RFC4120，2005年7月<https://www.rfc-editor.org/info/rfc4120>.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, DOI 10.17487/RFC4556, June 2006, <https://www.rfc-editor.org/info/rfc4556>.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 4556，DOI 10.17487/RFC4556，2006年6月<https://www.rfc-editor.org/info/rfc4556>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<https://www.rfc-editor.org/info/rfc6234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[SP80056A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publications 800-56A, Revision 3, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>.
[SP80056A]Barker，E.，Chen，L.，Roginsky，A.，Vassilev，A.，和R.Davis，“使用离散对数加密的成对密钥建立方案的建议”，NIST特别出版物800-56A，第3版，DOI 10.6028/NIST.SP.800-56Ar3，2018年4月<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>。
[SP80056C] Barker, E., Chen, L., and R. Davis, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes", NIST Special Publications 800-56C, Revision 1, DOI 10.6028/NIST.SP.800-56Cr1, April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Cr1.pdf>.
[SP80056C]Barker，E.，Chen，L.，和R.Davis，“关键设施计划中关键推导方法的建议”，NIST特别出版物800-56C，第1版，DOI 10.6028/NIST.SP.800-56Cr1，2018年4月<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Cr1.pdf>。
[X680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, August 2015, <https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
[X680]ITU-T，“信息技术-抽象语法符号1（ASN.1）：基本符号规范”，ITU-T建议X.680，2015年8月<https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, August 2015, <https://www.itu.int/rec/T-REC-X.690-201508-I/en>.
[X690]ITU-T，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，2015年8月<https://www.itu.int/rec/T-REC-X.690-201508-I/en>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC 1321，DOI 10.17487/RFC1321，1992年4月<https://www.rfc-editor.org/info/rfc1321>.
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, DOI 10.17487/RFC6150, March 2011, <https://www.rfc-editor.org/info/rfc6150>.
[RFC6150]Turner，S.和L.Chen，“MD4的历史地位”，RFC 6150，DOI 10.17487/RFC6150，2011年3月<https://www.rfc-editor.org/info/rfc6150>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <https://www.rfc-editor.org/info/rfc6194>.
[RFC6194]Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 6194，DOI 10.17487/RFC6194，2011年3月<https://www.rfc-editor.org/info/rfc6194>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.
[RFC7696]Housley，R.，“加密算法敏捷性和选择强制算法的指南”，BCP 201，RFC 7696，DOI 10.17487/RFC7696，2015年11月<https://www.rfc-editor.org/info/rfc7696>.
[RFC8062] Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed., "Anonymity Support for Kerberos", RFC 8062, DOI 10.17487/RFC8062, February 2017, <https://www.rfc-editor.org/info/rfc8062>.
[RFC8062]Zhu，L.，Leach，P.，Hartman，S.，和S.Emery，Ed.，“Kerberos的匿名性支持”，RFC 8062，DOI 10.17487/RFC8062，2017年2月<https://www.rfc-editor.org/info/rfc8062>.
[RFC8070] Short, M., Ed., Moore, S., and P. Miller, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension", RFC 8070, DOI 10.17487/RFC8070, February 2017, <https://www.rfc-editor.org/info/rfc8070>.
[RFC8070]Short，M.，Ed.，Moore，S.，和P.Miller，“Kerberos（PKINIT）新鲜度扩展中初始身份验证的公钥加密”，RFC 8070，DOI 10.17487/RFC8070，2017年2月<https://www.rfc-editor.org/info/rfc8070>.
[WANG04] Wang, X., Lai, X., Feng, D., Chen, H., and X. Yu, "Cryptanalysis of the Hash Functions MD4 and RIPEMD", Advances in Cryptology - EUROCRYPT 2005, DOI 10.1007/11426639_1, August 2004.
[WANG04]Wang，X.，Lai，X.，Feng，D.，Chen，H.，和X.Yu，“散列函数MD4和RIPEMD的密码分析”，密码学进展-EUROCRYPT 2005，DOI 10.1007/11426639_12004年8月。
KerberosV5-PK-INIT-Agility-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
KerberosV5-PK-INIT-Agility-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS AlgorithmIdentifier, SubjectPublicKeyInfo 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 5280.
从PKIX1Explicit88{iso（1）已识别组织（3）国防部（6）互联网（1）安全（5）机制（5）pkix（7）id mod（0）id-pkix1-explicit（18）}导入算法标识符SubjectPublicKeyInfo，如RFC 5280中所定义。
Ticket, Int32, 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.
票证、Int32、领域、加密密钥、来自KerberosV5Spec2的校验和{iso（1）确定的组织（3）国防部（6）互联网（1）安全（5）kerberosV5（2）模块（4）krb5spec2（2）}——如RFC 4120所定义。
PKAuthenticator, DHNonce, id-pkinit
FROM KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) };
-- as defined in RFC 4556.
PKAuthenticator, DHNonce, id-pkinit
FROM KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) };
-- as defined in RFC 4556.
id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
-- PKINIT KDFs
id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
-- PKINIT KDFs
id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha1(1) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-1
id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha1(1) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-1
id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha256(2) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-256
id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha256(2) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-256
id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha512(3) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-512
id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha512(3) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-512
id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha384(4) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-384
id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha384(4) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-384
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- acceptable to the KDC for signing CMS data in
-- decreasing order of preference.
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- acceptable to the KDC for signing CMS data in
-- decreasing order of preference.
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- that are used by the CA to sign the client's
-- X.509 certificate and are acceptable to the KDC
-- in the process of validating the client's X.509
-- certificate in decreasing order of
-- preference.
rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-- This identifies the digest algorithm that was
-- used to sign the client's X.509 certificate and
-- has been rejected by the KDC in the process of
-- validating the client's X.509 certificate
-- [RFC5280].
...
}
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms
-- that are used by the CA to sign the client's
-- X.509 certificate and are acceptable to the KDC
-- in the process of validating the client's X.509
-- certificate in decreasing order of
-- preference.
rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-- This identifies the digest algorithm that was
-- used to sign the client's X.509 certificate and
-- has been rejected by the KDC in the process of
-- validating the client's X.509 certificate
-- [RFC5280].
...
}
OtherInfo ::= SEQUENCE {
algorithmID AlgorithmIdentifier,
partyUInfo [0] OCTET STRING,
partyVInfo [1] OCTET STRING,
suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL
}
OtherInfo ::= SEQUENCE {
algorithmID AlgorithmIdentifier,
partyUInfo [0] OCTET STRING,
partyVInfo [1] OCTET STRING,
suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL
}
PkinitSuppPubInfo ::= SEQUENCE {
enctype [0] Int32,
-- The enctype of the AS reply key.
as-REQ [1] OCTET STRING,
-- The DER encoding of the AS-REQ [RFC4120] from the
-- client.
pk-as-rep [2] OCTET STRING,
-- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
-- KDC reply.
...
}
PkinitSuppPubInfo ::= SEQUENCE {
enctype [0] Int32,
-- The enctype of the AS reply key.
as-REQ [1] OCTET STRING,
-- The DER encoding of the AS-REQ [RFC4120] from the
-- client.
pk-as-rep [2] OCTET STRING,
-- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
-- KDC reply.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
clientDHNonce [3] DHNonce OPTIONAL,
...,
supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
-- Contains an unordered set of KDFs supported by the
-- client.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
clientDHNonce [3] DHNonce OPTIONAL,
...,
supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
-- Contains an unordered set of KDFs supported by the
-- client.
...
}
KDFAlgorithmId ::= SEQUENCE {
kdf-id [0] OBJECT IDENTIFIER,
-- The object identifier of the KDF
...
}
KDFAlgorithmId ::= SEQUENCE {
kdf-id [0] OBJECT IDENTIFIER,
-- The object identifier of the KDF
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL,
...,
kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC.
...
}
END
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL,
...,
kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC.
...
}
END
Acknowledgements
致谢
Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk, Scott Bradner, and Eric Rescorla reviewed the document and provided suggestions for improvements.
Jeffery Hutzelman、Shawn Emery、Tim Polk、Kelley Burgin、Ben Kaduk、Scott Bradner和Eric Rescorla审查了该文件，并提供了改进建议。
Authors' Addresses
作者地址
Love Hornquist Astrand Apple, Inc Cupertino, CA United States of America
Love Hornquist Astrand Apple，Inc.美国加利福尼亚州库比蒂诺市
Email: lha@apple.com
Email: lha@apple.com
Larry Zhu Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 United States of America
Larry Zhu甲骨文公司美国加利福尼亚州红木海岸甲骨文公园路500号，邮编94065
Email: larryzhu@live.com
Email: larryzhu@live.com
Margaret Cullen Painless Security 4 High St, Suite 134 North Andover, MA 01845 United States of America
Margaret Cullen无痛安全美国马萨诸塞州北安多佛市高街4号134室01845
Phone: +1 781-405-7464
Email: margaret@painless-security.com
Phone: +1 781-405-7464
Email: margaret@painless-security.com
Greg Hudson MIT
格雷格·哈德森麻省理工学院
Email: ghudson@mit.edu
Email: ghudson@mit.edu