Internet Engineering Task Force (IETF) M. Short, Ed.
Request for Comments: 8070 S. Moore
Category: Standards Track P. Miller
ISSN: 2070-1721 Microsoft Corporation
February 2017
Internet Engineering Task Force (IETF) M. Short, Ed.
Request for Comments: 8070 S. Moore
Category: Standards Track P. Miller
ISSN: 2070-1721 Microsoft Corporation
February 2017
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension
Kerberos（PKINIT）新鲜度扩展中用于初始身份验证的公钥加密
Abstract
摘要
This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange.
本文档描述了如何在Kerberos（PKINIT）扩展（在RFC 4556中定义）中进一步扩展用于初始身份验证的公钥加密，以交换密钥分发中心（KDC）可以验证的不透明数据块，以确保客户端当前在PKINIT身份验证服务期间拥有私钥（如）交换。
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 http://www.rfc-editor.org/info/rfc8070.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8070.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Kerberos Message Flow Using KRB_AS_REQ without
Pre-authentication .........................................3
1.2. Requirements Language ......................................3
2. Message Exchanges ...............................................4
2.1. Generation of KRB_AS_REQ Message ...........................4
2.2. Generation of KRB_ERROR Message ............................4
2.3. Generation of KRB_AS_REQ Message ...........................4
2.4. Receipt of KRB_AS_REQ Message ..............................5
2.5. Receipt of Second KRB_ERROR Message ........................5
3. PreAuthentication Data Types ....................................5
4. Extended PKAuthenticator ........................................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................7
7. Interoperability Considerations .................................7
8. Normative References ............................................8
Acknowledgements ...................................................8
Authors' Addresses .................................................9
1. Introduction ....................................................2
1.1. Kerberos Message Flow Using KRB_AS_REQ without
Pre-authentication .........................................3
1.2. Requirements Language ......................................3
2. Message Exchanges ...............................................4
2.1. Generation of KRB_AS_REQ Message ...........................4
2.2. Generation of KRB_ERROR Message ............................4
2.3. Generation of KRB_AS_REQ Message ...........................4
2.4. Receipt of KRB_AS_REQ Message ..............................5
2.5. Receipt of Second KRB_ERROR Message ........................5
3. PreAuthentication Data Types ....................................5
4. Extended PKAuthenticator ........................................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................7
7. Interoperability Considerations .................................7
8. Normative References ............................................8
Acknowledgements ...................................................8
Authors' Addresses .................................................9
The Kerberos PKINIT extension [RFC4556] defines two schemes for using asymmetric cryptography in a Kerberos pre-authenticator. One uses Diffie-Hellman key exchange and the other depends on public key encryption. The public key encryption scheme is less commonly used for two reasons:
Kerberos PKINIT扩展[RFC4556]定义了两种在Kerberos预身份验证程序中使用非对称加密的方案。一个使用Diffie-Hellman密钥交换，另一个依赖于公钥加密。由于两个原因，公钥加密方案不太常用：
o Elliptic Curve Cryptography (ECC) Support for PKINIT [RFC5349] only specified Elliptic Curve Diffie-Hellman (ECDH) key agreement, so it cannot be used for public key encryption.
o 椭圆曲线密码（ECC）对PKINIT的支持[RFC5349]仅指定了椭圆曲线Diffie-Hellman（ECDH）密钥协议，因此不能用于公钥加密。
o Public key encryption requires certificates with an encryption key, which is not deployed on many existing smart cards.
o 公钥加密需要具有加密密钥的证书，这在许多现有智能卡上都没有部署。
In the Diffie-Hellman exchange, the client uses its private key only to sign the AuthPack structure (specified in Section 3.2.1 of [RFC4556]), which is performed before any traffic is sent to the KDC. Thus, a client can generate requests with future times in the PKAuthenticator, and then send those requests at those future times. Unless the time is outside the validity period of the client's certificate, the KDC will validate the PKAuthenticator and return a Ticket-Granting Ticket (TGT) the client can use without possessing the private key.
在Diffie-Hellman交换中，客户端仅使用其私钥对AuthPack结构（在[RFC4556]第3.2.1节中指定）进行签名，该结构在任何通信发送到KDC之前执行。因此，客户端可以在PKAuthenticator中生成未来时间的请求，然后在未来时间发送这些请求。除非时间超出了客户端证书的有效期，否则KDC将验证PKAuthenticator并返回一个票据授予票据（TGT），客户端可以在不拥有私钥的情况下使用该票据。
As a result, a client performing PKINIT with the Diffie-Hellman key exchange does not prove current possession of the private key being used for authentication. It proves only prior use of that key. Ensuring that the client has current possession of the private key requires that the signed PKAuthenticator data include information that the client could not have predicted.
结果，使用Diffie-Hellman密钥交换执行PKINIT的客户端不能证明当前拥有用于身份验证的私钥。它只能证明之前使用过那把钥匙。要确保客户端当前拥有私钥，需要签名的PKAuthenticator数据包含客户端无法预测的信息。
Today, password-based AS exchanges [RFC4120] often begin with the client sending a KRB_AS_REQ without pre-authentication. When the principal requires pre-authentication, the KDC responds with a KRB_ERROR containing information needed to complete an AS exchange, such as the supported encryption types and salt values. This message flow is illustrated below:
今天，基于密码的AS交换[RFC4120]通常从客户端发送KRB_AS_请求开始，而无需预先验证。当主体需要预身份验证时，KDC会响应一个KRB_错误，其中包含完成AS交换所需的信息，例如支持的加密类型和salt值。此消息流如下所示：
Client KDC
客户端KDC
AS-REQ without pre-authentication ---->
<---- KRB-ERROR
AS-REQ without pre-authentication ---->
<---- KRB-ERROR
AS-REQ ---->
<---- AS-REP
AS-REQ ---->
<---- AS-REP
TGS-REQ ---->
<---- TGS-REP
TGS-REQ ---->
<---- TGS-REP
Figure 1
图1
We can use a similar message flow with PKINIT, allowing the KDC to provide a token for the client to include in its KRB_AS_REQ to ensure that the PA_PK_AS_REQ [RFC4556] was not pre-generated.
我们可以在PKINIT中使用类似的消息流，允许KDC为客户机提供一个令牌，以将其包含在KRB_AS_REQ中，以确保PA_PK_AS_REQ[RFC4556]不是预先生成的。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following summarizes the message flow with extensions to [RFC4120] and [RFC4556] required to support a KDC-provided freshness token during the initial request for a ticket:
以下总结了消息流以及[RFC4120]和[RFC4556]的扩展，这些扩展是在初始请求票证期间支持KDC提供的新鲜度令牌所必需的：
1. The client generates a KRB_AS_REQ, as specified in Section 2.9.3 of [RFC4120], that contains no PA_PK_AS_REQ and includes a freshness token request.
1. 客户机生成[RFC4120]第2.9.3节规定的KRB_AS_请求，该请求不包含PA_PK_AS_请求，并包含新鲜度令牌请求。
2. The KDC generates a KRB_ERROR, as specified in Section 3.1.4 of [RFC4120], providing a freshness token.
2. KDC生成[RFC4120]第3.1.4节规定的KRB_错误，提供新鲜度标记。
3. The client receives the error, as specified in Section 3.1.5 of [RFC4120], extracts the freshness token, and includes it as part of the KRB_AS_REQ as specified in [RFC4120] and [RFC4556].
3. 客户机收到[RFC4120]第3.1.5节中规定的错误，提取新鲜度令牌，并将其作为[RFC4120]和[RFC4556]中规定的KRB_as_请求的一部分。
4. The KDC receives and validates the KRB_AS_REQ, as specified in Section 3.2.2 of [RFC4556], then additionally validates the freshness token.
4. KDC接收并验证[RFC4556]第3.2.2节规定的KRB_AS_请求，然后额外验证新鲜度令牌。
5. The KDC and client continue, as specified in [RFC4120] and [RFC4556].
5. 按照[RFC4120]和[RFC4556]中的规定，KDC和客户端将继续。
The client indicates support of freshness tokens by adding a padata element with padata-type PA_AS_FRESHNESS and padata-value of an empty octet string.
客户端通过添加padata类型为PA_AS_freshness且padata值为空八位字节字符串的padata元素来表示对freshness令牌的支持。
The KDC will respond with a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_REQUIRED [RFC4120] adding a padata element with padata-type PA_AS_FRESHNESS and padata-value of the freshness token to the METHOD-DATA object.
KDC将响应KRB_错误[RFC4120]消息，错误代码为KDC_ERR_PREAUTH_REQUIRED[RFC4120]，向METHOD-DATA对象添加padata类型为PA_AS_FRESHNESS的padata元素和FRESHNESS令牌的padata值。
After the client receives the KRB-ERROR message containing a freshness token, it extracts the PA_AS_FRESHNESS padata-value field of the PA-DATA structure as an opaque data blob. The PA_AS_FRESHNESS padata-value field of the PA-DATA structure SHALL then be added as an opaque blob in the freshnessToken field when the client generates the PKAuthenticator specified in Section 4 for the PA_PK_AS_REQ message. This ensures that the freshness token value will be included in the signed data portion of the KRB_AS_REQ value.
客户端接收到包含刷新令牌的KRB-ERROR消息后，将PA-DATA结构的PA_AS_freshness padata值字段提取为不透明数据块。当客户端生成第4节为PA_PK_AS_REQ消息指定的PKAuthenticator时，PA-DATA结构的PA_AS_FRESHNESS padata值字段应作为不透明blob添加到freshnessToken字段中。这确保新鲜度令牌值将作为请求值包含在KRB_的签名数据部分中。
If the realm requires freshness and the PA_PK_AS_REQ message does not contain the freshness token, the KDC MUST return a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_FAILED [RFC4120] with a padata element with padata-type PA_AS_FRESHNESS and padata-value of the freshness token to the METHOD-DATA object.
如果领域需要新鲜度，并且PA_PK_AS_REQ消息不包含新鲜度令牌，则KDC必须向METHOD-DATA对象返回带有错误代码KDC_ERR_PREAUTH_FAILED[RFC4120]的KRB_ERROR[RFC4120]消息，其中包含padata元素，padata类型为PA_AS_freshness，并且新鲜度令牌的padata值。
When the PA_PK_AS_REQ message contains a freshness token, after validating the PA_PK_AS_REQ message normally, the KDC will validate the freshnessToken value in the PKAuthenticator in an implementation-specific way. If the freshness token is not valid, the KDC MUST return a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_EXPIRED [RFC6113]. The e-data field of the error contains a METHOD-DATA object [RFC4120], which specifies a valid PA_AS_FRESHNESS padata-value. Since the freshness tokens are validated by KDCs in the same realm, standardizing the contents of the freshness token is not a concern for interoperability.
当PA_PK_AS_REQ消息包含新鲜度令牌时，在正常验证PA_PK_AS_REQ消息后，KDC将以特定于实现的方式验证PKAuthenticator中的新鲜度令牌值。如果新鲜度令牌无效，KDC必须返回KRB_错误[RFC4120]消息，错误代码为KDC_ERR_PREAUTH_EXPIRED[RFC6113]。错误的e-data字段包含一个METHOD-data对象[RFC4120]，它指定了一个有效的pau AS_FRESHNESS padata值。由于新鲜度令牌由同一领域中的KDC进行验证，因此标准化新鲜度令牌的内容不需要考虑互操作性。
If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it SHOULD retry using the new freshness token.
如果客户端收到包含新鲜度令牌的KDC_ERR_PREAUTH_EXPIRED KRB_错误消息，则应使用新的新鲜度令牌重试。
The following are the new PreAuthentication data types:
以下是新的预验证数据类型：
+----------------------+-------------------+
| Padata and Data Type | Padata-type Value |
+----------------------+-------------------+
| PA_AS_FRESHNESS | 150 |
+----------------------+-------------------+
+----------------------+-------------------+
| Padata and Data Type | Padata-type Value |
+----------------------+-------------------+
| PA_AS_FRESHNESS | 150 |
+----------------------+-------------------+
The PKAuthenticator structure specified in Section 3.2.1 of [RFC4556] is extended to include a new freshnessToken as follows:
[RFC4556]第3.2.1节中规定的PKAuthenticator结构经过扩展，包括新的freshnessToken，如下所示：
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.
...,
freshnessToken [4] OCTET STRING OPTIONAL,
-- PA_AS_FRESHNESS padata value as received from the
-- KDC. MUST be present if sent by KDC
...
}
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.
...,
freshnessToken [4] OCTET STRING OPTIONAL,
-- PA_AS_FRESHNESS padata value as received from the
-- KDC. MUST be present if sent by KDC
...
}
IANA has assigned numbers for PA_AS_FRESHNESS listed in a subregistry of the "Kerberos Parameters" registry titled "Pre-authentication and Typed Data" as follows:
IANA已为“Kerberos参数”注册表子区域中名为“预认证和类型化数据”的PA_AS_新鲜度分配了编号，如下所示：
+------+-----------------+-----------+
| Type | Value | Reference |
+------+-----------------+-----------+
| 150 | PA_AS_FRESHNESS | [RFC8070] |
+------+-----------------+-----------+
+------+-----------------+-----------+
| Type | Value | Reference |
+------+-----------------+-----------+
| 150 | PA_AS_FRESHNESS | [RFC8070] |
+------+-----------------+-----------+
The freshness token SHOULD include signing, encrypting, or sealing data from the KDC to determine authenticity and prevent tampering.
新鲜度令牌应该包括对来自KDC的数据进行签名、加密或密封，以确定真实性并防止篡改。
Freshness tokens serve to guarantee that the client had the key when constructing the AS-REQ. They are not required to be single use tokens or bound to specific AS exchanges. Part of the reason the token is opaque is to allow KDC implementers the freedom to add additional functionality as long as the tokens expire so that the "freshness" guarantee remains.
新鲜度令牌用于保证客户机在构建AS-REQ时拥有密钥。它们不需要是一次性令牌或绑定到特定AS交换。令牌不透明的部分原因是，只要令牌过期，KDC实现者就可以自由添加额外的功能，从而保持“新鲜度”保证。
Since the client treats the KDC-provided data blob as opaque, changing the contents will not impact existing clients. Thus, extensions to the freshness token do not impact client interoperability.
由于客户端将KDC提供的数据blob视为不透明的，因此更改内容不会影响现有客户端。因此，对freshness令牌的扩展不会影响客户端互操作性。
Clients SHOULD NOT reuse freshness tokens across multiple exchanges. There is no guarantee that a KDC will allow a once-valid token to be used again. Thus, clients that do not retry with a new freshness token may not be compatible with KDCs, depending on how they choose to implement freshness validation.
客户端不应在多个交换中重复使用新鲜度令牌。无法保证KDC将允许再次使用曾经有效的令牌。因此，不使用新的新鲜度令牌重试的客户端可能与KDC不兼容，这取决于它们选择如何实现新鲜度验证。
Since upgrading clients takes time, implementers may consider allowing both freshness-token based exchanges and "legacy" exchanges without use of freshness tokens. However, until freshness tokens are required by the realm, the existing risks of pre-generated PKAuthenticators will remain.
由于升级客户端需要时间，所以实施者可以考虑允许新鲜令牌交换和“遗留”交换而不使用新鲜令牌。但是，在领域需要新鲜度令牌之前，预生成的PKAuthenticator的现有风险仍然存在。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://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月<http://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, <http://www.rfc-editor.org/info/rfc4556>.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 4556，DOI 10.17487/RFC4556，2006年6月<http://www.rfc-editor.org/info/rfc4556>.
[RFC5349] Zhu, L., Jaganathan, K., and K. Lauter, "Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 5349, DOI 10.17487/RFC5349, September 2008, <http://www.rfc-editor.org/info/rfc5349>.
[RFC5349]Zhu，L.，Jaganathan，K.，和K.Lauter，“椭圆曲线密码体制（ECC）对Kerberos（PKINIT）初始身份验证公钥密码体制的支持”，RFC 5349，DOI 10.17487/RFC5349，2008年9月<http://www.rfc-editor.org/info/rfc5349>.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/RFC6113, April 2011, <http://www.rfc-editor.org/info/rfc6113>.
[RFC6113]Hartman，S.和L.Zhu，“Kerberos预认证的通用框架”，RFC 6113，DOI 10.17487/RFC6113，2011年4月<http://www.rfc-editor.org/info/rfc6113>.
Acknowledgements
致谢
Douglas E. Engert, Sam Hartman, Henry B. Hotz, Nikos Mavrogiannopoulos, Martin Rex, Nico Williams, and Tom Yu were key contributors to the discovery of the freshness issue in PKINIT.
道格拉斯·E·恩格特、山姆·哈特曼、亨利·B·霍茨、尼科斯·马夫罗吉安诺普洛斯、马丁·雷克斯、尼科·威廉姆斯和汤姆·余是发现PKINIT新鲜度问题的关键贡献者。
Sam Hartman, Greg Hudson, Jeffrey Hutzelman, Nathan Ide, Benjamin Kaduk, Bryce Nordgren, Magnus Nystrom, Nico Williams, and Tom Yu reviewed the document and provided suggestions for improvements.
Sam Hartman、Greg Hudson、Jeffrey Hutzelman、Nathan Ide、Benjamin Kaduk、Bryce Nordgren、Magnus Nystrom、Nico Williams和Tom Yu审查了该文件，并提供了改进建议。
Authors' Addresses
作者地址
Michiko Short (editor) Microsoft Corporation United States of America
Michiko Short（编辑）美国微软公司
Email: michikos@microsoft.com
Email: michikos@microsoft.com
Seth Moore Microsoft Corporation United States of America
Seth Moore美国微软公司
Email: sethmo@microsoft.com
Email: sethmo@microsoft.com
Paul Miller Microsoft Corporation United States of America
美国微软公司保罗·米勒
Email: paumil@microsoft.com
Email: paumil@microsoft.com