[要約] RFC 4806は、IKEv2にOCSP拡張機能を追加するための規格です。目的は、IKEv2セッションのセキュリティを向上させ、証明書の状態をオンラインで確認することです。
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
オンライン証明書ステータスプロトコル（OCSP）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).
Copyright（c）The IETF Trust（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.
Internet Key Exchange Protocolバージョン2（IKEV2）は公開キーベースの認証をサポートしていますが、BoundのCRLサイズのために、バンド内証明書の取り消しリスト（CRL）の対応する使用は問題があります。ただし、オンライン証明書ステータスプロトコル（OCSP）応答のサイズは、十分に縛られており、小さいです。このドキュメントは、IKEV2の「OCSPコンテンツ」拡張機能を定義しています。「OCSPコンテンツ」を備えたCertreqペイロードは、ゼロ以下の信頼できるOCSP応答者を識別し、IKEV2ハンドシェイクにOCSP応答を含めるリクエストです。このようなリクエストの協同組合の受信者は、適切な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ピアの1つが関連するOCSPレスポンダーに直接アクセスすることを防ぎます。ファイアウォールは、多くの場合、エンタープライズネットワークの外側の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）プロトコル[IKEV2]のバージョン2は、公開キーベースの認証の使用など、さまざまな認証メカニズムをサポートしています。証明書の信頼性の確認は、公開キー暗号化が提供するセキュリティ保証を達成するために不可欠です。このような確認の基本的な要素の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.
ただし、CRLSはサイズがバウンドされていないことがあります。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.
取り消しデータへのアクセスには、IPSEC（したがってIKE）を使用してIKE参加者のCRLへの安全で承認されたアクセスを確立する必要がある場合、OOBメソッドへの依存がさらに複雑になる可能性があります。このようなネットワークアクセスのデッドロックは、盲目的な信頼を支持する証明書の取り消しのステータスへの依存度の低下にさらに貢献します。
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応答を含む証明書ペイロードで応答します。このコンテンツは、同じ「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応答とは、OCSPコンテンツと呼ばれる新しいコンテンツエンコーディングを含むCERTペイロードを指します。これは、セクション3.2で指定された定義と動作に準拠しています。
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 Responderは、証明書メッセージを送信する当事者を指すものではないことに注意してください。
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ペイロードの証明書エンコードフィールドの値は次のように拡張されます（このドキュメントの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ペイロードの証明書エンコードフィールドにおける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によって直接発行された特別にマークされた証明書を保持するCA指定レスポンダー（認定レスポンダー）は、そのCAのOCSP応答を発行する可能性があることを示しています
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）の場合、Certreqメッセージでのハッシュの使用は必要ありません。これは、OCSP応答が証明書を発行したCAによって署名されているためです。（c）の場合、OCSP応答は、Certreqメッセージの送信者が事前に公開キーを知らないCA指定レスポンダーによって署名されます。CertreqメッセージにOCSPコンテンツが存在すると、（b）の場合に送信者が信頼している1つ以上のOCSP応答者が識別されます。
The presence of OCSP Content (14) in a CERTREQ message:
certreqメッセージにおけるOCSPコンテンツの存在（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. 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ペイロードの証明書エンコードフィールドにおけるOCSPコンテンツの値（14）は、証明書ペイロードの証明書データフィールドに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応答の証明書を運ぶ対応する証明書のペイロードと、OCSP応答証明書フィールドを証明書に一致させることにより、対応する証明書ペイロードとの相関関係が実現できます。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.
したがって、上記のセクション3.1で定義されているOCSP要求は、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].
OCSPリクエストCertreqの認証機関の価値は、[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送信者は、[RFC3280]で定義されたPATH検証ロジックに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 Payloadを受信すると、受信者は関連するOCSPベースのアサーションを取得し、IKEV2ペイロードの署名を確認するために必要な証明書に対応するOCSP応答CERTペイロードを生産および送信する必要があります。
An OCSP response CERT payload is transmitted separate from any other CERT payload in an IKEv2 exchange.
OCSP応答証明書のペイロードは、IKEV2 Exchangeの他の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応答CERTペイロードの生産のためにOCSP応答を取得できる手段は、このドキュメントの範囲外です。
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}
(4) <-- HDR, SK {IDr, CERT(certificate), CERT(OCSP Response), AUTH, SAr2, TSi, TSr}
(4) <-hdr、sk {idr、cert（certificate）、cert（ocsp response）、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）では、Responderは、Responderが信頼しているゼロ以上のOCSPレスポンダーを識別するOCSPリクエストCertreqペイロードを送信します。これに応じて、イニシエーターは（3）証明書を運ぶ証明書のペイロードと、その証明書をカバーするOCSP応答証明書のペイロードの両方を送信します。（3）では、イニシエーターは、OCSPリクエストCertreqペイロードを介してOCSP応答も要求します。（4）では、レスポンダーは証明書とその証明書をカバーする個別のOCSP応答証明書のペイロードを返します。
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）の応答者はまだイニシエーターの証明書を所有していないため、[RFC2560]で定義されているOCSP要求を形成できないことに注意することが重要です。この問題をバイパスするために、ハッシュはセクション4.1で定義されているように使用されます。そのような場合、OCSPリクエストはこれらのデータへの単純なインデックス値です。したがって、OCSP応答は、対応する要求がない場合に生成できると簡単に推測できます（OCSP Noncesが使用されない場合は、セクション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.
また、このシナリオでIKEV2をOCSPに拡張することは重要です。イニシエーターは、レスポンダーが拡張機能に参加できることを意欲的であるという特定の知識を持っていることです。しかし、レスポンダーは1つ以上のOCSPレスポンダー署名のみを信頼します。これらの要因は、OCSP Responderハッシュ拡張の定義を動機付けます。
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.
差し迫った関心のもう1つのシナリオは、EAPを使用して、IPSECゲートウェイへのエンタープライズアクセスを求める複数のエンドユーザーに対応することです。OCSPは、EAPメソッド（EAPピアまたはEAPサーバーのいずれか）で使用できる証明書ではなく、サーバー側IKEV2証明書の証明書ステータスチェックに使用されることに注意してください。前のセクションと同様に、[IKEV2]から次の図を抽出します。このドキュメントと[IKEV2]の間にこれらの図に関して競合した場合、[IKEV2]が支配するものとします。
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)}
(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.
上記の理由により、セクション3.1で定義されているOCSP要求は、OCSPリクエスト構文の代わりに使用され、OCSP応答の生産と伝送をトリガーします。[RFC2560]で定義されているOCSPには、リプレイ攻撃に対するセキュリティを改善するためのNonCEリクエスト拡張機能が含まれている場合があります（詳細については、[RFC2560]のセクション4.4.1を参照）。このドキュメントで定義されたOCSP要求は、Noncesに対応できません。[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 CERTエンコードフィールドで使用する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.
著者は、彼の支援についてRuss Housleyに感謝したいと思います。さらに、Pasi Eronen、Nicolas Williams、Liqiang（Larry）Zhu、Lakshminath Dondeti、Paul Hoffmanのレビューに感謝します。Pasiは非常に貴重なラストコールコメントを与えてくれました。また、トム・テイラーのgen-artレビューに感謝します。Jari ArkkoはIESGレビューのコメントをくれました。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
Authors' Addresses
著者のアドレス
Michael Myers TraceRoute Security LLC
Michael Myers Traceroute Security LLC
EMail: mmyers@fastq.com
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Siemens Networks GmbH＆Co KG Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。