[要約] RFC 4556は、Kerberosの初期認証に公開鍵暗号を導入するPKINIT拡張を定義します。クライアントとKDCは公開鍵を使って認証し、Diffie-Hellman鍵合意または公開鍵暗号によってAS応答鍵を確立します。仕様は、証明書の検証と対応付け、エラー処理、相互運用性、およびセキュリティ上の考慮事項も定めます。
Network Working Group L. Zhu
Request for Comments: 4556 Microsoft Corporation
Category: Standards Track B. Tung
Aerospace Corporation
June 2006
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Kerberos における初期認証のための公開鍵暗号 (PKINIT)
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを定め、改善に向けた議論と提案を求めています。このプロトコルの標準化段階と状態については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。このメモは無制限に配布できます。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields.
この文書では、Kerberosプロトコル仕様を拡張するプロトコル機能（以下、PKINITと呼びます）について説明します。この拡張機能は、事前認証データフィールドで非対称鍵の署名方式や暗号化方式を使い、公開鍵暗号を初期認証交換に導入する方法を提供します。
Table of Contents
目次
1. Introduction ....................................................2 2. Conventions Used in This Document ...............................4 3. Extensions ......................................................5 3.1. Definitions, Requirements, and Constants ...................6 3.1.1. Required Algorithms .................................6 3.1.2. Recommended Algorithms ..............................6 3.1.3. Defined Message and Encryption Types ................7 3.1.4. Kerberos Encryption Types Defined for CMS Algorithm Identifiers ...............................8 3.2. PKINIT Pre-authentication Syntax and Use ...................9 3.2.1. Generation of Client Request ........................9 3.2.2. Receipt of Client Request ..........................14 3.2.3. Generation of KDC Reply ............................18 3.2.3.1. Using Diffie-Hellman Key Exchange .........21 3.2.3.2. Using Public Key Encryption ...............23
3.2.4. Receipt of KDC Reply ...............................25
3.3. Interoperability Requirements .............................26
3.4. KDC Indication of PKINIT Support ..........................27
4. Security Considerations ........................................27
5. Acknowledgements ...............................................30
6. References .....................................................30
6.1. Normative References ......................................30
6.2. Informative References ....................................32
Appendix A. PKINIT ASN.1 Module ..................................33
Appendix B. Test Vectors .........................................38
Appendix C. Miscellaneous Information about Microsoft Windows
PKINIT Implementations ...............................40
The Kerberos V5 protocol [RFC4120] involves use of a trusted third party known as the Key Distribution Center (KDC) to negotiate shared session keys between clients and services and provide mutual authentication between them.
Kerberos V5プロトコル [RFC4120] では、Key Distribution Center（KDC）と呼ばれる信頼できる第三者を使い、クライアントとサービスの間で共有セッション鍵をネゴシエートし、両者を相互認証します。
The corner-stones of Kerberos V5 are the Ticket and the Authenticator. A Ticket encapsulates a symmetric key (the ticket session key) in an envelope (a public message) intended for a specific service. The contents of the Ticket are encrypted with a symmetric key shared between the service principal and the issuing KDC. The encrypted part of the Ticket contains the client principal name, among other items. An Authenticator is a record that can be shown to have been recently generated using the ticket session key in the associated Ticket. The ticket session key is known by the client who requested the ticket. The contents of the Authenticator are encrypted with the associated ticket session key. The encrypted part of an Authenticator contains a timestamp and the client principal name, among other items.
Kerberos V5の中核となる要素はTicketとAuthenticatorです。Ticketは、特定のサービス宛ての封筒（公開メッセージ）に対称鍵（ticket session key）を格納します。Ticketの内容は、サービスプリンシパルと発行元KDCが共有する対称鍵で暗号化します。暗号化されたTicketには、クライアントプリンシパル名などが含まれます。Authenticatorは、対応するTicket内のticket session keyを使って最近生成されたことを証明できるレコードです。ticket session keyはTicketを要求したクライアントが知っています。Authenticatorの内容は対応するticket session keyで暗号化し、暗号化部分にはタイムスタンプやクライアントプリンシパル名などを含めます。
As shown in Figure 1, below, the Kerberos V5 protocol consists of the following message exchanges between the client and the KDC, and the client and the application service:
以下の図1に示すように、Kerberos V5プロトコルは、クライアントとKDCの間、およびクライアントとアプリケーションサービスの間で行う次のメッセージ交換から成ります。
- The Authentication Service (AS) Exchange
- 認証サービス（AS）交換
The client obtains an "initial" ticket from the Kerberos authentication server (AS), typically a Ticket Granting Ticket (TGT). The AS-REQ message and the AS-REP message are the request and the reply message, respectively, between the client and the AS.
クライアントはKerberos認証サーバー（AS）から「初期」Ticketを取得します。通常、これはTicket Granting Ticket（TGT）です。AS-REQメッセージとAS-REPメッセージは、それぞれクライアントからASへの要求とASからクライアントへの応答です。
- The Ticket Granting Service (TGS) Exchange
- チケット付与サービス（TGS）交換
The client subsequently uses the TGT to authenticate and request a service ticket for a particular service, from the Kerberos ticket-granting server (TGS). The TGS-REQ message and the TGS-REP message are the request and the reply message respectively between the client and the TGS.
クライアントはその後、TGTを使って認証し、Kerberosのチケット付与サーバー（TGS）から特定のサービス向けのサービスTicketを要求します。TGS-REQとTGS-REPは、それぞれクライアントからTGSへの要求とTGSからクライアントへの応答です。
- The Client/Server Authentication Protocol (AP) Exchange
- クライアント/サーバー認証プロトコル（AP）交換
The client then makes a request with an AP-REQ message, consisting of a service ticket and an authenticator that certifies the client's possession of the ticket session key. The server may optionally reply with an AP-REP message. AP exchanges typically negotiate session-specific symmetric keys.
次にクライアントは、サービスTicketと、クライアントがticket session keyを所有していることを証明するAuthenticatorを含むAP-REQメッセージで要求します。サーバーは任意でAP-REPメッセージを返します。AP交換では通常、セッション固有の対称鍵をネゴシエートします。
Usually, the AS and TGS are integrated in a single device also known as the KDC.
通常、ASとTGSは、KDCとも呼ばれる単一のデバイスに統合されます。
+--------------+
+--------->| KDC |
AS-REQ / +-------| |
/ / +--------------+
/ / ^ |
/ |AS-REP / |
| | / TGS-REQ + TGS-REP
| | / /
| | / /
| | / +---------+
| | / /
| | / /
| | / /
| v / v
++-------+------+ +-----------------+
| Client +------------>| Application |
| | AP-REQ | Server |
| |<------------| |
+---------------+ AP-REP +-----------------+
Figure 1: The Message Exchanges in the Kerberos V5 Protocol
図1：Kerberos V5プロトコルのメッセージ交換
In the AS exchange, the KDC reply contains the ticket session key, among other items, that is encrypted using a key (the AS reply key) shared between the client and the KDC. The AS reply key is typically derived from the client's password for human users. Therefore, for human users, the attack resistance strength of the Kerberos protocol is no stronger than the strength of their passwords.
AS交換では、KDCの応答にticket session keyなどが含まれます。この鍵は、クライアントとKDCが共有する鍵（AS reply key）で暗号化されています。人間のユーザーの場合、AS reply keyは通常、クライアントのパスワードから導出します。したがって、人間のユーザーに対するKerberosプロトコルの攻撃耐性は、そのユーザーのパスワードの強度を超えません。
The use of asymmetric cryptography in the form of X.509 certificates [RFC3280] is popular for facilitating data origin authentication and perfect secrecy. An established Public Key Infrastructure (PKI) provides key management and key distribution mechanisms that can be used to establish authentication and secure communication. Adding public-key cryptography to Kerberos provides a nice congruence to public-key protocols, obviates the human users' burden to manage strong passwords, and allows Kerberized applications to take advantage of existing key services and identity management.
X.509証明書 [RFC3280] を使う非対称暗号は、データ送信元認証と完全秘匿性を実現するために広く使われています。確立された公開鍵基盤（PKI）は、認証と安全な通信の確立に使える鍵管理および鍵配布の仕組みを提供します。Kerberosに公開鍵暗号を追加すると、公開鍵プロトコルとの整合性が高まり、人間のユーザーが強固なパスワードを管理する負担をなくし、Kerberos対応アプリケーションが既存の鍵サービスとID管理を利用できるようになります。
The advantage afforded by the Kerberos TGT is that the client exposes his long-term secrets only once. The TGT and its associated session key can then be used for any subsequent service ticket requests. One result of this is that all further authentication is independent of the method by which the initial authentication was performed. Consequently, initial authentication provides a convenient place to integrate public-key cryptography into Kerberos authentication. In addition, the use of symmetric cryptography after the initial exchange is preferred for performance.
Kerberos TGTの利点は、クライアントが長期シークレットを公開するのが一度だけで済むことです。その後のサービスTicket要求には、TGTとそれに対応するセッション鍵を使えます。そのため、以後の認証は初期認証の方式に依存しません。したがって、初期認証はKerberos認証に公開鍵暗号を導入するのに適した機会です。また、性能上、初期交換後は対称暗号を使うことが望まれます。
This document describes the methods and data formats using which the client and the KDC can use public and private key pairs to mutually authenticate in the AS exchange and negotiate the AS reply key, known only by the client and the KDC, to encrypt the AS-REP sent by the KDC.
この文書では、AS交換でクライアントとKDCが公開鍵と秘密鍵のペアを使って相互認証し、AS reply keyをネゴシエートする方法とデータ形式を説明します。このAS reply keyはクライアントとKDCだけが知り、KDCが送信するAS-REPの暗号化に使います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。
In this protocol, both the client and the KDC have a public-private key pair in order to prove their identities to each other over the open network. The term "signature key" is used to refer to the private key of the key pair being used.
このプロトコルでは、クライアントとKDCの両方が、オープンネットワーク上で互いの身元を証明するための公開鍵・秘密鍵ペアを持ちます。「署名鍵」は、使用する鍵ペアの秘密鍵を指します。
The encryption key used to encrypt the enc-part field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS reply key.
AS-REP [RFC4120] 内のKDC-REPのenc-partフィールドを暗号化する鍵を、AS reply keyと呼びます。
An empty sequence in an optional field can be either included or omitted: both encodings are permitted and considered equivalent.
optionalフィールド内の空シーケンスは含めても省略してもかまいません。どちらの符号化も許可され、同等と見なします。
The term "Modular Exponential Diffie-Hellman" is used to refer to the Diffie-Hellman key exchange, as described in [RFC2631], in order to differentiate it from other equivalent representations of the same key agreement algorithm.
同じ鍵合意アルゴリズムの他の等価な表現と区別するため、ここでは[RFC2631]に記載されたDiffie-Hellman鍵交換を「Modular Exponential Diffie-Hellman」と呼びます。
This section describes extensions to [RFC4120] for supporting the use of public-key cryptography in the initial request for a ticket.
この節では、チケットの初期要求で公開鍵暗号を使えるようにするための[RFC4120]への拡張を説明します。
Briefly, this document defines the following extensions to [RFC4120]:
要約すると、本書では[RFC4120]に対して次の拡張を定義します。
1. The client indicates the use of public-key authentication by including a special preauthenticator in the initial request. This preauthenticator contains the client's public-key data and a signature.
1. クライアントは、初期要求に特別なpreauthenticatorを含めて、公開鍵認証を使うことを示します。このpreauthenticatorには、クライアントの公開鍵データと署名が含まれます。
2. The KDC tests the client's request against its authentication policy and trusted Certification Authorities (CAs).
2. KDCは、クライアントの要求を自身の認証ポリシーおよび信頼する認証局（CA）に照らして検査します。
3. If the request passes the verification tests, the KDC replies as usual, but the reply is encrypted using either:
3. 要求が検証に合格すると、KDCは通常どおり応答しますが、応答の暗号化には次のいずれかを使います。
a. a key generated through a Diffie-Hellman (DH) key exchange [RFC2631] [IEEE1363] with the client, signed using the KDC's signature key; or
a. クライアントとのDiffie-Hellman（DH）鍵交換 [RFC2631] [IEEE1363] で生成し、KDCの署名鍵で署名した鍵。
b. a symmetric encryption key, signed using the KDC's signature key and encrypted using the client's public key.
b. KDCの署名鍵で署名し、クライアントの公開鍵で暗号化した対称暗号鍵。
Any keying material required by the client to obtain the encryption key for decrypting the KDC reply is returned in a pre-authentication field accompanying the usual reply.
KDCの応答を復号する暗号鍵をクライアントが得るために必要な鍵素材は、通常の応答に付随する事前認証フィールドで返します。
4. The client validates the KDC's signature, obtains the encryption key, decrypts the reply, and then proceeds as usual.
4. クライアントはKDCの署名を検証し、暗号鍵を取得して応答を復号し、その後通常の手順を続けます。
Section 3.1 of this document enumerates the required algorithms and necessary extension message types. Section 3.2 describes the extension messages in greater detail.
本書のセクション3.1では必須アルゴリズムと必要な拡張メッセージ型を列挙し、セクション3.2では拡張メッセージを詳しく説明します。
All PKINIT implementations MUST support the following algorithms:
すべてのPKINIT実装は次のアルゴリズムをサポートしなければなりません (MUST)。
o AS reply key enctypes: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 [RFC3962].
o AS reply key enctypes：aes128-cts-hmac-sha1-96およびaes256-cts-hmac-sha1-96 [RFC3962]。
o Signature algorithm: sha-1WithRSAEncryption [RFC3370].
o 署名アルゴリズム：sha-1WithRSAEncryption [RFC3370]。
o AS reply key delivery method: the Diffie-Hellman key delivery method, as described in Section 3.2.3.1.
o AS reply keyの鍵配送方式：セクション3.2.3.1に記載するDiffie-Hellman鍵配送方式。
In addition, implementations of this specification MUST be capable of processing the Extended Key Usage (EKU) extension and the id-pkinit-san (as defined in Section 3.2.2) otherName of the Subject Alternative Name (SAN) extension in X.509 certificates [RFC3280].
さらに、この仕様の実装は、X.509証明書 [RFC3280] 内のExtended Key Usage（EKU）拡張と、Subject Alternative Name（SAN）拡張のid-pkinit-san otherName（セクション3.2.2で定義）を処理できなければなりません (MUST)。
All PKINIT implementations SHOULD support the following algorithm:
すべてのPKINIT実装は、次のアルゴリズムをサポートすべきです (SHOULD)。
o AS reply key delivery method: the public key encryption key delivery method, as described in Section 3.2.3.2.
o AS reply keyの鍵配送方式：セクション3.2.3.2に記載する公開鍵暗号による鍵配送方式。
For implementations that support the public key encryption key delivery method, the following algorithms MUST be supported:
公開鍵暗号による鍵配送方式をサポートする実装は、次のアルゴリズムをサポートしなければなりません (MUST)。
a) Key transport algorithms identified in the keyEncryptionAlgorithm field of the type KeyTransRecipientInfo [RFC3852] for encrypting the temporary key in the encryptedKey field [RFC3852] with a public key, as described in Section 3.2.3.2: rsaEncryption (this is the RSAES-PKCS1-v1_5 encryption scheme) [RFC3370] [RFC3447].
b) Content encryption algorithms identified in the contentEncryptionAlgorithm field of the type EncryptedContentInfo [RFC3852] for encrypting the AS reply key with the temporary key contained in the encryptedKey field of the type KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2: des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
PKINIT makes use of the following new pre-authentication types:
PKINITでは次の新しい事前認証型を使います。
PA_PK_AS_REQ 16
PA_PK_AS_REP 17
PKINIT also makes use of the following new authorization data type:
PKINITでは次の新しい認可データ型も使います。
AD_INITIAL_VERIFIED_CAS 9
PKINIT introduces the following new error codes:
PKINITでは次の新しいエラーコードを定義します。
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_INVALID_SIG 64
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
PKINIT uses the following typed data types for errors:
PKINITではエラーに次のtyped-data型を使います。
TD_TRUSTED_CERTIFIERS 104
TD_INVALID_CERTIFICATES 105
TD_DH_PARAMETERS 109
The ASN.1 module for all structures defined in this document (plus IMPORT statements for all imported structures) is given in Appendix A.
本書で定義するすべての構造（およびインポートするすべての構造のIMPORT文）を含むASN.1モジュールを付録Aに示します。
All structures defined in or imported into this document MUST be encoded using Distinguished Encoding Rules (DER) [X680] [X690] (unless otherwise noted). All data structures carried in OCTET STRINGs MUST be encoded according to the rules specified in the specifications defining each data structure; a reference to the appropriate specification is provided for each data structure.
本書で定義またはインポートするすべての構造は、特に明記しない限り、Distinguished Encoding Rules（DER）[X680] [X690] でエンコードしなければなりません (MUST)。OCTET STRINGに格納するすべてのデータ構造は、その構造を定義する仕様の規則に従ってエンコードしなければなりません (MUST)。各データ構造について、該当する仕様を参照しています。
Interoperability note: Some implementations may not be able to decode wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded with BER; specifically, they may not be able to decode indefinite-length encodings. To maximize interoperability, implementers SHOULD encode CMS objects used in PKINIT with DER.
相互運用性に関する注意：実装によっては、BERでエンコードされたCryptographic Message Syntax（CMS）[RFC3852]オブジェクト（特に長さが不定の符号化）をデコードできない場合があります。相互運用性を最大限に高めるため、実装者はPKINITで使うCMSオブジェクトをDERでエンコードすべきです (SHOULD)。
PKINIT defines the following Kerberos encryption type numbers [RFC3961], which can be used in the etype field of the AS-REQ [RFC4120] message to indicate to the KDC the client's acceptance of the corresponding algorithms (including key transport algorithms [RFC3370], content encryption algorithms [RFC3370], and signature algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852] [RFC3370].
Per [RFC4120], the encryption types in the etype field are in the decreasing preference order of the client. Note that there is no significance in the relative order between any two of different types of algorithms: key transport algorithms, content encryption algorithms, and signature algorithms.
[RFC4120]に従い、etypeフィールド内の暗号化型はクライアントの優先順位が高い順に並べます。ただし、鍵転送、コンテンツ暗号化、署名という異なる種類のアルゴリズム間では、相対的な順序に意味はありません。
The presence of each of these encryption types in the etype field is equivalent to the presence of the corresponding algorithm Object Identifier (OID) in the supportedCMSTypes field as described in Section 3.2.1. And the preference order expressed in the supportedCMSTypes field would override the preference order listed in the etype field.
etypeフィールドにこれらの暗号化型を指定することは、セクション3.2.1で説明するsupportedCMSTypesフィールドに対応するアルゴリズムのObject Identifier（OID）を指定することと同等です。また、supportedCMSTypesフィールドに示す優先順位はetypeフィールドに示す優先順位に優先します。
Kerberos Encryption Type Name Num Corresponding Algorithm OID
============================== === ===============================
id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3370]
md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3370]
sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3370]
rc2-cbc-EnvOID 12 rc2-cbc [RFC3370]
rsaEncryption-EnvOID 13 rsaEncryption [RFC3447][RFC3370]
id-RSAES-OAEP-EnvOID 14 id-RSAES-OAEP [RFC3447][RFC3560]
des-ede3-cbc-EnvOID 15 des-ede3-cbc [RFC3370]
The above encryption type numbers are used only to indicate support for the use of the corresponding algorithms in PKINIT; they do not correspond to actual Kerberos encryption types [RFC3961] and MUST NOT be used in the etype field of the Kerberos EncryptedData type [RFC4120]. The practice of assigning Kerberos encryption type numbers to indicate support for CMS algorithms is considered deprecated, and new numbers should not be assigned for this purpose. Instead, the supportedCMSTypes field should be used to identify the algorithms supported by the client and the preference order of the client.
For maximum interoperability, however, PKINIT clients wishing to indicate to the KDC the support for one or more of the algorithms listed above SHOULD include the corresponding encryption type number(s) in the etype field of the AS-REQ.
ただし、相互運用性を最大限に高めるため、上記アルゴリズムのいずれかをサポートすることをKDCに示したいPKINITクライアントは、対応する暗号化型番号をAS-REQのetypeフィールドに含めるべきです (SHOULD)。
This section defines the syntax and use of the various pre-authentication fields employed by PKINIT.
この節では、PKINITが使う各種事前認証フィールドの構文と使用方法を定義します。
The initial authentication request (AS-REQ) is sent as per [RFC4120]; in addition, a pre-authentication data element, whose padata-type is PA_PK_AS_REQ and whose padata-value contains the DER encoding of the type PA-PK-AS-REQ, is included.
初期認証要求（AS-REQ）は[RFC4120]に従って送信します。これに加えて、padata-typeがPA_PK_AS_REQで、padata-valueにPA-PK-AS-REQ型のDER符号化を格納する事前認証データ要素を含めます。
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the
-- type AuthPack.
-- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL,
-- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
-- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as
-- hints to guide its selection of an appropriate
-- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852].
-- Identifies, if present, a particular KDC
-- public key that the client already has.
...
}
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a PKIX type Name encoded according to
-- [RFC3280].
-- Identifies the certificate subject by the
-- distinguished subject name.
-- REQUIRED when there is a distinguished subject
-- name present in the certificate.
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a CMS type IssuerAndSerialNumber encoded
-- according to [RFC3852].
-- Identifies a certificate of the subject.
-- REQUIRED for TD-INVALID-CERTIFICATES and
-- TD-TRUSTED-CERTIFIERS.
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
-- Identifies the subject's public key by a key
-- identifier. When an X.509 certificate is
-- referenced, this key identifier matches the X.509
-- subjectKeyIdentifier extension value. When other
-- certificate formats are referenced, the documents
-- that specify the certificate format and their use
-- with the CMS must include details on matching the
-- key identifier to the appropriate certificate
-- field.
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in
-- [RFC3280].
-- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363].
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
-- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- Type AlgorithmIdentifier is defined in
-- [RFC3280].
-- List of CMS algorithm [RFC3370] identifiers
-- that identify key transport algorithms, or
-- content encryption algorithms, or signature
-- algorithms supported by the client in order of
-- (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it
-- wishes to reuse DH keys or to allow the KDC to
-- do so (see Section 3.2.3.1).
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for
-- replay prevention.
nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present.
-- Contains the SHA1 checksum, performed over
-- KDC-REQ-BODY.
...
}
2. The eContentType field for the type SignedData is id-pkinit-authData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS implementers: the signed attribute content-type MUST be present in this SignedData instance, and its value is id-pkinit-authData according to [RFC3852].
2. SignedData型のeContentTypeフィールドは id-pkinit-authData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) authData(1) } です。CMS実装者への注記: 署名属性content-typeは、このSignedDataインスタンスに存在しなければならず (MUST)、その値は [RFC3852] に従い id-pkinit-authData です。
3. The eContent field for the type SignedData contains the DER encoding of the type AuthPack.
3. SignedData型のeContentフィールドには、AuthPack型のDERエンコーディングが含まれます。
4. The signerInfos field of the type SignedData contains a single signerInfo, which contains the signature over the type AuthPack.
4. SignedData型のsignerInfosフィールドには、単一のsignerInfoが含まれます。このsignerInfoには、AuthPack型に対する署名が含まれます。
5. The AuthPack structure contains a PKAuthenticator, the client public key information, the CMS encryption types supported by the client, and a DHNonce. The pkAuthenticator field certifies to the KDC that the client has recent knowledge of the signing key that authenticates the client. The clientPublicValue field specifies Diffie-Hellman domain parameters and the client's public key value. The DH public key value is encoded as a BIT STRING according to [RFC3279]. The clientPublicValue field is present only if the client wishes to use the Diffie-Hellman key agreement method. The supportedCMSTypes field specifies the list of CMS algorithm identifiers that are supported by the client in order of (decreasing) preference, and can be used to identify a signature algorithm or a key transport algorithm [RFC3370] in the keyEncryptionAlgorithm field of the type KeyTransRecipientInfo, or a content encryption algorithm [RFC3370] in the contentEncryptionAlgorithm field of the type EncryptedContentInfo [RFC3852] when encrypting the AS reply key as described in Section 3.2.3.2. However, there is no significance in the relative order between any two of different types of algorithms: key transport algorithms, content encryption algorithms, and signature algorithms. The clientDHNonce field is described later in this section.
5. AuthPack構造体には、PKAuthenticator、クライアントの公開鍵情報、クライアントがサポートするCMS暗号化方式、およびDHNonceが含まれます。pkAuthenticatorフィールドは、クライアントが自身を認証する署名鍵を最近使用したことをKDCに証明します。clientPublicValueフィールドは、Diffie-Hellmanのドメインパラメーターとクライアントの公開鍵値を指定します。DH公開鍵値は、[RFC3279]に従ってBIT STRINGとしてエンコードされます。clientPublicValueフィールドは、クライアントがDiffie-Hellman鍵合意方式を使用する場合にのみ存在します。supportedCMSTypesフィールドは、クライアントがサポートするCMSアルゴリズム識別子の一覧を、優先度の高い順に指定します。この一覧は、AS reply keyを暗号化する際に、KeyTransRecipientInfo型のkeyEncryptionAlgorithmフィールドに指定する署名アルゴリズムまたは鍵配送アルゴリズム[RFC3370]、あるいはEncryptedContentInfo型のcontentEncryptionAlgorithmフィールドに指定するコンテンツ暗号化アルゴリズム[RFC3370]を識別するために使用できます（セクション3.2.3.2参照）。ただし、鍵配送アルゴリズム、コンテンツ暗号化アルゴリズム、署名アルゴリズムという異なる種類のアルゴリズム同士の相対的な順序には意味がありません。clientDHNonceフィールドについては、このセクションの後半で説明します。
6. The ctime field in the PKAuthenticator structure contains the current time on the client's host, and the cusec field contains the microsecond part of the client's timestamp. The ctime and cusec fields are used together to specify a reasonably accurate timestamp [RFC4120]. The nonce field is chosen randomly. The paChecksum field MUST be present and it contains a SHA1 checksum that is performed over the KDC-REQ-BODY [RFC4120]. In order to ease future migration from the use of SHA1, the paChecksum field is made optional syntactically: when the request is extended to negotiate hash algorithms, the new client wishing not to use SHA1 will send the request in the extended message syntax without the paChecksum field. The KDC conforming to this specification MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3). That will allow a new client to retry with SHA1 if allowed by the local policy.
6. PKAuthenticator構造体のctimeフィールドにはクライアントホストの現在時刻が含まれ、cusecフィールドにはクライアントのタイムスタンプのマイクロ秒部分が含まれます。ctimeフィールドとcusecフィールドは、十分に正確なタイムスタンプを指定するために併用されます [RFC4120]。nonceフィールドにはランダムな値を設定します。paChecksumフィールドは必ず存在し (MUST)、KDC-REQ-BODYに対して計算したSHA1チェックサムを含みます [RFC4120]。SHA1の使用から将来移行しやすくするため、paChecksumフィールドは構文上は省略可能になっています。ハッシュアルゴリズムのネゴシエーションに対応する拡張要求では、SHA1を使用しない新しいクライアントは、paChecksumフィールドを含めずに拡張メッセージ構文で要求を送信します。この仕様に準拠するKDCは、KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDEDコードを含むKRB-ERRORメッセージを返さなければなりません (MUST)（セクション3.2.3参照）。これにより、ローカルポリシーで許可されていれば、新しいクライアントはSHA1を使って再試行できます。
7. The certificates field of the type SignedData contains certificates intended to facilitate certification path construction, so that the KDC can verify the signature over the type AuthPack. For path validation, these certificates SHOULD be sufficient to construct at least one certification path from the client certificate to one trust anchor acceptable by the KDC [RFC4158]. The client MUST be capable of including such a set of certificates if configured to do so. The certificates field MUST NOT contain "root" CA certificates.
7. SignedData型のcertificatesフィールドには、認証パスの構築を助け、KDCがAuthPack型への署名を検証できるようにする証明書が含まれます。パス検証では、これらの証明書は、クライアント証明書からKDCが信頼できる少なくとも1つのトラストアンカーまで認証パスを構築するのに十分であるべきです (SHOULD) [RFC4158]。クライアントは、そのように設定されている場合、この証明書一式を含められなければなりません (MUST)。certificatesフィールドに「ルート」CA証明書を含めてはなりません (MUST NOT)。
8. The client's Diffie-Hellman public value (clientPublicValue) is included if and only if the client wishes to use the Diffie-Hellman key agreement method. The Diffie-Hellman domain parameters [IEEE1363] for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279], and the client's Diffie-Hellman public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279]. When using the Diffie-Hellman key agreement method, implementations MUST support Oakley 1024-bit Modular Exponential (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit MODP well-known group 16 [RFC3526].
8. クライアントのDiffie-Hellman公開値（clientPublicValue）は、クライアントがDiffie-Hellman鍵合意方式を使用する場合に限り含めます。クライアントの公開鍵に関するDiffie-Hellmanドメインパラメーター [IEEE1363] は、SubjectPublicKeyInfo型のalgorithmフィールドで指定します [RFC3279]。また、クライアントのDiffie-Hellman公開鍵値は、[RFC3279]に従ってsubjectPublicKey（BIT STRING）に対応付けます。Diffie-Hellman鍵合意方式を使用する場合、実装はOakley 1024ビットMODP既知グループ2 [RFC2412] とOakley 2048ビットMODP既知グループ14 [RFC3526] をサポートしなければなりません (MUST)。また、Oakley 4096ビットMODP既知グループ16 [RFC3526] をサポートすべきです (SHOULD)。
The Diffie-Hellman field size should be chosen so as to provide sufficient cryptographic security [RFC3766].
Diffie-Hellmanのフィールドサイズは、十分な暗号学的安全性が得られるように選択すべきです [RFC3766]。
When MODP Diffie-Hellman is used, the exponents should have at least twice as many bits as the symmetric keys that will be derived from them [ODL99].
MODP Diffie-Hellmanを使用する場合、指数のビット数は、そこから導出する対称鍵のビット数の少なくとも2倍にすべきです [ODL99]。
9. The client may wish to reuse DH keys or to allow the KDC to do so (see Section 3.2.3.1). If so, then the client includes the clientDHNonce field. This nonce string MUST be as long as the longest key length of the symmetric key types that the client supports. This nonce MUST be chosen randomly.
9. クライアントはDH鍵を再利用したり、KDCに再利用を許可したりすることがあります（セクション3.2.3.1参照）。その場合、クライアントはclientDHNonceフィールドを含めます。このnonce文字列の長さは、クライアントがサポートする対称鍵のうち最長の鍵長以上でなければなりません (MUST)。このnonceはランダムに選ばなければなりません (MUST)。
The ExternalPrincipalIdentifier structure is used in this document to identify the subject's public key thereby the subject principal. This structure is filled out as follows:
この文書では、ExternalPrincipalIdentifier構造体を使用して、主体の公開鍵を識別し、それによって主体プリンシパルを特定します。この構造体の各フィールドは、次のように設定します。
1. The subjectName field contains a PKIX type Name encoded according to [RFC3280]. This field identifies the certificate subject by the distinguished subject name. This field is REQUIRED when there is a distinguished subject name present in the certificate being used.
1. subjectNameフィールドには、[RFC3280]に従ってエンコードされたPKIX Name型が含まれます。このフィールドは、識別名によって証明書の主体を特定します。使用する証明書に識別名が存在する場合、このフィールドは必須です (MUST)。
2. The issuerAndSerialNumber field contains a CMS type IssuerAndSerialNumber encoded according to [RFC3852]. This field identifies a certificate of the subject. This field is REQUIRED for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both structures are defined in Section 3.2.2).
2. issuerAndSerialNumberフィールドには、[RFC3852]に従ってエンコードされたCMS IssuerAndSerialNumber型が含まれます。このフィールドは主体の証明書を特定します。TD-INVALID-CERTIFICATESおよびTD-TRUSTED-CERTIFIERSでは、このフィールドは必須です (MUST)（両構造体はセクション3.2.2で定義）。
3. The subjectKeyIdentifier [RFC3852] field identifies the subject's public key by a key identifier. When an X.509 certificate is referenced, this key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. This field is RECOMMENDED for TD-TRUSTED-CERTIFIERS (as defined in Section 3.2.2).
3. subjectKeyIdentifierフィールド [RFC3852] は、鍵識別子によって主体の公開鍵を特定します。X.509証明書を参照する場合、この鍵識別子はX.509のsubjectKeyIdentifier拡張の値と一致します。他の証明書形式を参照する場合、その証明書形式とCMSでの使用を規定する文書に、鍵識別子を対応する証明書フィールドと照合する方法を記載する必要があります。このフィールドはTD-TRUSTED-CERTIFIERSで推奨されます (SHOULD)（セクション3.2.2で定義）。
The trustedCertifiers field of the type PA-PK-AS-REQ contains a list of CAs, trusted by the client, that can be used to certify the KDC. Each ExternalPrincipalIdentifier identifies a CA or a CA certificate (thereby its public key).
PA-PK-AS-REQ型のtrustedCertifiersフィールドには、クライアントが信頼し、KDCの認証に使用できるCAの一覧が含まれます。各ExternalPrincipalIdentifierは、CAまたはCA証明書（したがって、その公開鍵）を特定します。
The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type SignerIdentifier encoded according to [RFC3852]. This field identifies, if present, a particular KDC public key that the client already has.
PA-PK-AS-REQ型のkdcPkIdフィールドには、[RFC3852]に従ってエンコードされたCMS SignerIdentifier型が含まれます。このフィールドが存在する場合、クライアントがすでに保持している特定のKDC公開鍵を特定します。
Upon receiving the client's request, the KDC validates it. This section describes the steps that the KDC MUST (unless otherwise noted) take in validating the request.
クライアントの要求を受信すると、KDCはその内容を検証します。このセクションでは、特に指定がない限り、KDCが要求の検証時に実行しなければならない手順を説明します (MUST)。
The KDC verifies the client's signature in the signedAuthPack field according to [RFC3852].
KDCは[RFC3852]に従って、signedAuthPackフィールドに含まれるクライアントの署名を検証します。
If, while validating the client's X.509 certificate [RFC3280], the KDC cannot build a certification path to validate the client's certificate, it sends back a KRB-ERROR [RFC4120] message with the code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this error message is a TYPED-DATA (as defined in [RFC4120]) that contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data-value contains the DER encoding of the type TD-TRUSTED-CERTIFIERS:
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate (thereby its public key) trusted by the KDC.
TD-TRUSTED-CERTIFIERS構造体に含まれる各ExternalPrincipalIdentifier（セクション3.2.1で定義）は、KDCが信頼するCAまたはCA証明書（したがって、その公開鍵）を特定します。
Upon receiving this error message, the client SHOULD retry only if it has a different set of certificates (from those of the previous requests) that form a certification path (or a partial path) from one of the trust anchors acceptable by the KDC to its own certificate.
このエラーメッセージを受信したクライアントは、前回までの要求に含めたものとは異なる証明書一式を持ち、その一式で、KDCが信頼できるトラストアンカーのいずれかからクライアント自身の証明書までの認証パス（または部分パス）を構成できる場合に限り、再試行すべきです (SHOULD)。
If, while processing the certification path, the KDC determines that the signature on one of the certificates in the signedAuthPack field is invalid, it returns a KRB-ERROR [RFC4120] message with the code KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error message is a TYPED-DATA that contains an element whose data-type is TD_INVALID_CERTIFICATES, and whose data-value contains the DER encoding of the type TD-INVALID-CERTIFICATES:
認証パスの処理中に、KDCがsignedAuthPackフィールド内の証明書のいずれかの署名を無効と判定した場合、KDCはKDC_ERR_INVALID_CERTIFICATEコードを含むKRB-ERRORメッセージを返します [RFC4120]。このエラーメッセージに付随するe-dataはTYPED-DATAであり、data-typeがTD_INVALID_CERTIFICATES、data-valueがTD-INVALID-CERTIFICATES型のDERエンコーディングである要素を含みます。
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid
-- signature.
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the TD-INVALID-CERTIFICATES structure identifies a certificate (that was sent by the client) with an invalid signature.
TD-INVALID-CERTIFICATES構造体に含まれる各ExternalPrincipalIdentifier（セクション3.2.1で定義）は、無効な署名を持つ証明書（クライアントが送信したもの）を特定します。
If more than one X.509 certificate signature is invalid, the KDC MAY include one IssuerAndSerialNumber per invalid signature within the TD-INVALID-CERTIFICATES.
複数のX.509証明書の署名が無効な場合、KDCはTD-INVALID-CERTIFICATES内に、無効な署名ごとに1つのIssuerAndSerialNumberを含めてもかまいません (MAY)。
The client's X.509 certificate is validated according to [RFC3280].
クライアントのX.509証明書は[RFC3280]に従って検証します。
Depending on local policy, the KDC may also check whether any X.509 certificates in the certification path validating the client's certificate have been revoked. If any of them have been revoked, the KDC MUST return an error message with the code KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the revocation status but is unable to do so, it SHOULD return an error message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or certificates affected are identified exactly as for the error code KDC_ERR_INVALID_CERTIFICATE (see above).
ローカルポリシーによっては、KDCはクライアント証明書の認証パスに含まれるX.509証明書が失効していないか確認することもあります。いずれかの証明書が失効している場合、KDCはKDC_ERR_REVOKED_CERTIFICATEコードを含むエラーメッセージを返さなければなりません (MUST)。失効状態の判定を試みても判定できない場合、KDCはKDC_ERR_REVOCATION_STATUS_UNKNOWNコードを含むエラーメッセージを返すべきです (SHOULD)。該当する証明書は、エラーコードKDC_ERR_INVALID_CERTIFICATEの場合と同じ方法で特定します（前述参照）。
Note that the TD_INVALID_CERTIFICATES error data is only used to identify invalid certificates sent by the client in the request.
TD_INVALID_CERTIFICATESエラーデータは、要求内でクライアントが送信した無効な証明書を特定する場合にのみ使用することに注意してください。
The client's public key is then used to verify the signature. If the signature fails to verify, the KDC MUST return an error message with the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error message.
次に、クライアントの公開鍵を使って署名を検証します。署名を検証できない場合、KDCはKDC_ERR_INVALID_SIGコードを含むエラーメッセージを返さなければなりません (MUST)。このエラーメッセージに付随するe-dataはありません。
In addition to validating the client's signature, the KDC MUST also check that the client's public key used to verify the client's signature is bound to the client principal name specified in the AS-REQ as follows:
クライアントの署名の検証に加え、KDCは、その検証に使用したクライアントの公開鍵が、AS-REQで指定されたクライアントプリンシパル名に次のいずれかの方法で結び付けられていることも確認しなければなりません (MUST)。
1. If the KDC has its own binding between either the client's signature-verification public key or the client's certificate and the client's Kerberos principal name, it uses that binding.
1. KDCが、クライアントの署名検証用公開鍵またはクライアント証明書と、クライアントのKerberosプリンシパル名との対応付けを独自に保持している場合、KDCはその対応付けを使用します。
2. Otherwise, if the client's X.509 certificate contains a Subject Alternative Name (SAN) extension carrying a KRB5PrincipalName (defined below) in the otherName field of the type GeneralName [RFC3280], it binds the client's X.509 certificate to that name.
2. それ以外の場合、クライアントのX.509証明書にSubject Alternative Name（SAN）拡張が含まれ、そのotherNameフィールド（GeneralName型 [RFC3280]）にKRB5PrincipalName（後述）が格納されていれば、KDCはクライアントのX.509証明書をその名前に対応付けます。
The type of the otherName field is AnotherName. The type-id field of the type AnotherName is id-pkinit-san:
otherNameフィールドの型はAnotherNameです。AnotherName型のtype-idフィールドにはid-pkinit-sanを指定します。
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
And the value field of the type AnotherName is a KRB5PrincipalName.
AnotherName型のvalueフィールドにはKRB5PrincipalNameを格納します。
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
If the Kerberos client name in the AS-REQ does not match a name bound by the KDC (the binding can be in the certificate, for example, as described above), or if there is no binding found by the KDC, the KDC MUST return an error message with the code KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for this error message.
AS-REQのKerberosクライアント名がKDCによって対応付けられた名前と一致しない場合（前述のように、対応付けは証明書内にある場合があります）、またはKDCが対応付けを見つけられない場合、KDCはKDC_ERR_CLIENT_NAME_MISMATCHコードを含むエラーメッセージを返さなければなりません (MUST)。このエラーメッセージに付随するe-dataはありません。
Even if the certification path is validated and the certificate is mapped to the client's principal name, the KDC may decide not to accept the client's certificate, depending on local policy.
認証パスが検証され、証明書がクライアントのプリンシパル名に対応付けられていても、KDCはローカルポリシーに応じてクライアント証明書を受け入れないことがあります。
The KDC MAY require the presence of an Extended Key Usage (EKU) KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field of the client's X.509 certificate:
KDCは、クライアントのX.509証明書のextensionsフィールドにExtended Key Usage（EKU）KeyPurposeId [RFC3280] id-pkinit-KPClientAuthが存在することを要求してもかまいません (MAY)。
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeClientAuth(4) }
-- PKINIT client authentication.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
The digitalSignature key usage bit [RFC3280] MUST be asserted when the intended purpose of the client's X.509 certificate is restricted with the id-pkinit-KPClientAuth EKU.
クライアントのX.509証明書の用途がid-pkinit-KPClientAuth EKUによって制限されている場合、digitalSignature鍵使用ビット [RFC3280] を設定しなければなりません (MUST)。
If this EKU KeyPurposeId is required but it is not present, or if the client certificate is restricted not to be used for PKINIT client authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There is no accompanying e-data for this error message. KDCs implementing this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a large number of X.509 client certificates deployed for use with PKINIT that have this EKU.
このEKU KeyPurposeIdが必須なのに存在しない場合、または[RFC3280]のセクション4.2.1.13に従い、クライアント証明書のPKINITクライアント認証での使用が制限されている場合、KDCはKDC_ERR_INCONSISTENT_KEY_PURPOSEコードのエラーメッセージを返さなければなりません (MUST)。このエラーメッセージに付随するe-dataはありません。この要件を実装するKDCは、id-ms-kp-sc-logon（1.3.6.1.4.1.311.20.2.2）というEKU KeyPurposeIdも要件を満たすものとして受け入れるべきです (SHOULD)。PKINITで使用するために配備されたX.509クライアント証明書の多くが、このEKUを持っているためです。
As a matter of local policy, the KDC MAY decide to reject requests on the basis of the absence or presence of other specific EKU OIDs.
ローカルポリシーとして、KDCは他の特定のEKU OIDの有無に基づいて要求を拒否してもかまいません (MAY)。
If the digest algorithm used in generating the CA signature for the public key in any certificate of the request is not acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be encoded in TYPED-DATA, although none is defined at this point.
要求内のいずれかの証明書について、その公開鍵に対するCA署名の生成に使われたダイジェストアルゴリズムをKDCが受け入れられない場合、KDCはKDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTEDコードを含むKRB-ERRORメッセージを返さなければなりません (MUST) [RFC4120]。現時点では内容が定義されていませんが、付随するe-dataはTYPED-DATAとしてエンコードしなければなりません (MUST)。
If the client's public key is not accepted with reasons other than those specified above, the KDC returns a KRB-ERROR [RFC4120] message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no accompanying e-data currently defined for this error message.
前述の理由以外でクライアントの公開鍵を受け入れない場合、KDCはKDC_ERR_CLIENT_NOT_TRUSTEDコードを含むKRB-ERRORメッセージを返します [RFC4120]。このエラーメッセージに付随するe-dataは、現時点では定義されていません。
The KDC MUST check the timestamp to ensure that the request is not a replay, and that the time skew falls within acceptable limits. The recommendations for clock skew times in [RFC4120] apply here. If the check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.
KDCは、要求がリプレイでないこと、および時刻のずれが許容範囲内であることを確認するため、タイムスタンプを検査しなければなりません (MUST)。ここでは[RFC4120]のクロックスキューに関する推奨値が適用されます。検査に失敗した場合、KDCはそれぞれKRB_AP_ERR_REPEATまたはKRB_AP_ERR_SKEWエラーコードを返さなければなりません (MUST)。
If the clientPublicValue is filled in, indicating that the client wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD check to see if the key parameters satisfy its policy. If they do not, it MUST return an error message with the code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a TYPED-DATA that contains an element whose data-type is TD_DH_PARAMETERS, and whose data-value contains the DER encoding of the type TD-DH-PARAMETERS:
clientPublicValueが設定されていて、クライアントがDiffie-Hellman鍵合意方式の使用を希望していることを示す場合、KDCは鍵パラメーターが自身のポリシーを満たすか確認すべきです (SHOULD)。満たさない場合、KDCはKDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTEDコードを含むエラーメッセージを返さなければなりません (MUST)。付随するe-dataはTYPED-DATAであり、data-typeがTD_DH_PARAMETERS、data-valueがTD-DH-PARAMETERS型のDERエンコーディングである要素を含みます。
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order.
TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters that the KDC supports in decreasing preference order, from which the client SHOULD pick one to retry the request.
TD-DH-PARAMETERSには、KDCがサポートするDiffie-Hellmanドメインパラメーターの一覧が優先度の高い順に含まれます。クライアントはその中から1つを選び、要求を再試行すべきです (SHOULD)。
If the client included a kdcPkId field in the PA-PK-AS-REQ and the KDC does not possess the corresponding key, the KDC MUST ignore the kdcPkId field as if the client did not include one.
クライアントがPA-PK-AS-REQにkdcPkIdフィールドを含めていても、KDCが対応する鍵を持っていない場合、KDCは、クライアントがkdcPkIdフィールドを含めなかったものとして、そのフィールドを無視しなければなりません (MUST)。
If the digest algorithm used by the id-pkinit-authData is not acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. The accompanying e-data MUST be encoded in TYPED-DATA, although none is defined at this point.
id-pkinit-authDataで使用されたダイジェストアルゴリズムをKDCが受け入れられない場合、KDCはKDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTEDコードを含むKRB-ERRORメッセージを返さなければなりません (MUST) [RFC4120]。現時点では内容が定義されていませんが、付随するe-dataはTYPED-DATAとしてエンコードしなければなりません (MUST)。
If the paChecksum filed in the request is not present, the KDC conforming to this specification MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. The accompanying e-data MUST be encoded in TYPED-DATA (no error data is defined by this specification).
要求にpaChecksumフィールドが含まれていない場合、この仕様に準拠するKDCはKDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDEDコードを含むKRB-ERRORメッセージを返さなければなりません (MUST) [RFC4120]。付随するe-dataはTYPED-DATAとしてエンコードしなければなりません (MUST)（この仕様ではエラーデータを定義していません）。
Assuming that the client's request has been properly validated, the KDC proceeds as per [RFC4120], except as follows.
クライアントの要求が適切に検証されたら、以下の点を除き、KDCは[RFC4120]に従って処理を進めます。
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies the certification path with which
-- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
The AD-INITIAL-VERIFIED-CAS structure identifies the certification path with which the client certificate was validated. Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate (thereby its public key).
AD-INITIAL-VERIFIED-CAS構造体は、クライアント証明書の検証に使用した認証パスを特定します。この構造体に含まれる各ExternalPrincipalIdentifier（セクション3.2.1で定義）は、CAまたはCA証明書（したがって、その公開鍵）を特定します。
Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization data does permit empty SEQUENCEs to be encoded. Such empty sequences may only be used if the KDC itself vouches for the user's certificate.
AD-INITIAL-VERIFIED-CAS認可データの構文では、空のSEQUENCEをエンコードできます。ただし、このような空のSEQUENCEを使用できるのは、KDC自体がユーザーの証明書を保証する場合に限られます。
The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT containers if the list of CAs satisfies the AS' realm's local policy (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag [RFC4120]). Furthermore, any TGS MUST copy such authorization data from tickets used within a PA-TGS-REQ of the TGS-REQ into the resulting ticket. If the list of CAs satisfies the local KDC's realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT container; otherwise, it MAY unwrap the authorization data out of the AD-IF-RELEVANT container.
CAの一覧がASのレルムのローカルポリシーを満たす場合、ASはAD-INITIAL-VERIFIED-CASデータをAD-IF-RELEVANTコンテナに格納します（これはTRANSITED-POLICY-CHECKEDチケットフラグに対応します [RFC4120]）。さらに、すべてのTGSは、TGS-REQのPA-TGS-REQ内で使用されたチケットから、そのような認可データを結果のチケットにコピーしなければなりません (MUST)。CAの一覧がローカルKDCのレルムポリシーを満たす場合、TGSはそのデータをAD-IF-RELEVANTコンテナに格納してもかまいません (MAY)。満たさない場合、TGSはコンテナから認可データを取り出してもかまいません (MAY)。
Application servers that understand this authorization data type SHOULD apply local policy to determine whether a given ticket bearing such a type *not* contained within an AD-IF-RELEVANT container is acceptable. (This corresponds to the AP server's checking the transited field when the TRANSITED-POLICY-CHECKED flag has not been set [RFC4120].) If such a data type is contained within an AD-IF-RELEVANT container, AP servers MAY apply local policy to determine whether the authorization data is acceptable.
この認可データ型を理解するアプリケーションサーバーは、AD-IF-RELEVANTコンテナに格納されていないこの型のデータを持つチケットを受け入れられるか、ローカルポリシーに基づいて判断すべきです (SHOULD)（TRANSITED-POLICY-CHECKEDフラグが設定されていない場合にAPサーバーがtransitedフィールドを確認することに対応します [RFC4120]）。このデータ型がAD-IF-RELEVANTコンテナに格納されている場合、APサーバーは認可データを受け入れられるか、ローカルポリシーに基づいて判断してもかまいません (MAY)。
A pre-authentication data element, whose padata-type is PA_PK_AS_REP and whose padata-value contains the DER encoding of the type PA-PK-AS-REP (defined below), is included in the AS-REP [RFC4120].
padata-typeがPA_PK_AS_REPであり、padata-valueにPA-PK-AS-REP型（後述）のDERエンコーディングが含まれる認証前データ要素を、AS-REPに含めます [RFC4120]。
PA-PK-AS-REP ::= CHOICE {
dhInfo [0] DHRepInfo,
-- Selected when Diffie-Hellman key exchange is
-- used.
encKeyPack [1] IMPLICIT OCTET STRING,
-- Selected when public key encryption is used.
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-envelopedData (1.2.840.113549.1.7.3).
-- The content field is an EnvelopedData.
-- The contentType field for the type EnvelopedData
-- is id-signedData (1.2.840.113549.1.7.2).
-- The eContentType field for the inner type
-- SignedData (when unencrypted) is
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-- eContent field contains the DER encoding of the
-- type ReplyKeyPack.
-- ReplyKeyPack is defined in Section 3.2.3.2.
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded according
-- to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL,
-- Present if and only if dhKeyExpiration is
-- present in the KDCDHKeyInfo.
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- The KDC's DH public key.
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the pkAuthenticator field
-- in the request if the DH keys are NOT reused,
-- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair,
-- present if and only if the DH keys are reused.
-- If present, the KDC's DH public key MUST not be
-- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
-- field MUST also be omitted. ... }
The content of the AS-REP is otherwise unchanged from [RFC4120]. The KDC encrypts the reply as usual, but not with the client's long-term key. Instead, it encrypts it with either a shared key derived from a Diffie-Hellman exchange or a generated encryption key. The contents of the PA-PK-AS-REP indicate which key delivery method is used.
AS-REPの内容は、その他の点では[RFC4120]から変更されていません。KDCは通常どおり応答を暗号化しますが、クライアントの長期鍵は使いません。代わりに、Diffie-Hellman交換から導出した共有鍵、または生成した暗号鍵を使って暗号化します。どちらの鍵配送方式を使用したかはPA-PK-AS-REPの内容から分かります。
If the client does not wish to use the Diffie-Hellman key delivery method (the clientPublicValue field is not present in the request) and the KDC does not support the public key encryption key delivery method, the KDC MUST return an error message with the code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. There is no accompanying e-data for this error message.
クライアントがDiffie-Hellman鍵配送方式を希望せず（要求にclientPublicValueフィールドがない）、かつKDCが公開鍵暗号による鍵配送方式をサポートしていない場合、KDCはKDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTEDコードを含むエラーメッセージを返さなければなりません (MUST)。このエラーメッセージに付随するe-dataはありません。
In addition, the lifetime of the ticket returned by the KDC MUST NOT exceed that of the client's public-private key pair. The ticket lifetime, however, can be shorter than that of the client's public-private key pair. For the implementations of this specification, the lifetime of the client's public-private key pair is the validity period in X.509 certificates [RFC3280], unless configured otherwise.
さらに、KDCが返すチケットの有効期間は、クライアントの公開鍵と秘密鍵のペアの有効期間を超えてはなりません (MUST NOT)。ただし、チケットの有効期間を鍵ペアの有効期間より短くすることはできます。この仕様の実装では、別途設定しない限り、クライアントの公開鍵と秘密鍵のペアの有効期間はX.509証明書の有効期間です [RFC3280]。
In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
この場合、PA-PK-AS-REPにはDHRepInfo構造体が含まれます。
The ContentInfo [RFC3852] structure for the dhSignedData field is filled in as follows:
dhSignedDataフィールドのContentInfo構造体 [RFC3852] は、次のように設定します。
2. The eContentType field for the type SignedData is the OID value for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS implementers: the signed attribute content-type MUST be present in this SignedData instance, and its value is id-pkinit-DHKeyData according to [RFC3852].
2. SignedData型のeContentTypeフィールドには、id-pkinit-DHKeyDataのOID値を設定します：{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }。CMS実装者への注記：このSignedDataインスタンスには署名属性content-typeが存在しなければなりません (MUST)。その値は[RFC3852]に従いid-pkinit-DHKeyDataです。
3. The eContent field for the type SignedData contains the DER encoding of the type KDCDHKeyInfo.
3. SignedData型のeContentフィールドには、KDCDHKeyInfo型のDERエンコーディングが含まれます。
4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce, and, optionally, the expiration time of the KDC's DH key being reused. The subjectPublicKey field of the type KDCDHKeyInfo field identifies KDC's DH public key. This DH public key value is encoded as a BIT STRING according to [RFC3279]. The nonce field contains the nonce in the pkAuthenticator field in the request if the DH keys are NOT reused. The value of this nonce field is 0 if the DH keys are reused. The dhKeyExpiration field is present if and only if the DH keys are reused. If the dhKeyExpiration field is present, the KDC's public key in this KDCDHKeyInfo structure MUST NOT be used past the point of this expiration time. If this field is omitted, then the serverDHNonce field MUST also be omitted.
4. KDCDHKeyInfo構造体には、KDCの公開鍵、nonce、および任意で再利用中のKDCのDH鍵の有効期限が含まれます。KDCDHKeyInfo型のsubjectPublicKeyフィールドは、KDCのDH公開鍵を特定します。このDH公開鍵値は[RFC3279]に従ってBIT STRINGとしてエンコードされます。DH鍵を再利用しない場合、nonceフィールドには要求内のpkAuthenticatorフィールドにあるnonceが含まれます。DH鍵を再利用する場合、このnonceフィールドの値は0です。dhKeyExpirationフィールドは、DH鍵を再利用する場合に限り存在します。このフィールドが存在する場合、このKDCDHKeyInfo構造体内のKDC公開鍵は、有効期限を過ぎて使用してはなりません (MUST NOT)。dhKeyExpirationフィールドを省略する場合、serverDHNonceフィールドも省略しなければなりません (MUST)。
5. The signerInfos field of the type SignedData contains a single signerInfo, which contains the signature over the type KDCDHKeyInfo.
5. SignedData型のsignerInfosフィールドには、単一のsignerInfoが含まれます。このsignerInfoにはKDCDHKeyInfo型に対する署名が含まれます。
6. The certificates field of the type SignedData contains certificates intended to facilitate certification path construction, so that the client can verify the KDC's signature over the type KDCDHKeyInfo. The information contained in the trustedCertifiers in the request SHOULD be used by the KDC as hints to guide its selection of an appropriate certificate chain to return to the client. This field may be left empty if the KDC public key specified by the kdcPkId field in the PA-PK-AS-REQ was used for signing. Otherwise, for path validation, these certificates SHOULD be sufficient to construct at least one certification path from the KDC certificate to one trust anchor acceptable by the client [RFC4158]. The KDC MUST be capable of including such a set of certificates if configured to do so. The certificates field MUST NOT contain "root" CA certificates.
6. SignedData型のcertificatesフィールドには、クライアントがKDCDHKeyInfo型に対するKDCの署名を検証できるよう、認証パスの構築を助ける証明書が含まれます。要求内のtrustedCertifiersに含まれる情報は、クライアントに返す適切な証明書チェーンをKDCが選ぶ際の手掛かりとして使うべきです (SHOULD)。PA-PK-AS-REQのkdcPkIdフィールドで指定されたKDC公開鍵を署名に使用した場合、このフィールドは空でもかまいません。それ以外の場合、パス検証において、これらの証明書はKDC証明書からクライアントが信頼できる少なくとも1つのトラストアンカーまで認証パスを構築するのに十分であるべきです (SHOULD) [RFC4158]。KDCは、そのように設定されている場合、この証明書一式を含められなければなりません (MUST)。certificatesフィールドに「ルート」CA証明書を含めてはなりません (MUST NOT)。
7. If the client included the clientDHNonce field, then the KDC may choose to reuse its DH keys. If the server reuses DH keys, then it MUST include an expiration time in the dhKeyExpiration field. Past the point of the expiration time, the signature over the type DHRepInfo is considered expired/invalid. When the server reuses DH keys then, it MUST include a serverDHNonce at least as long as the length of keys for the symmetric encryption system used to encrypt the AS reply. Note that including the serverDHNonce changes how the client and server calculate the key to use to encrypt the reply; see below for details. The KDC SHOULD NOT reuse DH keys unless the clientDHNonce field is present in the request.
7. クライアントがclientDHNonceフィールドを含めた場合、KDCはDH鍵を再利用してもかまいません。サーバーがDH鍵を再利用する場合、dhKeyExpirationフィールドに有効期限を含めなければなりません (MUST)。有効期限を過ぎると、DHRepInfo型に対する署名は期限切れまたは無効と見なされます。DH鍵を再利用するサーバーは、AS replyの暗号化に使用する対称暗号方式の鍵長以上の長さを持つserverDHNonceを含めなければなりません (MUST)。serverDHNonceを含めると、クライアントとサーバーが応答の暗号化に使う鍵の計算方法が変わることに注意してください。詳細は後述します。要求にclientDHNonceフィールドがない限り、KDCはDH鍵を再利用すべきではありません (SHOULD NOT)。
The AS reply key is derived as follows:
AS reply keyは次のように導出します。
1. Both the KDC and the client calculate the shared secret value as follows:
1. KDCとクライアントは、どちらも次のように共有シークレット値を計算します。
a) When MODP Diffie-Hellman is used, let DHSharedSecret be the shared secret value. DHSharedSecret is the value ZZ, as described in Section 2.1.1 of [RFC2631].
a) MODP Diffie-Hellmanを使用する場合、共有シークレット値をDHSharedSecretとします。DHSharedSecretは[RFC2631]のセクション2.1.1で説明する値ZZです。
DHSharedSecret is first padded with leading zeros such that the size of DHSharedSecret in octets is the same as that of the modulus, then represented as a string of octets in big-endian order.
DHSharedSecretのオクテット長が法（modulus）の長さと等しくなるよう、まず先頭にゼロを埋めます。その後、ビッグエンディアン順のオクテット列として表します。
Implementation note: Both the client and the KDC can cache the triple (ya, yb, DHSharedSecret), where ya is the client's public key and yb is the KDC's public key. If both ya and yb are the same in a later exchange, the cached DHSharedSecret can be used.
実装上の注記：クライアントとKDCは、組 (ya, yb, DHSharedSecret) をキャッシュできます。ここで、yaはクライアントの公開鍵、ybはKDCの公開鍵です。後続の交換でyaとybがどちらも同じ場合、キャッシュしたDHSharedSecretを使用できます。
3. Define the function octetstring2key() as follows:
3. 次のように関数octetstring2key()を定義します。
octetstring2key(x) == random-to-key(K-truncate(
SHA1(0x00 | x) |
SHA1(0x01 | x) |
SHA1(0x02 | x) |
...
))
where x is an octet string; | is the concatenation operator; 0x00, 0x01, 0x02, etc. are each represented as a single octet; random-to-key() is an operation that generates a protocol key from a bitstring of length K; and K-truncate truncates its input to the first K bits. Both K and random-to-key() are as defined in the kcrypto profile [RFC3961] for the enctype of the AS reply key.
ここで、xはオクテット文字列、|は連結演算子です。0x00、0x01、0x02などは、それぞれ1オクテットとして表します。random-to-key()は、長さKのビット列からプロトコル鍵を生成する操作です。K-truncateは、入力を先頭からKビットに切り詰めます。Kとrandom-to-key()はどちらも、AS reply keyのenctypeに対応するkcryptoプロファイル [RFC3961] で定義されています。
4. When DH keys are reused, let n_c be the clientDHNonce and n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty octet strings.
4. DH鍵を再利用する場合、n_cをclientDHNonce、n_kをserverDHNonceとします。再利用しない場合は、n_cとn_kの両方を空のオクテット文字列とします。
5. The AS reply key k is: k = octetstring2key(DHSharedSecret | n_c | n_k)
5. AS reply key kは次のとおりです。k = octetstring2key(DHSharedSecret | n_c | n_k)
In this case, the PA-PK-AS-REP contains the encKeyPack field where the AS reply key is encrypted.
この場合、PA-PK-AS-REPにはencKeyPackフィールドが含まれ、その中でAS reply keyが暗号化されます。
2. The contentType field for the type EnvelopedData is id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }.
2. EnvelopedData型のcontentTypeフィールドはid-signedDataです：{ iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }。
3. The eContentType field for the inner type SignedData (when decrypted from the encryptedContent field for the type EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. Notes to CMS implementers: the signed attribute content-type MUST be present in this SignedData instance, and its value is id-pkinit-rkeyData according to [RFC3852].
3. 内側のSignedData型のeContentTypeフィールド（EnvelopedData型のencryptedContentフィールドから復号した後の値）はid-pkinit-rkeyDataです：{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }。CMS実装者への注記：このSignedDataインスタンスには署名属性content-typeが存在しなければなりません (MUST)。その値は[RFC3852]に従いid-pkinit-rkeyDataです。
4. The eContent field for the inner type SignedData contains the DER encoding of the type ReplyKeyPack (as described below).
4. 内側のSignedData型のeContentフィールドには、ReplyKeyPack型（後述）のDERエンコーディングが含まれます。
5. The signerInfos field of the inner type SignedData contains a single signerInfo, which contains the signature for the type ReplyKeyPack.
5. 内側のSignedData型のsignerInfosフィールドには、単一のsignerInfoが含まれます。このsignerInfoにはReplyKeyPack型に対する署名が含まれます。
6. The certificates field of the inner type SignedData contains certificates intended to facilitate certification path construction, so that the client can verify the KDC's signature for the type ReplyKeyPack. The information contained in the trustedCertifiers in the request SHOULD be used by the KDC as hints to guide its selection of an appropriate certificate chain to return to the client. This field may be left empty if the KDC public key specified by the kdcPkId field in the PA-PK-AS-REQ was used for signing. Otherwise, for path validation, these certificates SHOULD be sufficient to construct at least one certification path from the KDC certificate to one trust anchor acceptable by the client [RFC4158]. The KDC MUST be capable of including such a set of certificates if configured to do so. The certificates field MUST NOT contain "root" CA certificates.
6. 内側のSignedData型のcertificatesフィールドには、クライアントがReplyKeyPack型に対するKDCの署名を検証できるよう、認証パスの構築を助ける証明書が含まれます。要求内のtrustedCertifiersに含まれる情報は、クライアントに返す適切な証明書チェーンをKDCが選ぶ際の手掛かりとして使うべきです (SHOULD)。PA-PK-AS-REQのkdcPkIdフィールドで指定されたKDC公開鍵を署名に使用した場合、このフィールドは空でもかまいません。それ以外の場合、パス検証において、これらの証明書はKDC証明書からクライアントが信頼できる少なくとも1つのトラストアンカーまで認証パスを構築するのに十分であるべきです (SHOULD) [RFC4158]。KDCは、そのように設定されている場合、この証明書一式を含められなければなりません (MUST)。certificatesフィールドに「ルート」CA証明書を含めてはなりません (MUST NOT)。
7. The recipientInfos field of the type EnvelopedData is a SET that MUST contain exactly one member of type KeyTransRecipientInfo. The encryptedKey of this member contains the temporary key that is encrypted using the client's public key.
7. EnvelopedData型のrecipientInfosフィールドはSETです。このSETにはKeyTransRecipientInfo型の要素をちょうど1つ含めなければなりません (MUST)。この要素のencryptedKeyには、クライアントの公開鍵で暗号化した一時鍵が含まれます。
8. The unprotectedAttrs or originatorInfo fields of the type EnvelopedData MAY be present.
8. EnvelopedData型のunprotectedAttrsフィールドまたはoriginatorInfoフィールドは存在してもかまいません (MAY)。
If there is a supportedCMSTypes field in the AuthPack, the KDC must check to see if it supports any of the listed types. If it supports more than one of the types, the KDC SHOULD use the one listed first. If it does not support any of them, it MUST return an error message with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
AuthPackにsupportedCMSTypesフィールドが含まれる場合、KDCは、一覧にある方式のいずれかをサポートしているか確認します。複数をサポートしている場合、KDCは一覧の先頭にある方式を使うべきです (SHOULD)。どの方式もサポートしていない場合、KDCはKDC_ERR_ETYPE_NOSUPPコードを含むエラーメッセージを返さなければなりません (MUST) [RFC4120]。
Furthermore, the KDC computes the checksum of the AS-REQ in the client request. This checksum is performed over the type AS-REQ, and the protocol key [RFC3961] of the checksum operation is the replyKey, and the key usage number is 6. If the replyKey's enctype is "newer" [RFC4120] [RFC4121], the checksum operation is the required checksum operation [RFC3961] of that enctype.
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP, i.e., the
-- AS reply key.
asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ.
-- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6.
-- If the replyKey's enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt
-- of the AS-REP.
...
}
Implementations of this RSA encryption key delivery method are RECOMMENDED to support RSA keys at least 2048 bits in size.
このRSA公開鍵暗号による鍵配送方式を実装する場合、2048ビット以上のRSA鍵をサポートすることが推奨されます (SHOULD)。
Upon receipt of the KDC's reply, the client proceeds as follows. If the PA-PK-AS-REP contains the dhSignedData field, the client derives the AS reply key using the same procedure used by the KDC, as defined in Section 3.2.3.1. Otherwise, the message contains the encKeyPack field, and the client decrypts and extracts the temporary key in the encryptedKey field of the member KeyTransRecipientInfo and then uses that as the AS reply key.
KDCの応答を受信すると、クライアントは次のように処理します。PA-PK-AS-REPにdhSignedDataフィールドが含まれる場合、クライアントはセクション3.2.3.1で定義した、KDCと同じ手順でAS reply keyを導出します。それ以外の場合、メッセージにはencKeyPackフィールドが含まれます。クライアントはKeyTransRecipientInfo要素のencryptedKeyフィールドにある一時鍵を復号して取り出し、その鍵をAS reply keyとして使用します。
If the public key encryption method is used, the client MUST verify the asChecksum contained in the ReplyKeyPack.
公開鍵暗号方式を使用する場合、クライアントはReplyKeyPackに含まれるasChecksumを検証しなければなりません (MUST)。
In either case, the client MUST verify the signature in the SignedData according to [RFC3852]. The KDC's X.509 certificate MUST be validated according to [RFC3280]. In addition, unless the client can otherwise verify that the public key used to verify the KDC's signature is bound to the KDC of the target realm, the KDC's X.509 certificate MUST contain a Subject Alternative Name extension [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as defined in Section 3.2.2) and whose value is a KRB5PrincipalName that matches the name of the TGS of the target realm (as defined in Section 7.3 of [RFC4120]).
いずれの場合も、クライアントは[RFC3852]に従ってSignedData内の署名を検証しなければなりません (MUST)。KDCのX.509証明書は[RFC3280]に従って検証しなければなりません (MUST)。さらに、KDCの署名検証に使用する公開鍵が対象レルムのKDCに対応付けられていることを別の方法で確認できない限り、KDCのX.509証明書にはSubject Alternative Name拡張 [RFC3280] を含めなければなりません (MUST)。この拡張には、type-idがid-pkinit-san（セクション3.2.2で定義）であり、valueが対象レルムのTGS名（[RFC4120]のセクション7.3で定義）と一致するKRB5PrincipalNameであるAnotherNameを格納します。
Unless the client knows by some other means that the KDC certificate is intended for a Kerberos KDC, the client MUST require that the KDC certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
KDC証明書がKerberos KDCを対象としているとクライアントが別の方法で確認できない限り、クライアントは、KDC証明書にEKU KeyPurposeId [RFC3280] id-pkinit-KPKdcが含まれることを必須としなければなりません (MUST)。
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeKdc(5) }
-- Signing KDC responses.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
The digitalSignature key usage bit [RFC3280] MUST be asserted when the intended purpose of the KDC's X.509 certificate is restricted with the id-pkinit-KPKdc EKU.
KDCのX.509証明書の用途がid-pkinit-KPKdc EKUによって制限されている場合、digitalSignature鍵使用ビット [RFC3280] を設定しなければなりません (MUST)。
If the KDC certificate contains the Kerberos TGS name encoded as an id-pkinit-san SAN, this certificate is certified by the issuing CA as a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
KDC証明書にid-pkinit-san SANとしてエンコードされたKerberos TGS名が含まれる場合、その証明書は発行CAによってKDC証明書として認証されているため、id-pkinit-KPKdc EKUは必要ありません。
If all applicable checks are satisfied, the client then decrypts the enc-part field of the KDC-REP in the AS-REP, using the AS reply key, and then proceeds as described in [RFC4120].
該当するすべての検査に合格したら、クライアントはAS reply keyを使ってAS-REP内のKDC-REPのenc-partフィールドを復号し、その後[RFC4120]に記載されたとおりに処理します。
The client MUST be capable of sending a set of certificates sufficient to allow the KDC to construct a certification path for the client's certificate, if the correct set of certificates is provided through configuration or policy.
構成またはポリシーを通じて適切な証明書一式が提供されている場合、クライアントはKDCがクライアント証明書の認証パスを構築するのに十分な証明書一式を送信できなければなりません (MUST)。
If the client sends all the X.509 certificates on a certification path to a trust anchor acceptable by the KDC, and if the KDC cannot verify the client's public key otherwise, the KDC MUST be able to process path validation for the client's certificate based on the certificates in the request.
クライアントが、KDCの信頼できるトラストアンカーまでの認証パスに含まれるすべてのX.509証明書を送信し、かつKDCが別の方法でクライアントの公開鍵を検証できない場合、KDCは要求内の証明書に基づいてクライアント証明書のパス検証を処理できなければなりません (MUST)。
The KDC MUST be capable of sending a set of certificates sufficient to allow the client to construct a certification path for the KDC's certificate, if the correct set of certificates is provided through configuration or policy.
構成またはポリシーを通じて適切な証明書一式が提供されている場合、KDCはクライアントがKDC証明書の認証パスを構築するのに十分な証明書一式を送信できなければなりません (MUST)。
If the KDC sends all the X.509 certificates on a certification path to a trust anchor acceptable by the client, and the client can not verify the KDC's public key otherwise, the client MUST be able to process path validation for the KDC's certificate based on the certificates in the reply.
KDCが、クライアントの信頼できるトラストアンカーまでの認証パスに含まれるすべてのX.509証明書を送信し、かつクライアントが別の方法でKDCの公開鍵を検証できない場合、クライアントは応答内の証明書に基づいてKDC証明書のパス検証を処理できなければなりません (MUST)。
If pre-authentication is required but was not present in the request, per [RFC4120] an error message with the code KDC_ERR_PREAUTH_FAILED is returned, and a METHOD-DATA object will be stored in the e-data field of the KRB-ERROR message to specify which pre-authentication mechanisms are acceptable. The KDC can then indicate the support of PKINIT by including an empty element whose padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
要求に認証前データが含まれていないものの認証前処理が必要な場合、[RFC4120]に従ってKDC_ERR_PREAUTH_FAILEDコードを含むエラーメッセージを返します。受け入れ可能な認証前方式を示すMETHOD-DATAオブジェクトは、KRB-ERRORメッセージのe-dataフィールドに格納します。KDCは、このMETHOD-DATAオブジェクトにpadata-typeがPA_PK_AS_REQである空の要素を含めることで、PKINITをサポートしていることを示せます。
Otherwise if it is required by the KDC's local policy that the client must be pre-authenticated using the pre-authentication mechanism specified in this document, but no PKINIT pre-authentication was present in the request, an error message with the code KDC_ERR_PREAUTH_FAILED SHOULD be returned.
それ以外の場合、KDCのローカルポリシーで、この文書に規定された認証前方式によるクライアントの認証が求められているにもかかわらず、要求にPKINIT認証前データが含まれていなければ、KDC_ERR_PREAUTH_FAILEDコードを含むエラーメッセージを返すべきです (SHOULD)。
KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET STRING), and clients MUST ignore this and any other value. Future extensions to this protocol may specify other data to send instead of an empty OCTET STRING.
KDCは、KRB-ERRORのMETHOD-DATAにあるPA_PK_AS_REQ要素のpadata-valueフィールドを空にしなければなりません (MUST)（つまり、長さ0のOCTET STRINGを送信します）。クライアントは、この値や他の値を無視しなければなりません (MUST)。このプロトコルの将来の拡張で、空のOCTET STRINGの代わりに送信する別のデータが規定される可能性があります。
The security of cryptographic algorithms is dependent on generating secret quantities [RFC4086]. The number of truly random bits is extremely important in determining the attack resistance strength of the cryptosystem; for example, the secret Diffie-Hellman exponents must be chosen based on n truly random bits (where n is the system security requirement). The security of the overall system is significantly weakened by using insufficient random inputs: a sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
暗号アルゴリズムの安全性は、秘密値の生成に依存します [RFC4086]。真にランダムなビットの数は、暗号システムの攻撃耐性を決めるうえで極めて重要です。たとえば、秘密のDiffie-Hellman指数は、n個の真にランダムなビットに基づいて選ぶ必要があります（nはシステムのセキュリティ要件です）。乱数の入力が不十分だと、システム全体の安全性が大きく損なわれます。高度な攻撃者にとっては、秘密値を生成した環境を再現し、そこから得られる少数の候補を探索するほうが、可能な数値全体から秘密値を探すより容易になる可能性があります。
Kerberos error messages are not integrity protected; as a result, the domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered with by an attacker so that the set of domain parameters selected could be either weaker or not mutually preferred. Local policy can configure sets of domain parameters acceptable locally, or disallow the negotiation of DH domain parameters.
Kerberosのエラーメッセージは完全性保護されていません。そのため、KDCがTD-DH-PARAMETERSとして送信するドメインパラメーターを攻撃者が改ざんし、選択されるパラメーターを弱くしたり、双方の優先度が一致しないものにしたりする可能性があります。ローカルポリシーで、許容するドメインパラメーターの集合を設定したり、DHドメインパラメーターのネゴシエーションを禁止したりできます。
The symmetric reply key size and Diffie-Hellman field size or RSA modulus size should be chosen so as to provide sufficient cryptographic security [RFC3766].
対称応答鍵のサイズ、Diffie-Hellmanフィールドのサイズ、またはRSA法のサイズは、十分な暗号学的安全性が得られるように選ぶことが望ましいです [RFC3766]。
When MODP Diffie-Hellman is used, the exponents should have at least twice as many bits as the symmetric keys that will be derived from them [ODL99].
MODP Diffie-Hellmanを使用する場合、指数のビット数は、そこから導出する対称鍵のビット数の少なくとも2倍にすることが望ましいです [ODL99]。
PKINIT raises certain security considerations beyond those that can be regulated strictly in protocol definitions. We will address them in this section.
PKINITには、プロトコル定義だけでは厳密に規定できないセキュリティ上の考慮事項があります。このセクションではそれらを説明します。
PKINIT extends the cross-realm model to the public-key infrastructure. Users of PKINIT must understand security policies and procedures appropriate to the use of Public Key Infrastructures [RFC3280].
PKINITはクロスレルムモデルを公開鍵基盤に拡張します。PKINITの利用者は、公開鍵基盤の利用に適用されるセキュリティポリシーと手順を理解しておく必要があります [RFC3280]。
In order to trust a KDC certificate that is certified by a CA as a KDC certificate for a target realm (for example, by asserting the TGS name of that Kerberos realm as an id-pkinit-san SAN and/or restricting the certificate usage by using the id-pkinit-KPKdc EKU, as described in Section 3.2.4), the client MUST verify that the KDC certificate's issuing CA is authorized to issue KDC certificates for that target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established.
ターゲットレルムのKDC証明書としてCAが認証した証明書を信頼するには（たとえば、セクション3.2.4で説明するように、KerberosレルムのTGS名をid-pkinit-san SANとして示す、またはid-pkinit-KPKdc EKUを使って証明書の用途を制限する場合）、クライアントは、そのKDC証明書の発行CAが当該レルムのKDC証明書を発行する権限を持つことを検証しなければなりません (MUST)。検証できなければ、KDC証明書とターゲットレルムのKDCとの対応付けは確立されません。
How to validate this authorization is a matter of local policy. A way to achieve this is the configuration of specific sets of intermediary CAs and trust anchors, one of which must be on the KDC certificate's certification path [RFC3280], and, for each CA or trust anchor, the realms for which it is allowed to issue certificates.
この権限を検証する方法はローカルポリシーで決めます。方法の1つは、中間CAとトラストアンカーの集合を指定し、そのうち少なくとも1つをKDC証明書の認証パスに含めることです [RFC3280]。また、各CAまたはトラストアンカーについて、証明書の発行を許可するレルムを指定します。
In addition, if any CA that is trusted to issue KDC certificates can also issue other kinds of certificates, then local policy must be able to distinguish between them; for example, it could require that KDC certificates contain the id-pkinit-KPKdc EKU or that the realm be specified with the id-pkinit-san SAN.
KDC証明書の発行を信頼されたCAが他の種類の証明書も発行できる場合、ローカルポリシーでそれらを区別できる必要があります。たとえば、KDC証明書にid-pkinit-KPKdc EKUを含めることや、id-pkinit-san SANでレルムを指定することを求められます。
It is the responsibility of the PKI administrators for an organization to ensure that KDC certificates are only issued to KDCs, and that clients can ascertain this using their local policy.
KDC証明書をKDCだけに発行し、クライアントがローカルポリシーを使ってそれを確認できるようにすることは、組織のPKI管理者の責任です。
Standard Kerberos allows the possibility of interactions between cryptosystems of varying strengths; this document adds interactions with public-key cryptosystems to Kerberos. Some administrative policies may allow the use of relatively weak public keys. When using such weak asymmetric keys to protect/exchange stronger symmetric Keys, the attack resistant strength of the overall system is no better than that of these weak keys [RFC3766].
Kerberos標準仕様では、強度の異なる暗号システム間の相互作用が想定されています。この文書は公開鍵暗号システムとの相互作用をKerberosに追加します。一部の管理ポリシーでは、比較的弱い公開鍵の使用が許可される場合があります。そのような弱い非対称鍵で、より強い対称鍵を保護または交換する場合、システム全体の攻撃耐性は弱い鍵の強度を超えません [RFC3766]。
PKINIT requires that keys for symmetric cryptosystems be generated. Some such systems contain "weak" keys. For recommendations regarding these weak keys, see [RFC4120].
PKINITでは、対称暗号システム用の鍵を生成する必要があります。そのようなシステムの中には「弱い」鍵が存在するものがあります。これらの弱い鍵に関する推奨事項は[RFC4120]を参照してください。
PKINIT allows the use of the same RSA key pair for encryption and signing when doing RSA encryption-based key delivery. This is not recommended usage of RSA keys [RFC3447]; by using DH-based key delivery, this is avoided.
PKINITでは、RSA暗号方式による鍵配送で、同じRSA鍵ペアを暗号化と署名に使用できます。これはRSA鍵の推奨されない使い方です [RFC3447]。DH鍵配送を使えば、この使い方を避けられます。
Care should be taken in how certificates are chosen for the purposes of authentication using PKINIT. Some local policies may require that key escrow be used for certain certificate types. Deployers of PKINIT should be aware of the implications of using certificates that have escrowed keys for the purposes of authentication. Because signing-only certificates are normally not escrowed, by using DH-based key delivery this is avoided.
PKINIT認証に使う証明書は、選択方法に注意が必要です。ローカルポリシーによっては、特定の種類の証明書に鍵エスクローを求める場合があります。PKINITの導入者は、エスクローされた鍵を持つ証明書を認証に使うことの影響を理解しておく必要があります。署名専用証明書は通常エスクローされないため、DH鍵配送を使えばこの問題を避けられます。
PKINIT does not provide for a "return routability" test to prevent attackers from mounting a denial-of-service attack on the KDC by causing it to perform unnecessary and expensive public-key operations. Strictly speaking, this is also true of standard Kerberos, although the potential cost is not as great, because standard Kerberos does not make use of public-key cryptography. By using DH-based key delivery and reusing DH keys, the necessary crypto processing cost per request can be minimized.
PKINITには、攻撃者が不要で高コストな公開鍵演算をKDCに実行させ、サービス拒否攻撃を仕掛けることを防ぐ「応答経路確認」テストがありません。厳密には標準Kerberosにも同じことが言えますが、標準Kerberosは公開鍵暗号を使わないため、攻撃に伴うコストはそれほど大きくありません。DH鍵配送とDH鍵の再利用により、要求ごとに必要な暗号処理のコストを最小限にできます。
When the Diffie-Hellman key exchange method is used, additional pre-authentication data [RFC4120] (in addition to the PA_PK_AS_REQ, as defined in this specification) is not bound to the AS_REQ by the mechanisms discussed in this specification (meaning it may be dropped or added by attackers without being detected by either the client or the KDC). Designers of additional pre-authentication data should take that into consideration if such additional pre-authentication data can be used in conjunction with the PA_PK_AS_REQ. The future work of the Kerberos working group is expected to update the hash algorithms specified in this document and provide a generic mechanism to bind additional pre-authentication data with the accompanying AS_REQ.
Diffie-Hellman鍵交換方式を使用する場合、この仕様で定義するPA_PK_AS_REQ以外の認証前データ [RFC4120] は、この仕様で説明する仕組みではAS_REQに結び付けられません。つまり、攻撃者が認証前データを削除または追加しても、クライアントにもKDCにも検出されない可能性があります。追加の認証前データをPA_PK_AS_REQと併用できる場合、その設計者はこの点を考慮する必要があります。Kerberosワーキンググループでは、今後この文書で指定したハッシュアルゴリズムを更新し、追加の認証前データを対応するAS_REQに結び付ける汎用的な仕組みを提供する作業が見込まれています。
The key usage number 6 used by the asChecksum field is also used for the authenticator checksum (cksum field of AP-REQ) contained in the PA-TGS-REQ preauthentication data contained in a TGS-REQ [RFC4120]. This conflict is present for historical reasons; the reuse of key usage numbers is strongly discouraged.
asChecksumフィールドで使う鍵使用番号6は、TGS-REQに含まれるPA-TGS-REQ認証前データ内のAuthenticatorチェックサム（AP-REQのcksumフィールド）にも使われます [RFC4120]。この重複は歴史的な経緯によるものです。鍵使用番号の再利用は強く推奨されません。
The following people have made significant contributions to this document: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M Grundman, and Jeffrey Altman.
この文書には、次の方々から重要な貢献をいただきました：Paul Leach、Stefan Santesson、Sam Hartman、Love Hornquist Astrand、Ken Raeburn、Nicolas Williams、John Wray、Tom Yu、Jeffrey Hutzelman、David Cross、Dan Simon、Karthik Jaganathan、Chaskiel M Grundman、Jeffrey Altman。
Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay, and Chris Walstad discovered a binding issue between the AS-REQ and AS-REP in draft -26; the asChecksum field was added as the result.
Andre Scedrov、Aaron D. Jaggard、Iliano Cervesato、Joe-Kai Tsay、Chris Walstadは、draft -26でAS-REQとAS-REPの対応付けの問題を発見しました。その結果、asChecksumフィールドが追加されました。
Special thanks to Clifford Neuman, Matthew Hur, Ari Medvinsky, Sasha Medvinsky, and Jonathan Trostle who wrote earlier versions of this document.
この文書の初期版を執筆したClifford Neuman、Matthew Hur、Ari Medvinsky、Sasha Medvinsky、Jonathan Trostleに特に感謝します。
The authors are indebted to the Kerberos working group chair, Jeffrey Hutzelman, who kept track of various issues and was enormously helpful during the creation of this document.
著者は、さまざまな課題を追跡し、この文書の作成に大きく貢献したKerberosワーキンググループ議長のJeffrey Hutzelmanに感謝します。
Some of the ideas on which this document is based arose during discussions over several years between members of the SAAG, the IETF CAT working group, and the PSRG, regarding integration of Kerberos and SPX. Some ideas have also been drawn from the DASS system. These changes are by no means endorsed by these groups. This is an attempt to revive some of the goals of those groups, and this document approaches those goals primarily from the Kerberos perspective.
この文書の基になったアイデアの一部は、KerberosとSPXの統合について、SAAG、IETF CATワーキンググループ、PSRGのメンバーが数年にわたって議論する中で生まれました。DASSシステムから取り入れたアイデアもあります。これらの変更が各グループの承認を得たわけではありません。この文書は各グループの目標の一部を再び取り上げる試みであり、主にKerberosの観点からその目標に取り組みます。
Lastly, comments from groups working on similar ideas in DCE have been invaluable.
最後に、DCEで類似のアイデアに取り組んでいるグループから寄せられたコメントも非常に貴重でした。
[IEEE1363] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000.
[IEEE1363] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[ODL99] Odlyzko, A., "Discrete logarithms: The past and the future, Designs, Codes, and Cryptography (1999)". April 1999.
[ODL99] Odlyzko, A., "Discrete logarithms: The past and the future, Designs, Codes, and Cryptography (1999)". April 1999.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005.
KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
SubjectPublicKeyInfo, AlgorithmIdentifier 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 3280.
KerberosTime, PrincipalName, 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.
id-pkinit OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit (3) }
id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
pa-pk-as-req INTEGER ::= 16
pa-pk-as-rep INTEGER ::= 17
ad-initial-verified-cas INTEGER ::= 9
td-trusted-certifiers INTEGER ::= 104
td-invalid-certificates INTEGER ::= 105
td-dh-parameters INTEGER ::= 109
PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo
-- is id-signedData (1.2.840.113549.1.7.2),
-- and the content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-- eContent field contains the DER encoding of the
-- type AuthPack.
-- AuthPack is defined below.
trustedCertifiers [1] SEQUENCE OF
ExternalPrincipalIdentifier OPTIONAL,
-- Contains a list of CAs, trusted by the client,
-- that can be used to certify the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
-- The information contained in the
-- trustedCertifiers SHOULD be used by the KDC as
-- hints to guide its selection of an appropriate
-- certificate chain to return to the client.
kdcPkId [2] IMPLICIT OCTET STRING
OPTIONAL,
-- Contains a CMS type SignerIdentifier encoded
-- according to [RFC3852].
-- Identifies, if present, a particular KDC
-- public key that the client already has.
...
}
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a PKIX type Name encoded according to
-- [RFC3280].
-- Identifies the certificate subject by the
-- distinguished subject name.
-- REQUIRED when there is a distinguished subject
-- name present in the certificate.
issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
-- Contains a CMS type IssuerAndSerialNumber encoded
-- according to [RFC3852].
-- Identifies a certificate of the subject.
-- REQUIRED for TD-INVALID-CERTIFICATES and
-- TD-TRUSTED-CERTIFIERS.
subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
-- Identifies the subject's public key by a key
-- identifier. When an X.509 certificate is
-- referenced, this key identifier matches the X.509
-- subjectKeyIdentifier extension value. When other
-- certificate formats are referenced, the documents
-- that specify the certificate format and their use
-- with the CMS must include details on matching the
-- key identifier to the appropriate certificate
-- field.
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in
-- [RFC3280].
-- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363].
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
-- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- Type AlgorithmIdentifier is defined in
-- [RFC3280].
-- List of CMS algorithm [RFC3370] identifiers
-- that identify key transport algorithms, or
-- content encryption algorithms, or signature
-- algorithms supported by the client in order of
-- (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it
-- wishes to reuse DH keys or to allow the KDC to
-- do so.
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for
-- replay prevention.
nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present.
-- Contains the SHA1 checksum, performed over
-- KDC-REQ-BODY. ... }
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid
-- signature.
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies the certification path based on which
-- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
PA-PK-AS-REP ::= CHOICE {
dhInfo [0] DHRepInfo,
-- Selected when Diffie-Hellman key exchange is
-- used.
encKeyPack [1] IMPLICIT OCTET STRING,
-- Selected when public key encryption is used.
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-envelopedData (1.2.840.113549.1.7.3).
-- The content field is an EnvelopedData.
-- The contentType field for the type EnvelopedData
-- is id-signedData (1.2.840.113549.1.7.2).
-- The eContentType field for the inner type
-- SignedData (when unencrypted) is
-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-- eContent field contains the DER encoding of the
-- type ReplyKeyPack.
-- ReplyKeyPack is defined below.
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded according
-- to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL,
-- Present if and only if dhKeyExpiration is
-- present.
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- The KDC's DH public key.
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the pkAuthenticator field
-- in the request if the DH keys are NOT reused,
-- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair,
-- present if and only if the DH keys are reused.
-- If present, the KDC's DH public key MUST not be
-- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
-- field MUST also be omitted.
...
}
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP, i.e., the
-- AS reply key.
asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ.
-- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6.
-- If the replyKey's enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt
-- of the AS-REP.
...
}
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order.
END
Function octetstring2key() is defined in Section 3.2.3.1. This section describes a few sets of test vectors that would be useful for implementers of octetstring2key().
octetstring2key()はセクション3.2.3.1で定義されています。このセクションでは、octetstring2key()の実装者に役立ついくつかのテストベクトルを示します。
Set 1:
=====
Input octet string x is:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Output of K-truncate() when the key size is 32 octets:
鍵長が32オクテットの場合のK-truncate()の出力：
5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
Set 2:
=====
Input octet string x is:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Output of K-truncate() when the key size is 32 octets:
鍵長が32オクテットの場合のK-truncate()の出力：
ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
Set 3:
======
Input octet string x is:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
Output of K-truncate() when the key size is 32 octets:
鍵長が32オクテットの場合のK-truncate()の出力：
c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
Set 4:
=====
Input octet string x is:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
Output of K-truncate() when the key size is 32 octets:
鍵長が32オクテットの場合のK-truncate()の出力：
00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
Earlier revisions of the PKINIT I-D were implemented in various releases of Microsoft Windows and deployed in fairly large numbers. To enable the community to interoperate better with systems running those releases, the following information may be useful.
PKINIT Internet-Draftの以前の版は、Microsoft Windowsの複数のリリースに実装され、広く展開されました。これらのリリースを実行するシステムとの相互運用性を高めるため、次の情報が役立ちます。
KDC certificates issued by Windows 2000 Enterprise CAs contain a dNSName SAN with the DNS name of the host running the KDC, and the id-kp-serverAuth EKU [RFC3280].
Windows 2000 Enterprise CAが発行するKDC証明書には、KDCを実行するホストのDNS名を格納したdNSName SANと、id-kp-serverAuth EKUが含まれます [RFC3280]。
KDC certificates issued by Windows 2003 Enterprise CAs contain a dNSName SAN with the DNS name of the host running the KDC, the id-kp-serverAuth EKU, and the id-ms-kp-sc-logon EKU.
Windows 2003 Enterprise CAが発行するKDC証明書には、KDCを実行するホストのDNS名を格納したdNSName SAN、id-kp-serverAuth EKU、およびid-ms-kp-sc-logon EKUが含まれます。
It is anticipated that the next release of Windows is already too far along to allow it to support the issuing KDC certificates with id-pkinit-san SAN as specified in this RFC. Instead, they will have a dNSName SAN containing the domain name of the KDC, and the intended purpose of these KDC certificates will be restricted by the presence of the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
このRFCで規定するid-pkinit-san SANを持つKDC証明書の発行を次期Windowsリリースでサポートするには、開発がすでに進みすぎていると予想されます。その代わりに、KDCのドメイン名を格納したdNSName SANが使用され、id-pkinit-KPKdc EKUとid-kp-serverAuth EKUによって、これらのKDC証明書の用途が制限されます。
In addition to checking that the above are present in a KDC certificate, Windows clients verify that the issuer of the KDC certificate is one of a set of allowed issuers of such certificates, so those wishing to issue KDC certificates need to configure their Windows clients appropriately.
KDC証明書に上記の項目が含まれることを確認するだけでなく、Windowsクライアントは、その証明書の発行者がKDC証明書の発行を許可された発行者の集合に含まれることも確認します。そのため、KDC証明書を発行する場合は、Windowsクライアントを適切に設定する必要があります。
Client certificates accepted by Windows 2000 and Windows 2003 Server KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN contains a UTF8-encoded string whose value is that of the Directory Service attribute UserPrincipalName of the client account object, and the purpose of including the id-ms-san-sc-logon-upn SAN in the client certificate is to validate the client mapping (in other words, the client's public key is bound to the account that has this UserPrincipalName value).
Windows 2000およびWindows 2003 ServerのKDCが受け入れるクライアント証明書には、id-ms-san-sc-logon-upn（1.3.6.1.4.1.311.20.2.3）SANとid-ms-kp-sc-logon EKUが含まれている必要があります。id-ms-san-sc-logon-upn SANには、クライアントアカウントオブジェクトのDirectory Service属性UserPrincipalNameの値をUTF8でエンコードした文字列が格納されます。このSANをクライアント証明書に含める目的は、クライアントとの対応付けを検証することです。つまり、クライアントの公開鍵が、そのUserPrincipalName値を持つアカウントに結び付けられていることを確認します。
It should be noted that all Microsoft Kerberos realm names are domain-style realm names and strictly in uppercase. In addition, the UserPrincipalName attribute is globally unique in Windows 2000 and Windows 2003.
すべてのMicrosoft Kerberos Realmの名前はドメインスタイルのレルム名であり、厳密には大文字であることに注意する必要があります。さらに、UserPrincipalName属性は、Windows 2000およびWindows 2003でグローバルにユニークです。
Authors' Addresses
著者のアドレス
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu Microsoft Corporation One Microsoft Way Redmond、WA 98052 US
EMail: lzhu@microsoft.com
Brian Tung Aerospace Corporation 2350 E. El Segundo Blvd. El Segundo, CA 90245 US
Brian Tung Aerospace Corporation 2350 E. El Segundo Blvd.El Segundo、CA 90245 US
EMail: brian@aero.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、この文書に記載された技術の実装または使用に関係すると主張される知的財産権その他の権利の有効性や範囲、またはそれらの権利に基づくライセンスが利用可能かどうかについて、いかなる見解も示しません。また、そのような権利を独自に特定するための調査を行ったとも表明しません。RFC文書に関する権利手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に提出されたIPR開示の写し、ライセンスを利用可能にする旨の保証、および本仕様の実装者や利用者が該当する権利の一般ライセンスまたは利用許可を得ようとした結果は、IETFのオンラインIPRリポジトリ http://www.ietf.org/ipr から入手できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある方に、この標準の実装に必要となる可能性がある技術を対象とする著作権、特許、特許出願、その他の所有権について、IETFに知らせるよう求めています。情報はietf-ipr@ietf.org宛てにお送りください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能の資金は、IETF Administrative Support Activity（IASA）が提供しています。