RFC5077 日本語訳
5077 Transport Layer Security (TLS) Session Resumption withoutServer-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. January 2008. (Format: TXT=41989 bytes) (Obsoletes RFC4507) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Saloweyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5077時間周は以下を時代遅れにします。 4507年のシスコシステムズカテゴリ: 規格は2008年1月にP.EronenノキアH.Tschofenigノキアジーメンスネットワークを追跡します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントはTransport Layer Security(TLS)サーバが、再開して、1クライアントあたりのセッション状態を維持するのを避けるのを可能にするメカニズムについて説明します。 TLSサーバは、セッションが状態であるとチケットの中にカプセル化して、それをクライアントに送ります。 クライアントは、次に、得られたチケットを使用することでセッションを再開できます。 このドキュメントはRFC4507を時代遅れにします。
Salowey, et al. Standards Track [Page 1] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[1ページ]RFC5077
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7
3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8
3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9
4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12
5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13
5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13
5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13
5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Discussion of Changes to RFC 4507 . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 .33.1について議定書の中で述べてください。 概要. . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2。 SessionTicket TLS拡張子. . . . . . . . . . . . . . . 7 3.3。 NewSessionTicket握手メッセージ. . . . . . . . . . . . 8 3.4。 TLSセッションID. . . . . . . . . . . . . 9 4との相互作用。 お勧めのチケット工事. . . . . . . . . . . . . . . 10 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 5.1。 セッション. . . . . . . . . . . . . . . . . . 12 5.2を無効にします。 盗まれたチケット. . . . . . . . . . . . . . . . . . . . . . 12 5.3。 偽造チケット. . . . . . . . . . . . . . . . . . . . . . 12 5.4。 サービス不能攻撃. . . . . . . . . . . . . . . . 12 5.5。 チケット保護キー管理. . . . . . . . . . . . . 13 5.6。 チケット生涯. . . . . . . . . . . . . . . . . . . . . 13 5.7。 チケット形式と分配体系. . . . 13 5.8を交替してください。 アイデンティティプライバシー、匿名、およびUnlinkability. . . . . . 14 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 14 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 15 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 15 8.2。 RFC4507.17への変化の有益な参照. . . . . . . . . . . . . . . . . . 15付録A.議論
Salowey, et al. Standards Track [Page 2] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[2ページ]RFC5077
1. Introduction
1. 序論
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サーバでセッション特有の状態を必要としないでTransport Layer Security(TLS)セッションを再開する方法を定義します。このメカニズムはどんなTLS ciphersuiteと共にも使用されるかもしれません。 このドキュメントは[RFC2246]で定義されたTLS1.0と[RFC4346]で定義されたTLS1.1の両方に適用されます。 メカニズムは、[RFC4366]で定義されたTLS拡張子を利用して、新しいTLSメッセージタイプを定義します。
This mechanism is useful in the following situations:
このメカニズムは以下の状況で役に立ちます:
1. servers that handle a large number of transactions from different
users
1. 異なったユーザから多くのトランザクションを扱うサーバ
2. servers that desire to cache sessions for a long time
2. 長い間セッションをキャッシュすることを望んでいるサーバ
3. ability to load balance requests across servers
3. サーバの向こう側にバランス要求をロードする能力
4. embedded servers with little memory
4. 少ないメモリがある埋め込まれたサーバ
This document obsoletes RFC 4507 [RFC4507] to correct an error in the encoding that caused the specification to differ from deployed implementations. At the time of this writing, there are no known implementations that follow the encoding specified in RFC 4507. This update to RFC 4507 aligns the document with currently deployed implementations. More details of the change are given in Appendix A.
このドキュメントは、仕様が配布している実装と異なっていたコード化で誤りを改めるために、RFC4507[RFC4507]を時代遅れにします。 この書くこと時点で、RFC4507で指定されたコード化に続く実装が知られていません。 RFC4507へのこのアップデートは現在配布している実装にドキュメントを一直線にします。 Appendix Aで変化に関するその他の詳細を与えます。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Protocol
3. プロトコル
This specification describes a mechanism to distribute encrypted session-state information to the client in the form of a ticket and a mechanism to present the ticket back to the server. The ticket is created by a TLS server and sent to a TLS client. The TLS client presents the ticket to the TLS server to resume a session. Implementations of this specification are expected to support both mechanisms. Other specifications can take advantage of the session tickets, perhaps specifying alternative means for distribution or selection. For example, a separate specification may describe an
この仕様は、チケットをサーバに贈って戻すためにチケットとメカニズムの形のクライアントに暗号化されたセッション州の情報を分配するためにメカニズムについて説明します。チケットをTLSサーバで作成して、TLSクライアントに送ります。 TLSクライアントは、セッションを再開するためにTLSサーバにチケットを贈ります。 この仕様の実装が両方のメカニズムをサポートすると予想されます。他の仕様はセッションチケットを利用できます、恐らく分配か選択のための代替の手段を指定して。 例えば、別々の仕様は説明するかもしれません。
Salowey, et al. Standards Track [Page 3] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[3ページ]RFC5077
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拡張子を使用する方法を交替してください。 この振舞いは、ドキュメントの範囲を超えていて、別々の仕様で説明される必要があるでしょう。
3.1. Overview
3.1. 概要
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.
サーバがこのメカニズムを使用したいと思うなら、それはセッション状態(ciphersuiteやマスター秘密などの)をキーによってサーバだけに知られていて、暗号化されて保全によって保護されたチケットとして保存します。チケットは、セクション3.3で説明されたNewSessionTicket TLS握手メッセージを使用することでクライアントに分配されます。 ChangeCipherSpecメッセージの前にTLS握手の間、このメッセージを送ります、サーバが首尾よくクライアントのFinishedメッセージについて確かめた後に。
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(空のSessionTicket拡張子)-------->ServerHello(空のSessionTicket拡張子)証明書*ServerKeyExchange*CertificateRequest*<。-------- ServerHelloDone証明書*ClientKeyExchange CertificateVerify*[ChangeCipherSpec]は終わりました。-------->NewSessionTicket[ChangeCipherSpec]<。-------- 完成アプリケーションデータ<。------->アプリケーションデータ
Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
図1: 新しいセッションチケットを発行する完全な握手のためのメッセージ流動
Salowey, et al. Standards Track [Page 4] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[4ページ]RFC5077
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はRFC4507から拡大と変化のコード化の詳述を提供します。 サーバは、次に、容認されたチケットを解読して、チケットの正当性について確かめて、チケットのコンテンツからセッション状態を検索して、セッションを再開するのにこの状態を使用します。 TLS Session IDとの相互作用はセクション3.4で説明されます。 サーバが首尾よくクライアントのチケットについて確かめるなら、それは、ServerHelloの後にNewSessionTicket握手メッセージを含んでいることによって、チケットを取り替えるかもしれません。
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
クライアントServer ClientHello(SessionTicket拡張子)-------->ServerHello(空のSessionTicket拡張子)NewSessionTicket[ChangeCipherSpec]<。-------- 終わっている[ChangeCipherSpec]は終わりました。-------->アプリケーションデータ<。------->アプリケーションデータ
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握手メッセージを含んでいなくて、サーバがこのとき新しいチケットを発行したがっていなくて、それはただ握手を終了します。 これは以下に示されます(この流れがRFC4346の図1と同じです、最初のメッセージにおけるSessionTicket拡張子を除いて):
Salowey, et al. Standards Track [Page 5] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[5ページ]RFC5077
Client Server
クライアントサーバ
ClientHello
(SessionTicket extension) -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello(SessionTicket拡張子)-------->ServerHello証明書*ServerKeyExchange*CertificateRequest*<。-------- ServerHelloDone証明書*ClientKeyExchange CertificateVerify*[ChangeCipherSpec]は終わりました。-------->[ChangeCipherSpec]<。-------- 完成アプリケーションデータ<。------->アプリケーションデータ
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.
また、図3と同様の交換を持っているのもクライアントがセッションを再開するのにSessionTicket拡張子を使用するRFC4346の図2で定義された簡略化された握手を使用するのにおいて許されていますが、サーバは、新しいチケットを発行することを願わないで、またしたがって、SessionTicket拡張子を送りません。
If the server rejects the ticket, it may still wish to issue a new ticket after performing the full handshake as shown below (this flow is identical to Figure 1, except the SessionTicket extension in the ClientHello is not empty):
サーバがチケットを拒絶するなら、以下に示すように完全な握手を実行した後に、まだ新しいチケットを発行していたがっているかもしれません(この流れは図1と同じです、そして、ClientHelloのSessionTicket拡張子は空ではありません):
Salowey, et al. Standards Track [Page 6] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[6ページ]RFC5077
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拡張子)-------->ServerHello(空のSessionTicket拡張子)証明書*ServerKeyExchange*CertificateRequest*<。-------- ServerHelloDone証明書*ClientKeyExchange CertificateVerify*[ChangeCipherSpec]は終わりました。-------->NewSessionTicket[ChangeCipherSpec]<。-------- 完成アプリケーションデータ<。------->アプリケーションデータ
Figure 4: Message Flow for Server Rejecting Ticket, Performing Full
Handshake, and Issuing New Session Ticket
図4: 完全な握手を実行して、チケットを拒絶するサーバのためのメッセージ流動と、新しいセッションチケットを発行すること。
3.2. SessionTicket TLS Extension
3.2. SessionTicket TLS拡張子
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を受け取らないなら、サーバはこの拡大を送ってはいけません。
Salowey, et al. Standards Track [Page 7] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[7ページ]RFC5077
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.
サーバがチケットについて確かめないなら、それは完全な握手を実行することへ後ろへ下がります。 サーバでチケットを受け入れますが、握手が失敗するなら、クライアントSHOULDはチケットを削除します。
The SessionTicket extension has been assigned the number 35. The extension_data field of SessionTicket extension contains the ticket.
No.35をSessionTicket拡張子に割り当ててあります。 SessionTicket拡張子の拡大_データ・フィールドはチケットを含んでいます。
3.3. NewSessionTicket Handshake Message
3.3. NewSessionTicket握手メッセージ
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握手メッセージにNo.4を割り当てました、そして、このセクションの端で定義を与えます。 チケット_生涯_ヒント分野はチケットがどれくらい長い間保存されるべきであるかに関するサーバからのヒントを含んでいます。 チケットが受け取られている時に比例して値は秒に32ビットの符号のない整数としてネットワークバイトオーダーで生涯を示します。 ゼロの値は、チケットの寿命が不特定であることを示すために予約されます。 時間が期限が切れると、クライアントSHOULDはチケットと準国家を削除します。 それは前にローカルの方針に基づいたチケットを削除するかもしれません。 サーバは有効であるとしてチケット_生涯_ヒントで述べられていることよりさらに短いか長い期間の間、チケットを処理するかもしれません。
Salowey, et al. Standards Track [Page 8] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[8ページ]RFC5077
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;
_要求: こんにちは、HelloRequestをケースに入れてください; _: こんにちは、クライアントClientHelloをケースに入れてください; _: こんにちは、サーバServerHelloをケースに入れてください; 証明書をケースに入れてください: 証明書; ケースサーバ_キー_交換: ServerKeyExchange;は証明書_要求をケースに入れます: CertificateRequest; _行われた_: こんにちは、ケースサーバServerHelloDone;は証明書をケースに入れます。struct、HandshakeType msg_タイプ; uint24の長さ;が(HandshakeType)を選択する、_CertificateVerify; ケースクライアント_キー_交換: ClientKeyExchange; ケースは終わりました: 終わりました; 以下について確かめてください、そして、セッション_チケット: NewSessionTicketをケースに入れてください;、/*NEW*/、ボディー; 握手。
struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>;
} NewSessionTicket;
struct uint32チケット_生涯_ヒント; 不透明なチケット<0..2^16-1>;NewSessionTicket。
3.4. Interaction with TLS Session ID
3.4. TLS Session IDとの相互作用
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のSHOULDインクルードの人影のないSession IDです。 サーバがチケットを拒絶して、完全な握手へ後ろへ下がるなら、それは、statefulセッション再開のサポートを示すために非人影のないSession IDを含むかもしれません。 クライアントがサーバからセッションチケットを受け取るなら、それはServerHelloで送られたどんなSession 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でSession IDを生成して、入れるかもしれません。 サーバがチケットを受け入れて、Session IDが人影がなくないなら、同じSession IDが存在していた状態で、それはClientHelloで応じなければなりません。 これはそれが完全な握手へ後ろへ下がっている時からのセッションを容易に差別化するサーバが再開するクライアントに許容します。 クライアントがSession IDを生成するので、サーバはチケットを有効にするとき特定の値を持っているSession IDを当てにされてはいけません。 チケットがクライアントによって贈られるなら、サーバは、statefulセッション再開にClientHelloでSession IDを使用するのを試みてはいけません。 あるいはまた、クライアントはClientHelloで人影のないSession IDを入れるかもしれません。 この場合、クライアントは、ServerHelloで送られたSession IDを無視して、サーバがその後の握手メッセージでセッションを再開しているかどうかと決心しています。
Salowey, et al. Standards Track [Page 9] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[9ページ]RFC5077
4. Recommended Ticket Construction
4. お勧めのチケット工事
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].
サーバは2個の異なったキーを使用します: HMAC-SHA-256[RFC4634]のためのCipher Block Chaining(CBC)モード[CBC]暗号化と1個の256ビットのキーのエー・イー・エス(AES)[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;
struct不明瞭な主要な_名[16]; 不透明なiv[16]; 不透明な暗号化された_州の<0..2^16-1>; 不透明なmac[32];のチケット。
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.
ここで、主要な_名は、チケットを保護するのに使用される特定のセットのキーを特定するのに役立ちます。 それは、サーバが容易にそれが発行したチケットを認識するのを可能にします。 主要な_名は、サーバの間の衝突を避けるために手当たりしだいに生成されるべきです。 1つの可能性はサーバが始められるときはいつも、新しいランダムキーと主要な_が名前であると生成することです。
The actual state information in encrypted_state is encrypted using 128-bit AES in CBC mode with the given IV. The Message Authentication Code (MAC) is calculated using HMAC-SHA-256 over key_name (16 octets) and IV (16 octets), followed by the length of the encrypted_state field (2 octets) and its contents (variable length).
暗号化された_状態の実際の州の情報は、与えられたIVと共にCBCモードで128ビットのAESを使用することで暗号化されています。 メッセージ立証コード(MAC)は、暗号化された_州の分野(2つの八重奏)とそのコンテンツ(可変長)の長さがあとに続いた主要な_名前(16の八重奏)とIV(16の八重奏)の上でHMAC-SHA-256を使用することで計算されます。
Salowey, et al. Standards Track [Page 10] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[10ページ]RFC5077
struct {
ProtocolVersion protocol_version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque master_secret[48];
ClientIdentity client_identity;
uint32 timestamp;
} StatePlaintext;
struct ProtocolVersionプロトコル_バージョン; CipherSuite暗号_スイート; CompressionMethod圧縮_メソッド; 不明瞭なマスター_秘密[48]; ClientIdentityのクライアント_アイデンティティ; uint32タイムスタンプ;StatePlaintext。
enum {
anonymous(0),
certificate_based(1),
psk(2)
} ClientAuthenticationType;
匿名の(0)、証明書_に基づいている(1)、psk(2)をenumする、ClientAuthenticationType。
struct {
ClientAuthenticationType client_authentication_type;
select (ClientAuthenticationType) {
case anonymous: struct {};
case certificate_based:
ASN.1Cert certificate_list<0..2^24-1>;
case psk:
opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
};
} ClientIdentity;
struct、ClientAuthenticationTypeクライアント_認証_タイプ; (ClientAuthenticationType)を選択してください、ケース匿名:、struct、;、_が基礎づけた証明書をケースに入れてください: ASN.1Certが_リスト<0..2^24-1>; ケースpsk: 不透明なpsk_のアイデンティティ<0..2^16-1>; [RFC4279]*/からの/*を証明する ;、ClientIdentity。
The structure StatePlaintext stores the TLS session state including the master_secret. The timestamp within this structure allows the TLS server to expire tickets. To cover the authentication and key exchange protocols provided by TLS, the ClientIdentity structure contains the authentication type of the client used in the initial exchange (see ClientAuthenticationType). To offer the TLS server with the same capabilities for authentication and authorization, a certificate list is included in case of public-key-based authentication. The TLS server is therefore able to inspect a number of different attributes within these certificates. A specific implementation might choose to store a subset of this information or additional information. Other authentication mechanisms, such as Kerberos [RFC2712], would require different client identity data. Other TLS extensions may require the inclusion of additional data in the StatePlaintext structure.
構造StatePlaintextはマスター_秘密を含むTLSセッション州を保存します。 この構造の中のタイムスタンプで、TLSサーバはチケットを吐き出すことができます。 TLSによって提供された認証と主要な交換プロトコルを含むために、ClientIdentity構造は初期の交換に使用されるクライアントの認証タイプを含んでいます(ClientAuthenticationTypeを見てください)。 認証と承認のために同じ能力があるTLSサーバを提供するために、証明書リストは公開鍵ベースの認証の場合に含まれています。 したがって、TLSサーバはこれらの証明書の中の多くの異なった属性を点検できます。 特定の実装は、この情報か追加情報の部分集合を保存するのを選ぶかもしれません。 ケルベロスなどの他の認証機構[RFC2712]は異なったクライアントアイデンティティデータを必要とするでしょう。 他のTLS拡張子はStatePlaintext構造での追加データの包含を必要とするかもしれません。
Salowey, et al. Standards Track [Page 11] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[11ページ]RFC5077
5. Security Considerations
5. セキュリティ問題
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.
実装は、チケットの処理が以下で説明されるようにサービスの否定の可能性を増強しないのを保証するために注意されるべきです。
5.1. Invalidating Sessions
5.1. セッションを無効にします。
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つのセッションの情報はマスター秘密か異なったセッションを攻撃する利点を提供しません。 セッション無効にする体系が使用されているなら、攻撃者が選ばれたセッションを無効にすることができないのを保証するためにセッションを無効にするのにコンテンツを使用する前に、実装はチケットの保全について確かめるべきです。
5.2. Stolen Tickets
5.2. 盗まれたチケット
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サーバは強い暗号化と保全保護を使用しなければなりません。
5.3. Forged Tickets
5.3. 偽造チケット
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などの強い保全保護アルゴリズムを使用することで保護されるなら、この攻撃は可能ではありません。
5.4. Denial of Service Attacks
5.4. サービス不能攻撃
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
お勧めのチケット形式で定義された主要な_名前欄は、サーバが効率的に、それが発行しなかったチケットを拒絶するのを助けます。 しかしながら、敵は、発信するために多くのチケットを保存するか、または生成することができました。
Salowey, et al. Standards Track [Page 12] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[12ページ]RFC5077
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サーバに。 サービスの否定の可能性を最小にするために、チケットの検証は軽量であるべきです(例えば、効率的な対称鍵暗号アルゴリズムを使用します)。
5.5. Ticket Protection Key Management
5.5. チケット保護キー管理
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.
チケットを保護するのに使用されるキーの管理の余すところのない解説はこのドキュメントの範囲を超えています。 RECOMMENDED習慣のリストを以下に与えます。
o The keys should be generated securely following the randomness
recommendations in [RFC4086].
o [RFC4086]でしっかりと偶発性推薦に続いて、キーは生成されるべきです。
o The keys and cryptographic protection algorithms should be at
least 128 bits in strength. Some ciphersuites and applications
may require cryptographic protection greater than 128 bits in
strength.
o キーと暗号の保護アルゴリズムは強さにおいて少なくとも128ビットであるべきです。 いくつかのciphersuitesとアプリケーションが強さにおける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 チケット形式か暗号の保護アルゴリズムが変化するなら、キーを変えるべきです。
5.6. Ticket Lifetime
5.6. チケット生涯
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クライアントに与えるかもしれません。 チケットの寿命が不特定であるかもしれないので、クライアントには、それがいつチケットを捨てるかを決定するそれ自身のローカルの方針があります。
5.7. Alternate Ticket Formats and Distribution Schemes
5.7. 代替のチケット形式と分配体系
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.
本書では定義されたチケット書式か分配体系が使用されていないなら、ソリューションのセキュリティを分析しながら、高度の注意を中に入れなければなりません。 秘密鍵などの秘密情報をクライアントに移すなら、特に、攻撃者がキーを入手するか、または変更するのを防ぐのに安全なコミュニケーションを使用しそれを終わらなければなりません。 また、チケットで、システムのセキュリティにおける不履行を防ぐために強い暗号のテクニックでその保全と秘密性を保護しなければなりません。
Salowey, et al. Standards Track [Page 13] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[13ページ]RFC5077
5.8. Identity Privacy, Anonymity, and Unlinkability
5.8. アイデンティティプライバシー、匿名、およびUnlinkability
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握手を観測する同じチケットが、使用されて、したがって、同じコミュニケーション終点に属すと結論づけているところの能力です。 本書では説明されたチケットメカニズムを使用するアプリケーション設計者は、unlinkability[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 renegotiation握手を使用するチケットを発行するのが可能であることに注意されるべきです。 これは、いくらかのプライバシーとunlinkabilityがいくつかの環境で問題であると扱うのを助けるかもしれません。
6. Acknowledgements
6. 承認
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ワーキンググループのエリック・レスコラ、モハマドBadra、ティムDierks、ネルソンBolyard、ナンシーCam-Winget、デヴィッド・マグリュー、ロブDugal、ラスHousley、Amirハーズバーグ、バーナードAboba、およびメンバー。
[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 ciphersuitesのケルベロス[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.
また、作者はジャン・ノルドクビストに感謝したがっています。(ノルドクビストは、このドキュメントによって修正されたRFC4507でコード化誤りを見つけました)。 さらに、Nagendra Modadugu、Wan-Tehチャン、およびマイケルD'Erricoはこのドキュメントのレビューの間、役に立つフィードバックを提供しました。
Salowey, et al. Standards Track [Page 14] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[14ページ]RFC5077
7. IANA Considerations
7. IANA問題
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は35のTLS内線電話番号を[RFC4366]で定義されたExtensionType値のTLS登録からSessionTicket 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はTLS HandshakeType No.4を[RFC4346]で定義されたHandshakeType値のTLS登録からNewSessionTicket握手タイプに割り当てました。
This document does not require any actions or assignments from IANA.
このドキュメントはIANAからどんな動作や課題も必要としません。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4366]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、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)セッション再開を輸送します」、RFC4507、2006年5月。
8.2. Informative References
8.2. 有益な参照
[AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information Processing
Standards (FIPS) Publication 197, November 2001.
2001年11月の[AES]米国商務省標準技術局、「エー・イー・エス(AES)」連邦政府の情報処理規格(FIPS)公表197。
[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.
http://dud.inf.tu-dresden.de/はやがて、/をliteraturします。[ANON] Pfitzmann、A.、およびM.ハンセン、「匿名、Unlinkability、Unobservability、偽名、およびアイデンティティ管理--、用語のための統合提案、」、_Terminology_v0.26-1.pdfバージョン0.26(2005年12月)。
Salowey, et al. Standards Track [Page 15] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[15ページ]RFC5077
[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のためのクライアントサイドキャッシュ」と情報のTransactionsとSystem Security(TISSEC)、Volume7、Issue4、2004年11月。
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[RFC2712] MedvinskyとA.とM.Hur、「トランスポート層セキュリティ(TLS)へのケルベロス暗号スイートの追加」、RFC2712、1999年10月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[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)」、RFC4120 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)のためのあらかじめ共有された主要なCiphersuites」、RFC4279、2005年12月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634] イーストレークとD.とT.ハンセン、「米国の安全なハッシュアルゴリズム(SHAとHMAC-SHA)」、RFC4634、2006年7月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007.
[RFC4851]カム-Winget、N.、マグリュー、D.、Salowey、J.、およびH.周、「Secure Tunneling拡張認証プロトコルMethodを通したFlexible Authentication(EAP-FAST)」、RFC4851(2007年5月)。
[SC97] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on
Information and Communication Security (ICICS '97) , 1997.
情報とコミュニケーションセキュリティ(ICICS97年)の国際労働者協会コンファレンス、1997年の[SC97]香気とT.とP.Nikander、「状態がないコネクションズ」、議事。
Salowey, et al. Standards Track [Page 16] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[16ページ]RFC5077
Appendix A. Discussion of Changes to RFC 4507
RFC4507への変化の付録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].
RFC4507[RFC4507]は、クライアントの上で維持される暗号化されたチケットを指定することによってサーバサイド州を維持しないでTLSセッションを再開するためにメカニズムを定義します。 クライアントがこのチケットをSessionTicketのサーバに贈る、こんにちは、拡大。 RFC4507でのコード化はTLS[RFC4346]で指定されたXDRスタイルコード化を使用しました。
An error in the encoding caused the specification to differ from deployed implementations. At the time of this writing there are no known implementations that follow the encoding specified in RFC 4507. This update to RFC 4507 aligns the document with these currently deployed implementations.
異なっている仕様が引き起こされたコード化における誤りは実装を配布しました。 この書くこと時点で、RFC4507で指定されたコード化に続く知られている実装が全くありません。 RFC4507へのこのアップデートは現在実装であると配布されているこれらにドキュメントを一直線にします。
Erroneous encoding in RFC 4507 resulted in two length fields; one for the extension contents and one for the ticket itself. Hence, for a ticket that is 256 bytes long and begins with the hex value FF FF, the encoding of the extension would be as follows according to RFC 4507:
RFC4507での誤ったコード化は2つの長さの分野をもたらしました。 拡大コンテンツのためのものとチケット自体のためのもの。 したがって、256バイト長であり、十六進法価値のFF FFと共に始まるチケットに関して、RFC4507によると、拡大のコード化は以下の通りでしょう:
00 23 Ticket Extension type 35
01 02 Length of extension contents
01 00 Length of ticket
FF FF .. .. Actual ticket
00 23チケットExtensionはチケットFF FFの拡大コンテンツ01 00Lengthの35 01 02Lengthをタイプします。 .. 実際のチケット
The update proposed in this document reflects what implementations actually encode, namely it removes the redundant length field. So, for a ticket that is 256 bytes long and begins with the hex value FF FF, the encoding of the extension would be as follows according to this update:
本書では提案されたアップデートは実装が実際にコード化することを反映します、すなわち、それが余分な長さの野原を取り除きます。 それで、256バイト長であり、十六進法価値のFF FFと共に始まるチケットに関して、このアップデートに従って、拡大のコード化は以下の通りでしょう:
00 23 Extension type 35
01 00 Length of extension contents (ticket)
FF FF .. .. Actual ticket
拡大コンテンツ(チケット)FF FFの00 23拡大タイプ35 01 00Length。 .. 実際のチケット
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
このドキュメントに従うクライアントからチケット拡大を受けるRFC4507によると、実装されたサーバはこのチケットの長さとしてチケットの最初の2バイトを解釈するでしょう。 これは矛盾した長さの分野か最初の2バイトなくなるチケットの処理に結果として生じるでしょう。 前者の場合、サーバは奇形の長さに基づく要求を拒絶するべきです。 2番目の場合では、サーバは奇形のチケット、不正確な主要なバージョン、または失敗した復号化に基づくチケットを拒絶するべきです。 RFC4507拡張子を受け取るこのアップデートに基づいているサーバ実装は最初の長さの分野を解釈するでしょう。
Salowey, et al. Standards Track [Page 17] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[17ページ]RFC5077
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番目の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拡張子のコード化がRFC4507であいまいであったことに注意してください。 RFC4507実装は以下としてそれをコード化したかもしれません。
00 23 Extension type 35
00 02 Length of extension contents
00 00 Length of ticket
チケットの拡大コンテンツ00 00Lengthの00 23拡大タイプ35 00 02Length
or it may have encoded it the same way as this update:
または、このアップデートとして同じようにそれをコード化したかもしれません:
00 23 Extension type 35
00 00 Length of extension contents
拡大コンテンツの00 23拡大タイプ35 00 00Length
A server wishing to support RFC 4507 clients should respond to an empty SessionTicket extension encoded the same way as it received it.
4507人のクライアントをRFCにサポートしたがっているサーバはずっとそれを受けたように同じようにコード化された空の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.
サーバ実装は4507年のRFC実装を検出できるように、チケットを組み立てることができます、1つが存在したなら、有効な長さと区別できるチケットの始めにクッキーを含んでいることによって。 例えば、実装がまず第一にチケットを組み立てたなら十六進法がFF FFを評価して、次に、それは、分野が提示する長さのタイプからチケットがどこで始まるかを測定して、長さを正しく測定するかもしれません。
This document makes a few additional changes to RFC 4507 listed below.
このドキュメントはいくつかの付加的な変化を以下に記載されたRFC4507にします。
o Clarifying that the server can allow session resumption using a
ticket without issuing a new ticket in Section 3.1.
o それをはっきりさせて、サーバは、セクション3.1で新しいチケットを発行しないでチケットを使用することでセッション再開を許すことができます。
o Clarifying that the lifetime is relative to when the ticket is
received in section 3.3.
o それをはっきりさせて、寿命はチケットがセクション3.3で受け取られる時に比例しています。
o Clarifying that the NewSessionTicket handshake message is included
in the hash generated for the Finished messages in Section 3.3.
o それをはっきりさせて、NewSessionTicket握手メッセージはセクション3.3のFinishedメッセージのために生成されたハッシュに含まれています。
o Clarifying the interaction with TLS Session ID in Section 3.4.
o セクション3.4でTLS Session IDとの相互作用をはっきりさせます。
o Recommending the use of SHA-256 for the integrity protection of
the ticket in Section 4.
o SHA-256のセクション4における、チケットの保全保護の使用を推薦します。
o Clarifying that additional data can be included in the
StatePlaintext structure in Section 4.
o セクション4のStatePlaintext構造にその追加データをはっきりさせるのを含むことができます。
Salowey, et al. Standards Track [Page 18] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[18ページ]RFC5077
Authors' Addresses
作者のアドレス
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
第3ジョゼフSaloweyシスコシステムズ2901Aveワシントン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フィン-00045Nokia Groupフィンランド
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
Salowey, et al. Standards Track [Page 19] RFC 5077 Stateless TLS Session Resumption January 2008
Salowey、他 TLSセッション再開2008年1月に状態がない標準化過程[19ページ]RFC5077
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Salowey, et al. Standards Track [Page 20]
Salowey、他 標準化過程[20ページ]
一覧
スポンサーリンク
