[要約] RFC 6717は、2012年に使用されていたkx509 Kerberized Certificate Issuance Protocolに関する要約です。このプロトコルの目的は、Kerberos認証を使用して証明書の発行を行うことです。
Independent Submission H. Hotz
Request for Comments: 6717 Jet Propulsion Lab, Caltech
Category: Informational R. Allbery
ISSN: 2070-1721 Stanford University
August 2012
kx509 Kerberized Certificate Issuance Protocol in Use in 2012
2012年に使用されたkx509 Kerberos証明書発行プロトコル
Abstract
概要
This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.
このドキュメントでは、Kerberosチケットを使用してX.509証明書を取得するためのkx509と呼ばれるプロトコルについて説明します。これらの証明書は、他の方法で取得したX.509証明書と同じ目的の多くに使用できますが、Kerberosインフラストラクチャがすでに存在する場合、kx509を使用するオーバーヘッドははるかに少なくなる可能性があります。
While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation.
標準化されていませんが、このプロトコルはすでにいくつかの大規模な組織で使用されており、このプロトコルで発行された証明書は国際グリッド信頼連合によって認識されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6717.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6717で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Protocol Data ...................................................3
2.1. Request Packet .............................................3
2.2. Reply Packet ...............................................4
3. Protocol Operation ..............................................7
4. Acknowledgements ................................................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Appendix A. Certificate Caching and Deployment Considerations ....12
Appendix B. Historic Extensions ..................................12
Appendix C. Example Exchange .....................................12
The two primary ways of providing cryptographically secure identification on the Internet are Kerberos tickets [RFC4120] and X.509 [RFC5280] [X.509] certificates.
インターネット上で暗号化された安全な識別を提供する2つの主要な方法は、Kerberosチケット[RFC4120]とX.509 [RFC5280] [X.509]証明書です。
In practical IT infrastructure where both are in use, it's highly desirable to deploy their support in a way that guarantees they both authoritatively refer to the same entities. There is already a widely adopted standard for using X.509 certificates to acquire corresponding Kerberos tickets called Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC4556]. This document describes the kx509 protocol for supporting the symmetric operation of acquiring X.509 certificates using Kerberos tickets.
両方が使用されている実際のITインフラストラクチャでは、両者が同じエンティティを正式に参照していることを保証する方法でサポートを展開することが非常に望ましいです。 X.509証明書を使用して対応するKerberosチケットを取得するための広く採用されている標準は、Kerberosの初期認証の公開鍵暗号化（PKINIT）[RFC4556]と呼ばれています。このドキュメントでは、Kerberosチケットを使用してX.509証明書を取得する対称操作をサポートするためのkx509プロトコルについて説明します。
Preparing and reviewing this document exposed a number of issues that are discussed in the security considerations. Unfortunately, some of them can only be addressed with an incompatible upgrade to this protocol. The IETF's Kerberos working group has an expected work item to address these issues.
このドキュメントを準備して確認すると、セキュリティに関する考慮事項で説明されている多くの問題が明らかになりました。残念ながら、それらのいくつかは、このプロトコルへの互換性のないアップグレードでのみ対処できます。 IETFのKerberosワーキンググループには、これらの問題に対処するための作業項目があります。
The International Grid Trust Federation [IGTF] supports the use of Short Lived Credential Services [SLCS] as a means to authenticate for resource usage based on other, native identity stores that an organization maintains. X.509 certificates issued using the kx509 protocol based on a Kerberos identity is one of the recognized credential services. The certificate profile for that use is outside the scope of this RFC but is described in [GRID-prof].
International Grid Trust Federation [IGTF]は、組織が維持する他のネイティブIDストアに基づいてリソースの使用を認証する手段として、Short Lived Credential Services [SLCS]の使用をサポートしています。 Kerberos IDに基づいてkx509プロトコルを使用して発行されたX.509証明書は、認識されている資格情報サービスの1つです。その使用のための証明書プロファイルはこのRFCの範囲外ですが、[GRID-prof]で説明されています。
In normal operation, kx509 can be used after a Kerberos ticket-granting-ticket (TGT) is acquired, which is most likely during user login. First, the client generates an RSA public/private key pair. Next, using the Kerberos ticket-granting-ticket, it acquires a Kerberos service ticket for the KCA (Kerberized Certificate Authority) and uses this to send the public half of its key pair. The KCA will decrypt the service ticket, verify the integrity of the incoming packet, determine the identity of the user, and use the session key to send back a corresponding X.509 certificate.
通常の操作では、Kerberosチケット認可チケット（TGT）を取得した後でkx509を使用できます。最初に、クライアントはRSA公開/秘密鍵ペアを生成します。次に、Kerberos ticket-granting-ticketを使用して、KCA（Kerberos認証局）のKerberosサービスチケットを取得し、これを使用して鍵ペアの公開半分を送信します。 KCAはサービスチケットを復号化し、着信パケットの整合性を検証し、ユーザーのIDを決定し、セッションキーを使用して対応するX.509証明書を送り返します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The protocol consists of a single request/reply exchange using UDP.
プロトコルは、UDPを使用した単一の要求/応答交換で構成されています。
Both the request and the reply packet begin with four bytes of version ID information, followed by a DER-encoded ASN.1 message. The first two bytes of the version ID are reserved. They MUST be set to zero when sent and SHOULD be ignored when received. The third and fourth bytes are the major and minor version numbers, respectively. The version of the protocol described in this document is designated 2.0, so the first four bytes of the packet are 0, 0, 2, and 0.
要求パケットと応答パケットはどちらも4バイトのバージョンID情報で始まり、その後にDERエンコードされたASN.1メッセージが続きます。バージョンIDの最初の2バイトは予約されています。それらは送信時にゼロに設定されなければならず、受信時に無視されるべきです（SHOULD）。 3番目と4番目のバイトは、それぞれメジャーバージョン番号とマイナーバージョン番号です。このドキュメントで説明されているプロトコルのバージョンは2.0と指定されているため、パケットの最初の4バイトは0、0、2、0です。
Incompatible variations of this protocol MUST use a different major version number.
このプロトコルの互換性のないバリエーションでは、異なるメジャーバージョン番号を使用する必要があります。
The request consists of a version ID, followed by a DER-encoded ASN.1 message containing a Kerberos AP-REQ, integrity check data on the request, and public key generated by the client. The ASN.1 encoding is:
リクエストは、バージョンIDと、それに続くKerberos AP-REQ、リクエストの整合性チェックデータ、およびクライアントによって生成された公開鍵を含むDERエンコードされたASN.1メッセージで構成されます。 ASN.1エンコーディングは次のとおりです。
KX509Request ::= SEQUENCE {
AP-REQ OCTET STRING,
pk-hash OCTET STRING,
pk-key OCTET STRING
}
The AP-REQ is as described in [RFC4120], Section 5.5.1.
AP-REQは[RFC4120]、セクション5.5.1で説明されています。
The pk-hash is Hashed Message Authentication Code (HMAC) using SHA-1 as the underlying hash. All 160 bits are sent. The key used is the Kerberos session key. The data to be hashed is the concatenation of the following:
pk-hashは、基盤となるハッシュとしてSHA-1を使用するハッシュメッセージ認証コード（HMAC）です。 160ビットすべてが送信されます。使用されるキーは、Kerberosセッションキーです。ハッシュされるデータは、次の連結です。
o 4-byte version ID at the beginning of the packet.
o パケットの先頭にある4バイトのバージョンID。
o OCTET STRING of the AP-REQ.
o AP-REQのオクテット文字列。
o OCTET STRING of the pk-key.
o pk-keyのオクテット文字列。
The pk-key contains a public key. This key and its corresponding private key are generated by the client before contacting the server. Implementations of this protocol MUST support RSA keys, in which case the key is a DER-encoded RSAPublicKey as defined in [RFC3447], Section A.1.1, and then it is stored in this octet string in the request. Its encoding as an OCTET STRING starts with the 0x30 byte sequence at the beginning of a DER-encoded RSAPublicKey. Use of other public-key types is not defined.
pk-keyには公開鍵が含まれています。このキーとそれに対応する秘密キーは、サーバーに接続する前にクライアントによって生成されます。このプロトコルの実装はRSAキーをサポートする必要があります。その場合、キーは[RFC3447]、セクションA.1.1で定義されているDERエンコードのRSAPublicKeyであり、リクエストのこのオクテット文字列に格納されます。 OCTET STRINGとしてのエンコードは、DERエンコードされたRSAPublicKeyの先頭にある0x30バイトシーケンスで始まります。他の公開鍵タイプの使用は定義されていません。
Appendix C shows an example request packet.
付録Cは、要求パケットの例を示しています。
The reply consists of a version ID, followed by a DER-encoded ASN.1 message containing an error code, an optional authentication hash, optional certificate, and optional error text. The service SHOULD return replies of the same version as the request where possible.
応答は、バージョンIDの後に、エラーコード、オプションの認証ハッシュ、オプションの証明書、オプションのエラーテキストを含むDERエンコードされたASN.1メッセージが続きます。サービスは、可能であればリクエストと同じバージョンの応答を返す必要があります（SHOULD）。
KX509Response ::= SEQUENCE {
error-code[0] INTEGER DEFAULT 0,
hash[1] OCTET STRING OPTIONAL,
certificate[2] OCTET STRING OPTIONAL,
e-text[3] VisibleString OPTIONAL
}
Although the format of the reply contains independently optional objects, the server MUST only generate replies with one of the following allowed combinations.
応答のフォーマットには独立してオプションのオブジェクトが含まれていますが、サーバーは以下の許可された組み合わせのいずれかでのみ応答を生成する必要があります。
+------------+------+-------------+--------+
| | hash | certificate | |
| error-code | hash | | e-text |
| error-code | | | e-text |
+------------+------+-------------+--------+
The first case is returned when the server successfully generates a certificate for the user. The certificate is a DER-encoded certificate as defined in [RFC5280], Appendix A, page 116. Its encoding as an OCTET STRING starts with the 0x30 byte sequence that is at the beginning of a DER-encoded certificate.
最初のケースは、サーバーがユーザーの証明書を正常に生成したときに返されます。証明書は、[RFC5280]、付録A、116ページで定義されているDERエンコードされた証明書です。OCTETSTRINGとしてのエンコードは、DERエンコードされた証明書の先頭にある0x30バイトシーケンスで始まります。
The second case is returned when the server successfully authenticates the user and their key, but is unable for some other reason to generate a certificate.
2番目のケースは、サーバーがユーザーとそのキーを正常に認証したが、何らかの理由で証明書を生成できない場合に返されます。
The third case MAY be returned if the server is unable to successfully authenticate the user and intends to return some unauthenticated information to the client.
3番目のケースは、サーバーがユーザーを正常に認証できず、認証されていない情報をクライアントに返す場合に返される可能性があります。
The hash on a response is computed using SHA-1 HMAC as for the request.
応答のハッシュは、要求と同様にSHA-1 HMACを使用して計算されます。
The data that is hashed is the concatenation of the following things:
ハッシュされるデータは、次のものを連結したものです。
o 4-byte version ID at the beginning of the packet.
o パケットの先頭にある4バイトのバージョンID。
o DER representation of the error-code exclusive of the tag and length, if it is present.
o 存在する場合、タグと長さを除いたエラーコードのDER表現。
o OCTET STRING of the certificate, if it is present.
o 証明書のOCTET STRING（存在する場合）。
o VisibleString representation of the e-text exclusive of the tag and length, if it is present.
o タグと長さが存在する場合は、それを除いた電子テキストのVisibleString表現。
In other words, the hash is computed on the data in the fields that are present, exclusive of the overall ASN.1 wrapping.
つまり、ハッシュは、ASN.1ラッピング全体を除いて、存在するフィールドのデータに対して計算されます。
The e-text MAY be translated into other character sets for display purposes, but the hash is computed on the e-text in its VisibleString representation. If the e-text contains NUL characters, the client MAY ignore any part of the error message after the first NUL character for display purposes.
e-textは表示目的で他の文字セットに変換される場合がありますが、ハッシュはVisibleString表現でe-textに対して計算されます。 e-textにNUL文字が含まれている場合、クライアントは、表示のために最初のNUL文字の後のエラーメッセージの部分を無視してもよい（MAY）。
As implied by the above table, if the reply does not contain a certificate, it MUST contain an error message and a non-zero error code. Conversely, if a certificate is returned, then the error-code MUST be zero. The server SHOULD use the DEFAULT encoding for a zero error-code value by omitting any explicit error-code from the reply.
上記の表に示されているように、応答に証明書が含まれていない場合は、エラーメッセージとゼロ以外のエラーコードが含まれている必要があります。逆に、証明書が返された場合、エラーコードはゼロでなければなりません。サーバーは、返信から明示的なエラーコードを省略して、エラーコード値がゼロの場合にDEFAULTエンコーディングを使用する必要があります（SHOULD）。
The defined values for error-code are as follows:
エラーコードの定義値は次のとおりです。
+------------+-----------------------------+------------------------+
| error-code | Condition | Example |
+------------+-----------------------------+------------------------+
| 1 | Permanent problem with | Incompatible version |
| | client request | |
| 2 | Solvable problem with | Expired Kerberos |
| | client request | credentials |
| 3 | Temporary problem with | Packet loss |
| | client request | |
| 4 | Permanent problem with the | Internal |
| | server | misconfiguration |
| 5 | Temporary problem with the | Server overloaded |
| | server | |
+------------+-----------------------------+------------------------+
If a client error is returned, the client SHOULD NOT retry the request unless some remedial action is first taken, although if error-code 3 is returned, the client MAY retry with other servers before giving up.
クライアントエラーが返された場合、クライアントは何らかの修正アクションが最初に実行されない限り、要求を再試行してはなりません（SHOULD NOT）。
If a server error is returned, it is RECOMMENDED that the client retry the request with a different server if one is known.
サーバーエラーが返された場合、クライアントがわかっている場合は、クライアントが別のサーバーで要求を再試行することをお勧めします。
Since all KCAs serving a Kerberos realm are intended to be equivalent, in accordance with Section 4.1.2.2 of [RFC5280], the certificates returned from different KCAs serving the same Kerberos realm MUST NOT contain duplicate serial numbers.
[RFC5280]のセクション4.1.2.2に従って、Kerberosレルムを提供するすべてのKCAは同等であることが意図されているため、同じKerberosレルムを提供する異なるKCAから返される証明書には、重複したシリアル番号を含めてはなりません。
This protocol and document do not address certificate verification or path construction. There are no provisions for returning any additional certificates that might be needed. Any application using a returned certificate must be configured independently to address these issues. An incompatible upgrade to this protocol will provide options to address this issue.
このプロトコルとドキュメントは、証明書の検証やパスの構築については触れていません。必要になる可能性のある追加の証明書を返すための規定はありません。返された証明書を使用するアプリケーションは、これらの問題に対処するために個別に構成する必要があります。このプロトコルへの互換性のないアップグレードは、この問題に対処するオプションを提供します。
The returned certificate MUST identify the Kerberos client principal from the AP-REQ in the original KX509Request in the subject of the certificate or in a subjectAltName extension. The identification MUST be unique within the organization's deployed infrastructure. It is RECOMMENDED that a subjectAltName extension be included of type id-pkinit-san as described in [RFC4556], Section 3.2.2. Note that the id-pkinit-san is simply a standard representation of a Kerberos principal and has no other implications with respect to PKINIT.
返された証明書は、証明書の件名またはsubjectAltName拡張の元のKX509RequestのAP-REQからのKerberosクライアントプリンシパルを識別しなければなりません（MUST）。識別は、組織の展開されたインフラストラクチャ内で一意である必要があります。 [RFC4556]のセクション3.2.2で説明されているように、subjectAltName拡張をタイプid-pkinit-sanに含めることをお勧めします。 id-pkinit-sanはKerberosプリンシパルの単なる標準表現であり、PKINITに関して他の影響はないことに注意してください。
Other extensions MAY be added according to local policy.
その他の拡張機能は、ローカルポリシーに従って追加される場合があります。
Appendix C shows an example reply packet.
付録Cに、応答パケットの例を示します。
Absent errors, the protocol consists of a single request, sent via UDP, and a single reply, also sent via UDP.
エラーがない場合、プロトコルは、UDPを介して送信される単一の要求と、同じくUDPを介して送信される単一の応答で構成されます。
There is no special provision for requests or replies that exceed the allowable size of a UDP packet. Also, some implementations have imposed hard size limits that are smaller than a typical UDP MTU and will limit the use of extensions and the supportable key size. Even without hard limits, if the request or reply exceeds the MTU size of a UDP packet for the infrastructure in use, then the reliability of the exchange will decrease significantly.
UDPパケットの許容サイズを超える要求または応答に対する特別な規定はありません。また、一部の実装では、一般的なUDP MTUよりも小さいハードサイズ制限が課されており、拡張機能の使用とサポート可能なキーサイズが制限されます。ハード制限がない場合でも、要求または応答が使用中のインフラストラクチャのUDPパケットのMTUサイズを超えると、交換の信頼性が大幅に低下します。
For "normal" Kerberos AP-REQ structures, and "normal" X.509 certificates, this is unlikely unless the Kerberos service ticket contains large amounts of authorization data. For this reason, it is RECOMMENDED that service tickets for the KCA be issued without authorization data. If the KCA performs authorization, it should do so by other means.
「通常の」Kerberos AP-REQ構造と「通常の」X.509証明書の場合、Kerberosサービスチケットに大量の承認データが含まれていない限り、これはほとんどありません。このため、認証データなしでKCAのサービスチケットを発行することをお勧めします。 KCAが許可を実行する場合は、他の方法で行う必要があります。
Before constructing the request, the client must know the canonical name(s) and port(s) of the server(s) to contact. It MAY determine them by looking up the service's SRV record as described in [RFC2782]. The entry to be used is _kca._udp._realm_, where _realm_ is the Kerberos realm, used as part of the DNS name.
リクエストを作成する前に、クライアントは接続するサーバーの正規名とポートを知っている必要があります。 [RFC2782]で説明されているように、サービスのSRVレコードを検索することにより、それらを決定する場合があります。使用されるエントリは_kca._udp._realm_です。ここで、_realm_は、DNS名の一部として使用されるKerberosレルムです。
The client has to acquire a service ticket in order to construct the AP-REQ for the service. Conventionally, the Kerberos service principal name to use for this service has a first component of "kca_service". Absent local configuration or other external knowledge of the correct principal to use, the second and final component is conventionally the canonical name of the KCA server being contacted, and the realm of the principal is determined following normal Kerberos domain-to-realm mapping conventions, as discussed in [RFC4120], Section 1.3.
クライアントは、サービスのAP-REQを構築するためにサービスチケットを取得する必要があります。従来、このサービスに使用するKerberosサービスプリンシパル名には、「kca_service」の最初のコンポーネントがあります。使用する正しいプリンシパルのローカル構成またはその他の外部知識がない場合、2番目および最後のコンポーネントは通常、接続されるKCAサーバーの正規名であり、プリンシパルのレルムは、通常のKerberosドメインからレルムへのマッピング規則に従って決定されます。 [RFC4120]、セクション1.3で説明されているとおり。
When the server receives a request, it MUST verify the following properties of the request before issuing a certificate:
サーバーがリクエストを受信すると、証明書を発行する前に、リクエストの次のプロパティを確認する必要があります。
o The AP-REQ can be decoded and is not expired.
o AP-REQはデコードでき、期限切れにはなりません。
o If the request uses cross-realm authentication, then it satisfies the requirements of local policy and [RFC4120], Sections 1.2 and 2.7.
o リクエストがクロスレルム認証を使用する場合、ローカルポリシーと[RFC4120]、セクション1.2および2.7の要件を満たします。
o The request's hash is valid.
o リクエストのハッシュは有効です。
The server SHOULD make other sanity checks, such as a minimum public key length, to the extent feasible.
サーバーは、可能な限り、公開鍵の最小長などの他の健全性チェックを行う必要があります（SHOULD）。
The server MAY decline to respond to an erroneous request. If it does not receive a response, a client MAY retry its request, but the client SHOULD wait at least one second before doing so.
サーバーは、誤った要求への応答を拒否してもよい（MAY）。それが応答を受け取らないならば、クライアントはその要求を再試行するかもしれませんが、クライアントはそうする前に少なくとも1秒待つべきです。
The client MUST verify any hash in the reply and MUST NOT use any certificate in a reply whose hash does not verify. The client MAY display the e-text if the hash is absent or does not verify but SHOULD indicate the message is not authenticated.
クライアントは応答内のハッシュを検証する必要があり、ハッシュが検証されていない応答内の証明書を使用してはなりません（MUST NOT）。ハッシュが存在しない場合、または検証されない場合、クライアントはe-textを表示できますが、メッセージが認証されていないことを示す必要があります（SHOULD）。
The original version of kx509 was implemented using Kerberos 4 at the University of Michigan and was nicely documented in [KX509]. Many thanks to them for their original work, as well as the subsequent updates.
kx509のオリジナルバージョンは、ミシガン大学でKerberos 4を使用して実装され、[KX509]で文書化されていました。元の作業とその後の更新について、彼らに感謝します。
While developing this document, important corrections and comments were provided by Jeffrey Altman and Love Hornquist Astrand. The following people also provided many helpful comments and corrections: Doug Engert, Jeffrey Hutzelman, Sam Hartman, Timothy J. Miller, Chaskiel Grundman, and Jim Schaad. Alan Sill provided the references to the International Grid Trust Federation and its acceptable credential services. Example network traffic was provided by Doug Engert, Marcus Watts, Matt Crawford, and Chaskiel Grundman from their deployments and was extremely useful for verifying the reality of this specification.
このドキュメントの作成中に、重要な修正とコメントがJeffrey AltmanとLove Hornquist Astrandから提供されました。次の人々も多くの役立つコメントと修正を提供しました：ダグエンガート、ジェフリーハッツェルマン、サムハートマン、ティモシーJ.ミラー、チャスキエルグルントマン、ジムシャード。 Alan Sillは、International Grid Trust Federationおよびその受け入れ可能な資格サービスへの参照を提供しました。ネットワークトラフィックの例は、Doug Engert、Marcus Watts、Matt Crawford、およびChaskiel Grundmanによって展開から提供されたものであり、この仕様の現実を検証するのに非常に役立ちました。
This service is conventionally run on UDP port 9878. IANA has registered that port in the Service Name and Transport Port Number Registry as follows:
このサービスは通常、UDPポート9878で実行されます。IANAは、次のようにそのポートをサービス名およびトランスポートポート番号レジストリに登録しました。
Service Name: kca-service Transport Protocol: UDP Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Description: The kx509 Kerberized Certificate Issuance Protocol in Use in 2012 Reference: RFC 6717 Port Number: 9878 Assignment Notes: Historically, this service has been referred to as "kca_service", but this service name does not meet the registry requirements.
サービス名：kca-serviceトランスポートプロトコル：UDP割り当て先：IESG <iesg@ietf.org>連絡先：IETF議長<chair@ietf.org>説明：2012年に使用されているkx509 Kerberized Certificate Issuance Protocol参照：RFC 6717ポート番号： 9878割り当てメモ：これまで、このサービスは「kca_service」と呼ばれていましたが、このサービス名はレジストリ要件を満たしていません。
The Generic Security Service Application Program Interface (GSS-API) / Kerberos / Simple Authentication and Security Layer (SASL) service name currently in use for this protocol is "kca_service". This does not meet the naming requirements for IANA's GSS-API/Kerberos/SASL service name registry, so no registration has been requested. The conflict between the conventional service name and the registry rules is expected to be addressed in a future version of this protocol. Appropriate registrations will be requested at that time.
Generic Security Service Application Program Interface（GSS-API）/ Kerberos / Simple Authentication and Security Layer（SASL）サービス名は、現在このプロトコルで使用されており、「kca_service」です。これは、IANAのGSS-API / Kerberos / SASLサービス名レジストリの命名要件を満たしていないため、登録は要求されていません。従来のサービス名とレジストリルールの競合は、このプロトコルの将来のバージョンで対処される予定です。その際、適切な登録をお願いします。
The only encrypted information in the protocol is that used by Kerberos itself. The considerations for any Kerberized service apply here.
プロトコル内の唯一の暗号化された情報は、Kerberos自体によって使用されるものです。 Kerberos対応サービスの考慮事項がここに適用されます。
The public key in the request is sent in the clear and without any guarantees that the requester actually possesses the corresponding private key. Therefore, the only appropriate uses of the returned certificate are those where the identity of the requester is unimportant or the subsequent use independently guarantees that the user possesses the private key. This issue is expected to be addressed in a future version of this protocol.
要求の公開鍵は平文で送信され、要求者が対応する秘密鍵を実際に所有しているという保証はありません。したがって、返された証明書の唯一の適切な使用は、要求者のIDが重要でない場合、またはその後の使用でユーザーが秘密鍵を所有していることを個別に保証する場合です。この問題は、このプロトコルの将来のバージョンで解決される予定です。
For example, if the kx509-issued certificate is used for a digital signature in a way that does not independently demonstrate proof-of-possession of the private key, then an eavesdropper could request their own valid certificate via kx509 and claim to have originated material signed by the legitimate, original requester. [RFC4211], Appendix C, contains a more detailed discussion of why proof-of-possession is important.
たとえば、kx509発行の証明書が秘密鍵の所持証明を個別に示さない方法でデジタル署名に使用されている場合、盗聴者はkx509を介して独自の有効な証明書を要求し、出所があったと主張することができます。正当な元の要求者によって署名されました。 [RFC4211]の付録Cには、所有証明が重要である理由の詳細な説明が含まれています。
An example that should be safe is initial client authentication with Transport Layer Security (TLS) [RFC5246] connections. If a client certificate is used, then a Certificate Verify message (Section 7.4.8 of [RFC5246]) is added to the handshake exchange. It includes a signature of the handshake messages to that point. Those messages depend on data known only to the client and server ends of the specific connection, so computing the signature proves possession of the private key. This application was the original intended use case for kx509.
安全なはずの例は、トランスポート層セキュリティ（TLS）[RFC5246]接続による初期クライアント認証です。クライアント証明書が使用されている場合は、証明書の確認メッセージ（[RFC5246]のセクション7.4.8）がハンドシェイク交換に追加されます。その時点までのハンドシェイクメッセージの署名が含まれています。これらのメッセージは、特定の接続のクライアント側とサーバー側だけが知っているデータに依存しているため、署名を計算すると、秘密鍵を所有していることが証明されます。このアプリケーションは、kx509の本来の使用目的でした。
Some information, such as the public key and certificate, is transmitted in the clear but (as the name implies) is generally intended to be publicly available. However, its visibility could still raise privacy concerns. The hash is used to protect the integrity of this information.
公開鍵や証明書などの一部の情報は平文で送信されますが、（名前が示すように）一般に公開されることを意図しています。ただし、その可視性はプライバシーの問題を引き起こす可能性があります。ハッシュは、この情報の整合性を保護するために使用されます。
The policies for issuing Kerberos tickets and X.509 certificates are usually expressed very differently. An implementation of this protocol should not provide a mechanism for bypassing ticket or certificate policies.
KerberosチケットとX.509証明書を発行するためのポリシーは、通常非常に異なって表現されます。このプロトコルの実装は、チケットまたは証明書ポリシーをバイパスするメカニズムを提供してはなりません。
In particular, if the issued certificate can be used with PKINIT, this authentication loop SHOULD NOT bypass policy limits for either X.509 certificates or Kerberos tickets.
特に、発行された証明書をPKINITで使用できる場合、この認証ループはX.509証明書またはKerberosチケットのいずれかのポリシー制限をバイパスしてはなりません（SHOULD NOT）。
X.509 certificates are usually issued with considerably longer validity times than Kerberos tickets. Care should be taken that the issued certificate is not valid for longer than the intended policy should allow. Note that Section 3.2.3 of [RFC4556] REQUIRES that the lifetime of an issued ticket not exceed the lifetime of the predecessor certificate. By analogy, it is RECOMMENDED that the lifetime of an issued certificate not exceed the lifetime of the predecessor Kerberos ticket unless the implications with respect to local policy and supporting infrastructure are clearly understood and allow it.
X.509証明書は通常、Kerberosチケットよりもかなり長い有効期間で発行されます。発行された証明書が、意図されたポリシーで許可されている期間よりも長く有効でないことに注意する必要があります。 [RFC4556]のセクション3.2.3は、発行されたチケットの有効期間が先行する証明書の有効期間を超えないことを要求することに注意してください。同様に、ローカルポリシーとサポートインフラストラクチャに関する影響が明確に理解されて許可されていない限り、発行された証明書の有効期間は、先行するKerberosチケットの有効期間を超えないことが推奨されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月。
[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。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[GRID-prof] "Grid Certificate Profile", March 2008, <http://www.ogf.org/documents/GFD.125.pdf>.
[GRID-prof]「グリッド証明書プロファイル」、2008年3月、<http://www.ogf.org/documents/GFD.125.pdf>。
[IGTF] "The International Grid Trust Federation", <http://www.igtf.net/>.
[IGTF]「The International Grid Trust Federation」、<http://www.igtf.net/>。
[KX509] Doster, W., Watts, M., and D. Hyde, "The KX.509 Protocol", September 2001, <http://www.citi.umich.edu/ techreports/reports/citi-tr-01-2.pdf>.
[KX509] Doster、W.、Watts、M。、およびD. Hyde、「The KX.509 Protocol」、2001年9月、<http://www.citi.umich.edu/ techreports / reports / citi-tr- 01-2.pdf>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC4211] Schaad、J。、「Internet X.509 Public Key Infrastructure Certificate Request Message Format（CRMF）」、RFC 4211、2005年9月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556] Zhu、L。、およびB. Tung、「Kerberosでの初期認証のための公開鍵暗号化（PKINIT）」、RFC 4556、2006年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[SLCS] "Short Lived Credential Services", February 2009, <http://tagpma.org/authn_profiles/slcs>.
[SLCS]「Short Lived Credential Services」、2009年2月、<http://tagpma.org/authn_profiles/slcs>。
[X.509] International Telecommunications Union, "Recommendation X.509: The Directory: Public-key and attribute certificate framework", November 2008.
[X.509] International Telecommunications Union、「Recommendation X.509：The Directory：Public-key and attribute certificate framework」、2008年11月。
As noted in the Security Considerations section, the functional lifetime of the acquired X.509 certificate should usually match the lifetime of its predecessor Kerberos ticket. Therefore, it is likely that X.509 certificates issued with this protocol should be deleted when the supporting Kerberos tickets are deleted. That makes the Kerberos ticket cache a reasonable location to store the certificate (and its private key).
「セキュリティに関する考慮事項」のセクションで述べたように、取得したX.509証明書の機能的なライフタイムは、通常、その前のKerberosチケットのライフタイムと一致する必要があります。したがって、サポートされているKerberosチケットが削除されると、このプロトコルで発行されたX.509証明書も削除される可能性があります。これにより、Kerberosチケットキャッシュは、証明書（およびその秘密キー）を保存するための適切な場所になります。
On the other hand, applications, such as web browsers, probably expect certificates in different stores.
一方、Webブラウザーなどのアプリケーションでは、おそらく異なるストアに証明書が必要です。
A widely used solution to this dichotomy is to implement a PKCS11 library that supports the kx509-acquired credentials. The credentials remain stored in the Kerberos credentials cache, but full PKI functionality is still available via a standard interface for PKI credentials.
この二分法に対して広く使用されているソリューションは、kx509が取得した資格情報をサポートするPKCS11ライブラリを実装することです。資格情報はKerberos資格情報キャッシュに保存されたままですが、PKI資格情報の標準インターフェイスを介して、完全なPKI機能を引き続き使用できます。
This appendix documents extensions to the kx509 protocol that are either no longer in use or are expected to be dropped.
この付録では、kx509プロトコルの拡張機能について説明します。これらの拡張機能は使用されなくなったか、削除される予定です。
A subjectAltName othername extension of type kcaAuthRealm (OID value 1.3.6.1.4.1.250.42.1) is frequently used to include the client's realm as an ASN.1 octet string.
タイプkcaAuthRealm（OID値1.3.6.1.4.1.250.42.1）のsubjectAltName othername拡張は、クライアントのレルムをASN.1オクテット文字列として含めるために頻繁に使用されます。
The Microsoft-defined userPrincipalName has frequently been used for the same purpose as the id-pkinit-san.
Microsoft定義のuserPrincipalNameは、id-pkinit-sanと同じ目的で頻繁に使用されています。
The historic implementations of this protocol included provisions for DSA keys in place of RSA. DSA does not appear to be in use. A future version of this protocol will use a standard certificate request structure that will provide algorithm agility.
このプロトコルの歴史的な実装には、RSAの代わりにDSAキーの規定が含まれていました。 DSAは使用されていないようです。このプロトコルの将来のバージョンでは、アルゴリズムの俊敏性を提供する標準の証明書要求構造を使用します。
The historic implementations of this protocol allowed an optional client-version field (at the end of the request) of type VisibleString. If present, the KCA copied it into the issued certificate as an extension with the OID 1.3.6.1.4.1.250.42.2. This feature does not appear to be in use.
このプロトコルの歴史的な実装では、VisibleStringタイプのオプションのclient-versionフィールド（リクエストの最後）が許可されていました。存在する場合、KCAはそれをOID 1.3.6.1.4.1.250.42.2の拡張機能として発行された証明書にコピーしました。この機能は使用されていないようです。
The request and reply are from the same exchange. The Ethernet, IP, and UDP headers, and the 4-byte version string at the beginning of the request and reply packets are all omitted. Only the ASN.1- encoded portions are shown.
要求と応答は同じ交換からのものです。イーサネット、IP、UDPヘッダー、および要求パケットと応答パケットの先頭にある4バイトのバージョン文字列はすべて省略されています。 ASN.1でエンコードされた部分のみが表示されます。
0:d=0 hl=4 l= 678 cons: SEQUENCE
4:d=1 hl=4 l= 509 prim: OCTET STRING
[HEX DUMP]:6E8201F9308201F5A003... (AP-REQ)
517:d=1 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:ECFF1C922300D0E9DD02... (pk-hash)
539:d=1 hl=3 l= 140 prim: OCTET STRING
[HEX DUMP]:30818902818100B70F46... (pk-key)
Request Packet ASN.1 Decode
パケットASN.1デコードの要求
0:d=0 hl=4 l= 870 cons: SEQUENCE
4:d=1 hl=2 l= 22 cons: cont [ 1 ]
6:d=2 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:F3A844834C26D843B6FD... (hash)
28:d=1 hl=4 l= 842 cons: cont [ 2 ]
32:d=2 hl=4 l= 838 prim: OCTET STRING
[HEX DUMP]:308203423082022AA003... (certificate)
Reply Packet ASN.1 Decode
応答パケットASN.1デコード
Authors' Addresses
著者のアドレス
Henry B. Hotz Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Dr. Pasadena, CA 91109 USA
カリフォルニア工科大学ヘンリーB.ホッツジェット推進研究所4800 Oak Grove Dr. Pasadena、CA 91109 USA
Phone: +01 818 354-4880
EMail: hotz@jpl.nasa.gov
Russ Allbery Stanford University P.O. Box 20066 Stanford, CA 94309 USA
Russ Allberyスタンフォード大学P.O.ボックス20066アメリカ合衆国、スタンフォード、94309
EMail: rra@stanford.edu
URI: http://www.eyrie.org/~eagle/