Network Working Group S. Santesson
Request for Comments: 4680 Microsoft
Updates: 4346 September 2006
Category: Standards Track
Network Working Group S. Santesson
Request for Comments: 4680 Microsoft
Updates: 4346 September 2006
Category: Standards Track
TLS Handshake Message for Supplemental Data
补充数据的TLS握手消息
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types.
本规范定义了用于交换补充应用程序数据的TLS握手消息。TLS hello消息扩展用于确定TLS客户端和TLS服务器都支持哪些补充数据类型。然后，使用补充数据握手消息来交换数据。其他文档将定义这些扩展的语法以及相关补充数据类型的语法。
Recent standards activities have proposed different mechanisms for transmitting supplemental application data in the TLS handshake message. For example, recent proposals transfer data that is not processed by the TLS protocol itself, but assist the TLS-protected application in the authentication and authorization decisions. One proposal transfers user name hints for locating credentials, and another proposal transfers attribute certificates and Security Assertions Markup Language (SAML) assertions for authorization checks.
最近的标准活动提出了在TLS握手消息中传输补充应用程序数据的不同机制。例如，最近的提案传输的数据不是由TLS协议本身处理的，而是协助受TLS保护的应用程序进行身份验证和授权决策。一个方案传输用户名提示以定位凭据，另一个方案传输属性证书和安全断言标记语言（SAML）断言以进行授权检查。
In order to avoid definition of multiple handshake messages, one for each new type of application-specific supplemental data, this specification defines a new handshake message type that bundles together all data objects that are to be delivered to the TLS-protected application and sends them in a single handshake message.
为了避免定义多个握手消息，每种新类型的特定于应用程序的补充数据定义一个握手消息，本规范定义了一种新的握手消息类型，它将要传递到受TLS保护的应用程序的所有数据对象捆绑在一起，并在一个握手消息中发送它们。
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 RFC 2119 [N1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[N1]中所述进行解释。
The syntax for the supplemental_data handshake message is defined using the TLS Presentation Language, which is specified in Section 4 of [N2].
补充_数据握手消息的语法使用TLS表示语言定义，该语言在[N2]的第4节中规定。
The new supplemental_data handshake message type is defined to accommodate communication of supplemental data objects as agreed during the exchange of extensions in the client and server hello messages. See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake message types.
新的补充_数据握手消息类型被定义为适应在客户端和服务器hello消息中交换扩展时商定的补充数据对象的通信。有关其他握手消息类型，请参见RFC 2246（TLS 1.0）[N2]和RFC 4346（TLS 1.1）[N3]。
Information provided in a supplemental data object MUST be intended to be used exclusively by applications and protocols above the TLS protocol layer. Any such data MUST NOT need to be processed by the TLS protocol.
补充数据对象中提供的信息必须专用于TLS协议层之上的应用程序和协议。任何此类数据都不需要通过TLS协议进行处理。
enum {
supplemental_data(23), (255)
} HandshakeType;
enum {
supplemental_data(23), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* octets in message */
select (HandshakeType) {
case supplemental_data: SupplementalData;
} body;
} Handshake;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* octets in message */
select (HandshakeType) {
case supplemental_data: SupplementalData;
} body;
} Handshake;
struct {
SupplementalDataEntry supp_data<1..2^24-1>;
} SupplementalData;
struct {
SupplementalDataEntry supp_data<1..2^24-1>;
} SupplementalData;
struct {
SupplementalDataType supp_data_type;
uint16 supp_data_length;
select(SupplementalDataType) { }
} SupplementalDataEntry;
struct {
SupplementalDataType supp_data_type;
uint16 supp_data_length;
select(SupplementalDataType) { }
} SupplementalDataEntry;
enum {
(65535)
} SupplementalDataType;
enum {
(65535)
} SupplementalDataType;
supp_data_length This field is the length (in bytes) of the data selected by SupplementalDataType.
supp_data_length此字段是由SupplementalDataType选择的数据的长度（以字节为单位）。
The client MUST NOT send more than one SupplementalData handshake message, and the server MUST NOT send more than one SupplementalData handshake message. Receiving more than one SupplementalData handshake message results in a fatal error, and the receiver MUST close the connection with a fatal unexpected_message alert.
客户端不得发送多个SupplementalData握手消息，服务器不得发送多个SupplementalData握手消息。接收到多条补充数据握手消息将导致致命错误，并且接收器必须使用致命意外消息警报关闭连接。
If present, the SupplementalData handshake message MUST contain a non-empty SupplementalDataEntry structure carrying data associated with at least one defined SupplementalDataType. An explicit agreement that governs presence of any supplemental data MUST be concluded between client and server for each SupplementalDataType using the TLS extensions [N4] in the client and server hello messages. Receiving an unexpected SupplementalData handshake message results in a fatal error, and the receiver MUST close the connection with a fatal unexpected_message alert.
如果存在，则SupplementalData握手消息必须包含非空的SupplementalDataEntry结构，其中包含与至少一个定义的SupplementalDataType关联的数据。客户机和服务器之间必须使用客户机和服务器hello消息中的TLS extensions[N4]为每个补充数据类型签订管理任何补充数据存在的明确协议。接收到意外的补充数据握手消息会导致致命错误，并且接收器必须使用致命的意外消息警报关闭连接。
Other documents will define specific SupplementalDataTypes and their associated data syntax and processing. These same specifications must also specify the client and server hello message extensions that are used to negotiate the support for the specified supplemental data type. This document simply specifies the TLS Handshake Protocol message that will carry the supplemental data objects.
其他文档将定义特定的补充数据类型及其相关的数据语法和处理。这些相同的规范还必须指定用于协商对指定补充数据类型的支持的客户机和服务器hello消息扩展。本文档仅指定将携带补充数据对象的TLS握手协议消息。
Different situations require the transfer of supplemental data from the client to the server, require the transfer of supplemental data from the server to the client, or both ways. All three situations are fully supported.
不同的情况需要将补充数据从客户端传输到服务器，需要将补充数据从服务器传输到客户端，或者两种方式都需要。这三种情况都得到充分支持。
The SupplementalData handshake message, if exchanged, MUST be sent as the first handshake message as illustrated in Figure 1 below.
如果交换了补充数据握手消息，则必须将其作为第一个握手消息发送，如下图1所示。
Client Server
客户端服务器
ClientHello (with extensions) -------->
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages.
* 指示可选或与情况相关的消息。
Figure 1. Message Flow with SupplementalData
图1。带有补充数据的消息流
Each SupplementalDataType included in the handshake message defined in this specification introduces its own unique set of security properties and related considerations. Security considerations must therefore be defined in each document that defines a supplemental data type.
本规范中定义的握手消息中包含的每个补充数据类型都引入了自己独特的一组安全属性和相关注意事项。因此，必须在定义补充数据类型的每个文档中定义安全注意事项。
In some cases, the SupplementalData information may be sensitive. The double handshake technique can be used to provide protection for the SupplementalData information. Figure 2 illustrates the double handshake, where the initial handshake does not include any extensions, but it does result in protected communications. Then, a second handshake that includes the SupplementalData information is performed using the protected communications. In Figure 2, the number on the right side indicates the amount of protection for the TLS message on that line. A zero (0) indicates that there is no communication protection; a one (1) indicates that protection is provided by the first TLS session; and a two (2) indicates that protection is provided by both TLS sessions.
在某些情况下，补充数据信息可能是敏感的。双重握手技术可用于为补充数据信息提供保护。图2说明了双握手，其中初始握手不包括任何扩展，但它确实会导致受保护的通信。然后，使用受保护通信执行包括补充数据信息的第二握手。在图2中，右侧的数字表示该行上TLS消息的保护量。零（0）表示没有通信保护；一（1）表示由第一TLS会话提供保护；两（2）表示两个TLS会话都提供了保护。
The placement of the SupplementalData message in the TLS Handshake results in the server providing its SupplementalData information before the client is authenticated. In many situations, servers will not want to provide authorization information until the client is authenticated. The double handshake illustrated in Figure 2 provides a technique to ensure that the parties are mutually authenticated before either party provides SupplementalData information.
在TLS握手中放置SupplementalData消息会导致服务器在对客户端进行身份验证之前提供其SupplementalData信息。在许多情况下，服务器在客户端通过身份验证之前不希望提供授权信息。图2中所示的双重握手提供了一种技术，以确保在任何一方提供补充数据信息之前，双方都经过了相互身份验证。
Client Server
客户端服务器
ClientHello (no extensions) --------> |0
ServerHello (no extensions) |0
Certificate* |0
ServerKeyExchange* |0
CertificateRequest* |0
<-------- ServerHelloDone |0
Certificate* |0
ClientKeyExchange |0
CertificateVerify* |0
[ChangeCipherSpec] |0
Finished --------> |1
[ChangeCipherSpec] |0
<-------- Finished |1
ClientHello (w/ extensions) --------> |1
ServerHello (w/ extensions) |1
SupplementalData* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
ClientHello (no extensions) --------> |0
ServerHello (no extensions) |0
Certificate* |0
ServerKeyExchange* |0
CertificateRequest* |0
<-------- ServerHelloDone |0
Certificate* |0
ClientKeyExchange |0
CertificateVerify* |0
[ChangeCipherSpec] |0
Finished --------> |1
[ChangeCipherSpec] |0
<-------- Finished |1
ClientHello (w/ extensions) --------> |1
ServerHello (w/ extensions) |1
SupplementalData* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
* Indicates optional or situation-dependent messages.
* 指示可选或与情况相关的消息。
Figure 2. Double Handshake to Protect Supplemental Data
图2。双重握手以保护补充数据
IANA has taken the following actions:
IANA已采取以下行动：
1) Created an entry, supplemental_data(23), in the existing registry for HandshakeType (defined in RFC 2246 [N2]).
1) 在现有注册表中为握手类型（在RFC 2246[N2]中定义）创建了一个条目，即补充_数据（23）。
2) Established a registry for TLS Supplemental Data Formats (SupplementalDataType). Values in the inclusive range 0-16385 (decimal) are assigned via RFC 2434 [N5] Standards Action. Values from the inclusive range 16386-65279 (decimal) are assigned via RFC 2434 IETF Consensus. Values from the inclusive range 65280-65535 (decimal) are reserved for RFC 2434 Private Use.
2) 为TLS补充数据格式（补充数据类型）建立了注册表。0-16385（十进制）范围内的值通过RFC 2434[N5]标准操作分配。包含范围16386-65279（十进制）的值通过RFC 2434 IETF共识分配。包含范围65280-65535（十进制）的值保留给RFC 2434专用。
[N1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[N2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[N2]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[N3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[N3]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[N4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[N4]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[N5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[N5]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
The fundamental architectural idea for the supplemental data handshake message was provided by Russ Housley and Eric Rescorla.
补充数据握手消息的基本架构思想由Russ Housley和Eric Rescorla提供。
Author's Address
作者地址
Stefan Santesson Microsoft Finlandsgatan 30 164 93 KISTA Sweden
Stefan Santesson微软Finlandsgatan 30 164 93 KISTA瑞典
EMail: stefans@microsoft.com
EMail: stefans@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。