[要約] RFC 4507は、サーバー側でセッション状態を保持せずにTransport Layer Security (TLS) セッションの再開を可能にする方法について説明しています。このメカニズムの目的は、サーバーのリソース要求を減らしながら、セキュリティを維持することにあります。利用場面としては、高頻度でセッション再開が必要な環境や、サーバーのリソースが限られている場合に適しています。このRFCは、TLS 1.2 (RFC 5246) や後続のTLS 1.3 (RFC 8446) など、TLSプロトコルの発展において基礎的な役割を果たしています。
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、Transport Layer Security（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
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 ciphersuiteで使用できます。このドキュメントは、[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.
このドキュメント内では、「チケット」という用語は、サーバーによって作成され、サーバーによって消費されてセッション固有の状態を再構築する暗号化された保護されたデータ構造を指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This 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
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メッセージ内のセッションチケット拡張機能にチケットが含まれます。その後、サーバーは受信したチケットを復号化し、チケットの有効性を検証し、チケットの内容からセッション状態を取得し、この状態を使用してセッションを再開します。TLSセッションIDとの相互作用は、セクション3.4で説明されています。サーバーがクライアントのチケットを正常に検証した場合、ServerHelloの後にNewsessionTicketのハンドシェイクメッセージを含めることにより、チケットを更新できます。
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 2246, except for the session ticket extension in the first message):
サーバーが現時点で新しいチケットを発行することを望まない場合、セッションチケット拡張機能や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
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と同じです。
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
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.
セッションチケット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のセッションチケット拡張機能にチケットが含まれます。クライアントがチケットを持っておらず、NewsessionTicketのハンドシェイクメッセージでチケットを受け取る準備ができている場合は、セッションチケット拡張機能にゼロ長チケットを含める必要があります。クライアントがNewsessionTicketのハンドシェイクメッセージでチケットを受け取る準備ができていない場合、サーバーから他の手段で受け取った非空白のチケットを送信しない限り、セッションチケット拡張機能を含めてはなりません。
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 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.
サーバーは、ゼロ長さセッションチケット拡張機能を使用して、セクション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 format of the SessionTicket extension is given at the end of this section.
セッションチケット拡張機能には35番が割り当てられています。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にセッションチケット拡張機能を含めた場合は、このメッセージを送信する必要があります。サーバーがServerHelloにセッションチケット拡張機能を含めなかった場合、このメッセージを送信しないでください。完全な握手の場合、サーバーはチケットを送信する前にクライアントの完成したメッセージを確認する必要があります。クライアントは、サーバーの完成したメッセージを確認するまで、チケットを有効であると扱ってはなりません。サーバーが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 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_hintフィールドには、チケットの保管期間についてサーバーからのヒントが含まれています。この値は、ネットワークバイト順序で32ビットの署名されていない整数として秒単位で寿命を示します。ゼロの値は、チケットの寿命が不特定であることを示すために予約されています。クライアントは、時間が切れるときにチケットと関連状態を削除する必要があります。ローカルポリシーに基づいて、以前にチケットを削除する場合があります。サーバーは、チケットを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 {
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が含まれている場合、Stateful Session Resumeを使用する意図を示しています。クライアントがサーバーからセッションチケットを受信した場合、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 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.
チケットを提示するとき、クライアントは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 AES [AES] in CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104] [SHA1].
サーバーは、CBCモード[CBC]暗号化のAES [AES]の1つの128ビットキーと、HMAC-SHA1 [RFC2104] [SHA1]の1つの128ビットキーの2つの異なるキーを使用します。
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;
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は、チケットを保護するために使用される特定のキーセットを識別するのに役立ちます。これにより、サーバーが発行したチケットを簡単に認識できます。キー_nameは、サーバー間の衝突を避けるためにランダムに生成する必要があります。1つの可能性は、サーバーが開始されるたびに新しいランダムキーと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).
暗号化された_Stateの実際の状態情報は、指定されたIVを使用してCBCモードで128ビットAESを使用して暗号化されます。MACは、key_name（16オクテット）およびIV（16オクテット）を介したHMAC-SHA1を使用して計算され、その後、暗号化された_STATEフィールド（2オクテット）とその内容（可変長）の長さが続きます。
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;
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.
構造StatePlintextは、Master_Secretを含むTLSセッション状態を保存します。この構造内のタイムスタンプにより、TLSサーバーがチケットを期限切れにすることができます。TLSが提供する認証とキー交換プロトコルをカバーするために、ClientIdentity構造には、初期交換で使用されるクライアントの認証タイプが含まれています（ClientAuthenticationTypeを参照）。認証と承認のための同じ機能を備えたTLSサーバーを提供するために、公開キーベースの認証の場合、証明書リストが含まれています。したがって、TLSサーバーは、これらの証明書内のさまざまな属性を検査することができます。特定の実装では、この情報または追加情報のサブセットを保存することを選択する場合があります。Kerberos [RFC2712]などの他の認証メカニズムには、異なるクライアントIDデータが必要になります。
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 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のプロパティに基づいてクライアントの身元の機密性を提供しない場合があります。もう1つの関連するセキュリティの脅威は、同じチケットが使用されている複数の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.
著者は、このドキュメントの準備とレビューの支援に次の人々に感謝したいと思います：エリック・レスコルラ、モハマド・バドラ、ティム・ディアークス、ネルソン・ボリヤード、ナンシー・カム・ウィンゲット、デビッド・マクグリュー、ロブ・デュガル、ラス・ハウズリー、アミール・ヘルツバーグ、バーナード・アボバ、および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 ciphersuitesで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]で定義された拡張タイプ値のTLSレジストリからTLS拡張番号35をセッションチケットTLS拡張に割り当てました。
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をNissessionTicketのハンドシェイクタイプに割り当てました。
[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」、RFC 2246、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、「The Transport Layer Security（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、「Transport Layer Security（TLS）Extensions」、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]国立標準技術研究所、「Advanced Encryption Standard（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] Pfitzmann、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 Special Publication 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巻、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、「Secure Tunneling（EAP-FAST）によるEAP柔軟性認証」、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、「層のセキュリティ（TLS）へのKerberos cipherスイートの追加」、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、「The Kerberos Network認証サービス（V5）」、RFC 4120、2005年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、「Stateless Connections」、情報通信セキュリティに関する最初の国際会議（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]国立標準技術研究所、「Secure Hash Standard（SHS）」、連邦情報処理基準（FIPS）出版180-2、2002年8月。
Authors' Addresses
著者のアドレス
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
ジョセフ・サロウィ・シスコ・システム2901 3番目のアベニュー・シアトル、ワシントン州98121米国
EMail: jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield、Oh 44286 US
EMail: hzhou@cisco.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich、Bayern 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。