RFC5056 日本語訳
5056 On the Use of Channel Bindings to Secure Channels. N. Williams. November 2007. (Format: TXT=49995 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Williams Request for Comments: 5056 Sun Category: Standards Track November 2007
コメントを求めるワーキンググループN.ウィリアムズ要求をネットワークでつないでください: 5056年のSunカテゴリ: 標準化過程2007年11月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントは、チャンネルを固定するためにチャンネル結合の概念について議論して、正式にします。
Williams Standards Track [Page 1] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[1ページ]。
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
1. 序論…3 1.1. このドキュメントで中古のコンベンション…4 2. 定義…4 2.1. チャンネル結合の特性…6 2.2. EAPは結合を向けます…9 3. 認証とチャンネルの拘束力がある意味論…10 3.1. GSS-APIとチャンネル結合…10 3.2. SASLとチャンネル結合…11 4. チャンネル結合仕様…11 4.1. ユニークなチャンネル結合に関する例…11 4.2. エンドポイントに関する例は結合を向けます…12 5. チャンネル結合の用途…12 6. チャンネルがチャンネルを固定するために付く利益…14 7. IANA問題…15 7.1. 登録手順…15 7.2. チャンネル結合登録証明書のコメント…16 7.3. コントロールを変えてください…17 8. セキュリティ問題…17 8.1. 非ユニークなチャンネル結合とチャンネルの拘束力がある再建…18 9. 参照…19 9.1. 標準の参照…19 9.2. 有益な参照…19 付録A.承認…22
Williams Standards Track [Page 2] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[2ページ]。
1. Introduction
1. 序論
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.
「チャンネル結合」という本書では使用される用語はGeneric Security Service Application Program Interface(GSS-API)から[RFC2743]を引き出します。(チャンネルはそれで、拘束力があるGSS-API認証が下側のネットワーク層でチャンネルを固定するつもりであった施設を縛ります)。 十分施設を縛る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アプリケーションで全く制限しません。 私たちは他のセキュリティフレームワークを利用するアプリケーションでチャンネル結合の使用を思い描きます、Simple Authenticationや、Security Layer(SASL)[RFC4422]やそれら自身の認証機構を提供するプロトコル(例えば、ケルベロスV[RFC4120]のKey Distributionセンター(KDC)交換)のようにさえ。 また、私たちはセキュリティプロトコルの分析におけるチャンネル結合の概念の使用を思い描きます。
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はチャンネル結合のいくつかの意図している用途について説明します。 また、いくつかのアプリケーションが活動的な暗号の状態の量を減少させることによって、利益を得るかもしれません、その結果、潜在でそのような状態としたがって、セキュリティの影響にアクセスする際に経費を削減します。
Williams Standards Track [Page 3] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[3ページ]。
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攻撃が特に効果に難しく見えても、あるアプリケーションが、ある文脈のTLS[RFC4346]と共にIPsec[RFC2401][RFC4301]かHTTPなどの技術をうまく利用することができる(例えば、いつ、話す認証が全くないか、そして、または1つのノードの信頼アンカーのセットはいつ同輩を認証できると信じることができないくらい苦手ですか)ように、攻撃を防がなければなりません。 さらに、応用層認証に結合されると、どんな役に立つエンドポイント認証も提供しないのでMITM攻撃に影響されやすい安全なチャンネルは役に立ちます(さもなければ、それらはいくらかだけ「ないよりまし」です--Better Than Nothing Security(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.
例えば、インターネットSmallコンピュータシステムズInterface(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.
このドキュメントはソリューションについて説明します: アプリケーションで認証を縛る「チャンネル結合」の使用は、ネットワークスタックの下層でセッションを保証するために層にされます。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Definitions
2. 定義
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することができるなら、チャンネルは安全ではありません。
Williams Standards Track [Page 4] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[4ページ]。
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.
一般に、より高いネットワーク層にチャンネルの両端で同じになるようにこのデータを示すことができるなら2つの間には、MITMsが全くないようにエンドポイントのチャンネル、1または両方を「命名する」いくつかのデータがそのより高いネットワーク層を終わりで指します。 今期は名詞として使用されます。
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;
aでチャンネルを任命するチャンネル結合が、暗号で方法を保証して、中で唯一調節されます。
+ 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]ために個人的な暗号化か署名などのオブジェクトにキー、または確立した安全なチャンネルを引き起こす暗号の操作。 例えば、(PKIX)が証明するX.509 Certificatesのための公開鍵暗号基盤は、前述の秘密鍵の所有者が証明書によって指定されたユーザ(または、他の実体)を代表して行動できるように、証明書の発行人の信頼ドメインで元本の名前に秘密鍵を縛ります。
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
チャンネル結合の応用における「暗号の結合」の多くのインスタンスがあるかもしれないことに注意してください。 応用層で主体を認証する資格証明書はそれらの主体のアイデンティティの個人的であるか秘密のキーを縛ります、前述のキーが代弁するそのようなもの
Williams Standards Track [Page 5] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[5ページ]。
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.
上で定義された用語は、何年間も使用中であり、少なくともいくつかの文脈で何が以下に述べられているかを意味するにはかかりました。 残念ながら、時々aの名前に、精神を集中して、これは、「チャンネル結合」が操作を縛るチャンネルを示すことができることを意味します、そして、一般に、「チャンネル結合」(ある手紙だけの違い)はチャンネルの名前を呼びます。
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を見てください。
2.1. Properties of Channel Binding
2.1. チャンネル結合の特性
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-アピ、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.
* アプリケーションで使用される認証プロトコルがチャンネルに結合をサポートするなら、アプリケーションSHOULDはそれを使用します。
* 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.
* 認証プロトコルが操作を縛るチャンネルを支えませんが、「セキュリティ層」に少なくとも保全保護を提供するなら、アプリケーションは、チャンネル結合、またはそれの暗号のハッシュを交換するのに認証プロトコルの保全保護施設を使用しなければなりません。
Williams Standards Track [Page 6] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[6ページ]。
* 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 どんな安全なチャンネルも単一の、そして、正準な八重奏に備えなければならないので、チャンネル結合の仕様はチャンネル結合のコード化を結びます。 このフレームワークの下では、チャンネル結合はコロン(ASCII0x3A)があとに続いたユニークな接頭語を縛るチャンネルから始まらなければなりません。
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)のように。 そのような場合、アプリケーションは、チャンネルがそのような識別子の適切な認証を提供するのを確実にしなければなりません(例えば、証明書合法化方針と信頼が使用されていた状態で投錨されるのがチャンネルでアプリケーションの要件を満たします)。 この要件を扱うことにおける実装苦労を避けるのに、アプリケーションSHOULDはエンドポイントチャンネル結合として暗号の量を使用します、証明書対象公開鍵などのように。
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 制限されたチャンネルが秘密性保護を提供しないとき、秘密性保護を望んでいるアプリケーションは秘密性保護に応用層セッション保護サービスを利用しなければなりません。
Williams Standards Track [Page 7] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[7ページ]。
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 エンドポイントが重要であるところでエンドポイントチャンネル結合はSHOULD NOTを命名します。チャンネルが秘密性保護を提供しないで、プライバシー保護が望まれていたら、使用されてください。 あるいはまた、そのようなチャンネル結合がSHOULDであるとエクスポートするチャンネルがダイジェストの使用に備えます、そして、SHOULD NOTはその結果新しいダイジェスト/ハッシュ機敏さ問題を紹介します。
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 セキュリティー対策はチャンネル結合の保全で保護されたダイジェストを交換するかもしれません。 そのようなメカニズムSHOULDはハッシュ/ダイジェストの機敏さに備えます。
o A security mechanism MAY use channel bindings in key exchange,
authentication, or key derivation, prior to the exchange of
"authenticator" messages.
o セキュリティー対策は主要な交換、認証、または主要な派生におけるチャンネル結合を使用するかもしれません、「固有識別文字」メッセージの交換の前に。
Williams Standards Track [Page 8] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[8ページ]。
2.2. EAP Channel Binding
2.2. EAPチャンネル結合
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).
を通して値にたとえることができる終点識別子などの保全で保護されたチャンネルの特性のEAPメソッドの中のコミュニケーションが交信した、バンドメカニズム(AAAか下位層プロトコルを通したなど)から。
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はNetwork Access Server(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が「aは終点識別子などのチャンネルの特性の交換を保護した」ために電話をするので、「固有識別文字によって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検出の認証)の基本的な違いがあります。
Williams Standards Track [Page 9] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[9ページ]。
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があります。
3. Authentication and Channel Binding Semantics
3. 認証とチャンネルの拘束力がある意味論
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).
適当なチャンネル拘束力があるところには、施設が提供されないで、アプリケーション・プロトコルはチャンネル結合の別々の、そして、保護された交換を含むかもしれません。 これをするために、応用層認証サービスはメッセージ保護サービス(少なくとも保全保護)を提供しなければなりません。
3.1. The GSS-API and Channel Binding
3.1. GSS-APIとチャンネル結合
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]はそれ自身のGSS-APIメカニズム交渉を提供します、SSHv2プロトコル[RFC4462]のように。 [STACKABLE]は、そのような疑似メカニズムが別々に提案されているのを見ます。
Williams Standards Track [Page 10] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[10ページ]。
3.2. SASL and Channel Binding
3.2. SASLとチャンネル結合
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は失敗を縛るチャンネルの取り扱いにおけるGSS-APIと成功/失敗を縛るチャンネルがSASLセキュリティ層の交渉に影響するだけであるという点においておそらく異なるでしょう(すなわち、いつ、MITMがあるかもしれませんか)。 すなわち、チャンネル結合が成功すると、SASLはセキュリティ層を全く選択するはずがありません、SASL認証が制限されている安全なチャンネルにセッションの暗号の保護を任せて。
4. Channel Bindings Specifications
4. チャンネル結合仕様
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. | +--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+ | 安全なチャンネル| 参照| | タイプ| | +--------------------+----------------------------------------------+ | SSHv2| [セキュアシェル (SSH)-CB]| | | | | TLS| [TLS-CB]| | | | | IPsec| IPsecチャンネルへの仕様が全くありません。| | | 結合、まだ、しかし、IETF Better Than| | | 何でもないSecurity(BTNS)WGが働いている| | | IPsecチャンネル、およびことによるとIPsecを指定してください。| | | チャンネル結合。 | +--------------------+----------------------------------------------+
4.1. Examples of Unique Channel Bindings
4.1. ユニークなチャンネル結合に関する例
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,
TLS[RFC4346]セッションIDはサーバによって単に割り当てられます。そういうものとして、チャンネルとして役に立つ必要な特性は、どんなMITMであっても、ポーズをとるので、サーバとしてTLSセッションIDで固まりません。
Williams Standards Track [Page 11] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[11ページ]。
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.
単に、MITMに割り当てられたサーバとして犠牲者クライアントへのIDを同じセッションに割り当てることができます。 代わりに初期、unencrypted TLSの終わっているメッセージ(クライアントのもの、サーバのもの、または両方)は、それらがすべての握手の材料に主要で、適用されたセッションで合わせられたTLS擬似ランダム機能の出力であるので、十分です。
4.2. Examples of End-Point Channel Bindings
4.2. エンドポイントチャンネル結合に関する例
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ホスト公開鍵は十分であるべきです。 長さとして、クライアントはサーバが使用した個人的なホストキーに対応するホスト公開鍵を観測して、次に、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暗号スイートはサーバ証明書にかかわります。 したがって、チャンネル結合のこの工事に関するユーティリティはサーバ証明書が一般的に使用されるシナリオに制限されます。
5. Uses of Channel Binding
5. チャンネル結合の用途
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をサポートする無コピーレセプションのためのRemote Direct Data Placement(RDDP)[NFS-DDP]とNFSv4[RFC3530]。 Encapsulating Security有効搭載量(超能力)[RFC4303]/認証Headers(AHs)[RFC4302]へ暗号のセッション保護を代表として派遣するでしょう。
* iSCSI [RFC3720] with Remote Direct Memory Access (RDMA)
[RFC5046]. Cryptographic session protection would be delegated
to ESP/AH.
* リモートダイレクトメモリアクセス(RDMA)[RFC5046]があるiSCSI[RFC3720]。 暗号のセッション保護を超能力/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
* TLS[RFC2817][RFC2818]があるHTTP。 プロキシにかかわる状況で、ユーザは最後のクライアントサイドプロキシと最初サーバ側の間のTLSチャンネルに認証を縛りたがっているかもしれません。
Williams Standards Track [Page 12] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[12ページ]。
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.
プロキシ(「集中装置」)。 終わりから終わりへの認証のための選択のセットを膨張させるように、進行中の仕事が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]は複数のユーザを個々の接続に多重送信します。 各ユーザは別々に認証されます、そして、ユーザの遠隔手続き呼び出し(RPCs)は1ユーザあたりの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を使用したがっているアプリケーションは根回しされたメモリ・バッファの中へアプリケーションデータの配送を積み下ろすためにNICsに解釈されたネットワーク層を使用するかもしれません。 アプリケーションデータが無コピーレセプション意味論を得るためにcleartextにこの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.
利用可能な応用層暗号のセッション保護プロトコルの多数があります。 NICsがそのような多くのプロトコルをサポートするはずであると予想するのは妥当ではありません。 さらに、いくつかのアプリケーション・プロトコルが多くの暗号のセッション文脈を維持するかもしれない、-、接続(例えば、NFSv4はそうします)。 ネットワークスタック(IPsecへの)まで暗号のセッション保護を押し下げますが、それより他の操作(すなわち、TCP/IP、超能力/AH、およびDDP)を積み下ろすNICsは生産できるのがさらに簡単であることが、NICでサポートを加える応用層の一般的なアプリケーションで使用中の多くのセッション暗号の保護プロトコルのためにことであると思われます。
Williams Standards Track [Page 13] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[13ページ]。
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 |
+---------------------+
| ... |
+---------------------+
+---------------------+ | 応用層| <、-、--+ | | <、-+ | cleartext、親類+で---------------------+ | | 互いに。 | RDDP| <、-、--+ +---------------------+ | | TCP/SCTP| <、-+ +---------------------+ | 装置層のチャンネル結合| 超能力/、ああ。| <、-+ IPsec+への認証---------------------+ | IP| +---------------------+ | ... | +---------------------+
6. Benefits of Channel Binding to Secure Channels
6. チャンネルがチャンネルを固定するために付く利益
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に動かされます。(IPsecはRDDPの下で層にされます)。 それで、RDDPは、アプリケーション・プロトコルがcleartextに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は[コン-LATCH]にチャネルを開設します。
Williams Standards Track [Page 14] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[14ページ]。
o Application programming interfaces (APIs) related to IPsec
channels [BTNS-IPSEC];
o アプリケーションプログラミングインターフェース(API)はIPsecチャンネル[BTNS-IPSEC]に関連しました。
o Channel bindings for IPsec channels;
o IPsecチャンネルのためのチャンネル結合。
o Low infrastructure IPsec authentication [BTNS-CORE].
o 低いインフラストラクチャIPsec認証[BTNS-CORE]。
7. IANA Considerations
7. IANA問題
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英数字で構成された、以上、('、'、)、そして、('--')が満足させるダッシュ。
The procedure detailed in Section 7.1 is to be used for registration of a value naming a specific individual mechanism.
セクション7.1で詳細な手順は特定の個々のメカニズムを命名する価値の登録に使用されることです。
7.1. Registration Procedure
7.1. 登録手順
Registration of a new channel binding requires expert review as defined in BCP 26 [RFC2434].
新しいチャンネル結合の登録はBCP26[RFC2434]で定義されるように専門のレビューを必要とします。
Registration of a channel binding is requested by filling in the following template:
チャンネル結合の登録は以下のテンプレートに記入することによって、要求されています:
o Subject: Registration of channel binding X
o Subject: チャンネル結合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 記述、(任意である、aであるなら、仕様を与えます; 広められた仕様が全く指定されないなら必要である、)、:
Williams Standards Track [Page 15] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[15ページ]。
o Intended usage: (one of COMMON, LIMITED USE, or OBSOLETE)
o 意図している用法: (1つ、コモン使用、または時代遅れで制限されて、
o Person and email address to contact for further information:
o 詳細のために連絡する人とEメールアドレス:
o Owner/Change controller name and email address:
o 所有者/変化コントローラ名とEメールアドレス:
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.
電子メール to <channel-binding@ietf.org を通してそれを送る、gt;、(公共のメーリングリスト)と炭素のコピーしているIANA at <iana@iana.org 、gt。 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にメーリングリストを掲示することによってコメントに請求することによって共同体レビューを追求するよう奨励されます。
7.2. Comments on Channel Bindings Registrations
7.2. チャンネル結合登録証明書のコメント
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
コメントのSubmittersが、所有者に連絡する合理的な試みの後にメール to <iana@iana.org を送ることによってタイプ登録自体を縛るチャンネルに彼らのコメントに愛着するようIANAに要求するかもしれない、gt。 at
Williams Standards Track [Page 16] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[16ページ]。
IANA's sole discretion, IANA may attach the comment to the channel bindings registration.
IANAの唯一の思慮深さであり、IANAはチャンネル結合登録にコメントを付けるかもしれません。
7.3. Change Control
7.3. 変化コントロール
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標準化過程の上にあるオール・チャンネル結合の所有者であると考えられます。
8. Security Considerations
8. セキュリティ問題
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つの層から別の層までのセッション保護を代表として派遣するとき、1つはほぼ確実にいくつかのセッションセキュリティトレードオフをするでしょう、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.
チャンネル結合で、「匿名」のチャンネル(どちらのエンドポイントも強くもう片方に認証されないところ)は役に立つようになります。 作成者は、チャンネル結合なしでそのようなチャンネルを使用するのを簡単にするのを避けるべきです。
Williams Standards Track [Page 17] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[17ページ]。
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.
チャンネル結合は第三者のチャンネルのチャンネル結合を明らかにするのがチャンネルのセキュリティを弱めないような方法で構成されるべきです。 しかしながら、チャンネルのエンドポイントチャンネル結合公開のために、結合は同輩のアイデンティティを明らかにするかもしれません。
8.1. Non-Unique Channel Bindings and Channel Binding Re-Establishment
8.1. 非ユニークなチャンネル結合とチャンネルの拘束力がある再建
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のようなユーザマルチプレクシングプロトコルを考えてください。 別のユーザが、2049(NFS)を何らかのサーバに移植するためにIPsecを使用することで直接接続して、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.
他の文脈には、例えば単独のチャンネルの上にユーザを多重送信しないで、秘密性保護が安全なチャンネルでいつも使用されるアプリケーション・プロトコルの場合にそのような問題がないかもしれません。
Williams Standards Track [Page 18] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[18ページ]。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[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、-、]、接触、J.、黒、D.、およびY.ワング、「ないよりましなセキュリティ(BTNS)のための問題と適用性証明」は進行中(10月2007)で働いています。
[BTNS-CORE] Richardson, M. and N. Williams, "Better-Than-Nothing-
Security: An Unauthenticated Mode of IPsec", Work in
Progress, September 2007.
[BTNS-コア] リチャードソン、M.、およびN.ウィリアムズ、「良さ、-、-、無、-、セキュリティ:、」 「IPsecのUnauthenticatedモード」、処理中の作業、2007年9月。
[BTNS-IPSEC] Richardson, M. and B. Sommerfeld, "Requirements for an
IPsec API", Work in Progress, April 2006.
[BTNS-IPSEC] 「IPsec APIのための要件」というリチャードソン、M.、およびB.ゾンマーフェルトは進歩、2006年4月に働いています。
[CONN-LATCH] Williams, N., "IPsec Channels: Connection Latching",
Work in Progress, September 2007.
[コン-掛け金] ウィリアムズ、N.、「IPsecは以下を精神を集中します」。 「接続は掛け金をおろし」て、進歩、2007年9月に働いてください。
[Lampson91] Lampson, B., Abadi, M., Burrows, M., and E. Wobber,
"Authentication in Distributed Systems: Theory and
Practive", October 1991.
[Lampson91] ランプソン、B.、Abadi、M.、バロウズ、M.、およびE.Wobber、「分散システムにおける認証:」 1991年10月の「理論とPractive」
[NFS-DDP] Callaghan, B. and T. Talpey, "NFS Direct Data
Placement", Work in Progress, July 2007.
「NFSのダイレクトデータプレースメント」という[NFS-DDP]のキャラハン、B.、およびT.Talpeyは進歩、2007年7月に働いています。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC1964] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2203] アイスラーとM.とチウ、A.とL.の御柳もどき、「RPCSEC_GSSプロトコル仕様」、RFC2203、1997年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
[RFC2744] レイ、J.、「ジェネリックセキュリティはAPIバージョン2を供給します」。 「C-結合」、RFC2744、2000年1月。
Williams Standards Track [Page 19] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[19ページ]。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[RFC2817]Khare、R.、およびS.ローレンス。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[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.、サーロウ、R.、Beame、C.、アイスラー、M.、およびD.Noveck)は「File System(NFS)バージョン4プロトコルをネットワークでつなぎます」、RFC3530、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)を連結します」、RFC3720、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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、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)」、RFC4120 2005年7月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4251] YlonenとT.とC.Lonvick、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、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.ウェルチ、「セキュア・シェル(セキュアシェル (SSH))へのジェネリックセキュリティー・サービス適用業務プログラム・インタフェース(GSS-API)認証と主要な交換は議定書を作ります」、RFC4462、2006年5月。
Williams Standards Track [Page 20] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[20ページ]。
[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.ターレル、「リモートダイレクトメモリアクセス(RDMA)のためのインターネットスモールコンピュータシステムインタフェース(iSCSI)拡大」、RFC5046(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.
[STACKABLE] ウィリアムズ、N.、「Stackableジェネリックセキュリティー・サービス疑似メカニズム」が進歩、2006年6月に働いています。
[TLS-CB] Altman, J. and N. Williams, "Unique Channel Bindings for
TLS", Work in Progress, November 2007.
[TLS-CB] 「TLSに、ユニークなチャンネル結合」というアルトマン、J.、およびN.ウィリアムズは進歩、2007年11月に働いています。
Williams Standards Track [Page 21] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[21ページ]。
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.
Conjunction Mechanismが記録する英仏海峡に対する彼の仕事とヘッド(チャンネル結合が問題を縛るチャンネルの一般解を提供すると指摘するためのサム・ハートマン)にマイク・アイスラーに問題をもたらしてくださってありがとうございます、TLSが結合を向けるとき、彼のTLSを使用する提案のためのジェフ・アルトマンはメッセージを終えました。 また、ビル・ゾンマーフェルト、Radiaパールマン、サイモンJosefsson、ジョーSalowey、エリック・レスコラ、マイケル・リチャードソン、バーナードAboba、トムPetch、マーク・ブラウン、および多くの他のものをありがとうございます。
Author's Address
作者のアドレス
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct. Austin, TX 78727 US
ニコラスウィリアムズサン・マイクロシステムズ5300Riataはctをたどります。 オースチン、テキサス78727米国
EMail: Nicolas.Williams@sun.com
メール: Nicolas.Williams@sun.com
Williams Standards Track [Page 22] RFC 5056 On Channel Bindings November 2007
ウィリアムズStandardsは2007年11月にチャンネル結合のときにRFC5056を追跡します[22ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Williams Standards Track [Page 23]
ウィリアムズ標準化過程[23ページ]
一覧
スポンサーリンク
