RFC4806 日本語訳
4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2. M.Myers, H. Tschofenig. February 2007. (Format: TXT=21991 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Myers
Request for Comments: 4806 TraceRoute Security LLC
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
February 2007
コメントを求めるワーキンググループM.マイアーズの要求をネットワークでつないでください: 4806年のトレースルートセキュリティLLCカテゴリ: 標準化過程H.TschofenigジーメンスネットワークGmbHと共同kg2007年2月
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
IKEv2へのオンライン証明書状態プロトコル(OCSP)拡大
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 IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
インターネット・キー・エクスチェンジプロトコルバージョン2(IKEv2)は、公開鍵がベースの認証であるとサポートしますが、バンドにおけるCertificate Revocation Lists(CRL)の対応する使用は限りないCRLサイズのために問題が多いです。 Online Certificate Statusプロトコル(OCSP)応答のサイズは、しかしながら、よくバウンドしていて小さいです。 このドキュメントは「OCSP内容」拡大をIKEv2と定義します。 「OCSP内容」に従ったCERTREQペイロードは、ゼロかさらに信じられたOCSP応答者を特定して、IKEv2握手でのOCSP応答の包含を求めて要求です。 CERTペイロードが適切なOCSP応答を含んでいて、そのような要求の協力的な受取人は応じます。 この内容は同じ「OCSP内容」識別子で認識可能です。
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network.
証明書がIKEv2と共に使用されるとき、交信している同輩は、同輩の証明書の取消し状態を決定するためにメカニズムを必要とします。 OCSPはそのようなメカニズムの1つです。 OCSPが望まれていて、IKEv2同輩のひとりが安全保障政策によって直接関連OCSP応答者にアクセスできないとき、このドキュメントは適用されます。 ファイアウォールはIKEv2同輩による外のそのようなアクセスを防ぐ企業網の方法でしばしば配布されます。
Myers & Tschofenig Standards Track [Page 1] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[1ページ]RFC4806OCSP拡張子
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 拡大定義. . . . . . . . . . . . . . . . . . . . . 4 3.1。 OCSPは.43.2を要求します。 OCSP応答. . . . . . . . . . . . . . . . . . . . . . 5 4。 拡大要件. . . . . . . . . . . . . . . . . . . . 5 4.1。 OCSPには、サポート. . . . . . . . . . . . . . . . . 5 4.2を要求してください。 OCSPサポート. . . . . . . . . . . . . . . . . 6 5への応答。 例と議論. . . . . . . . . . . . . . . . . . . 6 5.1。 ピアツーピア. . . . . . . . . . . . . . . . . . . . . . . 6 5.2。 拡張認証プロトコル(EAP。). . . . . . . . . . 7 6 セキュリティ問題. . . . . . . . . . . . . . . . . . . 8 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 9 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 9 9。 引用規格. . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
1. 序論
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] supports a range of authentication mechanisms, including the use of public key based authentication. Confirmation of certificate reliability is essential in order to achieve the security assurances public key cryptography provides. One fundamental element of such confirmation is reference to certificate revocation status (see [RFC3280] for additional detail).
[IKEv2]がさまざまな認証機構をサポートするインターネット・キー・エクスチェンジ(IKE)プロトコルのバージョン2、公開鍵の使用を含んでいると、認証は基づきました。 証明書の信頼性の確認は、公開鍵暗号が提供する安全保証を達成するのに不可欠です。 そのような確認のある基本的な要素は取消し状態を証明する参照(追加詳細に関して[RFC3280]を見る)です。
The traditional means of determining certificate revocation status is through the use of Certificate Revocation Lists (CRLs). IKEv2 allows CRLs to be exchanged in-band via the CERT payload.
証明書取消し状態を決定する伝統的な手段がCertificate Revocation Lists(CRLs)の使用であります。 IKEv2は、CRLsが交換されたCERTを通したバンドのペイロードであることを許容します。
However, CRLs can grow unbounded in size. Many real-world examples exist to demonstrate the impracticality of including a multi-megabyte file in an IKE exchange. This constraint is particularly acute in bandwidth-limited environments (e.g., mobile communications). The net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) acquisition of these data, should they even be used at all.
しかしながら、CRLsはサイズで限りなくなることができます。 多くの本当の世界の例が、IKE交換にマルチメガバイトファイルを含む実行不可能を示すために存在しています。 この規制は帯域幅で限られた環境(例えば、移動通信)で特に鋭いです。 ネットの効果はこれらのデータのバンドで出ている(OOB)獲得を支持してバンドにおけるCRLsの除外です、それらが少しでも使用されても。
Reliance on OOB methods can be further complicated if access to revocation data requires use of IPsec (and therefore IKE) to establish secure and authorized access to the CRLs of an IKE participant. Such network access deadlock further contributes to a reduced reliance on the status of certificate revocations in favor of blind trust.
取消しデータへのアクセスがIKE関係者のCRLsへの安全で認可されたアクセスを証明するためにIPsec(そして、したがって、IKE)の使用を必要とするなら、さらにOOBメソッドへの信用を複雑にすることができます。 そのようなネットワークアクセス行き詰まりは白紙委任を支持してさらに証明書取消しの状態への減少している信用に貢献します。
Myers & Tschofenig Standards Track [Page 2] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[2ページ]RFC4806OCSP拡張子
OCSP [RFC2560] offers a useful alternative. The size of an OCSP response is bounded and small and therefore suitable for in-band IKEv2 signaling of a certificate's revocation status.
OCSP[RFC2560]は役に立つ代替手段を提供します。 OCSP応答のサイズは、境界があって小さくしたがって、バンドにおける、証明書の取消し状態のIKEv2シグナリングに適しています。
This document defines an extension to IKEv2 that enables the use of OCSP for in-band signaling of certificate revocation status. A new content encoding is defined for use in the CERTREQ and CERT payloads. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
このドキュメントはOCSPのバンドにおける、証明書取消し状態のシグナリングの使用を可能にするIKEv2と拡大を定義します。 新しい満足しているコード化はCERTREQとCERTペイロードにおける使用のために定義されます。 「OCSP内容」に従ったCERTREQペイロードは、ゼロかさらに信じられたOCSP応答者を特定して、IKEv2握手でのOCSP応答の包含を求めて要求です。 CERTペイロードが適切なOCSP応答を含んでいて、そのような要求の協力的な受取人は応じます。 この内容は同じ「OCSP内容」識別子で認識可能です。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
This document defines the following terms:
このドキュメントは次の用語を定義します:
OCSP request:
OCSPは以下を要求します。
An OCSP request refers to the CERTREQ payload that contains a new
content encoding, referred to as OCSP Content, that conforms to
the definition and behavior specified in Section 3.1.
OCSP要求はセクション3.1で指定された定義と振舞いに従うOCSP Contentと呼ばれた新しい満足しているコード化を含むCERTREQペイロードについて言及します。
OCSP response:
OCSP応答:
An OCSP response refers to the CERT payload that contains a new
content encoding, referred to as OCSP Content, that conforms to
the definition and behavior specified in Section 3.2.
OCSP応答はセクション3.2で指定された定義と振舞いに従うOCSP Contentと呼ばれた新しい満足しているコード化を含むCERTペイロードについて言及します。
OCSP responder:
OCSP応答者:
The term OCSP responder refers to the entity that accepts requests
from an OCSP client and returns responses as defined in [RFC2560].
Note that the OCSP responder does not refer to the party that
sends the CERT message.
用語OCSP応答者はOCSPクライアントから要求を受け入れて、[RFC2560]で定義されるように応答を返す実体について言及します。 OCSP応答者がCERTメッセージを送るパーティーについて言及しないことに注意してください。
Myers & Tschofenig Standards Track [Page 3] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[3ページ]RFC4806OCSP拡張子
3. Extension Definition
3. 拡大定義
With reference to Section 3.6 of [IKEv2], the values for the Cert Encoding field of the CERT payload are extended as follows (see also the IANA Considerations section of this document):
[IKEv2]のセクション3.6に関して、CERTペイロードのCert Encoding分野への値は以下の通り広げられます(また、このドキュメントのIANA Considerations部を見てください):
Certificate Encoding Value
-------------------- -----
OCSP Content 14
値をコード化する証明書-------------------- ----- OCSP内容14
3.1. OCSP Request
3.1. OCSP要求
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ Payload indicates the presence of zero or more OCSP responder certificate hashes in the Certificate Authority field of the CERTREQ payload. Section 2.2 of [RFC2560] defines responses, which belong to one of the following three groups:
CERTREQ有効搭載量のCert Encoding分野のOCSP Content(14)の値はOCSP応答者証明書がCERTREQペイロードのCertificate Authority分野で論じ尽くすゼロか以上の存在を示します。 [RFC2560]のセクション2.2は応答を定義します:(応答は以下の3つのグループの1つに属します)。
(a) the CA who issued the certificate
(a) 証明書を発行したカリフォルニア
(b) a Trusted Responder whose public key is trusted by the requester
(b) 公開鍵がリクエスタによって信じられるTrusted Responder
(c) a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA,
indicating that the responder may issue OCSP responses for that
CA
(c) 応答者がそのカリフォルニアのためにOCSPに応答を発行するかもしれないのを示して、直接カリフォルニアが特に著しい証明書を発行するように主張するカリフォルニアDesignated Responder(Responderを認可します)
In case of (a), the use of hashes in the CERTREQ message is not needed since the OCSP response is signed by the CA who issued the certificate. In case of (c), the OCSP response is signed by the CA Designated Responder whereby the sender of the CERTREQ message does not know the public key in advance. The presence of OCSP Content in a CERTREQ message will identify one or more OCSP responders trusted by the sender in case of (b).
(a)の場合には、OCSP応答が証明書を発行したカリフォルニアによって署名されるので、CERTREQメッセージにおけるハッシュの使用は必要ではありません。 (c)の場合には、OCSP応答はCERTREQメッセージの送付者があらかじめ公開鍵を知らないカリフォルニアDesignated Responderによって署名されます。 CERTREQメッセージでのOCSP Contentの存在は(b)の場合に送付者によって信じられた1人以上のOCSP応答者を特定するでしょう。
The presence of OCSP Content (14) in a CERTREQ message:
CERTREQメッセージでのOCSP Content(14)の存在:
1. identifies zero or more OCSP responders trusted by the sender;
1.、ゼロか送付者によって信じられたより多くのOCSP応答者を特定します。
2. notifies the recipient of sender's support for the OCSP extension
to IKEv2; and
2.、送付者のOCSP拡張子のサポートについて受取人にIKEv2に通知します。 そして
3. notifies the recipient of sender's desire to receive OCSP
confirmation in a subsequent CERT payload.
3.、その後のCERTペイロードにおけるOCSP確認を受け取る送付者の願望について受取人に通知します。
Myers & Tschofenig Standards Track [Page 4] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[4ページ]RFC4806OCSP拡張子
3.2. OCSP Response
3.2. OCSP応答
A value of OCSP Content (14) in the Cert Encoding field of a CERT Payload indicates the presence of an OCSP response in the Certificate Data field of the CERT payload.
CERT有効搭載量のCert Encoding分野のOCSP Content(14)の値はCERTペイロードのCertificate Data分野でのOCSP応答の存在を示します。
Correlation between an OCSP response CERT payload and a corresponding CERT payload carrying a certificate can be achieved by matching the OCSP response CertID field to the certificate. See [RFC2560] for the definition of OCSP response content.
OCSP応答CertID分野を証明書に合わせることによって、OCSP応答CERTペイロードと証明書を運ぶ対応するCERTペイロードの間の相関関係を達成できます。 OCSP応答内容の定義に関して[RFC2560]を見てください。
4. Extension Requirements
4. 拡大要件
4.1. Request for OCSP Support
4.1. OCSPには、サポートを要求してください。
Section 3.7 of [IKEv2] allows for the concatenation of trust anchor hashes as the Certification Authority value of a single CERTREQ message. There is no means however to indicate which among those hashes, if present, relates to the certificate of a trusted OCSP responder.
[IKEv2]のセクション3.7はただ一つのCERTREQメッセージの認証局値として信頼アンカーハッシュの連結を考慮します。 しかしながら、存在しているならどれがそれらのハッシュの中で信じられたOCSP応答者の証明書に関連するかを示すために、手段は全くありません。
Therefore, an OCSP request, as defined in Section 3.1 above, is transmitted separate from any other CERTREQ payloads in an IKEv2 exchange.
したがって、上のセクション3.1で定義されるOCSP要求はいかなる他のCERTREQペイロードからもIKEv2交換で別々の状態で伝えられます。
Where it is useful to identify more than one trusted OCSP responder, each such identification SHALL be concatenated in a manner identical to the method documented in Section 3.7 of [IKEv2] regarding the assembly of multiple trust anchor hashes.
それが役に立つところでは、1人以上の信じられたOCSP応答者、そのような各識別SHALLを特定するために、[IKEv2]のセクション3.7に複数の信頼アンカーハッシュのアセンブリに関して記録されたメソッドと同じ方法で連結されてください。
The Certification Authority value in an OCSP request CERTREQ SHALL be computed and produced in a manner identical to that of trust anchor hashes as documented in Section 3.7 of [IKEv2].
AuthorityがOCSPで評価するCertificationは、CERTREQ SHALLが[IKEv2]のセクション3.7に記録されるように信頼アンカーハッシュのものと同じ方法で計算されて、生産されるよう要求します。
Upon receipt of an OCSP response CERT payload corresponding to a prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the OCSP response into path validation logic defined by [RFC3280].
先のOCSP要求CERTREQに対応するOCSP応答CERTペイロードを受け取り次第、CERTREQ送付者SHALLは[RFC3280]によって定義された経路合法化論理にOCSP応答を組み入れます。
Note that the lack of an OCSP response CERT payload after sending an OCSP request CERT payload might be an indication that this OCSP extension is not supported. As a result, it is recommended that nodes be configured to require a response only if it is known that all peers do in fact support this extension. Otherwise, it is recommended that the nodes be configured to try OCSP and, if there is no response, attempt to determine certificate revocation status by some other means.
OCSP要求CERTペイロードを送った後のOCSP応答CERTペイロードの不足がこのOCSP拡張子がサポートされないという指示であるかもしれないことに注意してください。 その結果、事実上、すべての同輩がこの拡大をサポートするのが知られている場合にだけノードが応答を必要とするように構成されるのは、お勧めです。 さもなければ、ノードがOCSPを試みて、応答が全くなければある他の手段で証明書取消し状態を決定するのを試みるために構成されるのは、お勧めです。
Myers & Tschofenig Standards Track [Page 5] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[5ページ]RFC4806OCSP拡張子
4.2. Response to OCSP Support
4.2. OCSPサポートへの応答
Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD acquire the related OCSP-based assertion and produce and transmit an OCSP response CERT payload corresponding to the certificate needed to verify its signature on IKEv2 payloads.
OCSP要求CERTREQペイロードを受け取り次第、受取人SHOULDはIKEv2ペイロードの上に署名について確かめるのが必要である証明書に対応するOCSP応答CERTペイロードを関連するOCSPベースの主張を取得して、生産して、伝えます。
An OCSP response CERT payload is transmitted separate from any other CERT payload in an IKEv2 exchange.
OCSP応答CERTペイロードはいかなる他のCERTペイロードからもIKEv2交換で別々の状態で伝えられます。
The means by which an OCSP response may be acquired for production of an OCSP response CERT payload is out of scope of this document.
このドキュメントの範囲の外にOCSP応答がOCSP応答CERTペイロードの生産のために取得されるかもしれない手段があります。
The Certificate Data field of an OCSP response CERT payload SHALL contain a DER-encoded OCSPResponse structure as defined in [RFC2560].
[RFC2560]で定義されて、SHALLがDERによってコード化されたOCSPResponse構造を含むOCSP応答CERTペイロードのCertificate Data分野。
5. Examples and Discussion
5. 例と議論
This section shows the standard IKEv2 message examples with both peers, the initiator and the responder, using public key based authentication, CERTREQ and CERT payloads. The first instance corresponds to Section 1.2 of [IKEv2], the illustrations of which are reproduced below for reference.
このセクションは、公開鍵を使用すると両方の同輩、創始者、および応答者と共に、認証、CERTREQ、およびCERTペイロードが基づいたのを標準のIKEv2メッセージの例に示します。 最初のインスタンスは[IKEv2]のセクション1.2に対応しています。そのイラストは参照のために以下で複製されます。
5.1. Peer to Peer
5.1. ピアツーピア
Application of the IKEv2 extensions defined in this document to the peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as follows. Messages are numbered for ease of reference.
本書では[IKEv2]のセクション1.2で定義されたピアツーピア交換と定義されたIKEv2拡張子の応用は以下の通りです。 メッセージは参照する場合に便利なように付番されます。
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
創始者応答者----------- ----------- (1) HDR、SAi1、KEi、Ni-->。
(2) <-- HDR, SAr1, KEr, Nr,
CERTREQ(OCSP Request)
(3) HDR, SK {IDi, CERT(certificate),-->
CERT(OCSP Response),
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(2)<--HDR、SAr1、KEr、Nr、CERTREQ(OCSP要求)(3)HDR、SKIDi、本命(証明書)-->本命(OCSP応答)、CERTREQ(OCSP要求)、AUTH、SAi2、[IDr]TSi、TSr
(4) <-- HDR, SK {IDr,
CERT(certificate),
CERT(OCSP Response),
AUTH, SAr2, TSi, TSr}
(4)<--HDR、SKIDr、本命(証明書)、本命(OCSP応答)、AUTH、SAr2、TSi、TSr
OCSP Extensions to Baseline IKEv2
基線IKEv2へのOCSP拡張子
Myers & Tschofenig Standards Track [Page 6] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[6ページ]RFC4806OCSP拡張子
In (2), Responder sends an OCSP request CERTREQ payload identifying zero or more OCSP responders trusted by the Responder. In response, Initiator sends in (3) both a CERT payload carrying its certificate and an OCSP response CERT payload covering that certificate. In (3), Initiator also requests an OCSP response via the OCSP request CERTREQ payload. In (4), the Responder returns its certificate and a separate OCSP response CERT payload covering that certificate.
(2)では、ResponderはOCSP要求CERTREQペイロードにゼロを特定するのを行かせるか、またはResponderによって信じられた応答者により多くのOCSPに行かせます。 応答では、Initiatorは(3) 証明書を運ぶCERTペイロードとその証明書をカバーするOCSP応答CERTペイロードの両方を送ります。 また、(3)では、InitiatorはOCSP要求CERTREQペイロードでOCSP応答を要求します。 (4)では、Responderは証明書とその証明書をカバーする別々のOCSP応答CERTペイロードを返します。
It is important to note that in this scenario, the Responder in (2) does not yet possess the Initiator's certificate and therefore cannot form an OCSP request as defined in [RFC2560]. To bypass this problem, hashes are used as defined in Section 4.1. In such instances, OCSP Requests are simply index values into these data. Thus, it is easily inferred that OCSP responses can be produced in the absence of a corresponding request (provided that OCSP nonces are not used, see Section 6).
(2)のResponderがこのシナリオでは、まだInitiatorの証明書を持っていなくて、したがって、[RFC2560]で定義されるOCSP要求を形成できないことに注意するのは重要です。 この問題を迂回させるために、ハッシュはセクション4.1で定義されるように使用されています。 そういった場合には、OCSP Requestsは単にこれらのデータへのインデックス値です。 したがって、対応する要求がないときOCSP応答を起こすことができる(OCSP一回だけが使用されていなければ、セクション6を見る)と容易に推論されます。
It is also important in extending IKEv2 toward OCSP in this scenario that the Initiator has certain knowledge that the Responder is capable of and willing to participate in the extension. Yet the Responder will only trust one or more OCSP responder signatures. These factors motivate the definition of OCSP responder hash extension.
また、InitiatorにはResponderが、拡大でできるのと参加しても構わないと思っているというある知識があるのも、このシナリオでOCSPに向かってIKEv2を広げるのにおいて重要です。 しかし、Responderは1つ以上のOCSP応答者署名しか信じないでしょう。 これらの要素はOCSP応答者ハッシュ拡張子の定義を動機づけます。
5.2. Extended Authentication Protocol (EAP)
5.2. 拡張認証プロトコル(EAP)
Another scenario of pressing interest is the use of EAP to accommodate multiple end users seeking enterprise access to an IPsec gateway. Note that OCSP is used for the certificate status check of the server side IKEv2 certificate and not for certificates that may be used within EAP methods (either by the EAP peer or the EAP server). As with the preceding section, the following illustration is extracted from [IKEv2]. In the event of a conflict between this document and [IKEv2] regarding these illustrations, [IKEv2] SHALL dominate.
緊急の関心の別のシナリオはIPsecゲートウェイへの企業アクセスを求めている複数のエンドユーザを収容するEAPの使用です。 OCSPがEAPメソッドの中で使用されるかもしれない証明書ではなく、サーバサイドIKEv2証明書(EAP同輩かEAPサーバによる)の証明書状態チェックに使用されることに注意してください。 先行するセクションのように、以下のイラストは[IKEv2]から抜粋されます。 これらのイラストに関するこのドキュメントと[IKEv2]との闘争の場合、[IKEv2]SHALLは支配しています。
Myers & Tschofenig Standards Track [Page 7] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[7ページ]RFC4806OCSP拡張子
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
(2) <-- HDR, SAr1, KEr, Nr
(3) HDR, SK {IDi, -->
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(4) <-- HDR, SK {IDr,
CERT(certificate),
CERT(OCSP Response),
AUTH, EAP}
(5) HDR, SK {EAP} -->
創始者応答者----------- ----------- (1) Ni-->(2)<--HDR、SAi1、KEi、HDR、SAr1、KEr、Nr(3)HDR、SK、IDi-->CERTREQ(OCSP要求)、AUTH、SAi2、[IDr]TSi、TSr、(4)<--HDR、SK、IDr、本命(証明書)、本命(OCSP応答)、AUTH、EAP、(5)HDR、SK EAP--、>。
(6) <-- HDR, SK {EAP (success)}
(6)<--HDR、SKEAP(成功)
(7) HDR, SK {AUTH} -->
(7)HDR、SK AUTH-->。
(8) <-- HDR, SK {AUTH, SAr2, TSi,
TSr }
(8)<--HDR、SKAUTH、SAr2、TSi、TSr
OCSP Extensions to EAP in IKEv2
IKEv2のEAPへのOCSP拡張子
In the EAP scenario, messages (5) through (8) are not relevant to this document.
EAPシナリオでは、メッセージ(5)から(8)はこのドキュメントに関連していません。
6. Security Considerations
6. セキュリティ問題
For the reasons noted above, an OCSP request, as defined in Section 3.1, is used in place of an OCSP request syntax to trigger production and transmission of an OCSP response. OCSP, as defined in [RFC2560], may contain a nonce request extension to improve security against replay attacks (see Section 4.4.1 of [RFC2560] for further details). The OCSP request defined by this document cannot accommodate nonces. [RFC2560] deals with this aspect by allowing pre-produced responses.
上に述べられた理由で、セクション3.1で定義されるOCSP要求は、OCSP応答の生産と送信の引き金となるのにOCSP要求構文に代わって使用されます。 [RFC2560]で定義されるOCSPは反射攻撃に対してセキュリティを向上させる一回だけの要求拡張子を含むかもしれません(さらに詳しい明細については.1セクション4.4[RFC2560]を見てください)。 このドキュメントによって定義されたOCSP要求は一回だけを収容できません。 あらかじめ生産された応答を許容することによって、[RFC2560]はこの局面に対処します。
[RFC2560] points to this replay vulnerability and indicates: "The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution." Nodes SHOULD make the required freshness of an OCSP response configurable.
[RFC2560]は、この再生脆弱性を示して、以下を示します。 「前計算された応答の使用は有効期限の前にもかかわらず、証明書が取り消された後を除いて、古い(良い)応答が再演される反射攻撃を許容します。」 「OCSPの展開は慎重に反射攻撃の確率とうまくいっている実行に関連しているコストに対して前計算された応答の恩恵を評価するべきです。」 ノードSHOULDはOCSP応答の必要な新しさを構成可能にします。
Myers & Tschofenig Standards Track [Page 8] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[8ページ]RFC4806OCSP拡張子
7. IANA Considerations
7. IANA問題
This document defines one new field type for use in the IKEv2 Cert Encoding field of the Certificate Payload format. Official assignment of the "OCSP Content" extension to the Cert Encoding table of Section 3.6 of [IKEv2] has been acquired from IANA.
このドキュメントはCertificate有効搭載量形式のIKEv2 Cert Encoding分野での使用のための1人の新しいフィールド・タイプを定義します。 IANAから[IKEv2]のセクション3.6のCert Encodingテーブルへの「OCSP内容」拡大の公式の課題を習得しました。
Certificate Encoding Value
-------------------- -----
OCSP Content 14
値をコード化する証明書-------------------- ----- OCSP内容14
8. Acknowledgements
8. 承認
The authors would like to thank Russ Housley for his support. Additionally, we would like to thank Pasi Eronen, Nicolas Williams, Liqiang (Larry) Zhu, Lakshminath Dondeti, and Paul Hoffman for their review. Pasi gave us invaluable last-call comments. We would also like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us IESG review comments.
作者は彼のサポートについてラスHousleyに感謝したがっています。 さらに、パシEronenに感謝申し上げます、ニコラス・ウィリアムズ、彼らのレビューのためのLiqiang(ラリー)の朱、Lakshminath Dondeti、およびポール・ホフマン。 パシは非常に貴重な最後の呼び出しコメントを私たちに与えました。 また、彼のGen-ARTレビューについてトム・テイラーに感謝申し上げます。 ヤリArkkoはIESGレビューコメントを私たちに与えました。
9. Normative References
9. 引用規格
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[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月。
[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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
Myers & Tschofenig Standards Track [Page 9] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[9ページ]RFC4806OCSP拡張子
Authors' Addresses
作者のアドレス
Michael Myers TraceRoute Security LLC
マイケルマイアーズトレースルートセキュリティLLC
EMail: mmyers@fastq.com
メール: mmyers@fastq.com
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigジーメンスネットワークGmbHと共同kgオットーハーン一味6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
メール: Hannes.Tschofenig@siemens.com ユリ: http://www.tschofenig.com
Myers & Tschofenig Standards Track [Page 10] RFC 4806 OCSP Extensions to IKEv2 February 2007
IKEv2 February 2007へのマイアーズとTschofenig標準化過程[10ページ]RFC4806OCSP拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Myers & Tschofenig Standards Track [Page 11]
マイアーズとTschofenig標準化過程[11ページ]
一覧
スポンサーリンク
