Internet Engineering Task Force (IETF) M. Brown
Request for Comments: 5878 RedPhone Security
Updates: 5246 R. Housley
Category: Experimental Vigil Security
ISSN: 2070-1721 May 2010
Internet Engineering Task Force (IETF) M. Brown
Request for Comments: 5878 RedPhone Security
Updates: 5246 R. Housley
Category: Experimental Vigil Security
ISSN: 2070-1721 May 2010
Transport Layer Security (TLS) Authorization Extensions
传输层安全（TLS）授权扩展
Abstract
摘要
This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message.
本文档指定了传输层安全（TLS）握手协议的授权扩展。客户端和服务器hello消息中包含扩展，以确认双方都支持所需的授权数据类型。然后，如果客户端和服务器都支持，则在补充数据握手消息中交换授权信息，例如属性证书（ACs）或安全断言标记语言（SAML）断言。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc5878.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5878.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
The Transport Layer Security (TLS) protocol ([TLS1.0], [TLS1.1], [TLS1.2]) is being used in an increasing variety of operational environments, including ones that were not envisioned at the time of the original design for TLS. The extensions introduced in this document are designed to enable TLS to operate in environments where authorization information needs to be exchanged between the client and the server before any protected data is exchanged. The use of these TLS authorization extensions is especially attractive when more than one application protocol can make use of the same authorization information.
传输层安全性（TLS）协议（[TLS1.0]、[TLS1.1]、[TLS1.2]）正在越来越多的操作环境中使用，包括TLS原始设计时没有想到的环境。本文档中介绍的扩展旨在使TLS能够在需要在交换任何受保护数据之前在客户端和服务器之间交换授权信息的环境中运行。当多个应用程序协议可以使用相同的授权信息时，使用这些TLS授权扩展尤其有吸引力。
The format and content of the authorization information carried in these extensions are extensible. This document references Security Assertion Markup Language (SAML) assertion ([SAML1.1], [SAML2.0]) and X.509 attribute certificate (AC) [ATTRCERT] authorization formats, but other formats can be used. Future authorization extensions may include any opaque assertion that is digitally signed by a trusted issuer. Recognizing the similarity to certification path validation, this document recommends the use of TLS Alert messages related to certificate processing to report authorization information processing failures.
这些扩展中包含的授权信息的格式和内容是可扩展的。本文档引用了安全断言标记语言（SAML）断言（[SAML1.1]、[SAML2.0]）和X.509属性证书（AC）[ATTRCERT]授权格式，但也可以使用其他格式。未来的授权扩展可能包括任何由可信颁发者数字签名的不透明断言。认识到与证书路径验证的相似性，本文档建议使用与证书处理相关的TLS警报消息来报告授权信息处理失败。
Straightforward binding of identification, authentication, and authorization information to an encrypted session is possible when all of these are handled within TLS. If each application requires unique authorization information, then it might best be carried within the TLS-protected application protocol. However, care must be taken to ensure appropriate bindings when identification, authentication, and authorization information are handled at different protocol layers.
当所有这些都在TLS中处理时，可以将标识、身份验证和授权信息直接绑定到加密会话。如果每个应用程序都需要唯一的授权信息，那么最好将其放在受TLS保护的应用程序协议中。但是，在不同的协议层处理标识、身份验证和授权信息时，必须注意确保适当的绑定。
This document describes authorization extensions for the TLS Handshake Protocol in TLS 1.0, TLS 1.1, and TLS 1.2. These extensions observe the conventions defined for TLS extensions that were originally defined in [TLSEXT1] and revised in [TLSEXT2]; TLS extensions are now part of TLS 1.2 [TLS1.2]. TLS extensions use general extension mechanisms for the client hello message and the
本文档描述了TLS 1.0、TLS 1.1和TLS 1.2中TLS握手协议的授权扩展。这些扩展遵守了最初在[TLSEXT1]中定义并在[TLSEXT2]中修订的TLS扩展的约定；TLS扩展现在是TLS 1.2[TLS1.2]的一部分。TLS扩展为客户机hello消息和
server hello message. The extensions described in this document confirm that both the client and the server support the desired authorization data types. Then, if supported, authorization information is exchanged in the supplemental data handshake message [TLSSUPP].
服务器hello消息。本文档中描述的扩展确认客户端和服务器都支持所需的授权数据类型。然后，如果支持，在补充数据握手消息[TLSSUPP]中交换授权信息。
The authorization extensions may be used in conjunction with TLS 1.0, TLS 1.1, and TLS 1.2. The extensions are designed to be backwards compatible, meaning that the handshake protocol supplemental data messages will only contain authorization information of a particular type if the client indicates support for them in the client hello message and the server indicates support for them in the server hello message.
授权扩展可与TLS 1.0、TLS 1.1和TLS 1.2一起使用。扩展设计为向后兼容，这意味着握手协议补充数据消息将仅包含特定类型的授权信息，前提是客户端在客户端hello消息中表示支持这些信息，而服务器在服务器hello消息中表示支持这些信息。
Clients typically know the context of the TLS session that is being set up; thus, the client can use the authorization extensions when they are needed. Servers must accept extended client hello messages, even if the server does not "understand" all of the listed extensions. However, the server will not indicate support for these "not understood" extensions. Then, clients may reject communications with servers that do not support the authorization extensions.
客户端通常知道正在设置的TLS会话的上下文；因此，客户机可以在需要时使用授权扩展。服务器必须接受扩展客户机hello消息，即使服务器不“理解”列出的所有扩展。但是，服务器不会表示支持这些“未理解”的扩展。然后，客户端可能拒绝与不支持授权扩展的服务器的通信。
The syntax for the authorization messages is defined using the TLS Presentation Language, which is specified in Section 4 of [TLS1.0].
授权消息的语法是使用TLS表示语言定义的，该语言在[TLS1.0]的第4节中有规定。
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 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
Figure 1 illustrates the placement of the authorization extensions and supplemental data messages in the full TLS handshake.
图1说明了授权扩展和补充数据消息在完整TLS握手中的位置。
The ClientHello message includes an indication of the client authorization data formats that are supported and an indication of the server authorization data formats that are supported. The ServerHello message contains similar indications, but any authorization data formats that are not supported by the server are not included. Both the client and the server MUST indicate support for the authorization data types. If the list of mutually supported authorization data formats is empty, then the ServerHello message MUST NOT carry the affected extension at all.
ClientHello消息包括受支持的客户端授权数据格式指示和受支持的服务器授权数据格式指示。ServerHello消息包含类似的指示，但不包括服务器不支持的任何授权数据格式。客户端和服务器都必须指示对授权数据类型的支持。如果相互支持的授权数据格式列表为空，则ServerHello消息不能包含受影响的扩展名。
Successful session resumption uses the same authorization information as the original session.
成功的会话恢复使用与原始会话相同的授权信息。
Client Server
客户端服务器
ClientHello (w/ extensions) -------->
ClientHello (w/ extensions) -------->
ServerHello (w/ extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ServerHello (w/ extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are not always sent.
* 指示并非始终发送的可选消息或情况相关消息。
[] Indicates that ChangeCipherSpec is an independent TLS protocol content type; it is not actually a TLS handshake message.
[]表示ChangeCipherSpec是独立的TLS协议内容类型；它实际上不是TLS握手消息。
Figure 1. Authorization Data Exchange in Full TLS Handshake
图1。全TLS握手中的授权数据交换
The general extension mechanisms enable clients and servers to negotiate whether to use specific extensions, and how to use specific extensions. As specified in [TLS1.2], the extension format used in the extended client hello message and extended server hello message is repeated here for convenience:
通用扩展机制使客户端和服务器能够协商是否使用特定扩展以及如何使用特定扩展。如[TLS1.2]中所述，为方便起见，此处重复了扩展客户端hello消息和扩展服务器hello消息中使用的扩展格式：
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
The extension_type identifies a particular extension type, and the extension_data contains information specific to the particular extension type. This document specifies the use of two new extension types: client_authz and server_authz. These extension types are described in Section 2.1 and Section 2.2, respectively. This specification adds two new types to ExtensionType:
扩展类型标识特定的扩展类型，扩展类型数据包含特定于特定扩展类型的信息。本文档指定了两种新扩展类型的使用：client_authz和server_authz。第2.1节和第2.2节分别描述了这些扩展类型。此规范向ExtensionType添加了两个新类型：
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;
The authorization extensions are relevant when a session is initiated and on any subsequent session resumption. However, a client that requests resumption of a session does not know whether the server will have all of the context necessary to accept this request, and therefore the client SHOULD send an extended client hello message that includes the extension types associated with the authorization extensions. This way, if the resumption request is denied, then the authorization extensions will be negotiated as normal.
授权扩展在会话启动和任何后续会话恢复时都是相关的。但是，请求恢复会话的客户端不知道服务器是否具有接受此请求所需的所有上下文，因此客户端应发送扩展客户端hello消息，其中包括与授权扩展关联的扩展类型。这样，如果恢复请求被拒绝，则授权扩展将正常协商。
When a session is resumed, ClientHello is followed immediately by ChangeCipherSpec, which does not provide an opportunity for different authorization information can be exchanged. Successful session resumption MUST use the same authorization information as the original session.
当会话恢复时，ClientHello后面紧接着ChangeCipherSpec，它不提供交换不同授权信息的机会。成功的会话恢复必须使用与原始会话相同的授权信息。
Clients MUST include the client_authz extension type in the extended client hello message to indicate their desire to send authorization data to the server. The extension_data field indicates the format of the authorization data that will be sent in the supplemental data handshake message. The syntax of the client_authz extension_data field is described in Section 2.3.
客户机必须在扩展客户机hello消息中包含client_authz扩展类型，以表明他们希望向服务器发送授权数据。extension_数据字段指示将在补充数据握手消息中发送的授权数据的格式。第2.3节中描述了client_authz extension_数据字段的语法。
Servers that receive an extended client hello message containing the client_authz extension MUST respond with the same client_authz extension in the extended server hello message if the server is willing to receive authorization data in the indicated format. Any unacceptable formats must be removed from the list provided by the client. The client_authz extension MUST be omitted from the extended server hello message if the server is not willing to receive authorization data in any of the indicated formats.
如果服务器愿意接收指定格式的授权数据，则接收包含client_authz扩展名的扩展客户端hello消息的服务器必须在扩展服务器hello消息中使用相同的client_authz扩展名进行响应。任何不可接受的格式必须从客户提供的列表中删除。如果服务器不愿意接收任何指定格式的授权数据，则必须从扩展服务器hello消息中省略client_authz扩展。
Clients MUST include the server_authz extension type in the extended client hello message to indicate their desire to receive authorization data from the server. The extension_data field indicates the format of the authorization data that will be sent in the supplemental data handshake message. The syntax of the server_authz extension_data field is described in Section 2.3.
客户端必须在扩展客户端hello消息中包含server_authz扩展类型，以表明其希望从服务器接收授权数据。extension_数据字段指示将在补充数据握手消息中发送的授权数据的格式。server_authz extension_数据字段的语法如第2.3节所述。
Servers that receive an extended client hello message containing the server_authz extension MUST respond with the same server_authz extension in the extended server hello message if the server is willing to provide authorization data in the requested format. Any unacceptable formats must be removed from the list provided by the client. The server_authz extension MUST be omitted from the extended server hello message if the server is not able to provide authorization data in any of the indicated formats.
如果服务器愿意以请求的格式提供授权数据，则接收包含server_authz扩展名的扩展客户端hello消息的服务器必须在扩展服务器hello消息中使用相同的server_authz扩展名进行响应。任何不可接受的格式必须从客户提供的列表中删除。如果服务器无法以任何指定的格式提供授权数据，则必须从扩展服务器hello消息中省略server_authz扩展。
The AuthzDataFormat type is used in both the client_authz and the server_authz extensions. It indicates the format of the authorization data that will be transferred. The AuthzDataFormats type definition is:
AuthzDataFormat类型在客户端authz和服务器authz扩展中都使用。它指示将传输的授权数据的格式。AuthzDataFormats类型定义为：
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), (255)
} AuthzDataFormat;
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), (255)
} AuthzDataFormat;
AuthzDataFormats authz_format_list<1..2^8-1>;
AuthzDataFormats authz_format_list<1..2^8-1>;
When the x509_attr_cert value is present, the authorization data is an X.509 attribute certificate (AC) that conforms to the profile in RFC 5755 [ATTRCERT].
当存在x509_attr_cert值时，授权数据是符合RFC 5755[ATTRCERT]中配置文件的X.509属性证书（AC）。
When the saml_assertion value is present, the authorization data is an assertion composed using the Security Assertion Markup Language (SAML) ([SAML1.1], [SAML2.0]).
当存在saml_断言值时，授权数据是使用安全断言标记语言（saml）（[SAML1.1]、[SAML2.0]）编写的断言。
When the x509_attr_cert_url value is present, the authorization data is an X.509 AC that conforms to the profile in RFC 5755 [ATTRCERT]; however, the AC is fetched with the supplied URL. A one-way hash value is provided to ensure that the intended AC is obtained.
当x509_attr_cert_url值存在时，授权数据是符合RFC 5755[ATTRCERT]中配置文件的X.509 AC；但是，AC是使用提供的URL获取的。提供单向散列值以确保获得预期AC。
When the saml_assertion_url value is present, the authorization data is a SAML assertion; however, the SAML assertion is fetched with the supplied URL. A one-way hash value is provided to ensure that the intended SAML assertion is obtained.
当saml_断言_url值存在时，授权数据为saml断言；但是，SAML断言是使用提供的URL获取的。提供单向散列值以确保获得预期的SAML断言。
Implementations that support either x509_attr_cert_url or saml_assertion_url MUST support URLs that employ the http scheme [HTTP]. These implementations MUST confirm that the hash value computed on the fetched authorization matches the one received in the handshake. Mismatch of the hash values SHOULD be treated as though the authorization was not provided, which will result in a bad_certificate_hash_value alert (see Section 4). Implementations
支持x509_attr_cert_url或saml_assertion_url的实现必须支持采用http方案[http]的url。这些实现必须确认在获取的授权上计算的哈希值与握手中接收的哈希值匹配。哈希值不匹配应视为未提供授权，这将导致错误的\u证书\u哈希值警报（请参阅第4节）。启动位置
MUST deny access if the authorization cannot be obtained from the provided URL, by sending a certificate_unobtainable alert (see Section 4).
如果无法从提供的URL获得授权，则必须通过发送证书不可获取警报来拒绝访问（参见第4节）。
As shown in Figure 1, supplemental data can be exchanged in two places in the handshake protocol. The client_authz extension determines what authorization data formats are acceptable for transfer from the client to the server, and the server_authz extension determines what authorization data formats are acceptable for transfer from the server to the client. In both cases, the syntax specified in [TLSSUPP] is used along with the authz_data type defined in this document.
如图1所示，在握手协议中，可以在两个位置交换补充数据。client_authz扩展确定哪些授权数据格式可以从客户端传输到服务器，而server_authz扩展确定哪些授权数据格式可以从服务器传输到客户端。在这两种情况下，[TLSSUPP]中指定的语法与本文档中定义的authz_数据类型一起使用。
enum {
authz_data(16386), (65535)
} SupplementalDataType;
enum {
authz_data(16386), (65535)
} SupplementalDataType;
struct {
SupplementalDataType supplemental_data_type;
select(SupplementalDataType) {
case authz_data: AuthorizationData;
}
} SupplementalData;
struct {
SupplementalDataType supplemental_data_type;
select(SupplementalDataType) {
case authz_data: AuthorizationData;
}
} SupplementalData;
The SupplementalData message sent from the client to the server contains authorization data associated with the TLS client. Following the principle of least privilege, the client ought to send the minimal set of authorization information necessary to accomplish the task at hand. That is, only those authorizations that are expected to be required by the server in order to gain access to the needed server resources ought to be included. The format of the authorization data depends on the format negotiated in the client_authz hello message extension. The AuthorizationData structure is described in Section 3.3.
从客户端发送到服务器的补充数据消息包含与TLS客户端关联的授权数据。遵循最小特权原则，客户机应该发送完成手头任务所需的最小授权信息集。也就是说，应该只包括服务器为了访问所需的服务器资源而需要的那些授权。授权数据的格式取决于在client_authz hello消息扩展中协商的格式。授权数据结构如第3.3节所述。
In some systems, clients present authorization information to the server, and then the server provides new authorization information. This type of transaction is not supported by SupplementalData messages. In cases where the client intends to request the TLS server to perform authorization translation or expansion services, such translation services ought to occur within the ApplicationData messages, and not within the TLS Handshake Protocol.
在某些系统中，客户端向服务器提供授权信息，然后服务器提供新的授权信息。补充数据消息不支持此类型的事务。在客户机打算请求TLS服务器执行授权转换或扩展服务的情况下，此类转换服务应该出现在ApplicationData消息中，而不是TLS握手协议中。
The SupplementalData message sent from the server to the client contains authorization data associated with the TLS server. This authorization information is expected to include statements about the server's qualifications, reputation, accreditation, and so on. Wherever possible, authorizations that can be misappropriated for fraudulent use ought to be avoided. The format of the authorization data depends on the format negotiated in the server_authz hello message extensions. The AuthorizationData structure is described in Section 3.3, and the following fictitious example of a single 5-octet SAML assertion illustrates its use:
从服务器发送到客户端的补充数据消息包含与TLS服务器关联的授权数据。此授权信息应包括有关服务器资格、声誉、认证等的声明。在可能的情况下，应避免为欺诈性使用而挪用授权。授权数据的格式取决于服务器\u authz hello消息扩展中协商的格式。AuthorizationData结构在第3.3节中进行了描述，下面一个5-octet SAML断言的虚构示例说明了它的用法：
17 # Handshake.msg_type == supplemental_data(23)
00 00 11 # Handshake.length = 17
00 00 0e # length of SupplementalData.supp_data = 14
40 02 # SupplementalDataEntry.supp_data_type = 16386
00 0a # SupplementalDataEntry.supp_data_length = 10
00 08 # length of AuthorizationData.authz_data_list = 8
01 # authz_format = saml_assertion(1)
00 05 # length of SAMLAssertion
aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")
17 # Handshake.msg_type == supplemental_data(23)
00 00 11 # Handshake.length = 17
00 00 0e # length of SupplementalData.supp_data = 14
40 02 # SupplementalDataEntry.supp_data_type = 16386
00 0a # SupplementalDataEntry.supp_data_length = 10
00 08 # length of AuthorizationData.authz_data_list = 8
01 # authz_format = saml_assertion(1)
00 05 # length of SAMLAssertion
aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")
The AuthorizationData structure carries authorization information for either the client or the server. The AuthzDataFormat specified in Section 2.3 for use in the hello extensions is also used in this structure.
AuthorizationData结构包含客户端或服务器的授权信息。第2.3节中指定用于hello扩展的AuthzDataFormat也用于此结构。
All of the entries in the authz_data_list MUST employ authorization data formats that were negotiated in the relevant hello message extension.
authz_data_列表中的所有条目都必须使用在相关hello消息扩展中协商的授权数据格式。
The HashAlgorithm type is taken from [TLS1.2], which allows additional one-way hash functions to be registered in the IANA TLS HashAlgorithm registry in the future.
HashAlgorithm类型取自[TLS1.2]，它允许将来在IANA TLS HashAlgorithm注册表中注册其他单向散列函数。
struct{
AuthorizationDataEntry authz_data_list<1..2^16-1>;
} AuthorizationData;
struct{
AuthorizationDataEntry authz_data_list<1..2^16-1>;
} AuthorizationData;
struct {
AuthzDataFormat authz_format;
select (AuthzDataFormat) {
case x509_attr_cert: X509AttrCert;
case saml_assertion: SAMLAssertion;
case x509_attr_cert_url: URLandHash;
case saml_assertion_url: URLandHash;
}
} AuthorizationDataEntry;
struct {
AuthzDataFormat authz_format;
select (AuthzDataFormat) {
case x509_attr_cert: X509AttrCert;
case saml_assertion: SAMLAssertion;
case x509_attr_cert_url: URLandHash;
case saml_assertion_url: URLandHash;
}
} AuthorizationDataEntry;
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), (255)
} AuthzDataFormat;
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), (255)
} AuthzDataFormat;
opaque X509AttrCert<1..2^16-1>;
opaque X509AttrCert<1..2^16-1>;
opaque SAMLAssertion<1..2^16-1>;
opaque SAMLAssertion<1..2^16-1>;
struct {
opaque url<1..2^16-1>;
HashAlgorithm hash_alg;
select (hash_alg) {
case md5: MD5Hash;
case sha1: SHA1Hash;
case sha224: SHA224Hash;
case sha256: SHA256Hash;
case sha384: SHA384Hash;
case sha512: SHA512Hash;
} hash;
} URLandHash;
struct {
opaque url<1..2^16-1>;
HashAlgorithm hash_alg;
select (hash_alg) {
case md5: MD5Hash;
case sha1: SHA1Hash;
case sha224: SHA224Hash;
case sha256: SHA256Hash;
case sha384: SHA384Hash;
case sha512: SHA512Hash;
} hash;
} URLandHash;
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
opaque MD5Hash[16];
不透明MD5Hash[16]；
opaque SHA1Hash[20];
不透明SHA1Hash[20]；
opaque SHA224Hash[28];
不透明散列[28]；
opaque SHA256Hash[32];
不透明SHA256Hash[32]；
opaque SHA384Hash[48];
不透明SHA384Hash[48]；
opaque SHA512Hash[64];
不透明SHA512Hash[64]；
When X509AttrCert is used, the field contains an ASN.1 Distinguished Encoding Rules (DER)-encoded X.509 attribute certificate (AC) that follows the profile in RFC 5755 [ATTRCERT]. An AC is a structure similar to a public key certificate (PKC) [PKIX1]; the main difference is that the AC contains no public key. An AC may contain attributes that specify group membership, role, security clearance, or other authorization information associated with the AC holder.
使用X509AttrCert时，该字段包含一个ASN.1可分辨编码规则（DER）编码的X.509属性证书（AC），该证书遵循RFC 5755[ATTRCERT]中的配置文件。AC是类似于公钥证书（PKC）[PKIX1]的结构；主要区别在于AC不包含公钥。AC可能包含指定组成员资格、角色、安全许可或与AC持有人相关的其他授权信息的属性。
When making an authorization decision based on an AC, proper linkage between the AC holder and the public key certificate that is transferred in the TLS Certificate message is needed. The AC holder field provides this linkage. The holder field is a SEQUENCE allowing three different (optional) syntaxes: baseCertificateID, entityName, and objectDigestInfo. In the TLS authorization context, the holder field MUST use either the baseCertificateID or entityName. In the baseCertificateID case, the baseCertificateID field MUST match the issuer and serialNumber fields in the certificate. In the entityName case, the entityName MUST be the same as the subject field in the certificate or one of the subjectAltName extension values in the certificate. Note that [PKIX1] mandates that the subjectAltName extension be present if the subject field contains an empty distinguished name.
当基于AC做出授权决策时，AC持有者和TLS证书消息中传输的公钥证书之间需要适当的链接。空调保持架字段提供此链接。holder字段是一个允许三种不同（可选）语法的序列：baseCertificateID、entityName和objectDigestInfo。在TLS授权上下文中，holder字段必须使用baseCertificateID或entityName。在baseCertificateID情况下，baseCertificateID字段必须与证书中的issuer和serialNumber字段匹配。在entityName情况下，entityName必须与证书中的subject字段或证书中的subjectAltName扩展值之一相同。请注意，[PKIX1]要求如果subject字段包含空的可分辨名称，则subjectAltName扩展必须存在。
When SAMLAssertion is used, the field MUST contain well-formed XML [XML1.0] and MUST use either UTF-8 [UTF-8] or UTF-16 [UTF-16] character encoding. UTF-8 is the preferred character encoding. The XML text declaration MUST be followed by an <Assertion> element using the AssertionType complex type as defined in [SAML1.1] and [SAML2.0]. The XML text MUST also follow the rules of [XML1.0] for including the Byte Order Mark (BOM) in encoded entities. SAML is an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects,
使用SAMLAssertion时，字段必须包含格式良好的XML[XML1.0]，并且必须使用UTF-8[UTF-8]或UTF-16[UTF-16]字符编码。UTF-8是首选的字符编码。XML文本声明后面必须跟一个<Assertion>元素，该元素使用[SAML1.1]和[SAML2.0]中定义的AssertionType复杂类型。XML文本还必须遵循[XML1.0]的规则，以便在编码实体中包含字节顺序标记（BOM）。SAML是用于交换安全信息的基于XML的框架。该安全信息以关于主题的断言的形式表示，
where a subject is either human or computer with an identity. In this context, the SAML assertions are most likely to convey authentication or attribute statements to be used as input to authorization policy governing whether subjects are allowed to access certain resources. Assertions are issued by SAML authorities.
主体是具有身份的人或计算机。在这种情况下，SAML断言最有可能传递身份验证或属性语句，作为授权策略的输入，用于控制是否允许主体访问某些资源。断言由SAML当局发布。
When making an authorization decision based on a SAML assertion, proper linkage between the SAML assertion and the public key certificate that is transferred in the TLS Certificate message may be needed. A "Holder of Key" subject confirmation method in the SAML assertion can provide this linkage. In other scenarios, it may be acceptable to use alternate confirmation methods that do not provide a strong binding, such as a bearer mechanism. SAML assertion recipients MUST decide which subject confirmation methods are acceptable; such decisions MAY be specific to the SAML assertion contents and the TLS session context.
当基于SAML断言做出授权决策时，可能需要SAML断言和TLS证书消息中传输的公钥证书之间的适当链接。SAML断言中的“密钥持有者”主题确认方法可以提供这种链接。在其他场景中，可以使用不提供强绑定的替代确认方法，例如承载机制。SAML断言接收者必须决定哪些主题确认方法是可接受的；此类决定可能特定于SAML断言内容和TLS会话上下文。
There is no general requirement that the subject of the SAML assertion correspond directly to the subject of the certificate. They may represent the same or different entities. When they are different, SAML also provides a mechanism by which the certificate subject can be identified separately from the subject in the SAML assertion subject confirmation method.
SAML断言的主题与证书的主题没有直接对应的一般要求。它们可能代表相同或不同的实体。当它们不同时，SAML还提供了一种机制，通过该机制，可以在SAML断言主题确认方法中将证书主题与主题分开标识。
Since the SAML assertion is being provided at a part of the TLS handshake that is unencrypted, an eavesdropper could replay the same SAML assertion when they establish their own TLS session. This is especially important when a bearer mechanism is employed; the recipient of the SAML assertion assumes that the sender is an acceptable attesting entity for the SAML assertion. Some constraints may be included to limit the context where the bearer mechanism will be accepted. For example, the period of time that the SAML assertion can be short-lived (often minutes), the source address can be constrained, or the destination endpoint can be identified. Also, bearer assertions are often checked against a cache of SAML assertion unique identifiers that were recently received, in order to detect replay. This is an appropriate countermeasure if the bearer assertion is intended to be used just once. Section 6 provides a way to protect authorization information when necessary.
由于SAML断言是在未加密的TLS握手部分提供的，因此窃听者可以在建立自己的TLS会话时重播相同的SAML断言。这在采用承载机制时尤其重要；SAML断言的接收者假定发送者是SAML断言的可接受证明实体。可以包括一些约束以限制承载机制将被接受的上下文。例如，SAML断言可以是短期的（通常是几分钟）、可以约束源地址或可以识别目标端点的时间段。此外，为了检测重播，通常会根据最近接收到的SAML断言唯一标识符缓存检查承载断言。如果承载断言只打算使用一次，那么这是一种适当的对策。第6节提供了在必要时保护授权信息的方法。
Since the X.509 AC and SAML assertion can be large, alternatives provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML assertion. To ensure that the intended object is obtained, a one-way hash value of the object is also included. Integrity of this one-way hash value is provided by the TLS Finished message.
由于X.509 AC和SAML断言可能很大，因此备选方案提供了一个URL来获取ASN.1 DER编码的X.509 AC或SAML断言。为了确保获得预期对象，还包括该对象的单向散列值。此单向散列值的完整性由TLS Finished消息提供。
Implementations that support either x509_attr_cert_url or saml_assertion_url MUST support URLs that employ the HTTP scheme. Other schemes may also be supported. When dereferencing these URLs, circular dependencies MUST be avoided. Avoiding TLS when dereferencing these URLs is one way to avoid circular dependencies. Therefore, clients using the HTTP scheme MUST NOT use these TLS extensions if UPGRADE in HTTP [UPGRADE] is used. For other schemes, similar care must be taken to avoid using these TLS extensions.
支持x509_attr_cert_url或saml_assertion_url的实现必须支持采用HTTP方案的url。其他计划也可能得到支持。当取消引用这些URL时，必须避免循环依赖关系。在取消引用这些URL时避免TLS是避免循环依赖的一种方法。因此，如果使用HTTP[UPGRADE]中的升级，则使用HTTP方案的客户端不得使用这些TLS扩展。对于其他方案，必须注意避免使用这些TLS扩展。
Implementations that support either x509_attr_cert_url or saml_assertion_url MUST support both SHA-1 [SHS] and SHA-256 [SHS] as one-way hash functions. Other one-way hash functions may also be supported. Additional one-way hash functions can be added to the IANA TLS HashAlgorithm registry in the future.
支持x509_attr_cert_url或saml_assertion_url的实现必须同时支持SHA-1[SHS]和SHA-256[SHS]作为单向散列函数。还可以支持其他单向散列函数。将来可以向IANA TLS HashAlgorithm注册表添加其他单向散列函数。
Implementations that support x509_attr_cert_url MUST support responses that employ the "application/pkix-attr-cert" Multipurpose Internet Mail Extension (MIME) media type as defined in [ACTYPE].
支持x509_attr_cert_url的实现必须支持使用[ACTYPE]中定义的“应用程序/pkix attr cert”多用途Internet邮件扩展（MIME）媒体类型的响应。
Implementations that support saml_assertion_url MUST support responses that employ the "application/samlassertion+xml" MIME type as defined in Appendix A of [SAMLBIND].
支持saml_断言_url的实现必须支持使用[SAMLBIND]附录A中定义的“application/samlassertion+xml”MIME类型的响应。
TLS authorizations SHOULD follow the additional guidance provided in Section 3.3 of [TLSEXT2] regarding client certificate URLs.
TLS授权应遵循[TLSEXT2]第3.3节中关于客户证书URL的附加指南。
This document specifies the reuse of TLS Alert messages related to public key certificate processing for any errors that arise during authorization processing, while preserving the AlertLevels as authoritatively defined in [TLS1.2] or [TLSEXT2]. All alerts used in authorization processing are fatal.
本文档规定了在授权处理过程中出现的任何错误时重用与公钥证书处理相关的TLS警报消息，同时保留[TLS1.2]或[TLSEXT2]中权威定义的警报级别。授权处理中使用的所有警报都是致命的。
The following updated definitions for the Alert messages are used to describe errors that arise while processing authorizations. For ease of comparison, we reproduce the Alert message definition from Section 7.2 of [TLS1.2], augmented with two values defined in [TLSEXT2]:
以下警报消息的更新定义用于描述处理授权时出现的错误。为了便于比较，我们复制了[TLS1.2]第7.2节中的警报消息定义，并增加了[TLSEXT2]中定义的两个值：
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
certificate_unobtainable(111),
bad_certificate_hash_value(114),
(255)
} AlertDescription;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
certificate_unobtainable(111),
bad_certificate_hash_value(114),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
TLS processing of alerts includes some ambiguity because the message does not indicate which certificate in a certification path gave rise to the error. This problem is made slightly worse in this extended use of alerts, as the alert could be the result of an error in processing of either a certificate or an authorization. Implementations that support these extensions should be aware of this imprecision.
TLS对警报的处理包含一些模糊性，因为该消息没有指明证书路径中的哪个证书导致了错误。在这种警报的扩展使用中，此问题会稍微恶化，因为警报可能是由于处理证书或授权时出错造成的。支持这些扩展的实现应该意识到这种不精确性。
The AlertDescription values are used as follows to report errors in authorizations processing:
AlertDescription值用于报告授权处理中的错误，如下所示：
bad_certificate In certificate processing, bad_certificate indicates that a certificate was corrupt, contained signatures that did not verify correctly, and so on. Similarly, in authorization processing, bad_certificate indicates that an authorization was corrupt, contained signatures that did not verify correctly, and so on. In authorization processing, bad_certificate can also indicate that the handshake established that an AuthzDataFormat was to be provided, but no AuthorizationData of the expected format was provided in SupplementalData.
bad_证书在证书处理中，bad_证书表示证书已损坏，包含未正确验证的签名，等等。类似地，在授权处理中，bad_证书表示授权已损坏，包含未正确验证的签名，等等。在授权处理中，bad_证书还可以表示握手确定要提供AuthzDataFormat，但在补充数据中未提供预期格式的授权数据。
unsupported_certificate In certificate processing, unsupported_certificate indicates that a certificate was of an unsupported type. Similarly, in authorization processing, unsupported_certificate indicates that AuthorizationData uses a version or format unsupported by the implementation.
不支持的\u证书在证书处理中，不支持的\u证书表示证书的类型不受支持。类似地，在授权处理中，unsupported_certificate表示AuthorizationData使用实现不支持的版本或格式。
certificate_revoked In certificate processing, certificate_revoked indicates that a certificate was revoked by its issuer. Similarly, in authorization processing, certificate_revoked indicates that authorization was revoked by its issuer, or a certificate that was needed to validate the signature on the authorization was revoked by its issuer.
证书\u已在证书处理中吊销，证书\u已吊销表示证书已被其颁发者吊销。类似地，在授权处理中，certificate_Reversed表示授权已被其颁发者撤销，或者验证授权签名所需的证书已被其颁发者撤销。
certificate_expired In certificate processing, certificate_expired indicates that a certificate has expired or is not currently valid. Similarly, in authorization processing, certificate_expired indicates that an authorization has expired or is not currently valid.
证书\u在证书处理中过期，证书\u过期表示证书已过期或当前无效。类似地，在授权处理中，证书_expired表示授权已过期或当前无效。
certificate_unknown In certificate processing, certificate_unknown indicates that some other (unspecified) issue arose while processing the certificate, rendering it unacceptable. Similarly, in authorization processing, certificate_unknown indicates that processing of AuthorizationData failed because of other (unspecified) issues, including AuthzDataFormat parse errors.
证书_未知在证书处理中，证书_未知表示在处理证书时出现其他（未指定）问题，使其不可接受。类似地，在授权处理中，certificate_unknown表示由于其他（未指定）问题，包括AuthzDataFormat解析错误，授权数据的处理失败。
unknown_ca In certificate processing, unknown_ca indicates that a valid certification path or partial certification path was received, but the certificate was not accepted because the certification authority (CA) certificate could not be located or could not be
unknown_ca在证书处理中，unknown_ca表示接收到有效的证书路径或部分证书路径，但证书未被接受，因为找不到或无法找到证书颁发机构（ca）证书
matched with a known, trusted CA. Similarly, in authorization processing, unknown_ca indicates that the authorization issuer is not known and trusted.
与已知的、受信任的CA匹配。类似地，在授权处理中，未知的CA表示授权颁发者未知且不受信任。
access_denied In certificate processing, access_denied indicates that a valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. Similarly, in authorization processing, access_denied indicates that the authorization was not sufficient to grant access.
在证书处理中拒绝访问，拒绝访问表示收到了有效的证书，但在应用访问控制时，发件人决定不继续协商。类似地，在授权处理中，access_denied表示授权不足以授予访问权限。
certificate_unobtainable The client_certificate_url extension defined in RFC 4366 [TLSEXT2] specifies that download errors lead to a certificate_unobtainable alert. Similarly, in authorization processing, certificate_unobtainable indicates that a URL does not result in an authorization. While certificate processing does not require this alert to be fatal, this is a fatal alert in authorization processing.
证书不可获取RFC 4366[TLSEXT2]中定义的客户端证书url扩展指定下载错误导致证书不可获取警报。类似地，在授权处理中，certificate_Unabled表示URL不会导致授权。虽然证书处理不要求此警报为致命警报，但这是授权处理中的致命警报。
bad_certificate_hash_value In certificate processing, bad_certificate_hash_value indicates that a downloaded certificate does not match the expected hash. Similarly, in authorization processing, bad_certificate_hash_value indicates that a downloaded authorization does not match the expected hash.
错误的\u证书\u哈希值在证书处理中，错误的\u证书\u哈希值表示下载的证书与预期的哈希不匹配。类似地，在授权处理中，错误的\u证书\u散列\u值表示下载的授权与预期的散列不匹配。
This document defines two TLS extensions: client_authz(7) and server_authz(8). These extension type values are assigned from the TLS Extension Type registry defined in [TLSEXT2].
本文档定义了两个TLS扩展：client_authz（7）和server_authz（8）。这些扩展类型值是从[TLSEXT2]中定义的TLS扩展类型注册表分配的。
This document defines one TLS supplemental data type: authz_data(16386). This supplemental data type is assigned from the TLS Supplemental Data Type registry defined in [TLSSUPP].
本文档定义了一种TLS补充数据类型：authz_数据（16386）。此补充数据类型是从[TLSSUPP]中定义的TLS补充数据类型注册表分配的。
This document establishes a new registry, to be maintained by IANA, for TLS Authorization Data Formats. The first four entries in the registry are x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), and saml_assertion_url(3). TLS Authorization Data Format identifiers with values in the inclusive range 0-63 (decimal) are assigned via RFC 5226 [IANA] IETF Review. Values from the inclusive range 64-223 (decimal) are assigned via RFC 5226 Specification Required. Values from the inclusive range 224-255 (decimal) are reserved for RFC 5226 Private Use.
本文件为TLS授权数据格式建立了一个新的注册表，由IANA维护。注册表中的前四个条目是x509_attr_cert（0）、saml_断言（1）、x509_attr_cert_url（2）和saml_断言_url（3）。通过RFC 5226[IANA]IETF Review分配值在0-63（十进制）范围内的TLS授权数据格式标识符。包含范围64-223（十进制）的值通过RFC 5226规范指定。包含范围224-255（十进制）的值保留给RFC 5226专用。
A TLS server can support more than one application, and each application may include several features, each of which requires separate authorization checks. This is the reason that more than one piece of authorization information can be provided.
TLS服务器可以支持多个应用程序，每个应用程序可能包括多个功能，每个功能都需要单独的授权检查。这就是可以提供多条授权信息的原因。
A TLS server that requires different authorization information for different applications or different application features may find that a client has provided sufficient authorization information to grant access to a subset of these offerings. In this situation, the TLS Handshake Protocol will complete successfully; however, the server must ensure that the client will only be able to use the appropriate applications and application features. That is, the TLS server must deny access to the applications and application features for which authorization has not been confirmed.
需要不同应用程序或不同应用程序功能的不同授权信息的TLS服务器可能会发现客户端提供了足够的授权信息来授予对这些产品子集的访问权。在这种情况下，TLS握手协议将成功完成；但是，服务器必须确保客户端只能使用适当的应用程序和应用程序功能。也就是说，TLS服务器必须拒绝访问尚未确认授权的应用程序和应用程序功能。
In cases where the authorization information itself is sensitive, the double handshake technique can be used to provide protection for the authorization information. Figure 2 illustrates the double handshake, where the initial handshake does not include any authorization extensions, but it does result in protected communications. Then, a second handshake that includes the authorization 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 authorization 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 authorization information.
在TLS握手中放置补充数据消息会导致服务器在对客户端进行身份验证之前提供其授权信息。在许多情况下，服务器在客户端通过身份验证之前不希望提供授权信息。图2中所示的双重握手提供了一种技术，以确保在任何一方提供授权信息之前，双方都经过相互身份验证。
The use of bearer SAML assertions allows an eavesdropper or a man-in-the-middle to capture the SAML assertion and try to reuse it in another context. The constraints discussed in Section 3.3.2 might be effective against an eavesdropper, but they are less likely to be effective against a man-in-the-middle. Authentication of both parties in the TLS session, which involves the use of client authentication, will prevent an undetected man-in-the-middle, and the use of the double handshake illustrated in Figure 2 will prevent the disclosure of the bearer SAML assertion to any party other than the TLS peer.
使用承载SAML断言允许窃听者或中间人捕获SAML断言，并尝试在另一个上下文中重用它。第3.3.2节中讨论的约束可能对窃听者有效，但对中间人不太可能有效。TLS会话中双方的身份验证（涉及使用客户端身份验证）将防止中间出现未被检测到的人，并且使用图2中所示的双重握手将防止向TLS对等方以外的任何一方披露承载SAML断言。
AuthzDataFormats that point to authorization data, such as x509_attr_cert_url and saml_assertion_url, rather than simply including the authorization data in the handshake, may be exploited by an attacker. Implementations that accept pointers to authorization data SHOULD adopt a policy of least privilege that limits the acceptable references that they will attempt to use. For more information, see Section 6.3 of [TLSEXT2].
攻击者可能会利用指向授权数据的AuthzData格式，例如x509_attr_cert_url和saml_assertion_url，而不仅仅是在握手中包含授权数据。接受授权数据指针的实现应该采用最小特权策略，该策略限制它们将尝试使用的可接受引用。有关更多信息，请参见[TLSEXT2]第6.3节。
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 (w/ authz data)* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData (w/ authz data)* |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 (w/ authz data)* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData (w/ authz data)* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
Figure 2. Double Handshake To Protect Authorization Data
图2。双重握手以保护授权数据
The authors thank Scott Cantor for his assistance with the SAML assertion portion of the document.
作者感谢Scott Cantor对文档SAML断言部分的帮助。
[ACTYPE] Housley, R., "The application/pkix-attr-cert Media Type for Attribute Certificates", RFC 5877, May 2010.
[ACTYPE]Housley，R.，“属性证书的应用程序/pkix属性证书媒体类型”，RFC 5877，2010年5月。
[ATTRCERT] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[ATTRCERT]Farrell，S.，Housley，R.，和S.Turner，“用于授权的互联网属性证书配置文件”，RFC 57552010年1月。
[HTTP] 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.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[PKIX1] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIX1]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[SAML1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set", September 2003.
[SAML1.1]OASIS安全服务技术委员会，“安全断言标记语言（SAML）1.1版规范集”，2003年9月。
[SAML2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set", March 2005.
[SAML2.0]OASIS安全服务技术委员会，“安全断言标记语言（SAML）2.0版规范集”，2005年3月。
[SAMLBIND] OASIS Security Services Technical Committee, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005.
[SAMLBIND]OASIS安全服务技术委员会，“OASIS安全断言标记语言（SAML）V2.0的绑定”，2005年3月。
[SHS] National Institute of Standards and Technology (NIST), FIPS PUB 180-3, Secure Hash Standard (SHS), October 2008.
[SHS]国家标准与技术研究所（NIST），FIPS PUB 180-3，安全哈希标准（SHS），2008年10月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS1.0]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS1.1]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[TLS1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS1.2]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[TLSEXT2] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[TLSEXT2]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[TLSSUPP] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, October 2006.
[TLSSUPP]Santesson，S.，“补充数据的TLS握手信息”，RFC 46802006年10月。
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[升级]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[UTF-16]Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[XML1.0] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", http://www.w3.org/TR/xml/, November 2008.
[XML1.0]Bray，T.，J.Paoli，C.M.Sperberg McQueen，E.Maler和F.Yergeau，“可扩展标记语言（XML）1.0（第五版）”，http://www.w3.org/TR/xml/，2008年11月。
[TLSEXT1] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[TLSEXT1]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 35462003年6月。
Authors' Addresses
作者地址
Mark Brown RedPhone Security 1199 Falls View Court Mendota Heights, MN 55118 USA EMail: mark@redphonesecurity.com
Mark Brown RedPhone Security 1199 Falls View Court Mendota Heights，明尼苏达州55118美国电子邮件：mark@redphonesecurity.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州20170美国电子邮件：housley@vigilsec.com