[要約] RFC 5723は、IKEv2セッションの再開に関するプロトコルであり、セッションの再開を効率的かつ安全に行うための仕様を提供しています。目的は、セッションの再開を容易にし、通信のパフォーマンスを向上させることです。
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
インターネットキー交換プロトコルバージョン2（IKEV2）セッション再開
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.
Internet Key Exchangeバージョン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.
障害回復条件でセキュリティ協会（SAS）を再確立するには、特に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.
クライアントは、切断されたゲートウェイに再接続できます。提案されたアプローチは、部分的なIKE状態を不透明なチケットにエンコードします。これは、クライアントまたは集中型の店舗に保存でき、後にIKEV2レスポンダーが再認可のために利用できるようになります。チケットという用語を使用して、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
Internet Key Exchangeバージョン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.
特にVPNゲートウェイなどのIPSECピアがさまざまなエンドポイントを持つ多くのSAを再確立する必要がある場合、障害回復条件でセキュリティ協会（SAS）を再確立することは時間がかかります。多数の同時セッションは、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 Responder）には、以前の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 「Value by Value」アプローチでは、ゲートウェイは、ゲートウェイのみが知られているキーによって暗号化され、整合性で保護されているチケット（データ構造）に状態を保存します。チケットはクライアント（チケットを不透明な文字列として扱う）に渡され、セッションが再開されたときにゲートウェイに送り返されます。その後、ゲートウェイはチケットを復号化し、状態を回復できます。
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.
このアプローチは、2相プロトコル構造に対応するためにIKEV2に必要な適応を伴う、トランスポートレイヤーセキュリティ（TLS）セッション再開[RFC5077]によって採用されたアプローチと類似しています。私たちはその仕様から大きく借りました。
The proposed solution should additionally meet the following goals:
提案されたソリューションは、さらに次の目標を満たす必要があります。
o Using only symmetric cryptography to minimize CPU consumption.
o 対称暗号のみを使用して、CPU消費を最小限に抑えます。
o Providing cryptographic agility.
o 暗号化の敏ility性を提供します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
1つ目は、IKEV2仕様[RFC4306]のセクション1.1.3で指定されたユースケースに似ています。ここでは、IPSECトンネルモードを使用して、リモートアクセスクライアントとゲートウェイの間に安全なチャネルを確立します。トラフィックフローは、クライアントとゲートウェイを越えたエンティティの間にある場合があります。このシナリオについては、以下でさらに説明します。
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つのサーバーなど）間で通信を保護するための輸送（またはトンネル）モードの使用に焦点を当てています。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).
上記の最初のユースケースでは、ENDホスト（IPSECのホスト実装[RFC4301]のホスト実装を持つエンティティ）が、IKEV2を使用してリモートネットワークにゲートウェイを備えたトンネルモードIPSEC SAを確立します。このシナリオのエンドホストは、リモートアクセスクライアントと呼ばれることもあります。後の段階では、クライアントがIKEV2セッションを再確立する必要がある場合、完全なIKEV2 ExchangeまたはIKE_SESSION_RESUME Exchangeを使用してIPSEC SASを確立することを選択できます（図1を参照）。
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がLivension Test Facilityを介して時間を出した場合、a.k.a.「Dead Peer Detection」）、このメカニズムは、オーバーヘッド（ネットワーク、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 以下の図2のメッセージ交換の例に示すように、IKE_AUTH交換で。
o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only when this exchange is initiated by the client).
o create_child_sa Exchangeでは、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.
o たとえば、情報交換では、たとえば、ゲートウェイがチケットを提供する代わりに以前にn（ticke_ack）で返信した場合、またはチケットの寿命が期限切れになっている場合、またはゲートウェイによって誘発されたIke Rekeに従っている場合。そのような情報交換はすべて、クライアントによって開始されなければなりません。
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.
o IKEセッションの再開中、つまりIKE_SESSION_RESUME Exchangeに続くIKE_AUTH Exchangeで、セクション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 Exchange（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)} -->
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-BIS]を参照してください。
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（ticke_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 Exchangeが成功した場合に受け入れることがあります。チケットは、この拡張機能をサポートする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 Exchangeを使用する場合、N（Ticke_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 Exchange、IKE_AUTH Exchange、および最終化で構成される再開プロセスについて説明します。
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 Exchangeを開始できます。クライアントは、チケットの寿命が切れていることを知っている場合、チケットを提示してはなりません。
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_SESSION_RESUMEと呼ばれる新しいIKEV2 Exchangeタイプを指定します。この交換はIKE_SA_INIT Exchangeに相当し、IKE_AUTH Exchangeが続く必要があります。クライアントは、ゲートウェイがサポートしていることを知らない限り、この交換タイプを使用しないでください（この条件は、クライアントが常にチケットを生成した同じゲートウェイに再開するため、現在のドキュメントのコンテキストでは些細なことです）。
Initiator Responder
----------- -----------
HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] -->
Figure 4: IKEv2 Initiator Wishes to Resume an IKE SA
図4：IKEV2イニシエーターは、IKESAを再開したい
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 ResponderがN（Ticket_Opaque）ペイロードを使用してチケットを受け取った場合、このドキュメントで定義されている拡張機能をサポートする場合、次の手順のいずれかを実行する必要があります。
o If it is willing to accept the ticket, it responds as shown in Figure 5.
o チケットを受け入れる意思がある場合、図5に示すように応答します。
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交換を再開する必要があります。そのようなケースの1つは、ResponderがResponder自体で以前に終了したIKE SAのチケットを受け取った場合です。ただし、終了セッションのために州を維持するためにレスポンダーは必要ありません。
Initiator Responder
----------- -----------
<-- HDR, Nr [,N+]
Figure 5: IKEv2 Responder Accepts the Ticket
図5：IKEV2レスポンダーはチケットを受け入れます
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」に設定されています。Responderは、リクエストからSPII値をコピーし、SPIR値は新しいユニークな値に設定されます。
Where not specified otherwise, the IKE_SESSION_RESUME exchange behaves exactly like the IKE_SA_INIT exchange. Specifically:
それ以外の場合は指定されていない場合、IKE_SESSION_RESUME ExchangeはIKE_SA_INIT Exchangeとまったく同じように動作します。具体的には：
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 Exchangeを再開できます。ゲートウェイは、そのポリシーがクライアントのアドレスに依存している場合、再開された交換を拒否する場合があります（ただし、これはめったに意味がありません）。
o The first message MAY be rejected in denial-of-service (DoS) situations, with the initiator instructed to send a cookie.
o 最初のメッセージは、サービス拒否（DOS）の状況で拒否される場合があり、イニシエーターはCookieを送信するように指示されます。
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]、セクション2.23に従って、ポート4500のUDPカプセル化に切り替えます。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 Exchangeが完了するまで完全には有効ではありませんが、ピアは現在、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 Exchangeに続いて、クライアントは[RFC4306]で指定されているとおりであるIKE_AUTH Exchangeを開始する必要があります。このセクションには、ベースドキュメントと比較した違いと制約をリストします。
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>)
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_PXに独自の値、つまりイニシエーターのSK_PI、ResponderにSK_PRを使用します。どちらも新しく生成された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 Exchangeで送信されたIDI値は、チケットに含まれる値と同一でなければなりません。この交換には、証明書のペイロードを含めるべきではないため、新しい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（ticke_lt_opaque）通知は、ike_session_resume Exchangeに続くike_auth Exchangeに含まれます。返されたチケット（もしあれば）は、セクション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 Exchangeに続いて、新しいIKE SAが両方の当事者によって作成され、セクション5を参照し、[RFC4306]のセクション2.17に従って、子SAが導出されます。
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 SAのチケットを受け取った場合、レスポンダーがそれを受け入れる場合（つまり、IKE_AUTH Exchangeの正常に完了した後）、古いSAは削除情報交換を送信せずに静かに削除する必要があります。したがって、すべての従属IPSECの子SASも削除されます。
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 Exchangeの成功後にのみ完了しますが、そのコンポーネントの多くは以前に作成されます。特に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をチケットに含める必要があります。クライアントはこの値にアクセスできない場合があることに注意してください。
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：証明書にiPaddressの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は子SAの交渉に関連する機能（IPComp_Supported、ESP_TFC_PADDING_NOT_SUPPORTED、ROHCOVER-IPSEC [ROHCOIPSEC]および構成）に関連しています。
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.
IKEV2機能は、IKE_AUTH Exchange（http_cert_lookup_supported、複数の認証交換[RFC4739]、楕円曲線デジタル署名アルゴリズム（ECDSA）認証[RFC4754]、およびオンライン証明書ステータスプロトコル（OCSSP）[RFC4806]）[RFC4806]を必要としない[RFC4754]を含む[RFC4754]を含む[RFC4754]、IKE SAのどの状態（IKE_AUTH交換が完了した後）であるため、再開はそれらに影響しません。
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:
暗号化資料は、現在の交換からチケットとNonCE値Ni、およびNRに基づいて更新されます。新しいskeyseed値は次のように導き出されます。
SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr)
skeyseed = prf（sk_d_old、 "再開" | ni | 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は、新しいIKE Exchangeで作成された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.
各チケットは、単一のIKESAに関連付けられています。特に、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 Lifetime（Gatewayのローカルポリシーごと）の最小値とその再認証時間である必要があります。これらのいずれもゲートウェイによって実施されていなくても、チケットに有限の寿命を指定する必要があります。
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.
通常の操作では、クライアントは最初のIKE SAを確立するときにチケットをリクエストし、その後、再認証のために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通知ペイロードのデータは、Notifyメッセージヘッダー、生涯フィールド、チケット自体で構成されています。4 Octet Lifetimeフィールドには、チケットの有効期限が切れるまでの秒数の相対的な時間値が含まれています（ネットワークバイトの順序で署名されていない整数としてエンコード）。
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 Notify Payloadのデータは、Notifyメッセージヘッダーとチケット自体で構成されています。ticket_lt_opaqueペイロードとは異なり、ticket_opaque Notify Payloadに生涯値は含まれていません。
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 Exchangeタイプ」レジストリから値が割り当てられている新しいIKEV2 Exchange Typeである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レスポンダーとのセッションを確立するために、交換を盗聴しようとすることができます。クライアントがチケットを取得するすべての交換は暗号化されているため、これはクライアントがセッションを再開するためにチケットを使用していることを聞くことによってのみ可能です。ただし、チケットのコンテンツは暗号化されており、攻撃者は対応する秘密キーを知らないため、攻撃者が盗まれたチケットを使用してセッションを正常に再開することはできません。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 Cookieメカニズムを使用して、状態オーバーフロー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 SAS（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].
o [RFC4086]のランダム性の推奨事項に従って、キーを安全に生成する必要があります。
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.
チケットは特定の身元に関連付けられており、クライアント側で安全に管理する必要があります。セクション6.2では、チケットの身元に関連付けられた資格情報がもはや有効でない場合、たとえば、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）が維持される場合があります。[Tokens]を参照してください。これは、取り消されたチケットのシンプルなブラックリストになる可能性があります。あるいは、[Tokens]は、Bloom Filters [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 Exchangeの一部としてチケットを提示する場合、交換用の機密性は提供されません。それにより、同じ状態情報が使用されている複数の交換ハンドシェイクを観察し、したがって、それらが同じ通信エンドポイントに属していると結論付ける可能性があります。
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レスポンダーに1回だけ表示する必要があります。通常の状況では（アクティブな攻撃者はいません）、同じチケットの複数の使用は必要ありません。
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.
Paul Hoffman、Pasi Eronen、Florian Tegeler、Stephen Kent、Sean Shen、Xiaoming Fu、Stjepan Gros、Dan Harkins、Russ Housely、Yoav Nir、Peny Yang、Sean Turner、Tero Kivinenのコメントに感謝します。Florian TegelerとStjepan Grosの実装活動について、Casper Tool Setを使用した正式な検証については、Florian 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]（Yan Xu、Peny Yang、Yuanchen MA、Hui Deng、Ke Xu）の著者に、スタブコンセプトへの入力について感謝したいと思います。
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.
Hui Deng、Tero Kivinen、Peny Yang、Ahmad Muhanna、およびStephen Kentに、「参照によるチケット」の概念に関するフィードバックに感謝します。
Vidya Narayanan and Lakshminath Dondeti coauthored several past versions of this document, and we acknowledge their significant contribution.
Vidya NarayananとLakshminath Dondetiは、この文書の過去のいくつかのバージョンを共著し、彼らの重要な貢献を認めています。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（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] Bloom、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. Sheffer、「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] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocol：IKEV2」、2009年10月の作業。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4478] NIR、Y。、「インターネットキーエクスチェンジ（IKEV2）プロトコルでの繰り返し認証」、RFC 4478、2006年4月。
[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. Hoffman、「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] Fu、D。およびJ. Solinas、「IkeおよびIKEV2認証楕円曲線デジタル署名アルゴリズム（ECDSA）」、RFC 4754、2007年1月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806] Myers、M。およびH. Tschofenig、「オンライン証明書ステータスプロトコル（OCSP）IKEV2への拡張」、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.、Zhou、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、「インターネットキー交換プロトコルバージョン2（IKEV2）のリダイレクトメカニズム」、RFC 5685、2009年11月。
[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. Bormann、「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] Xu、Y.、Yang、P.、Ma、Y.、Deng、H。、およびH. Deng、「セッション再開のためのIKEV2 SA同期」、2008年10月の作業。
[TOKENS] Rescorla, E., "How to Implement Secure (Mostly) Stateless Tokens", Work in Progress, March 2007.
[Tokens] Rescorla、E。、「Secure（ほとんど）Stateless Tokensを実装する方法」、2007年3月、進行中の作業。
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.
このドキュメントでは、特定のチケット形式やチケットの提案された内容さえも指定していません。どちらも完全に実装者次第です。次のサブセクションで説明されている形式は有用な例として提供されており、実装者はそれらを自由に採用したり、必要な方法でそれらを変更したりできます。
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.
読者は[トークン]に照会され、同様の（同一ではない）チケット形式を推奨し、関連するセキュリティに関する考慮事項について詳しく説明します。
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
Yaron Sheffer Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 67897イスラエル
EMail: yaronf@checkpoint.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at