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.
結合チャネルの概念は、アプリケーションが下層にチャネルに上位レイヤでの認証を結合することによって一つのネットワーク層でのセキュアチャネルの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アーキテクチャは、特に、アプリケーション内のセキュリティメカニズムとして使用するように適していませんクライアントとしてのユーザを持つアプリケーション。両方の層のセキュリティを組み合わせる方法は、従って、魅力的です。 man-in-the-middleの脆弱性を回避し、シームレスな方法で統合するためのメカニズムを可能にするように - 安全に行われるために、これを有効にするには、それはメカニズム一緒に「バインド」することが必要です。これは、「チャネルバインディング」の目的です。
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認証を結合するために意図されたチャネルバインディング施設があり、汎用セキュリティサービスアプリケーションプログラムインタフェース（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]、独自の認証メカニズム（ケルベロスVの例えば、キー配布センター（KDC）の交流を提供してもプロトコルなどの他のセキュリティフレームワークを利用するアプリケーションによって結合チャネルの使用を想定します[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.
セッション保護のように委任を実現するために解決するための重要なセキュリティ問題は、セッション保護がされている下位ネットワーク層で、ビューのポイントアプリケーションから、何のman-in-the-middle（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攻撃が効果に特に難しいように見える場合でも、攻撃はIPsecなどの技術を有効に活用することができるようにするため、特定の用途のために防止しなければならない[RFC2401] [RFC4301]またはTLSとHTTP [RFC4346]特定のコンテキスト（例えば、中話をするは認証がない場合、または信頼アンカーの一つのノードのセットは、そのピアを認証することができると信じているにはあまりにも弱い場合）。 （アプリケーション層認証と組み合わせるとさらに、彼らは何の役に立つのエンドポイントの認証を提供しないので、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]は（例えば、ケルベロス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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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つのエンドポイント間の接続のシーケンスを、データの機密性は、それを介して交換しました。攻撃者が、チャネルのセッションキーをcryptanalyzeすることができ、たとえば、チャネルがセキュリティで保護されていない場合は - 私たちは、チャネルが安全であることを前提としています。
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チャネルバインディング：なしのman-in-the-middleは、一つのネットワーク層で認証されているが、下位ネットワーク層でセキュアチャネルを使用している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.
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.
上記に定義された用語は、長年にわたって使用されてきたし、以下に記載されているもの、少なくともいくつかの状況では、意味すると解釈されてきました。一般的にチャンネルの名前を指します - だけ一文字の違い - 残念ながら、これは「チャネル結合」は、時々チャンネルの名前、および「チャネルバインディング」に、チャネル結合操作を参照してできることを意味します。
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]は、ここでdecribedものと類似しているように見えることが施設を参照するために「結合チャネル」を使用し、それは、実際には、全く異なっていることに留意されたいです。モードの詳細については、セクション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）、セキュリティ機構（たとえば、ケルベロス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を認証するために、他の、または両方のアプリケーション・ピア（チャネルの各端部に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）は（別名「オーセンティケータ」）ピア（クライアント）に嘘をつくことができる1つとして、問題を説明し、（間違ったの認可決定を行うために、ピアを引き起こすなど、としてどのようなトラフィックのかもしれないと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「は、EAPメソッド内で交換されたものに対して、アウトオブバンド機構を介してオーセンティケータによって提供されるチャネル特性を一致させることができる」ように「このようなエンドポイント識別子のようなチャネル特性の保護された交換」を要求します。
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側のアイデンティティ、チャネル自体のもセキュリティプロパティで、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検出対認証目的のために下層チャネル特性の認証）があります。
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).
他の人がいない場合があるいくつかの認証フレームワークおよび/または機構は、SASLとして（但し、進行中の作業は、SASLを支持する結合チャネルを追加して）、そのようなGSS-APIおよびいくつかのGSS-API機構として、結合チャネルを提供します。セマンティクスは、結合が発生方法ネゴシエーションに対して、チャネル結合不良の取り扱い（下記参照）に応じて変化してもよいです。
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メカニズムはこの機能をサポートするために必要とされていないもののGSS-API [RFC2743]は、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の擬似メカニズムを設計することが可能です。 SSHv2のプロトコル[RFC4462]を行うように、例えば、NFSv4の[RFC3530]は、独自のGSS-API機構のネゴシエーションを提供します。このような擬似メカニズムは、[STACKABLE]を参照して、別々に提案されています。
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はおそらくチャネル結合の失敗の取り扱い（すなわち、MITMがあるかもしれない時に）そのチャネル結合成功/失敗だけSASLセキュリティ層の交渉に影響を与えるで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.
次のテキストは規範的ではなく、1が安全なチャンネルの様々なタイプのチャネルバインディングを構築する方法を示したものです。
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は、単にサーバによって割り当てられます。任意のMITMは、サーバーを装った、単にMITMに割り当てられたサーバーとして被害者のクライアントに同じセッションIDを割り当てることができますので、このようにして、TLSセッション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.
次のテキストは規範的ではなく、1が安全なチャンネルの様々なタイプのチャネルバインディングを構築する方法を示したものです。
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].
*ゼロコピーの受信ネットワークインタフェースコントローラ（NIC）をサポート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.
* iSCSIのリモートダイレクトメモリアクセス（RDMA）と[RFC3720] [RFC5046]。暗号セッションの保護は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。プロキシを含む状況では、ユーザーが最後のクライアント側プロキシと最初のサーバ側プロキシ（「コンセントレータ」）との間にTLSチャネルに認証をバインドすることもできます。公共のインターネット上の保護をの前述されていないが、TLSへの結合チャネルと相まって、プロキシを可能にするであろうことを、HTTP層でのエンドツーエンド認証のための選択肢を広げるための継続的な仕事があります。
o Reducing the number of live cryptographic contexts that an application must maintain:
アプリケーションは維持しなければならないライブ暗号コンテキストの数を減らします○：
* 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のはない）接続ごとの多くの暗号化セッション・コンテキストを維持することができます。それは希望よりも、（すなわち、TCP / IP、ESP / AH、およびDDP）（IPsecの）は、ネットワークスタックダウン暗号化セッションの保護を押すと、まだ他の操作をオフロードNICを生み出すことができるように単純であると考えられていますアプリケーション層での一般的な用途で使用されている多くのセッションの暗号化保護プロトコルの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.
IPsecが使用されているアプリケーションは、独自のセキュアなチャネルを提供する場合に、アプリケーション・データの二重の保護を回避することによってOパフォーマンスの向上。
o Performance improvements by leveraging hardware-accelerated IPsec.
ハードウェアアクセラレーションのIPsecを活用することにより、Oパフォーマンスの向上。
o Performance improvements by allowing RDDP hardware offloading to be integrated with IPsec hardware acceleration.
可能RDDPのハードウェアオフロードすることによりOパフォーマンスの向上は、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.
o Latency improvements for applications that multiplex multiple users onto a single channel, such as NFS with RPCSEC_GSS [RFC2203].
RPCSEC_GSS [RFC2203]とNFSなどの単一のチャネルに複数のユーザを多重化アプリケーション、の待ち時間改善O。
Delegation of session cryptographic protection to IPsec requires features not yet specified. There is ongoing work to specify:
IPsecのにセッション暗号保護の代表団は、まだ指定されていない機能が必要です。指定する進行中の作業があります：
o IPsec channels [CONN-LATCH];
IPsecのチャンネルO [CONN-LATCH]。
o Application programming interfaces (APIs) related to IPsec channels [BTNS-IPSEC];
IPsecのチャンネル[BTNS-IPSEC]に関連Oアプリケーション・プログラミング・インターフェース（API）。
o Channel bindings for IPsec channels;
IPsecのチャンネルのOチャネルバインディング。
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.
十分でしょう - US-ASCII文字の英数字で構成される任意の文字列、ピリオド（「 『）、およびダッシュ（』」）：なし命名チャネルバインディングのための規則はありません。
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チャネルバインディングタイプ：（「ユニーク」または「エンドポイント」の一つ）
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意図している用法：（COMMONの1、限られた使用、またはOBSOLETE）
o Person and email address to contact for further information:
O詳細のために連絡する人とEメールアドレス：
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.
そして、<iana@iana.org>で<channel-binding@ietf.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 Considerations部などの任意の提供技術仕様の関連する側面の考慮を伴ってもよいです。ただし、この口コミは狭く任意の提供、技術仕様の全体的な健全性の要求された登録とないの妥当性に焦点を当てています。
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は<iana@iana.org>にメールを送信することによって、チャネルバインディングタイプ登録自体に自分のコメントを添付することを要求することができます。に
IANA's sole discretion, IANA may attach the comment to the channel bindings registration.
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.
チャネルバインディングの登録が削除されないことがあります。もはや使用するのに適したと考えられているメカニズムは、彼らの「使用目的」欄への変更によってOBSOLETEと宣言することができます。このようなチャネルバインディングは明らかに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.
別の層からのセッション保護を委任すると、1はほぼ確実な他で使用される可能性がありますよりも、一つの層に弱い暗号モードを使用するなど、いくつかのセッションセキュリティのトレードオフを、作ることになります。評価し、これらの相対的な暗号強みの比較は困難であり、容易に自動化、およびこのドキュメントのための範囲の外に遠く離れていることはできません。実装者と管理者は、これらのトレードオフを理解する必要があります。アプリケーションは、必要なセキュリティプロファイルに合わせて弱すぎるチャンネルにセッション保護の委任を避けることができるようにチャンネルとアプリケーション層認証フレームワークとメカニズムを確保するためのインタフェースは、セキュリティプロファイルの一部概念を提供することができます。
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）高速再認証クッキーを推測することが困難であること（例えば、多数）がランダムに選択されました。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]タッチ、J.、ブラック、D.、およびY.王、 "問題とベター・ザンナッシングセキュリティ（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]リチャードソン、M.とB.ゾンマーフェルト、進歩、2006年4月に、ワーク "のIPsec APIの要件"。
[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.、アバディ、M.、バローズ、M。、及びE. Wobber、 "分散システムにおける認証：理論とpractiveの"、1991年10月。
[NFS-DDP] Callaghan, B. and T. Talpey, "NFS Direct Data Placement", Work in Progress, July 2007.
[NFS-DDP]キャラハン、B.およびT. Talpey、 "NFS直接データ配置"、進歩、2007年7月の作業。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]リン、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]アイスラー、M.、チウ、A.、およびL.リン、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1997年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744]レイ、J.、 "ジェネリックセキュリティサービスAPIバージョン2：C-バインディング"、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.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、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.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、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.、メタ、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.、ブルンク、L.、Vollbrecht、J.、カールソン、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]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（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、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（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.、ガルブレイス、J.、およびV.ウェルチ、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース（GSS-API）の認証とセキュアシェル（SSH）プロトコルのための鍵交換"、RFC 4462、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]コ、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターラー、「インターネット小型コンピュータシステムインタフェース（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.、 "Secure Shellのチャンネルのためのチャンネルバインディング識別子"、進歩、2007年11月に作業。
[STACKABLE] Williams, N., "Stackable Generic Security Service Pseudo-Mechanisms", Work in Progress, June 2006.
[STACKABLE]ウィリアムズ、N.、「スタッカブルジェネリックセキュリティサービス擬似メカニズム」、進歩、2006年6月に作業。
[TLS-CB] Altman, J. and N. Williams, "Unique Channel Bindings for TLS", Work in Progress, November 2007.
[TLS-CB]アルトマン、J.とN.ウィリアムズ、 "TLSのためのユニークなチャネルバインディング"、進歩、2007年11月に作業。
Appendix A. Acknowledgments
付録A.謝辞
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チャネルバインディングとメッセージを終えました。また、ビルゾンマーフェルト、ラディア・パールマン、サイモンJosefsson氏、ジョー・Salowey、エリックレスコラ、マイケル・リチャードソン、バーナードAboba、トム・ペッチ、マーク・ブラウン、そして他の多くのおかげで。
Author's Address
著者のアドレス
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct. Austin, TX 78727 US
ニコラス・ウィリアムズSun Microsystemsの5300 RiataトレースのCt。オースティン、TX 78727米国
EMail: Nicolas.Williams@sun.com
メールアドレス：Nicolas.Williams@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。