Independent Submission S. Barbato
Request for Comments: 6896 S. Dorigotti
Category: Informational T. Fossati, Ed.
ISSN: 2070-1721 KoanLogic
March 2013
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:KoanLogic针对HTTP的安全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 cookies的简单协议使用此类令牌的一种可能方式。
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.
安全Cookie会话（SCS）用例涵盖广泛的应用程序，从通过HTTP分发授权内容（例如，使用带外签名的URI）到使用无盘嵌入式设备（例如，小型办公室、家庭办公室（SOHO）路由器）保护浏览器会话或具有高可用性或负载平衡要求的web服务器，这些服务器可能希望将应用程序状态的处理委托给客户端，而不是使用共享存储或强制对等。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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
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.
它是URI和HTTP头友好的，因为它被明确设计为与ABNF“token”语法[RFC2616]（用于设置Cookie和Cookie头的语法）和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的简单协议使用此类令牌的一种可能方式，该协议允许建立“客户端模式”会话。这不是它们唯一可能的用途。虽然此处未概述其他操作模式，但预计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服务器可以通过用户库在web应用程序中实现，该用户库公开核心SCS功能并将SCS令牌的显式控制留给程序员，或者例如通过将“无盘会话”设施隐藏在通用会话API抽象后面而透明地实现。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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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 使用设置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是一个或多个可互换的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字段由其左侧和/或右侧同级通过%x7c ASCII字符（即“|”）分隔，如下所示：
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
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.
机密性仅限于应用程序状态信息（即数据字段），而完整性和身份验证适用于整个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).
与对会话数据执行的最后一次读或写操作相关的绝对时间戳，编码为十六进制字符串，表示自UNIX纪元（即自1970年1月1日00:00:00起）起的秒数。
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上的当前时间之间的差值大于预定义的“会话\u max\u 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.
此标识符相当于数据安全SA[RFC3740]中的安全参数索引（SPI），由ASCII字符串组成，该字符串唯一标识用于生成此SCS cookie的转换集（键和算法）。
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假设，对于由多台服务器组成的环境，存在密钥协议/分发机制，这些服务器为池成员之间共享的每个转换集提供唯一的外部标识符。
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.
如果池中只有一台服务器，并且密钥是在适当的位置生成的，也就是说，它不是由外部源处理的，那么这种机制可以安全地降级为定期密钥刷新。
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样本的攻击者提供相关信息，必须为每个SCS cookie随机创建IV。
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编码数据、ATIME、TID和IV字段的纯字符串串联，并由“|”分隔符框定（另请参见第3.2节中Box（）函数的定义）：
AUTHTAG = HMAC(base64url(DATA) "|"
base64url(ATIME) "|"
base64url(TID) "|"
base64url(IV))
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可能会使用能够执行认证加密的原语的任何组合。在实践中，选择了一种先加密后MAC的方法[Kohno]，该方法利用密码块链接（CBC）模式和哈希消息认证码（HMAC）[RFC2104]认证进行加密。
The two algorithms MUST be associated with two independent keys.
这两种算法必须与两个独立的密钥相关联。
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输入中明确包含的框架符号将blob作为一个整体与其每个组成原子的精确位置密封在一起。
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 HMAC-SHA1具有128位密钥，确保真实性和完整性，
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 cookies的参与者）看到，如图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。时间：=现在3。数据：=Enc（Comp（纯文本cookie值），IV）4。AUTHTAG:=HMAC（框（e（数据）、e（时间）、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字段的唯一用户是服务器，因此它不需要与客户机同步——尽管它需要使用相当稳定的时钟。但是，如果多台服务器在负载平衡配置中处于活动状态，则应同步时钟，以避免计算会话到期时出错。
The plaintext cookie value is then compressed (if needed) and encrypted by using the key-set identified by TID (step 3).
然后使用TID标识的密钥集对明文cookie值进行压缩（如果需要）和加密（步骤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).
然后，通过HMAC使用TID标识的密钥集对其base64url表示的“|”分隔串联，计算包含每个SCS字段（以及长度和相对位置）的认证标签（步骤4）。
Finally, the SCS-cookie-value is created as follows:
最后，SCS cookie值的创建如下所示：
scs-cookie-value = Box(e(DATA), e(ATIME), e(TID), e(IV),
e(AUTHTAG))
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. 如果（分割_字段（scs cookie值）=确定）1。tid'：=d（eTID）2。如有(tid)3。标签'：=d（eAUTHTAG）4。标签：=HMAC（框（eDATA、eATIME、eTID、eIV））5。如果（标记=标记'）6。atime'：=d（eATIME）7。如果（现在-atime'<=session\u max\u age）8。iv’：=d（eIV）数据’：=d（eDATA）9。状态：=未压缩（12月（数据'，iv'））10。否则丢弃PDU 11。否则丢弃PDU 12。否则丢弃PDU 13。否则丢弃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值分解为其组件字段，这些字段必须正好为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），并且（仍然）编码的数据、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).
如果“年龄”检查通过，则最终对数据和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，由一个或多个HTTP服务器和客户端C组成，客户端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所示。
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。。。过期=。。。；路径=。。。；域=。。。；
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.
在以下小节中，提供了一系列建议，以最大限度地提高SCS PDU在通用cookie生态系统中的适用性。
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属性，则该属性必须设置为与会话\u max\u 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日期格式编码，这需要4位数的年份。
Since not all User Agents (UAs) support this attribute, it MUST NOT be present in any SCS cookie.
由于并非所有用户代理（UAs）都支持此属性，因此它不能出现在任何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.
应始终声明此属性。
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或加密算法的格式发生变化时更换密钥。
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.
此外，为了在更新加密凭据时（每当TID的值发生变化时）保持活动HTTP会话的有效性，SCS服务器必须能够同时管理至少两个转换：当前实例化的转换及其前身。
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
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.
实际上，这不应该是一个障碍，因为这两个实体（HTTP会话和SCS转换集）的寿命应该相差一到两个数量级。
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内具有多个密钥（例如，一个用于加密，一个用于认证）的情况下，也只有一个刷新属性，因此选择最小值。
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不强制使用任何特定的密钥共享机制，只要该机制能够提供池成员共享密钥的单一一致视图，SCS将继续正常工作，同时符合本节给出的建议。
In general, SCS cookies are bigger than their plaintext counterparts. This is due to the following reasons:
一般来说，SCS cookie比其纯文本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（具有四字节TID）的字节长度和最坏情况下的相应明文Cookie，即在未使用压缩（或适用）时。
plain | SCS
-------+-------
11 | 128
102 | 256
285 | 512
651 | 1024
1382 | 2048
2842 | 4096
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.8KB。
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.
我们要感谢Jim Schaad、David Wagner、Lorenzo Cavallaro、Willy Tarrau、Tobias Gondrom、John Michener、Sean Turner、Barry Leiba、Robert Sparks、Stephen Farrell、Stewart Bryant和Nevil Brownlee对本文件的宝贵反馈。
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”方案（先编码然后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.
事实上，没有任何东西可以确保SCS应用程序知道客户端返回了最新版本的cookie。
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].
可以使用安全套接字层/传输层安全（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\u max\u age参数，否则在cookie中放置一个显式TTL（例如，validity\u period=“start\u time，duration”），应用程序可在每次客户端呈现SCS cookie时验证该TTL。
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（））”）中，并保留有效会话cid的列表，根据该列表可以检查客户端提供的SCS cookie。当cookie需要失效时，从列表中删除相应的cid。所述方法的缺点是，如果使用非永久性存储来存档有效的CID，则重新启动/重新启动将使所有会话无效（当| 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（））”，并在RAM中保留一个尚未使用的nonce列表。一旦客户端显示其cookie凭据，包含的nonce将从列表中删除，因此在重播时将被丢弃。
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本身的数据字段中[RFC5056]。此安全通道绑定的建立防止任何第三方重用SCS cookie，并在TLS会话终止后完全删除其值，而不管cookie的生存期如何。这种方法存在可伸缩性问题，因为它要求每个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之前使用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.
SCS未解决会话固定漏洞[Kolsec]。
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.
需要一个更复杂的协议，涉及UA积极参与SCS cookie操作过程：例如，服务器在HTTP响应中发起某种形式的质询/响应交换，UA在下一个链接HTTP请求中响应。
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 cookies包装机制将来可能会用作更健壮的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.
请注意，上述所有漏洞也适用于普通cookies，使SCS至少安全，但有几个很好的理由来考虑其安全级别提高。
First of all, the confidentiality and authentication features provided by SCS protect the cookie value, which is normally plaintext and tamperable.
首先，SCS提供的机密性和身份验证功能保护cookie值，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).
此外，在使用SCS时，服务器端会话的两个常见漏洞（会话标识符（SID）预测和SID暴力强制）都不能被利用，除非攻击者拥有加密和HMAC密钥（当前密钥和与前一组凭据相关的密钥）。
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]国家标准与技术研究所，“高级加密标准（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压缩数据格式规范1.3版”，RFC1951，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：用于消息认证的键控哈希”，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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——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，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年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 61942011年3月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，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.
[集团]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.
[Kohno]Kohno，T.，Palacio，A.，和J.Black，“构建安全的加密转换，或如何加密和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，“多播组安全架构”，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 43012005年12月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，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，“传输层安全（TLS）协议版本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密钥分发扩展到组通信”，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捆绑的“scs”测试工具创建的，LibSCS是scs协议的免费开源参考实现，可在(http://github.com/koanlogic/libscs).
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键：“123456789001234567890”
o TID: "tid"
o 工业贸易署：“工业贸易署”
o ATIME: 1347265955
o 时间：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 时间：MTM0NzI2NTk1NQ
o TID: OHU7M1cqdDQt
o TID:OHU7M1cqdDQt
o IV: tL3lJPf2nUSFMN6dtVXJTw
o IV:tL3lJPf2nUSFMN6dtVXJTw
o AUTHTAG: AznYHKga9mLL8ioi3If_1iy2KSA
o AUTHTAG:AznyHKGA9MLL8IOI3If1I2KSA
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键：“123456789001234567890”
o TID: "tid"
o 工业贸易署：“工业贸易署”
o ATIME: 1347281709
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 时间：MTM0NzI4MTcwOQ
o TID: akxIKmhbMTE8
o TID:akxIKmhbMTE8
o IV: HadvoP8R15XjS_up_2X5xw
o IV:HadvoP8R15XjS\u up\u 2X5xw
o AUTHTAG: A6qevPr-ugHQChlr_EiKYWPvpB0
o 作者标签：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
意大利维托奇亚诺（VT）4号马尔莫拉达大街Stefano Barbato KoanLogic，邮编01030
EMail: tat@koanlogic.com
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 Bolzano，意大利39100
EMail: stewy@koanlogic.com
EMail: stewy@koanlogic.com
Thomas Fossati (editor) KoanLogic Via di Sabbiuno 11/5 Bologna, 40136 Italy
Thomas Fossati（编辑）KoanLogic Via di Sabbiuno 11/5 Bologna，40136意大利
EMail: tho@koanlogic.com
EMail: tho@koanlogic.com