RFC 7751 - Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7751
タイトル : RFC 7751 - 複数のメッセージ認証コード（MAC）によって認証されたKerberos承認データコンテナー
翻訳編集 : 自動生成

[要約] RFC 7751は、複数のメッセージ認証コード（MAC）によって認証されたKerberos認証データコンテナに関する規格です。このRFCの目的は、Kerberosプロトコルのセキュリティを向上させ、認証データの整合性と機密性を確保することです。

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)

複数のメッセージ認証コード（MAC）によって認証されたKerberos承認データコンテナー

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.

このドキュメントでは、AD-KDC-ISSUEDに代わるKerberos認証データコンテナーを指定します。複数のメッセージ認証コード（MAC）または署名を使用して、含まれている承認データ要素を認証できます。既存のAD-KDC-ISSUEDコンテナの欠点を軽減するには、複数のMACが必要です。このドキュメントはRFC 4120を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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で入手できます。

著作権表示

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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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

1. はじめに

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.

このドキュメントでは、CAMMAC（複数のMACによって認証されるコンテナー）と呼ばれる、Kerberosの新しい承認データコンテナーを指定します。 CAMMAC概念を実装する抽象構文記法1（ASN.1）タイプはAD-CAMMACであり、[RFC4120]で指定されているAD-KDC-ISSUED許可データタイプに取って代わります。この新しいコンテナーにより、受信アプリケーションサービスとキー配布センター（KDC）自体の両方が、含まれている承認データの信頼性を確認できます。 AD-CAMMACコンテナーには、「信頼されたサービス」が含まれている承認データを検証するために使用できる追加の検証機能を含めることもできます。

2. Requirements Language

2. 要件言語

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Motivations

3. 動機

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 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.

RFC 4120 [RFC4120]で指定されているAD-KDC-ISSUED認可データコンテナは、KDCがチケットに指定されたサービスがKDCは含まれている認証データを発行しました。この機能は、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-ISSUEDコンテナーは、認証データのフローがKDCからサービスへの場合に適しています。ただし、制約付き委任（S4U2Proxy [MS-SFU]）などのプロトコル拡張では、サービスがそのチケットで指定されたクライアントプリンシパルを偽装することを許可されている証拠として、サービスがKDCに以前に発行したサービスチケットをKDCに提示する必要があります。 S4U2Proxy拡張機能では、KDCは証拠チケットを、サービスがクライアントを偽装するために使用できる派生チケットを発行するための基礎として使用します。証拠チケット内に含まれる承認データは、アプリケーションサービスからKDCへの承認データのフローを構成します。 AD-KDC-ISSUEDコンテナーのプロパティは、サービスがAD-KDC-ISSUEDコンテナー内のチェックサムの対称キーを知っているため、このユースケースには不十分です。したがって、KDCは、サービスが証拠チケット内のAD-KDC-ISSUEDコンテナーの内容を改ざんしているかどうかを検出する方法がありません。

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-ISSUEDを改善しています。 AD-CAMMACのsvc-verifier（サービス検証）要素には、AD-KDC-ISSUEDのad-checksum要素と同じ機能およびセキュリティプロパティがあります。 svc-verifierを使用すると、サービスは、AD-KDC-ISSUEDコンテナーを使用した場合と同様に、AD-CAMMACコンテンツの整合性を検証できます。 kdc-verifierおよびother-verifiers要素は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-verifier要素を使用すると、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コンテナのother-verifiers要素内のベリファイアは必須ではありませんが、権限の低いサービスがクライアントからチケットを受け取り、AD-CAMMACを抽出して権限の高い「信頼されている」ことを示す必要がある場合に役立ちます。クライアントに代わって合法的に動作しているのと同じホスト上の「サービス」。信頼できるサービスは、other-verifiers要素のベリファイアを使用して、KDCとさらに通信することなく、AD-CAMMACのコンテンツを検証できます。

4. Encoding

4. エンコーディング

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プロトコルは、ASN.1 [X.680]とASN.1 Distinguished Encoding Rules（DER）[X.690]を使用して[RFC4120]で定義されています。一貫性を保つために、この仕様ではAD-CAMMACのレイアウトを指定するためにASN.1も使用しています。 AD-CAMMAC許可データ要素のad-dataは、以下で指定されている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

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.

