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
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（Security Assertion Markup Language）アサーションとして、クライアントとサーバ、認証情報の両方でサポートされている場合、補足データのハンドシェイクメッセージで交換されます。
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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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（Security Assertion Markup Language）アサーション（[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 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].
この文書では、TLS 1.0、TLS 1.1、およびTLS 1.2でTLSハンドシェイクプロトコルの認可の拡張機能について説明します。これらの拡張機能は、もともと[TLSEXT1]で定義されており、[TLSEXT2]に改定されたTLSの拡張のために定義された規則を遵守し、 TLSの拡張子は今[TLS1.2] TLS 1.2の一部です。 TLSの拡張は、クライアントハローメッセージとサーバーの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と組み合わせて使用することができます。拡張機能は、クライアントは、クライアントハローメッセージでそれらのサポートを示しており、サーバは、サーバハローメッセージでそれらのサポートを示している場合、ハンドシェイクプロトコルの補足データメッセージは、特定の種類の認証情報が含まれていることを意味し、後方互換性を持つように設計されています。
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].
認証メッセージの構文は、[TLS1.0]のセクション4で指定された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 [STDWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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) -------->
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
完全なTLSハンドシェイク図1.認証データ交換
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メッセージおよびメッセージは便宜上、ここで繰り返されるハロー拡張サーバ。
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:
EXTENSION_TYPEは、特定の拡張子の種類を識別し、拡大は、特定の拡張子タイプに固有の情報が含まれています。 client_authzとserver_authz：この文書は、2つの新しい拡張型を使用することを指定します。これらの拡張タイプは、それぞれ、2.1節及び2.2節に記載されています。この仕様は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拡張タイプを含まなければなりません。拡大フィールドは、補足データハンドシェークメッセージで送信される認証データのフォーマットを示します。 client_authz拡大フィールドの構文は、セクション2.3に記載されています。
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拡張子で応じなければなりませんclient_authz拡張子を含むハローメッセージを受け取るサーバー。任意の許容できないフォーマットは、クライアントによって提供されたリストから除去されなければなりません。サーバが示されているフォーマットのいずれかで認証データを受信することを望んでいない場合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拡張タイプを含まなければなりません。拡大フィールドは、補足データハンドシェークメッセージで送信される認証データのフォーマットを示します。 server_authz拡大フィールドの構文は、セクション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拡張子で応じなければなりませんserver_authz拡張子を含むハローメッセージを受け取るサーバー。任意の許容できないフォーマットは、クライアントによって提供されたリストから除去されなければなりません。サーバが示されているフォーマットのいずれかで認証データを提供することができない場合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タイプはclient_authzとserver_authz拡張の両方で使用されています。これは、転送されます認証データの形式を示します。 AuthzDataFormatsタイプ定義は次のとおりです。
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_assertion値が存在する場合、許可データは、セキュリティアサーションマークアップ言語（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値が存在する場合、許可データは、[ATTRCERT] RFC 5755で、プロファイルに準拠した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_assertion_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をサポートしなければなりません。これらの実装は、フェッチされた許可に計算されたハッシュ値は、ハンドシェークで受信したものと一致することを確認しなければなりません。許可がbad_certificate_hash_valueアラート（セクション4を参照）をもたらすであろう、提供されなかったかのようにハッシュ値の不一致は、治療すべきです。実装
MUST deny access if the authorization cannot be obtained from the provided URL, by sending a certificate_unobtainable alert (see Section 4).
認証がcertificate_unobtainableアラートを送信することにより、提供された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に示すように、補足データは、ハンドシェークプロトコルで2つの場所で交換することができます。 client_authz拡張認証データ形式はクライアントからサーバーへの転送、およびserver_authz拡張のために許容されるかを決定することは許可データ形式はサーバーからクライアントへの転送のために許容可能であるかを決定します。両方の場合において、[TLSSUPP]で指定された構文は、本書では定義されauthz_dataタイプと共に使用されます。
enum {
authz_data(16386), (65535)
} SupplementalDataType;
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.
クライアントからサーバに送信されSupplementalDataメッセージは、TLSクライアントに関連付けられた認証データが含まれています。最小特権の原則に続いて、クライアントは手でタスクを達成するために必要な認証情報の最小セットを送信するべきです。つまり、必要なサーバリソースへのアクセスが含まれるべきであるを得るために、サーバによって必要とされることが期待されているもののみの権限です。認証データの形式は、client_authzハローメッセージ拡張で交渉形式によって異なります。 AuthorizationData構造はセクション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.
いくつかのシステムでは、クライアントの現在の認証サーバへの情報、そしてその後、サーバーは、新しい認証情報を提供します。トランザクションのこのタイプは、SupplementalDataメッセージによってサポートされていません。クライアントは、認可翻訳または拡張サービスを実行するために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:
サーバからクライアントに送信されSupplementalDataメッセージはTLSサーバに関連付けられた認証データが含まれています。この権限情報は、ように、サーバーの資格に関する記述、評判、認定などを含めることが予想されます。可能な限り、不正使用のために流用することが可能な権限は回避されるべきです。認証データの形式は、server_authzのhelloメッセージの拡張で交渉形式によって異なります。 AuthorizationData構造はセクション3.3に記載され、単5オクテット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 SupplementalData.supp_data位長= 14 40 02＃SupplementalDataEntry.supp_data_type = 16386 00 0A＃SupplementalDataEntry.supp_data_length = 10 00 08＃ SAMLAssertionのAAのAA、AA、AAのAA＃のSAMLアサーション（ "AA、AAのAAのAAのAA" 架空）のAuthorizationData.authz_data_list = 8 01＃1 authz_format = saml_assertion（1）00 05＃長の長さ
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節で指定された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_list内のエントリのすべてが該当する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タイプは、追加の一方向ハッシュ関数が将来IANA TLS HashAlgorithmレジストリに登録されることを可能にする[TLS1.2]から取られます。
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;
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>;
不透明X509AttrCert <1..2 ^ 16-1>;
opaque SAMLAssertion<1..2^16-1>;
不透明な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;
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];
不透明SHA224Hash [28]。
opaque SHA256Hash[32];
不透明SHA256Hash [32]。
opaque SHA384Hash[48];
不透明SHA384ハッシュ[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を使用した場合、フィールドは、RFC 5755 [ATTRCERT]内のプロファイルに従うASN.1顕著な符号化規則（DER）でエンコードX.509属性証明書（AC）を含みます。 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証明書メッセージに転送された公開鍵証明書の間の適切な連携が必要とされています。 ACホルダーフィールドは、このリンクを提供します。 baseCertificateID、エンティティネーム、及びobjectDigestInfo：ホルダーフィールドは、3つの異なる（オプション）構文を可能にする配列です。 TLS認証コンテキストでは、ホルダーフィールドはbaseCertificateIDまたはエンティティネームのいずれかを使用しなければなりません。 baseCertificateIDケースにおいて、baseCertificateIDフィールドは、証明書発行者とのserialNumberフィールドに一致しなければなりません。エンティティネームの場合、エンティティネームは、証明書または証明書にsubjectAltName拡張値のいずれかとする対象フィールドと同じでなければなりません。サブジェクトフィールドが空の識別名が含まれている場合、subjectAltName拡張が存在する[PKIX1]任務ことに留意されたいです。
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, 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.
SAMLAssertionを使用した場合、フィールドは[XML1.0]整形式XMLを含まなければなりませんし、UTF-8 [UTF-8]またはUTF-16 [UTF-16]文字エンコーディングのいずれかを使用しなければなりません。 UTF-8は、好適な文字エンコーディングです。 [SAML2.0] [SAML1.1]で定義したXMLテキスト宣言はAssertionType複合型を使用して<アサーション>要素が続かなければなりません。 XMLのテキストもエンコードされたエンティティにバイトオーダーマーク（BOM）を含むため[XML1.0]の規則に従わなければなりません。 SAMLは、セキュリティ情報を交換するためのXMLベースのフレームワークです。このセキュリティ情報は、対象が同一性を有するヒトまたはコンピュータのいずれかである対象、約アサーションの形で表現されます。この文脈では、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アサーションを大きくすることができるので、選択肢はASN.1のDER符号化されたX.509 ACまたはSAMLアサーションを取得するためにURLを提供します。所期の目的が得られることを保証するために、オブジェクトの一方向ハッシュ値も含まれます。この一方向ハッシュ値の完全性は、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]でUPGRADEを使用している場合は、これらのTLS拡張を使用してはならないHTTPスキームを使用しているクライアント。他の方式の場合は、同様の注意がこれらの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のいずれかをサポートする実装は、一方向ハッシュ関数として[SHS] SHA-1 [SHS]とSHA-256の両方をサポートしなければなりません。他の一方向ハッシュ関数もサポートすることができます。追加の一方向ハッシュ関数は、将来の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」多目的インターネットメール拡張（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_assertion_urlをサポートする実装は、[SAMLBIND]の付録Aで定義されるような「アプリケーション/ samlassertion + XML」MIMEタイプを使用する応答をサポートしなければなりません。
TLS authorizations SHOULD follow the additional guidance provided in Section 3.3 of [TLSEXT2] regarding client certificate URLs.
TLSの権限は、クライアント証明書のURLについて[TLSEXT2]のセクション3.3で提供される追加のガイダンスに従ってください。
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.
厳然[TLSEXT2] [TLS1.2]で定義されたかAlertLevelsを維持しながら、この文書では、認可処理中に発生したエラーのために公開鍵証明書の処理に関連するTLS警告メッセージの再利用を指定します。認可処理で使用されるすべてのアラートは致命的です。
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]、[TLSEXT2]で定義された二つの値で拡張の7.2節からのアラートメッセージの定義を再現します：
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;
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_certificateは、bad_certificateは、証明書は、壊れたように正確に確認し、しませんでした署名が含まれていることを示しています。同様に、認可処理に、bad_certificateは承認が、壊れたように正確に確認し、しませんでした署名が含まれていることを示しています。認可処理において、bad_certificateもハンドシェークがAuthzDataFormatが提供されるようになったことを確立したが、予想されるフォーマットのないAuthorizationDataをSupplementalDataで提供されなかったことを示すことができます。
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.
証明書処理においてunsupported_certificate、unsupported_certificate証明書がサポートされていないタイプのものであったことを示しています。同様に、認可処理において、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.
証明書処理でcertificate_revoked、certificate_revokedは、証明書が発行者によって取り消されたことを示しています。同様に、認可処理において、許可は、その発行者によって取り消されたことを示し、又は承認の署名を検証するために必要とされた証明書は、その発行者によって取り消されたcertificate_revoked。
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.
証明書処理でcertificate_expired、certificate_expiredは、証明書の有効期限が切れてか、現在有効ではないことを示しています。同様に、認可処理に、certificate_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は、certificate_unknownは許容できない、それをレンダリングする、証明書の処理中にいくつかの他の（不特定の）問題が発生したことを示しています。同様に、認可処理において、certificate_unknownはAuthorizationDataの処理が原因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 matched with a known, trusted CA. Similarly, in authorization processing, unknown_ca indicates that the authorization issuer is not known and trusted.
証明書の処理でunknown_caは、unknown_caは、有効な証明書パスまたは部分的証明書パスを受信したことを示しますが、証明書は、認証局（CA）証明書が見つかりませんでしたので、受け入れられなかったか、知られている、信頼できるCAと一致することができませんでした同様に、認可処理において、unknown_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、有効な証明書が受信されたことを示しているが、アクセス制御が適用されたとき、送信者が交渉を進めないことを決定したACCESS_DENIED。同様に、認可処理において、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.
[TLSEXT2]ダウンロードエラーがcertificate_unobtainableアラートにつながることを指定するRFC 4366で定義されてclient_certificate_url拡張をcertificate_unobtainable。同様に、認可処理に、certificate_unobtainableは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.
証明書の処理でbad_certificate_hash_valueは、bad_certificate_hash_valueは、ダウンロードした証明書が期待されるハッシュと一致しないことを示しています。同様に、認可処理に、bad_certificate_hash_valueは、ダウンロードの許可が期待されるハッシュが一致しないことを示しています。
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].
client_authz（7）とserver_authz（8）：この文書は、二つのTLS拡張を定義します。これらの拡張タイプ値は、[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].
authz_data（16386）：この文書は、一のTLS補足データ・タイプを定義します。この補足的なデータタイプは[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によって維持される新しいレジストリを確立します。レジストリ内の最初の4つのエントリはx509_attr_cert（0）、saml_assertion（1）、x509_attr_cert_url（2）、及びsaml_assertion_url（3）です。包含範囲0-63（10進数）の値とのTLS認証データフォーマット識別子は、RFC 5226 [IANA] IETFレビューを介して割り当てられています。包含範囲64から223（10進数）の値は、RFC 5226仕様が必要経由して割り当てられます。包含範囲224から255（10進数）の値は、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のハンドシェイクは、保護された通信を使用して実行されます。図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ハンドシェイクの結果でSupplementalDataメッセージの配置。多くの状況では、サーバーは、クライアントが認証されるまで、認証情報を提供するとは思わないだろう。図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アサーションを使用すると、盗聴者かのman-in-the-middleは、SAMLアサーションをキャプチャし、別のコンテキストでそれを再利用しようとすることができます。 3.3.2項で述べた制約は、盗聴者に対して有効であるかもしれないが、彼らはのman-in-the-middleに対して有効である可能性が低いです。クライアント認証の使用を含むTLSセッションにおける両当事者の認証、未検出のman-in-the-middleを防止する、図2に示す二重ハンドシェークの使用は、にベアラSAMLアサーションの開示を防止しますTLSピア以外の任意のパーティ。
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].
単にハンドシェークにおける認証データを含むようx509_attr_cert_urlとsaml_assertion_urlなどの認証データを指すAuthzDataFormats、むしろよりは、攻撃者が利用することができます。認証データへのポインタを受け入れる実装は、彼らが使用しようと許容の参照を制限最小特権の政策を採用すべきです。詳細については、[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
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.
著者は、文書のSAMLアサーションの部分との彼の援助のためのスコット・カンターに感謝します。
[ACTYPE] Housley, R., "The application/pkix-attr-cert Media Type for Attribute Certificates", RFC 5877, May 2010.
[ACTYPE] Housley氏、R.、 "属性証明書の申請/ PKIX-ATTR-CERTメディアタイプ"、RFC 5877、2010年5月。
[ATTRCERT] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[ATTRCERT]ファレル、S.、Housley氏、R.、およびS.ターナー、 "認可のためのインターネット属性証明書プロフィール"、RFC 5755、2010年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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[SAML1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set", September 2003.
[SAML1.1] OASISセキュリティサービス技術委員会、 "のSAML（Security Assertion Markup Language）バージョン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（Security Assertion Markup Language）バージョン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セキュリティサービス技術委員会、2005年3月、 "OASISのSAML（Security Assertion Markup Language）V2.0のバインディング"。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ダークス、T.とC.アレン、 "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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[TLSSUPP] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, October 2006.
[TLSSUPP] Santesson、S.、 "補足データのためのTLSハンドシェイクメッセージ"、RFC 4680、2006年10月。
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[アップグレード] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年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]ホフマン、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]ブレイ、T.、J.パオリ、CM Sperberg-マックイーン、E. MALER、及びF. Yergeau、 "拡張マークアップ言語（XML）1.0（第5版）" は、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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）の拡張"、RFC 3546、2003年6月。
Authors' Addresses
著者のアドレス
Mark Brown RedPhone Security 1199 Falls View Court Mendota Heights, MN 55118 USA EMail: mark@redphonesecurity.com
マーク・ブラウンRedPhoneセキュリティ1199フォールビュー裁判所メンドタハイツ、MN 55118 USA Eメール：mark@redphonesecurity.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA電子メール：housley@vigilsec.com