RFC4557 日本語訳
4557 Online Certificate Status Protocol (OCSP) Support for Public KeyCryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu,K. Jaganathan, N. Williams. June 2006. (Format: TXT=11593 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Zhu
Request for Comments: 4557 K. Jaganathan
Category: Standards Track Microsoft Corporation
N. Williams
Sun Microsystems
June 2006
コメントを求めるワーキンググループL.朱の要求をネットワークでつないでください: 4557年のK.Jaganathanカテゴリ: 標準化過程マイクロソフト社N.ウィリアムズサン・マイクロシステムズ2006年6月
Online Certificate Status Protocol (OCSP) Support for
Public Key Cryptography for
Initial Authentication in Kerberos (PKINIT)
ケルベロスにおける初期の認証のための公開鍵暗号のオンライン証明書状態プロトコル(OCSP)サポート(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography.
このドキュメントは、バンドにおける、ケルベロスネットワーク認証プロトコルにおける、Online Certificate Statusプロトコル(OCSP)応答の送信を可能にするためにメカニズムを定義します。 これらの応答は、公開鍵暗号の使用に備えるケルベロスバージョン5拡大であるケルベロス(PKINIT)によるInitial AuthenticationにPublic Key Cryptographyで使用される証明書の正当性について確かめるのに使用されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Message Definition ..............................................2
4. Security Considerations .........................................3
5. Acknowledgements ................................................4
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................4
1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. メッセージ定義…2 4. セキュリティ問題…3 5. 承認…4 6. 参照…4 6.1. 標準の参照…4 6.2. 有益な参照…4
Zhu, et al. Standards Track [Page 1] RFC 4557 OCSP Support for PKINIT June 2006
朱、他 標準化過程[1ページ]RFC4557OCSPは、PKINITのために6月が2006であるとサポートします。
1. Introduction
1. 序論
Online Certificate Status Protocol (OCSP) [RFC2560] enables applications to obtain timely information regarding the revocation status of a certificate. Because OCSP responses are well bounded and small in size, constrained clients may wish to use OCSP to check the validity of the certificates for Kerberos Key Distribution Center (KDC) in order to avoid transmission of large Certificate Revocation Lists (CRLs) and therefore save bandwidth on constrained networks [OCSP-PROFILE].
オンラインCertificate Statusプロトコル(OCSP)[RFC2560]は、アプリケーションが証明書の取消し状態に関する時宜を得た情報を得るのを可能にします。 OCSP応答がサイズがよくバウンドしていて小さいので、強制的なクライアントは大きいCertificate Revocation Lists(CRLs)のトランスミッションを避けて、したがって、制約つきネットワーク[OCSP-PROFILE]における帯域幅を保存するためにケルベロスKey Distributionセンター(KDC)がないかどうか証明書の正当性をチェックするのにOCSPを使用したがっているかもしれません。
This document defines a pre-authentication type [RFC4120], where the client and the KDC MAY piggyback OCSP responses for certificates used in authentication exchanges, as defined in [RFC4556].
このドキュメントはプレ認証タイプ[RFC4120]を定義します、[RFC4556]で定義されるように。(そこでは、クライアントとKDC MAYが認証交換に使用される証明書のためのOCSP応答を背負います)。
By using this OPTIONAL extension, PKINIT clients and the KDC can maximize the reuse of cached OCSP responses.
このOPTIONAL拡張子を使用することによって、PKINITクライアントとKDCはキャッシュされたOCSP応答の再利用を最大にすることができます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
3. Message Definition
3. メッセージ定義
A pre-authentication type identifier is defined for this mechanism:
プレ認証タイプ識別子はこのメカニズムのために定義されます:
PA-PK-OCSP-RESPONSE 18
PA PK-OCSP応答18
The corresponding padata-value field [RFC4120] contains the DER [X60] encoding of the following ASN.1 type:
対応するpadata-値の分野[RFC4120]は以下のASN.1タイプのDER[X60]コード化を含んでいます:
PKOcspData ::= SEQUENCE OF OcspResponse
-- If more than one OcspResponse is
-- included, the first OcspResponse
-- MUST contain the OCSP response
-- for the signer's certificate.
-- The signer refers to the client for
-- AS-REQ, and the KDC for the AS-REP,
-- respectively.
PKOcspData:、:= SEQUENCE OF OcspResponseを1OcspResponseがそうであるなら含んでいる最初のOcspResponse--署名者の証明書のためのOCSP応答を含まなければなりません。 -- 署名者がクライアントを参照する、--AS-REQ、およびAS-REPのためのKDC--それぞれ。
OcspResponse ::= OCTET STRING
-- Contains a complete OCSP response,
-- as defined in [RFC2560].
OcspResponse:、:= OCTET STRING--[RFC2560]で定義されるように完全なOCSP応答を含んでいます。
The client MAY send OCSP responses for certificates used in PA-PK- AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE.
クライアントはPA-PK-OCSP-RESPONSEを通してPA-PK- AS-REQ[RFC4556]で使用される証明書のための応答をOCSPに送るかもしれません。
Zhu, et al. Standards Track [Page 2] RFC 4557 OCSP Support for PKINIT June 2006
朱、他 標準化過程[2ページ]RFC4557OCSPは、PKINITのために6月が2006であるとサポートします。
The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK- OCSP-RESPONSE containing OCSP responses for certificates used in the KDC's PA-PK-AS-REP. The client can request a PA-PK-OCSP-RESPONSE by using a PKOcspData containing an empty sequence.
PA-PK-OCSP-RESPONSE SHOULDを受けるKDCはKDCのPA-PK-AS-REPで使用される証明書のためのOCSP応答を含むPA-PK- OCSP-RESPONSEを送ります。クライアントは、空の系列を含むPKOcspDataを使用することによって、PA-PK-OCSP-RESPONSEを要求できます。
The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-PK-OCSP-RESPONSE from the client.
それがクライアントからPA-PK-OCSP-RESPONSEを受けないとき、KDC MAYはPA-PK-OCSP-RESPONSEを送ります。
The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for certificates used in PA-PK-AS-REP [RFC4556].
KDCによって送られたPA-PK-OCSP-RESPONSEはPA-PK-AS-REP[RFC4556]で使用される証明書のためのOCSP応答を含んでいます。
Note the lack of integrity protection for the empty or missing OCSP response; lack of an expected OCSP response from the KDC for the KDC's certificates SHOULD be treated as an error by the client, unless it is configured otherwise.
空の、または、なくなったOCSP応答のための保全保護の不足に注意してください。 クライアントによって誤りとして扱われた状態で、KDCの証明書SHOULDのためのKDCからの予想されたOCSP応答に欠けてください、それが別の方法で構成されない場合。
When using OCSP, the response is signed by the OCSP server, which is trusted by the receiver. Depending on local policy, further verification of the validity of the OCSP servers may be needed
OCSPを使用するとき、応答はOCSPサーバによって署名されます。(サーバは受信機によって信じられます)。ローカルの方針によって、OCSPサーバの正当性のさらなる検証が必要であるかもしれません。
The client and the KDC SHOULD ignore invalid OCSP responses received via this mechanism, and they MAY implement CRL processing logic as a fall-back position, if the OCSP responses received via this mechanism alone are not sufficient for the verification of certificate validity. The client and/or the KDC MAY ignore a valid OCSP response and perform its own revocation status verification independently.
クライアントとKDC SHOULDはこのメカニズムで受けられた無効のOCSP応答を無視します、そして、後退位置としてCRL処理が論理であると実装するかもしれません、このメカニズムで単独で受けられたOCSP応答が証明書の正当性の検証に十分でないなら。 クライアント、そして/または、KDC MAYは独自に有効なOCSP応答を無視して、それ自身の取消し状態検証を実行します。
4. Security Considerations
4. セキュリティ問題
The pre-authentication data in this document do not actually authenticate any principals, but are designed to be used in conjunction with PKINIT.
プレ認証データは、実際に本書ではどんな主体も認証しませんが、PKINITに関連して使用されるように設計されています。
There is no binding between PA-PK-OCSP-RESPONSE pre-authentication data and PKINIT pre-authentication data other than a given OCSP response corresponding to a certificate used in a PKINIT pre- authentication data element. Attacks involving removal or replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements are, at worst, downgrade attacks, where a PKINIT client or KDC would proceed without use of CRLs or OCSP for certificate validation, or denial-of-service attacks, where a PKINIT client or KDC that cannot validate the other's certificate without an accompanying OCSP response might reject the AS exchange or might have to download very large CRLs in order to continue. Kerberos V does not protect against denial-of-service attacks; therefore, the denial-of-service aspect of these attacks is acceptable.
PA-PK-OCSP-RESPONSEプレ認証データとPKINITプレ認証データ要素で使用される証明書に対応する与えられたOCSP応答以外のPKINITプレ認証データの間で縛ってはいけません。 PA-PK-OCSP-RESPONSEプレ認証データ要素の取り外しか交換にかかわる攻撃は最悪の場合はダウングレード攻撃です、PKINITクライアントかKDCがCRLsの使用も証明書合法化、またはサービス不能攻撃のためのOCSP((交換を拒絶しなければならないか、または続くように非常に大きいCRLsをダウンロードしなければならないかもしれません)付随のOCSP応答なしでもう片方の証明書を有効にすることができないPKINITクライアントかKDC)なしで続くだろうところで。 Vがするケルベロスはサービス不能攻撃から守りません。 したがって、これらの攻撃のサービスの否定局面は許容できます。
Zhu, et al. Standards Track [Page 3] RFC 4557 OCSP Support for PKINIT June 2006
朱、他 標準化過程[3ページ]RFC4557OCSPは、PKINITのために6月が2006であるとサポートします。
If a PKINIT client or KDC cannot validate certificates without the aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS exchange, possibly according to local configuration.
PKINITクライアントかKDCが有効なPA-PK-OCSP-RESPONSEの援助なしで証明書を有効にすることができないで、次に、それはASが交換するSHOULDやり損ないです、ことによると地方の構成に従って。
5. Acknowledgements
5. 承認
This document was based on conversations among the authors, Jeffrey Altman, Sam Hartman, Martin Rex, and other members of the Kerberos working group.
このドキュメントは作者の中で会話に基づきました、ジェフリー・アルトマン、サム・ハートマン、ケルベロスワーキンググループのマーチンレックスの、そして、他のメンバー。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
C. Adams, "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[RFC2560] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC
4120, July 2005.
[RFC4120]ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for
Initial Authentication in Kerberos (PKINIT)", RFC
4556, June 2006.
[RFC4556] 朱とL.とB.タン、「ケルベロス(PKINIT)における初期の認証のための公開鍵暗号」、RFC4556、2006年6月。
[X690] ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), ITU-T
Recommendation X.690 (1997) | ISO/IEC International
Standard 8825-1:1998.
[X690]ASN.1符号化規則: 基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様、ITU-T推薦X.690(1997)| ISO/IEC国際規格8825-1:1998。
6.2. Informative References
6.2. 有益な参照
[OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
High Volume Environments", Work in Progress, May 2006.
[OCSP-プロフィール] 「ライト級OCSPは高いボリュームのために環境の輪郭を描く」という執事、A.、およびR.ハーストは進歩、2006年5月に働いています。
Zhu, et al. Standards Track [Page 4] RFC 4557 OCSP Support for PKINIT June 2006
朱、他 標準化過程[4ページ]RFC4557OCSPは、PKINITのために6月が2006であるとサポートします。
Authors' Addresses
作者のアドレス
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
ラリー朱マイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: lzhu@microsoft.com
メール: lzhu@microsoft.com
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Karthik Jaganathanマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: karthikj@microsoft.com
メール: karthikj@microsoft.com
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
ニコラスウィリアムズサン・マイクロシステムズ5300Riata跡のCtオースチン(テキサス)78727米国
EMail: Nicolas.Williams@sun.com
メール: Nicolas.Williams@sun.com
Zhu, et al. Standards Track [Page 5] RFC 4557 OCSP Support for PKINIT June 2006
朱、他 標準化過程[5ページ]RFC4557OCSPは、PKINITのために6月が2006であるとサポートします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Zhu, et al. Standards Track [Page 6]
朱、他 標準化過程[6ページ]
一覧
スポンサーリンク
