Network Working Group J. Salowey
Request for Comments: 5077 H. Zhou
Obsoletes: 4507 Cisco Systems
Category: Standards Track P. Eronen
Nokia
H. Tschofenig
Nokia Siemens Networks
January 2008
Network Working Group J. Salowey
Request for Comments: 5077 H. Zhou
Obsoletes: 4507 Cisco Systems
Category: Standards Track P. Eronen
Nokia
H. Tschofenig
Nokia Siemens Networks
January 2008
Transport Layer Security (TLS) Session Resumption without Server-Side State
无服务器端状态的传输层安全（TLS）会话恢复
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507.
本文档描述了一种机制，该机制使传输层安全性（TLS）服务器能够恢复会话并避免保持每个客户端会话状态。TLS服务器将会话状态封装到票证中，并将其转发给客户端。客户端随后可以使用获得的票证恢复会话。本文件淘汰RFC 4507。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7
3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8
3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9
4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12
5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13
5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13
5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13
5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Discussion of Changes to RFC 4507 . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7
3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8
3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9
4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12
5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13
5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13
5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13
5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Discussion of Changes to RFC 4507 . . . . . . . . . . 17
This document defines a way to resume a Transport Layer Security (TLS) session without requiring session-specific state at the TLS server. This mechanism may be used with any TLS ciphersuite. This document applies to both TLS 1.0 defined in [RFC2246], and TLS 1.1 defined in [RFC4346]. The mechanism makes use of TLS extensions defined in [RFC4366] and defines a new TLS message type.
本文档定义了一种恢复传输层安全性（TLS）会话的方法，无需TLS服务器上的特定会话状态。此机制可用于任何TLS密码套件。本文件适用于[RFC2246]中定义的TLS 1.0和[RFC4346]中定义的TLS 1.1。该机制利用了[RFC4366]中定义的TLS扩展，并定义了新的TLS消息类型。
This mechanism is useful in the following situations:
此机制在以下情况下非常有用：
1. servers that handle a large number of transactions from different users
1. 处理来自不同用户的大量事务的服务器
2. servers that desire to cache sessions for a long time
2. 希望长时间缓存会话的服务器
3. ability to load balance requests across servers
3. 跨服务器负载平衡请求的能力
4. embedded servers with little memory
4. 内存很少的嵌入式服务器
This document obsoletes RFC 4507 [RFC4507] to correct an error in the encoding that caused the specification to differ from deployed implementations. At the time of this writing, there are no known implementations that follow the encoding specified in RFC 4507. This update to RFC 4507 aligns the document with currently deployed implementations. More details of the change are given in Appendix A.
本文档淘汰了RFC 4507[RFC4507]，以更正导致规范与已部署实现不同的编码错误。在撰写本文时，没有遵循RFC4507中指定的编码的已知实现。RFC 4507的此更新使文档与当前部署的实现保持一致。有关变更的更多详细信息，请参见附录A。
Within this document, the term 'ticket' refers to a cryptographically protected data structure that is created and consumed by the server to rebuild session-specific state.
在本文档中，术语“ticket”是指由服务器创建和使用的受密码保护的数据结构，用于重建特定于会话的状态。
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 specification describes a mechanism to distribute encrypted session-state information to the client in the form of a ticket and a mechanism to present the ticket back to the server. The ticket is created by a TLS server and sent to a TLS client. The TLS client presents the ticket to the TLS server to resume a session. Implementations of this specification are expected to support both mechanisms. Other specifications can take advantage of the session tickets, perhaps specifying alternative means for distribution or selection. For example, a separate specification may describe an
本规范描述了将加密会话状态信息以票证的形式分发给客户端的机制，以及将票证呈现回服务器的机制。票证由TLS服务器创建并发送到TLS客户端。TLS客户端向TLS服务器提供票证以恢复会话。本规范的实现预计将支持这两种机制。其他规范可以利用会话票证，也许可以指定分发或选择的替代方法。例如，单独的规范可以描述
alternate way to distribute a ticket and use the TLS extension in this document to resume the session. This behavior is beyond the scope of the document and would need to be described in a separate specification.
分发票证并使用本文档中的TLS扩展来恢复会话的替代方法。此行为超出了文档的范围，需要在单独的规范中进行描述。
The client indicates that it supports this mechanism by including a SessionTicket TLS extension in the ClientHello message. The extension will be empty if the client does not already possess a ticket for the server. The server sends an empty SessionTicket extension to indicate that it will send a new session ticket using the NewSessionTicket handshake message. The extension is described in Section 3.2.
客户端通过在ClientHello消息中包含SessionTicket TLS扩展来表示它支持此机制。如果客户端尚未拥有服务器的票证，则扩展将为空。服务器发送一个空的SessionTicket扩展，以指示它将使用NewSessionTicket握手消息发送一个新的会话票证。第3.2节描述了扩展。
If the server wants to use this mechanism, it stores its session state (such as ciphersuite and master secret) to a ticket that is encrypted and integrity-protected by a key known only to the server. The ticket is distributed to the client using the NewSessionTicket TLS handshake message described in Section 3.3. This message is sent during the TLS handshake before the ChangeCipherSpec message, after the server has successfully verified the client's Finished message.
如果服务器想要使用这种机制，它会将其会话状态（如ciphersuite和master secret）存储到一个票据中，该票据由一个只有服务器知道的密钥进行加密和完整性保护。票证使用第3.3节中描述的NewSessionTicket TLS握手消息分发给客户端。在服务器成功验证客户端完成的消息之后，在ChangeCipherSpec消息之前的TLS握手期间发送此消息。
Client Server
客户端服务器
ClientHello
(empty SessionTicket extension)-------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello
(empty SessionTicket extension)-------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
图1：发出新会话票证的完全握手的消息流
The client caches this ticket along with the master secret and other parameters associated with the current session. When the client wishes to resume the session, it includes the ticket in the SessionTicket extension within the ClientHello message. Appendix A provides a detailed description of the encoding of the extension and changes from RFC 4507. The server then decrypts the received ticket, verifies the ticket's validity, retrieves the session state from the contents of the ticket, and uses this state to resume the session. The interaction with the TLS Session ID is described in Section 3.4. If the server successfully verifies the client's ticket, then it may renew the ticket by including a NewSessionTicket handshake message after the ServerHello.
客户端缓存此票证以及主密钥和与当前会话关联的其他参数。当客户端希望恢复会话时，它会在ClientHello消息中的SessionTicket扩展中包含票据。附录A提供了扩展编码和RFC 4507变更的详细说明。然后，服务器解密接收到的票据，验证票据的有效性，从票据内容中检索会话状态，并使用此状态恢复会话。第3.4节描述了与TLS会话ID的交互。如果服务器成功验证了客户端的票证，那么它可以通过在ServerHello之后包含NewSessionTicket握手消息来续订票证。
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2: Message Flow for Abbreviated Handshake Using New Session Ticket
图2：使用新会话票证的简短握手的消息流
A recommended ticket format is given in Section 4.
第4节给出了推荐的票证格式。
If the server cannot or does not want to honor the ticket, then it can initiate a full handshake with the client.
如果服务器不能或不想兑现票据，那么它可以启动与客户端的完全握手。
In the case that the server does not wish to issue a new ticket at this time, it just completes the handshake without including a SessionTicket extension or NewSessionTicket handshake message. This is shown below (this flow is identical to Figure 1 in RFC 4346, except for the SessionTicket extension in the first message):
如果服务器此时不希望发出新票证，那么它只完成握手，而不包括SessionTicket扩展或NewSessionTicket握手消息。如下所示（此流程与RFC 4346中的图1相同，但第一条消息中的SessionTicket扩展除外）：
Client Server
客户端服务器
ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 3: Message Flow for Server Completing Full Handshake Without Issuing New Session Ticket
图3：服务器完成完全握手而不发出新会话票证的消息流
It is also permissible to have an exchange similar to Figure 3 using the abbreviated handshake defined in Figure 2 of RFC 4346, where the client uses the SessionTicket extension to resume the session, but the server does not wish to issue a new ticket, and therefore does not send a SessionTicket extension.
还允许使用RFC 4346图2中定义的简化握手进行类似于图3的交换，其中客户端使用SessionTicket扩展来恢复会话，但服务器不希望发出新票证，因此不发送SessionTicket扩展。
If the server rejects the ticket, it may still wish to issue a new ticket after performing the full handshake as shown below (this flow is identical to Figure 1, except the SessionTicket extension in the ClientHello is not empty):
如果服务器拒绝票证，则在执行如下所示的完全握手后，它可能仍希望发出新票证（此流程与图1相同，只是ClientHello中的SessionTicket扩展不是空的）：
Client Server
客户端服务器
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 4: Message Flow for Server Rejecting Ticket, Performing Full Handshake, and Issuing New Session Ticket
图4：服务器拒绝票证、执行完全握手和发出新会话票证的消息流
The SessionTicket TLS extension is based on [RFC4366]. The format of the ticket is an opaque structure used to carry session-specific state information. This extension may be sent in the ClientHello and ServerHello.
SessionTicket TLS扩展基于[RFC4366]。票证的格式是一种不透明的结构，用于携带特定于会话的状态信息。此扩展可以在ClientHello和ServerHello中发送。
If the client possesses a ticket that it wants to use to resume a session, then it includes the ticket in the SessionTicket extension in the ClientHello. If the client does not have a ticket and is prepared to receive one in the NewSessionTicket handshake message, then it MUST include a zero-length ticket in the SessionTicket extension. If the client is not prepared to receive a ticket in the NewSessionTicket handshake message, then it MUST NOT include a SessionTicket extension unless it is sending a non-empty ticket it received through some other means from the server.
如果客户端拥有一个要用于恢复会话的票证，那么它会将该票证包含在ClientHello中的SessionTicket扩展中。如果客户端没有票证，并且准备在NewSessionTicket握手消息中接收票证，则它必须在SessionTicket扩展中包含长度为零的票证。如果客户端不准备在NewSessionTicket握手消息中接收票证，则它不得包含SessionTicket扩展，除非它正在发送通过其他方式从服务器接收的非空票证。
The server uses a zero-length SessionTicket extension to indicate to the client that it will send a new session ticket using the NewSessionTicket handshake message described in Section 3.3. The server MUST send this extension in the ServerHello if it wishes to issue a new ticket to the client using the NewSessionTicket handshake message. The server MUST NOT send this extension if it does not receive one in the ClientHello.
服务器使用长度为零的SessionTicket扩展向客户端指示，它将使用第3.3节中描述的NewSessionTicket握手消息发送新的会话票证。如果服务器希望使用NewSessionTicket握手消息向客户端发出新票证，则必须在ServerHello中发送此扩展。如果服务器在ClientHello中未收到此扩展，则服务器不得发送此扩展。
If the server fails to verify the ticket, then it falls back to performing a full handshake. If the ticket is accepted by the server but the handshake fails, the client SHOULD delete the ticket.
如果服务器无法验证票据，那么它将返回执行完全握手。如果票据被服务器接受，但握手失败，则客户端应删除票据。
The SessionTicket extension has been assigned the number 35. The extension_data field of SessionTicket extension contains the ticket.
SessionTicket扩展名已分配编号35。SessionTicket扩展的extension_数据字段包含票证。
This message is sent by the server during the TLS handshake before the ChangeCipherSpec message. This message MUST be sent if the server included a SessionTicket extension in the ServerHello. This message MUST NOT be sent if the server did not include a SessionTicket extension in the ServerHello. This message is included in the hash used to create and verify the Finished message. In the case of a full handshake, the server MUST verify the client's Finished message before sending the ticket. The client MUST NOT treat the ticket as valid until it has verified the server's Finished message. If the server determines that it does not want to include a ticket after it has included the SessionTicket extension in the ServerHello, then it sends a zero-length ticket in the NewSessionTicket handshake message.
此消息由服务器在ChangeCipherSpec消息之前的TLS握手期间发送。如果服务器在ServerHello中包含SessionTicket扩展，则必须发送此消息。如果服务器未在ServerHello中包含SessionTicket扩展，则不得发送此消息。此消息包含在用于创建和验证已完成消息的哈希中。在完全握手的情况下，服务器必须在发送票据之前验证客户端已完成的消息。在验证服务器的已完成消息之前，客户端不得将票据视为有效。如果服务器在ServerHello中包含SessionTicket扩展后确定不希望包含票证，则它会在NewSessionTicket握手消息中发送长度为零的票证。
If the server successfully verifies the client's ticket, then it MAY renew the ticket by including a NewSessionTicket handshake message after the ServerHello in the abbreviated handshake. The client should start using the new ticket as soon as possible after it verifies the server's Finished message for new connections. Note that since the updated ticket is issued before the handshake completes, it is possible that the client may not put the new ticket into use before it initiates new connections. The server MUST NOT assume that the client actually received the updated ticket until it successfully verifies the client's Finished message.
如果服务器成功验证了客户端的票证，那么它可以通过在缩写握手中的ServerHello之后包含NewSessionTicket握手消息来续订票证。客户端应在验证服务器的新连接完成消息后尽快开始使用新票证。请注意，由于更新的票证是在握手完成之前发出的，因此客户端在启动新连接之前可能不会将新票证投入使用。在成功验证客户端的已完成消息之前，服务器不得假定客户端实际收到了更新的票证。
The NewSessionTicket handshake message has been assigned the number 4 and its definition is given at the end of this section. The ticket_lifetime_hint field contains a hint from the server about how long the ticket should be stored. The value indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order relative to when the ticket is received. A value of zero is reserved to indicate that the lifetime of the ticket is unspecified. A client SHOULD delete the ticket and associated state when the time expires. It MAY delete the ticket earlier based on local policy. A server MAY treat a ticket as valid for a shorter or longer period of time than what is stated in the ticket_lifetime_hint.
NewSessionTicket握手消息被分配了数字4，其定义在本节末尾给出。ticket_lifetime_提示字段包含来自服务器的提示，提示应将ticket存储多长时间。该值以秒为单位，以32位无符号整数表示生存期，以网络字节顺序表示，与接收票证的时间相关。保留零值表示未指定票证的生存期。当时间到期时，客户端应删除票据和关联状态。它可以根据本地策略提前删除票据。服务器可以将票证视为有效期短于或长于票证提示中所述的时间。
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case session_ticket: NewSessionTicket; /* NEW */
} body;
} Handshake;
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case session_ticket: NewSessionTicket; /* NEW */
} body;
} Handshake;
struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>;
} NewSessionTicket;
struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>;
} NewSessionTicket;
If a server is planning on issuing a session ticket to a client that does not present one, it SHOULD include an empty Session ID in the ServerHello. If the server rejects the ticket and falls back to the full handshake then it may include a non-empty Session ID to indicate its support for stateful session resumption. If the client receives a session ticket from the server, then it discards any Session ID that was sent in the ServerHello.
如果服务器计划向不存在会话票证的客户端发出会话票证，则它应该在ServerHello中包含一个空会话ID。如果服务器拒绝票据并退回到完全握手，那么它可能会包含一个非空会话ID，以指示它支持有状态会话恢复。如果客户端从服务器接收到会话票证，则会丢弃在ServerHello中发送的任何会话ID。
When presenting a ticket, the client MAY generate and include a Session ID in the TLS ClientHello. If the server accepts the ticket and the Session ID is not empty, then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session from when it is falling back to a full handshake. Since the client generates a Session ID, the server MUST NOT rely upon the Session ID having a particular value when validating the ticket. If a ticket is presented by the client, the server MUST NOT attempt to use the Session ID in the ClientHello for stateful session resumption. Alternatively, the client MAY include an empty Session ID in the ClientHello. In this case, the client ignores the Session ID sent in the ServerHello and determines if the server is resuming a session by the subsequent handshake messages.
当呈现票据时，客户端可以在TLS ClientHello中生成并包括会话ID。如果服务器接受票据并且会话ID不是空的，那么它必须使用ClientHello中存在的相同会话ID进行响应。这使客户机能够轻松区分服务器何时恢复会话和何时恢复完全握手。由于客户端生成会话ID，服务器在验证票据时不能依赖具有特定值的会话ID。如果客户端提供了票证，则服务器不得尝试使用ClientHello中的会话ID进行有状态会话恢复。或者，客户端可以在ClientHello中包括空会话ID。在这种情况下，客户端将忽略ServerHello中发送的会话ID，并通过后续握手消息确定服务器是否正在恢复会话。
This section describes a recommended format and protection for the ticket. Note that the ticket is opaque to the client, so the structure is not subject to interoperability concerns, and implementations may diverge from this format. If implementations do diverge from this format, they must take security concerns seriously. Clients MUST NOT examine the ticket under the assumption that it complies with this document.
本节介绍票证的推荐格式和保护。请注意，票据对客户端是不透明的，因此结构不受互操作性问题的影响，实现可能与此格式不同。如果实现确实与此格式不同，则必须认真考虑安全问题。客户不得在假设票据符合本文件的前提下检查票据。
The server uses two different keys: one 128-bit key for Advanced Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634].
服务器使用两个不同的密钥：一个用于密码块链接（CBC）模式[CBC]加密中的高级加密标准（AES）[AES]的128位密钥和一个用于HMAC-SHA-256[RFC4634]的256位密钥。
The ticket is structured as follows:
票证的结构如下：
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[32];
} ticket;
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[32];
} ticket;
Here, key_name serves to identify a particular set of keys used to protect the ticket. It enables the server to easily recognize tickets it has issued. The key_name should be randomly generated to avoid collisions between servers. One possibility is to generate new random keys and key_name every time the server is started.
在这里，key_name用于标识用于保护票据的一组特定密钥。它使服务器能够轻松识别它已发行的票据。密钥名称应随机生成，以避免服务器之间发生冲突。一种可能是在每次启动服务器时生成新的随机密钥和密钥名。
The actual state information in encrypted_state is encrypted using 128-bit AES in CBC mode with the given IV. The Message Authentication Code (MAC) is calculated using HMAC-SHA-256 over key_name (16 octets) and IV (16 octets), followed by the length of the encrypted_state field (2 octets) and its contents (variable length).
加密_状态下的实际状态信息在给定IV的CBC模式下使用128位AES加密。使用HMAC-SHA-256在密钥_名称（16个八位字节）和IV（16个八位字节）上计算消息身份验证码（MAC），然后是加密_状态字段的长度（2个八位字节）及其内容（可变长度）。
struct {
ProtocolVersion protocol_version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque master_secret[48];
ClientIdentity client_identity;
uint32 timestamp;
} StatePlaintext;
struct {
ProtocolVersion protocol_version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque master_secret[48];
ClientIdentity client_identity;
uint32 timestamp;
} StatePlaintext;
enum {
anonymous(0),
certificate_based(1),
psk(2)
} ClientAuthenticationType;
enum {
anonymous(0),
certificate_based(1),
psk(2)
} ClientAuthenticationType;
struct {
ClientAuthenticationType client_authentication_type;
select (ClientAuthenticationType) {
case anonymous: struct {};
case certificate_based:
ASN.1Cert certificate_list<0..2^24-1>;
case psk:
opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
};
} ClientIdentity;
struct {
ClientAuthenticationType client_authentication_type;
select (ClientAuthenticationType) {
case anonymous: struct {};
case certificate_based:
ASN.1Cert certificate_list<0..2^24-1>;
case psk:
opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
};
} ClientIdentity;
The structure StatePlaintext stores the TLS session state including the master_secret. The timestamp within this structure allows the TLS server to expire tickets. To cover the authentication and key exchange protocols provided by TLS, the ClientIdentity structure contains the authentication type of the client used in the initial exchange (see ClientAuthenticationType). To offer the TLS server with the same capabilities for authentication and authorization, a certificate list is included in case of public-key-based authentication. The TLS server is therefore able to inspect a number of different attributes within these certificates. A specific implementation might choose to store a subset of this information or additional information. Other authentication mechanisms, such as Kerberos [RFC2712], would require different client identity data. Other TLS extensions may require the inclusion of additional data in the StatePlaintext structure.
结构StatePlaintext存储TLS会话状态，包括主密钥。此结构中的时间戳允许TLS服务器使票据过期。为了涵盖TLS提供的身份验证和密钥交换协议，ClientIdentity结构包含初始交换中使用的客户端的身份验证类型（请参阅ClientAuthenticationType）。为了向TLS服务器提供相同的身份验证和授权功能，在基于公钥的身份验证的情况下，将包含一个证书列表。因此，TLS服务器能够检查这些证书中的许多不同属性。特定的实现可能会选择存储此信息或附加信息的子集。其他身份验证机制，如Kerberos[RFC2712]，将需要不同的客户端身份数据。其他TLS扩展可能需要在StatePlaintext结构中包含其他数据。
This section addresses security issues related to the usage of a ticket. Tickets must be authenticated and encrypted to prevent modification or eavesdropping by an attacker. Several attacks described below will be possible if this is not carefully done.
本节讨论与票证使用相关的安全问题。票据必须经过身份验证和加密，以防止攻击者修改或窃听。如果不小心这样做，可能会发生下面描述的几种攻击。
Implementations should take care to ensure that the processing of tickets does not increase the chance of denial of service as described below.
实施应注意确保票据处理不会增加拒绝服务的机会，如下所述。
The TLS specification requires that TLS sessions be invalidated when errors occur. [CSSC] discusses the security implications of this in detail. In the analysis within this paper, failure to invalidate sessions does not pose a security risk. This is because the TLS handshake uses a non-reversible function to derive keys for a session so information about one session does not provide an advantage to attack the master secret or a different session. If a session invalidation scheme is used, the implementation should verify the integrity of the ticket before using the contents to invalidate a session to ensure that an attacker cannot invalidate a chosen session.
TLS规范要求发生错误时TLS会话无效。[CSSC]详细讨论了此操作的安全影响。在本文的分析中，会话失效不会带来安全风险。这是因为TLS握手使用不可逆函数为会话派生密钥，因此关于一个会话的信息不会提供攻击主密钥或不同会话的优势。如果使用会话失效方案，则实现应在使用内容使会话失效之前验证票据的完整性，以确保攻击者无法使所选会话失效。
An eavesdropper or man-in-the-middle may obtain the ticket and attempt to use it to establish a session with the server; however, since the ticket is encrypted and the attacker does not know the secret key, a stolen ticket does not help an attacker resume a session. A TLS server MUST use strong encryption and integrity protection for the ticket to prevent an attacker from using a brute force mechanism to obtain the ticket's contents.
窃听者或中间人可能获得票据并试图使用票据与服务器建立会话；但是，由于票据是加密的，攻击者不知道密钥，因此被盗票据无法帮助攻击者恢复会话。TLS服务器必须对票据使用强大的加密和完整性保护，以防止攻击者使用暴力机制获取票据内容。
A malicious user could forge or alter a ticket in order to resume a session, to extend its lifetime, to impersonate another user, or to gain additional privileges. This attack is not possible if the ticket is protected using a strong integrity protection algorithm such as a keyed HMAC-SHA-256.
恶意用户可以伪造或更改票证以恢复会话、延长其生存期、模拟其他用户或获得其他权限。如果使用强完整性保护算法（如加密HMAC-SHA-256）保护票据，则不可能进行此攻击。
The key_name field defined in the recommended ticket format helps the server efficiently reject tickets that it did not issue. However, an adversary could store or generate a large number of tickets to send
在推荐票证格式中定义的key_name字段有助于服务器有效地拒绝其未发出的票证。但是，对手可以存储或生成大量要发送的票证
to the TLS server for verification. To minimize the possibility of a denial of service, the verification of the ticket should be lightweight (e.g., using efficient symmetric key cryptographic algorithms).
发送到TLS服务器进行验证。为了尽量减少拒绝服务的可能性，票据的验证应该是轻量级的（例如，使用有效的对称密钥加密算法）。
A full description of the management of the keys used to protect the ticket 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. Some ciphersuites and applications may require cryptographic protection greater than 128 bits in strength.
o 密钥和密码保护算法的强度应至少为128位。某些密码套件和应用程序可能需要强度大于128位的密码保护。
o The keys should not be used for any purpose other 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 如果票证格式或加密保护算法更改，则应更改密钥。
The TLS server controls the lifetime of the ticket. Servers determine the acceptable lifetime based on the operational and security requirements of the environments in which they are deployed. The ticket lifetime may be longer than the 24-hour lifetime recommended in [RFC4346]. TLS clients may be given a hint of the lifetime of the ticket. Since the lifetime of a ticket may be unspecified, a client has its own local policy that determines when it discards tickets.
TLS服务器控制票证的生存期。服务器根据其部署环境的操作和安全要求确定可接受的生存期。票证生存期可能长于[RFC4346]中建议的24小时生存期。TLS客户端可能会得到票证生命周期的提示。由于票证的生存期可能未指定，因此客户端有自己的本地策略来确定何时丢弃票证。
If the ticket format or distribution scheme defined in this document is not used, then great care must be taken in analyzing the security of the solution. In particular, if confidential information, such as a secret key, is transferred to the client, it MUST be done using secure communication so as to prevent attackers from obtaining or modifying the key. Also, the ticket MUST have its integrity and confidentiality protected with strong cryptographic techniques to prevent a breach in the security of the system.
如果未使用本文档中定义的票证格式或分发方案，则必须非常小心地分析解决方案的安全性。特别是，如果机密信息（如密钥）被传输到客户端，则必须使用安全通信进行传输，以防止攻击者获取或修改密钥。此外，票证的完整性和机密性必须使用强大的密码技术进行保护，以防止系统安全性遭到破坏。
This document mandates that the content of the ticket is confidentiality protected in order to avoid leakage of its content, such as user-relevant information. As such, it prevents disclosure of potentially sensitive information carried within the ticket.
本文件要求票据内容受保密保护，以避免其内容（如用户相关信息）泄露。因此，它可以防止票据中携带的潜在敏感信息被泄露。
The initial handshake exchange, which was used to obtain the ticket, might not provide identity confidentiality of the client based on the properties of TLS. Another relevant security threat is the ability for an on-path adversary to observe multiple TLS handshakes where the same ticket is used, therefore concluding they belong to the same communication endpoints. Application designers that use the ticket mechanism described in this document should consider that unlinkability [ANON] is not necessarily provided.
用于获取票据的初始握手交换可能不会根据TLS的属性提供客户端的身份保密性。另一个相关的安全威胁是路径上的对手能够观察到使用同一票据的多个TLS握手，从而得出它们属于相同的通信端点的结论。使用本文档中描述的票证机制的应用设计者应该考虑不一定提供不可链接性。
While a full discussion of these topics is beyond the scope of this document, it should be noted that it is possible to issue a ticket using a TLS renegotiation handshake that occurs after a secure tunnel has been established by a previous handshake. This may help address some privacy and unlinkability issues in some environments.
虽然对这些主题的全面讨论超出了本文件的范围，但应注意的是，在通过先前的握手建立安全隧道后，可以使用TLS重新协商握手发出票据。这可能有助于解决某些环境中的一些隐私和不可链接性问题。
The authors would like to thank the following people for their help with preparing and reviewing this document: Eric Rescorla, Mohamad Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of the TLS working group.
作者要感谢以下人员帮助编写和审查本文件：Eric Rescorla、Mohamad Badra、Tim Dierks、Nelson Bolyard、Nancy Cam Winget、David McGrew、Rob Dugal、Russ Housley、Amir Herzberg、Bernard Aboba和TLS工作组成员。
[CSSC] describes a solution that is very similar to the one described in this document and gives a detailed analysis of the security considerations involved. [RFC2712] describes a mechanism for using Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use of tickets to avoid server state. [RFC4851] makes use of a similar mechanism to avoid maintaining server state for the cryptographic tunnel. [SC97] also investigates the concept of stateless sessions.
[CSSC]描述了一种与本文档中描述的解决方案非常相似的解决方案，并详细分析了所涉及的安全注意事项。[RFC2712]描述了一种在TLS密码套件中使用Kerberos[RFC4120]的机制，这有助于鼓励使用票据来避免服务器状态。[RFC4851]使用类似的机制来避免维护加密隧道的服务器状态。[SC97]还研究了无状态会话的概念。
The authors would also like to thank Jan Nordqvist, who found the encoding error in RFC 4507, corrected by this document. In addition Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided useful feedback during the review of this document.
作者还要感谢Jan Nordqvist，他发现了RFC 4507中的编码错误，并通过本文档进行了更正。此外，Nagendra Modadugu、Wan Teh Chang和Michael D'Errico在审查本文件期间提供了有用的反馈。
IANA has assigned a TLS extension number of 35 to the SessionTicket TLS extension from the TLS registry of ExtensionType values defined in [RFC4366].
IANA已从[RFC4366]中定义的ExtensionType值的TLS注册表中为SessionTicket TLS扩展分配了一个TLS扩展号35。
IANA has assigned a TLS HandshakeType number 4 to the NewSessionTicket handshake type from the TLS registry of HandshakeType values defined in [RFC4346].
IANA已从[RFC4346]中定义的握手类型值的TLS注册表将TLS握手类型编号4分配给NewSessionTicket握手类型。
This document does not require any actions or assignments from IANA.
本文件不要求IANA采取任何行动或分配任务。
[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月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 4507, May 2006.
[RFC4507]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 4507，2006年5月。
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards (FIPS) Publication 197, November 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）”，联邦信息处理标准（FIPS）出版物197，2001年11月。
[ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability, Unobservability, Pseudonymity, and Identity Management - A Consolidated Proposal for Terminology", http:// dud.inf.tu-dresden.de/literatur/ Anon_Terminology_v0.26-1.pdf Version 0.26, December 2005.
[ANON]Pfizmann，A.和M.Hansen，“匿名性、不可链接性、不可观察性、假名和身份管理——术语的综合建议”，http://dud.inf.tu-dresden.de/literatur/ANON_Terminology_v0.26-1.pdf版本0.26，2005年12月。
[CBC] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation - Methods and Techniques", NIST Special Publication 800-38A, December 2001.
[CBC]国家标准与技术研究所，“分组密码操作模式的建议-方法和技术”，NIST特别出版物800-38A，2001年12月。
[CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side caching for TLS", Transactions on Information and System Security (TISSEC) , Volume 7, Issue 4, November 2004.
[CSSC]Shacham，H.，Boneh，D.，和E.Rescorla，“TLS的客户端缓存”，信息和系统安全交易（TISSEC），第7卷，第4期，2004年11月。
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
[RFC2712]Medvinsky，A.和M.Hur，“将Kerberos密码套件添加到传输层安全性（TLS）”，RFC 2712，1999年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月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]Eastlake，D.和T.Hansen，“美国安全哈希算法（SHA和HMAC-SHA）”，RFC 46342006年7月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851]Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道可扩展认证协议方法（EAP-FAST）的灵活认证”，RFC 4851，2007年5月。
[SC97] Aura, T. and P. Nikander, "Stateless Connections", Proceedings of the First International Conference on Information and Communication Security (ICICS '97) , 1997.
[SC97]Aura，T.和P.Nikander，“无国籍联系”，第一届信息和通信安全国际会议记录（ICICS'97），1997年。
RFC 4507 [RFC4507] defines a mechanism to resume a TLS session without maintaining server side state by specifying an encrypted ticket that is maintained on the client. The client presents this ticket to the server in a SessionTicket hello extension. The encoding in RFC 4507 used the XDR style encoding specified in TLS [RFC4346].
RFC 4507[RFC4507]定义了一种机制，通过指定在客户端上维护的加密票证，在不维护服务器端状态的情况下恢复TLS会话。客户端在SessionTicket hello扩展中将此票证呈现给服务器。RFC 4507中的编码使用TLS[RFC4346]中指定的XDR样式编码。
An error in the encoding caused the specification to differ from deployed implementations. At the time of this writing there are no known implementations that follow the encoding specified in RFC 4507. This update to RFC 4507 aligns the document with these currently deployed implementations.
编码中的错误导致规范与部署的实现不同。在撰写本文时，还没有遵循RFC4507中指定的编码的已知实现。RFC 4507的此更新使文档与这些当前部署的实现保持一致。
Erroneous encoding in RFC 4507 resulted in two length fields; one for the extension contents and one for the ticket itself. Hence, for a ticket that is 256 bytes long and begins with the hex value FF FF, the encoding of the extension would be as follows according to RFC 4507:
RFC4507中的错误编码导致两个长度字段；一个用于分机内容，一个用于票据本身。因此，对于256字节长且以十六进制值FF FF开始的票据，根据RFC 4507，扩展的编码如下：
00 23 Ticket Extension type 35 01 02 Length of extension contents 01 00 Length of ticket FF FF .. .. Actual ticket
00 23车票分机类型35 01 02分机内容长度01 00车票长度FF FF。。实际票
The update proposed in this document reflects what implementations actually encode, namely it removes the redundant length field. So, for a ticket that is 256 bytes long and begins with the hex value FF FF, the encoding of the extension would be as follows according to this update:
本文档中建议的更新反映了实现实际编码的内容，即删除了冗余长度字段。因此，对于长度为256字节且以十六进制值FF FF开头的票证，根据此更新，扩展名的编码如下：
00 23 Extension type 35 01 00 Length of extension contents (ticket) FF FF .. .. Actual ticket
00 23分机类型35 01 00分机内容长度（票）FF FF FF。。实际票
A server implemented according to RFC 4507 receiving a ticket extension from a client conforming to this document would interpret the first two bytes of the ticket as the length of this ticket. This will result in either an inconsistent length field or in the processing of a ticket missing the first two bytes. In the first case, the server should reject the request based on a malformed length. In the second case, the server should reject the ticket based on a malformed ticket, incorrect key version, or failed decryption. A server implementation based on this update receiving an RFC 4507 extension would interpret the first length field as the
根据RFC 4507实现的服务器从符合本文档的客户端接收票据扩展，将票据的前两个字节解释为该票据的长度。这将导致长度字段不一致，或处理缺少前两个字节的票证。在第一种情况下，服务器应根据错误的长度拒绝请求。在第二种情况下，服务器应该基于错误的票证、不正确的密钥版本或解密失败而拒绝票证。基于此更新并接收RFC4507扩展名的服务器实现会将第一个长度字段解释为
length of the ticket and include the second two length bytes as the first bytes in the ticket, resulting in the ticket being rejected based on a malformed ticket, incorrect key version, or failed decryption.
票证的长度，并将第二个两个长度字节作为票证中的第一个字节，导致票证因格式错误、密钥版本不正确或解密失败而被拒绝。
Note that the encoding of an empty SessionTicket extension was ambiguous in RFC 4507. An RFC 4507 implementation may have encoded it as:
请注意，在RFC4507中，空SessionTicket扩展的编码是不明确的。RFC 4507实现可能已将其编码为：
00 23 Extension type 35 00 02 Length of extension contents 00 00 Length of ticket
00 23分机类型35 00 02分机内容长度00 00车票长度
or it may have encoded it the same way as this update:
或者，它可能以与此更新相同的方式对其进行编码：
00 23 Extension type 35 00 00 Length of extension contents
00 23扩展类型35 00 00扩展内容的长度
A server wishing to support RFC 4507 clients should respond to an empty SessionTicket extension encoded the same way as it received it.
希望支持RFC4507客户端的服务器应响应空的Sessionicket扩展，其编码方式与接收到的方式相同。
A server implementation can construct tickets such that it can detect an RFC 4507 implementation, if one existed, by including a cookie at the beginning of the tickets that can be differentiated from a valid length. For example, if an implementation constructed tickets to start with the hex values FF FF, then it could determine where the ticket begins and determine the length correctly from the type of length fields present.
服务器实现可以构造票证，以便通过在票证的开头包含可以与有效长度区分的cookie来检测RFC 4507实现（如果存在）。例如，如果一个实现将票据构造为以十六进制值FF FF开始，那么它可以确定票据的起始位置，并根据存在的长度字段类型正确确定长度。
This document makes a few additional changes to RFC 4507 listed below.
本文件对下面列出的RFC 4507进行了一些附加更改。
o Clarifying that the server can allow session resumption using a ticket without issuing a new ticket in Section 3.1.
o 在第3.1节中说明服务器可以允许使用票证恢复会话，而无需发出新票证。
o Clarifying that the lifetime is relative to when the ticket is received in section 3.3.
o 在第3.3节中，澄清生命周期与收到票据的时间相关。
o Clarifying that the NewSessionTicket handshake message is included in the hash generated for the Finished messages in Section 3.3.
o 澄清NewSessionTicket握手消息包含在为第3.3节中的已完成消息生成的哈希中。
o Clarifying the interaction with TLS Session ID in Section 3.4.
o 澄清第3.4节中与TLS会话ID的交互。
o Recommending the use of SHA-256 for the integrity protection of the ticket in Section 4.
o 建议使用SHA-256保护第4节中的票据完整性。
o Clarifying that additional data can be included in the StatePlaintext structure in Section 4.
o 澄清第4节中的StatePlaintext结构中可以包含其他数据。
Authors' Addresses
作者地址
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
郝州思科系统4125美国俄亥俄州汉兰达大道里奇菲尔德44286号
EMail: hzhou@cisco.com
EMail: hzhou@cisco.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
德国拜仁慕尼黑，诺基亚西门子网络奥托哈恩6环，邮编81739
EMail: Hannes.Tschofenig@nsn.com
EMail: Hannes.Tschofenig@nsn.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.