Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 5723 Check Point
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
January 2010
Internet Key Exchange Protocol Version 2 (IKEv2)
Session Resumption
Abstract
抽象
The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.
インターネットキー交換バージョン2（IKEv2）プロトコルが必要なラウンドトリップおよび関連暗号化操作の数に対して特定の計算および通信のオーバヘッドを有しています。リモートアクセス状況では、拡張認証プロトコル（EAP）は、さらにいくつかのラウンドトリップ、その結果待ち時間を追加認証するために使用されます。
To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.
障害回復条件にセキュリティアソシエーション（SA）を再確立することがIPsecピアは、（例えば、VPNゲートウェイなど）は、様々なエンドポイントとSAの再確立多数必要がある場合は特に時間がかかります。同時セッションの数が多いと、SAの再確立中にIPsecピアのための追加的な問題を引き起こす可能性があります。
In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.
最初から鍵交換プロトコルを再実行する必要性を避けるためには、IKE / IPsecのセッションを再開するための効率的な方法を提供することが有用であろう。この文書は、クライアントが以前に確立されたIKE SAを利用して、非常に効率的な方法でゲートウェイとIKE SAを再確立することを可能にするのIKEv2の拡張を提案します。
A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided.
クライアントは、それが切断されたゲートウェイに再接続することができます。提案されたアプローチは、クライアント上または中央ストアに格納することができ、以降の再認証のためのIKEv2レスポンダに利用可能にされる不透明なチケット、に部分IKE状態を符号化します。私たちは、IKEv2の応答者によって作成された不透明なデータを参照するために用語のチケットを使用しています。この文書では、チケットの形式を指定しませんが、例が提供されています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5723.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5723で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Usage Scenario ..................................................5
4. Protocol Sequences ..............................................7
4.1. Requesting a Ticket ........................................7
4.2. Receiving a Ticket .........................................8
4.3. Presenting a Ticket ........................................9
4.3.1. Prologue ............................................9
4.3.2. IKE_SESSION_RESUME Exchange ........................10
4.3.3. IKE_AUTH Exchange ..................................11
4.3.4. Epilogue ...........................................12
5. IKE and IPsec State after Resumption ...........................12
5.1. Generating Cryptographic Material for the Resumed IKE SA ..15
6. Ticket Handling ................................................16
6.1. Ticket Content ............................................16
6.2. Ticket Identity and Lifecycle .............................16
7. IKE Notifications ..............................................17
7.1. TICKET_LT_OPAQUE Notify Payload ...........................17
7.2. TICKET_OPAQUE Notify Payload ..............................18
8. IANA Considerations ............................................18
9. Security Considerations ........................................19
9.1. Stolen Tickets ............................................19
9.2. Forged Tickets ............................................19
9.3. Denial-of-Service Attacks .................................20
9.4. Detecting the Need for Resumption .........................20
9.5. Key Management for "Tickets by Value" .....................20
9.6. Ticket Lifetime ...........................................21
9.7. Tickets and Identity ......................................21
9.8. Ticket Revocation .........................................21
9.9. Ticket by Value Format ....................................21
9.10. Identity Privacy, Anonymity, and Unlinkability ...........22
10. Acknowledgements ..............................................22
11. References ....................................................23
11.1. Normative References .....................................23
11.2. Informative References ...................................23
Appendix A. Ticket Format ........................................25
A.1. Example "Ticket by Value" Format ..........................25
A.2. Example "Ticket by Reference" Format ......................25
The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In particular, the Extensible Authentication Protocol (EAP) is used for authentication in remote access cases, which increases latency.
インターネットキー交換バージョン2（IKEv2）プロトコルが必要なラウンドトリップおよび関連暗号化操作の数に対して特定の計算および通信のオーバヘッドを有しています。具体的には、拡張認証プロトコル（EAP）は、待ち時間を増加させる、リモートアクセスの場合に、認証のために使用されます。
To re-establish security associations (SAs) upon a failure recovery condition is time-consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec responder. Usability is also affected when the re-establishment of an IKE SA involves user interaction for re-authentication.
障害回復条件にセキュリティアソシエーション（SA）を再確立することがIPsecピアは、そのようなVPNゲートウェイとして、種々のエンドポイントとSAの再確立多数する必要が場合は特に、時間がかかります。同時セッションの数が多いは、IPsec応答者のための追加的な問題を引き起こす可能性があります。 IKE SAの再確立は、再認証のためにユーザ対話を伴う場合ユーザビリティにも影響されます。
In many failure cases, it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.
多くの失敗例では、中断されたIKE / IPsecのセッションを再開するための効率的な方法を提供することが有用であろう。この文書は、クライアントが以前に確立されたIKE SAを利用して、非常に効率的な方法でゲートウェイとIKE SAを再確立することを可能にするのIKEv2の拡張を提案します。
The client (IKEv2 initiator) stores the state about the previous IKE SA locally. The gateway (IKEv2 responder) has two options for maintaining the IKEv2 state about the previous IKE SA:
クライアント（IKEv2のイニシエータ）は、ローカルに、前のIKE SAについての状態を保存します。ゲートウェイ（IKEv2のレスポンダ）は、前のIKE SAについてのIKEv2状態を維持するための2つのオプションがあります。
o In the "ticket by reference" approach, the gateway stores the state locally, and gives the client a protected and opaque reference (e.g., an index to the gateway's table) that the gateway can later use to find the state. The client includes this opaque reference when it resumes the session.
O「チケット参照によって」アプローチでは、ゲートウェイは、ローカル状態を格納し、クライアントを保護し、不透明な基準を与える（例えば、ゲートウェイのテーブルへのインデックス）ゲートウェイが後の状態を検索するために使用することができます。クライアントは、それがセッションを再開したときに、この不透明な参照を含んでいます。
o In the "ticket by value" approach, the gateway stores its state in a ticket (data structure) that is encrypted and integrity-protected by a key known only to the gateway. The ticket is passed to the client (who treats the ticket as an opaque string) and sent back to the gateway when the session is resumed. The gateway can then decrypt the ticket and recover the state.
「チケット値によって」アプローチでは、ゲートウェイは、チケットにその状態を記憶O（データ構造）暗号化のみゲートウェイに知られている鍵によって完全性保護されています。チケットは、（不透明な文字列としてチケットを扱います）クライアントに渡され、セッションが再開されたゲートウェイに送り返されます。ゲートウェイは、チケットを復号化し、状態を回復することができます。
Note that the client behaves identically in both cases, and in general does not know which approach the gateway is using. Since the ticket (or reference) is only interpreted by the same party that created it, this document does not specify the exact format for it. However, Appendix A contains examples for both "ticket by reference" and "ticket by value" formats.
クライアントは両方のケースで同じ動作することに注意してください、と一般的にゲートウェイが使用されているアプローチを知りません。チケット（または参照）が唯一、それを作成したのと同じパーティによって解釈されているので、この文書では、それのための正確な形式を指定しません。しかし、付録A「は、参照することにより、チケット」と「チケット値で」形式の両方のための例が含まれています。
This approach is similar to the one taken by Transport Layer Security (TLS) session resumption [RFC5077] with the required adaptations for IKEv2, e.g., to accommodate the two-phase protocol structure. We have borrowed heavily from that specification.
このアプローチは、二相のプロトコル構造を収容するために、例えば、IKEv2のために必要な適応を有するトランスポート層セキュリティ（TLS）セッションを再開[RFC5077]で撮影されたものと同様です。私たちは、その仕様から重く借りてきました。
The proposed solution should additionally meet the following goals:
提案された解決策は、さらに次の目標を満たしている必要があります。
o Using only symmetric cryptography to minimize CPU consumption.
CPUの消費を最小限に抑えるためにのみ対称暗号化を使用して、O。
o Providing cryptographic agility.
O暗号敏捷性を提供します。
o Having no negative impact on IKEv2 security features.
OのIKEv2セキュリティ機能に悪影響を持ちません。
The following are non-goals of this solution:
このソリューションの非目標は以下のとおりです。
o Failover from one gateway to another. This use case may be added in a future specification.
別のゲートウェイからOフェイルオーバー。このユースケースは、将来の仕様に加えてもよいです。
o Providing load balancing among gateways.
ゲートウェイ間で負荷分散を提供し、O。
o Specifying how a client detects the need for resumption.
クライアントは、再開の必要性を検知する方法を指定するO。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document uses terminology defined in [RFC4301] and [RFC4306]. In addition, this document uses the following term:
この文書では、[RFC4301]と[RFC4306]で定義された用語を使用しています。また、この文書は、次の用語を使用しています：
Ticket: An IKEv2 ticket is a data structure that contains all the necessary information that allows an IKEv2 responder to re-establish an IKEv2 security association.
チケット：IKEv2のチケット再確立のIKEv2セキュリティアソシエーションにIKEv2のレスポンダを可能にするすべての必要な情報を含むデータ構造です。
In this document, we use the term "ticket" and thereby refer to an opaque data structure that may either contain IKEv2 state as described above or a reference pointing to such state.
この文書では、用語「チケット」を使用することにより、上述したようなIKEv2の状態を含むことができるいずれかの不透明なデータ構造またはそのような状態を指す参照を指します。
This specification envisions two usage scenarios for efficient IKEv2 and IPsec SA session re-establishment.
この仕様は、効率のIKEv2およびIPsec SAセッション再確立するための2つの使用シナリオを想定しています。
The first is similar to the use case specified in Section 1.1.3 of the IKEv2 specification [RFC4306], where the IPsec tunnel mode is used to establish a secure channel between a remote access client and a gateway; the traffic flow may be between the client and entities beyond the gateway. This scenario is further discussed below.
最初は、IPsecトンネルモードは、リモートアクセスクライアントとゲートウェイの間にセキュアチャネルを確立するために使用されるのIKEv2仕様[RFC4306]のセクション1.1.3で指定された使用の場合と同様です。トラフィックフローは、ゲートウェイを超えたクライアントとエンティティの間であってもよいです。このシナリオは、以下でさらに説明されます。
The second use case focuses on the usage of transport (or tunnel) mode to secure the communicate between two endpoints (e.g., two servers). The two endpoints have a client-server relationship with respect to a protocol that runs using the protections afforded by the IPsec SA.
第2の使用ケースは、2つのエンドポイント（例えば、二つのサーバ）との間で通信を確保するためにトランスポート（又はトンネル）モードの使用に焦点を当てています。 2つのエンドポイントは、IPsec SAによって与えられる保護を使用して実行したプロトコルに関して、クライアント - サーバ関係を持っています。
(a)
（A）
+-+-+-+-+-+ +-+-+-+-+-+
| | IKEv2/IKEv2-EAP | | Protected
| Remote |<------------------------>| | Subnet
| Access | | Access |<--- and/or
| Client |<------------------------>| Gateway | Internet
| | IPsec tunnel | |
+-+-+-+-+-+ +-+-+-+-+-+
(b)
（B）
+-+-+-+-+-+ +-+-+-+-+-+
| | IKE_SESSION_RESUME | |
| Remote |<------------------------>| |
| Access | | Access |
| Client |<------------------------>| Gateway |
| | IPsec tunnel | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 1: Resuming a Session with a Remote Access Gateway
図1：リモートアクセスゲートウェイとのセッションを再開
In the first use case above, an end host (an entity with a host implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA with a gateway in a remote network using IKEv2. The end host in this scenario is sometimes referred to as a remote access client. At a later stage, when a client needs to re-establish the IKEv2 session, it may choose to establish IPsec SAs using a full IKEv2 exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1).
上記第一のユースケースでは、エンドホスト（のIPsecのホスト実装とエンティティ[RFC4301]）はのIKEv2を使用してリモートネットワーク内のゲートウェイとトンネルモードのIPsec SAを確立します。このシナリオでは、エンドホストは時々、リモートアクセスクライアントと呼ばれています。クライアントのIKEv2セッションを再確立する必要がある後の段階にて、それは完全のIKEv2交換又はIKE_SESSION_RESUME交換（図1に示されている）を使用してIPSec SAを確立することを選択することができます。
For either of the above use cases, there are multiple possible situations where the mechanism specified in this document could be useful. These include the following (note that this list is not meant to be exhaustive, and any particular deployment may not care about all of these): o If a client temporarily loses network connectivity (and the IKE SA times out through the liveness test facility, a.k.a. "dead peer detection"), this mechanism could be used to re-establish the SA with less overhead (network, CPU, authentication infrastructure) and without requiring user interaction for authentication.
上記ユースケースのいずれかのために、この文書で指定された機構は有用であり得る複数の可能な状況があります。これらには以下が含まれる（このリストは網羅的であることを意味するものではないことに注意して、任意の特定の配置は、これらのすべてを気にしない場合があります）：Oクライアントが一時的にアウトライブネステスト機能によってIKE SAの時間をネットワーク接続を失った（とした場合、別名「デッド・ピア検出」）は、このメカニズムは、より少ないオーバーヘッド（ネットワーク、CPU、認証基盤）と、認証のためにユーザ対話を必要とせずにSAを再確立するのに使用することができます。
o If the connectivity problems affect a large number of clients (e.g., a large remote access VPN gateway), when the connectivity is restored, all the clients might reconnect almost simultaneously. This mechanism could be used to reduce the load spike for cryptographic operations and authentication infrastructure.
接続の問題は、多数のクライアントに影響を与える場合には、O（例えば、大規模なリモートアクセスVPNゲートウェイ）接続が復元され、すべてのクライアントがほぼ同時に再接続するかもしれません。このメカニズムは、暗号化操作と認証インフラストラクチャの負荷スパイクを軽減するために使用することができます。
o Losing connectivity can also be predictable and planned; for example, putting a laptop to "stand-by" mode before traveling. This mechanism could be used to re-establish the SA when the laptop is switched back on (again, with less overhead and without requiring user interaction for authentication). However, such user-level "resumption" may often be disallowed by policy. Moreover, this document requires the client to destroy the ticket when the user explicitly "logs out" (Section 6.2).
O接続性を失うことも予測可能で計画することができます。例えば、「スタンドバイ」にするモード旅行前にラップトップを置きます。この機構は、ラップトップが（より少ないオーバーヘッドで、認証のためにユーザ対話を必要とせずに、再び）バックスイッチオンされるときにSAを再確立するのに使用することができます。しかし、そのようなユーザーレベルの「再開」しばしばポリシーで禁止することができます。また、この文書は（セクション6.2）、ユーザーが明示的に「ログアウト」ときチケットを破壊するためにクライアントが必要です。
This section provides protocol details and contains the normative parts. This document defines two protocol exchanges, namely requesting a ticket, see Section 4.1, and presenting a ticket, see Section 4.3.
このセクションでは、プロトコルの詳細を提供し、規範的な部品が含まれています。このドキュメントはすなわちチケットを要求して、2つのプロトコル交換を定義して、セクション4.1を参照してください、とチケットを提示し、4.3節を参照してください。
A client MAY request a ticket in the following exchanges:
クライアントは、次の交換でチケットを要求することができます。
o In an IKE_AUTH exchange, as shown in the example message exchange in Figure 2 below.
O IKE_AUTH交換は、以下の図2の例のメッセージ交換に示すように。
o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only when this exchange is initiated by the client).
CREATE_CHILD_SA交換中のO、IKE SAは（この交換は、クライアントによって開始されている場合のみ）リキーされたとき。
o In an Informational exchange at any time, e.g., if the gateway previously replied with an N(TICKET_ACK) instead of providing a ticket, or when the ticket lifetime is about to expire, or following a gateway-initiated IKE rekey. All such Informational exchanges MUST be initiated by the client.
ゲートウェイは、以前の代わりにチケットを提供する、またはチケットの有効期間が満了しようとしている場合、またはゲートウェイによって開始IKEの再入力を次のN（TICKET_ACK）と答え例えば、場合に、任意の時点での情報交換中のO。このようなすべての情報交換は、クライアントによって開始されなければなりません。
o While resuming an IKE session, i.e., in the IKE_AUTH exchange that follows an IKE_SESSION_RESUME exchange, see Section 4.3.3.
即ち、IKEセッションを再開しながらO、IKE_SESSION_RESUME交換を以下のIKE_AUTH交換において、セクション4.3.3を参照。
Normally, a client requests a ticket in the third message of an IKEv2 exchange (the first of IKE_AUTH). Figure 2 shows the message exchange for this typical case.
通常、クライアントは、IKEv2の交換（IKE_AUTHの第一）の第3のメッセージにチケットを要求します。図2は、この一般的な場合のメッセージ交換を示しています。
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr [, CERTREQ]
< - HDR、SAR1、KER、Nrの[、CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
HDR、SK {IDI、[CERT、] [CERTREQ、] [IDR、】AUTH、SAI2、をTSi、TSrを、N（TICKET_REQUEST）} - >
Figure 2: Example Message Exchange for Requesting a Ticket
図2：チケットを要求するための例のメッセージ交換
The notification payloads are described in Section 7. The above is an example, and IKEv2 allows a number of variants on these messages. Refer to [RFC4306] and [IKEV2-BIS] for more details on IKEv2.
通知ペイロードはセクション7上記に記載されている例であり、IKEv2のは、これらのメッセージの変異体の数を可能にします。 IKEv2の詳細については[RFC4306]と[IKEv2のビス]を参照。
When an IKEv2 responder receives a request for a ticket using the N(TICKET_REQUEST) payload, it MUST perform one of the following operations if it supports the extension defined in this document:
IKEv2のレスポンダがN（TICKET_REQUEST）ペイロードを使用してチケットの要求を受信すると、それは、この文書で定義された拡張機能をサポートしている場合、それは次のいずれかの操作を実行する必要があります。
o it creates a ticket and returns it with the N(TICKET_LT_OPAQUE) payload in a subsequent message towards the IKEv2 initiator. This is shown in Figure 3.
Oそれはチケットを作成し、IKEv2の開始に向けて、後続のメッセージ中のN（TICKET_LT_OPAQUE）ペイロードとそれを返します。これは、図3に示されています。
o it returns an N(TICKET_NACK) payload, if it refuses to grant a ticket for some reason.
それはいくつかの理由のためにチケットを付与することを拒否した場合、Oは、N（TICKET_NACK）ペイロードを返します。
o it returns an N(TICKET_ACK), if it cannot grant a ticket immediately, e.g., due to packet size limitations. In this case, the client MAY request a ticket later using an Informational exchange, at any time during the lifetime of the IKE SA.
Oそれが原因パケットサイズ制限のために、例えば、すぐにチケットを付与することができない場合は、N（TICKET_ACK）を返します。この場合、クライアントは後にIKE SAのライフタイム中に任意の時点で、情報交換を使用してチケットを要求することができます。
Regardless of this choice, there is no change to the behavior of the responder with respect to the IKE exchange, and the proper IKE response (e.g., an IKE_AUTH response or an error notification) MUST be sent.
かかわらず、この選択の、IKE交換に対する応答の挙動に変化がない、適切なIKE応答が（例えば、IKE_AUTH応答又はエラー通知）が送信されなければなりません。
The IKEv2 initiator receives the ticket and may accept it, provided the IKEv2 exchange was successful. The ticket may be used later with an IKEv2 responder that supports this extension. Figure 3 shows how the initiator receives the ticket.
IKEv2のイニシエータは、チケットを受け取り、それを受け入れることが、IKEv2の交換が成功した提供しました。チケットは、この拡張機能をサポートしているのIKEv2応答して後で使用することができます。図3は、イニシエータが、チケットを受け取る方法を示しています。
Initiator Responder
----------- -----------
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
TSr, N(TICKET_LT_OPAQUE) }
Figure 3: Receiving a Ticket
図3：チケットを受け取ります
When a multi-round-trip IKE_AUTH exchange is used, the N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST only be returned in the final IKE_AUTH response.
マルチ往復IKE_AUTH交換が使用される場合、N（TICKET_REQUEST）ペイロードは、最初のIKE_AUTH要求に含まれなければならない、及びN（TICKET_LT_OPAQUE）（またはTICKET_NACK / TICKET_ACK）が唯一の最終IKE_AUTH応答で返さなければなりません。
When the client accepts the ticket, it stores it in its local storage for later use, along with the IKE SA to which the ticket refers. Since the ticket itself is opaque to the client, the local storage MUST also include all items marked as "from the ticket" in the table of Section 5.
クライアントがチケットを受け入れる場合は、チケットが参照するIKE SAと一緒に、後で使用するために、ローカルストレージに格納します。チケット自体はクライアントに不透明であるので、ローカルストレージは、第5節の表中の「チケットから」とマークされたすべての項目をも含まなければなりません。
When the client wishes to recover from an interrupted session, it presents the ticket to resume the session. This section describes the resumption process, consisting of some preparations, an IKE_SESSION_RESUME exchange, an IKE_AUTH exchange and finalization.
クライアントが中断したセッションから回復したい場合は、セッションを再開するためにチケットを提示します。このセクションでは、いくつかの製剤、IKE_SESSION_RESUME交換、IKE_AUTH交換およびファイナライズからなる、再開処理について説明します。
It is up to the client's local policy to decide when the communication with the IKEv2 responder is seen as interrupted and the session resumption procedure is to be initiated.
それは中断され、セッションの再開手順が開始されるようなIKEv2応答側との通信が見たときに決定するクライアントのローカルポリシー次第です。
A client MAY initiate a regular (non-ticket-based) IKEv2 exchange even if it is in possession of a valid, unexpired ticket. A client MUST NOT present a ticket when it knows that the ticket's lifetime has expired.
クライアントは、それが有効で、期限が切れていないチケットを所持している場合でも、通常の（非チケットベース）のIKEv2交換を開始することができます。それは、チケットの有効期間が満了していることを知っているときに、クライアントは、チケットを提示してはなりません。
Tickets are intended for one-time use, i.e., a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected by a gateway. Note that a ticket is considered as used only when an IKE SA has been established successfully with it.
チケットは、1回の使用のために意図されている、すなわち、クライアントは、チケットを再利用してはいけません。再利用したチケットは、ゲートウェイによって拒否されるべきです。 IKE SAはそれで正常に確立されたときにのみ使用されるように、チケットが考慮されることに注意してください。
This document specifies a new IKEv2 exchange type called IKE_SESSION_RESUME whose value is 38. This exchange is equivalent to the IKE_SA_INIT exchange, and MUST be followed by an IKE_AUTH exchange. The client SHOULD NOT use this exchange type unless it knows that the gateway supports it (this condition is trivially true in the context of the current document, since the client always resumes into the same gateway that generated the ticket).
この文書では、値38であり、この交換は、IKE_SA_INIT交換に相当するIKE_SESSION_RESUMEと呼ばれる新しいのIKEv2交換タイプを指定し、IKE_AUTH交換が続かなければなりません。それはゲートウェイがそれをサポートしています（クライアントは常にチケットを生成し、同じゲートウェイに再開するので、この状態は、現在のドキュメントのコンテキストで自明真である）ことを知っていない限り、クライアントは、この交換タイプを使用しないでください。
Initiator Responder
----------- -----------
HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] -->
Figure 4: IKEv2 Initiator Wishes to Resume an IKE SA
図4：IKEv2のイニシエータは、IKE SAを再開することを希望
The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The initiator sets the SPIi (Security Parameter Index, Initiator) value in the HDR to a new, unique value and the SPIr value is set to 0.
HDRでの交換タイプを「IKE_SESSION_RESUME」に設定されています。イニシエータは新しい、ユニークな値にHDRでSPII（セキュリティパラメータインデックス、イニシエータ）の値を設定し、SPIR値が0に設定されています。
When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) payload, it MUST perform one of the following steps if it supports the extension defined in this document:
IKEv2のレスポンダがN（TICKET_OPAQUE）ペイロードを使用してチケットを受信したとき、それは、この文書で定義された拡張機能をサポートしている場合、それは次のいずれかの手順を実行する必要があります。
o If it is willing to accept the ticket, it responds as shown in Figure 5.
それはチケットを受け入れる場合には、図5に示すように、O、それが応答します。
o It responds with an unprotected N(TICKET_NACK) notification, if it rejects the ticket for any reason. In that case, the initiator should re-initiate a regular IKE exchange. One such case is when the responder receives a ticket for an IKE SA that has previously been terminated on the responder itself, which may indicate inconsistent state between the IKEv2 initiator and the responder. However, a responder is not required to maintain the state for terminated sessions.
それが何らかの理由でチケットを拒否した場合、Oは、保護されていないN（TICKET_NACK）通知で応答します。その場合には、開始剤は、通常のIKE交換を再開始すべきです。応答者は、以前のIKEv2イニシエータとレスポンダとの間の不整合な状態を示すことができる応答自体、上で終了したIKE SAのチケットを受け取ったときにそのような場合です。しかし、応答が終了したセッションの状態を維持するために必要とされていません。
Initiator Responder
----------- -----------
<-- HDR, Nr [,N+]
Figure 5: IKEv2 Responder Accepts the Ticket
図5：IKEv2のResponderはチケットを受け入れ
Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The responder copies the SPIi value from the request, and the SPIr value is set to a new, unique value.
ここでも、HDRでの交換タイプを「IKE_SESSION_RESUME」に設定されています。応答要求からコピーSPII値、およびSPIR値が新しい、ユニークな値に設定されています。
Where not specified otherwise, the IKE_SESSION_RESUME exchange behaves exactly like the IKE_SA_INIT exchange. Specifically:
特に指定がない場合は、IKE_SESSION_RESUME交換が正確にIKE_SA_INIT交換のように振る舞います。具体的に：
o The client MAY resume the IKE exchange from any IP address and port, regardless of its original address. The gateway MAY reject the resumed exchange if its policy depends on the client's address (although this rarely makes sense).
Oクライアントに関係なく、元のアドレスの、任意のIPアドレスとポートからのIKE交換を再開することができます。そのポリシーは、クライアントのアドレスに依存している場合（これはほとんど意味がありませんが）ゲートウェイが再開交換を拒否するかもしれません。
o The first message MAY be rejected in denial-of-service (DoS) situations, with the initiator instructed to send a cookie.
イニシエータがクッキーを送信するように指示してoを最初のメッセージは、サービス拒否（DoS）の状況で拒否されることがあります。
o Notifications normally associated with IKE_SA_INIT can be sent. In particular, NAT detection payloads.
O通常IKE_SA_INITに関連した通知が送信することができます。具体的には、NATの検出ペイロード。
o The client's NAT traversal status SHOULD be determined anew in IKE_SESSION_RESUME. If NAT is detected, the initiator switches to UDP encapsulation on port 4500, as per [RFC4306], Section 2.23. NAT status is explicitly not part of the session resumption state.
OクライアントのNATトラバーサル状態はIKE_SESSION_RESUMEに新たに決定されるべきです。 NATが検出された場合、イニシエータは、[RFC4306]に従って、ポート4500上のUDPカプセル化に切り替え、セクション2.23。 NAT状態が明示的にセッション再開状態の一部ではありません。
o The SPI values and Message ID fields behave similarly to IKE_SA_INIT.
O SPI値とメッセージIDフィールドは、IKE_SA_INITと同様に振る舞います。
Although the IKE SA is not fully valid until the completion of the IKE_AUTH exchange, the peers must create much of the SA state (Section 5) now. Specifically, the shared key values are required to protect the IKE_AUTH payloads. Their generation is described in Section 5.1.
IKE SAは、IKE_AUTH交換が完了するまで完全には有効ではありませんが、ピアは今SA状態（第5節）の多くを作成する必要があります。具体的には、共有キーの値は、IKE_AUTHペイロードを保護するために必要とされます。彼らの世代は、セクション5.1に記載されています。
Following the IKE_SESSION_RESUME exchange, the client MUST initiate an IKE_AUTH exchange, which is largely as specified in [RFC4306]. This section lists the differences and constraints compared to the base document.
IKE_SESSION_RESUME交換後、クライアントは[RFC4306]で指定されるように大部分であるIKE_AUTH交換を開始しなければなりません。このセクションでは、基本文書と比べて違いと制約を示しています。
The value of the AUTH payload is derived in a manner similar to the usage of IKEv2 pre-shared secret authentication:
AUTHペイロードの値のIKEv2事前共用秘密の認証の使用と同様に導出されます。
AUTH = prf(SK_px, <message octets>)
AUTH = PRF（SK_px、<メッセージオクテット>）
Each of the initiator and responder uses its own value for SK_px, namely SK_pi for the initiator and SK_pr for the responder. Both are taken from the newly generated IKE SA (Section 5.1).
イニシエータとレスポンダの各々は、応答のための開始剤とSK_prためSK_px、すなわちSK_piための独自の値を使用します。両方が新たに生成されたIKE SA（セクション5.1）から取られます。
The exact material to be signed is defined in Section 2.15 of [RFC4306].
署名されるべき正確な材料は、[RFC4306]のセクション2.15に定義されています。
The IDi value sent in the IKE_AUTH exchange MUST be identical to the value included in the ticket. A CERT payload MUST NOT be included in this exchange, and therefore a new IDr value cannot be negotiated (since it would not be authenticated). As a result, the IDr value sent (by the gateway, and optionally by the client) in this exchange MUST also be identical to the value included in the ticket.
IKE_AUTH交換に送られたのIDI値はチケットに含まれる値と同じでなければなりません。 CERTペイロードは、この交換に含んではいけませんので、新しいIDR値は、（それが認証されないため）に交渉することはできません。結果として、IDR値は、送信（ゲートウェイによって、および必要に応じてクライアントによって）この交換においても、チケットに含まれる値と同一でなければなりません。
When resuming a session, a client will typically request a new ticket immediately, so that it is able to resume the session again in the case of a second failure. The N(TICKET_REQUEST) and N(TICKET_LT_OPAQUE) notifications will be included in the IKE_AUTH exchange that follows the IKE_SESSION_RESUME exchange, with similar behavior to a ticket request during a regular IKE exchange, Section 4.1. The returned ticket (if any) will correspond to the IKE SA created per the rules described in Section 5.
セッションを再開すると、第2障害が発生した場合には、再びセッションを再開することができるように、クライアントは通常、すぐに新しいチケットを要求します。 N（TICKET_REQUEST）とN（TICKET_LT_OPAQUE）通知は、通常のIKE交換、4.1節中のチケット要求と同様の挙動とIKE_SESSION_RESUME交換を、以下のIKE_AUTH交換に含まれます。返されたチケットは、（もしあれば）第5節に記載ルールごとに作成されたIKE SAに対応することになります。
Following the IKE_AUTH exchange, a new IKE SA is created by both parties, see Section 5, and a Child SA is derived, per Section 2.17 of [RFC4306].
IKE_AUTH交換に続いて、新しいIKE SAは、第5節を参照してください、両当事者によって作成され、そして子供SAは、[RFC4306]のセクション2.17ごとに、導出されます。
When the responder receives a ticket for an IKE SA that is still active and if the responder accepts it (i.e., following successful completion of the IKE_AUTH exchange), the old SA SHOULD be silently deleted without sending a DELETE informational exchange. Consequently, all the dependent IPsec Child SAs are also deleted.
応答者がまだアクティブであると応答側がそれを受け入れる場合（すなわち、IKE_AUTH交換が正常に完了した後）IKE SAのチケットを受け取ると、古いSAは黙っDELETEの情報交換を送信せずに削除する必要があります。その結果、すべての依存のIPsec SAの子も削除されます。
During the resumption process, both peers create IKE and IPsec state for the resumed IKE SA. Although the SA is only completed following a successful IKE_AUTH exchange, many of its components are created earlier, notably the SA's crypto material (Section 5.1).
再開処理中に、両方のピアが再開IKE SAのIKEおよびIPsec状態を作り出します。 SAが唯一成功したIKE_AUTH交換以下完了しているが、その構成要素の多くは、特にSAの暗号材料（セクション5.1）、以前に作成されます。
When a ticket is presented, the gateway needs to obtain the ticket state. In case a "ticket by reference" was provided by the client, the gateway needs to resolve the reference in order to obtain this state. In case the client has already provided a "ticket by value", the gateway can parse the ticket to obtain the state directly. In either case, the gateway needs to process the ticket state in order to restore the state of the old IKE SA, and the client retrieves the same state from its local store.
チケットが提示されている場合、ゲートウェイは、チケットの状態を取得する必要があります。 「参照によるチケットは、」クライアントによって提供された場合、ゲートウェイは、この状態を得るために、参照を解決する必要があります。ケースでは、クライアントは既に「値によってチケット」を提供している、ゲートウェイは、直接状態を得るためにチケットを解析することができます。いずれの場合も、ゲートウェイは、古いIKE SAの状態を復元するために、チケットの状態を処理する必要がある、とクライアントは、そのローカルストアから同じ状態を取得します。
The following table describes the IKE and IPsec state of the peers after session resumption, and how it is related to their state before the IKE SA was interrupted. When the table mentions that a certain state item is taken "from the ticket", this should be construed as:
次の表は、セッション再開後のピアのIKEおよびIPsecの状態を説明し、IKE SAが中断された前に、それは彼らの状態に関係していますか。表は、特定の状態の項目が「チケットから」取り出されることに言及するとき、これは次のように解釈されるべきです。
o The client retrieves this item from its local store.
Oクライアントは、そのローカルストアからこのアイテムを取得します。
o In the case of "ticket by value", the gateway encodes this information in the ticket.
O「値によってチケット」の場合には、ゲートウェイは、チケットにこの情報を符号化します。
o In the case of "ticket by reference", the gateway fetches this information from the ticket store.
O「参照によってチケット」の場合には、ゲートウェイは、チケットストアからこの情報を取り出します。
+--------------------------------+----------------------------------+
| State Item | After Resumption |
+--------------------------------+----------------------------------+
| IDi | From the ticket (but must also |
| | be exchanged in IKE_AUTH). See |
| | also Note 1. |
| | |
| IDr | From the ticket (but must also |
| | be exchanged in IKE_AUTH). |
| | |
| Authentication method (PKI, | From the ticket. |
| pre-shared secret, EAP, | |
| PKI-less EAP [EAP-AUTH] etc.) | |
| | |
| Certificates (when applicable) | From the ticket, see Note 2. |
| | |
| Local IP address/port, peer IP | Selected by the client, see Note |
| address/port | 3. |
| | |
| NAT detection status | From new exchange. |
| | |
| SPIs | From new exchange, see Note 4. |
| | |
| Which peer is the "original | Determined by the initiator of |
| initiator"? | IKE_SESSION_RESUME. |
| | |
| IKE SA sequence numbers | Reset to 0 in |
| (Message ID) | IKE_SESSION_RESUME, and |
| | subsequently incremented |
| | normally. |
| | |
| IKE SA algorithms (SAr) | From the ticket. |
| | |
| IKE SA keys (SK_*) | The old SK_d is obtained from |
| | the ticket and all keys are |
| | refreshed, see Section 5.1. |
| | |
| IKE SA window size | Reset to 1. |
| | |
| Child SAs (ESP/AH) | Created in new exchange, see |
| | Note 6. |
| | |
| Internal IP address | Not resumed, but see Note 5. |
| | |
| Other Configuration Payload | Not resumed. |
| information | |
| | |
| Peer Vendor IDs | Not resumed, resent in new |
| | exchange if required. |
| | |
| Peer supports MOBIKE [RFC4555] | From new exchange. |
| | |
| MOBIKE additional addresses | Not resumed, should be resent by |
| | client if necessary. |
| | |
| Time until re-authentication | From new exchange (but ticket |
| [RFC4478] | lifetime is bounded by this |
| | duration). |
| | |
| Peer supports redirects | From new exchange. |
| [RFC5685] | |
+--------------------------------+----------------------------------+
Note 1: The authenticated peer identity used for policy lookups may not be the same as the IDi payload. This is possible when using certain EAP methods, see Section 3.5 of [RFC4718]. If these identities are indeed different, then the authenticated client identity MUST be included in the ticket. Note that the client may not have access to this value.
注1：ポリシー・ルックアップに使用される認証済みのピアのアイデンティティは、IDiをペイロードと同じでなくてもよいです。これは、特定のEAPメソッドを使用する場合に可能である、[RFC4718]のセクション3.5を参照します。これらのIDが実際に異なっている場合には、認証されたクライアントIDはチケットに含まれなければなりません。クライアントがこの値へのアクセスを持っていないことに注意してください。
Note 2: Certificates don't need to be stored if the peer never uses them for anything after the IKE SA is up; however, if they are needed, e.g., if exposed to applications via IPsec APIs, they MUST be stored in the ticket.
注2：IKE SAがアップした後、ピアは何のためにそれらを使用したことがない場合、証明書は保存する必要はありません。それらが必要な場合はIPsecのAPIを経由してアプリケーションに公開場合は、例えば、それらは、チケットに格納する必要があります。
Note 3: If the certificate has an iPAddress SubjectAltName, and the implementation requires it to match the peer's source IP address, the same check needs to be performed on session resumption and the required information saved locally or in the ticket.
注3：証明書は、IPアドレスのSubjectAltNameがあり、実装は、ピアの送信元IPアドレスと一致するように、それを必要とする場合、同じチェックがセッションの再開と、ローカルまたはチケットに保存され、必要な情報で実行する必要があります。
Note 4: SPI values of the old SA MAY be stored in the ticket, to help the gateway locate corresponding old IKE state. These values MUST NOT be used for the resumed SA.
注4：古いSAのSPI値は、ゲートウェイが古いIKEの状態を対応見つけやすくするために、チケットに格納されてもよいです。これらの値は、再開SAのために使用してはいけません。
Note 5: The client can request the address it was using earlier, and if possible, the gateway SHOULD honor the request.
注5：クライアントは、それが以前使用していたアドレスを要求することができ、そして可能ならば、ゲートウェイは、要求を尊重すべきです。
Note 6: Since information about Child SAs and configuration payloads is not resumed, IKEv2 features related to Child SA negotiation (such as IPCOMP_SUPPORTED, ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec [ROHCoIPsec] and configuration) aren't usually affected by session resumption.
注6：子供SASおよび構成ペイロードに関する情報が再開されないので、IKEv2のは、通常、セッションの再開によって影響されない（例えばIPCOMP_SUPPORTED、ESP_TFC_PADDING_NOT_SUPPORTED、ROHCオーバーのIPsec [ROHCoIPsec]と設定など）子SAのネゴシエーションに関連する機能。
IKEv2 features that affect only the IKE_AUTH exchange (including HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges [RFC4739], Elliptic Curve Digital Signature Algorithm (ECDSA) authentication [RFC4754], and the Online Certificate Status Protocol (OCSP) [RFC4806]) don't usually need any state in the IKE SA (after the IKE_AUTH exchanges are done), so resumption doesn't affect them.
通常は必要ありません（[RFC4739]、楕円曲線デジタル署名アルゴリズム（ECDSA）認証[RFC4754]、およびオンライン証明書状態プロトコル（OCSP）[RFC4806]、HTTP_CERT_LOOKUP_SUPPORTEDを含む複数の認証交換）のみIKE_AUTH交換に影響を与えるのIKEv2機能（IKE_AUTH交換が行われた後）IKE SAのいずれかの状態が、再開がそれらに影響を与えないように。
New IKEv2 features that are not covered by Note 6 or by the previous paragraph should specify how they interact with session resumption.
注6または前の段落でカバーされていない新しいのIKEv2機能は、彼らがセッション再開との対話方法を指定する必要があります。
The cryptographic material is refreshed based on the ticket and the nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED value is derived as follows:
暗号材料は、現在の為替から、チケットとナンス値、ニッケル、およびNrとに基づいて更新されます。次のように新しいSKEYSEED値が導出されます。
SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
SKEYSEED = PRF（SK_d_old、 "再開" |ニッケル| NR）
where SK_d_old is taken from the ticket. The literal string is encoded as 10 ASCII characters, with no NULL terminator.
どこSK_d_oldは、チケットから取得されます。文字列リテラルはありませんNULLターミネータで、10のASCII文字としてエンコードされます。
The keys are derived as follows, unchanged from IKEv2:
IKEv2のから、そのまま次のようにキーが導出されています。
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
where SPIi, SPIr are the SPI values created in the new IKE exchange.
SPII、SPIRは新しいIKE交換で作成したSPIの値です。
See [RFC4306] for the notation. "prf" is determined from the SA value in the ticket.
表記のために[RFC4306]を参照。 「PRFは、」チケットでSA値から決定されます。
When passing a "ticket by value" to the client, the ticket content MUST be integrity protected and encrypted.
クライアントに「値によってチケット」渡した場合、チケットの内容は、完全性が保護され、暗号化されなければなりません。
A "ticket by reference" does not need to be encrypted, as it does not contain any sensitive material, such as keying material. However, access to the storage where that sensitive material is stored MUST be protected so that only authorized access is allowed. We note that such a ticket is analogous to the concept of 'stub', as defined in [SA-SYNC], or the concept of a Session ID from TLS.
それは、このような材料を鍵として、機密情報が含まれていないとして、「参照によるチケット」、暗号化する必要はありません。唯一許可されたアクセスが許可されるように、しかし、その感光材料が保存されているストレージへのアクセスは保護されなければなりません。私たちは、[SA-SYNC]、またはTLSのセッションIDの概念で定義されているようなチケットは、「スタブ」の概念に似ていることに注意してください。
Although not strictly required for cryptographic protection, it is RECOMMENDED to integrity-protect the "ticket by reference". Failing to do so could result in various security vulnerabilities on the gateway side, depending on the format of the reference. Potential vulnerabilities include access by the gateway to unintended URLs (similar to cross-site scripting) or SQL injection.
厳密に暗号保護のために必要ではないが、それは整合性保護「参照してチケット」することをお勧めします。そうしないと、参照の形式に応じて、ゲートウェイ側で様々なセキュリティの脆弱性が生じる可能性があります。潜在的な脆弱性は、意図しない（クロスサイトスクリプティングと同様）URLまたはSQLインジェクションへのゲートウェイのアクセスを含みます。
When the state is passed by value, the ticket MUST encode all state information marked "from the ticket" in the table on Section 5. The same state MUST be stored in the ticket store, in the case of "ticket by reference".
状態が値によって渡される場合、チケットは同じ状態5節の表に「チケットから」マークされたすべての状態情報を符号化しなければならない「参照によってチケット」の場合には、チケットストアに格納されなければなりません。
A "ticket by value" MUST include a protected expiration time, which is an absolute time value and SHOULD correspond to the value included in the TICKET_LT_OPAQUE payload.
「値によるチケットは、」絶対時間値であり、TICKET_LT_OPAQUEペイロードに含まれる値に対応する必要があり、保護有効期限を含まなければなりません。
The "ticket by value" MUST additionally include a key identity field, so that keys for ticket encryption and authentication can be changed, and when necessary, algorithms can be replaced.
「値でチケットは、」別途ように、チケットの暗号化と認証のためのキーは変更することができ、必要なときに、アルゴリズムは、交換することができ、キーのIDフィールドを含まなければなりません。
Each ticket is associated with a single IKE SA. In particular, when an IKE SA is deleted by the client or the gateway, the client MUST delete its stored ticket. Similarly, when credentials associated with the IKE SA are invalidated (e.g., when a user logs out), the ticket MUST be deleted. When the IKE SA is rekeyed, the ticket is invalidated, and the client SHOULD request a new ticket. When a client does not follow these rules, it might present an invalid ticket to the gateway. See Section 9.8 for more about this issue.
各チケットは、単一のIKE SAに関連付けられています。具体的には、IKE SAは、クライアントまたはゲートウェイによって削除された場合、クライアントは、その保存されたチケットを削除しなければなりません。 IKE SAに関連付けられた証明書が無効化されている場合（ユーザがログアウトするときに、例えば、）同様に、チケットを削除しなければなりません。 IKE SAが再 - 合わせされた場合、チケットは無効化され、そしてクライアントが新しいチケットを要求すべきです。クライアントがこれらの規則に従わない場合は、ゲートウェイに無効なチケットを提示することがあります。この問題の詳細については、セクション9.8を参照してください。
The lifetime of the ticket sent by the gateway SHOULD be the minimum of the IKE SA lifetime (per the gateway's local policy) and its re-authentication time, according to [RFC4478]. Even if neither of these are enforced by the gateway, a finite lifetime MUST be specified for the ticket.
ゲートウェイによって送信されたチケットの有効期間は、[RFC4478]によれば、（ゲートウェイのローカルポリシーに従って）IKE SAの寿命とその再認証時間の最小値であるべきです。これらのどちらがゲートウェイによって強制されている場合でも、有限の寿命は、チケットを指定しなければなりません。
The key that is used to protect the ticket MUST have a lifetime that is significantly longer than the lifetime of an IKE SA.
チケットを保護するために使用されるキーは、IKE SAのライフタイムよりも有意に長い寿命を持っていなければなりません。
In normal operation, the client will request a ticket when establishing the initial IKE SA, and then every time the SA is rekeyed or re-established because of re-authentication.
通常の操作では、クライアントは、SAがリキーため、または再認証の再確立されるたびに、最初のIKE SAを確立するときにチケットを要求、およびます。
This document defines a number of notifications. The following Notify Message types have been assigned by IANA.
この文書は、通知の数を定義します。次のメッセージを通知タイプはIANAによって割り当てられています。
+-------------------+-------+-----------------+
| Notification Name | Value | Data |
+-------------------+-------+-----------------+
| TICKET_LT_OPAQUE | 16409 | See Section 7.1 |
| | | |
| TICKET_REQUEST | 16410 | None |
| | | |
| TICKET_ACK | 16411 | None |
| | | |
| TICKET_NACK | 16412 | None |
| | | |
| TICKET_OPAQUE | 16413 | See Section 7.2 |
+-------------------+-------+-----------------+
For all these notifications, the Protocol ID and the SPI Size fields MUST both be sent as 0.
これらすべての通知の場合、プロトコルIDとSPIサイズフィールドは両方0として送らなければなりません。
The data for the TICKET_LT_OPAQUE Notify payload consists of the Notify message header, a Lifetime field and the ticket itself. The four octet Lifetime field contains a relative time value, the number of seconds until the ticket expires (encoded as an unsigned integer, in network byte order).
TICKET_LT_OPAQUE通知ペイロードのデータは、通知メッセージのヘッダ、Lifetimeフィールドとチケット自体から成ります。チケットの有効期限が切れるまで、4つのオクテットのライフタイムフィールドは、（ネットワークバイト順に、符号なし整数として符号化）の相対的な時間値、秒数を含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| Reserved | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size = 0 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ticket ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TICKET_LT_OPAQUE Notify Payload
図6：TICKET_LT_OPAQUEペイロードを通知
The data for the TICKET_OPAQUE Notify payload consists of the Notify message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE payload, no lifetime value is included in the TICKET_OPAQUE Notify payload.
TICKET_OPAQUEためのデータは、ペイロードを通知する通知メッセージヘッダ、及びチケット自体から成ります。 TICKET_LT_OPAQUEペイロードとは異なり、寿命値は、ペイロードを通知TICKET_OPAQUEに含まれていません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| Reserved | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size = 0 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ticket ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TICKET_OPAQUE Notify Payload
図7：TICKET_OPAQUEペイロードを通知
Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME, whose value has been allocated from the "IKEv2 Exchange Types" registry.
4.3.2は、値が「IKEv2の交換タイプ」レジストリから割り当てられた新しいのIKEv2交換タイプ、IKE_SESSION_RESUMEを、定義されています。
Section 7 defines several new IKEv2 notifications whose Message Type values have been allocated from the "IKEv2 Notify Message Types - Status Types" registry.
レジストリ - 第7節は、そのメッセージタイプの値が「ステータスタイプのIKEv2は、メッセージタイプを通知する」から割り当てられたいくつかの新しいIKEv2の通知を定義します。
This section addresses security issues related to the usage of a ticket.
このセクションでは、チケットの使用に関連するセキュリティ問題に対処します。
A man in the middle may try to eavesdrop on an exchange to obtain a "ticket by value" and use it to establish a session with the IKEv2 responder. Since all exchanges where the client obtains a ticket are encrypted, this is only possible by listening in on a client's use of the ticket to resume a session. However, since the ticket's contents are encrypted and the attacker does not know the corresponding secret key, a stolen ticket cannot be used by an attacker to successfully resume a session. An IKEv2 responder MUST use strong encryption and integrity protection of the ticket to prevent an attacker from obtaining the ticket's contents, e.g., by using a brute force attack.
真ん中の男が「値によってチケット」を取得し、IKEv2の応答者とのセッションを確立するためにそれを使用するようにExchangeを盗聴しようとします。クライアントがチケットを取得し、すべてのやり取りは暗号化されているので、これはセッションを再開するために、チケットのクライアントの使用上で聴くことによってのみ可能です。チケットの内容が暗号化され、攻撃者が対応する秘密鍵を知らないので、盗まれたチケットが正常にセッションを再開するために、攻撃者によって使用することはできません。 IKEv2の応答者は、ブルートフォース攻撃を使用することにより、例えば、チケットの内容を取得する攻撃者を防ぐために、チケットの強力な暗号化と完全性保護を使用しなければなりません。
A "ticket by reference" does not need to be encrypted. When an adversary is able to eavesdrop on a resumption attempt, as described in the previous paragraph, then the "ticket by reference" may be obtained. A "ticket by reference" cannot be used by an attacker to successfully resume a session, for the same reasons as for a "ticket by value", namely because the attacker would not be able to prove, during IKE_AUTH, its knowledge of the secret part of the IKE state embedded in the ticket. Moreover, the adversary MUST NOT be able to resolve the ticket via the reference, i.e., access control MUST be enforced to ensure disclosure only to authorized entities.
「参照によるチケットは、」暗号化する必要はありません。敵が再開試行を盗聴することが可能である場合、前の段落で説明したように、次に「参照によるチケット」が得られてもよいです。 「参照によるチケットは、」攻撃者は、IKE_AUTHの間に、秘密の知識を証明することができないであろう、すなわちので、成功した「値でチケット」の場合と同様の理由により、セッションを再開するために、攻撃者によって使用することはできませんチケットに埋め込まれたIKE状態の一部。また、敵は、すなわち、アクセス制御のみ認可エンティティに開示を確実にするために実施されなければならない、参照を介してチケットを解決できてはいけません。
A malicious user could forge or alter a "ticket by value" in order to resume a session, to extend its lifetime, to impersonate as another user, or to gain additional privileges. This attack is not possible if the content of the "ticket by value" is protected using a strong integrity protection algorithm.
悪意のあるユーザーが偽造または、その寿命を延ばすために、別のユーザーとして偽装するために、または追加の権限を取得するために、セッションを再開するために、「値でチケット」を変更することができます。 「値でチケット」の内容は、強力な完全性保護アルゴリズムを使用して保護されている場合は、この攻撃はできません。
In the case of a "ticket by reference" an adversary may attempt to construct a fake "ticket by reference" to point to state information stored by the IKEv2 responder. This attack will fail because the adversary is not in possession of the keying material associated with the IKEv2 SA. As noted in Section 6.1, it is often useful to integrity-protect the "ticket by reference", too.
「参照によるチケット」の場合には、敵のIKEv2応答によって格納された状態情報を指すように、「参照によってチケット」偽を構築しようと試みることができます。敵がIKEv2のSAに関連付けられているの鍵材料を所持していないので、この攻撃は失敗します。 6.1節で述べたように、あまりにも、「参照によってチケット」整合性の保護に有用であることがしばしばあります。
An adversary could generate and send a large number of "tickets by value" to a gateway for verification. Such an attack could burden the gateway's CPU, and/or exhaust its memory with half-open IKE state. To minimize the possibility of such denial of service, ticket verification should be lightweight (e.g., using efficient symmetric key cryptographic algorithms).
敵は生成と検証のためのゲートウェイに「値でチケット」を大量に送信することができます。このような攻撃は負担ゲートウェイのCPU可能性、および/またはハーフオープンIKE状態でそのメモリを使い果たします。サービスのような拒否の可能性を最小限に抑えるために、チケット検証（例えば、効率的な対称鍵暗号アルゴリズムを用いて）軽量であるべきです。
When an adversary chooses to send a large number of "tickets by reference" then this may lead to an amplification attack as the IKEv2 responder is forced to resolve the reference to a ticket in order to determine that the adversary is not in possession of the keying material corresponding to the stored state or that the reference is void. To minimize this attack, the protocol to resolve the reference should be as lightweight as possible and should not generate a large number of messages.
敵は「参照によってチケット」の大規模な番号を送信することを選択した場合のIKEv2応答者が敵対者がキーを所持していないことを判定するために、チケットへの参照を解決することを余儀なくされたとして、これは、増幅攻撃につながる可能性材料保存された状態に対応するか、参照が無効です。この攻撃を最小限に抑えるために、参照を解決するためのプロトコルは、可能な限り軽量でなければならず、大量のメッセージを生成するべきではありません。
Note also that the regular IKEv2 cookie mechanism can be used to handle state-overflow DoS situations.
通常のIKEv2のクッキー機構が状態オーバーフローのDoS状況を処理するために使用できることにも注意してください。
Detecting when an old IKE SA is no longer usable and needs to be resumed is out of scope of the current document. However, clients are warned against implementing a more liberal policy than that used to detect failed IKE SAs (Section 2.4 of RFC 4306). In particular, untrusted messages MUST NOT be relied upon to make this decision.
古いIKE SAがもはや利用可能で、再開する必要があるときに検出しないと、現在の文書の範囲外です。ただし、クライアントは、それが失敗したIKE SAの（RFC 4306のセクション2.4）を検出するために使用されるよりも、より自由なポリシーを実装に対して警告しています。具体的には、信頼されていないメッセージは、この決定を行うために依存してはなりません。
A full description of the management of the keys used to protect the "ticket by value" is beyond the scope of this document. A list of RECOMMENDED practices is given below.
「値によってチケット」を保護するために使用されるキーの管理の完全な説明はこのドキュメントの範囲を超えています。推奨事項のリストは以下のとおりです。
o The keys should be generated securely following the randomness recommendations in [RFC4086].
キーは[RFC4086]で乱数推奨に従って確実に生成する必要があり、O。
o The keys and cryptographic protection algorithms should be at least 128 bits in strength.
O鍵暗号保護アルゴリズムは、強度が少なくとも128ビットであるべきです。
o The keys should not be used for any other purpose than generating and verifying tickets.
キーoを生成し、チケットを検証する以外の目的のために使用すべきではありません。
o The keys should be changed regularly.
キーoを定期的に変更する必要があります。
o The keys should be changed if the ticket format or cryptographic protection algorithms change.
チケット形式または暗号保護アルゴリズムが変更された場合、Oキーを変更する必要があります。
An IKEv2 responder controls the validity period of the state information by attaching a lifetime to a ticket. The chosen lifetime is based on the operational and security requirements of the environment in which this IKEv2 extension is deployed. The responder provides information about the ticket lifetime to the IKEv2 initiator, allowing it to manage its tickets.
IKEv2の応答者は、チケットに生涯を取り付けることにより、状態情報の有効期間を制御します。選ばれた寿命は、このIKEv2の拡張が展開されている環境の運用とセキュリティ要件に基づいています。応答者は、そのチケットを管理できるように、IKEv2のイニシエータにチケットの有効期間についての情報を提供します。
A ticket is associated with a certain identity, and MUST be managed securely on the client side. Section 6.2 requires that a ticket be deleted when the credentials associated with the ticket's identity are no longer valid, e.g., when a user whose credentials were used to create the SA logs out.
チケットは、特定のIDに関連付けられており、クライアント側で安全に管理されなければなりません。 6.2節では、チケットのIDに関連付けられた証明書が有効でなくなったときにその資格情報をユーザーがSAがログアウト作成するために使用されたとき、チケットは、例えば、削除されている必要があります。
A misbehaving client could present a ticket in its possession to the gateway resulting in session resumption, even though the IKE SA associated with this ticket had previously been deleted. This is disallowed by Section 6.2. This issue is unique to "ticket by value" cases, since a "ticket by reference" will have been deleted from the ticket store.
ふらちなクライアントはこのチケットに関連IKE SAが以前に削除されていたにも関わらず、セッションの再開が生じゲートウェイに保有してチケットを提示することができます。これは、6.2節で禁止されています。 「参照によるチケットは」チケット・ストアから削除されていますので、この問題は、「チケット値で」例に特有のものです。
To avoid this issue for "ticket by value", an Invalid Ticket List (ITL) may be maintained by the gateway, see [TOKENS]. This can be a simple blacklist of revoked tickets. Alternatively, [TOKENS] suggests to use Bloom Filters [Bloom70] to maintain the list in constant space. Management of such lists is outside the scope of the current document. Note that a policy that requires tickets to have shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.
「値でチケット」のために、この問題を回避するには、無効チケット一覧（ITL）は、ゲートウェイによって維持することができる、[トークンを参照してください。これは取り消さチケットのシンプルなブラックリストすることができます。あるいは、[トークン]ブルーム[Bloom70】一定の空間内リストを維持するためにフィルタを使用することを示唆しています。このようなリストの管理は、現在のドキュメントの範囲外です。 （例えば、1時間）短い寿命を持つようにチケットを要求するポリシーが大幅にこの問題を軽減することに注意してください。
The ticket's format is not defined by this document, since this is not required for interoperability. However, great care must be taken when defining a ticket format such that the requirements outlined in Section 6.1 are met. The "ticket by value" MUST have its integrity and confidentiality protected with strong cryptographic techniques to prevent a breach in the security of the system.
これは、相互運用性のために必要とされないので、チケットのフォーマットは、このドキュメントで定義されていません。 6.1節で概説した要件が満たされているように、チケットのフォーマットを定義するときしかし、細心の注意が払われなければなりません。 「値でチケット」は、完全性と機密性は、システムのセキュリティを侵害することを防止するために、強力な暗号化技術で保護されていなければなりません。
Since opaque state information is passed around between the IKEv2 initiator and the IKEv2 responder it is important that leakage of information, such as the identities of an IKEv2 initiator and a responder, MUST be avoided.
不透明な状態情報は、IKEv2のイニシエータとIKEv2の間で渡されるので、情報の漏洩は、このようなIKEv2イニシエータとレスポンダのアイデンティティとして、避けなければならないことが重要であるレスポンダ。
When an IKEv2 initiator presents a ticket as part of the IKE_SESSION_RESUME exchange, confidentiality is not provided for the exchange. There is thereby the possibility for an on-path adversary to observe multiple exchange handshakes where the same state information is used and therefore to conclude that they belong to the same communication endpoints.
IKEv2のイニシエータがIKE_SESSION_RESUME交換の一環としてチケットを提示すると、機密性は、交換のために提供されていません。同一の状態情報が使用され、したがって、それらは同じ通信エンドポイントに属していると結論付けるために、複数の交換ハンドシェークを観察するために、パス攻撃の可能性は、それによって存在します。
This document therefore requires that the ticket be presented to the IKEv2 responder only once; under normal circumstances (e.g., no active attacker), there should be no multiple use of the same ticket.
この文書では、したがって、チケットは一度だけのIKEv2応答者に提示されている必要があります。通常の状況下で（例えば、アクティブな攻撃者）は、同じチケットのない複数の利用があってはなりません。
We are not aware of additional security issues associated with ticket reuse: the protocol guarantees freshness of the generated crypto material even in such cases. As noted in Section 4.3.1, the gateway SHOULD prevent multiple uses of the same ticket. But this is only an extra precaution, to ensure that clients do not implement reuse. In other words, the gateway is not expected to cache old tickets for extended periods of time.
私たちは、チケットの再利用に関連する追加のセキュリティ上の問題を認識していません：プロトコルは、このような場合であっても発生した暗号材料の鮮度を保証します。セクション4.3.1で述べたように、ゲートウェイは、同じチケットの複数使用を防止するはずです。しかし、これは、クライアントが再利用を実装していないことを保証するために、唯一の余分な予防策です。言い換えれば、ゲートウェイは、長時間の古いチケットをキャッシュすることが期待されていません。
We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ Housely, Yoav Nir, Peny Yang, Sean Turner, and Tero Kivinen for their comments. We would like to particularly thank Florian Tegeler and Stjepan Gros for their implementation efforts and Florian Tegeler for a formal verification using the Casper tool set.
私たちは、彼らのコメントのためにポール・ホフマン、パシEronen、フロリアンTegeler、スティーブン・ケント、ショーン・シェン、暁明フー、ステパングロ、ダンハーキンズ、ラスHousely、ヨアフニール、Penyヤン、ショーン・ターナー、およびTERO Kivinenに感謝したいと思います。私たちは、特にキャスパーツールセットを使用して、フォーマル検証のためのフロリアンTegelerとステパングロその実施の努力のためのフロリアンTegelerに感謝したいと思います。
We would furthermore like to thank the authors of [SA-SYNC] (Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng, and Ke Xu) for their input on the stub concept.
我々はさらに、スタブ概念上の入力のために[SA-SYNC]（ヤン徐、Penyヤン、Yuanchen馬、ホイ鄧小平、および柯徐）の作者に感謝したいと思います。
We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad Muhanna, and Stephen Kent for their feedback regarding the "ticket by reference" concept.
私たちは、「チケット参照による」という概念に関する彼らのフィードバックのためにホイ鄧小、TERO Kivinen、Penyヤン、アフマドMuhanna、スティーブン・ケントに感謝したいと思います。
Vidya Narayanan and Lakshminath Dondeti coauthored several past versions of this document, and we acknowledge their significant contribution.
VidyaナラヤナンとLakshminath Dondetiは、このドキュメントのいくつかの過去のバージョンを共同執筆し、我々は彼らの重要な貢献を認めます。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[Bloom70] Bloom, B., "Space/time trade-offs in hash coding with allowable errors", Comm. ACM 13(7):422-6, July 1970.
【Bloom70]ブルーム、B.、Commの「許容誤差と符号化ハッシュの空間/時間のトレードオフ」。 ACM 13（7）：422から6、1970年7月。
[EAP-AUTH] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", Work in Progress, October 2009.
[EAP-AUTH] Eronen、P.、Tschofenig、H.、およびY.シェファー、 "IKEv2の中EAPのみの認証のための拡張"、進歩、2009年10月に作業。
[IKEV2-BIS] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol: IKEv2", Work in Progress, October 2009.
[IKEv2の-BIS]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコル：IKEv2の"、進歩、2009年10月に作業。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4478]ニール、Y.、RFC 4478、2006年4月 "インターネットキーエクスチェンジ（IKEv2の）プロトコルで繰り返さ認証"。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P.およびP.ホフマン、 "IKEv2の明確化および実装のガイドライン"、RFC 4718、2006年10月。
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006.
[RFC4739] Eronen、P.およびJ. Korhonen、 "インターネットキーエクスチェンジ（IKEv2の）プロトコルで複数の認証交換"、RFC 4739、2006年11月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
[RFC4754]フー、D.およびJ. Solinas、 "楕円曲線デジタル署名アルゴリズム（ECDSA）を使用してIKE及びIKEv2の認証"、RFC 4754、2007年1月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806]マイヤーズ、M.およびH. Tschofenig、 "IKEv2のにオンライン証明書状態プロトコル（OCSP）の拡張"、RFC 4806、2007年2月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、周、H.、Eronen、P.、およびH. Tschofenig、 "サーバー側の状態なしのトランスポート層セキュリティ（TLS）セッション再開"、RFC 5077、2008年1月。
[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.
[RFC5685] Devarapalli、V.およびK. Weniger、2009年11月、RFC 5685 "インターネット鍵交換プロトコルバージョン2（IKEv2の）ためのメカニズムをリダイレクト"。
[ROHCoIPsec] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)", Work in Progress, December 2009.
[ROHCoIPsec] Ertekin、E.、Christouの、C.、Jasani、R.、Kivinen、T.、およびC.ボルマン、 "IKEv2の拡張機能のIPsec（ROHCoIPsec）上でロバストヘッダ圧縮をサポートするために"、進歩、2009年12月の作業。
[SA-SYNC] Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA Synchronization for session resumption", Work in Progress, October 2008.
[SA-SYNC]徐、Y.、ヤン、P.、馬、Y.、鄧小平、H.、およびH.鄧小、進歩、2008年10月に、ワーク "のIKEv2 SAの同期セッションの再開のために"。
[TOKENS] Rescorla, E., "How to Implement Secure (Mostly) Stateless Tokens", Work in Progress, March 2007.
、進歩、2007年3月に仕事を "セキュア（主に）ステートレストークンを実装する方法" [TOKENS]レスコラ、E.、。
Appendix A. Ticket Format
付録A.チケットフォーマット
This document does not specify a particular ticket format nor even the suggested contents of a ticket: both are entirely up to the implementer. The formats described in the following sub-sections are provided as useful examples, and implementers are free to adopt them as-is or change them in any way necessary.
この文書は、特定のチケットフォーマットやチケットのも、提案内容を指定していません：両方が完全に実装次第です。以下のサブセクションで説明フォーマットは有用な例として提供され、実装者は、あるとしてそれらを採用するか、必要な任意の方法でそれらを変更することは自由です。
A.1. Example "Ticket by Value" Format
A.1。例「チケットバリューによる」フォーマット
struct {
[authenticated] struct {
octet format_version; // 1 for this version of the protocol
octet reserved[3]; // sent as 0, ignored by receiver.
octet key_id[8]; // arbitrary byte string
opaque IV[0..255]; // actual length (possibly 0) depends
// on the encryption algorithm
[encrypted] struct {
opaque IDi, IDr; // the full payloads
octet SPIi[8], SPIr[8];
opaque SA; // the full SAr payload
octet SK_d[0..255]; // actual length depends on SA value
enum ... authentication_method;
int32 expiration; // an absolute time value, seconds
// since Jan. 1, 1970
} ikev2_state;
} protected_part;
opaque MAC[0..255]; // the length (possibly 0) depends
// on the integrity algorithm
} ticket;
Note that the key defined by "key_id" determines the encryption and authentication algorithms used for this ticket. Those algorithms are unrelated to the transforms defined by the SA payload.
「のkey_id」によって定義されたキーが、このチケットのために使用される暗号化および認証アルゴリズムを決定することに注意してください。これらのアルゴリズムは、SAペイロードによって定義された変換とは無関係です。
The reader is referred to [TOKENS] that recommends a similar (but not identical) ticket format, and discusses related security considerations in depth.
読者は、同様の（しかし同一ではない）チケットフォーマットを推奨し、そして深さに関連するセキュリティ問題を議論[TOKENS]と呼ばれます。
A.2. Example "Ticket by Reference" Format
A.2。例「チケット参照による」フォーマット
For implementations that prefer to pass a reference to IKE state in the ticket, rather than the state itself, we suggest the following format:
チケットでのIKEの状態を参照するのではなく、状態自体を渡すことを好むの実装のために、私たちは次の形式を提案します：
struct {
[authenticated] struct {
octet format_version; // 1 for this version of the protocol
octet reserved[3]; // sent as 0, ignored by receiver.
octet key_id[8]; // arbitrary byte string
struct {
opaque state_ref; // reference to IKE state
int32 expiration; // an absolute time value, seconds
// since Jan. 1, 1970
} ikev2_state_ref;
} protected_part;
opaque MAC[0..255]; // the length depends
// on the integrity algorithm
} ticket;
Authors' Addresses
著者のアドレス
Yaron Sheffer Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 67897 Israel
ヤロンシェファーは、ポイント・ソフトウェア・テクノロジーズ株式会社5 Hasolelim聖テルアビブ67897イスラエルをチェック
EMail: yaronf@checkpoint.com
メールアドレス：yaronf@checkpoint.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at