[要約] RFC 5878は、Transport Layer Security (TLS) プロトコルにおける認証拡張に関する文書です。このRFCの目的は、TLSハンドシェイクプロセス中にクライアントとサーバー間で認証情報を交換するためのメカニズムを提供することにあります。これにより、相互認証や特定のアプリケーションにおける権限付与のプロセスが強化されます。利用場面としては、セキュアな通信を必要とするWebサービスや企業内ネットワークなどが挙げられます。関連するRFCとしては、RFC 5246 (TLS 1.2の定義) やRFC 8446 (TLS 1.3の定義) などがあります。
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）のハンドシェイクプロトコルへの承認拡張機能を指定します。拡張機能は、クライアントとサーバーのハローメッセージに携帯されており、両方の当事者が目的の承認データ型をサポートしていることを確認します。次に、クライアントとサーバーの両方でサポートされている場合、属性証明書（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 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拡張機能は、TLS 1.2 [TLS1.2]の一部になりました。TLS拡張機能は、クライアントのhelloメッセージとサーバーの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セッションのコンテキストを知っています。したがって、クライアントは、必要なときに承認拡張機能を使用できます。サーバーがリストされているすべての拡張機能を「理解」しない場合でも、サーバーは拡張クライアントのハローメッセージを受け入れる必要があります。ただし、サーバーは、これらの「理解されていない」拡張機能のサポートを示していません。その後、クライアントは、承認拡張機能をサポートしていないサーバーとの通信を拒否する場合があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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
図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;
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は特定の拡張型タイプを識別し、extension_Dataには特定の拡張型タイプに固有の情報が含まれています。このドキュメントは、2つの新しい拡張機能タイプの使用を指定しています：client_authzとserver_authz。これらの拡張タイプについては、それぞれセクション2.1とセクション2.2で説明します。この仕様は、extensionTypeに2つの新しいタイプを追加します。
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_Dataフィールドは、補足データハンドシェイクメッセージで送信される承認データの形式を示します。client_authz extension_dataフィールドの構文については、セクション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拡張機能を含む拡張クライアントのhelloメッセージを受信するサーバーは、拡張サーバーのextended Serverのextensionで同じclient_authz拡張機能で応答する必要があります。容認できない形式は、クライアントが提供するリストから削除する必要があります。client_authz拡張機能は、サーバーが指定された形式のいずれかで承認データを受け取ることをいとわない場合は、拡張サーバーのhelloメッセージから省略する必要があります。
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_Dataフィールドは、補足データハンドシェイクメッセージで送信される承認データの形式を示します。Server_Authz拡張機能_DATAフィールドの構文については、セクション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メッセージを受信するサーバーは、拡張サーバーのServer_Authz拡張機能で応答する必要があります。サーバーが要求された形式で承認データを提供する場合は、拡張サーバーのHelloメッセージです。容認できない形式は、クライアントが提供するリストから削除する必要があります。Server_Authz拡張機能は、Serverが指定された形式のいずれにおいても認証データを提供できない場合、拡張サーバーHelloメッセージから省略する必要があります。
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>;
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値が存在する場合、認証データはX.509属性証明書（AC）であり、RFC 5755 [AttrCert]のプロファイルに準拠しています。
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値が存在する場合、承認データはX.509 ACであり、RFC 5755 [ATTRCERT]のプロファイルに適合します。ただし、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 MUST deny access if the authorization cannot be obtained from the provided URL, by sending a certificate_unobtainable alert (see Section 4).
X509_ATTR_CERT_URLまたはSAML_ASSERTION_URLをサポートする実装は、HTTPスキーム[HTTP]を使用するURLをサポートする必要があります。これらの実装では、フェッチされた承認で計算されたハッシュ値が、握手で受け取った承認と一致することを確認する必要があります。ハッシュ値の不一致は、承認が提供されていないかのように扱う必要があります。これにより、bad_certificate_hash_valueアラートが生じます（セクション4を参照）。証明書_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拡張機能は、クライアントからサーバーへの転送に受け入れられる承認データ形式を決定し、サーバーからクライアントへの転送に容認できる承認データ形式を決定します。どちらの場合も、[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.
クライアントからサーバーに送信された補足メッセージには、TLSクライアントに関連付けられた認証データが含まれています。最小の特権の原則に従って、クライアントは、手元のタスクを達成するために必要な最小限の許可情報セットを送信する必要があります。つまり、必要なサーバーリソースにアクセスするために、サーバーが必要とすると予想される承認のみを含める必要があります。承認データの形式は、client_authz hello mession拡張子でネゴシエートされた形式に依存します。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.
一部のシステムでは、クライアントがサーバーに認証情報を提示し、サーバーが新しい承認情報を提供します。このタイプのトランザクションは、補足メッセージによってサポートされていません。クライアントがTLSサーバーに承認翻訳または拡張サービスを実行するように要求する場合、そのような翻訳サービスは、TLSハンドシェイクプロトコル内ではなく、ApplicationDataメッセージ内で発生するはずです。
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サーバーに関連付けられた認証データが含まれています。この承認情報には、サーバーの資格、評判、認定などに関する声明が含まれることが期待されています。可能な限り、不正使用のために不正に流用できる承認は避けるべきです。承認データの形式は、server_authz hello message拡張子でネゴシエートされた形式によって異なります。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")
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構造には、クライアントまたはサーバーのいずれかの許可情報が含まれています。Hello Extensionsで使用するためにセクション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.
ハサルゴリズムのタイプは[TLS1.2]から取得されます。これにより、将来的にはIANA TLS Hashalgorithmレジストリに追加の一方向ハッシュ関数を登録できます。
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>;
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;
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];
不透明な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を使用すると、フィールドには、RFC 5755 [attrcert]のプロファイルに続くプロファイルに続くasn.1 distinguishedエンコードルール（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ホルダーフィールドは、このリンクを提供します。ホルダーフィールドは、3つの異なる（オプションの）構文を許可するシーケンスです：basecertificateid、entityName、およびobjectDigestinfo。TLS認証のコンテキストでは、ホルダーフィールドはBasecertificateIDまたはEntityNameのいずれかを使用する必要があります。BasecertificateIDの場合、BasecertificateIDフィールドは、証明書の発行者とSerialNumberフィールドと一致する必要があります。EntityNameの場合、EntityNameは、証明書の件名フィールドまたは証明書のsubjectaltname拡張値のいずれかと同じでなければなりません。[pkix1]は、サブジェクトフィールドに空の識別名が含まれている場合、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, 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を使用する場合、フィールドにはよく形成されたXML [XML1.0]が含まれている必要があり、UTF-8 [UTF-8]またはUTF-16 [UTF-16]文字エンコードのいずれかを使用する必要があります。UTF-8は、好ましい文字エンコードです。XMLテキスト宣言の後に、[SAML1.1]および[SAML2.0]で定義されているAssertionType Complex Typeを使用して、<Assertion>要素が続く必要があります。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アサーションの一意の識別子のキャッシュに対して、Bearer Assertionsはしばしばチェックされます。これは、ベアラーの主張が一度だけ使用することを意図している場合、適切な対策です。セクション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-Encoded X.509 ACまたはSAMLアサーションを取得するためのURLを提供します。意図したオブジェクトが取得されるようにするために、オブジェクトの一方向ハッシュ値も含まれています。この一方向ハッシュ値の整合性は、TLS完成メッセージによって提供されます。
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を避けることは、円形の依存関係を回避する1つの方法です。したがって、HTTP [アップグレード]でアップグレードされた場合、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ハサルゴリズムレジストリに追加できます。
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]で定義されている「Application/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.
このドキュメントは、[TLS1.2]または[TLSEXT2]で信頼できるようにアラートレベルを保存しながら、認証処理中に発生するエラーの公開キー証明書処理に関連する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]のセクション7.2からのアラートメッセージの定義を再現し、[TLSEXT2]で定義された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が提供されることを握手が確立したことを示すこともできますが、補足形式の承認形式は提供されていません。
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 certificated処理で、証明書_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 certificated processingで、証明書_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 certificated processingでは、証明書_unknownは、証明書の処理中に他の（不特定の）問題が発生し、許容できないことを示しています。同様に、承認処理では、cermost_unknownは、authzdataformatの解析エラーを含む他の（不明確な）問題のために承認dataの処理が失敗したことを示しています。
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.
未知の_CA証明書処理では、不明_CAは、有効な認証パスまたは部分認定パスが受信されたことを示していますが、認証機関（CA）証明書を見つけることができないか、既知の信頼できる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証明書処理では、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.
certificate_unobtainable RFC 4366 [TLSEXT2]で定義されているclient_certificate_url拡張機能は、ダウンロードエラーが証明書_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].
このドキュメントでは、2つの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].
このドキュメントでは、1つのTLS補足データタイプを定義します：authz_data（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によって維持される新しいレジストリを確立します。レジストリの最初の4つのエントリは、x509_attr_cert（0）、saml_assertion（1）、x509_attr_cert_url（2）、およびsaml_assertion_url（3）です。包括的範囲0〜63（小数）の値を持つTLS認証データ形式識別子は、RFC 5226 [IANA] IETFレビューを介して割り当てられます。包括的範囲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）は、通信保護がないことを示します。A（1）は、最初のTLSセッションによって保護が提供されることを示します。また、2つのTLSセッションによって保護が提供されることを2つ示します。
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.
Bearer SAMLアサーションの使用により、盗聴者または中間の男がSAMLの主張をキャプチャし、別の文脈でそれを再利用しようとすることができます。セクション3.3.2で説明した制約は、盗聴者に対して効果的である可能性がありますが、中間の男に対して効果的である可能性は低くなります。クライアント認証の使用を伴うTLSセッションでの両当事者の認証は、検出されない中間の男を妨げ、図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アサーション部分を支援してくれたScott Cantorに感謝します。
[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] Farrell、S.、Housley、R。、およびS. Turner、「認証のためのインターネット属性証明書プロファイル」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[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 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）バージョン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 Security Services Technical Committee、「Oasis Security Assertion Markup Language（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、Secure Hash Standard（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、「The Transport Layer Security（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、「The Transport Layer Security（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、「Transport Layer Security（TLS）Extensions」、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. Lawrence、「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] 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（第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] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 3546、2003年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、Mn 55118 USAメール：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、VA 20170 USAメール：housley@vigilsec.com