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
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
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.サーバ
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]を時代遅れ。この記事の執筆時点では、RFC 4507にこの更新プログラムは、現在展開の実装との文書を揃え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.
このドキュメント内では、用語「チケットは、」セッション固有の状態を再構築するためにサーバによって作成され、消費された暗号で保護されたデータ構造を指します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 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 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拡張子を含めることによって、このメカニズムをサポートしていることを示しています。クライアントがすでにサーバのチケットを持っていない場合の拡張子は空になります。サーバーは、それがNewSessionTicketハンドシェイクメッセージを使用して新しいセッションチケットを送信することを示すために、空のSessionTicket拡張子を送信します。拡張子は、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.
サーバは、このメカニズムを使用したい場合は、暗号化され、サーバだけに知られているキーで整合性が保護されたチケットに（例えば暗号スイートとマスター秘密として）そのセッション状態を保存します。チケットは、3.3節に記載NewSessionTicket TLSハンドシェイクメッセージを使用して、クライアントに配信されます。サーバーがクライアントのFinishedメッセージを正常に確認した後に、このメッセージは、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. 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からの拡張や変更の符号化の詳細な説明を提供するチケットの正当性を検証し、チケットの内容からセッション状態を取得し、セッションを再開し、この状態を使用し。 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 4346, except for the SessionTicket extension in the first message):
サーバは、この時点で新しいチケットを発行することを希望しない場合には、それだけでSessionTicket拡張子またはNewSessionTicketハンドシェイクメッセージを含めずにハンドシェイクを完了します。これは、（この流れは最初のメッセージでSessionTicket拡張子を除いて、RFC 4346で図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：新規セッションチケットを発行することなく、完全なハンドシェイクを完了サーバーのメッセージフロー
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.
したがって、クライアントがセッションを再開するSessionTicket拡張子を使用していますが、サーバーが新しいチケットを発行することを希望しないRFC 4346の図2で定義された簡略ハンドシェイクを使用して、図3のように交流を持つことも許され、そして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):
サーバーがチケットを拒否した場合、それはまだ（のClientHelloでSessionTicket拡張子が空でない以外、このフローは、図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.
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ハンドシェイクメッセージに1を受け取るために用意されていない場合、それは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.
サーバは、3.3節で説明NewSessionTicketハンドシェイクメッセージを使用して新しいセッションチケットを送信することをクライアントに示すために、長さゼロのSessionTicket拡張を使用しています。それはNewSessionTicketハンドシェイクメッセージを使用して、クライアントに新しいチケットを発行することを希望する場合、サーバはServerHelloメッセージでこの拡張を送らなければなりません。それはのClientHelloで1を受信しない場合、サーバーは、この拡張機能を送ってはいけません。
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拡張子はSessionTicket拡張の拡フィールドは、チケットが含まれている番号35が割り当てられています。
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拡張子が含まれていなかった場合、このメッセージは送ってはいけません。このメッセージは、Finishedメッセージを作成し、検証するために使用されるハッシュに含まれています。完全なハンドシェイクの場合、サーバーは、チケットを送信する前に、クライアントのFinishedメッセージを確かめなければなりません。それは、サーバーのFinishedメッセージを検証するまで、クライアントは有効なものとして、チケットを処理してはなりません。サーバは、それがの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ハンドシェイクメッセージを含めることによって、チケットを更新することができます。クライアントは、それが新しい接続のためのサーバのFinishedメッセージを確認した後、できるだけ早く新しいチケットを使用して開始する必要があります。ハンドシェイクが完了する前に更新され、チケットが発行されているので、新しい接続を開始する前に、クライアントが使用されるように新しいチケットを入れない可能性があることに注意してください。サーバは、それが成功し、クライアントのFinishedメッセージを確認するまで、クライアントが実際に更新チケットを受け取ったと仮定してはいけません。
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_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 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.
サーバーが1つを提示していないクライアントにセッションチケットを発行することを計画している場合、それはの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]暗号化およびHMAC-SHA-256のための1つの256ビット・キー[RFC4634]で[AES]のAdvanced Encryption Standard（AES）のための1つの128ビット鍵：サーバは、二つの異なる鍵を使用します。
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;
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は、ランダムにサーバー間での衝突を避けるために生成する必要があります。一つの可能性は、新しいランダムキーを生成し、サーバが起動されるたびに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).
encrypted_stateにおける実際の状態情報は、所与のIVとCBCモードで128ビットのAESを使用して暗号化されています。メッセージ認証コード（MAC）をかけたキー名（16オクテット）HMAC-SHA-256を使用して計算し、IV（16オクテット）、encrypted_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;
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.
でマスター_を含むTLSセッション状態を保存するStatePlaintext構造。この構造内のタイムスタンプは、TLSサーバがチケットを期限切れにすることができます。 TLSが提供する認証および鍵交換プロトコルをカバーするために、ClientIdentity構造は、初期の交換（ClientAuthenticationTypeを参照）に使用されるクライアントの認証タイプが含まれています。認証と承認のために同じ機能を備えたTLSサーバーを提供するには、証明書のリストが公開鍵ベースの認証の場合に含まれています。 TLSサーバは、したがって、これらの証明書内の異なる属性の数を検査することができます。具体的な実装は、この情報や追加情報のサブセットを格納することもできます。このようケルベロス[RFC2712]、などの他の認証メカニズムは、異なるクライアントIDのデータを必要とします。他の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ハンドシェイクが1つのセッションに関する情報は、マスタシークレットまたは別のセッションを攻撃する利点を提供しないように、セッションのために鍵を導出するために、非可逆関数を使用するためです。セッションの無効化スキームを使用する場合、実装は、攻撃者が選択したセッションを無効にすることができないことを保証するためにセッションを無効にするためのコンテンツを使用する前に、チケットの整合性を確認する必要があります。
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 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].
キーは[RFC4086]で乱数推奨に従って確実に生成する必要があり、O。
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ハンドシェイクを観察するために、パス敵のための機能です。この文書で説明したチケットのメカニズムを使用するアプリケーションの設計者は、リンク不能[ANON]は必ずしも提供されていないことを考慮すべきです。
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.
著者は、この文書を作成し、見直しを持つ彼らの助けのために、以下の人々に感謝したいと思います：エリックレスコラ、モハマドBadra、ティム・ダークス、ネルソンBolyard、ナンシー・カム・ウィンゲット、デビッドマグリュー、ロブDugal、ラスHousley、アミール・ハーツバーグ、バーナード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暗号群にケルベロス[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.
著者らはまた、この文書によって修正、RFC 4507でエンコードのエラーを発見した月Nordqvistを、感謝したいと思います。またNagendra Modadugu、ワン・テー・チャン、そしてマイケル・D'エリコは、この文書の見直しの際に有用なフィードバックを提供しました。
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拡張子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]で定義さHandshakeType値のTLSレジストリからNewSessionTicketハンドシェイクタイプにTLS HandshakeType番号4が割り当てられています。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（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.、周、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] Pfitzmann、A.とM.ハンセンは、 "匿名性、リンク不能性、観察不能、偽名、およびアイデンティティ管理 - 用語の連結提案" は、http：// dud.inf.tu-dresden.de/literatur/ Anon_Terminology_v0。バージョン0.26 26-1.pdf、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.レスコラ、 "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.ハー、RFC 2712、1999年10月 "Layer Security（TLS）を輸送するためのケルベロス暗号スイートの追加"。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（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、RFC 4279 "トランスポート層セキュリティ（TLS）のための事前共有鍵暗号の組み合わせ"、2005年12月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]イーストレイク、D.とT.ハンセンは、RFC 4634、2006年7月、 "米国は、ハッシュアルゴリズム（SHAとHMAC-SHA）を固定します"。
[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]カムウィンゲット、N.、マグリュー、D.、Salowey、J.、およびH.周、RFC 4851、2007年5月 "（EAP-FAST）セキュアなトンネリング拡張認証プロトコル方法を介してフレキシブル認証"。
[SC97] Aura, T. and P. Nikander, "Stateless Connections", Proceedings of the First International Conference on Information and Communication Security (ICICS '97) , 1997.
[SC97]オーラ、T.およびP. Nikander、 "ステートレス接続"、情報通信セキュリティ（ICICS '97）、1997年第一回国際会議の議事録。
Appendix A. Discussion of Changes to
への変更の付録A.ディスカッション
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のハロー拡張子内のサーバーに、このチケットを提示します。 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.
符号化誤差が仕様が展開実装異なるさせます。この記事の執筆時点ではRFC 4507にこのアップデートでは、これらの現在配備実装で文書を整列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:
RFC 4507における誤符号化は、二つの長さフィールドをもたらしました。拡張コンテンツ用とチケット自体に1つ。 RFC 4507によれば、以下のようしたがって、256バイト長であり、16進値のFF FFで始まるチケットのために、拡張の符号化は次のようになります。
00 23 Ticket Extension type 35
01 02 Length of extension contents
01 00 Length of ticket
FF FF .. .. Actual ticket
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バイト長であり、16進値のFF FFで始まるチケットのために、拡張の符号化は次のようになります。
00 23 Extension type 35
01 00 Length of extension contents (ticket)
FF FF .. .. Actual ticket
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に従って実装サーバは、このチケットの長さとしてチケットの最初の2つのバイトを解釈します。これは、いずれかの一貫性のない長さフィールドまたは最初の2つのバイトが欠落してチケットの処理をもたらすであろう。最初のケースでは、サーバは、奇形の長さに基づいて、要求を拒否すべきです。後者の場合、サーバは不正なチケット、間違ったキーバージョン、または失敗した復号に基づいてチケットを拒否すべきです。 RFC 4507拡張を受信し、この更新に基づいてサーバの実装は、第1の長さのフィールドを解釈します
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.
チケットの長さとは、不正なチケット、間違ったキーバージョン、または失敗した復号に基づいて拒否されたチケットで、その結果、チケットの最初のバイトとして第2の長さのバイトを含みます。
Note that the encoding of an empty SessionTicket extension was ambiguous in RFC 4507. An RFC 4507 implementation may have encoded it as:
空SessionTicket拡張の符号化は、RFC 4507に曖昧であったRFC 4507の実装のように、それをコードしていることに留意されたいです。
00 23 Extension type 35
00 02 Length of extension contents
00 00 Length of ticket
or it may have encoded it the same way as this update:
またはそれはそれを、この更新と同じようにエンコードされた可能性があります。
00 23 Extension type 35
00 00 Length of extension contents
A server wishing to support RFC 4507 clients should respond to an empty SessionTicket extension encoded the same way as it received it.
RFC 4507のクライアントをサポートしたいサーバーは、空のSessionTicket延長に応じるべきで、それはそれを受け取ったのと同じ方法でエンコードされました。
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.
サーバの実装は、1つの有効な長さと区別することができるチケットの冒頭にクッキーを含むことによって、存在する場合には、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.
サーバは、セクション3.1で新しいチケットを発行せずにチケットを使用してセッション再開を許可することができることを明確O。
o Clarifying that the lifetime is relative to when the ticket is received in section 3.3.
寿命がチケットはセクション3.3で受信されたときに相対的であることを明確O。
o Clarifying that the NewSessionTicket handshake message is included in the hash generated for the Finished messages in Section 3.3.
NewSessionTicketハンドシェークメッセージはセクション3.3で終了メッセージのために生成されたハッシュに含まれていることを明確O。
o Clarifying the interaction with TLS Session ID in Section 3.4.
3.4節でTLSセッションIDとの相互作用を解明O。
o Recommending the use of SHA-256 for the integrity protection of the ticket in Section 4.
第4節では、チケットの完全性保護のためのSHA-256の使用を推奨するO。
o Clarifying that additional data can be included in the StatePlaintext structure in Section 4.
追加データは、セクション4でStatePlaintext構造に含まれ得ることが明確O。
Authors' Addresses
著者のアドレス
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
ジョセフSaloweyシスコシステムズ2901年第三アベニューシアトル、WA 98121米国
EMail: jsalowey@cisco.com
メールアドレス：jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
ハオ周シスコシステムズ4125ハイランダーパークウェイリッチフィールド、オハイオ州44286米国
EMail: hzhou@cisco.com
メールアドレス：hzhou@cisco.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
ハンネスTschofenigノキアシーメンスネットワークスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@nsn.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。