Internet Engineering Task Force (IETF) S. Sorce
Request for Comments: 7751 Red Hat
Updates: 4120 T. Yu
Category: Standards Track MIT
ISSN: 2070-1721 March 2016
Internet Engineering Task Force (IETF) S. Sorce
Request for Comments: 7751 Red Hat
Updates: 4120 T. Yu
Category: Standards Track MIT
ISSN: 2070-1721 March 2016
Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)
Kerberos授权数据容器通过多个消息身份验证码（MAC）进行身份验证
Abstract
摘要
This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120.
本文档指定了一个Kerberos授权数据容器，该容器将取代AD-KDC-ISTED。它允许使用多个消息身份验证码（MAC）或签名对包含的授权数据元素进行身份验证。需要多个MAC来缓解现有AD-KDC发布容器中的缺点。本文档更新了RFC 4120。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7751.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7751.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
This document specifies a new authorization data container for Kerberos, called the CAMMAC (Container Authenticated by Multiple MACs). The Abstract Syntax Notation One (ASN.1) type implementing the CAMMAC concept is the AD-CAMMAC, which supersedes the AD-KDC-ISSUED authorization data type specified in [RFC4120]. This new container allows both the receiving application service and the Key Distribution Center (KDC) itself to verify the authenticity of the contained authorization data. The AD-CAMMAC container can also include additional verifiers that "trusted services" can use to verify the contained authorization data.
本文档为Kerberos指定了一个新的授权数据容器，称为CAMMAC（由多个MAC验证的容器）。实现CAMMAC概念的抽象语法符号1（ASN.1）类型是AD-CAMMAC，它取代了[RFC4120]中指定的AD-KDC发布的授权数据类型。这个新容器允许接收应用程序服务和密钥分发中心（KDC）本身验证包含的授权数据的真实性。AD-CAMMAC容器还可以包括额外的验证器，“可信服务”可以用来验证包含的授权数据。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The Kerberos protocol allows clients to submit arbitrary authorization data for a KDC to insert into a Kerberos ticket. These client-requested authorization data allow the client to express authorization restrictions that the application service will interpret. With few exceptions, the KDC can safely copy these client-requested authorization data to the issued ticket without necessarily inspecting, interpreting, or filtering their contents.
Kerberos协议允许客户端提交任意授权数据，以便KDC插入Kerberos票证。这些客户端请求的授权数据允许客户端表示应用程序服务将解释的授权限制。除了少数例外，KDC可以安全地将这些客户端请求的授权数据复制到已发布的票据中，而无需检查、解释或过滤其内容。
The AD-KDC-ISSUED authorization data container specified in RFC 4120 [RFC4120] is a means for KDCs to include positive or permissive (rather than restrictive) authorization data in service tickets in a way that the service named in a ticket can verify that the KDC has
RFC 4120[RFC4120]中指定的AD-KDC颁发的授权数据容器是KDC在服务票证中包括积极或允许（而非限制性）授权数据的一种方式，票证中命名的服务可以验证KDC是否具有
issued the contained authorization data. This capability takes advantage of a shared symmetric key between the KDC and the service to assure the service that the KDC did not merely copy client-requested authorization data to the ticket without inspecting them.
已发布包含的授权数据。此功能利用KDC和服务之间的共享对称密钥，以确保服务KDC不只是将客户端请求的授权数据复制到票据中，而不进行检查。
The AD-KDC-ISSUED container works well for situations where the flow of authorization data is from the KDC to the service. However, protocol extensions such as Constrained Delegation (S4U2Proxy [MS-SFU]) require that a service present to the KDC a service ticket that the KDC previously issued, as evidence that the service is authorized to impersonate the client principal named in that ticket. In the S4U2Proxy extension, the KDC uses the evidence ticket as the basis for issuing a derivative ticket that the service can then use to impersonate the client. The authorization data contained within the evidence ticket constitute a flow of authorization data from the application service to the KDC. The properties of the AD-KDC-ISSUED container are insufficient for this use case because the service knows the symmetric key for the checksum in the AD-KDC-ISSUED container. Therefore, the KDC has no way to detect whether the service has tampered with the contents of the AD-KDC-ISSUED container within the evidence ticket.
AD-KDC发布的容器适用于授权数据流从KDC流向服务的情况。然而，诸如受限委派（S4U2Proxy[MS-SFU]）之类的协议扩展要求服务向KDC提供KDC先前发布的服务票证，作为该服务被授权模拟该票证中指定的客户端主体的证据。在S4U2Proxy扩展中，KDC使用证据票证作为发布衍生票证的基础，然后服务可以使用衍生票证模拟客户端。证据票证中包含的授权数据构成了从应用程序服务到KDC的授权数据流。AD-KDC-ISTED容器的属性不足以满足此用例，因为服务知道AD-KDC-ISTED容器中校验和的对称密钥。因此，KDC无法检测服务是否篡改了证据票证中AD-KDC发布的容器的内容。
The new AD-CAMMAC authorization data container specified in this document improves upon AD-KDC-ISSUED by including additional verifier elements. The svc-verifier (service verifier) element of the AD-CAMMAC has the same functional and security properties as the ad-checksum element of AD-KDC-ISSUED; the svc-verifier allows the service to verify the integrity of the AD-CAMMAC contents as it already could with the AD-KDC-ISSUED container. The kdc-verifier and other-verifiers elements are new to AD-CAMMAC and provide its enhanced capabilities.
本文档中指定的新AD-CAMMAC授权数据容器通过包含额外的验证器元素而改进了AD-KDC-ISTED。AD-CAMAC的svc验证器（服务验证器）元素与AD-KDC-MAC的AD校验和元素具有相同的功能和安全属性；svc验证器允许服务验证AD-CAMMAC内容的完整性，就像它已经可以使用AD-KDC发布的容器一样。kdc验证器和其他验证器元件是AD-CAMMAC的新元件，提供了增强的功能。
The kdc-verifier element of the AD-CAMMAC container allows a KDC to verify the integrity of authorization data that it previously inserted into a ticket by using a key that only the KDC knows. The KDC thus avoids recomputing all of the authorization data for the issued ticket; this recomputation might not always be possible when that data includes ephemeral information such as the strength or type of authentication method used to obtain the original ticket.
AD-CAMMAC容器的kdc验证器元素允许kdc通过使用只有kdc知道的密钥来验证其先前插入到票据中的授权数据的完整性。因此，KDC避免重新计算已发行票据的所有授权数据；当该数据包括短暂信息（例如用于获取原始票据的身份验证方法的强度或类型）时，可能并不总是能够重新计算。
The verifiers in the other-verifiers element of the AD-CAMMAC container are not required but can be useful when a lesser-privileged service receives a ticket from a client and needs to extract the AD-CAMMAC to demonstrate to a higher-privileged "trusted service" on the same host that it is legitimately acting on behalf of that client. The trusted service can use a verifier in the other-verifiers element to validate the contents of the AD-CAMMAC without further communication with the KDC.
AD-CAMMAC容器的其他验证器元素中的验证器不是必需的，但是当较低特权的服务从客户端接收票证并且需要提取AD-CAMMAC以向同一主机上的较高特权的“受信任服务”证明其合法地代表该客户端行事时，该验证器可以是有用的。可信服务可以使用其他验证器元素中的验证器来验证AD-CAMMAC的内容，而无需与KDC进一步通信。
The Kerberos protocol is defined in [RFC4120] using ASN.1 [X.680] and using the ASN.1 Distinguished Encoding Rules (DER) [X.690]. For consistency, this specification also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data of the AD-CAMMAC authorization data element is the ASN.1 DER encoding of the AD-CAMMAC ASN.1 type specified below.
Kerberos协议在[RFC4120]中使用ASN.1[X.680]和ASN.1可分辨编码规则（DER）[X.690]定义。为了保持一致性，本规范还使用ASN.1来指定AD-CAMMAC的布局。ad-CAMMAC授权数据元素的ad数据是下面指定的ad-CAMMAC ASN.1类型的ASN.1 DER编码。
KerberosV5CAMMAC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) cammac(7)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
KerberosV5CAMMAC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) cammac(7)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS AuthorizationData, PrincipalName, Checksum, UInt32, Int32 FROM KerberosV5Spec2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) }; -- as defined in RFC 4120.
从KerberosV5Spec2{iso（1）标识组织（3）国防部（6）互联网（1）安全（5）kerberosV5（2）模块（4）krb5spec2（2）}导入授权数据、原则名称、校验和、UInt32；——如RFC 4120中所定义。
AD-CAMMAC ::= SEQUENCE {
elements [0] AuthorizationData,
kdc-verifier [1] Verifier-MAC OPTIONAL,
svc-verifier [2] Verifier-MAC OPTIONAL,
other-verifiers [3] SEQUENCE (SIZE (1..MAX))
OF Verifier OPTIONAL
}
AD-CAMMAC ::= SEQUENCE {
elements [0] AuthorizationData,
kdc-verifier [1] Verifier-MAC OPTIONAL,
svc-verifier [2] Verifier-MAC OPTIONAL,
other-verifiers [3] SEQUENCE (SIZE (1..MAX))
OF Verifier OPTIONAL
}
Verifier ::= CHOICE {
mac Verifier-MAC,
...
}
Verifier ::= CHOICE {
mac Verifier-MAC,
...
}
Verifier-MAC ::= SEQUENCE {
identifier [0] PrincipalName OPTIONAL,
kvno [1] UInt32 OPTIONAL,
enctype [2] Int32 OPTIONAL,
mac [3] Checksum
}
Verifier-MAC ::= SEQUENCE {
identifier [0] PrincipalName OPTIONAL,
kvno [1] UInt32 OPTIONAL,
enctype [2] Int32 OPTIONAL,
mac [3] Checksum
}
END
终止
elements: A sequence of authorization data elements issued by the KDC. These elements are the authorization data that the verifier fields authenticate.
元素：KDC发布的一系列授权数据元素。这些元素是验证器字段验证的授权数据。
Verifier: A CHOICE type that currently contains only one alternative: Verifier-MAC. Future extensions might add support for public-key signatures.
验证器：当前仅包含一个选项的选择类型：验证器MAC。未来的扩展可能会增加对公钥签名的支持。
Verifier-MAC: Contains an RFC 3961 [RFC3961] checksum (MAC) computed over the ASN.1 DER encoding of the AuthorizationData value in the elements field of the AD-CAMMAC. The identifier, kvno, and enctype fields help the recipient locate the key required for verifying the MAC. For the kdc-verifier and the svc-verifier, the identifier, kvno, and enctype fields are often obvious from context and MAY be omitted. For the kdc-verifier, the MAC is computed differently than for the svc-verifier and the other-verifiers, as described later. The key usage number for computing the MAC (checksum) is 64.
验证器MAC：包含一个RFC 3961[RFC3961]校验和（MAC），通过AD-CAMMAC元素字段中授权数据值的ASN.1 DER编码进行计算。标识符、kvno和enctype字段帮助收件人找到验证MAC所需的密钥。对于kdc验证器和svc验证器，标识符、kvno和enctype字段通常在上下文中很明显，可以省略。对于kdc验证器，MAC的计算不同于svc验证器和其他验证器，如下文所述。用于计算MAC（校验和）的密钥使用数是64。
kdc-verifier: A Verifier-MAC where the key is a long-term key of the local Ticket-Granting Service (TGS). The checksum type is the required checksum type for the enctype of the TGS key. In contrast to the other Verifier-MAC elements, the KDC computes the MAC in the kdc-verifier over the ASN.1 DER encoding of a modified version of the EncTicketPart of the surrounding ticket. To construct this modified version of the EncTicketPart, the KDC replaces the AuthorizationData value that would have appeared in the authorization-data field of the EncTicketPart with the AuthorizationData value from the elements field of the AD-CAMMAC. The original authorization-data field in the EncTicketPart would have contained the AD-CAMMAC itself, possibly accompanied by other authorization data outside of the AD-CAMMAC. This altered Verifier-MAC computation binds the kdc-verifier to the other contents of the ticket, assuring the KDC that a malicious service has not substituted a mismatched AD-CAMMAC received from another ticket.
kdc验证器：验证器MAC，其中密钥是本地票证授予服务（TGS）的长期密钥。校验和类型是TGS密钥的enctype所需的校验和类型。与其他验证器MAC元素不同，KDC通过周围票证的EncTicketPart的修改版本的ASN.1 DER编码来计算KDC验证器中的MAC。为了构建此修改版本的EncTicketPart，KDC将EncTicketPart授权数据字段中出现的AuthorizationData值替换为AD-CAMMAC元素字段中的AuthorizationData值。EncTicketPart中的原始授权数据字段将包含AD-CAMMAC本身，可能伴随着AD-CAMMAC之外的其他授权数据。这种改变的验证器MAC计算将kdc验证器绑定到票证的其他内容，从而确保kdc没有恶意服务替换从另一个票证接收到的不匹配的AD-CAMAC。
svc-verifier: A Verifier-MAC where the key is the same long-term service key that the KDC uses to encrypt the surrounding ticket. The checksum type is the required checksum type for the enctype of the service key used to encrypt the ticket. This field MUST be present if the service principal of the ticket is not the local TGS, including when the ticket is a cross-realm Ticket-Granting Ticket (TGT).
svc验证器：验证器MAC，其中密钥与KDC用于加密周围票据的长期服务密钥相同。校验和类型是用于加密票据的服务密钥类型所需的校验和类型。如果票证的服务主体不是本地TGS，包括票证是跨领域票证授予票证（TGT）时，此字段必须存在。
other-verifiers: A sequence of additional verifiers. In each additional Verifier-MAC, the key is a long-term key of the principal name specified in the identifier field. The PrincipalName MUST be present and be a valid principal in the realm. KDCs MAY add one or more "trusted service" verifiers. Unless otherwise administratively configured, the KDC SHOULD determine the "trusted service" principal name by replacing the service identifier component of the sname element of the surrounding ticket with "host". The checksum is computed using a long-term key of the identified principal, and the checksum type is the required checksum type for the enctype of that long-term key. The kvno and enctype SHOULD be specified to disambiguate which of the long-term keys of the trusted service is used.
其他验证器：附加验证器的序列。在每个附加验证器MAC中，密钥是标识符字段中指定的主体名称的长期密钥。PrincipalName必须存在并且是域中的有效主体。KDC可以添加一个或多个“可信服务”验证器。除非另有管理配置，否则KDC应通过将周围票据的sname元素的服务标识符组件替换为“主机”来确定“受信任服务”主体名称。校验和是使用已识别主体的长期密钥计算的，校验和类型是该长期密钥的enctype所需的校验和类型。应指定kvno和enctype以消除使用受信任服务的哪些长期密钥的歧义。
Application servers and KDCs MAY ignore the AD-CAMMAC container and the authorization data elements it contains. For compatibility with older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD enclose it in an AD-IF-RELEVANT container [RFC4120] unless the KDC knows that the application server is likely to recognize it.
应用服务器和KDC可能会忽略AD-CAMMAC容器及其包含的授权数据元素。为了与旧的Kerberos实现兼容，发出AD-CAMAC的KDC应将其封装在AD-IF相关容器[RFC4120]中，除非KDC知道应用程序服务器可能会识别它。
RFC 4120 is updated in the following ways:
RFC 4120通过以下方式更新：
o The ad-type number 96 is assigned for AD-CAMMAC, updating the table in Section 7.5.4 of [RFC4120].
o ad类型编号96分配给ad-CAMMAC，更新[RFC4120]第7.5.4节中的表格。
o The table in Section 5.2.6 of [RFC4120] is updated to map the ad-type 96 to "DER encoding of AD-CAMMAC".
o [RFC4120]第5.2.6节中的表格已更新，以将ad类型96映射为“ad-CAMMAC的DER编码”。
o The key usage number 64 is assigned for the Verifier-MAC checksum, updating the table in Section 7.5.1 of [RFC4120].
o 密钥使用编号64分配给验证器MAC校验和，更新[RFC4120]第7.5.1节中的表。
The CAMMAC provides data origin authentication for authorization data contained in it, attesting that it originated from the KDC. This section describes the precautions required to maintain the integrity of that data origin authentication through various information flows involving a Kerberos ticket containing a CAMMAC.
CAMMAC为其中包含的授权数据提供数据源身份验证，证明其来自KDC。本节介绍通过各种信息流（涉及包含CAMAC的Kerberos票证）维护数据源身份验证完整性所需的预防措施。
When handling a TGS-REQ containing a CAMMAC, a KDC makes a policy decision on how to produce the CAMMAC contents of the newly issued ticket based on properties of the ticket(s) accompanying the TGS-REQ. This policy decision can involve filtering, transforming, or verbatim
当处理包含CAMAC的TGS-REQ时，KDC根据TGS-REQ附带的票证的属性，就如何生成新发行的票证的CAMAC内容做出策略决策。此策略决策可能涉及筛选、转换或逐字记录
copying of the original CAMMAC contents. The following paragraphs provide some guidance on formulating such policies.
复制原始CAMMAC内容。以下段落为制定此类政策提供了一些指导。
A KDC verifies a CAMMAC as originating from a local-realm KDC when at least one of following the criteria is true:
当以下条件中的至少一个为真时，KDC验证CAMMAC是否源自本地领域KDC：
1. the KDC successfully verifies the kdc-verifier; or
1. KDC成功验证KDC验证器；或
2. the KDC successfully verifies the svc-verifier, and the svc-verifier uses a key known only to the local-realm KDCs; or
2. KDC成功验证svc验证器，svc验证器使用仅本地领域KDC已知的密钥；或
3. no verifiers are present, the ticket-encrypting key is known only to local-realm KDCs, and all local-realm KDCs properly filter out client-submitted CAMMACs. (This can require particular caution in a realm that has KDCs with mixed CAMMAC support, as might happen when incrementally upgrading KDCs in a realm to support CAMMAC.)
3. 不存在验证器，票据加密密钥仅对本地领域KDC已知，并且所有本地领域KDC都正确过滤掉客户端提交的CAMMAC。（在具有混合CAMMAC支持的KDC的领域中，这可能需要特别小心，当以增量方式升级领域中的KDC以支持CAMMAC时可能会发生这种情况。）
A CAMMAC that originates from a local-realm KDC might contain information that originates from elsewhere. Originating from a local-realm KDC means that a local-realm KDC attests that the CAMMAC contents conform to the policies of the local realm, regardless of the ultimate origin of the information in the CAMMAC (which could be a remote realm in the case of a CAMMAC contained in a cross-realm TGT).
源自本地领域KDC的CAMMAC可能包含源自其他地方的信息。源自本地领域KDC意味着本地领域KDC证明CAMMAC内容符合本地领域的策略，而不管CAMMAC中信息的最终来源（在跨领域TGT中包含CAMMAC的情况下，可能是远程领域）。
Local policy determines when a KDC can apply a kdc-verifier to a CAMMAC (or otherwise creates a CAMMAC that satisfies the local-origin criteria listed above). Semantically, a CAMMAC that a KDC verifies as originating from a local-realm KDC attests that the CAMMAC contents conformed to local policy at the time of creation of the CAMMAC. Such a local policy can include allowing verbatim copying of CAMMAC contents from cross-realm TGTs from designated remote realms and applying a kdc-verifier to the new CAMMAC.
本地策略确定KDC何时可以将KDC验证器应用于CAMAC（或以其他方式创建满足上述本地源标准的CAMAC）。语义上，KDC验证为源自本地领域KDC的CAMMAC证明在创建CAMMAC时CAMMAC内容符合本地策略。这种本地策略可以包括允许从指定的远程领域逐字复制来自跨领域tgt的CAMMAC内容，并将kdc验证器应用于新的CAMMAC。
Usually, when a KDC verifies a CAMMAC as originating from a local-realm KDC, the KDC can assume that the CAMMAC contents continue to conform to the policies of the local realm. It is generally safe for a KDC to make verbatim copies of the contents of such a CAMMAC into a new CAMMAC when handling a TGS-REQ. Particularly strict implementations might conduct additional policy checks on the contents of a CAMMAC originating from a local-realm KDC if the policy of the local realm materially changes during the life of the CAMMAC.
通常，当KDC验证CAMAC源于本地领域KDC时，KDC可以假定CAMAC内容继续符合本地领域的策略。在处理TGS-REQ时，KDC将此类CAMMAC的内容逐字复制到新的CAMMAC中通常是安全的。特别严格的实现可能会对源自本地领域KDC的CAMMAC的内容执行额外的策略检查，如果本地领域的策略在CAMMAC的生命周期内发生重大变化。
A KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed according to how realm policies will subsequently treat the containing ticket. An implementation might choose to do this
当不需要KDC验证器时，KDC可以从CAMMAC中省略KDC验证器，这取决于领域策略随后如何处理包含的票证。实现可能会选择这样做
omission to reduce the size of tickets it issues. Some examples of when such an omission is safe are:
省略以减少it发行的票证的大小。此类遗漏安全的一些示例如下：
1. For a local-realm TGT, if all local-realm KDCs correctly filter out client-submitted CAMMACs, the local-realm origin criteria listed above allow omission of the kdc-verifier.
1. 对于本地域TGT，如果所有本地域kdc正确过滤掉客户端提交的CAMMAC，则上面列出的本地域源标准允许省略kdc验证器。
2. An application service might not use the S4U2Proxy extension, or the realm policy might disallow the use of S4U2Proxy by that service. In such situations where there is no flow of authorization data from the service to the KDC, the application service could modify the CAMMAC contents, but such modifications would have no effect on other services. Because of the lack of security impact to other application services, the KDC MAY omit the kdc-verifier from a CAMMAC contained in a ticket for that service.
2. 应用程序服务可能不使用S4U2Proxy扩展，或者领域策略可能不允许该服务使用S4U2Proxy。在没有从服务到KDC的授权数据流的情况下，应用程序服务可以修改CAMMAC内容，但这种修改不会对其他服务产生影响。由于缺乏对其他应用程序服务的安全影响，KDC可能会从该服务的票证中包含的CAMAC中省略KDC验证器。
Extracting a CAMMAC from a ticket for use as a credential removes it from the context of the ticket. In the general case, this could turn it into a bearer token, with all of the associated security implications. Also, the CAMMAC does not itself necessarily contain sufficient information to identify the client principal. Therefore, application protocols that rely on extracted CAMMACs might need to duplicate a substantial portion of the ticket contents and include that duplicated information in the authorization data contained within the CAMMAC. The extent of this duplication would depend on the security properties required by the application protocol.
从票据中提取CAMMAC以用作凭证将其从票据的上下文中删除。在一般情况下，这可能会将其转换为具有所有相关安全含义的承载令牌。此外，CAMAC本身不一定包含足够的信息来识别客户机主体。因此，依赖于提取的CAMMAC的应用协议可能需要复制票据内容的很大一部分，并在CAMMAC中包含的授权数据中包括该复制信息。这种复制的程度取决于应用程序协议所需的安全属性。
The method for computing the kdc-verifier binds it only to the authorization data contained within the CAMMAC; it does not bind the CAMMAC to any authorization data within the containing ticket but outside the CAMMAC. At least one (non-standard) authorization data type, AD-SIGNEDPATH, attempts to bind to other authorization data in a ticket, and it is very difficult for two such authorization data types to coexist.
用于计算kdc验证器的方法仅将其绑定到CAMMAC中包含的授权数据；它不会将CAMMAC绑定到包含票据但在CAMMAC之外的任何授权数据。至少有一种（非标准）授权数据类型AD-SIGNEDPATH尝试绑定到票据中的其他授权数据，并且这两种授权数据类型很难共存。
The kdc-verifier in CAMMAC does not bind the service principal name to the CAMMAC contents because the service principal name is not part of the EncTicketPart. An entity that has access to the keys of two different service principals can decrypt a ticket for one service and encrypt it in the key of the other service, altering the svc-verifier to match. Both the kdc-verifier and the svc-verifier would still validate, but the KDC never issued this fabricated ticket. The impact of this manipulation is minor if the CAMMAC contents only communicate attributes related to the client. If an application requires an authenticated binding between the service principal name and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC some authorization data element that names the service principal.
CAMAC中的kdc验证器不会将服务主体名称绑定到CAMAC内容，因为服务主体名称不是EncTicketPart的一部分。可以访问两个不同服务主体的密钥的实体可以解密一个服务的票证，并在另一个服务的密钥中对其加密，从而更改svc验证器以匹配。kdc验证器和svc验证器仍将进行验证，但kdc从未发布过此伪造票据。如果CAMMAC内容只传递与客户端相关的属性，则此操作的影响很小。如果应用程序需要服务主体名称与CAMMAC或票证内容之间的经过身份验证的绑定，KDC必须在CAMMAC中包含一些命名服务主体的授权数据元素。
[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>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 2005, <http://www.rfc-editor.org/info/rfc3961>.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，DOI 10.17487/RFC3961，2005年2月<http://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, <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>.
[X.680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC International Standard 8824-1:2008, November 2008.
[X.680]ITU-T，“信息技术——抽象语法符号1（ASN.1）：基本符号规范”，ITU-T建议X.680，ISO/IEC国际标准8824-1:2008，2008年11月。
[X.690] 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, ISO/IEC International Standard 8825-1:2008, November 2008.
[X.690]ITU-T，“信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC国际标准8825-1:2008，2008年11月。
[MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol", October 2015, <http://msdn.microsoft.com/en-us/library/cc246071.aspx>.
[MS-SFU]微软，“[MS-SFU]：Kerberos协议扩展：用户服务和受约束的委派协议”，2015年10月<http://msdn.microsoft.com/en-us/library/cc246071.aspx>.
Acknowledgements
致谢
Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful technical and editorial feedback on earlier draft versions of this document. Thomas Hardjono helped with the initial editing to split this document from a predecessor document that had a wider scope.
Shawn Emery、Sam Hartman、Greg Hudson、Ben Kaduk、Barry Leiba、Meral Shirazipour、Zhanna Tsitkov、Qin Wu和Kai Zheng就本文件的早期草稿提供了有用的技术和编辑反馈。Thomas Hardjono帮助进行了初步编辑，将此文档从范围更广的前一个文档中分离出来。
Authors' Addresses
作者地址
Simo Sorce Red Hat
Simo Sorce红帽
Email: ssorce@redhat.com
Email: ssorce@redhat.com
Tom Yu MIT
汤姆余麻省理工学院
Email: tlyu@mit.edu
Email: tlyu@mit.edu