Network Working Group J. Salowey
Request for Comments: 4507 H. Zhou
Category: Standards Track Cisco Systems
P. Eronen
Nokia
H. Tschofenig
Siemens
May 2006
Network Working Group J. Salowey
Request for Comments: 4507 H. Zhou
Category: Standards Track Cisco Systems
P. Eronen
Nokia
H. Tschofenig
Siemens
May 2006
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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.
本文档描述了一种机制，该机制使传输层安全性（TLS）服务器能够恢复会话并避免保持每个客户端会话状态。TLS服务器将会话状态封装到票证中，并将其转发给客户端。客户端随后可以使用获得的票证恢复会话。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol ........................................................3
3.1. Overview ...................................................4
3.2. SessionTicket TLS Extension ................................6
3.3. NewSessionTicket Handshake Message .........................7
3.4. Interaction with TLS Session ID ............................8
4. Recommended Ticket Construction .................................9
5. Security Considerations ........................................10
5.1. Invalidating Sessions .....................................11
5.2. Stolen Tickets ............................................11
5.3. Forged Tickets ............................................11
5.4. Denial of Service Attacks .................................11
5.5. Ticket Protection Key Management ..........................12
5.6. Ticket Lifetime ...........................................12
5.7. Alternate Ticket Formats and Distribution Schemes .........12
5.8. Identity Privacy, Anonymity, and Unlinkability ............12
6. Acknowledgements ...............................................13
7. IANA Considerations ............................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................14
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol ........................................................3
3.1. Overview ...................................................4
3.2. SessionTicket TLS Extension ................................6
3.3. NewSessionTicket Handshake Message .........................7
3.4. Interaction with TLS Session ID ............................8
4. Recommended Ticket Construction .................................9
5. Security Considerations ........................................10
5.1. Invalidating Sessions .....................................11
5.2. Stolen Tickets ............................................11
5.3. Forged Tickets ............................................11
5.4. Denial of Service Attacks .................................11
5.5. Ticket Protection Key Management ..........................12
5.6. Ticket Lifetime ...........................................12
5.7. Alternate Ticket Formats and Distribution Schemes .........12
5.8. Identity Privacy, Anonymity, and Unlinkability ............12
6. Acknowledgements ...............................................13
7. IANA Considerations ............................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................14
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 2. servers that desire to cache sessions for a long time 3. ability to load balance requests across servers 4. embedded servers with little memory
1. 处理来自不同用户的大量事务的服务器2。希望长时间缓存会话的服务器3。能够跨服务器负载平衡请求4。内存很少的嵌入式服务器
Within this document, the term 'ticket' refers to a cryptographically protected data structure that is created by the server 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 in the form of a ticket. 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 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服务器创建并发送到TLS客户端。TLS客户端向TLS服务器提供票证以恢复会话。本规范的实现预计将支持这两种机制。其他规范可以利用会话票证，也许可以指定分发或选择的替代方法。例如，一个单独的规范可以描述分发票据和使用本文档中的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 extension is described in Section 3.2.
客户端通过在ClientHello消息中包含SessionTicket TLS扩展来表示它支持此机制。如果客户端尚未拥有服务器的票证，则扩展将为空。第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. 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扩展中包含票据。然后，服务器解密接收到的票据，验证票据的有效性，从票据内容中检索会话状态，并使用此状态恢复会话。第3.4节描述了与TLS会话ID的交互。如果服务器成功验证了客户端的票证，那么它可以通过在ServerHello之后包含NewSessionTicket握手消息来续订票证。
Client Server
客户端服务器
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
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 2246, except for the session ticket extension in the first message):
如果服务器此时不希望发出新票证，那么它只完成握手，而不包括SessionTicket扩展或NewSessionTicket握手消息。如下所示（此流程与RFC 2246中的图1相同，但第一条消息中的会话票证扩展除外）：
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：服务器完成完全握手而不发出新会话票证的消息流
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 Client Hello is not empty):
如果服务器拒绝票证，则在执行如下所示的完全握手后，它可能仍希望发出一个新票证（此流程与图1相同，只是客户机Hello中的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 an 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
服务器使用长度为零的SessionTicket扩展向客户端指示，它将使用第3.3节中描述的NewSessionTicket握手消息发送新的会话票证。这个
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.
如果服务器希望使用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 format of the SessionTicket extension is given at the end of this section.
SessionTicket扩展名已分配编号35。SessionTicket扩展的格式在本节末尾给出。
struct {
opaque ticket<0..2^16-1>;
} SessionTicket;
struct {
opaque ticket<0..2^16-1>;
} SessionTicket;
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. 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. A value of zero is reserved to indicate that the lifetime of the ticket
NewSessionTicket握手消息被分配了数字4，其定义在本节末尾给出。ticket_lifetime_提示字段包含来自服务器的提示，提示应将ticket存储多长时间。该值表示以秒为单位的生存期，以网络字节顺序表示为32位无符号整数。保留的值为零，表示票证的生存期
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.
没有具体说明。当时间到期时，客户端应删除票据和关联状态。它可以根据本地策略提前删除票据。服务器可以将票证视为有效期短于或长于票证提示中所述的时间。
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 SessionTicket to a client that does not present one, it SHOULD include an empty Session ID in the ServerHello. If the server includes a non-empty session ID, then it is indicating intent to use stateful session resume. If the client receives a SessionTicket from the server, then it discards any Session ID that was sent in the ServerHello.
如果服务器计划向不存在会话密钥的客户端发出会话密钥，则它应该在ServerHello中包含一个空会话ID。如果服务器包含非空会话ID，则表示打算使用有状态会话恢复。如果客户机从服务器接收到SessionTicket，那么它将丢弃在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
当呈现票据时，客户端可以在TLS ClientHello中生成并包括会话ID。如果服务器接受票据并且会话ID不是空的，那么它必须使用ClientHello中存在的相同会话ID进行响应。这使客户机能够轻松区分服务器何时恢复会话和何时恢复完全握手。由于客户端生成会话ID，服务器在验证票据时不能依赖具有特定值的会话ID。如果客户机提供票证，则服务器不得尝试使用
Session ID in the ClientHello for stateful session resume. 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.
有状态会话恢复的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 AES [AES] in CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104] [SHA1].
服务器使用两个不同的密钥：一个128位密钥用于CBC模式[CBC]加密中的AES[AES]，另一个128位密钥用于HMAC-SHA1[RFC2104][SHA1]。
The ticket is structured as follows:
票证的结构如下：
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[20];
} ticket;
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[20];
} 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 MAC is calculated using HMAC-SHA1 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加密。MAC使用HMAC-SHA1在密钥_名称（16个八位字节）和IV（16个八位字节）上计算，然后是加密_状态字段（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] */
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;
}
} 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.
结构StatePlaintext存储TLS会话状态，包括主密钥。此结构中的时间戳允许TLS服务器使票据过期。为了涵盖TLS提供的身份验证和密钥交换协议，ClientIdentity结构包含初始交换中使用的客户端的身份验证类型（请参阅ClientAuthenticationType）。为了向TLS服务器提供相同的身份验证和授权功能，在基于公钥的身份验证的情况下，将包含一个证书列表。因此，TLS服务器能够检查这些证书中的许多不同属性。特定的实现可能会选择存储此信息或附加信息的子集。其他身份验证机制，如Kerberos[RFC2712]，将需要不同的客户端身份数据。
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 in 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 the ticket 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 as 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-SHA1.
恶意用户可以伪造或更改票证以恢复会话、延长其生存期、冒充其他用户或获得其他特权。如果使用强完整性保护算法（如加密HMAC-SHA1）保护票据，则不可能进行此攻击。
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 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).
在推荐票证格式中定义的key_name字段有助于服务器有效地拒绝其未发出的票证。但是，对手可以存储或生成大量票据，以发送到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 The keys and cryptographic protection algorithms should be at least 128 bits in strength. o The keys should not be used for any other purpose than generating and verifying tickets. o The keys should be changed regularly. o The keys should be changed if the ticket format or cryptographic protection algorithms change.
o 密钥应按照[RFC4086]中的随机性建议安全生成。o密钥和加密保护算法的强度应至少为128位。o密钥不得用于生成和验证票据以外的任何其他目的。o应定期更换钥匙。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 [RFC2246]. 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服务器控制票证的生存期。服务器根据其部署环境的操作和安全要求确定可接受的生存期。票证有效期可能长于[RFC2246]中建议的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
用于获取票据的初始握手交换可能不会根据TLS的属性提供客户端的身份保密性。另一个相关的安全威胁是能力
for an on-path adversary to observe multiple TLS handshakes where the same ticket is used and therefore to conclude that 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握手，从而得出它们属于同一通信端点的结论。使用本文档中描述的票证机制的应用设计者应该考虑不一定提供不可链接性。
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. [EAP-FAST] 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]的机制，这有助于鼓励使用票据来避免服务器状态。[EAP-FAST]使用类似的机制来避免维护加密隧道的服务器状态。[SC97]还研究了无状态会话的概念。
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握手类型。
[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月。
[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, Draft 0.26, December 2005.
[ANON]Pfizmann，A.和M.Hansen，“匿名性、不可链接性、不可观察性、假名和身份管理——术语的综合建议”，http://dud.inf.tu-dresden.de/literatur/ Anon_Terminology_v0.26-1.pdf，草案0.262005年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月。
[EAP-FAST] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", Work in Progress, April 2005.
[EAP-FAST]Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道的EAP灵活身份验证（EAP-FAST）”，正在进行的工作，2005年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[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年。
[SHA1] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards (FIPS) Publication 180-2, August 2002.
[SHA1]国家标准与技术研究所，“安全哈希标准（SHS）”，联邦信息处理标准（FIPS）出版物180-22002年8月。
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 Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
德国拜仁慕尼黑第6环汉内斯·茨霍芬尼西门子奥托·哈恩81739
EMail: Hannes.Tschofenig@siemens.com
EMail: Hannes.Tschofenig@siemens.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。