[要約] RFC 5929 - Channel Bindings for TLSは、Transport Layer Security (TLS) プロトコルにおけるチャネルバインディングの使用に関する標準を定義しています。この文書の目的は、異なるプロトコル層間でセキュリティ特性を安全に結びつける方法を提供することにあります。これにより、アプリケーションはTLSセッションの特定のセキュリティ特性を確認し、それを基に安全な認証やその他のセキュリティ決定を行うことができます。利用場面としては、例えば、クライアントがサーバーに対して認証を行う際に、そのセッションが特定のTLS接続に基づいていることを確認する場合などがあります。関連するRFCにはRFC 5246 (TLS 1.2の定義) やRFC 5746 (TLSの再交渉問題に対処するための拡張) などがあります。
Internet Engineering Task Force (IETF) J. Altman
Request for Comments: 5929 Secure Endpoints
Category: Standards Track N. Williams
ISSN: 2070-1721 Oracle
L. Zhu
Microsoft Corporation
July 2010
Channel Bindings for TLS
TLS用のチャネルバインディング
Abstract
概要
This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).
このドキュメントでは、RFC 5056に従って、トランスポートレイヤーセキュリティ（TLS）、TLS-Unique、TLS-Server-end-Point、およびTLS-Unique-for-Telnetの3つのチャネル結合タイプを定義します（チャネルバインディングについて）。
Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry.
実装エクスペリエンスに基づいて、このドキュメントは、チャネルバインディングタイプIANAレジストリの「TLS-Unique」チャネル結合タイプの元の定義を変更することに注意してください。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5929.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5929で取得できます。
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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. The 'tls-unique' Channel Binding Type ...........................3
3.1. Description ................................................3
3.2. Registration ...............................................4
4. The 'tls-server-end-point' Channel Binding Type .................5
4.1. Description ................................................5
4.2. Registration ...............................................6
5. The 'tls-unique-for-telnet' Channel Binding Type ................6
5.1. Description ................................................7
5.2. Registration ...............................................7
6. Applicability of TLS Channel Binding Types ......................7
7. Required Application Programming Interfaces ....................10
8. Description of Backwards-Incompatible Changes Made
Herein to 'tls-unique' .........................................10
9. IANA Considerations ............................................11
10. Security Considerations .......................................11
10.1. Cryptographic Algorithm Agility ..........................12
10.2. On Disclosure of Channel Bindings Data by
Authentication Mechanisms ................................12
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................14
Subsequent to the publication of "On Channel Bindings" [RFC5056], three channel binding types for Transport Layer Security (TLS) were proposed, reviewed, and added to the IANA channel binding type registry, all in accordance with [RFC5056]. Those channel binding types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for-telnet'. It has become desirable to have these channel binding types re-registered through an RFC so as to make it easier to reference them, and to correct them to describe actual implementations. This document does just that. The authors of those three channel binding types have transferred, or have indicated that they will transfer, "ownership" of those channel binding types to the IESG.
「On Channel Bindings」[RFC5056]の公開に続いて、輸送層セキュリティ（TLS）の3つのチャネル結合タイプが提案、レビュー、およびIANAチャネル結合タイプレジストリにすべて[RFC5056]に従って追加されました。これらのチャネルバインディングタイプは、「TLS-Unique」、「TLS-Server-End-Point」、および「TLS-Unique-for-telnet」です。これらのチャネル結合タイプをRFCを介して再登録して、それらを参照しやすくし、実際の実装を説明するために修正することが望ましいようになりました。このドキュメントはまさにそれを行います。これらの3つのチャネル結合タイプの著者は、それらのチャネル結合タイプの「所有権」をIESGに転送することを転送するか、示唆しています。
We also provide some advice on the applicability of these channel binding types, as well as advice on when to use which. Additionally, we provide an abstract API that TLS implementors should provide, by which to obtain channel bindings data for a TLS connection.
また、これらのチャネルバインディングタイプの適用性に関するアドバイスと、いつ使用するかについてのアドバイスも提供します。さらに、TLS実装者が提供する抽象的なAPIを提供し、それによってTLS接続のチャネルバインディングデータを取得します。
WARNING: it turns out that the first implementor implemented and deployed something rather different than what was described in the IANA registration for 'tls-unique'. Subsequently, it was decided that we should adopt that form of 'tls-unique'. This means that this document makes a backwards-incompatible change to 'tls-unique'. See Section 8 for more details.
警告：最初の実装者は、「TLS-Unique」のIANA登録で説明されているものとはかなり異なるものを実装および展開したことがわかりました。その後、その形式の「TLS-Unique」を採用することが決定されました。これは、このドキュメントが「TLS-Unique」に逆方向に不可能な変更を加えることを意味します。詳細については、セクション8を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
IANA updated the registration of the 'tls-unique' channel binding type to match the description below. There are material and substantial changes from the original registration, both in the description as well as registration meta-data (such as registration ownership).
IANAは、以下の説明に一致するように、「TLS-Unique」チャネルバインディングタイプの登録を更新しました。説明と登録メタデータ（登録所有など）の両方に、元の登録からの重要な変更があります。
Description: The first TLS Finished message sent (note: the Finished struct, not the TLS record layer message containing it) in the most recent TLS handshake of the TLS connection being bound to (note: TLS connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). If TLS renegotiation takes place before the channel binding operation, then the first TLS Finished message sent of the latest/ inner-most TLS connection is used. Note that for full TLS handshakes, the first Finished message is sent by the client, while for abbreviated TLS handshakes (session resumption), the first Finished message is sent by the server.
説明：送信された最初のTLS完成したメッセージ（注：完成したstruct、TLSレコードレイヤーメッセージを含むTLSレイヤーメッセージではなく、完成した構造）が最新のTLS接続のハンドシェイク（注：TLS接続ではなく、セッションではなく、チャネルがチャネルがバインディングは、セッション再開が使用されるかどうかに関係なく、各接続に固有です）。チャネル結合操作の前にTLS再交渉が行われる場合、最新/内部TLS接続の送信された最初のTLS完成メッセージが使用されます。完全なTLSハンドシェイクのために、最初の完成したメッセージはクライアントによって送信されますが、TLSハンドシェイクの短縮（セッション再開）の場合、最初の完成したメッセージはサーバーによって送信されます。
WARNING: The definition, security, and interoperability considerations of this channel binding type have changed since the original registration. Implementors should read the document that last updated this registration for more information.
警告：このチャネル結合タイプの定義、セキュリティ、および相互運用性の考慮事項は、元の登録以来変更されました。実装者は、詳細についてこの登録を最後に更新したドキュメントを読む必要があります。
Interoperability note:
相互運用性注：
This definition of 'tls-unique' means that a channel's bindings data may change over time, which in turn creates a synchronization problem should the channel's bindings data change between the time that the client initiates authentication with channel binding and the time that the server begins to process the client's first authentication message. If that happens, the authentication attempt will fail spuriously.
「TLS-Unique」のこの定義は、チャネルのバインディングデータが時間の経過とともに変化する可能性があることを意味します。これにより、チャネルのバインディングデータがチャネルバインディングで認証を開始する時間とサーバーが開始されるまでの間にチャネルのバインディングデータが変化した場合に、同期問題が生じることを意味します。クライアントの最初の認証メッセージを処理します。それが起こった場合、認証試行は微妙に失敗します。
Based on the fact that while servers may request TLS renegotiation, only clients may initiate it, this synchronization problem can be avoided by clients and servers as follows: server applications MUST NOT request TLS renegotiation during phases of the application protocol during which application-layer authentication occurs. Client applications SHOULD NOT initiate TLS renegotiation between the start and completion of authentication.
サーバーはTLS再交渉を要求する可能性があるが、クライアントのみがそれを開始できるという事実に基づいて、この同期問題はクライアントとサーバーによって次のように回避できます。発生します。クライアントアプリケーションは、認証の開始と完了の間にTLS再交渉を開始する必要はありません。
The rationale for making the server behavior a requirement while the client behavior is only a recommendation is that there typically exist TLS APIs for requesting renegotiation on the server side of a TLS connection, while many client TLS stacks do not provide fine-grained control over when TLS renegotiation occurs.
サーバーの動作を要件にするための理論的根拠は、クライアントの動作が推奨ですが、通常、TLS接続のサーバー側に再交渉を要求するためにTLS APIが存在することですが、多くのクライアントTLSスタックは、いつ微調整された制御を提供しません。TLS再交渉が発生します。
Application protocols SHOULD be designed in such a way that a server would never need to request TLS renegotiation immediately before or during application-layer authentication.
アプリケーションプロトコルは、サーバーがアプリケーション層認証の直前または直前にTLS再交渉を要求する必要がないように設計する必要があります。
o Channel binding unique prefix: tls-unique
o チャネルバインドユニークなプレフィックス：TLS-Unique
o Channel binding type: unique
o チャネルバインディングタイプ：ユニーク
o Channel type: TLS [RFC5246] o Published specification: <RFC 5929>
o チャネルタイプ：TLS [RFC5246] o公開された仕様：<RFC 5929>
o Channel binding is secret: no
o チャネルバインディングは秘密です：いいえ
o Description: <See specification>
o 説明：<仕様>を参照してください
o Intended usage: COMMON
o 意図された使用法：共通
o Person and email address to contact for further information: Larry Zhu (larry.zhu@microsoft.com), Nicolas Williams (Nicolas.Williams@oracle.com).
o 詳細については、個人とメールアドレスをお問い合わせください：Larry Zhu（larry.zhu@microsoft.com）、nicolas Williams（nicolas.williams@oracle.com）。
o Owner/Change controller name and email address: IESG.
o 所有者/変更コントローラー名とメールアドレス：IESG。
o Expert reviewer name and contact information: IETF TLS WG (tls@ietf.org, failing that, ietf@ietf.org)
o エキスパートレビュー担当者の名前と連絡先情報：ietf TLS WG（tls@ietf.org、fails faile、ietf@ietf.org）
o Note: see the published specification for advice on the applicability of this channel binding type.
o 注：このチャネルバインディングタイプの適用性に関するアドバイスについては、公開された仕様を参照してください。
IANA updated the registration of the 'tls-server-end-point' channel binding type to match the description below. Note that the only material changes from the original registration are: the "owner" (now the IESG), the contacts, the published specification, and a note indicating that the published specification should be consulted for applicability advice. References were added to the description. All other fields of the registration are copied here for the convenience of readers.
IANAは、以下の説明に一致するように、「TLS-Server-End-Point」チャネルバインディングタイプの登録を更新しました。元の登録からの唯一の資料の変更は、「所有者」（現在のIESG）、連絡先、公開された仕様、および公開された仕様を適用可能性アドバイスのために参照する必要があることを示すメモです。参照が説明に追加されました。登録の他のすべてのフィールドは、読者の利便性のためにここにコピーされます。
Description: The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message. Note that the Certificate message contains a certificate_list, in which the first element is the server's certificate.
説明：TLSサーバーの証明書[RFC5280]のハッシュが表示されるように、OctetのOctet、サーバーの証明書メッセージ。証明書メッセージには、最初の要素がサーバーの証明書であることが証明書_LISTが含まれていることに注意してください。
The hash function is to be selected as follows:
ハッシュ関数は次のように選択されます。
o if the certificate's signatureAlgorithm uses a single hash function, and that hash function is either MD5 [RFC1321] or SHA-1 [RFC3174], then use SHA-256 [FIPS-180-3];
o 証明書のSignatureAlgorithmが単一のハッシュ関数を使用し、そのハッシュ関数がMD5 [RFC1321]またはSHA-1 [RFC3174]のいずれかである場合、SHA-256 [FIPS-180-3]を使用します。
o if the certificate's signatureAlgorithm uses a single hash function and that hash function neither MD5 nor SHA-1, then use the hash function associated with the certificate's signatureAlgorithm;
o 証明書のSignatureAlgorithmが単一のハッシュ関数を使用し、Hash関数をMD5もSHA-1も使用しない場合、証明書のSignatureAlgorithmに関連付けられたハッシュ関数を使用します。
o if the certificate's signatureAlgorithm uses no hash functions or uses multiple hash functions, then this channel binding type's channel bindings are undefined at this time (updates to is channel binding type may occur to address this issue if it ever arises).
o 証明書のSignatureAlgorithmがハッシュ関数を使用しないか、複数のハッシュ関数を使用している場合、このチャネルバインディングタイプのチャネルバインディングは現時点では未定義です（ISチャネルバインディングタイプの更新は、発生した場合にこの問題に対処するために発生する可能性があります）。
The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium.
証明書のハッシュを使用する理由は、いくつかの実装が、多くの場合プレミアムにあるカーネルモードメモリのTLSセッションのチャネル結合を追跡する必要があるためです。
o Channel binding unique prefix: tls-server-end-point
o チャネルバインディングユニークなプレフィックス：TLS-Server-End-Point
o Channel binding type: end-point
o チャネルバインディングタイプ：エンドポイント
o Channel type: TLS [RFC5246]
o チャネルタイプ：TLS [RFC5246]
o Published specification: <RFC 5929>
o 公開された仕様：<RFC 5929>
o Channel binding is secret: no
o チャネルバインディングは秘密です：いいえ
o Description: <See specification>
o 説明：<仕様>を参照してください
o Intended usage: COMMON
o 意図された使用法：共通
o Person and email address to contact for further information: Larry Zhu (larry.zhu@microsoft.com), Nicolas Williams (Nicolas.Williams@oracle.com).
o 詳細については、個人とメールアドレスをお問い合わせください：Larry Zhu（larry.zhu@microsoft.com）、nicolas Williams（nicolas.williams@oracle.com）。
o Owner/Change controller name and email address: IESG.
o 所有者/変更コントローラー名とメールアドレス：IESG。
o Expert reviewer name and contact information: IETF TLS WG (tls@ietf.org, failing that, ietf@ietf.org)
o エキスパートレビュー担当者の名前と連絡先情報：ietf TLS WG（tls@ietf.org、fails faile、ietf@ietf.org）
o Note: see the published specification for advice on the applicability of this channel binding type.
o 注：このチャネルバインディングタイプの適用性に関するアドバイスについては、公開された仕様を参照してください。
IANA updated the registration of the 'tls-unique-for-telnet' channel binding type to match the description below. Note that the only material changes from the original registration are: the "owner" (now the IESG), the contacts, the published specification, and a note indicating that the published specification should be consulted for applicability advice. The description is also clarified. We also moved the security considerations notes to the security considerations section of this document. All other fields of the registration are copied here for the convenience of readers.
IANAは、以下の説明に一致するように、「TLS-Unique-For-TelNet」チャネルバインディングタイプの登録を更新しました。元の登録からの唯一の資料の変更は、「所有者」（現在のIESG）、連絡先、公開された仕様、および公開された仕様を適用可能性アドバイスのために参照する必要があることを示すメモです。説明も明確にされています。また、このドキュメントのセキュリティ上の考慮事項セクションにセキュリティ上の考慮事項メモを移動しました。登録の他のすべてのフィールドは、読者の利便性のためにここにコピーされます。
Description: There is a proposal for adding a "StartTLS" extension to TELNET, and a channel binding extension for the various TELNET AUTH mechanisms whereby each side sends the other a "checksum" (MAC -- message authentication code) of their view of the channel's bindings. The client uses the TLS Finished messages (note: the Finished struct) sent by the client and server, each concatenated in that order and in their clear text form, of the first TLS handshake to which the connection is being bound. The server does the same but in the opposite concatenation order (server, then client).
説明：Telnetに「startTls」拡張機能を追加する提案と、さまざまなTelnet AUTHメカニズムのチャネル結合拡張機能があり、それにより、各側が他の側に、そのビューの「チェックサム」（MAC-メッセージ認証コード）を送信します。チャンネルのバインディング。クライアントは、クライアントとサーバーによって送信されたTLS完成メッセージ（注：完成した構造）を使用します。各サーバーは、接続がバインドされている最初のTLSハンドシェイクのその順序と明確なテキスト形式で連結されます。サーバーは同じですが、反対の連結順序（サーバー、クライアント）で行います。
o Channel binding unique prefix: tls-unique-for-telnet
o チャネルバインディングユニークなプレフィックス：TLS-Unique-for-telnet
o Channel binding type: unique
o チャネルバインディングタイプ：ユニーク
o Channel type: TLS [RFC5246]
o チャネルタイプ：TLS [RFC5246]
o Published specification: <RFC 5929>
o 公開された仕様：<RFC 5929>
o Channel binding is secret: no
o チャネルバインディングは秘密です：いいえ
o Description: <See specification>
o 説明：<仕様>を参照してください
o Intended usage: COMMON
o 意図された使用法：共通
o Person and email address to contact for further information: Jeff Altman (jaltman@secure-endpoints.com), Nicolas Williams (Nicolas.Williams@oracle.com).
o 詳細については、個人とメールアドレスをお問い合わせください：jeff altman（jaltman@secure-endpoints.com）、nicolas Williams（nicolas.williams@oracle.com）。
o Owner/Change controller name and email address: IESG.
o 所有者/変更コントローラー名とメールアドレス：IESG。
o Expert reviewer name and contact information: IETF TLS WG (tls@ietf.org, failing that, ietf@ietf.org)
o エキスパートレビュー担当者の名前と連絡先情報：ietf TLS WG（tls@ietf.org、fails faile、ietf@ietf.org）
o Note: see the published specification for advice on the applicability of this channel binding type.
o 注：このチャネルバインディングタイプの適用性に関するアドバイスについては、公開された仕様を参照してください。
The 'tls-unique-for-telnet' channel binding type is only applicable to TELNET [RFC0854] and is available for all TLS connections.
「TLS-UNIQUE-FOR-TELNET」チャネルバインディングタイプは、Telnet [RFC0854]にのみ適用され、すべてのTLS接続に使用できます。
The 'tls-unique' channel binding type is available for all TLS connections, while 'tls-server-end-point' is only available when TLS cipher suites with server certificates are used, specifically: cipher suites that use the Certificate handshake message, which typically involve the use of PKIX [RFC5280]. For example, 'tls-server-end-point' is available when using TLS ciphers suites such as (this is not an exhaustive list):
「TLS-Unique」チャネルバインディングタイプはすべてのTLS接続で使用できますが、「TLS-Server-end-Point」は、サーバー証明書を備えたTLS暗号スイートが使用される場合にのみ使用できます。通常、PKIX [RFC5280]の使用が含まれます。たとえば、「TLS-Server-end-Point」は、（これは網羅的なリストではない）などのTLS暗号スイートを使用する場合に使用できます。
o TLS_DHE_DSS_WITH_*
o tls_dhe_dss_with_*
o TLS_DHE_RSA_WITH_*
o tls_dhe_rsa_with_*
o TLS_DH_DSS_WITH_*
o tls_dh_dss_with_*
o TLS_DH_RSA_WITH_*
o tls_dh_rsa_with_*
o TLS_ECDHE_ECDSA_WITH_*
o tls_ecdhe_ecdsa_with_*
o TLS_ECDHE_RSA_WITH_*
o tls_ecdhe_rsa_with_*
o TLS_ECDH_ECDSA_WITH_*
o tls_ecdh_ecdsa_with_*
o TLS_ECDH_RSA_WITH_*
o tls_ecdh_rsa_with_*
o TLS_RSA_PSK_WITH_*
o tls_rsa_psk_with_*
o TLS_RSA_WITH_*
o tls_rsa_with_*
o TLS_SRP_SHA_DSS_WITH_*
o tls_srp_sha_dss_with_*
o TLS_SRP_SHA_RSA_WITH_*
o tls_srp_sha_rsa_with_*
but is not available when using TLS cipher suites such as (this is not an exhaustive list):
ただし、TLS暗号スイートを使用する場合は利用できません（これは網羅的なリストではありません）：
o TLS_DHE_PSK_WITH_*
o tls_dhe_psk_with_*
o TLS_DH_anon_WITH_*
o tls_dh_anon_with_*
o TLS_ECDHE_PSK_WITH_*
o tls_ecdhe_psk_with_*
o TLS_ECDH_anon_WITH_*
o tls_ecdh_anon_with_*
o TLS_KRB5_WITH_*
o tls_krb5_with_*
o TLS_PSK_WITH_*
o tls_psk_with_*
o TLS_SRP_SHA_WITH_*
o tls_srp_sha_with_*
'tls-server-end-point' is also not applicable for use with OpenPGP server certificates [RFC5081] [RFC4880] (since these don't use the Certificate handshake message).
「TLS-Server-end-Point」は、OpenPGPサーバー証明書[RFC5081] [RFC4880]での使用にも適用できません（これらは証明書ハンドシェイクメッセージを使用していないため）。
Therefore, 'tls-unique' is applicable to more contexts than 'tls-server-end-point'. However, 'tls-server-end-point' may be used with existing TLS server-side proxies ("concentrators") without modification to the proxies, whereas 'tls-unique' may require firmware or software updates to server-side proxies. Therefore there may be cases where 'tls-server-end-point' may interoperate but where 'tls-unique' may not.
したがって、「TLS-Unique」は、「TLS-Server-end-Point」よりも多くのコンテキストに適用できます。ただし、「TLS-Server-end-Point」は、プロキシを変更せずに既存のTLSサーバーサイドプロキシ（ "Concentorators"）で使用できますが、「TLS-Unique」では、サーバー側のプロキシにファームウェアまたはソフトウェアの更新が必要になる場合があります。したがって、「tls-server-end-point」が相互運用する場合がありますが、「tls-unique」が相互運用する場合があります。
Also, authentication mechanisms may arise that depend on channel bindings to contribute entropy, in which case unique channel bindings would always have to be used in preference to end-point channel bindings. At this time there are no such mechanisms, though one such SASL mechanism has been proposed. Whether such mechanisms should be allowed is out of scope for this document.
また、エントロピーに寄与するチャネルバインディングに依存する認証メカニズムが発生する場合があります。その場合、ユニークなチャネルバインディングは、エンドポイントチャネルバインディングよりも常に使用する必要があります。現時点では、そのようなメカニズムはありませんが、そのようなSASLメカニズムが提案されています。このようなメカニズムを許可すべきかどうかは、このドキュメントの範囲外です。
For many applications, there may be two or more potentially applicable TLS channel binding types. Existing security frameworks (such as the GSS-API [RFC2743] or the SASL [RFC4422] GS2 framework [RFC5801]) and security mechanisms generally do not support negotiation of channel binding types. Therefore, application peers need to agree a priori as to what channel binding type to use (or agree to rules for deciding what channel binding type to use).
多くのアプリケーションでは、2つ以上の潜在的に適用可能なTLSチャネルバインディングタイプがある場合があります。既存のセキュリティフレームワーク（GSS-API [RFC2743]やSASL [RFC4422] GS2フレームワーク[RFC5801]など）およびセキュリティメカニズムは、一般にチャネル結合タイプの交渉をサポートしていません。したがって、アプリケーションのピアは、使用するチャネルバインディングタイプについてのアプリオリに同意する必要があります（または、使用するチャネルバインディングタイプを決定するためのルールに同意する）。
The specifics of whether and how to negotiate channel binding types are beyond the scope of this document. However, it is RECOMMENDED that application protocols making use of TLS channel bindings, use 'tls-unique' exclusively, except, perhaps, where server-side proxies are common in deployments of an application protocol. In the latter case an application protocol MAY specify that 'tls-server-end-point' channel bindings must be used when available, with 'tls-unique' being used when 'tls-server-end-point' channel bindings are not available. Alternatively, the application may negotiate which channel binding type to use, or may make the choice of channel binding type configurable.
チャネルバインディングタイプを交渉するかどうか、どのように交渉するかの詳細は、このドキュメントの範囲を超えています。ただし、TLSチャネルバインディングを使用するアプリケーションプロトコルは、おそらくアプリケーションプロトコルの展開にサーバー側のプロキシが一般的である場合を除き、「TLS-Unique」のみを使用することをお勧めします。後者の場合、アプリケーションプロトコルは、「TLS-Server-End-Point」チャネルバインディングが利用できないときに「TLS-Server-end-Point」チャネルバインディングを使用する必要があることを指定することができます。。あるいは、アプリケーションは、使用するチャネルバインディングタイプを交渉するか、チャネルバインディングタイプの選択を構成可能にする場合があります。
Specifically, application protocol specifications MUST indicate at least one mandatory to implement channel binding type, MAY specify a negotiation protocol, MAY allow for out-of-band negotiation or configuration, and SHOULD have a preference for 'tls-unique' over 'tls-server-end-point'.
具体的には、アプリケーションプロトコルの仕様は、チャネルバインディングタイプを実装するために少なくとも1つの必須を示す必要があり、交渉プロトコルを指定し、帯域外交渉または構成を可能にする場合があり、「TLS-Unique」よりも「TLS-Unique」を優先する必要があります。サーバーエンドポイント '。
TLS implementations supporting the use of 'tls-unique' and/or 'tls-unique-for-telnet' channel binding types MUST provide application programming interfaces by which applications (clients and servers both) may obtain the channel bindings for a TLS connection. Such interfaces may be expressed in terms of extracting the channel bindings data for a given connection and channel binding type. Alternatively, the implementor may provide interfaces by which to obtain the initial client Finished message, the initial server Finished message, and/or the server certificate (in a form that matches the description of the 'tls-server-end-point' channel binding type). In the latter case, the application has to have knowledge of the channel binding type descriptions from this document. This document takes no position on which form these application programming interfaces must take.
「TLS-Unique」および/または「TLS-Unique-For-TelNet」チャネルバインディングタイプの使用をサポートするTLS実装は、アプリケーション（クライアントとサーバーの両方）がTLS接続のチャネルバインディングを取得する可能性があるアプリケーションプログラミングインターフェイスを提供する必要があります。このようなインターフェイスは、特定の接続およびチャネル結合タイプのチャネルバインディングデータを抽出するという点で表される場合があります。あるいは、実装者は、初期クライアントの完成メッセージ、初期サーバー完成メッセージ、および/またはサーバー証明書を取得するためのインターフェイスを提供することができます（「TLS-Server-end-Point」チャネルバインディングの説明に一致する形式でタイプ）。後者の場合、アプリケーションは、このドキュメントからのチャネル結合タイプの説明に関する知識を持たなければなりません。このドキュメントは、これらのアプリケーションプログラミングインターフェイスを取得する必要がある形式の位置を取得しません。
TLS implementations supporting TLS renegotiation SHOULD provide APIs that allow applications to control when renegotiation can take place. For example, a TLS client implementation may provide a "callback" interface to indicate that the server requested renegotiation, but may not start renegotiation until the application calls a function to indicate that now is a good time to renegotiate.
TLSの再交渉をサポートするTLS実装は、アプリケーションが再交渉が行われることを制御できるようにするAPIを提供する必要があります。たとえば、TLSクライアントの実装は、サーバーが再交渉を要求したことを示す「コールバック」インターフェイスを提供する場合がありますが、アプリケーションが関数を呼び出して再交渉する良い時期であることを示すまで再交渉を開始できない場合があります。
8. Description of Backwards-Incompatible Changes Made Herein to 'tls-unique'
8. ここで「TLS-Unique」に行われた逆方向に取得できない変更の説明
The original description of 'tls-unique' read as follows:
「TLS-Unique」の元の説明は、次のように読みます。
|OLD| Description: The client's TLS Finished message (note: the
|OLD| Finished struct) from the first handshake of the connection
|OLD| (note: connection, not session, so that the channel binding
|OLD| is specific to each connection regardless of whether session
|OLD| resumption is used).
Original 'tls-unique' description
オリジナルの「TLS-Unique」の説明
In other words: the client's Finished message from the first handshake of a connection, regardless of whether that handshake was a full or abbreviated handshake, and regardless of how many subsequent handshakes (renegotiations) might have followed.
言い換えれば、クライアントの接続の最初の握手からの完成したメッセージは、その握手が完全な握手であるか略された握手であるかに関係なく、そしてその後の握手（再交渉）がどれだけ続いたかに関係なく。
As explained in Section 1, this is no longer the description of 'tls-unique', and the new description is not backwards compatible with the original except in the case of TLS connections where: a) only one handshake has taken place before application-layer authentication, and b) that one handshake was a full handshake.
セクション1で説明したように、これは「TLS-Unique」の説明ではなくなり、新しい説明は、次のTLS接続の場合を除き、オリジナルとの逆方向に互換性がありません。認証を重ね、b）その片手が完全な握手であったこと。
This change has a number of implications:
この変更には多くの意味があります。
o Backwards-incompatibility. It is possible that some implementations of the original 'tls-unique' channel binding type have been deployed. We know of at least one TLS implementation that exports 'tls-unique' channel bindings with the original semantics, but we know of no deployed application using the same. Implementations of the original and new 'tls-unique' channel binding type will only interoperate when: a) full TLS handshakes are used, and b) TLS renegotiation is not used.
o 後方の不可分性。元の「TLS-Unique」チャネルバインディングタイプのいくつかの実装が展開されている可能性があります。「TLS-Unique」チャネルバインディングを元のセマンティクスでエクスポートする少なくとも1つのTLS実装を知っていますが、同じものを使用して展開されたアプリケーションはないことを知っています。元の「TLS-Unique」チャネルバインディングタイプの実装は、次の場合にのみ相互運用します。a）完全なTLSハンドシェイクが使用され、b）TLS再交渉は使用されません。
o Security considerations -- see Section 10.
o セキュリティ上の考慮事項 - セクション10を参照してください。
o Interoperability considerations. As described in Section 3, the new definition of the 'tls-unique' channel binding type has an interoperability problem that may result in spurious authentication failures unless the application implements one or both of the techniques described in that section.
o 相互運用性の考慮事項。セクション3で説明したように、「TLS-Unique」チャネル結合タイプの新しい定義には、アプリケーションがそのセクションで説明されている手法の1つまたは両方を実装しない限り、偽の認証障害をもたらす可能性のある相互運用性の問題があります。
IANA updated three existing channel binding type registrations. See the rest of this document.
IANAは、3つの既存のチャネルバインディングタイプ登録を更新しました。このドキュメントの残りを参照してください。
The Security Considerations sections of [RFC5056], [RFC5246], and [RFC5746] apply to this document.
[RFC5056]、[RFC5246]、および[RFC5746]のセキュリティに関する考慮事項セクションは、このドキュメントに適用されます。
The TLS Finished messages (see Section 7.4.9 of [RFC5246]) are known to both endpoints of a TLS connection and are cryptographically bound to it. For implementations of TLS that correctly handle renegotiation [RFC5746], each handshake on a TLS connection is bound to the preceding handshake, if any. Therefore, the TLS Finished messages can be safely used as a channel binding provided that the authentication mechanism doing the channel binding conforms to the requirements in [RFC5056]. Applications utilizing 'tls-unique' channel binding with TLS implementations without support for secure renegotiation [RFC5746] MUST ensure that ChangeCipherSpec has been used in any and all renegotiations prior to application-layer authentication, and MUST discard any knowledge learned from the server prior to the completion of application-layer authentication.
TLS完成したメッセージ（[RFC5246]のセクション7.4.9を参照）は、TLS接続の両方のエンドポイントに対して知られており、暗号化されています。再交渉[RFC5746]を正しく処理するTLSの実装の場合、TLS接続の各握手は、もしあれば前の握手に結合します。したがって、チャネルバインディングを行う認証メカニズムが[RFC5056]の要件に適合すると、TLS完成したメッセージはチャネル結合として安全に使用できます。「TLS-Unique」チャネルバインディングを使用して、安全な再交渉をサポートせずにTLS実装でバインドするアプリケーション[RFC5746]は、アプリケーションレイヤー認証の前にすべての再交渉でChangeciphersPecが使用されていることを保証する必要があり、前に学んだ知識をサーバーから学んだ知識を廃棄する必要があります。アプリケーション層認証の完了。
The server certificate, when present, is also cryptographically bound to the TLS connection through its use in key transport and/or authentication of the server (either by dint of its use in key transport, by its use in signing key agreement, or by its use in key agreement). Therefore, the server certificate is suitable as an end-point channel binding as described in [RFC5056].
サーバー証明書は、存在する場合、サーバーの主要なトランスポートおよび/または認証での使用を通じてTLS接続に暗号化されています（キートランスポートでの使用、キー契約の署名での使用、またはその使用による、またはその使用により、またはその使用により、主要な合意で使用）。したがって、[RFC5056]で説明されているように、サーバー証明書はエンドポイントチャネル結合として適しています。
The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do not add any use of cryptography beyond that used by TLS itself. Therefore, these two channel binding types add no considerations with respect to cryptographic algorithm agility.
「TLS-Unique」および「TLS-Unique-For-Telnet」チャネルバインディングタイプは、TLS自体が使用するものを超えて暗号化の使用を追加しません。したがって、これらの2つのチャネル結合タイプは、暗号化アルゴリズムの俊敏性に関して考慮事項を追加しません。
The 'tls-server-end-point' channel binding type consists of a hash of a server certificate. The reason for this is to produce manageably small channel binding data, as some implementations will be using kernel-mode memory (which is typically scarce) to store these. This use of a hash algorithm is above and beyond TLS's use of cryptography, therefore the 'tls-server-end-point' channel binding type has a security consideration with respect to hash algorithm agility. The algorithm to be used, however, is derived from the server certificate's signature algorithm as described in Section 4.1; to recap: use SHA-256 if the certificate signature algorithm uses MD5 or SHA-1, else use whatever hash function the certificate uses (unless the signature algorithm uses no hash functions or more than one hash function, in which case 'tls-server-end-point' is undefined). The construction of 'tls-server-end-point' channel bindings is not directly hash-agile (since no negotiation of hash function is provided for), but it is hash-agile nonetheless. The hash agility of 'tls-server-end-point' channel bindings derives from PKIX and TLS.
「TLS-Server-end-Point」チャネルバインディングタイプは、サーバー証明書のハッシュで構成されています。この理由は、いくつかの実装がカーネルモードメモリ（通常は不足している）を使用してこれらを保存するため、管理的に小さなチャネル結合データを作成するためです。ハッシュアルゴリズムのこの使用は、TLSの暗号化の使用を超えているため、「TLS-Server-end-Point」チャネル結合タイプには、ハッシュアルゴリズムの俊敏性に関してセキュリティが考慮されます。ただし、使用するアルゴリズムは、セクション4.1で説明されているサーバー証明書の署名アルゴリズムから導出されます。要約するには、SHA-256を使用して証明書署名アルゴリズムがMD5またはSHA-1を使用している場合、証明書が使用するハッシュ関数を使用します（署名アルゴリズムがハッシュ関数または1つ以上のハッシュ関数を使用しない限り、この場合は 'tls-server-End-Point 'は未定義です）。「TLS-Server-end-Point」チャネルバインディングの構築は、直接ハッシュアジャイルではありません（ハッシュ関数の交渉は提供されていないため）が、それでもハッシュアジャイルです。「TLS-Server-end-Point」チャネルバインディングのハッシュ俊敏性は、PKIXおよびTLSに由来します。
Current proposals for randomized signatures algorithms [RHASH] [NIST-SP.800-106.2009] use hash functions in their construction -- a single hash function in each algorithm. Therefore, the 'tls-server-end-point' channel binding type should be available even in cases where new signatures algorithms are used that are based on current randomized hashing proposals (but we cannot guarantee this, of course).
ランダム化署名アルゴリズムの現在の提案[Rhash] [NIST-SP.800-106.2009]は、構造にハッシュ関数を使用します。各アルゴリズムの単一のハッシュ関数です。したがって、現在のランダム化ハッシュ提案に基づいた新しい署名アルゴリズムが使用されている場合でも、「TLSサーバーエンドポイント」チャネルバインディングタイプが利用可能である必要があります（ただし、もちろんこれを保証することはできません）。
When these channel binding types were first considered, one issue that some commenters were concerned about was the possible impact on the security of the TLS channel, of disclosure of the channel bindings data by authentication mechanisms. This can happen, for example, when an authentication mechanism transports the channel bindings data, with no confidentiality protection, over other transports (for example, in communicating with a trusted third party), or when the TLS channel provides no confidentiality protection and the authentication mechanism does not protect the confidentiality of the channel bindings data. This section considers that concern.
これらのチャネル結合タイプが最初に考慮されたとき、一部のコメンターが懸念していた問題の1つは、認証メカニズムによるチャネルバインディングデータの開示のTLSチャネルのセキュリティに影響を与える可能性がありました。これは、たとえば、認証メカニズムが機密性保護なしでチャネルバインディングデータを他のトランスポート（たとえば、信頼できるサードパーティとの通信）に輸送する場合、またはTLSチャネルが機密保護と認証を提供しない場合に発生する可能性があります。メカニズムは、チャネルバインディングデータの機密性を保護しません。このセクションでは、その懸念を検討します。
When the TLS connection uses a cipher suite that does not provide confidentiality protection, the TLS Finished messages will be visible to eavesdroppers, regardless of what the authentication mechanism does. The same is true of the server certificate which, in any case, is generally visible to eavesdroppers. Therefore we must consider our choices of TLS channel bindings here to be safe to disclose by definition -- if that were not the case, then TLS with cipher suites that don't provide confidentiality protection would be unsafe. Furthermore, the TLS Finished message construction depends on the security of the TLS PRF, which in turn needs to be resistant to key recovery attacks, and we think that it is, as it is based on HMAC, and the master secret is, well, secret (and the result of key exchange).
TLS接続が機密保護を提供しない暗号スイートを使用すると、認証メカニズムが何をするかに関係なく、TLS完成メッセージが盗聴者に表示されます。同じことが、いずれにせよ、一般に盗聴者に見えるサーバー証明書にも当てはまります。したがって、ここでTLSチャネルバインディングの選択は、定義上開示するのが安全であることを考慮する必要があります。そうでない場合は、機密保護を提供しない暗号スイートを使用してTLSは安全ではありません。さらに、TLS完成したメッセージの構築は、TLS PRFのセキュリティに依存します。これは、重要な回復攻撃に耐性がある必要があり、HMACに基づいていると考えています。秘密（およびキー交換の結果）。
Note too that in the case of an attempted active man-in-the-middle attack, the attacker will already possess knowledge of the TLS Finished messages for both inbound and outbound TLS channels (which will differ, given that the attacker cannot force them to be the same). No additional information is obtained by the attacker from the authentication mechanism's disclosure of channel bindings data -- the attacker already has it, even when cipher suites providing confidentiality protection are provided.
また、中間攻撃の試みが試みられた場合、攻撃者は、インバウンドチャネルとアウトバウンドTLSチャネルの両方のTLS完成メッセージの知識をすでに持っていることに注意してください（攻撃者が強制することができないため、これは異なります。同じである）。攻撃者は、チャネルバインディングデータの認証メカニズムの開示からの追加情報は得られません。攻撃者は、機密性保護を提供する暗号スイートが提供されている場合でも、すでにそれを持っています。
None of the channel binding types defined herein produce channel bindings data that must be kept secret. Moreover, none of the channel binding types defined herein can be expected to be private (known only to the end-points of the channel), except that the unique TLS channel binding types can be expected to be private when a cipher suite that provides confidentiality protection is used to protect the Finished message exchanges and the application data records containing application-layer authentication messages.
本明細書で定義されているチャネルバインディングタイプはいずれも、秘密にしなければならないチャネルバインディングデータを生成しません。さらに、本明細書で定義されているチャネルバインディングタイプはいずれもプライベートであるとは予想されません（チャネルのエンドポイントにのみ知られています）。保護は、完成したメッセージ交換と、アプリケーション層認証メッセージを含むアプリケーションデータレコードを保護するために使用されます。
[FIPS-180-3] United States of America, National Institute of Standards and Technology, "Secure Hash Standard", Federal Information Processing Standard (FIPS) 180-3, October 2008.
[FIPS-180-3]アメリカ合衆国、国立標準技術研究所、「Secure Hash Standard」、連邦情報処理標準（FIPS）180-3、2008年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズ、N。、「チャンネルを保護するためのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「輸送層のセキュリティ（TLS）再交渉表示拡張」、RFC 5746、2010年2月。
[NIST-SP.800-106.2009] National Institute of Standards and Technology, "NIST Special Publication 800- 106: Randomized Hashing for Digital Signatures", February 2009.
[NIST-SP.800-106.2009]国立標準技術研究所、「NIST Special Publication 800-106：デジタル署名用のランダム化ハッシュ」、2009年2月。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A.、ed。、およびK. Zeilenga、ed。、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 4880、2007年11月。
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 5081, November 2007.
[RFC5081] MavrogianNopoulos、N。、「輸送層セキュリティ（TLS）認証にOpenPGPキーを使用」、RFC 5081、2007年11月。
[RFC5280] 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.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5801] Josefsson、S。およびN. Williams、「一般的な認証およびセキュリティ層（SASL）のジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）メカニズム：GS2メカニズムファミリー」、RFC 5801、2010年7月。
[RHASH] Halevi, S. and H. Krawczyk, "Strengthening Digital Signatures via Randomized Hashing", Work in Progress, October 2007.
[Rhash] Halevi、S。およびH. Krawczyk、「ランダム化されたハッシュによるデジタル署名の強化」、2007年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Jeff Altman Secure Endpoints 255 W 94TH ST PHB New York, NY 10025 US
ジェフ・アルトマンセキュアエンドポイント255 W 94th ST PHBニューヨーク、ニューヨーク10025米国
EMail: jaltman@secure-endpoints.com
Nicolas Williams Oracle 5300 Riata Trace Ct Austin, TX 78727 US
ニコラス・ウィリアムズオラクル5300リアタトレースCTオースティン、テキサス78727米国
EMail: Nicolas.Williams@oracle.com
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu Microsoft Corporation One Microsoft Way Redmond、WA 98052 US
EMail: larry.zhu@microsoft.com