IMPORTS AuthorizationData、PrincipalName、Checksum、UInt32、Int32 FROM KerberosV5Spec2 {iso（1）識別された組織（3）dod（6）internet（1）security（5）kerberosV5（2）modules（4）krb5spec2（2）}; -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
      }

      Verifier             ::= CHOICE {
            mac            Verifier-MAC,
            ...
      }

      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.

ベリファイア：現在1つの選択肢のみを含むCHOICEタイプ：ベリファイア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.

Verifier-MAC：AD-CAMMACのelementsフィールドのAuthorizationData値のASN.1 DERエンコーディングで計算されたRFC 3961 [RFC3961]チェックサム（MAC）を含みます。 identifier、kvno、およびenctypeフィールドは、受信者がMACの検証に必要なキーを見つけるのに役立ちます。 kdc-verifierとsvc-verifierの場合、識別子、kvno、およびenctypeフィールドは、多くの場合、コンテキストから明白であり、省略できます。 kdc-verifierの場合、MACは、後で説明するように、svc-verifierおよびother-verifierとは異なる方法で計算されます。 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-verifier：キーがローカルチケット許可サービス（TGS）の長期キーであるVerifier-MAC。チェックサムタイプは、TGSキーのenctypeに必要なチェックサムタイプです。他のVerifier-MAC要素とは対照的に、KDCは、周囲のチケットのEncTicketPartの変更バージョンのASN.1 DERエンコーディングを介してkdc-verifierでMACを計算します。 EncTicketPartのこの変更されたバージョンを構築するために、KDCは、EncTicketPartのauthorization-dataフィールドにあるはずのAuthorizationData値を、AD-CAMMACのelementsフィールドからのAuthorizationData値で置き換えます。 EncTicketPartの元の認証データフィールドには、AD-CAMMAC自体が含まれ、AD-CAMMACの外部にある他の認証データが含まれる可能性があります。この変更されたVerifier-MAC計算は、kdc-verifierをチケットの他のコンテンツにバインドし、悪意のあるサービスが別のチケットから受信した不一致のAD-CAMMACを置き換えていないことをKDCに保証します。

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-verifier：キーがKDCが周囲のチケットの暗号化に使用するのと同じ長期サービスキーであるVerifier-MAC。チェックサムタイプは、チケットの暗号化に使用されるサービスキーのenctypeに必要なチェックサムタイプです。このフィールドは、チケットがサービス間チケット認可チケット（TGT）である場合を含め、チケットのサービスプリンシパルがローカルTGSでない場合に存在する必要があります。

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.

other-verifiers：追加の検証者のシーケンス。追加の各Verifier-MACでは、キーは、識別子フィールドで指定されたプリンシパル名の長期キーです。 PrincipalNameが存在し、レルム内の有効なプリンシパルである必要があります。 KDCは、1つ以上の「信頼できるサービス」検証を追加してもよい（MAY）。特に管理上構成されていない限り、KDCは、周囲のチケットのsname要素のサービス識別子コンポーネントを「ホスト」に置き換えることにより、「信頼できるサービス」のプリンシパル名を決定する必要があります（SHOULD）。チェックサムは、識別されたプリンシパルの長期キーを使用して計算され、チェックサムタイプは、その長期キーのenctypeに必要なチェックサムタイプです。 kvnoとenctypeを指定して、信頼できるサービスのどの長期キーが使用されているかを明確にする必要があります（SHOULD）。

5. Usage

5. 使用法

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コンテナーとそれに含まれる承認データ要素を無視してもよい（MAY）。古いKerberos実装との互換性を保つために、KDCがAD-CAMMACを発行すると、アプリケーションサーバーが認識している可能性が高いことがわかっていない限り、AD-IF-RELEVANTコンテナ[RFC4120]でそれを囲む必要があります。

6. Assigned Numbers

6. 割り当てられた番号

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 広告タイプ番号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の表が更新され、広告タイプ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がVerifier-MACチェックサムに割り当てられ、[RFC4120]のセクション7.5.1の表を更新します。

7. Security Considerations

7. セキュリティに関する考慮事項

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から発信されたことを証明します。このセクションでは、CAMMACを含む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 copying of the original CAMMAC contents. The following paragraphs provide some guidance on formulating such policies.

