[要約] RFC 8636は、Kerberos認証プロトコルにおける初期認証のための公開鍵暗号技術（PKINIT）のアルゴリズムの柔軟性に関するものです。この文書の目的は、PKINITの実装が将来の暗号アルゴリズムの変更に柔軟に対応できるようにすることです。これにより、セキュリティの要件が変化した場合や新しい脅威が現れた場合にも、Kerberos認証システムを安全に保つことができます。RFC 8636は、特にRFC 4556（PKINITの仕様）と関連しており、PKINITのアルゴリズムの選択と更新のプロセスを明確にします。利用場面としては、セキュリティが重要な環境でのKerberos認証の強化が挙げられます。
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.
これは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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）このドキュメントの発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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月、Xiaoyun Wangの研究グループは、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のリストを提供し、Key Distribution Center（KDC）はレスポンスで1つを選択します。したがって、相互にサポートされている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.
さらに、事前認証データとクライアントX.509証明書に署名するためにKDCがサポートする暗号化メッセージ構文（CMS）[RFC5652]ダイジェストアルゴリズムをクライアントが発見できるように、構造が定義されています。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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], 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.
[RFC4556]のセクション3.2.3.2で説明されているように、応答鍵配信メカニズムが公開鍵暗号化に基づいている場合、KDC応答のasChecksumは、これらのメッセージの未認証のクリアテキストと、事前認証とチケットの要求および応答メッセージ。ただし、[RFC4556]のセクション3.2.3.1で説明されているように、返信キー配信メカニズムがDiffie-Hellmanキー合意に基づいている場合、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エラーに追加されました。この仕様に準拠するKDC実装がこのエラーコードを返す場合、KDCがサポートするダイジェストアルゴリズムを示すサポートされているCMSタイプのリストを、優先度の高い順に含めることができます（MAY）。これは、TD_CMS_DATA_DIGEST_ALGORITHMS型のデータ要素をエラーデータに含めることで実現されます。
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_ALGORITHMSに対応するデータには、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.
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がTD_CMS_DATA_DIGEST_ALGORITHMSを介して送信するこの情報は、クライアントがサポートするダイジェストアルゴリズムがKDCでサポートされていない場合のトラブルシューティングを容易にします。
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:
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].
...
}
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は、allowedAlgorithmフィールドに、クライアントのX.509証明書に署名するためにCAによって使用され、クライアントのX.509証明書を検証するプロセスでKDCに受け入れられるダイジェストアルゴリズムを示すアルゴリズム[RFC5652]識別子のリストを入力します。優先度の高い順に。 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が更新され、Diffie-Hellman鍵交換によって生成された秘密値に基づいてKerberosプロトコル鍵を導出する追加の鍵導出関数（KDF）が定義されています。 [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-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-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-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.
id-pkinitは[RFC4556]で定義されています。上記で指定されたすべての鍵導出関数は、[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. reps = ceiling（L / H_outputBits）
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（counter || Z || OtherInfo）を計算します。
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. key_material = Hash1 ||を設定しますハッシュ2 || ... key_materialの長さが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応答キーは、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_outputBitsは、id-pkinit-kdf-ah-sha1では160ビット、id-pkinit-kdf-ah-sha256では256ビット、id-pkinit-kdf-ah-sha384では384ビット、id-pkinit-kdfでは512ビットです。 -ah-sha512。
o max_H_inputBits is 2^64.
o max_H_inputBitsは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応答キーのenctypeは、[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 イニシエーターID（partyUInfo）には、要求のAS-REQ [RFC4120]で指定されているクライアントを識別するKRB5PrincipalName [RFC4556]のASN.1 DERエンコードが含まれています。
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）には、リクエストのAS-REQ [RFC4120]で指定されているチケット認可サーバー（TGS）を識別するKRB5PrincipalName [RFC4556]のASN.1 DERエンコーディングが含まれています。
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 補足的な個人情報（suppPrivInfo）はありません。
OtherInfo is the ASN.1 DER encoding of the following sequence:
OtherInfoは、次のシーケンスのASN.1 DERエンコーディングです。
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.
...
}
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は応答のセットから1つを選択します。
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.
...
}
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.
...
}
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 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:
拡張DHRepInfo構造の新しいkdfフィールドは、KDCによって選択されたKDFを識別します。 supportedKDFsフィールドがリクエストに存在する場合、この仕様に準拠するKDCは、クライアントがサポートするKDFの1つを選択し、応答のkdfフィールドでその選択を示す必要があります。 supportedKDFsフィールドがリクエストに存在しない場合、KDCは応答でkdfフィールドを省略し、[RFC4556]のセクション3.2.3.1の鍵導出関数を使用する必要があります。クライアントがサポートするKDFのいずれもKDCに受け入れられない場合、KDCは新しいエラーコードKDC_ERR_NO_ACCEPTABLE_KDFで応答する必要があります。
o KDC_ERR_NO_ACCEPTABLE_KDF 100
o KDC_ERR_NO_ACCEPTABLE_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がこの仕様に準拠するように更新されていないか、交換がダウングレード攻撃を受けたと推定できます。返信に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エラーのTD-CMS-DIGEST-ALGORITHMS-DATA要素、またはKDC_ERR_DIGEST_IN_CERT_NOT_ACCEP.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エラーのTD-CMS-DIGEST-ALGORITHMS-DATA要素や、KDC_ERR_DIGEST_IN_CERT_NOT_ACCEP。クライアントには、これはまるで新しい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を使用します。クライアントは、KDCがこの仕様に準拠するように更新されていないこと、または交換がダウングレード攻撃を受けたことを、省略されたkdfフィールドから推測できます。ローカルポリシーが古い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
client: Length = 9 bytes, ASCII Representation = lha@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：長さ= 10バイト、16進表記= AAAAAAAA AAAAAAAA AAAA
pk-as-rep: Length = 9 bytes, Hex Representation = BBBBBBBB BBBBBBBB BB
pk-as-rep：長さ= 9バイト、16進表記= BBBBBBBB BBBBBBBB BB
ticket: Length = 55 bytes, Hex Representation = 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 036C6861 A311300F A0030201 12A20804 0668656A 68656A
チケット：長さ= 55バイト、16進表記= 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
algorithm-id：（id-pkinit-kdf-ah-sha1）長さ= 8バイト、16進表記= 2B060105 02030601
enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal Representation = 18
enctype：（aes256-cts-hmac-sha1-96）長さ= 1バイト、10進表現= 18
key-material: Length = 32 bytes, Hex Representation = E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
キーマテリアル：長さ= 32バイト、16進表記= E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
key: Length = 32 bytes, Hex Representation = E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
キー：長さ= 32バイト、16進表記= E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex Representation = 2B060105 02030602
algorithm-id：（id-pkinit-kdf-ah-sha256）長さ= 8バイト、16進表記= 2B060105 02030602
enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal Representation = 18
enctype：（aes256-cts-hmac-sha1-96）長さ= 1バイト、10進表現= 18
key-material: Length = 32 bytes, Hex Representation = 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
鍵素材：長さ= 32バイト、16進表記= 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
key: Length = 32 bytes, Hex Representation = 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
キー：長さ= 32バイト、16進表記= 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex Representation = 2B060105 02030603
algorithm-id：（id-pkinit-kdf-ah-sha512）長さ= 8バイト、16進表記= 2B060105 02030603
enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16
enctype：（des3-cbc-sha1-kd）長さ= 1バイト、10進表現= 16
key-material: Length = 24 bytes, Hex Representation = D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
キーマテリアル：長さ= 24バイト、16進表記= D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
key: Length = 32 bytes, Hex Representation = D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
キー：長さ= 32バイト、16進表記= D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 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 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.
セクション4で説明する検出方法では、Kerberosエラーメッセージを使用します。これは、通常の交換では認証されません。攻撃者は、KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTEDエラーを偽造することにより、クライアントをより弱いCMSタイプにダウングレードしようと試みる可能性があります。クライアントがより弱い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ネゴシエーション方式では、クライアントのsupportedKDFs値は、要求のsignedAuthPackフィールドの署名によって保護されています。この署名アルゴリズムが衝突攻撃に対して脆弱である場合、攻撃者は、PKINITフレッシュネストークン[RFC8070]を使用して正当なAuthPack値を部分的に制御することで、AuthPackを別のまたは存在しないsupportedKDFs値で置き換えることにより、ネゴシエーションをダウングレードしようとする可能性があります。匿名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に対する攻撃を使用して別のリクエストボディを置換した場合（攻撃者が正当なリクエストボディのどの部分も制御しないため、2番目のプリイメージ攻撃が必要になる可能性があります）、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、「The Kerberos Network Authentication Service（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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、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。、「Cryptographic Message Syntax（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、「US Secure Hash Algorithms（SHA and SHA-based HMAC and 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 Special Publications 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 Special Publications 800-56C、Revision 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）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690、8月2015、<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。、「The MD5 Message-Digest Algorithm」、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]ターナー、S。およびL.チェン、「MD4 to Historic Status」、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、3月2011、<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、編、「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）Freshness Extensionの初期認証のための公開鍵暗号」、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、 "Cryptanalysis of the Hash Functions MD4 and RIPEMD"、Advances of Cryptology-EUROCRYPT 2005、DOI 10.1007 / 11426639_1 、2004年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
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.
IMPORTS AlgorithmIdentifier、SubjectPublicKeyInfo FROM PKIX1Explicit88 {iso（1）識別された組織（3）dod（6）インターネット（1）セキュリティ（5）メカニズム（5）pkix（7）id-mod（0）id-pkix1-explicit（18 ）}-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、レルム、EncryptionKey、チェックサムFROM KerberosV5Spec2 {iso（1）づけられた組織（3）dod（6）インターネット（1）セキュリティ（5）kerberosV5（2）モジュール（4）krb5spec2（2）}-as 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.
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-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-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-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
}
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.
...
}
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
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
Larry Zhu Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 United States of America
Larry Zhu Oracle Corporation 500 Oracle Parkway Redwood Shores、CA 94065アメリカ合衆国
Email: larryzhu@live.com
Margaret Cullen Painless Security 4 High St, Suite 134 North Andover, MA 01845 United States of America
マーガレットカレンペインレスセキュリティ4ハイストリート、スイート134ノースアンドーバー、MA 01845アメリカ合衆国
Phone: +1 781-405-7464
Email: margaret@painless-security.com
Greg Hudson MIT
グレッグハドソンMIT
Email: ghudson@mit.edu