Network Working Group M. Myers
Request for Comments: 4806 TraceRoute Security LLC
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
February 2007
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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の）は、公開鍵ベースの認証をサポートしていますが、インバンド証明書失効リストの対応する使用（CRL）が原因無制限CRLのサイズに問題があります。オンライン証明書状態プロトコル（OCSP）応答の大きさは、しかしよく囲まれた、小型です。この文書では、IKEv2のが「OCSPコンテンツ」の拡張子を定義します。 「コンテンツOCSP」とCERTREQペイロードは、ゼロまたはそれ以上の信頼OCSPレスポンダを識別し、IKEv2のハンドシェイクでOCSP応答の包含のための要求です。そのような要求の協調受信者は、適切なOCSP応答を含むCERTペイロードで応答します。このコンテンツは、同じ「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は、そのようなメカニズムです。 OCSPは、所望のセキュリティポリシーは直接関係OCSPレスポンダへのアクセスからのIKEv2ピアの1つを防止しているときに、この文書では、適用されます。ファイアウォールは、多くの場合、企業ネットワークの外のIKEv2ピアがそのようなアクセスを防止するように配備されています。
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
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).
インターネット鍵交換（IKE）プロトコルのバージョン2は[IKEv2の]公開鍵による認証の使用を含む認証メカニズムの範囲をサポートしています。証明書の信頼性の確認は、公開鍵暗号方式が提供するセキュリティ保証を実現するために不可欠です。このような確認の1つの基本的な要素は、証明書の失効状態を参照し（追加の詳細については[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.
証明書の失効ステータスを決定するための伝統的な手段は、証明書失効リスト（CRL）を使用することです。 IKEv2はCRLが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.
ただし、CRLは、サイズが無制限に成長することができます。多くの実世界の例は、IKE交換で数メガバイトのファイルを含めての非現実性を実証するために存在します。この制約は、帯域幅制限された環境（例えば、移動体通信）で特に深刻です。彼らも全く使用しなければならない正味の効果は、これらのデータのアウトオブバンド（OOB）買収に賛成して帯域内のCRLの除外です。
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.
OOB方式への依存度が失効データへのアクセスが安全を確立するために（したがって、およびIKE）のIPsecを使用する必要がある場合は、さらに複雑になるとIKEの参加者のCRLのへのアクセスを許可することができます。このようなネットワーク・アクセス・デッドロックは、さらに盲目の信頼の賛成で、証明書の失効の状態の軽減依存に貢献します。
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応答の包含のための要求です。そのような要求の協調受信者は、適切なOCSP応答を含むCERTペイロードで応答します。このコンテンツは、同じ「OCSPコンテンツ」識別子を経由して認識可能です。
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]に記載されているように解釈されます。
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コンテンツと呼ばれる新しいコンテンツの符号化を、含ん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応答は新しいコンテンツの符号化を含んCERTペイロードを指し、セクション3.2で指定された定義と動作に準拠していること、OCSPコンテンツと呼びます。
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メッセージを送信パーティを参照していないことに注意してください。
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ペイロードの証明書Encodingフィールドの値は（この文書のIANAの考慮事項のセクションを参照）に拡張されます。
Certificate Encoding Value
-------------------- -----
OCSP Content 14
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ペイロードの証明書EncodingフィールドでOCSPコンテンツ（14）の値はCERTREQペイロードの認証局のフィールドにゼロまたはそれ以上のOCSPレスポンダの証明書ハッシュの存在を示します。 [RFC2560]のセクション2.2は、以下の3つのグループのいずれかに属する応答を定義します。
(a) the CA who issued the certificate
（a）は、証明書を発行したCA
(b) a Trusted Responder whose public key is trusted by the requester
（b）はその公開鍵を要求者に信頼されている信頼レスポンダ
(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）レスポンダはそのCAのためにOCSP応答を発行することができることを示し、CAによって直接発行され、特別にマークされた証明書を保持しているCA指定レスポンダ（認定レスポンダ）
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).
OCSP応答が証明書を発行したCAによって署名されているので（A）の場合には、CERTREQメッセージでハッシュの使用は必要ありません。 （C）の場合には、OCSP応答はCERTREQメッセージの送信者が事前に公開鍵を知らないことにより、CA指定レスポンダによって署名されています。 CERTREQメッセージ内OCSPコンテンツの存在が（B）の場合には、送信者によって信頼一つ以上のOCSPレスポンダを識別する。
The presence of OCSP Content (14) in a CERTREQ message:
CERTREQメッセージ内OCSPコンテンツ（14）の存在：
2. notifies the recipient of sender's support for the OCSP extension to IKEv2; and
2.のIKEv2にOCSP拡張の送信者の支援の受信者に通知し、そして
3. notifies the recipient of sender's desire to receive OCSP confirmation in a subsequent CERT payload.
3.以降のCERTペイロードに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ペイロードの証明書EncodingフィールドでOCSPコンテンツ（14）の値はCERTペイロードの証明書データフィールドの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レスポンスCERTペイロードと証明書を保有する対応するCERTのペイロードとの間の相関は、証明書にOCSP応答CertIDフィールドを照合することによって達成することができます。 OCSP応答の内容の定義については、[RFC2560]を参照してください。
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.
したがって、OCSP要求は、上記のセクション3.1で定義されるように、IKEv2の交換で他CERTREQペイロードとは別に送信されます。
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.
それは複数の信頼OCSPレスポンダを同定するために有用であり、そのような各識別は、複数のトラストアンカーハッシュのアセンブリについて【の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].
【のIKEv2]のセクション3.7に記載のようにOCSP要求CERTREQにおける証明機関値をトラストアンカーハッシュと同じ方法で計算され、製造されなければなりません。
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送信者は[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を試してみてするように設定することをお勧めします。
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ペイロードを受信すると、受信者は、関連OCSPベースアサーションを取得し、生産し、IKEv2のペイロード上の署名を検証するために必要な証明書に対応するOCSP応答CERTペイロードを送信しなければなりません。
An OCSP response CERT payload is transmitted separate from any other CERT payload in an IKEv2 exchange.
OCSP応答CERTペイロードは、IKEv2の交換で他のCERTのペイロードから別個に送信されます。
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]で定義されるようにOCSPレスポンスCERTペイロードの証明書データフィールドは、DERエンコードOCSPResponse構造を含まなければなりません。
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に相当します。
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 -->
(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、SK {IDI、CERT（証明書）、 - > CERT（OCSP応答）、CERTREQ（OCSP要求）、[IDR 、】AUTH、SAI2、をTSi、TSrを}
(4) <-- HDR, SK {IDr, CERT(certificate), CERT(OCSP Response), AUTH, SAr2, TSi, TSr}
（4）< - HDR、SK {IDR、CERT（証明書）、CERT（OCSP応答）、AUTH、SAR2、をTSi、TSrを}
OCSP Extensions to Baseline IKEv2
ベースラインのIKEv2にOCSP拡張機能
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）において、レスポンダは、レスポンダによって信頼ゼロ以上のOCSPレスポンダを識別するOCSP要求CERTREQペイロードを送信します。これに応答して、イニシエータは、その証明書と、その証明書を覆うOCSPレスポンスCERTペイロードを運ぶ（3）CERTペイロードの両方に送信します。 （3）において、イニシエータはまた、OCSP要求CERTREQペイロードを介してOCSP応答を要求します。 （4）において、レスポンダは、その証明書と、その証明書を覆う別個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).
[RFC2560]で定義されるように、それはこのシナリオでことに注意することが重要である、（2）まだ従ってイニシエータの証明書を所有せずにレスポンダはOCSPリクエストを形成することができません。セクション4.1で定義されているこの問題を回避するには、ハッシュが使用されています。そのような場合には、OCSP要求は、これらのデータに簡単にインデックス値です。したがって、容易に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.
また、イニシエータは、Responderが可能と拡張に参加する意志があることは確かな知識を持って、このシナリオではOCSPに向けてのIKEv2を拡張する上で重要です。しかし、レスポンダは一つ以上のOCSPレスポンダの署名を信頼します。これらの要因は、OCSPレスポンダーハッシュ拡張の定義を動機づける。
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サーバ側のIKEv2証明書の証明書ステータスチェックのためではなく（いずれかEAPピアまたはEAPサーバによって）EAPメソッド内で使用することができる証明書のために使用されることに留意されたいです。前節と同様に、次の図は、[のIKEv2]から抽出されます。この文書と[IKEv2の】に関するこれらの図の間に矛盾がある場合には、[のIKEv2]支配SHALL。
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} -->
(6) <-- HDR, SK {EAP (success)}
（6）< - HDR、SK {EAP（成功）}
(7) HDR, SK {AUTH} -->
（7）HDR、SK {AUTH} - >
(8) <-- HDR, SK {AUTH, SAr2, TSi, TSr }
（8）< - HDR、SK {AUTH、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）は、このドキュメントに関連しません。
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.
理由は上述したため、OCSP要求は、セクション3.1で定義されるように、生産及びOCSP応答の送信をトリガするためにOCSP要求構文の代わりに使用されます。 OCSPは、[RFC2560]で定義されるように、（詳細については[RFC2560]のセクション4.4.1を参照）、リプレイ攻撃に対するセキュリティを向上させるためにナンス要求拡張を含んでいてもよいです。この文書で定義された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の展開を注意深く評価するべきリプレイ攻撃を可能にします。リプレイ攻撃の可能性とその実行が成功に関連した費用に対して事前に計算された応答の利点。」ノードは、OCSP応答の必要な新鮮さは設定すべきです。
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.
このドキュメントでは、証明書ペイロードフォーマットのIKEv2の証明書Encodingフィールドでの使用のための1つの新しいフィールドタイプを定義します。 [IKEv2の]のセクション3.6の証明書符号化テーブルに「OCSPコンテンツ」拡張子の公式割り当てはIANAから取得されています。
Certificate Encoding Value
-------------------- -----
OCSP Content 14
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のレビューコメントを与えました。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、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.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
Authors' Addresses
著者のアドレス
Michael Myers TraceRoute Security LLC
マイケル・マイヤーズtracerouteのセキュリティLLC
EMail: mmyers@fastq.com
メールアドレス：mmyers@fastq.com
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigシーメンスネットワークス社＆CoのKGオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
電子メール：Hannes.Tschofenig@siemens.com URI：http://www.tschofenig.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、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, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。