[要約] RFC 5056は、セキュアなチャネルを確立するためのチャネルバインディングの使用に関するものです。その目的は、クライアントとサーバー間の通信のセキュリティを向上させるために、チャネルバインディングの仕組みを提供することです。
Network Working Group N. Williams
Request for Comments: 5056 Sun
Category: Standards Track November 2007
On the Use of Channel Bindings to Secure Channels
チャネルバインディングの使用については、チャネルを保護します
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.
チャネル結合の概念により、アプリケーションは、1つのネットワークレイヤーでの安全なチャネルの2つのエンドポイントが、上層層の高レイヤーでの認証を結合することにより、より高いレイヤーの場合と同じであることを確立できます。これにより、アプリケーションはセッション保護を委任して、さまざまなパフォーマンスの利点があるレイヤーを低下させることができます。
This document discusses and formalizes the concept of channel binding to secure channels.
このドキュメントでは、チャネルバインディングの概念をセキュアチャネルへの概念について説明し、形式化します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Definitions .....................................................4
2.1. Properties of Channel Binding ..............................6
2.2. EAP Channel Binding ........................................9
3. Authentication and Channel Binding Semantics ...................10
3.1. The GSS-API and Channel Binding ...........................10
3.2. SASL and Channel Binding ..................................11
4. Channel Bindings Specifications ................................11
4.1. Examples of Unique Channel Bindings .......................11
4.2. Examples of End-Point Channel Bindings ....................12
5. Uses of Channel Binding ........................................12
6. Benefits of Channel Binding to Secure Channels .................14
7. IANA Considerations ............................................15
7.1. Registration Procedure ....................................15
7.2. Comments on Channel Bindings Registrations ................16
7.3. Change Control ............................................17
8. Security Considerations ........................................17
8.1. Non-Unique Channel Bindings and Channel Binding
Re-Establishment ..........................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................19
Appendix A. Acknowledgments .......................................22
In a number of situations, it is useful for an application to be able to handle authentication within the application layer, while simultaneously being able to utilize session or transport security at a lower network layer. For example, IPsec [RFC4301] [RFC4303] [RFC4302] is amenable to being accelerated in hardware to handle very high link speeds, but IPsec key exchange protocols and the IPsec architecture are not as amenable to use as a security mechanism within applications, particularly applications that have users as clients. A method of combining security at both layers is therefore attractive. To enable this to be done securely, it is necessary to "bind" the mechanisms together -- so as to avoid man-in-the-middle vulnerabilities and enable the mechanisms to be integrated in a seamless way. This is the objective of "Channel Bindings".
多くの状況では、アプリケーションがアプリケーションレイヤー内で認証を処理できるようにすると同時に、セッションを使用したり、より低いネットワーク層でセキュリティを輸送できるようにすることが役立ちます。たとえば、IPSEC [RFC4301] [RFC4303] [RFC4302]は、非常に高いリンク速度を処理するためにハードウェアで加速することに適していますが、IPSECキーエクスチェンジプロトコルとIPSECアーキテクチャは、アプリケーション、特にアプリケーション内のセキュリティメカニズムほど使用できません。ユーザーをクライアントとして持っているアプリケーション。したがって、両方のレイヤーでセキュリティを組み合わせる方法は魅力的です。これを安全に実行できるようにするには、中間の脆弱性を避け、メカニズムをシームレスな方法で統合できるようにするために、メカニズムを一緒に「バインド」する必要があります。これが「チャネルバインディング」の目的です。
The term "channel binding", as used in this document, derives from the Generic Security Service Application Program Interface (GSS-API) [RFC2743], which has a channel binding facility that was intended for binding GSS-API authentication to secure channels at lower network layers. The purpose and benefits of the GSS-API channel binding facility were not discussed at length, and some details were left unspecified. Now we find that this concept can be very useful, therefore we begin with a generalization and formalization of "channel binding" independent of the GSS-API.
このドキュメントで使用されている「チャネルバインディング」という用語は、ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）[RFC2743]に由来します。ネットワークレイヤーの低い。GSS-APIチャネル結合施設の目的と利点は長く議論されておらず、いくつかの詳細は特定されていません。これで、この概念は非常に有用である可能性があることがわかります。したがって、GSS-APIとは無関係に「チャネル結合」の一般化と形式化から始めます。
Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS-API applications. We envision use of channel binding by applications that utilize other security frameworks, such as Simple Authentication and Security Layer (SASL) [RFC4422] and even protocols that provide their own authentication mechanisms (e.g., the Key Distribution Center (KDC) exchanges of Kerberos V [RFC4120]). We also envision use of the notion of channel binding in the analysis of security protocols.
GSS-APIに触発され、派生したものの、本明細書に記載されているチャネル結合の概念は、GSS-APIアプリケーションによる使用にまったく限定されていません。単純な認証とセキュリティレイヤー（SASL）[RFC4422]や、独自の認証メカニズムを提供するプロトコル（例えば、Kerberos vの交換を提供するプロトコルなど、他のセキュリティフレームワークを利用するアプリケーションによるチャネルバインディングの使用を想定しています。[RFC4120]）。また、セキュリティプロトコルの分析におけるチャネル結合の概念の使用も想定しています。
The main goal of channel binding is to be able to delegate cryptographic session protection to network layers below the application in hopes of being able to better leverage hardware implementations of cryptographic protocols. Section 5 describes some intended uses of channel binding. Also, some applications may benefit by reducing the amount of active cryptographic state, thus reducing overhead in accessing such state and, therefore, the impact of security on latency.
チャネルバインディングの主な目標は、暗号化プロトコルのハードウェア実装をより適切に活用できることを期待して、暗号化セッション保護をアプリケーション以下のネットワークレイヤーに委任できることです。セクション5では、チャネルバインディングのいくつかの意図された使用について説明します。また、一部のアプリケーションは、アクティブな暗号化状態の量を減らすことで利益を得る可能性があり、したがって、そのような状態にアクセスする際のオーバーヘッド、したがって、セキュリティが遅延に与える影響を減らします。
The critical security problem to solve in order to achieve such delegation of session protection is ensuring that there is no man-in-the-middle (MITM), from the point of view the application, at the lower network layer to which session protection is to be delegated.
セッション保護のこのような委任を達成するために解決する重要なセキュリティの問題は、セッション保護があるネットワークレイヤーの下部で、アプリケーションの観点から、中間者（MITM）がないことを保証することです。委任される。
There may well be an MITM, particularly if either the lower network layer provides no authentication or there is no strong connection between the authentication or principals used at the application and those used at the lower network layer.
特に、低いネットワークレイヤーが認証を提供しない場合、またはアプリケーションで使用される認証またはプリンシパルと低いネットワークレイヤーで使用されているものとの間に強い接続がない場合、MITMがある場合があります。
Even if such MITM attacks seem particularly difficult to effect, the attacks must be prevented for certain applications to be able to make effective use of technologies such as IPsec [RFC2401] [RFC4301] or HTTP with TLS [RFC4346] in certain contexts (e.g., when there is no authentication to speak of, or when one node's set of trust anchors is too weak to believe that it can authenticate its peers). Additionally, secure channels that are susceptible to MITM attacks because they provide no useful end-point authentication are useful when combined with application-layer authentication (otherwise they are only somewhat "better than nothing" -- see Better Than Nothing Security (BTNS) [BTNS-AS]).
そのようなMITM攻撃を実施するのが特に難しいと思われたとしても、特定のアプリケーション[RFC2401] [RFC4301]または特定の文脈でTLS [RFC4346]を使用したHTTPなどのテクノロジーを効果的に使用できるようにするために、攻撃を防ぐ必要があります（例：話す認証がない場合、または1つのノードの信頼アンカーのセットが弱すぎて、同僚を認証できると信じるには）。さらに、MITM攻撃の影響を受けやすいセキュアチャネルは、アプリケーションレイヤー認証と組み合わせると便利なエンドポイント認証を提供しないために役立ちます（そうでなければ「何もない」 - セキュリティよりも優れている（BTNS）[btns-as]）。
For example, Internet Small Computer Systems Interface (iSCSI) [RFC3720] provides for application-layer authentication (e.g., using Kerberos V), but relies on IPsec for transport protection; iSCSI does not provide a binding between the two. iSCSI initiators have to be careful to make sure that the name of the server authenticated at the application layer and the name of the peer at the IPsec layer match -- an informal form of channel binding.
たとえば、インターネットスモールコンピューターシステムインターフェイス（ISCSI）[RFC3720]は、アプリケーション層認証（たとえば、Kerberos Vを使用）を提供しますが、輸送保護のためにIPSECに依存しています。ISCSIは、2つの間にバインディングを提供しません。ISCSIイニシエーターは、アプリケーションレイヤーで認証されたサーバーの名前とIPSECレイヤーマッチでピアの名前を確認するように注意する必要があります。
This document describes a solution: the use of "channel binding" to bind authentication at application layers to secure sessions at lower layers in the network stack.
このドキュメントでは、ソリューション：アプリケーションレイヤーで認証を結合するための「チャネルバインディング」の使用は、ネットワークスタック内の下層層でセッションを保護するためです。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
o Secure channel: a packet, datagram, octet stream connection, or sequence of connections between two end-points that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it. We assume that the channel is secure -- if an attacker can successfully cryptanalyze a channel's session keys, for example, then the channel is not secure.
o セキュアチャネル：パケット、データグラム、オクテットストリーム接続、または暗号化の完全性を提供する2つのエンドポイント間の接続のシーケンス、およびオプションで、それを交換するデータへの機密性。チャンネルは安全であると仮定します - 攻撃者がチャンネルのセッションキーを暗号化できた場合、たとえばチャンネルは安全ではありません。
o Channel binding: the process of establishing that no man-in-the-middle exists between two end-points that have been authenticated at one network layer but are using a secure channel at a lower network layer. This term is used as a noun.
o チャネルバインディング：1つのネットワークレイヤーで認証されているが、より低いネットワークレイヤーで安全なチャネルを使用している2つのエンドポイントの間に中間のマンが存在しないことを確立するプロセス。この用語は名詞として使用されます。
o Channel bindings: [See historical note below.]
o チャネルバインディング：[以下の歴史的なメモを参照してください。]
Generally, some data that "names" a channel or one or both of its end-points such that if this data can be shown, at a higher network layer, to be the same at both ends of a channel, then there are no MITMs between the two end-points at that higher network layer. This term is used as a noun.
一般に、このデータをより高いネットワークレイヤーで、チャネルの両端で同じであると表示できる場合、そのエンドポイントの1つまたは両方または両方がそのエンドポイントに「名前を付ける」データがあります。その高いネットワークレイヤーでの2つのエンドポイントの間。この用語は名詞として使用されます。
More formally, there are two types of channel bindings:
より正式には、チャネルバインディングには2つのタイプがあります。
+ unique channel bindings:
+ ユニークなチャネルバインディング：
channel bindings that name a channel in a cryptographically secure manner and uniquely in time;
チャンネルに名前を付けたチャネルバインディングは、暗号化的に安全な方法で、時間内に一意に並んでいます。
+ end-point channel bindings:
+ エンドポイントチャネルバインディング：
channel bindings that name the authenticated end-points, or even a single end-point, of a channel which are, in turn, securely bound to the channel, but which do not identify a channel uniquely in time.
チャネルには、チャネルにしっかりと縛られているが、時間内にチャネルを識別しないチャネルの認証されたエンドポイント、または単一のエンドポイントに名前を付けるチャネルバインディング。
o Cryptographic binding: (e.g., "cryptographically bound") a cryptographic operation that causes an object, such as a private encryption or signing key, or an established secure channel, to "speak for" [Lampson91] some principal, such as a user, a computer, etcetera. For example, a Public Key Infrastructure for X.509 Certificates (PKIX) certificate binds a private key to the name of a principal in the trust domain of the certificate's issuer such that a possessor of said private key can act on behalf of the user (or other entity) named by the certificate.
o 暗号化の結合：（例：「暗号化されたバウンド」）プライベート暗号化や署名キー、または確立された安全なチャネルなどのオブジェクトを引き起こす暗号操作は、ユーザーなどの一部のプリンシパルを「lampson91]コンピューターなど。たとえば、X.509証明書（PKIX）証明書の公開キーインフラストラクチャは、証明書の発行者の信頼領域のプリンシパルの名前の秘密鍵に結合し、当該秘密鍵の所有者がユーザーに代わって行動できるようにします（証明書によって名前が付けられた他のエンティティ）。
Cryptographic bindings are generally asymmetric in nature (not to be confused with symmetric or asymmetric key cryptography) in that an object is rendered capable of standing for another, but the reverse is not usually the case (we don't say that a user speaks for their private keys, but we do say that the user's private keys speak for the user).
暗号化のバインディングは、一般に本質的に非対称です（対称または非対称のキー暗号化と混同しないでください）オブジェクトは別のオブジェクトに立つことができるようにレンダリングされますが、逆は通常そうではありません（ユーザーが話すとは言いません彼らのプライベートキーですが、ユーザーのプライベートキーはユーザーのために話していると言います）。
Note that there may be many instances of "cryptographic binding" in an application of channel binding. The credentials that authenticate principals at the application layer bind private or secret keys to the identities of those principals, such that said keys speak for them. A secure channel typically consists of symmetric session keys used to provide confidentiality and integrity protection to data sent over the channel; each end-point's session keys speak for that end-point of the channel. Finally, each end-point of a channel bound to authentication at the application layer speaks for the principal authenticated at the application layer on the same side of the channel.
チャネル結合の適用には「暗号化結合」の多くのインスタンスがあるかもしれないことに注意してください。アプリケーションレイヤーでプリンシパルを認証する資格情報は、プライベートキーをそれらのプリンシパルのアイデンティティにバインドします。安全なチャネルは、通常、チャネルを介して送信されたデータに機密性と整合性の保護を提供するために使用される対称セッションキーで構成されています。各エンドポイントのセッションキーは、チャンネルのそのエンドポイントについて話します。最後に、アプリケーションレイヤーでの認証に結合したチャネルの各エンドポイントは、チャネルの同じ側のアプリケーションレイヤーで認証されたプリンシパルについて話します。
The terms defined above have been in use for many years and have been taken to mean, at least in some contexts, what is stated below. Unfortunately this means that "channel binding" can refer to the channel binding operation and, sometimes to the name of a channel, and "channel bindings" -- a difference of only one letter -- generally refers to the name of a channel.
上記で定義された用語は長年使用されており、少なくともいくつかの文脈では、以下に示されていることを意味すると考えられてきました。残念ながら、これは「チャネルバインディング」がチャネル結合操作を指し、時にはチャネルの名前を指し、「チャンネルバインディング」（1文字のみの違い）が通常、チャネルの名前を指します。
Note that the Extensible Authentication Protocol (EAP) [RFC3748] uses "channel binding" to refer to a facility that may appear to be similar to the one decribed here, but it is, in fact, quite different. See Section 2.2 for mode details.
拡張可能な認証プロトコル（EAP）[RFC3748]は「チャネルバインディング」を使用して、ここでは非難されているものと似ているように見える施設を指すことに注意してください。モードの詳細については、セクション2.2を参照してください。
Applications, authentication frameworks (e.g., the GSS-API, SASL), security mechanisms (e.g., the Kerberos V GSS-API mechanism [RFC1964]), and secure channels must meet the requirements and should follow the recommendations that are listed below.
アプリケーション、認証フレームワーク（例：GSS-API、SASL）、セキュリティメカニズム（たとえば、Kerberos v GSS-APIメカニズム[RFC1964]）、および安全なチャネルが要件を満たす必要があり、以下にリストされている推奨事項に従う必要があります。
Requirements:
要件：
o In order to use channel binding, applications MUST verify that the same channel bindings are observed at either side of the channel. To do this, the application MUST use an authentication protocol at the application layer to authenticate one, the other, or both application peers (one at each end of the channel).
o チャネルバインディングを使用するには、アプリケーションが同じチャネルバインディングがチャネルの両側で観察されていることを確認する必要があります。これを行うには、アプリケーションはアプリケーションレイヤーで認証プロトコルを使用して、一方、もう一方、または両方のアプリケーションピア（チャンネルの両端に1つ）を認証する必要があります。
* If the authentication protocol used by the application supports channel binding, the application SHOULD use it.
* アプリケーションで使用される認証プロトコルがチャネルバインディングをサポートする場合、アプリケーションはそれを使用する必要があります。
* An authentication protocol that supports channel binding MUST provide an input slot in its API for a "handle" to the channel, or its channel bindings.
* チャネルバインディングをサポートする認証プロトコルは、チャネルまたはチャネルバインディングに「ハンドル」のAPIの入力スロットを提供する必要があります。
* If the authentication protocol does not support a channel binding operation, but provides a "security layer" with at least integrity protection, then the application MUST use the authentication protocol's integrity protection facilities to exchange channel bindings, or cryptographic hashes thereof.
* 認証プロトコルがチャネルバインディング操作をサポートせず、少なくとも整合性保護を備えた「セキュリティレイヤー」を提供する場合、アプリケーションは認証プロトコルの整合性保護施設を使用してチャネルバインディングまたは暗号化のハッシュを交換する必要があります。
* The name of the type of channel binding MUST be used by the application and/or authentication protocol to avoid ambiguity about which of several possible types of channels is being bound. If nested instances of the same type of channel are available, then the innermost channel MUST be used.
* チャネルバインディングのタイプの名前は、アプリケーションおよび/または認証プロトコルで使用する必要があります。同じタイプのチャネルのネストされたインスタンスが利用可能な場合、最も内側のチャネルを使用する必要があります。
o Specifications of channel bindings for any secure channels MUST provide for a single, canonical octet string encoding of the channel bindings. Under this framework, channel bindings MUST start with the channel binding unique prefix followed by a colon (ASCII 0x3A).
o 安全なチャネルのチャネルバインディングの仕様は、チャネルバインディングの単一の標準的なオクテット文字列エンコードを提供する必要があります。このフレームワークでは、チャネルバインディングは、チャネルバインディングユニークなプレフィックスに続いてコロン（ASCII 0x3a）から開始する必要があります。
o The channel bindings for a given type of secure channel MUST be constructed in such a way that an MITM could not easily force the channel bindings of a given channel to match those of another.
o 特定のタイプの安全なチャネルのチャネルバインディングは、MITMが特定のチャネルのチャネルバインディングを他のチャネルのバインディングに簡単に強制できないように構築する必要があります。
o Unique channel bindings MUST bind not only the key exchange for the secure channel, but also any negotiations and authentication that may have taken place to establish the channel.
o ユニークなチャネルバインディングは、安全なチャネルの重要な交換だけでなく、チャネルを確立するために行われた可能性のある交渉と認証もバインドする必要があります。
o End-point channel bindings MUST be bound into the secure channel and all its negotiations. For example, a public key as an end-point channel binding should be used to verify a signature of such negotiations (or to encrypt them), including the initial key exchange and negotiation messages for that channel -- such a key would then be bound into the channel. A certificate name as end-point channel binding could also be bound into the channel in a similar way, though in the case of a certificate name, the binding also depends on the strength of the authentication of that name (that is, the validation of the certificate, the trust anchors, the algorithms used in the certificate path construction and validation, etcetera).
o エンドポイントチャネルバインディングは、安全なチャネルとそのすべての交渉に結合する必要があります。たとえば、エンドポイントチャネルバインディングとしての公開キーを使用して、そのチャネルの最初のキー交換と交渉メッセージを含む、そのような交渉の署名（またはそれらを暗号化する）を検証する必要があります - そのようなキーはバインドされますチャンネルに。エンドポイントチャネルバインディングとしての証明書名も同様の方法でチャネルにバインドできますが、証明書名の場合、バインディングはその名前の認証の強度（つまり、の検証にも依存します。証明書、トラストアンカー、証明書パスの構築と検証で使用されるアルゴリズムなど）。
o End-point channel bindings MAY be identifiers (e.g., certificate names) that must be authenticated through some infrastructure, such as a public key infrastructure (PKI). In such cases, applications MUST ensure that the channel provides adequate authentication of such identifiers (e.g., that the certificate validation policy and trust anchors used by the channel satisfy the application's requirements). To avoid implementation difficulties in addressing this requirement, applications SHOULD use cryptographic quantities as end-point channel bindings, such as certificate-subject public keys.
o エンドポイントチャネルバインディングは、公開キーインフラストラクチャ（PKI）などの一部のインフラストラクチャを通じて認証する必要がある識別子（例：証明書名）です。そのような場合、アプリケーションは、チャネルがそのような識別子の適切な認証を提供することを確認する必要があります（たとえば、チャネルで使用される証明書の検証ポリシーと信頼のアンカーがアプリケーションの要件を満たすこと）。この要件に対処する際の実装の困難を回避するために、アプリケーションは、証明書と被験者のパブリックキーなどのエンドポイントチャネルバインディングとして暗号化量を使用する必要があります。
o Applications that desire confidentiality protection MUST use application-layer session protection services for confidentiality protection when the bound channel does not provide confidentiality protection.
o 機密保護を希望するアプリケーションは、バインドチャネルが機密保護を提供しない場合、機密性保護のためにアプリケーション層セッション保護サービスを使用する必要があります。
o The integrity of a secure channel MUST NOT be weakened should their channel bindings be revealed to an attacker. That is, the construction of the channel bindings for any type of secure channel MUST NOT leak secret information about the channel. End-point channel bindings, however, MAY leak information about the end-points of the channel (e.g., their names).
o 安全なチャネルの完全性は、チャネルのバインディングが攻撃者に明らかにされた場合に弱めてはなりません。つまり、あらゆるタイプの安全なチャネル用のチャネルバインディングの構築は、チャネルに関する秘密の情報を漏らしてはなりません。ただし、エンドポイントチャネルのバインディングは、チャネルのエンドポイントに関する情報を漏らす可能性があります（たとえば、名前）。
o The channel binding operation MUST be at least integrity protected in the security mechanism used at the application layer.
o チャネル結合操作は、アプリケーション層で使用されるセキュリティメカニズムで少なくとも整合性保護されている必要があります。
o Authentication frameworks and mechanisms that support channel binding MUST communicate channel binding failure to applications.
o チャネル結合をサポートする認証フレームワークとメカニズムは、チャネル結合の障害をアプリケーションに伝達する必要があります。
o Applications MUST NOT send sensitive information, requiring confidentiality protection, over the underlying channel prior to completing the channel binding operation.
o アプリケーションは、チャネルバインディング操作を完了する前に、基礎となるチャネル上で、機密性の保護を必要とする機密情報を送信してはなりません。
Recommendations:
推奨事項：
o End-point channel bindings where the end-points are meaningful names SHOULD NOT be used when the channel does not provide confidentiality protection and privacy protection is desired. Alternatively, channels that export such channel bindings SHOULD provide for the use of a digest and SHOULD NOT introduce new digest/hash agility problems as a result.
o エンドポイントが意味のある名前であるエンドポイントチャネルバインディングは、チャネルが機密保護を提供しない場合、プライバシー保護を提供しない場合に使用しないでください。あるいは、そのようなチャネルバインディングをエクスポートするチャネルは、ダイジェストの使用を提供する必要があり、結果として新しいダイジェスト/ハッシュ俊敏性の問題を導入してはなりません。
Options:
オプション：
o Authentication frameworks and mechanisms that support channel binding MAY fail to establish authentication if channel binding fails.
o チャネル結合をサポートする認証フレームワークとメカニズムは、チャネルバインディングが失敗した場合、認証を確立できない場合があります。
o Applications MAY send information over the underlying channel and without integrity protection from the application-layer authentication protocol prior to completing the channel binding operation if such information requires only integrity protection. This could be useful for optimistic negotiations.
o アプリケーションは、そのような情報が完全性保護のみを必要とする場合、チャネルバインディング操作を完了する前に、基礎となるチャネルを介して、およびアプリケーション層認証プロトコルからの整合性保護なしで情報を送信する場合があります。これは、楽観的な交渉に役立つ可能性があります。
o A security mechanism MAY exchange integrity-protected channel bindings.
o セキュリティメカニズムは、整合性保護されたチャネルバインディングを交換する場合があります。
o A security mechanism MAY exchange integrity-protected digests of channel bindings. Such mechanisms SHOULD provide for hash/digest agility.
o セキュリティメカニズムは、チャネルバインディングの整合性保護されたダイジェストを交換する場合があります。このようなメカニズムは、ハッシュ/ダイジェストの俊敏性を提供する必要があります。
o A security mechanism MAY use channel bindings in key exchange, authentication, or key derivation, prior to the exchange of "authenticator" messages.
o セキュリティメカニズムは、「認証装置」メッセージの交換の前に、キー交換、認証、またはキー派生でチャネルバインディングを使用する場合があります。
This section is informative. This document does not update EAP [RFC3748], it neither normatively describes, nor does it impose requirements on any aspect of EAP or EAP methods.
このセクションは有益です。このドキュメントは、EAP [RFC3748]を更新せず、EAPまたはEAPメソッドのあらゆる側面に要件を規範的に説明するものでもありません。
EAP [RFC3748] includes a concept of channel binding described as follows:
EAP [RFC3748]には、次のように説明されているチャネル結合の概念が含まれています。
The communication within an EAP method of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol).
バンド外のメカニズム（AAAまたは下層層プロトコルなど）を介して伝達される値と比較できるエンドポイント識別子などの整合性保護されたチャネルプロパティのEAPメソッド内の通信。
Section 7.15 of [RFC3748] describes the problem as one where a Network Access Server (NAS) (a.k.a. "authenticator") may lie to the peer (client) and cause the peer to make incorrect authorization decisions (e.g., as to what traffic may transit through the NAS). This is not quite like the purpose of generic channel binding (MITM detection).
[RFC3748]のセクション7.15は、問題をネットワークアクセスサーバー（NAS）（別名「認証者」）がピア（クライアント）に嘘をつき、ピアに誤った承認の決定を行う可能性がある場合（例えば、トラフィックが何を誤って認証する決定を下す可能性があるかを説明しています。NASを通過する）。これは、一般的なチャネル結合（MITM検出）の目的とはまったく異なります。
Section 7.15 of [RFC3748] calls for "a protected exchange of channel properties such as endpoint identifiers" such that "it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method".
[RFC3748]のセクション7.15は、「エンドポイント識別子などのチャネルプロパティの保護された交換」を求めています。。
This has sometimes been taken to be very similar to the generic notion of channel binding provided here. However, there is a very subtle difference between the two concepts of channel binding that makes it much too difficult to put forth requirements and recommendations that apply to both. The difference is about the lower-layer channel:
これは、ここで提供されるチャネル結合の一般的な概念と非常によく似ていると見なされることがあります。ただし、チャネルバインディングの2つの概念には非常に微妙な違いがあり、両方に適用される要件と推奨事項を提出することが非常に難しくなります。違いは、低層チャネルに関するものです。
o In the generic channel binding case, the identities of either end of this channel are irrelevant to anything other than the construction of a name for that channel, in which case the identities of the channel's end-points must be established a priori.
o 一般的なチャネル結合の場合、このチャネルのいずれかの端のアイデンティティは、そのチャネルの名前の構築以外のものとは無関係です。その場合、チャネルのエンドポイントのアイデンティティはアプリオリを確立する必要があります。
o Whereas in the EAP case, the identity of the NAS end of the channel, and even security properties of the channel itself, may be established during or after authentication of the EAP peer to the EAP server.
o 一方、EAPの場合、チャネルのNAS端のID、さらにはチャネル自体のセキュリティプロパティさえ、EAPピアのEAPサーバーへの認証中または後に確立される場合があります。
In other words: there is a fundamental difference in mechanics (timing of lower-layer channel establishment) and in purpose (authentication of lower-layer channel properties for authorization purposes vs. MITM detection).
言い換えれば、メカニズム（低層チャネル確立のタイミング）と目的（MITM検出とMITM検出のための低層チャネル特性の認証）には根本的な違いがあります。
After some discussion we have concluded that there is no simple way to obtain requirements and recommendations that apply to both generic and EAP channel binding. Therefore, EAP is out of the scope of this document.
いくつかの議論の後、私たちは、一般的なチャネル結合とEAPチャネル結合の両方に適用される要件と推奨事項を取得する簡単な方法はないと結論付けました。したがって、EAPはこのドキュメントの範囲外です。
Some authentication frameworks and/or mechanisms provide for channel binding, such as the GSS-API and some GSS-API mechanisms, whereas others may not, such as SASL (however, ongoing work is adding channel binding support to SASL). Semantics may vary with respect to negotiation, how the binding occurs, and handling of channel binding failure (see below).
一部の認証フレームワークおよび/またはメカニズムは、GSS-APIや一部のGSS-APIメカニズムなどのチャネル結合を提供しますが、SASLなどの他のメカニズムはそうでない場合があります（ただし、進行中の作業ではSASLにチャネル結合サポートを追加しています）。セマンティクスは、交渉、結合の発生方法、およびチャネル結合障害の取り扱いに関して異なる場合があります（以下を参照）。
Where suitable channel binding facilities are not provided, application protocols MAY include a separate, protected exchange of channel bindings. In order to do this, the application-layer authentication service must provide message protection services (at least integrity protection).
適切なチャネル結合機能が提供されていない場合、アプリケーションプロトコルには、チャネルバインディングの個別の保護された交換が含まれる場合があります。これを行うには、アプリケーション層認証サービスがメッセージ保護サービスを提供する必要があります（少なくとも整合性保護）。
The GSS-API [RFC2743] provides for the use of channel binding during initialization of GSS-API security contexts, though GSS-API mechanisms are not required to support this facility.
GSS-API [RFC2743]は、GSS-APIセキュリティコンテキストの初期化中にチャネル結合の使用を規定していますが、GSS-APIメカニズムはこの施設をサポートするためには必要ありません。
This channel binding facility is described in [RFC2743] and [RFC2744].
このチャネル結合施設は、[RFC2743]および[RFC2744]で説明されています。
GSS-API mechanisms must fail security context establishment when channel binding fails, and the GSS-API provides no mechanism for the negotiation of channel binding. As a result GSS-API applications must agree a priori, through negotiation or otherwise, on the use of channel binding.
GSS-APIメカニズムは、チャネル結合が失敗した場合にセキュリティコンテキストの確立に失敗する必要があり、GSS-APIはチャネル結合の交渉のメカニズムを提供しません。その結果、GSS-APIアプリケーションは、チャネルバインディングの使用に関して、交渉などを通じてアプリオリに同意する必要があります。
Fortunately, it is possible to design GSS-API pseudo-mechanisms that simply wrap around existing mechanisms for the purpose of allowing applications to negotiate the use of channel binding within their existing methods for negotiating GSS-API mechanisms. For example, NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as does the SSHv2 protocol [RFC4462]. Such pseudo-mechanisms are being proposed separately, see [STACKABLE].
幸いなことに、GSS-APIメカニズムを交渉するために既存の方法内でアプリケーションを交渉できるようにするために、既存のメカニズムを単純に包むGSS-API擬似機械を設計することが可能です。たとえば、NFSV4 [RFC3530]は、SSHV2プロトコル[RFC4462]と同様に、独自のGSS-APIメカニズム交渉を提供します。このような擬似機械は別々に提案されています。[積み重ね可能]を参照してください。
SASL [RFC4422] does not yet provide for the use of channel binding during initialization of SASL contexts.
SASL [RFC4422]は、SASLコンテキストの初期化中にチャネル結合の使用をまだ提供していません。
Work is ongoing [SASL-GS2] to specify how SASL, particularly its new bridge to the GSS-API, performs channel binding. SASL will likely differ from the GSS-API in its handling of channel binding failure (i.e., when there may be an MITM) in that channel binding success/failure will only affect the negotiation of SASL security layers. That is, when channel binding succeeds, SASL should select no security layers, leaving session cryptographic protection to the secure channel that SASL authentication has been bound to.
SASL、特にGSS-APIへの新しいブリッジがチャネル結合を実行する方法を指定するために、作業は進行中です[SASL-GS2]。SASLは、チャネル結合の成功/障害がSASLセキュリティ層の交渉にのみ影響するというチャネル結合障害の処理（つまり、MITMがある可能性がある場合）のGSS-APIとは異なる可能性があります。つまり、チャネルバインディングが成功すると、SASLはセキュリティレイヤーを選択しないため、SASL認証が拘束されている安全なチャネルにセッションの暗号保護を残します。
Channel bindings for various types of secure channels are not described herein. Some channel bindings specifications can be found in:
さまざまなタイプの安全なチャネルのチャネルバインディングは、本明細書には説明されていません。いくつかのチャネルバインディングの仕様は、次のように見つけることができます。
+--------------------+----------------------------------------------+
| Secure Channel | Reference |
| Type | |
+--------------------+----------------------------------------------+
| SSHv2 | [SSH-CB] |
| | |
| TLS | [TLS-CB] |
| | |
| IPsec | There is no specification for IPsec channel |
| | bindings yet, but the IETF Better Than |
| | Nothing Security (BTNS) WG is working to |
| | specify IPsec channels, and possibly IPsec |
| | channel bindings. |
+--------------------+----------------------------------------------+
The following text is not normative, but is here to show how one might construct channel bindings for various types of secure channels.
次のテキストは規範的ではありませんが、さまざまなタイプの安全なチャネルのチャネルバインディングを構築する方法を示すためにここにあります。
For SSHv2 [RFC4251] the SSHv2 session ID should suffice as it is a cryptographic binding of all relevant SSHv2 connection parameters: key exchange and negotiation.
SSHV2 [RFC4251]の場合、SSHV2セッションIDは、関連するすべてのSSHV2接続パラメーターの暗号化結合であるため、キー交換と交渉です。
The TLS [RFC4346] session ID is simply assigned by the server. As such, the TLS session ID does not have the required properties to be useful as a channel binding because any MITM, posing as the server, can simply assign the same session ID to the victim client as the server assigned to the MITM. Instead, the initial, unencrypted TLS finished messages (the client's, the server's, or both) are sufficient as they are the output of the TLS pseudo-random function, keyed with the session key, applied to all handshake material.
TLS [RFC4346]セッションIDは、サーバーによって単純に割り当てられます。そのため、TLSセッションIDには、サーバーとしてポーズをとるMITMは、MITMに割り当てられたサーバーと同じセッションIDを被害者クライアントに割り当てるだけで、チャネルバインディングとして役立つ必要なプロパティがありません。代わりに、初期の暗号化されていないTLS完成メッセージ（クライアント、サーバー、またはその両方）は、すべてのハンドシェイク素材に適用されるセッションキーにキー付きTLS擬似ランダム関数の出力であるため、十分です。
The following text is not normative, but is here to show how one might construct channel bindings for various types of secure channels.
次のテキストは規範的ではありませんが、さまざまなタイプの安全なチャネルのチャネルバインディングを構築する方法を示すためにここにあります。
For SSHv2 [RFC4251] the SSHv2 host public key, when present, should suffice as it is used to sign the algorithm suite negotiation and Diffie-Hellman key exchange; as long the client observes the host public key that corresponds to the private host key that the server used, then there cannot be an MITM in the SSHv2 connection. Note that not all SSHv2 key exchanges use host public keys; therefore, this channel bindings construction is not as useful as the one given in Section 4.1.
SSHV2 [RFC4251]の場合、SSHV2ホスト公開キーは、存在する場合は、アルゴリズムスイートネゴシエーションとdiffie-hellmanキーエクスチェンジに署名するために使用されるため、十分である必要があります。長い間、クライアントがサーバーが使用したプライベートホストキーに対応するホスト公開キーを観察するにつれて、SSHV2接続にMITMは存在できません。すべてのSSHV2キー交換がホストパブリックキーを使用しているわけではないことに注意してください。したがって、このチャネルバインディング構造は、セクション4.1で示されたものほど有用ではありません。
For TLS [RFC4346]the server certificate should suffice for the same reasons as above. Again, not all TLS cipher suites involve server certificates; therefore, the utility of this construction of channel bindings is limited to scenarios where server certificates are commonly used.
TLS [RFC4346]の場合、上記と同じ理由でサーバー証明書で十分です。繰り返しますが、すべてのTLS暗号スイートがサーバー証明書を含むわけではありません。したがって、チャネルバインディングのこの構造の有用性は、サーバー証明書が一般的に使用されるシナリオに限定されます。
Uses for channel binding identified so far:
これまでに特定されたチャネルバインディングの使用：
o Delegating session cryptographic protection to layers where hardware can reasonably be expected to support relevant cryptographic protocols:
o ハードウェアが関連する暗号プロトコルをサポートすることが合理的に期待できるレイヤーにセッションの暗号保護を委任します。
* NFSv4 [RFC3530] with Remote Direct Data Placement (RDDP) [NFS-DDP] for zero-copy reception where network interface controllers (NICs) support RDDP. Cryptographic session protection would be delegated to Encapsulating Security Payload (ESP) [RFC4303] / Authentication Headers (AHs) [RFC4302].
* ネットワークインターフェイスコントローラー（NICS）がRDDPをサポートするゼロコピー受信用のリモート直接データ配置（RDDP）[NFS-DDP]を使用したNFSV4 [RFC3530]。暗号化セッションの保護は、セキュリティペイロード（ESP）[RFC4303] /認証ヘッダー（AHS）[RFC4302]をカプセル化するために委任されます。
* iSCSI [RFC3720] with Remote Direct Memory Access (RDMA) [RFC5046]. Cryptographic session protection would be delegated to ESP/AH.
* リモート直接メモリアクセス（RDMA）[RFC5046]を備えたISCSI [RFC3720]。暗号化セッションの保護は、ESP/AHに委任されます。
* HTTP with TLS [RFC2817] [RFC2818]. In situations involving proxies, users may want to bind authentication to a TLS channel between the last client-side proxy and the first server-side proxy ("concentrator"). There is ongoing work to expand the set of choices for end-to-end authentication at the HTTP layer, that, coupled with channel binding to TLS, would allow for proxies while not forgoing protection over public internets.
* TLS [RFC2817] [RFC2818]を使用したHTTP。プロキシを含む状況では、ユーザーは、最後のクライアント側プロキシと最初のサーバー側プロキシ（「Concentor」）の間のTLSチャネルに認証をバインドすることをお勧めします。HTTPレイヤーでのエンドツーエンド認証の選択セットを拡張するための継続的な作業があります。これは、TLSへのチャネルバインディングと相まって、パブリックインターネットに対する保護を控えることなくプロキシを可能にします。
o Reducing the number of live cryptographic contexts that an application must maintain:
o アプリケーションが維持する必要があるライブ暗号化コンテキストの数を減らす：
* NFSv4 [RFC3530] multiplexes multiple users onto individual connections. Each user is authenticated separately, and users' remote procedure calls (RPCs) are protected with per-user GSS-API security contexts. This means that large timesharing clients must often maintain many cryptographic contexts per-NFSv4 connection. With channel binding to IPsec, they could maintain a much smaller number of cryptographic contexts per-NFSv4 connection, thus reducing memory pressure and interactions with cryptographic hardware.
* NFSV4 [RFC3530]複数のユーザーを個々の接続に多重化します。各ユーザーは個別に認証され、ユーザーのリモートプロシージャコール（RPC）は、ユーザーごとのGSS-APIセキュリティコンテキストで保護されています。これは、大規模なタイムシェアリングクライアントが、多くの場合、NFSV4接続ごとに多くの暗号化コンテキストを維持する必要があることを意味します。IPSECへのチャネル結合により、NFSV4接続ごとに暗号化コンテキストの数がはるかに少ないため、メモリ圧力と暗号化ハードウェアとの相互作用が低下する可能性があります。
For example, applications that wish to use RDDP to achieve zero-copy semantics on reception may use a network layer understood by NICs to offload delivery of application data into pre-arranged memory buffers. Note that in order to obtain zero-copy reception semantics either application data has to be in cleartext relative to this RDDP layer, or the RDDP implementation must know how to implement cryptographic session protection protocols used at the application layer.
たとえば、RDDPを使用してレセプションでゼロコピーセマンティクスを実現したいアプリケーションでは、NICが理解しているネットワークレイヤーを使用して、アプリケーションデータを事前に配置されたメモリバッファーにオフロードする場合があります。ゼロコピー受信セマンティクスを取得するには、いずれかのアプリケーションデータがこのRDDPレイヤーに比べてクリアテキストである必要があるか、RDDPの実装がアプリケーションレイヤーで使用される暗号化セッション保護プロトコルを実装する方法を知っている必要があることに注意してください。
There are a multitude of application-layer cryptographic session protection protocols available. It is not reasonable to expect that NICs should support many such protocols. Further, some application protocols may maintain many cryptographic session contexts per-connection (for example, NFSv4 does). It is thought to be simpler to push the cryptographic session protection down the network stack (to IPsec), and yet be able to produce NICs that offload other operations (i.e., TCP/IP, ESP/AH, and DDP), than it would be to add support in the NIC for the many session cryptographic protection protocols in use in common applications at the application layer.
利用可能なアプリケーション層の暗号化セッション保護プロトコルが多数あります。NICがそのような多くのプロトコルをサポートすることを期待することは合理的ではありません。さらに、一部のアプリケーションプロトコルは、接続ごとに多くの暗号化セッションコンテキストを維持する場合があります（たとえば、NFSV4はそうです）。暗号化セッションの保護をネットワークスタック（IPSECに）に押し下げて、他の操作をオフロードするNIC（TCP/IP、ESP/AH、およびDDP）を生成できると考えられると考えられています。アプリケーションレイヤーの一般的なアプリケーションで使用されている多くのセッション暗号化保護プロトコルのNICにサポートを追加します。
The following figure shows how the various network layers are related:
次の図は、さまざまなネットワークレイヤーがどのように関連しているかを示しています。
+---------------------+
| Application layer |<---+
| |<-+ | In cleartext, relative
+---------------------+ | | to each other.
| RDDP |<---+
+---------------------+ |
| TCP/SCTP |<-+
+---------------------+ | Channel binding of app-layer
| ESP/AH |<-+ authentication to IPsec
+---------------------+
| IP |
+---------------------+
| ... |
+---------------------+
The use of channel binding to delegate session cryptographic protection include:
セッションの暗号化保護を委任するためのチャネルバインディングの使用には次のものがあります。
o Performance improvements by avoiding double protection of application data in cases where IPsec is in use and applications provide their own secure channels.
o IPSECが使用されている場合にアプリケーションデータの二重保護を回避し、アプリケーションが独自の安全なチャネルを提供する場合のパフォーマンスの改善。
o Performance improvements by leveraging hardware-accelerated IPsec.
o ハードウェアアクセラレーションのIPSECを活用することによるパフォーマンスの改善。
o Performance improvements by allowing RDDP hardware offloading to be integrated with IPsec hardware acceleration.
o RDDPハードウェアのオフロードをIPSECハードウェアアクセラレーションと統合できるようにすることにより、パフォーマンスの改善。
Where protocols layered above RDDP use privacy protection, RDDP offload cannot be done. Thus, by using channel binding to IPsec, the privacy protection is moved to IPsec, which is layered below RDDP. So, RDDP can address application protocol data that's in cleartext relative to the RDDP headers.
RDDPを超えて階層化されたプロトコルがプライバシー保護を使用している場合、RDDPオフロードは実行できません。したがって、IPSECへのチャネルバインディングを使用することにより、プライバシー保護がIPSECに移動され、RDDPの下に階層化されます。したがって、RDDPは、RDDPヘッダーと比較してクリアテキストにあるアプリケーションプロトコルデータに対処できます。
o Latency improvements for applications that multiplex multiple users onto a single channel, such as NFS with RPCSEC_GSS [RFC2203].
o RPCSEC_GSS [RFC2203]を搭載したNFSなど、単一のチャネルに複数のユーザーをマルチプレックスするアプリケーションのレイテンシの改善。
Delegation of session cryptographic protection to IPsec requires features not yet specified. There is ongoing work to specify:
IPSECへのセッション暗号化保護の委任には、まだ指定されていない機能が必要です。指定するための継続的な作業があります：
o IPsec channels [CONN-LATCH];
o IPSECチャネル[conn-latch];
o Application programming interfaces (APIs) related to IPsec channels [BTNS-IPSEC];
o IPSECチャネル[BTNS-IPSEC]に関連するアプリケーションプログラミングインターフェイス（API）;
o Channel bindings for IPsec channels;
o IPSECチャネル用のチャネルバインディング。
o Low infrastructure IPsec authentication [BTNS-CORE].
o 低インフラストラクチャIPSEC認証[BTNS-CORE]。
IANA has created a new registry for channel bindings specifications for various types of channels.
IANAは、さまざまなタイプのチャネル用のチャネルバインディング仕様の新しいレジストリを作成しました。
The purpose of this registry is not only to ensure uniqueness of values used to name channel bindings, but also to provide a definitive reference to technical specifications detailing each channel binding available for use on the Internet.
このレジストリの目的は、チャネルバインディングの名前を付けるために使用される値の独自性を確保するだけでなく、インターネットで使用できる各チャネルバインディングを詳述する技術仕様への決定的な参照を提供することでもあります。
There is no naming convention for channel bindings: any string composed of US-ASCII alphanumeric characters, period ('.'), and dash ('-') will suffice.
チャンネルバインディングには命名規則はありません。米国ASCII英数字（ '。'）、およびdash（ ' - '）で構成される文字列で十分です。
The procedure detailed in Section 7.1 is to be used for registration of a value naming a specific individual mechanism.
セクション7.1で詳述されている手順は、特定の個々のメカニズムを命名する値の登録に使用することです。
Registration of a new channel binding requires expert review as defined in BCP 26 [RFC2434].
新しいチャネルバインディングの登録には、BCP 26 [RFC2434]で定義されている専門家のレビューが必要です。
Registration of a channel binding is requested by filling in the following template:
チャネルバインディングの登録は、次のテンプレートに記入することで要求されます。
o Subject: Registration of channel binding X
o 件名：チャネルバインディングxの登録
o Channel binding unique prefix (name):
o チャネルバインディングユニークなプレフィックス（名前）：
o Channel binding type: (One of "unique" or "end-point")
o チャネルバインディングタイプ：（「ユニーク」または「エンドポイント」の1つ）
o Channel type: (e.g., TLS, IPsec, SSH, etc.)
o チャネルタイプ：（例：TLS、IPSEC、SSHなど）
o Published specification (recommended, optional):
o 公開された仕様（推奨、オプション）：
o Channel binding is secret (requires confidentiality protection): yes/no
o チャネルバインディングは秘密です（機密保護が必要です）：はい/いいえ
o Description (optional if a specification is given; required if no published specification is specified):
o 説明（オプション仕様が指定されている場合;公開された仕様が指定されていない場合は必須）：
o Intended usage: (one of COMMON, LIMITED USE, or OBSOLETE)
o 意図された使用法：（一般的な使用、限られた使用、または時代遅れの1つ）
o Person and email address to contact for further information:
o 詳細については、人とメールアドレスをお問い合わせください。
o Owner/Change controller name and email address:
o 所有者/変更コントローラー名とメールアドレス：
o Expert reviewer name and contact information: (leave blank)
o 専門家のレビュー担当者の名前と連絡先情報：（空白のまま）
o Note: (Any other information that the author deems relevant may be added here.)
o 注：（著者が関連すると判断したその他の情報は、ここに追加される場合があります。）
and sending it via electronic mail to <channel-binding@ietf.org> (a public mailing list) and carbon copying IANA at <iana@iana.org>. After allowing two weeks for community input on the mailing list to be determined, an expert will determine the appropriateness of the registration request and either approve or disapprove the request with notice to the requestor, the mailing list, and IANA.
電子メールで<ChannelBinding@ietf.org>（パブリックメーリングリスト）に送信し、<iana@iana.org>でIANAを炭素とコピーします。メーリングリストのコミュニティ入力を決定するために2週間を許可した後、専門家は登録要求の適切性を判断し、リクエスタ、メーリングリスト、およびIANAに通知してリクエストを承認または不承認にします。
If the expert approves registration, it adds her/his name to the submitted registration.
専門家が登録を承認した場合、提出された登録に彼女/彼の名前を追加します。
The expert has the primary responsibility of making sure that channel bindings for IETF specifications go through the IETF consensus process and that prefixes are unique.
専門家は、IETF仕様のチャネルバインディングがIETFコンセンサスプロセスを経て、接頭辞が一意であることを確認する主な責任を負っています。
The review should focus on the appropriateness of the requested channel binding for the proposed use, the appropriateness of the proposed prefix, and correctness of the channel binding type in the registration. The scope of this request review may entail consideration of relevant aspects of any provided technical specification, such as their IANA Considerations section. However, this review is narrowly focused on the appropriateness of the requested registration and not on the overall soundness of any provided technical specification.
このレビューでは、提案された使用のための要求されたチャネルバインディングの適切性、提案されたプレフィックスの適切性、および登録におけるチャネル結合タイプの正しさに焦点を当てる必要があります。このリクエストレビューの範囲は、IANAの考慮事項セクションなど、提供された技術仕様の関連する側面を考慮することを伴う場合があります。ただし、このレビューは、提供された技術仕様の全体的な健全性ではなく、要求された登録の適切性に狭く焦点を当てています。
Authors are encouraged to pursue community review by posting the technical specification as an Internet-Draft and soliciting comment by posting to appropriate IETF mailing lists.
著者は、技術仕様をインターネットドラフトとして投稿し、適切なIETFメーリングリストに投稿してコメントを求めることにより、コミュニティのレビューを追求することをお勧めします。
Comments on registered channel bindings should first be sent to the "owner" of the channel bindings and to the channel binding mailing list.
登録チャネルバインディングに関するコメントは、最初にチャンネルバインディングの「所有者」とチャンネルバインディングメーリングリストに送信する必要があります。
Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the channel binding type registration itself by sending mail to <iana@iana.org>. At IANA's sole discretion, IANA may attach the comment to the channel bindings registration.
コメントの提出者は、所有者に連絡しようとする合理的な試みの後、IANAに<iana@iana.org>にメールを送信して、チャンネルバインディングタイプの登録自体にコメントを添付するよう要求する場合があります。IANAの独自の裁量で、IANAはチャンネルバインディング登録にコメントを添付することができます。
Once a channel bindings registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request.
チャネルバインディング登録がIANAによって公開されると、著者はその定義の変更を要求することができます。変更要求は、登録要求と同じ手順に従います。
The owner of a channel bindings may pass responsibility for the channel bindings to another person or agency by informing IANA; this can be done without discussion or review.
チャンネルバインディングの所有者は、IANAに通知することにより、チャンネルバインディングの責任を他の人または代理店に渡すことができます。これは、議論やレビューなしで行うことができます。
The IESG may reassign responsibility for a channel bindings registration. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community.
IESGは、チャネルバインディング登録の責任を再割り当てする場合があります。これの最も一般的なケースは、登録の著者が死亡した、接触しなくなった、またはコミュニティにとって重要な変更を加えることができないメカニズムに変更を加えることを可能にすることです。
Channel bindings registrations may not be deleted; mechanisms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" field. Such channel bindings will be clearly marked in the lists published by IANA.
チャネルバインディング登録は削除されない場合があります。使用に適していないと考えられていないメカニズムは、「意図した使用」フィールドの変更によって時代遅れと宣言できます。このようなチャネルバインディングは、IANAが公開したリストに明確にマークされます。
The IESG is considered to be the owner of all channel bindings that are on the IETF standards track.
IESGは、IETF標準トラックにあるすべてのチャネルバインディングの所有者であると考えられています。
Security considerations appear throughout this document. In particular see Section 2.1.
このドキュメント全体にセキュリティ上の考慮事項が表示されます。特にセクション2.1を参照してください。
When delegating session protection from one layer to another, one will almost certainly be making some session security trade-offs, such as using weaker cipher modes in one layer than might be used in the other. Evaluation and comparison of the relative cryptographic strengths of these is difficult, may not be easily automated, and is far out of scope for this document. Implementors and administrators should understand these trade-offs. Interfaces to secure channels and application-layer authentication frameworks and mechanisms could provide some notion of security profile so that applications may avoid delegation of session protection to channels that are too weak to match a required security profile.
ある層から別のレイヤーにセッション保護を委任する場合、一方は、一方のレイヤーでより弱い暗号モードを他のレイヤーで使用するよりも使用するなど、セッションセキュリティのトレードオフをほぼ確実に作成します。これらの相対的な暗号強度の評価と比較は困難であり、簡単に自動化されることはなく、このドキュメントの範囲外です。実装者と管理者は、これらのトレードオフを理解する必要があります。セキュリティチャネルとアプリケーションレイヤー認証フレームワークとメカニズムを保護するためのインターフェイスにより、セキュリティプロファイルの概念が提供されるため、アプリケーションは必要なセキュリティプロファイルに合わせるには弱すぎるチャネルへのセッション保護の委任を回避できます。
Channel binding makes "anonymous" channels (where neither end-point is strongly authenticated to the other) useful. Implementors should avoid making it easy to use such channels without channel binding.
チャネルバインディングにより、「匿名」チャネル（どちらのエンドポイントも他のエンドポイントに強く認証されていない）を便利にします。実装者は、チャネルバインディングなしでそのようなチャネルを簡単に使用できるようにすることを避ける必要があります。
The security of channel binding depends on the security of the channels, the construction of their channel bindings, and the security of the authentication mechanism used by the application and its channel binding method.
チャネル結合のセキュリティは、チャネルのセキュリティ、チャネルバインディングの構築、およびアプリケーションとそのチャネル結合方法で使用される認証メカニズムのセキュリティに依存します。
Channel bindings should be constructed in such a way that revealing the channel bindings of a channel to third parties does not weaken the security of the channel. However, for end-point channel bindings disclosure of the channel bindings may disclose the identities of the peers.
チャネルバインディングは、チャネルのチャネルバインディングをサードパーティへのバインディングを明らかにすることで、チャネルのセキュリティを弱めないように構築する必要があります。ただし、チャネルバインディングのエンドポイントチャネルバインディングの開示については、ピアのアイデンティティが開示される場合があります。
Application developers may be tempted to use non-unique channel bindings for fast re-authentication following channel re-establishment. Care must be taken to avoid the possibility of attacks on multi-user systems.
アプリケーション開発者は、チャネルの再確立後の迅速な再認証のために、非ユニークチャネルバインディングを使用するように誘惑される場合があります。マルチユーザーシステムへの攻撃の可能性を避けるために注意する必要があります。
Consider a user multiplexing protocol like NFSv4 using channel binding to IPsec on a multi-user client. If another user can connect directly to port 2049 (NFS) on some server using IPsec and merely assert RPCSEC_GSS credential handles, then this user will be able to impersonate any user authenticated by the client to the server. This is because the new connection will have the same channel bindings as the NFS client's! To prevent this, the server must require that at least a host-based client principal, and perhaps all the client's user principals, re-authenticate and perform channel binding before the server will allow the clients to assert RPCSEC_GSS context handles. Alternatively, the protocol could require a) that secure channels provide confidentiality protection and b) that fast re-authentication cookies be difficult to guess (e.g., large numbers selected randomly).
マルチユーザークライアントのIPSECへのチャネルバインディングを使用して、NFSV4のようなユーザーマルチプレックスプロトコルを検討してください。別のユーザーがIPSECを使用して一部のサーバー上のポート2049（NFS）に直接接続し、RPCSEC_GSS資格情報を単にアサートできる場合、このユーザーはクライアントによって認証されたユーザーにサーバーになりすまします。これは、新しい接続にNFSクライアントと同じチャネルバインディングがあるためです！これを防ぐために、サーバーは、少なくともホストベースのクライアントプリンシパル、およびおそらくすべてのクライアントのユーザープリンシパルが、サーバーがRPCSEC_GSSコンテキストハンドルを主張する前にチャネルバインディングを再認証および実行することを要求する必要があります。あるいは、プロトコルでは、a）安全なチャネルが機密保護を提供することを要求する場合があります。b）高速な再認証Cookieを推測するのが難しい（たとえば、ランダムに選択された大量）。
In other contexts there may not be such problems, for example, in the case of application protocols that don't multiplex users over a single channel and where confidentiality protection is always used in the secure channel.
他のコンテキストでは、たとえば、単一のチャネルでユーザーをマルチプレックスしないアプリケーションプロトコルの場合、安全なチャネルで常に機密性保護が使用されるアプリケーションプロトコルの場合、そのような問題はないかもしれません。
[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月。
[BTNS-AS] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Work in Progress, October 2007.
[BTNS-AS] Touch、J.、Black、D。、およびY. Wang、「Better than Nothing Security（BTNS）のための問題と適用声明」、2007年10月の作業。
[BTNS-CORE] Richardson, M. and N. Williams, "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Work in Progress, September 2007.
[BTNS-CORE]リチャードソン、M。およびN.ウィリアムズ、「より良いセキュリティ：IPSECの認知度のないモード」、2007年9月、作業進行中。
[BTNS-IPSEC] Richardson, M. and B. Sommerfeld, "Requirements for an IPsec API", Work in Progress, April 2006.
[BTNS-IPSEC] Richardson、M.およびB. Sommerfeld、「IPSEC APIの要件」、2006年4月、進行中の作業。
[CONN-LATCH] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, September 2007.
[conn-latch]ウィリアムズ、N。、「Ipsecチャネル：接続ラッチング」、2007年9月、作業中の作業。
[Lampson91] Lampson, B., Abadi, M., Burrows, M., and E. Wobber, "Authentication in Distributed Systems: Theory and Practive", October 1991.
[Lampson91] Lampson、B.、Abadi、M.、Burrows、M。、およびE. Wobber、「分散システムの認証：理論と実践」、1991年10月。
[NFS-DDP] Callaghan, B. and T. Talpey, "NFS Direct Data Placement", Work in Progress, July 2007.
[NFS-DDP] Callaghan、B。およびT. Talpey、「NFS Direct Data Placement」、2007年7月の作業。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964] Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[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月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744] Wray、J。、「ジェネリックセキュリティサービスAPIバージョン2：C-Bindings」、RFC 2744、2000年1月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R。およびS. Lawrence、「HTTP/1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 3530、2003年4月。
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、「インターネットスモールコンピューターシステムインターフェイス（ISCSI）」、RFC 3720、2004年4月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network認証サービス（V5）」、RFC 4120、2005年7月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4462] Hutzelman、J.、Salowey、J.、Galbraith、J.、およびV. Welch、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）認証とセキュアシェル（SSH）プロトコルの主要な交換」、RFC4462、2006年5月。
[RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[RFC5046] Ko、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、Shah、H。、およびP. Thaler、 "インターネットスモールコンピューターシステムインターフェイス（ISCSI）リモートダイレクトメモリアクセスの拡張（RDMA）」、RFC 5046、2007年10月。
[SASL-GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Work in Progress, October 2007.
[SASL-GS2] Josefsson、S。、「SASLにおけるGSS-APIメカニズムの使用：GS2メカニズムファミリー」、2007年10月、進行中の作業。
[SSH-CB] Williams, N., "Channel Binding Identifiers for Secure Shell Channels", Work in Progress, November 2007.
[SSH-CB]ウィリアムズ、N。、「セキュアシェルチャネルのチャネル結合識別子」、2007年11月、進行中の作業。
[STACKABLE] Williams, N., "Stackable Generic Security Service Pseudo-Mechanisms", Work in Progress, June 2006.
[積み重ね可能]ウィリアムズ、N。、「積み重ね可能なジェネリックセキュリティサービスの疑似機械」、2006年6月、進行中の作業。
[TLS-CB] Altman, J. and N. Williams, "Unique Channel Bindings for TLS", Work in Progress, November 2007.
[TLS-CB] Altman、J。およびN. Williams、「TLS用のユニークなチャネルバインディング」、2007年11月、Work in Progress。
Thanks to Mike Eisler for his work on the Channel Conjunction Mechanism document and for bringing the problem to a head, Sam Hartman for pointing out that channel binding provides a general solution to the channel binding problem, and Jeff Altman for his suggestion of using the TLS finished messages as the TLS channel bindings. Also, thanks to Bill Sommerfeld, Radia Perlman, Simon Josefsson, Joe Salowey, Eric Rescorla, Michael Richardson, Bernard Aboba, Tom Petch, Mark Brown, and many others.
チャネル接続メカニズムドキュメントでの研究と問題を頭に導いてくれたマイクアイスラーに感謝します。サムハートマンは、チャネル結合がチャネル結合問題の一般的なソリューションを提供し、ジェフアルトマンがTLSを使用することを提案してくれたことを指摘してくれました。TLSチャネルバインディングとしてのメッセージが完成しました。また、ビル・ソマーフェルド、ラディア・ペルマン、サイモン・ジョセフソン、ジョー・サロウィー、エリック・レスコルラ、マイケル・リチャードソン、バーナード・アボバ、トム・ペッチ、マーク・ブラウンなどのおかげで。
Author's Address
著者の連絡先
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct. Austin, TX 78727 US
ニコラス・ウィリアムズサンマイクロシステムズ5300リアタトレースCT。テキサス州オースティン78727 US
EMail: Nicolas.Williams@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。