CAMMACを含むTGS-REQを処理するとき、KDCは、TGS-REQに付随するチケットのプロパティに基づいて、新しく発行されたチケットのCAMMACコンテンツを作成する方法に関するポリシー決定を行います。このポリシー決定には、元のCAMMACコンテンツのフィルタリング、変換、または逐語的コピーが含まれる場合があります。以下の段落では、そのようなポリシーの策定に関するいくつかのガイダンスを提供します。

A KDC verifies a CAMMAC as originating from a local-realm KDC when at least one of following the criteria is true:

KDCは、次の基準の少なくとも1つが当てはまる場合に、CAMMACがローカルレルムKDCから発信されたものであることを確認します。

1. the KDC successfully verifies the kdc-verifier; or

1. KDCはkdc-verifierを正常に検証します。または

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-verifierを正常に検証し、svc-verifierはローカルレルム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を段階的にアップグレードするときに発生する可能性があるように、混合CAMMACサポートを備えたKDCを持つレルムでは特に注意が必要になる場合があります。）

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-verifierをCAMMACに適用できるタイミングを決定します（または上記のローカルオリジン基準を満たすCAMMACを作成します）。意味的に、KDCがローカルレルムKDCから発信されたものであると確認するCAMMACは、CAMMACの内容がCAMMACの作成時にローカルポリシーに準拠していたことを証明します。このようなローカルポリシーには、指定されたリモートレルムからのクロスレルムTGTからのCAMMACコンテンツの逐語的コピーの許可、および新しいCAMMACへのkdc-verifierの適用が含まれます。

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がCAMMACをローカルレルムKDCから発信されたものとして検証する場合、KDCはCAMMACのコンテンツがローカルレルムのポリシーに引き続き準拠していると想定できます。 KGSがTGS-REQを処理するときに、そのようなCAMMACの内容の逐語的コピーを新しいCAMMACに作成することは、一般的に安全です。特に厳格な実装では、CAMMACの存続期間中にローカルレルムのポリシーが大幅に変更された場合、ローカルレルムKDCから発信された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 omission to reduce the size of tickets it issues. Some examples of when such an omission is safe are:

KDCは、レルムポリシーが含まれているチケットをその後どのように処理するかによって、不要な場合はCAMMACからkdc-verifierを省略してもよい（MAY）。実装によっては、この省略を行って、発行するチケットのサイズを縮小する場合があります。そのような省略が安全である場合の例は次のとおりです。

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-verifierを省略できます。

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はそのサービスのチケットに含まれるCAMMACからkdc-verifierを省略してもよい（MAY）。

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を抽出すると、CAMMACがチケットのコンテキストから削除されます。一般的なケースでは、これにより、関連するすべてのセキュリティ上の影響を伴うベアラートークンに変わる可能性があります。また、CAMMAC自体には、必ずしもクライアントプリンシパルを識別するのに十分な情報が含まれているとは限りません。したがって、抽出された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-verifierを計算する方法は、CAMMAC内に含まれる認証データにのみバインドします。 CAMMACを、チケットを含むチケット内ではなく、CAMMACの外部にある認証データにバインドしません。少なくとも1つの（非標準の）承認データタイプAD-SIGNEDPATHは、チケット内の他の承認データにバインドしようとします。そのような2つの承認データタイプを共存させることは非常に困難です。

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.

サービスプリンシパル名はEncTicketPartの一部ではないため、CAMMACのkdc-verifierはサービスプリンシパル名をCAMMACコンテンツにバインドしません。 2つの異なるサービスプリンシパルのキーにアクセスできるエンティティは、1つのサービスのチケットを復号化し、それを他のサービスのキーで暗号化して、一致するようにsvc-verifierを変更できます。 kdc-verifierとsvc-verifierの両方が引き続き検証されますが、KDCがこの偽造チケットを発行したことはありません。 CAMMACコンテンツがクライアントに関連する属性のみを伝達する場合、この操作の影響は軽微です。アプリケーションがサービスプリンシパル名とCAMMACまたはチケットの内容との間に認証されたバインディングを必要とする場合、KDCはサービスプリンシパルを指定するいくつかの承認データ要素をCAMMACに含める必要があります。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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、「The Kerberos Network Authentication Service（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、11月2008。

[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）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X。 690、ISO / IEC国際規格8825-1：2008、2008年11月。

8.2. Informative References

8.2. 参考引用

[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

   Email: ssorce@redhat.com

Tom Yu MIT

トム・ユー・ウォッシュ

   Email: tlyu@mit.edu