[要約] RFC 6896は、KoanLogicのSecure Cookie Sessions for HTTP（SCS）に関する仕様です。SCSは、HTTPセッションのセキュリティを向上させるための仕組みであり、セキュアなクッキーを使用してセッション情報を保護します。このRFCの目的は、SCSの仕様と実装の詳細を提供し、セッションハイジャックなどの攻撃からセッションデータを保護することです。
Independent Submission S. Barbato
Request for Comments: 6896 S. Dorigotti
Category: Informational T. Fossati, Ed.
ISSN: 2070-1721 KoanLogic
March 2013
SCS: KoanLogic's Secure Cookie Sessions for HTTP
SCS：HTTP用のKoanLogicのセキュアCookieセッション
Abstract
概要
This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.
このメモは、対称的に暗号化され、認証され、起源がタイムスタンプされたトークンを運ぶための汎用URIとHTTPヘッダーに適したエンベロープを定義します。また、HTTP Cookieに基づく単純なプロトコルを介した、このようなトークンの1つの可能な使用法についても説明します。
Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load-balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.
Secure Cookie Session（SCS）の使用例は、HTTP経由の承認済みコンテンツの配信（例：帯域外署名付きURI）から、ディスクレス組み込みデバイス（例：Small Office、Home）を使用したブラウザーセッションの保護まで、幅広いアプリケーションをカバーします。 Office（SOHO）ルーター）またはWebサーバー（高可用性または負荷分散要件があり、共有ストレージや強制ピアリングを使用する代わりに、アプリケーション状態の処理をクライアントに委任する必要がある場合があります）。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6896.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6896で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Requirements Language ...........................................4
3. SCS Protocol ....................................................5
3.1. SCS Cookie Description .....................................5
3.1.1. ATIME ...............................................6
3.1.2. DATA ................................................6
3.1.3. TID .................................................7
3.1.4. IV ..................................................7
3.1.5. AUTHTAG .............................................7
3.2. Crypto Transform ...........................................8
3.2.1. Choice and Role of the Framing Symbol ...............8
3.2.2. Cipher Set ..........................................9
3.2.3. Compression .........................................9
3.2.4. Cookie Encoding .....................................9
3.2.5. Outbound Transform ..................................9
3.2.6. Inbound Transform ..................................10
3.3. PDU Exchange ..............................................12
3.3.1. Cookie Attributes ..................................12
3.3.1.1. Expires ...................................12
3.3.1.2. Max-Age ...................................12
3.3.1.3. Domain ....................................13
3.3.1.4. Secure ....................................13
3.3.1.5. HttpOnly ..................................13
4. Key Management and Session State ...............................13
5. Cookie Size Considerations .....................................15
6. Acknowledgements ...............................................15
7. Security Considerations ........................................15
7.1. Security of the Cryptographic Protocol ....................15
7.2. Impact of the SCS Cookie Model ............................16
7.2.1. Old Cookie Replay ..................................16
7.2.2. Cookie Deletion ....................................17
7.2.3. Cookie Sharing or Theft ............................18
7.2.4. Session Fixation ...................................18
7.3. Advantages of SCS over Server-Side Sessions ...............19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
Appendix A. Examples ..............................................22
A.1. No Compression ............................................22
A.2. Use Compression ...........................................22
This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens.
このメモは、対称的に暗号化され、認証され、起源がタイムスタンプされたトークンを運ぶための汎用URIとHTTPヘッダーに適したエンベロープを定義します。
It is generic in that it does not force any specific format upon the authenticated information, which makes SCS tokens flexible, easy, and secure to use in many different scenarios.
これは、認証された情報に特定の形式を強制しないという点で一般的であり、SCSトークンを柔軟、簡単、かつ安全に使用して、さまざまなシナリオで使用できます。
It is URI and HTTP header friendly, as it has been explicitly designed to be compatible with both the ABNF "token" syntax [RFC2616] (the one used for, e.g., Set-Cookie and Cookie headers) and the path or query syntax of HTTP URIs.
これは、ABNFの「トークン」構文[RFC2616]（たとえば、Set-CookieおよびCookieヘッダーに使用されるもの）と、そのパスまたはクエリ構文の両方と互換性があるように明示的に設計されているため、URIおよびHTTPヘッダーに対応しています。 HTTP URI。
This memo also describes one possible usage of such tokens via a simple protocol based on HTTP cookies that allows the establishment of "client mode" sessions. This is not their sole possible use. While no other operational patterns are outlined here, it is expected that SCS tokens may be easily employed as a building block for other types of HTTP-based applications that need to carry in-band secured information.
このメモは、「クライアントモード」セッションの確立を可能にするHTTP Cookieに基づく単純なプロトコルを介した、そのようなトークンの1つの可能な使用法についても説明しています。これが唯一の可能な使用法ではありません。ここでは他の操作パターンについて概説していませんが、SCSトークンは、インバンドで保護された情報を運ぶ必要がある他のタイプのHTTPベースのアプリケーションのビルディングブロックとして簡単に使用できると予想されます。
When SCS tokens are used to implement client-mode cookie sessions, the SCS implementer must fully understand the security implications entailed by the act of delegating the whole application state to the client (browser). In this regard, some hopefully useful security considerations have been collected in Section 7.2. However, please note that they may not cover all possible scenarios; therefore, they must be weighed carefully against the specific application threat model.
SCSトークンを使用してクライアントモードのCookieセッションを実装する場合、SCSの実装者は、アプリケーション全体の状態をクライアント（ブラウザ）に委任する行為に伴うセキュリティの影響を完全に理解する必要があります。この点に関して、セクション7.2で、期待される有用なセキュリティの考慮事項が収集されました。ただし、可能なシナリオをすべて網羅しているわけではないことに注意してください。したがって、特定のアプリケーションの脅威モデルに対して慎重に比較検討する必要があります。
An SCS server may be implemented within a web application by means of a user library that exposes the core SCS functionality and leaves explicit control over SCS tokens to the programmer, or transparently, by hiding a "diskless session" facility behind a generic session API abstraction, for example. SCS implementers are free to choose the model that best suits their needs.
SCSサーバーは、コアSCS機能を公開し、SCSトークンの明示的な制御をプログラマーに委任するユーザーライブラリによって、または一般的なセッションAPI抽象化の背後にある「ディスクレスセッション」機能を隠すことにより透過的に、Webアプリケーション内に実装できます。 、 例えば。 SCSの実装者は、ニーズに最適なモデルを自由に選択できます。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The SCS protocol defines:
SCSプロトコルは以下を定義します。
o the SCS cookie structure and encoding (Section 3.1);
o SCS Cookieの構造とエンコード（セクション3.1）
o the cryptographic transformations involved in SCS cookie creation and verification (Section 3.2);
o SCS Cookieの作成と検証に関連する暗号化変換（セクション3.2）。
o the HTTP-based PDU exchange that uses the Set-Cookie and Cookie HTTP headers (Section 3.3);
o Set-CookieおよびCookie HTTPヘッダーを使用するHTTPベースのPDU交換（3.3節）。
o the underlying key management model (Section 4).
o 基礎となる鍵管理モデル（セクション4）。
Note that the PDU is transmitted to the client as an opaque data block; hence, no interpretation nor validation is necessary. The single requirement for client-side support of SCS is cookie activation on the user agent. The origin server is the sole actor involved in the PDU manipulation process, which greatly simplifies the crypto operations -- especially key management, which is usually a pesky task.
PDUは不透明なデータブロックとしてクライアントに送信されることに注意してください。したがって、解釈も検証も必要ありません。 SCSのクライアント側サポートの唯一の要件は、ユーザーエージェントでのCookieのアクティブ化です。オリジンサーバーはPDUの操作プロセスに関与する唯一のアクターであり、暗号化操作、特に通常は厄介なタスクであるキー管理を大幅に簡素化します。
In the following sections, we assume S to be one or more interchangeable HTTP server entities (e.g., a server pool in a load-balanced or high-availability environment) and C to be the client with a cookie-enabled browser or any user agent with equivalent capabilities.
次のセクションでは、Sを1つ以上の交換可能なHTTPサーバーエンティティ（たとえば、負荷分散または高可用性環境のサーバープール）とし、CをCookie対応のブラウザーまたは任意のユーザーエージェントを持つクライアントと想定します。同等の機能を備えています。
S and C exchange a cookie (Section 3.3) whose cookie value consists of a sequence of adjacent non-empty values, each of which is the 'URL and Filename safe' Base64 encoding [RFC4648] of a specific SCS field.
SとCはCookieを交換し（3.3節）、そのCookie値は隣接する空でない値のシーケンスで構成され、それぞれが特定のSCSフィールドの「URLおよびファイル名セーフ」Base64エンコーディング[RFC4648]です。
(Hereafter, the encoded and raw versions of each SCS field are distinguished based on the presence, or lack thereof, of the 'e' prefix in their name, e.g., eATIME and ATIME.)
（以下、各SCSフィールドのエンコードされたバージョンと未加工のバージョンは、名前に「e」接頭辞が含まれるかどうかに基づいて区別されます（eATIMEやATIMEなど）。
Each SCS field is separated by its left and/or right sibling by means
of the %x7c ASCII character (i.e., '|'), as follows:
scs-cookie = scs-cookie-name "=" scs-cookie-value
scs-cookie-name = token
scs-cookie-value = eDATA "|" eATIME "|" eTID "|" eIV "|" eAUTHTAG
eDATA = 1*base64url-character
eATIME = 1*base64url-character
eTID = 1*base64url-character
eIV = 1*base64url-character
eAUTHTAG = 1*base64url-character
Figure 1
図1
Confidentiality is limited to the application-state information (i.e., the DATA field), while integrity and authentication apply to the entire cookie value.
機密性はアプリケーションの状態情報（つまり、DATAフィールド）に限定され、整合性と認証はCookie値全体に適用されます。
The following subsections describe the syntax and semantics of each SCS cookie field.
以下のサブセクションでは、各SCS Cookieフィールドの構文とセマンティクスについて説明します。
Absolute timestamp relating to the last read or write operation performed on session DATA, encoded as a HEX string holding the number of seconds since the UNIX epoch (i.e., since 00:00:00, Jan 1 1970).
セッションDATAで実行された最後の読み取りまたは書き込み操作に関連する絶対タイムスタンプ。UNIXエポック（1970年1月1日00:00:00以降）からの秒数を保持するHEX文字列としてエンコードされます。
This value is updated with each client contact and is used to identify expired sessions. If the delta between the received ATIME value and the current time on S is larger than a predefined "session_max_age" (which is chosen by S as an application-level parameter), a session is considered to be no longer valid, and is therefore rejected.
この値はクライアントの連絡先ごとに更新され、期限切れのセッションを識別するために使用されます。受信したATIME値とSの現在時刻の間の差分が、事前定義された「session_max_age」（Sによってアプリケーションレベルのパラメーターとして選択されます）よりも大きい場合、セッションは無効であると見なされ、拒否されます。 。
Such an expiration error may be used to force user logout from an SCS-cookie-based session, or hooked in the web application logic to display an HTML form requiring revalidation of user credentials.
このような有効期限エラーは、SCS Cookieベースのセッションからユーザーを強制的にログアウトさせるために使用するか、Webアプリケーションロジックにフックして、ユーザー資格情報の再検証を必要とするHTMLフォームを表示します。
Block of encrypted and optionally compressed data, possibly containing the current session state. Note that no restriction is imposed on the cleartext structure: the protocol is completely agnostic as to inner data layout.
暗号化され、オプションで圧縮されたデータのブロック。おそらく現在のセッション状態が含まれています。平文の構造には何の制限も課されていないことに注意してください。プロトコルは内部データのレイアウトに関して完全に不可知です。
Generally speaking, the plaintext is the "normal" cookie that would have been exchanged by S and C if SCS had not been used.
一般的に言って、プレーンテキストは、SCSが使用されていなかった場合にSとCによって交換される「通常の」Cookieです。
This identifier is equivalent to a Security Parameter Index (SPI) in a Data Security SA [RFC3740]) and consists of an ASCII string that uniquely identifies the transform set (keys and algorithms) used to generate this SCS cookie.
この識別子は、Data Security SA [RFC3740]のセキュリティパラメータインデックス（SPI）に相当し、このSCS Cookieの生成に使用されるトランスフォームセット（キーとアルゴリズム）を一意に識別するASCII文字列で構成されます。
SCS assumes that a key-agreement/distribution mechanism exists for environments in which S consists of multiple servers that provide a unique external identifier for each transform set shared amongst pool members.
SCSは、Sが複数のサーバーで構成され、プールメンバー間で共有される各トランスフォームセットに一意の外部識別子を提供する環境に、鍵の合意/配布メカニズムが存在すると想定しています。
Such a mechanism may safely downgrade to a periodic key refresh, if there is only one server in the pool and the key is generated in place -- i.e., it is not handled by an external source.
そのようなメカニズムは、プールにサーバーが1つしかなく、キーが適切に生成されている場合、つまり、外部ソースによって処理されない場合、定期的なキーの更新に安全にダウングレードできます。
However, when many servers act concurrently upon the same pool, a more sophisticated protocol, whose specification is out of the scope of the present document, must be devised (ideally, one that is able to handle key agreement for dynamic peer groups in a secure and efficient way, e.g., [CLIQUES] or [Steiner]).
ただし、多くのサーバーが同じプールで同時に動作する場合は、仕様が現在のドキュメントの範囲外であるより洗練されたプロトコルを考案する必要があります（理想的には、動的なピアグループのキー合意を安全に処理できるプロトコル）効率的な方法、たとえば[CLIQUES]または[Steiner]）。
Initialization Vector used for the encryption algorithm (see Section 3.2).
暗号化アルゴリズムに使用される初期化ベクトル（セクション3.2を参照）。
In order to avoid providing correlation information to a possible attacker with access to a sample of SCS cookies created using the same TID, the IV MUST be created randomly for each SCS cookie.
同じTIDを使用して作成されたSCS Cookieのサンプルへのアクセス権を持つ潜在的な攻撃者に相関情報を提供しないようにするために、IVは各SCS Cookieに対してランダムに作成する必要があります。
Authentication tag that is based on the plain string concatenation of the base64url-encoded DATA, ATIME, TID, and IV fields and is framed by the "|" separator (see also the definition of the Box() function in Section 3.2):
base64urlでエンコードされたDATA、ATIME、TID、およびIVフィールドのプレーンストリング連結に基づいており、「|」で囲まれた認証タグセパレーター（セクション3.2のBox()関数の定義も参照）：
AUTHTAG = HMAC(base64url(DATA) "|"
base64url(ATIME) "|"
base64url(TID) "|"
base64url(IV))
Note that, from a cryptographic point of view, the "|" character provides explicit authentication of the length of each supplied field, which results in a robust countermeasure against splicing attacks.
暗号化の観点から、「|」文字は、提供された各フィールドの長さの明示的な認証を提供します。これにより、スプライシング攻撃に対する堅牢な対策が得られます。
SCS could potentially use any combination of primitives capable of performing authenticated encryption. In practice, an encrypt-then-MAC approach [Kohno] with encryption utilizing the Cipher Block Chaining (CBC) mode and Hashed Message Authentication Code (HMAC) [RFC2104] authentication was chosen.
SCSは、認証された暗号化を実行できるプリミティブの任意の組み合わせを使用する可能性があります。実際には、Cipher Block Chaining（CBC）モードとHashed Message Authentication Code（HMAC）[RFC2104]認証を利用した暗号化を使用した、encrypt-then-MACアプローチ[Kohno]が選択されました。
The two algorithms MUST be associated with two independent keys.
2つのアルゴリズムは、2つの独立したキーに関連付けられている必要があります。
The following conventions will be used in the algorithm description (Sections 3.2.5 and 3.2.6):
アルゴリズムの説明では、次の規則が使用されます（セクション3.2.5および3.2.6）。
o Enc/Dec(): block encryption/decryption functions (Section 3.2.2);
o Enc / Dec()：暗号化/復号化機能をブロックします（セクション3.2.2）。
o HMAC(): authentication function (Section 3.2.2);
o HMAC()：認証関数（セクション3.2.2）;
o Comp/Uncomp(): compression/decompression functions (Section 3.2.3);
o Comp / Uncomp()：圧縮/解凍関数（セクション3.2.3）;
o e/d(): cookie-value encoding/decoding functions (Section 3.2.4);
o e / d()：Cookie値のエンコード/デコード関数（セクション3.2.4）;
o RAND(): random number generator [RFC4086];
o RAND()：乱数ジェネレータ[RFC4086];
o Box(): string boxing function. It takes an arbitrary number of base64url-encoded strings and returns the string obtained by concatenating each input in the exact order in which they are listed, separated by the "|" char. For example:
o Box()：文字列ボクシング関数。任意の数のbase64urlでエンコードされた文字列を受け取り、各入力を「|」で区切って、リストされている正確な順序で連結して得られた文字列を返します。チャー。例えば：
Box("akxI", "MTM", "Hadvo") = "akxI|MTM|Hadvo".
ボックス（ "akxI"、 "MTM"、 "Hadvo"）= "akxI | MTM | Hadvo"。
Note that the adoption of "|" as the framing symbol in the Box() function is arbitrary: any char allowed by the cookie-value ABNF in [RFC6265] is safe to be used as long it has empty intersection with the base64url alphabet.
「|」の採用に注意してくださいBox()関数のフレーミングシンボルは任意であるため、[RFC6265]のcookie値ABNFで許可されている任意の文字を使用しても、base64urlアルファベットとの空の交差がある限り、安全に使用できます。
It is also worth noting that the role of the framing symbol, which provides an implicit length indicator for each of the atoms, is key to the accuracy and security of SCS.
また、原子ごとに暗黙的な長さインジケーターを提供するフレーミングシンボルの役割が、SCSの精度とセキュリティにとって重要であることも注目に値します。
This is especially relevant when the authentication tag is computed (see Section 3.1.5). More specifically, the explicit inclusion of the framing symbol within the HMAC input seals the integrity of the blob as a whole together with each of its composing atoms in their exact position.
これは、認証タグが計算されるときに特に関連します（セクション3.1.5を参照）。より具体的には、HMAC入力内にフレーミングシンボルを明示的に含めることにより、ブロブの整合性が全体として、その構成原子のそれぞれが正確な位置に配置されます。
This feature makes the protocol robust against attacks aimed at disrupting the security of SCS PDUs by freely moving boundaries between adjacent atoms.
この機能は、隣接する原子間の境界を自由に移動することにより、SCS PDUのセキュリティを破壊することを目的とした攻撃に対してプロトコルを堅牢にします。
Implementers MUST support at least the following algorithms:
実装者は少なくとも以下のアルゴリズムをサポートしなければなりません：
o AES-CBC-128 for encryption [NIST-AES];
o 暗号化にはAES-CBC-128 [NIST-AES];
o HMAC-SHA1 with a 128-bit key for authenticity and integrity,
o 信頼性と整合性のための128ビットキーを備えたHMAC-SHA1、
which appear to be sufficiently secure in a broad range of use cases ([Bellare] [RFC6194]), are widely available, and can be implemented in a few kilobytes of memory, providing an extremely valuable feature for constrained devices.
幅広いユースケース（[Bellare] [RFC6194]）で十分に安全であるように見え、広く利用可能で、数キロバイトのメモリに実装できるため、制約のあるデバイスに非常に価値のある機能を提供します。
One should consider using larger cryptographic key lengths (192- or 256-bit) according to the actual security and overall system performance requirements.
実際のセキュリティおよび全体的なシステムパフォーマンス要件に従って、より長い暗号化キーの長さ（192ビットまたは256ビット）の使用を検討する必要があります。
Compression, which may be useful or even necessary when handling large quantities of data, is not compulsory (in such a case, Comp/ Uncomp is replaced by an identity matrix). If this function is enabled, the DEFLATE [RFC1951] format MUST be supported.
大量のデータを処理する場合に役立つ、または必要になる可能性がある圧縮は必須ではありません（そのような場合、Comp / Uncompは単位行列で置き換えられます）。この機能が有効になっている場合、DEFLATE [RFC1951]形式がサポートされている必要があります。
Some advice to SCS users: compression should not be enabled when handling relatively short and entropic state, such as pseudorandom session identifiers. Instead, large and quite regular state blobs could get a significant boost when compressed.
SCSユーザーへのアドバイス：疑似ランダムセッション識別子など、比較的短くエントロピーな状態を処理するときは、圧縮を有効にしないでください。代わりに、大きくて非常に規則的な状態のblobは、圧縮されたときに大幅に向上する可能性があります。
SCS cookie values MUST be encoded using the alphabet that is URL and filename safe (i.e., base64url) defined in Section 5 of Base64 [RFC4648]. This encoding is very widespread, falls smoothly into the encoding rules defined in Section 4.1.1 of [RFC6265], and can be safely used to supply SCS-based authorization tokens within a URI (e.g., in a query string or straight into a path segment).
SCS Cookie値は、Base64 [RFC4648]のセクション5で定義されているURLおよびファイル名に対して安全なアルファベット（つまり、base64url）を使用してエンコードする必要があります。このエンコーディングは非常に普及しており、[RFC6265]のセクション4.1.1で定義されたエンコーディングルールにスムーズに当てはまり、URI内のSCSベースの認証トークンを提供するために安全に使用できます（たとえば、クエリ文字列またはパスに直接）セグメント）。
The output data transformation, as seen by the server (the only actor that explicitly manipulates SCS cookies), is illustrated by the pseudocode in Figure 2.
サーバー（SCS Cookieを明示的に操作する唯一のアクター）から見た出力データ変換は、図2の疑似コードで示されています。
1. IV := RAND() 2. ATIME := NOW 3. DATA := Enc(Comp(plain-text-cookie-value), IV) 4. AUTHTAG := HMAC(Box(e(DATA), e(ATIME), e(TID), e(IV)))
1. IV：= RAND()2. ATIME：= NOW 3. DATA：= Enc（Comp（plain-text-cookie-value）、IV）4. AUTHTAG：= HMAC（Box（e（DATA）、e（ATIME） 、e（TID）、e（IV）））
Figure 2
図2
A new Initialization Vector is randomly picked (step 1). As previously mentioned (Section 3.1.4), this step is necessary to avoid providing correlation information to an attacker.
新しい初期化ベクトルがランダムに選択されます（ステップ1）。前述のとおり（セクション3.1.4）、このステップは、相関情報を攻撃者に提供しないようにするために必要です。
A new ATIME value is taken as the current timestamp according to the server clock (step 2).
新しいATIME値は、サーバーのクロックに従って現在のタイムスタンプとして取得されます（ステップ2）。
Since the only user of the ATIME field is the server, it is unnecessary for it to be synchronized with the client -- though it needs to use a fairly stable clock. However, if multiple servers are active in a load-balancing configuration, clocks SHOULD be synchronized to avoid errors in the calculation of session expiry.
ATIMEフィールドの唯一のユーザーはサーバーなので、かなり安定したクロックを使用する必要がありますが、クライアントと同期する必要はありません。ただし、負荷分散構成で複数のサーバーがアクティブな場合は、セッションの有効期限の計算でエラーが発生しないように、クロックを同期する必要があります（SHOULD）。
The plaintext cookie value is then compressed (if needed) and encrypted by using the key-set identified by TID (step 3).
次に、プレーンテキストのCookie値が圧縮され（必要な場合）、TIDで識別されるキーセットを使用して暗号化されます（ステップ3）。
If the length of (compressed) state is not a multiple of the block size, its value MUST be filled with as many padding bytes of equal value as the pad length -- as defined by the scheme given in Section 6.3 of [RFC5652].
（圧縮された）状態の長さがブロックサイズの倍数でない場合、その値は、[RFC5652]のセクション6.3で指定されているスキームで定義されているように、パッド長と同じ値のパディングバイトで埋める必要があります。
Then, the authentication tag, which encompasses each SCS field (along with lengths and relative positions), is computed by HMAC'ing the "|"-separated concatenation of their base64url representations using the key-set identified by TID (step 4).
次に、各SCSフィールドを（長さと相対位置とともに）囲む認証タグが、TIDによって識別されたキーセットを使用して、base64url表現の「|」で区切られた連結をHMACすることによって計算されます（ステップ4）。
Finally, the SCS-cookie-value is created as follows:
最後に、SCS-cookie-valueは次のように作成されます。
scs-cookie-value = Box(e(DATA), e(ATIME), e(TID), e(IV),
e(AUTHTAG))
The inbound transformation is described in Figure 3. Each of the 'e'-prefixed names shown has to be interpreted as the base64url-encoded value of the corresponding SCS field.
インバウンド変換については、図3で説明しています。示されている「e」プレフィックス付きの名前のそれぞれは、対応するSCSフィールドのbase64urlエンコード値として解釈する必要があります。
0. If (split_fields(scs-cookie-value) == ok) 1. tid' := d(eTID) 2. If (tid' is available) 3. tag' := d(eAUTHTAG) 4. tag := HMAC(Box(eDATA, eATIME, eTID, eIV)) 5. If (tag = tag') 6. atime' := d(eATIME) 7. If (NOW - atime' <= session_max_age) 8. iv' := d(eIV) data' := d(eDATA) 9. state := Uncomp(Dec(data', iv')) 10. Else discard PDU 11. Else discard PDU 12. Else discard PDU 13. Else discard PDU
0. If（split_fields（scs-cookie-value）== ok）1. tid '：= d（eTID）2. If（tid'が利用可能）3. tag '：= d（eAUTHTAG）4. tag：= HMAC（ Box（eDATA、eATIME、eTID、eIV））5. If（tag = tag '）6. atime'：= d（eATIME）7. If（NOW-atime '<= session_max_age）8. iv'：= d（ eIV）data '：= d（eDATA）9. state：= Uncomp（Dec（data'、iv '））10. Else discard PDU 11. Else discard PDU 12. Else discard PDU 13. Else discard PDU
Figure 3
図3
First, the inbound scs-cookie-value is broken into its component fields, which MUST be exactly 5, and each at least the minimum length specified in Figure 3 (step 0). In case any of these preliminary checks fails, the PDU is discarded (step 13); else, TID is decoded to allow key-set lookup (step 1).
最初に、インバウンドscs-cookie-valueはそのコンポーネントフィールドに分割されます。コンポーネントフィールドは正確に5でなければならず、それぞれが少なくとも図3で指定された最小の長さです（ステップ0）。これらの予備チェックのいずれかが失敗した場合、PDUは破棄されます（ステップ13）。それ以外の場合は、TIDがデコードされ、キーセットの検索が可能になります（ステップ1）。
If the cryptographic credentials (encryption and authentication algorithms and keys identified by TID) are unavailable (step 12), the inbound SCS cookie is discarded since its value has no chance to be interpreted correctly. This may happen for several reasons: e.g., if a device without storage has been reset and loses the credentials stored in RAM, if a server pool node desynchronizes, or in case of a key compromise that forces the invalidation of all current TIDs, etc.
暗号化資格情報（TIDによって識別される暗号化および認証アルゴリズムとキー）が使用できない場合（ステップ12）、その値が正しく解釈される機会がないため、インバウンドSCS Cookieは破棄されます。これは、いくつかの理由で発生する可能性があります。たとえば、ストレージのないデバイスがリセットされ、RAMに保存されている資格情報が失われた場合、サーバープールノードが同期解除された場合、または現在のすべてのTIDを強制的に無効にするキーの侵害が発生した場合などです。
When a valid key-set is found (step 2), the AUTHTAG field is decoded (step 3) and the (still) encoded DATA, ATIME, TID, and IV fields are supplied to the primitive that computes the authentication tag (step 4).
有効なキーセットが見つかると（ステップ2）、AUTHTAGフィールドがデコードされ（ステップ3）、（まだ）エンコードされたDATA、ATIME、TID、IVフィールドが認証タグを計算するプリミティブに供給されます（ステップ4） ）。
If the tag computed using the local key-set matches the one carried by the supplied SCS cookie, we can be confident that the cookie carries authentic material; otherwise, the SCS cookie is discarded (step 11).
ローカルキーセットを使用して計算されたタグが、提供されたSCS Cookieによって運ばれるタグと一致する場合、Cookieが本物の素材を持っていると確信できます。それ以外の場合、SCS Cookieは破棄されます（ステップ11）。
Then the age of the SCS cookie (as deduced by ATIME field value and current time provided by the server clock) is decoded and compared to the maximum time-to-live (TTL) defined by the session_max_age parameter.
次に、SCS Cookieの経過時間（ATIMEフィールド値とサーバークロックによって提供される現在時刻から推定）がデコードされ、session_max_ageパラメーターで定義された最大存続時間（TTL）と比較されます。
If the "age" check passes, the DATA and IV fields are finally decoded (step 8), so that the original plaintext data can be extracted from the encrypted, and optionally compressed, blob (step 9).
「年齢」チェックに合格すると、DATAフィールドとIVフィールドが最終的にデコードされ（ステップ8）、元の平文データを暗号化され、オプションで圧縮されたblobから抽出できます（ステップ9）。
Note that steps 5 and 7 allow any altered packets or expired sessions to be discarded, hence avoiding unnecessary state decryption and decompression.
手順5と7では、変更されたパケットや期限切れのセッションを破棄できるため、不必要な状態の復号化と圧縮解除を回避できます。
SCS can be modeled in the same manner as a typical store-and-forward protocol in which the endpoints are S, consisting of one or more HTTP servers and the client C, an intermediate node used to "temporarily" store the data to be successively forwarded to S.
SCSは、エンドポイントがSであり、1つ以上のHTTPサーバーとクライアントCで構成される一般的なストアアンドフォワードプロトコルと同じ方法でモデル化できます。中間ノードは、連続的にデータを「一時的に」格納するために使用されます。 Sに転送されました
In brief, S and C exchange an immutable cookie data block (Section 3.1): the state is stored on the client at the first hop and then restored on the server at the second, as in Figure 4.
簡単に言うと、SとCは不変のCookieデータブロックを交換します（セクション3.1）。図4に示すように、状態は最初のホップでクライアントに格納され、2番目のサーバーで復元されます。
1. dump-state: S --> C Set-Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0... Expires=...; Path=...; Domain=...;
1. ダンプ状態：S-> CセットCookie：ANY_COOKIE_NAME = KrdPagFes_5ma-ZUluMsww | MTM0 ... Expires = ...;パス= ...;ドメイン= ...;
2. restore-state: C --> S Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0...
2. 復元状態：C-> S Cookie：ANY_COOKIE_NAME = KrdPagFes_5ma-ZUluMsww | MTM0 ...
Figure 4
図4
In the following subsections, a series of recommendations is provided in order to maximize SCS PDU fitness in the generic cookie ecosystem.
次のサブセクションでは、一般的なCookieエコシステムでSCS PDUの適合性を最大化するために、一連の推奨事項を示します。
If an SCS cookie includes an Expires attribute, then the attribute MUST be set to a value consistent with session_max_age.
SCS CookieにExpires属性が含まれている場合は、属性をsession_max_ageと一致する値に設定する必要があります。
For maximum compatibility with existing user agents, the timestamp value MUST be encoded in rfc1123-date format, which requires a 4-digit year.
既存のユーザーエージェントとの互換性を最大限にするには、タイムスタンプ値をrfc1123-date形式でエンコードする必要があります。これには4桁の年が必要です。
Since not all User Agents (UAs) support this attribute, it MUST NOT be present in any SCS cookie.
すべてのユーザーエージェント（UA）がこの属性をサポートしているわけではないため、SCS Cookieに存在してはなりません。
SCS cookies MUST include a Domain attribute compatible with application usage.
SCS Cookieには、アプリケーションの使用と互換性のあるドメイン属性を含める必要があります。
A trailing '.' MUST NOT be present in order to minimize the possibility of a user agent ignoring the attribute value.
末尾の「。」ユーザーエージェントが属性値を無視する可能性を最小限にするために存在してはなりません。
This attribute MUST always be asserted when SCS sessions are carried over a Transport Layer Security (TLS) channel.
SCSセッションがトランスポート層セキュリティ（TLS）チャネルを介して伝送される場合、この属性は常にアサートされる必要があります。
This attribute SHOULD always be asserted.
この属性は常にアサートされる必要があります（SHOULD）。
This specification provides some common recommendations and practices relevant to cryptographic key management.
この仕様は、暗号化キー管理に関連するいくつかの一般的な推奨事項と実践を提供します。
In the following, the term 'key' references both encryption and HMAC keys.
以下では、「キー」という用語は暗号化キーとHMACキーの両方を指します。
o The key SHOULD be generated securely following the randomness recommendations in [RFC4086];
o キーは[RFC4086]のランダム性の推奨事項に従って安全に生成する必要があります。
o the key SHOULD only be used to generate and verify SCS PDUs;
o キーは、SCS PDUの生成と検証にのみ使用してください。
o the key SHOULD be replaced regularly as well as any time the format of SCS PDUs or cryptographic algorithms changes.
o 鍵は定期的に、またSCS PDUまたは暗号化アルゴリズムの形式が変更されるたびに交換する必要があります（SHOULD）。
Furthermore, to preserve the validity of active HTTP sessions upon renewal of cryptographic credentials (whenever the value of TID changes), an SCS server MUST be capable of managing at least two transforms contemporarily: the currently instantiated one and its predecessor.
さらに、暗号化資格情報の更新時にアクティブなHTTPセッションの有効性を維持するために（TIDの値が変更されたときはいつでも）、SCSサーバーは少なくとも2つの変換を同時に管理できなければなりません（現在インスタンス化されているものとその前のもの）。
Each transform set SHOULD be associated with an attribute pair, "refresh" and "expiry", which is used to identify the exposure limits (in terms of time or quantity of encrypted and/or authenticated bytes, etc.) of related cryptographic material.
各トランスフォームセットは、「リフレッシュ」と「期限切れ」の属性ペアに関連付けられている必要があります。これは、関連する暗号化マテリアルの露出制限（暗号化バイトおよび/または認証済みバイトの時間や量など）を識別するために使用されます。
In particular, the "refresh" attribute specifies the time limit for substitution of transform set T with new material T'. From that moment onwards, and for an amount of time determined by "expiry", all new sessions will be created using T', while the active T-protected ones go through a translation phase in which:
特に、「更新」属性は、トランスフォームセットTを新しいマテリアルT 'で置き換えるための時間制限を指定します。その瞬間以降、「有効期限」によって決定された時間の間、すべての新しいセッションはT 'を使用して作成されますが、アクティブなT保護セッションは次の翻訳フェーズを通過します。
o the inbound transformation authenticates and decrypts/decompresses using T (identified by TID);
o インバウンド変換は、T（TIDで識別）を使用して認証および復号化/解凍を行います。
o the outbound transformation encrypts/compresses and authenticates using T'.
o アウトバウンド変換は、T 'を使用して暗号化/圧縮および認証します。
T' {not valid yet} |---------------------|----------------
| translation stage |
T ----------------|---------------------| {no longer valid}
refresh refresh + expiry
Figure 5
図5
As shown in Figure 5, the duration of the HTTP session MUST fit within the lifetime of a given transform set (i.e., from creation time until "refresh" + "expiry").
図5に示すように、HTTPセッションの期間は、指定されたトランスフォームセットの有効期間内に収まる必要があります（つまり、作成時から「更新」+「期限切れ」まで）。
In practice, this should not be an obstacle because the longevity of the two entities (HTTP session and SCS transform set) should differ by one or two orders of magnitude.
実際には、2つのエンティティ（HTTPセッションとSCSトランスフォームセット）の寿命が1桁または2桁異なるため、これは障害になりません。
An SCS server may take this into account by determining the duration of a session adaptively according to the expected deletion time of the active T, or by setting the "expiry" value to at least the maximum lifetime allowed by an HTTP session.
SCSサーバーは、アクティブTの予想削除時間に従って適応的にセッションの期間を決定するか、「有効期限」の値を少なくともHTTPセッションで許可されている最大有効期間に設定することで、これを考慮に入れます。
Since there is also only one refresh attribute in situations with more than one key (e.g., one for encryption and one for authentication) within the same T, the smallest value is chosen.
同じT内に複数のキー（暗号化用と認証用など）がある状況では、更新属性も1つしかないため、最小値が選択されます。
It is critical for the correctness of the protocol that in case multiple equivalent SCS servers are used in a pool, all of them share the same view of time (see also Section 3.2.5) and keying material.
複数の同等のSCSサーバーがプールで使用される場合、すべてのサーバーが同じ時間の見方（セクション3.2.5も参照）とキー情報を共有することがプロトコルの正確さにとって重要です。
As far as the latter is concerned, SCS does not mandate the use of any specific key-sharing mechanism, and will keep working correctly as long as the said mechanism is able to provide a single, coherent view of the keys shared by pool members -- while conforming to the recommendations given in this section.
後者に関する限り、SCSは特定のキー共有メカニズムの使用を強制せず、前述のメカニズムがプールメンバーによって共有されるキーの単一の一貫したビューを提供できる限り、正しく機能し続けます- -このセクションに記載されている推奨事項に準拠している。
In general, SCS cookies are bigger than their plaintext counterparts. This is due to the following reasons:
一般に、SCS Cookieは対応するプレーンテキストよりも大きくなります。これは、次の理由によるものです。
o inflation of the Base64 encoding of state data (approximately 1.4 times the original size, including the encryption padding);
o 状態データのBase64エンコードのインフレ（暗号化パディングを含む、元のサイズの約1.4倍）。
o the fixed size increment (approximately 80/90 bytes) caused by SCS fields and framing overhead.
o SCSフィールドとフレーミングオーバーヘッドによって発生する固定サイズの増分（約80/90バイト）。
While the former is a price the user must always pay proportionally to the original data size, the latter is a fixed quantum, which can be huge on small amounts of data but is quickly absorbed as soon as data becomes big enough.
前者はユーザーが常に元のデータサイズに比例して支払う必要がある価格ですが、後者は固定量であり、少量のデータでは巨大になる可能性がありますが、データが十分に大きくなるとすぐに吸収されます。
The following table compares byte lengths of SCS cookies (with a four-byte TID) and corresponding plaintext cookies in a worst-case scenario, i.e., when no compression is in use (or applicable).
次の表は、SCS Cookie（4バイトのTIDを含む）のバイト長と対応するプレーンテキストCookieを最悪のシナリオ、つまり圧縮が使用されていない（または適用されていない）場合の比較です。
plain | SCS
-------+-------
11 | 128
102 | 256
285 | 512
651 | 1024
1382 | 2048
2842 | 4096
The largest uncompressed cookie value that can be safely supplied to SCS is about 2.8 KB.
SCSに安全に提供できる最大の非圧縮Cookie値は、約2.8 KBです。
We would like to thank Jim Schaad, David Wagner, Lorenzo Cavallaro, Willy Tarreau, Tobias Gondrom, John Michener, Sean Turner, Barry Leiba, Robert Sparks, Stephen Farrell, Stewart Bryant, and Nevil Brownlee for their valuable feedback on this document.
このドキュメントに関する貴重なフィードバックをいただいたジムシャード、デビッドワグナー、ロレンソカヴァッラーロ、ウィリータロー、トビアスゴンドロム、ジョンミッチェナー、ショーンターナー、バリーレイバ、ロバートスパークス、スティーブンブライアント、ネヴィルブラウンリーに感謝します。
From a cryptographic architecture perspective, the described mechanism can be easily traced to an "encode then encrypt-then-MAC" scheme (Encode-then-EtM) as described in [Kohno].
[Kohno]で説明されているように、暗号化アーキテクチャの観点から、説明されているメカニズムは、「暗号化してからMACに暗号化」方式（Encode-then-EtM）に簡単にたどることができます。
Given a "provably-secure" encryption scheme and MAC (as for the algorithms mandated in Section 3.2.2), the authors of [Kohno] demonstrate that their composition results in a secure authenticated encryption scheme.
「確実に安全な」暗号化スキームとMAC（セクション3.2.2で義務付けられているアルゴリズムについて）を考えると、[Kohno]の作成者は、それらの構成が安全な認証済み暗号化スキームになることを示しています。
The fact that the server does not own the cookie it produces, gives rise to a series of consequences that must be clearly understood when one envisages the use of SCS as a cookie provider and validator for his/her application.
サーバーが生成するCookieをサーバーが所有していないという事実は、SCSをアプリケーションのCookieプロバイダーおよびバリデーターとして使用することを想定したときに明確に理解する必要がある一連の結果をもたらします。
In the following subsections, a set of different attack scenarios (together with corresponding countermeasures where applicable) are identified and analyzed.
以下のサブセクションでは、一連のさまざまな攻撃シナリオを（該当する場合は対応する対応策と共に）識別して分析します。
SCS doesn't address replay of old cookie values.
SCSは古いCookie値の再生には対応していません。
In fact, there is nothing that assures an SCS application about the client having returned the most recent version of the cookie.
実際、クライアントが最新バージョンのCookieを返したことをSCSアプリケーションに保証するものは何もありません。
As with "server-side" sessions, if an attacker gains possession of a given user's cookies -- via simple passive interception or another technique -- he/she will always be able to restore the state of an intercepted session by representing the captured data to the server.
「サーバー側」セッションと同様に、攻撃者が特定のユーザーのCookieを取得した場合（単純なパッシブインターセプトまたは別の手法によって）、キャプチャされたデータを表すことにより、傍受されたセッションの状態をいつでも復元できます。サーバーに。
The ATIME value, along with the session_max_age configuration parameter, allows SCS to mitigate the chances of an attack (by forcing a time window outside of which a given cookie is no longer valid) but cannot exclude it completely.
ATIME値とsession_max_age構成パラメーターを使用すると、SCSは攻撃の可能性を軽減できます（指定されたCookieが有効でなくなる時間枠を強制することにより）が、完全に除外することはできません。
A countermeasure against the "passive interception and replay" scenario can be applied at transport/network level using the anti-replay services provided by e.g., Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or IPsec [RFC4301].
「パッシブインターセプトおよびリプレイ」シナリオへの対策は、Secure Socket Layer / Transport Layer Security（SSL / TLS）[RFC5246]またはIPsec [RFC4301]などによって提供されるアンチリプレイサービスを使用して、トランスポート/ネットワークレベルで適用できます。
A native solution is not in scope with the security properties inherent to an SCS cookie. Hence, an application wishing to be replay-resistant must put in place some ad hoc mechanism to prevent clients (both rogue and legitimate) from (a) being able to replay old cookies as valid credentials and/or (b) getting any advantage by replaying them.
ネイティブソリューションは、SCS Cookieに固有のセキュリティプロパティの範囲ではありません。したがって、耐リプレイ性を希望するアプリケーションは、（不正なものと正当なものの両方の）クライアントが（a）古いCookieを有効な資格情報としてリプレイできなくなる、および/または（b）それらを再生します。
The following illustrate some typical use cases:
以下に、いくつかの典型的な使用例を示します。
o Session inactivity timeout scenario (implicit invalidation): use the session_max_age parameter if a global setting is viable, else place an explicit TTL in the cookie (e.g., validity_period="start_time, duration") that can be verified by the application each time the client presents the SCS cookie.
o セッション非アクティブタイムアウトシナリオ（暗黙的な無効化）：グローバル設定が有効な場合は、session_max_ageパラメーターを使用します。それ以外の場合は、クライアントごとにアプリケーションで検証できる明示的なTTLをCookieに配置します（例：validation_period = "start_time、duration"）。 SCS Cookieを提示します。
o Session voidance scenario (explicit invalidation): put a randomly chosen string into each SCS cookie (cid="$(random())") and keep a list of valid session cids against which the SCS cookie presented by the client can be checked. When a cookie needs to be invalidated, delete the corresponding cid from the list. The described method has the drawback that, in case a non-permanent storage is used to archive valid cids, a reboot/restart would invalidate all sessions (it can't be used when |S| > 1).
o セッションの無効化シナリオ（明示的な無効化）：ランダムに選択された文字列を各SCS Cookie（cid = "$（random()）"）に入れ、クライアントから提示されたSCS Cookieをチェックできる有効なセッションCIDのリストを保持します。 Cookieを無効にする必要がある場合は、対応するcidをリストから削除します。説明されている方法には、有効なCIをアーカイブするために非永続ストレージが使用された場合、再起動/再起動によりすべてのセッションが無効になるという欠点があります（| S |> 1の場合は使用できません）。
o One-shot transaction scenario (ephemeral): this is a variation on the previous theme when sessions are consumed within a single request/response. Put a nonce="$(random())" within the state information and keep a list of not-yet-consumed nonces in RAM. Once the client presents its cookie credential, the embodied nonce is deleted from the list and will be therefore discarded whenever replayed.
o ワンショットトランザクションシナリオ（エフェメラル）：これは、セッションが単一の要求/応答内で消費される場合の前のテーマのバリエーションです。 nonce = "$（random()）"を状態情報内に置き、まだ消費されていないnonceのリストをRAMに保持します。クライアントがCookieクレデンシャルを提示すると、具体化されたナンスはリストから削除されるため、再生されるたびに破棄されます。
o TLS binding scenario: the server application must run on TLS, be able to extract information related to the current TLS session, and store it in the DATA field of the SCS cookie itself [RFC5056]. The establishment of this secure channel binding prevents any third party from reusing the SCS cookie, and drops its value altogether after the TLS session is terminated -- regardless of the lifetime of the cookie. This approach suffers a scalability problem in that it requires each SCS session to be handled by the same client-server pair. However, it provides a robust model and an affordable compromise when security of the session is exceptionally valuable (e.g., a user interacting with his/her online banking site).
o TLSバインディングシナリオ：サーバーアプリケーションはTLS上で実行され、現在のTLSセッションに関連する情報を抽出し、それをSCS Cookie自体のDATAフィールドに格納できる必要があります[RFC5056]。この安全なチャネルバインディングの確立により、サードパーティがSCS Cookieを再利用できなくなり、Cookieの有効期間に関係なく、TLSセッションが終了した後にその値が完全に削除されます。このアプローチには、各SCSセッションを同じクライアント/サーバーペアで処理する必要があるという点で、スケーラビリティの問題があります。ただし、セッションのセキュリティが非常に価値がある場合（たとえば、ユーザーが自分のオンラインバンキングサイトとやり取りする場合）、堅牢なモデルと手頃な妥協点を提供します。
It is worth noting that in all but the latter scenario, if an attacker is able to use the cookie before the legitimate client gets a chance to, then the impersonation attack will always succeed.
後者のシナリオを除いて、正当なクライアントが機会を得る前に攻撃者がCookieを使用できる場合、偽装攻撃は常に成功することに注意してください。
A direct and important consequence of the missing owner role in SCS is that a client could intentionally delete its cookie and return nothing.
SCSに所有者の役割がないことの直接的かつ重要な結果は、クライアントが意図的にCookieを削除して何も返さない可能性があることです。
The application protocol has to be designed so there is no incentive to do so, for instance:
アプリケーションプロトコルは、そのようなインセンティブがないように設計する必要があります。次に例を示します。
o it is safe for the cookie to represent some kind of positive capability -- the possession of which increases the client's powers;
o Cookieが何らかのポジティブな機能を表すことは安全です。これを保持することで、クライアントの能力が向上します。
o it is not safe to use the cookie to represent negative capabilities -- where possession reduces the client's powers -- or for revocation.
o Cookieを使用して否定的な機能を表現することは安全ではありません-所持がクライアントの能力を低下させる場合-または取り消しのため。
Note that this behavior is not equivalent to cookie removal in the "server-side" cookie model, because in case of missing cookie backup by other parties (e.g., the application using SCS), the client could simply make it disappear once and for all.
この動作は、「サーバー側」のCookieモデルでのCookieの削除と同等ではないことに注意してください。他のパーティ（SCSを使用するアプリケーションなど）によるCookieのバックアップがない場合、クライアントはそれを一度だけ表示しないためです。 。
Just like with plain cookies, SCS doesn't prevent sharing (both voluntary and illegitimate) of cookies between multiple clients.
プレーンCookieと同様に、SCSは複数のクライアント間でのCookieの共有（自発的および非合法の両方）を防止しません。
In the context of voluntary cookie sharing, using HTTPS only as a separate secure transport provider is useless: in fact, client certificates are just as shareable as cookies. Instead, using some form of secure channel binding (as illustrated in Section 7.2.1) may cancel this risk.
自発的なCookie共有のコンテキストでは、独立したセキュアなトランスポートプロバイダーとしてHTTPSのみを使用しても意味がありません。実際、クライアント証明書はCookieと同じように共有できます。代わりに、何らかのセキュリティで保護されたチャネルバインディング（セクション7.2.1に示す）を使用すると、このリスクを取り消すことができます。
The risk of theft could be mitigated by securing the wire (e.g., via HTTPS, IPsec, VPN, etc.), thus reducing the opportunity of cookie stealing to a successful attack on the protocol endpoints.
盗難のリスクは、ワイヤーを保護することにより（例えば、HTTPS、IPsec、VPNなどを介して）、プロトコルエンドポイントへの攻撃を成功させるためにCookieを盗む機会を減らすことで軽減できます。
In order to reduce the attack window on stolen cookies, an application may choose to generate cookies whose lifetime is upper bounded by the browsing session lifetime (i.e., by not attaching an Expires attribute to them.)
盗まれたCookieに対する攻撃ウィンドウを減らすために、アプリケーションは、その有効期間がブラウジングセッションの有効期間によって上限が定められたCookieを生成することを選択できます（つまり、Expires属性をアタッチしないことによって）。
Session fixation vulnerabilities [Kolsec] are not addressed by SCS.
セッション固定の脆弱性[Kolsec]はSCSでは対処されていません。
A more sophisticated protocol involving active participation of the UA in the SCS cookie manipulation process would be needed: e.g., some form of challenge/response exchange initiated by the server in the HTTP response and replied to by the UA in the next chained HTTP request.
SCS Cookie操作プロセスへのUAのアクティブな参加を含むより洗練されたプロトコルが必要になります。たとえば、HTTP応答でサーバーによって開始され、次のチェーンされたHTTPリクエストでUAによって応答される、何らかの形式のチャレンジ/レスポンス交換。
Unfortunately, the present specification, which is based on [RFC6265], sees the UA as a completely passive actor whose role is to blindly paste the cookie value set by the server.
残念ながら、[RFC6265]に基づく現在の仕様では、UAは完全に受動的なアクターであり、その役割はサーバーによって設定されたCookie値を盲目的に貼り付けることです。
Nevertheless, the SCS cookies wrapping mechanism may be used in the future as a building block for a more robust HTTP state management protocol.
それにもかかわらず、SCS Cookieのラッピングメカニズムは、より堅牢なHTTP状態管理プロトコルのビルディングブロックとして将来使用される可能性があります。
Note that all the above-mentioned vulnerabilities also apply to plain cookies, making SCS at least as secure, but there are a few good reasons to consider its security level enhanced.
上記のすべての脆弱性はプレーンCookieにも適用されるため、SCSは少なくとも同じくらい安全ですが、セキュリティレベルが強化されていると考えるのにはいくつかの理由があります。
First of all, the confidentiality and authentication features provided by SCS protect the cookie value, which is normally plaintext and tamperable.
まず、SCSが提供する機密性と認証機能は、通常は平文で改ざん可能なCookieの値を保護します。
Furthermore, neither of the common vulnerabilities of server-side sessions (session identifier (SID) prediction and SID brute-forcing) can be exploited when using SCS, unless the attacker possesses encryption and HMAC keys (both current ones and those relating to the previous set of credentials).
さらに、攻撃者が暗号化とHMACキー（現在のものと以前のものに関連するものの両方）を所有していない限り、サーバー側セッションの一般的な脆弱性（セッション識別子（SID）予測とSIDブルートフォーシング）はSCSの使用時に悪用されることはありません。資格情報のセット）。
More in general, no slicing nor altering operations can be done over an SCS PDU without controlling the cryptographic key-set.
より一般的には、暗号化キーセットを制御せずに、SCS PDU上でスライス操作や変更操作を行うことはできません。
[NIST-AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
[NIST-AES]米国国立標準技術研究所、「Advanced Encryption Standard（AES）」、FIPS PUB 197、2001年11月、<http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf >。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、1996年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194] Polk、T.、Chen、L.、Turner、S。、およびP. Hoffman、「SHA-0およびSHA-1メッセージダイジェストアルゴリズムのセキュリティに関する考慮事項」、RFC 6194、2011年3月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]バース、A。、「HTTP状態管理メカニズム」、RFC 6265、2011年4月。
[Bellare] Bellare, M., "New Proofs for NMAC and HMAC: Security Without Collision-Resistance", 2006.
[Bellare] Bellare、M。、「NMACおよびHMACの新しい証明：衝突防止なしのセキュリティ」、2006年。
[CLIQUES] Steiner, M., Tsudik, G., and M. Waidner, "Cliques: A New Approach to Group Key Agreement", 1996.
[CLIQUES] Steiner、M.、Tsudik、G。、およびM. Waidner、「クリーク：グループキーアグリーメントへの新しいアプローチ」、1996年。
[Kohno] Kohno, T., Palacio, A., and J. Black, "Building Secure Cryptographic Transforms, or How to Encrypt and MAC", 2003.
[河野]河野徹、パラシオA、J。ブラック、「安全な暗号変換の構築、または暗号化とMACの方法」、2003年。
[Kolsec] Kolsec, M., "Session Fixation Vulnerability in Web-based Applications", 2002.
[Kolsec] Kolsec、M。、「Webベースのアプリケーションにおけるセッション固定の脆弱性」、2002年。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズN.、「セキュアチャネルへのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[Steiner] Steiner, M., Tsudik, G., and M. Waidner, "Diffie-Hellman Key Distribution Extended to Group Communication", 1996.
[Steiner] Steiner、M.、Tsudik、G。、およびM. Waidner、「Diffie-Hellman Key Distribution Extended to Group Communication」、1996年。
The examples in this section have been created using the 'scs' test tool bundled with LibSCS, a free and opensource reference implementation of the SCS protocol that can be found at (http://github.com/koanlogic/libscs).
このセクションの例は、LibSCS（http://github.com/koanlogic/libscs）にあるSCSプロトコルの無料のオープンソースリファレンス実装にバンドルされている「scs」テストツールを使用して作成されています。
The following parameters:
以下のパラメーター：
o Plaintext cookie: "a state string"
o プレーンテキストCookie：「状態文字列」
o AES-CBC-128 key: "123456789abcdef"
o AES-CBC-128キー：「123456789abcdef」
o HMAC-SHA1 key: "12345678901234567890"
o HMAC-SHA1キー：「12345678901234567890」
o TID: "tid"
o 時間：「時間」
o ATIME: 1347265955
o ATIME：1347265955
o IV: \xb4\xbd\xe5\x24\xf7\xf6\x9d\x44\x85\x30\xde\x9d\xb5\x55\xc9\x4f
o IV：\ xb4 \ xbd \ xe5 \ x24 \ xf7 \ xf6 \ x9d \ x44 \ x85 \ x30 \ xde \ x9d \ xb5 \ x55 \ xc9 \ x4f
produce the following tokens:
次のトークンを生成します。
o DATA: DqfW4SFqcjBXqSTvF2qnRA
o データ：DqfW4SFqcjBXqSTvF2qnRA
o ATIME: MTM0NzI2NTk1NQ
o ATIME：MTM0NzI2NTk1NQ
o TID: OHU7M1cqdDQt
o 時間：OHU7M1cqdDQt
o IV: tL3lJPf2nUSFMN6dtVXJTw
o IV：tL3lJPf2nUSFMN6dtVXJTw
o AUTHTAG: AznYHKga9mLL8ioi3If_1iy2KSA
o 必要です：AznYHKga9mLL8ioi3If_1iy2KSA
The same parameters as above, except ATIME and IV:
ATIMEとIVを除いて、上記と同じパラメーター：
o Plaintext cookie: "a state string"
o プレーンテキストCookie：「状態文字列」
o AES-CBC-128 key: "123456789abcdef"
o AES-CBC-128キー：「123456789abcdef」
o HMAC-SHA1 key: "12345678901234567890"
o HMAC-SHA1キー：「12345678901234567890」
o TID: "tid" o ATIME: 1347281709
o時間：「時間」o時間：1347281709
o IV: \x1d\xa7\x6f\xa0\xff\x11\xd7\x95\xe3\x4b\xfb\xa9\xff\x65\xf9\xc7
o IV：\ x1d \ xa7 \ x6f \ xa0 \ xff \ x11 \ xd7 \ x95 \ xe3 \ x4b \ xfb \ xa9 \ xff \ x65 \ xf9 \ xc7
produce the following tokens:
次のトークンを生成します。
o DATA: PbE-ypmQ43M8LzKZ6fMwFg-COrLP2l-Bvgs
o データ：PbE-ypmQ43M8LzKZ6fMwFg-COrLP2l-Bvgs
o ATIME: MTM0NzI4MTcwOQ
o ATIME：MTM0NzI4MTcwOQ
o TID: akxIKmhbMTE8
o 時間：akxIKmhbMTE8
o IV: HadvoP8R15XjS_up_2X5xw
o IV：HadvoP8R15XjS_up_2X5xw
o AUTHTAG: A6qevPr-ugHQChlr_EiKYWPvpB0
o AUTHTAG：A6qevPr-ugHQChlr_EiKYWPvpB0
In both cases, the resulting SCS cookie is obtained via ordered concatenation of the produced tokens, as described in Section 3.1.
どちらの場合も、結果のSCS Cookieは、セクション3.1で説明されているように、生成されたトークンの順序付けられた連結によって取得されます。
Authors' Addresses
著者のアドレス
Stefano Barbato KoanLogic Via Marmolada, 4 Vitorchiano (VT), 01030 Italy
Stefano Barbato KoanLogic Via Marmolada、4 Vitorchiano（VT）、01030イタリア
EMail: tat@koanlogic.com
Steven Dorigotti KoanLogic Via Maso della Pieve 25/C Bolzano, 39100 Italy
Steven Dorigotti KoanLogic Via Maso della Pieve 25 / Cボルツァーノ、39100イタリア
EMail: stewy@koanlogic.com
Thomas Fossati (editor) KoanLogic Via di Sabbiuno 11/5 Bologna, 40136 Italy
Thomas Fossati（編集者）KoanLogic Via di Sabbiuno 11/5ボローニャ、40136イタリア
EMail: tho@koanlogic.com