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 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
Internet密钥交换协议版本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密钥交换版本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会话的有效方法将非常有用。本文档提出了对IKEv2的扩展，该扩展允许客户机利用先前建立的IKE SA以高效的方式使用网关重新建立IKE SA。
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响应器用于重新认证。我们使用术语ticket来指代由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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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密钥交换版本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会话是非常有用的。本文档提出了对IKEv2的扩展，该扩展允许客户机利用先前建立的IKE SA以高效的方式使用网关重新建立IKE SA。
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状态：
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.
该方法类似于传输层安全（TLS）会话恢复[RFC5077]所采用的方法，对IKEv2进行了必要的调整，例如，以适应两阶段协议结构。我们大量借鉴了该规范。
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 提供加密灵活性。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
在本文档中，我们使用术语“ticket”，因此指的是不透明的数据结构，该数据结构可能包含如上所述的IKEv2状态或指向该状态的引用。
This specification envisions two usage scenarios for efficient IKEv2 and IPsec SA session re-establishment.
本规范设想了两种用于高效IKEv2和IPsec SA会话重建的使用场景。
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.
第一个类似于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.
第二个用例集中于使用传输（或隧道）模式来保护两个端点（例如，两台服务器）之间的通信。这两个端点对于使用IPsec SA提供的保护运行的协议具有客户机-服务器关系。
(a)
（a）
+-+-+-+-+-+ +-+-+-+-+-+
| | IKEv2/IKEv2-EAP | | Protected
| Remote |<------------------------>| | Subnet
| Access | | Access |<--- and/or
| Client |<------------------------>| Gateway | Internet
| | IPsec tunnel | |
+-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+
| | 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 | |
+-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ +-+-+-+-+-+
| | 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_会话_RESUME交换来建立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通过活跃度测试设施超时，也称为“死点检测”），则可以使用此机制以较少的开销（网络、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.
本节提供协议细节，并包含规范性部分。本文件定义了两种协议交换，即请求票证（见第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_身份验证交换中，如下面图2中的示例消息交换所示。
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交换中，当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（TICKET_ACK）而不是提供TICKET，或者当TICKET生存期即将到期时，或者在网关启动IKE重新密钥之后。所有此类信息交换必须由客户发起。
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会话恢复交换之后的IKE_身份验证交换中，请参阅第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的第一条）中请求票证。图2显示了这种典型情况下的消息交换。
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
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-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（票证请求）有效负载的票证请求时，如果它支持本文档中定义的扩展，则必须执行以下操作之一：
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（票证不透明）有效负载。这如图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（票证确认）。在这种情况下，客户机可以在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) }
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_身份验证交换时，第一个IKE_身份验证请求中必须包含N（票证请求）有效负载，并且N（票证LT_不透明）（或票证NACK/票证确认）必须仅在最终IKE_身份验证响应中返回。
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_会话_恢复交换、IKE_身份验证交换和最终确定。
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.
票据仅供一次性使用，即客户不得重复使用票据。重新使用的票证应被网关拒绝。请注意，只有在成功建立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).
本文档指定了一种新的IKEv2交换类型，称为IKE_SESSION_RESUME，其值为38。此交换相当于IKE_SA_INIT交换，后面必须跟IKE_AUTH交换。除非客户端知道网关支持此交换类型，否则不应使用此交换类型（在当前文档的上下文中，此条件非常正确，因为客户端总是恢复到生成票据的同一网关）。
Initiator Responder
----------- -----------
HDR, [N(COOKIE),] Ni, N(TICKET_OPAQUE) [,N+] -->
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_会话_恢复”。启动器将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_不透明）有效负载的ticket时，如果它支持本文档中定义的扩展，则必须执行以下步骤之一：
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（票证编号）通知进行响应。在这种情况下，启动器应该重新启动常规IKE交换。一种情况是，当响应者接收到先前在响应者自身上终止的IKE SA的票证时，这可能指示IKEv2发起方和响应者之间的不一致状态。但是，响应者不需要维护已终止会话的状态。
Initiator Responder
----------- -----------
<-- HDR, Nr [,N+]
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_会话_恢复”。响应程序从请求复制SPIi值，并且SPIr值被设置为新的唯一值。
Where not specified otherwise, the IKE_SESSION_RESUME exchange behaves exactly like the IKE_SA_INIT exchange. Specifically:
如果没有另外指定，IKE_会话_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）情况下，第一条消息可能会被拒绝，并指示启动器发送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_会话_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_身份验证交换完成后才完全有效，但是对等方现在必须创建大部分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_会话_恢复交换之后，客户端必须启动IKE_身份验证交换，这在很大程度上与[RFC4306]中的规定相同。本节列出了与基础文档相比的差异和限制。
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, <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和响应程序的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_授权交换中发送的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.
恢复会话时，客户端通常会立即请求新的票证，以便在第二次失败时能够再次恢复会话。N（票证请求）和N（票证不透明）通知将包含在IKE_会话恢复交换之后的IKE_身份验证交换中，其行为类似于常规IKE交换期间的票证请求，见第4.1节。返回的票证（如果有）将对应于根据第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_认证交换之后，双方将创建一个新的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_身份验证交换后），则应默默地删除旧SA，而不发送删除信息交换。因此，所有依赖的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_认证交换成功后才完成，但其许多组件都是在较早时创建的，尤其是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. |
| | |
+--------------------------------+----------------------------------+
| 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] | |
+--------------------------------+----------------------------------+
| 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节。如果这些身份确实不同，则必须在票据中包含经过身份验证的客户端身份。请注意，客户端可能无权访问此值。
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：由于未恢复有关子SA和配置有效负载的信息，因此与子SA协商相关的IKEv2功能（例如支持IPCOMP、不支持ESP、ROHC over 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_身份验证交换（包括支持的HTTP_CERT_LOOKUP_、多重身份验证交换[RFC4739]、椭圆曲线数字签名算法（ECDSA）身份验证[RFC4754]和在线证书状态协议（OCSP）[RFC4806]），通常不需要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|U 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的地方。文字字符串编码为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)
{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.
“按值计票”必须包括受保护的过期时间，这是一个绝对时间值，并且应该与计票有效负载中包含的值相对应。
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.
“票证价值”还必须包括一个密钥标识字段，以便可以更改票证加密和身份验证的密钥，并在必要时替换算法。
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.
在正常操作中，客户机将在建立初始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 |
+-------------------+-------+-----------------+
+-------------------+-------+-----------------+
| 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).
票证\u LT\u不透明通知有效负载的数据由通知消息头、生存期字段和票证本身组成。“四个八位字节生存期”字段包含一个相对时间值，即票证过期前的秒数（以网络字节顺序编码为无符号整数）。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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\u LT\u不透明通知有效负载
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.
票据通知有效负载的数据包括通知消息头和票据本身。与票证不透明有效负载不同，票证不透明通知有效负载中不包含生存期值。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：票据通知有效负载
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会话恢复，其值已从“IKEv2交换类型”注册表中分配。
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 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].
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]建议使用Bloom过滤器[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_会话_恢复交换过程中出示票据时，不为交换提供机密性。因此，路径上的对手有可能观察到使用相同状态信息的多个交换握手，从而得出它们属于相同通信端点的结论。
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.
我们要感谢Paul Hoffman、Pasi Eronen、Florian Tegeler、Stephen Kent、Sean Shen、付晓明、Stjepan Gros、Dan Harkins、Russ Housely、Yoav Nir、Peny Yang、Sean Turner和Tero Kivinen的评论。我们要特别感谢Florian Tegeler和Stjepan Gros的实施工作，以及Florian Tegeler使用Casper工具集进行的正式验证。
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]的作者（严旭、杨佩妮、马元晨、邓辉和徐克）对存根概念的贡献。
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.
我们要感谢邓晖、特罗·基维宁、杨佩妮、艾哈迈德·穆哈纳和斯蒂芬·肯特对“参考票”概念的反馈。
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.，“互联网密钥交换（IKEv2）协议”，RFC43062005年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.，“允许错误的哈希编码中的空间/时间权衡”，通信ACM 13（7）：422-61970年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.Erenen，“互联网密钥交换协议：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 43012005年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）”，RFC4555，2006年6月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718]Erenen，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，“使用椭圆曲线数字签名算法（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]Myers，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.，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 56852009年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]徐，Y.，杨，P.，马，Y.，邓，H.，邓，和H.邓，“IKEv2会话恢复的SA同步”，正在进行的工作，2008年10月。
[TOKENS] Rescorla, E., "How to Implement Secure (Mostly) Stateless Tokens", Work in Progress, March 2007.
[TOKENS]Rescorla，E.，“如何实现安全的（主要是）无状态令牌”，正在进行的工作，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
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;
[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]，它推荐类似（但不完全相同）的票证格式，并深入讨论相关的安全注意事项。
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 {
[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;
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
以色列特拉维夫Hasolelim街5号Yaron Sheffer Check Point软件技术有限公司67897
EMail: yaronf@checkpoint.com
EMail: yaronf@checkpoint.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at