Network Working Group N. Williams
Request for Comments: 5386 Sun
Category: Standards Track M. Richardson
SSW
November 2008
Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security).
この文書では、IPsecカプセル化セキュリティペイロード（ESP）およびIPsecの認証ヘッダー（AH）で使用するためのセットアップ「認証されていない」セキュリティアソシエーション（SA）には、そのようなのIKEv1とIKEv2のようなインターネットキー交換（IKE）プロトコルを使用する方法を指定します。 IKEv2のビット・オン・ワイヤーを変更する必要はありませんが、ピア認証データベース（PAD）とセキュリティポリシーデータベース（SPD）の拡張子が指定されています。未認証のIPsecは、本明細書では「BTNS」（ベター・ザン・ナッシングセキュリティ）、その人気の頭字語で呼ばれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example #1: A Security Gateway . . . . . . . . . . . . . . 5
3.2. Example #2: A Mixed End-System . . . . . . . . . . . . . . 7
3.3. Example #3: A BTNS-Only System . . . . . . . . . . . . . . 8
3.4. Miscellaneous Comments . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Connection Latching and Channel Binding . . . . . . . . . 9
4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Here we describe how to establish unauthenticated IPsec SAs using IKEv2 [RFC4306] and unauthenticated public keys. No new on-the-wire protocol elements are added to IKEv2.
ここでは、IKEv2の[RFC4306]と未認証の公開鍵を使用して認証されていないのIPsec SAを確立する方法について説明します。新しいオン・ワイヤープロトコル要素は、IKEv2のに追加されません。
The [RFC4301] processing model is assumed.
[RFC4301]の処理モデルが仮定されます。
This document does not define an opportunistic BTNS mode of IPsec whereby nodes may fall back to unprotected IP when their peers do not support IKEv2, nor does it describe "leap-of-faith" modes or "connection latching".
仲間は、IKEv2のをサポートしていないときのノードが戻って保護されていないIPに落ちるおそれがこの文書では、IPsecの日和見BTNSモードを定義していません。また、「うるう・オブ・信仰」モードまたは「ラッチング接続」を記述ありません。
See [RFC5387] for the applicability and uses of BTNS and definitions of these terms.
BTNSこれらの用語の定義の適用および使用のための[RFC5387]を参照してください。
This document describes BTNS in terms of IKEv2 and [RFC4301]'s concepts. There is no reason why the same methods cannot be used with IKEv1 [RFC2408], [RFC2409], and [RFC2401]; however, those specifications do not include the PAD concepts, and therefore it may not be possible to implement BTNS on all compliant RFC2401 implementations.
この文書では、IKEv2のと[RFC4301]の概念の面でBTNSを説明しています。同じ方法でのIKEv1 [RFC2408]、[RFC2409]、および[RFC2401]で使用することができない理由はありません。しかし、これらの仕様は、PADの概念を含んでいないので、すべての準拠したRFC2401の実装にBTNSを実装することはできないかもしれません。
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]に記載されているように解釈されます。
The IPsec processing model is hereby modified as follows:
次のようにIPsec処理モデルは、ここに修正されます。
o A new ID type is added: 'PUBLICKEY'. IDs of this type have public keys as values. This ID type is not used on the wire.
O新しいIDの種類が追加されます：「PUBLICKEY」。このタイプのIDが値として公開鍵を持っています。このIDタイプは、ワイヤ上で使用されていません。
o PAD entries that match on PUBLICKEY IDs are referred to as "BTNS PAD entries". All other PAD entries are referred to as "non-BTNS PAD entries".
PUBLICKEY IDに一致Oパッドエントリは「BTNS PADのエントリ」と呼ばれています。他のすべてのPADのエントリは、「非BTNS PADのエントリ」と呼ばれています。
o BTNS PAD entries may match on specific peer PUBLICKEY IDs (or public key fingerprints) or on all peer public keys. The latter is referred to as the "wildcard BTNS PAD entry".
O BTNS PADエントリは、特定のピアの公開鍵のID（又は公開鍵のフィンガープリント）に一致またはすべてに公開鍵をピアできます。後者は、「ワイルドカードBTNS PADエントリ」と呼ばれます。
o BTNS PAD entries MUST logically (see below) follow all other PAD entries (the PAD being an ordered list).
O BTNS PADのエントリは、論理的に（PADは、順序付きリストである）（下記参照）他のすべてのPADエントリに従わなければなりません。
o At most one wildcard BTNS PAD entry may appear in the PAD, and, if present, MUST be the last entry in the PAD (see below).
O最大1つのワイルドカードBTNS PADのエントリは、パッドに表示されること、および、存在する場合、（下記参照）PADの最後のエントリでなければなりません。
o Any peer that uses an IKEv2 AUTH method involving a digital signature (made with a private key to a public key cryptosystem) may match a BTNS PAD entry, provided that it matches no non-BTNS PAD entries. Suitable AUTH methods as of August 2007 are: RSA Digital Signature (method #1) and DSS Digital Signature (method #3); see [RFC4306], Section 3.8.
（公開鍵暗号の秘密鍵を用いて作られた）デジタル署名を含むのIKEv2 AUTH方法はBTNS PADエントリと一致することができる使用するすべてのピアO、それは非BTNS PADエントリと一致しないことを条件とします。 2007年8月のような適切なAUTH方法がある：RSAデジタル署名（方法＃1）とDSSデジタル署名（方法＃3）。 [RFC4306]、セクション3.8を参照してください。
o A BTNS-capable implementation of IPsec will first search the PAD for non-BTNS entries matching a peer's ID. If no matching non-BTNS PAD entries are found, then the peer's ID MUST be coerced to be of 'PUBLICKEY' type with the peer's public key as its value. The PAD is then searched again for matching BTNS PAD entries. This ensures that BTNS PAD entries logically follow non-BTNS PAD entries. A single PAD search that preserves these semantics is allowed.
OのIPsecのBTNS可能な実装は、最初のピアのIDと一致する非BTNSエントリのPADを検索します。一致非BTNS PADのエントリが見つからない場合は、ピアのIDは、その値としてピアの公開鍵で「PUBLICKEY」タイプであることを強制されなければなりません。 PADが、その後BTNS PADのエントリを一致させるために再び検索されます。これはBTNS PADのエントリは、論理的に非BTNS PADのエントリに従うことを保証します。これらのセマンティクスを保持する単一のパッドの検索が許可されています。
o A peer that matches a BTNS PAD entry is referred to as a "BTNS peer". Such a peer is "authenticated" by verifying the signature in its IKEv2 AUTH payload with the public key from the peer's CERT payload.
O BTNS PADエントリに一致ピアは「BTNSピア」と呼ばれます。このようなピアは、ピアのCERTペイロードから公開鍵とのIKEv2のAUTHペイロードに署名を検証することにより、「認証済み」されます。
o Of course, if no matching PAD entry is found, then the IKE SA is rejected as usual.
一致するPADのエントリが見つからない場合はもちろんの入出力、そして、IKE SAは、いつものように拒否されます。
o A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that match the BTNS PAD entry will match only SPD entries that have the BTNS_OK flag set. The SPD may be searched by address or by ID (of type PUBLICKEY for BTNS peers), as per the IPsec processing model [RFC4301]. Searching by ID in this case requires creation of SPD entries that are bound to public key values. This could be used to build "leap-of-faith" [RFC5387] behavior (see Section 4.2), for example.
O SPDエントリ用の新しいフラグ：「BTNS_OK」。 BTNS PADのエントリに一致するピアから/へのトラフィックはBTNS_OKフラグがセットされている唯一のSPDエントリと一致します。 SPDは、IPsec処理モデル[RFC4301]に従って、アドレスまたは（BTNSピアのタイプPUBLICKEYの）IDにより検索することができます。この場合、IDで検索する公開鍵値に束縛されているSPDエントリを作成する必要があります。これは、例えば、（4.2節を参照）、「うるう・オブ・信仰」[RFC5387]の挙動を構築するために使用することができます。
Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD entries but fail to authenticate properly.
ノードは非BTNS PADのエントリと一致しますが、正しく認証に失敗ピアからIKE_SAの提案を拒絶しなければなりません。
Nodes wishing to be treated as BTNS nodes by their peers MUST include bare public key CERT payloads. Currently only bare RSA public key CERT payloads are defined, which means that BTNS works only with RSA public keys at this time (see "Raw RSA Key" in Section 3.6 of [RFC4306]). Nodes MAY also include any number of certificates that bind the same public key. These certificates do not need to be pre-shared with their peers (e.g., because ephemeral, self-signed). RSA keys for use in BTNS may be generated at any time, but connection latching [ConnLatch] requires that they remain constant between IKEv2 exchanges that are used to establish SAs for latched connections.
仲間でBTNSノードとして扱われることを望むものではノードが裸の公開鍵CERTペイロードを含まなければなりません。現在、唯一の裸のRSA公開鍵CERTペイロードはBTNSは（[RFC4306]のセクション3.6で「生のRSAキー」を参照）、この時点でRSA公開鍵でのみ動作することを意味し、定義されています。ノードは、同じ公開鍵をバインドする証明書のいずれかを含むことができます。 （はかない、自己署名ので、例えば、）これらの証明書は、仲間との事前共有する必要はありません。 BTNSにおける使用のためのRSAキーはいつでも発生することができるが、[ConnLatch】ラッチ接続は、彼らがラッチ接続のためにSAを確立するために使用されるのIKEv2交換の間に一定のままであることを必要とします。
To preserve standard IPsec access control semantics:
標準のIPsecアクセス制御セマンティクスを保護するには：
o BTNS PAD entries MUST logically follow all non-BTNS PAD entries,
O BTNS PADのエントリは、論理的にすべての非BTNS PADのエントリに従わなければなりません、
o the wildcard BTNS PAD entry MUST be the last entry in the PAD, logically, and
ワイルドカードBTNS PADのエントリは論理的には、パッドの最後のエントリでなければならない、O、および
o the wildcard BTNS PAD entry MUST have ID constraints that do not logically overlap those of other PAD entries.
OワイルドカードBTNS PADのエントリには、論理的に他のPADエントリのものと重複しないIDの制約を持たなければなりません。
As described above, the logical PAD ordering requirements can easily be implemented by searching the PAD twice at peer authentication time: once using the peer-asserted ID, and if that fails, once using the peer's public key as a PUBLICKEY ID. A single pass implementation that meets this requirement is permitted.
一度ピアアサートIDを使用して、それが失敗した場合、一度PUBLICKEYのIDとしてピアの公開鍵を使用して：前述したように、論理的なパッド発注要件は簡単ピア認証時に二回、PADを検索することで実現できます。この要件を満たす単一パス実装が許可されます。
The BTNS entry ID constraint non-overlap requirement can easily be implemented by searching the PAD twice: once when BTNS peers authenticate, and again when BTNS peers negotiate child SAs. In the first pass, the PAD is searched for a matching PAD entry as described above. In the second, it is searched to make sure that BTNS peers' asserted child SA traffic selectors do not conflict with non-BTNS PAD entries. Single pass implementations that preserve these semantics are feasible.
BTNSエントリーID制約ノンオーバーラップ要件が簡単に二回、PADを検索することで実装できますBTNSピアが子SAをネゴシエートするときBTNSピアが再度認証、およびときたら。上述したように、第1のパスでは、PADは、整合PADエントリが検索されます。第二に、BTNSのピアのアサート子SAのトラフィックセレクタが非BTNS PADのエントリと競合していないことを確認するために検索されます。これらのセマンティクスを保護シングルパスの実装が可能です。
In order to explain the above rules, a number of scenarios will be examined. The goal here is to persuade the reader that the above rules are both sufficient and necessary.
上記の規則を説明するために、多くのシナリオを検討します。ここでの目的は、上記のルールは必要十分の両方である読者を説得することです。
This section is informative only.
このセクションでは有益です。
To explain the scenarios, a reference diagram describing an example network will be used. It is as follows:
シナリオを説明するために、ネットワーク例を説明する参考図が使用されます。以下のようになります：
[Q] [R]
AS1 . . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
...... \
..PI.. ----[btns-B]
......
[btns-C].....+....+.......[btns-D]
Figure 1: Reference Network Diagram
図1：リファレンスネットワークダイアグラム
In this diagram, there are eight systems. Six systems are end-nodes (A, B, C, D, Q, and R). Two are security gateways (SG-A, SG-B) protecting networks on which [A] and [B] reside. Node [Q] is IPsec and BTNS capable. Node [R] is a simple node, with no IPsec or BTNS capability. Nodes [C] and [D] are BTNS capable.
この図では、8つのシステムがあります。六のシステムは、エンドノード（A、B、C、D、Q、及びR）です。二つは、[A]及び[B]常駐するネットワークを保護するセキュリティゲートウェイ（SG-A、SG-B）です。ノード[Q]はIPsecとBTNSが可能です。ノード[R]はIPSecまたはBTNS能力なしで、単純なノードです。ノード[C]および[D]はできるBTNSあります。
Nodes [C] and [Q] have fixed addresses. Node [D] has a non-fixed address.
ノード[C]と[Q]はアドレスが固定されています。ノード[D]は非固定アドレスを有します。
We will examine how these various nodes communicate with node [SG-A] and/or how [SG-A] rejects communications with some such nodes. In the first example, we examine [SG-A]'s point of view. In the second example, we look at [Q]'s point of view. In the third example, we look at [C]'s point of view.
これらの様々なノードがノード[SG-A]及び/又は方法[SG-Aは、いくつかのこのようなノードとの通信を拒否すると通信するどのように検討します。最初の例では、ビューの[SG-A]の点を検討します。 2番目の例では、我々は、ビューのポイントの[Q]を見てください。第三の例では、ビューの[C]の点を見てください。
PI is the Public Internet ("The Wild").
PIは、公衆インターネット（「ワイルド」）です。
The machine that we will focus on in this example is [SG-A], a firewall device of some kind that we wish to configure to respond to BTNS connections from [C].
私たちは、この例では集中するマシンは、[SG-A]、我々は[C]からBTNS接続に対応するように設定したいいくつかの種類のファイアウォールデバイスです。
[SG-A] has the following PAD and SPD entries:
[SG-A]は、以下のPADとSPDエントリを有します。
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <B's ID> <B's network> by-IP
2 <Q's ID> <Q's host> by-IP
3 PUBLICKEY:any ANY by-IP
The last entry is the BTNS entry.
最後のエントリはBTNSエントリです。
Figure 2: [SG-A] PAD Table
図2：[SG-A] PAD表
Note that [SG-A]'s PAD entry has one and only one wildcard PAD entry: the BTNS catch-all PAD entry as the last entry, as described in Section 2.
第2節で説明したように、最後のエントリとしてBTNSキャッチオールパッド入力：[SG-A]さん、PADエントリは、唯一のワイルドカードPADのエントリを持っていることに注意してください。
<Child SA IDs allowed> and <SPD Search by> are from [RFC4301], Section 4.4.3.
<によってSPD検索>と<許容子SA IDは> [RFC4301]、セクション4.4.3からのものです。
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [A] [R] ANY N/A BYPASS
2 [A] [Q] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
3 [A] B-net ANY no PROTECT(ESP,tunnel,AES,
SHA256)
4 [A] ANY ANY yes PROTECT(ESP,transport,
integr+conf)
Figure 3: [SG-A] SPD Table
図3：[SG-A] SPD表
The processing by [SG-A] of SA establishment attempts by various peers is as follows:
次のように様々なピアによるSAの確立の試行[SG-A]による処理です。
o [Q] does not match PAD entry #1 but does match PAD entry #2. PAD processing stops, then the SPD is searched by [Q]'s ID to find entry #2. CHILD SAs are then allowed that have [SG-A]'s and [Q]'s addresses as the end-point addresses.
O [Q]は、PADエントリー＃1と一致するが、一致パッドのエントリ＃2を実行していません。 PADの処理は、SPDは、エントリ＃2を見つけるために、[Q] 'sのIDで検索され、停止します。 CHILDのSAが次に持っている許可されている[SG-A]さんと[Q] [エンドポイントアドレスとしてのアドレス。
o [SG-B] matches PAD entry #1. PAD processing stops, then the SPD is searched by [SG-B]'s ID to find SPD entry #3. CHILD SAs are then allowed that have [SG-A]'s address and any addresses from B's network as the end-point addresses.
O [SG-B] PADエントリ＃1に一致します。 PADの処理が停止し、その後、SPDはSPDエントリ＃3を見つけるために[SG-B]のIDで検索されます。 CHILD SAのその後のエンドポイントアドレスとして[SG-A]のアドレスとBのネットワークからの任意のアドレスを持つことが許可されます。
o [R] does not initiate any IKE SAs; its traffic to [A] is bypassed by SPD entry #1.
O [R]は、任意のIKE SAを開始しません。 [A]へのトラフィックは、SPDエントリー＃1によってバイパスされます。
o [C] does not match PAD entries #1 or #2 but does match entry #3, the BTNS wildcard PAD entry. The SPD is searched by [C]'s address, and SPD entry #4 is matched. CHILD SAs are then allowed that have [SG-A]'s address and [C]'s address as the end-point addresses, provided that [C]'s address is neither [Q]'s nor any of [B]'s (see Section 2). See the last bullet item below.
O [C]はPADエントリを＃1又は＃2と一致するが、一致エントリ＃3、BTNSワイルドカードPADエントリをしません。 SPDは、[C]のアドレスにより検索し、SPDエントリ＃4が一致しています。 CHILD SAの後、[SG-A]のアドレスと[C] '終点アドレスとしてのアドレスを持っている許可されている、[C] Sも、[B]のいずれかのアドレスが[Q]もない」ことを条件としますさん（セクション2を参照）。下の最後の箇条書き項目を参照してください。
o A rogue BTNS node attempting to assert [Q]'s or [B]'s addresses will either match the PAD entries for [Q] or [B] and fail to authenticate as [Q] or [B], in which case they are rejected, or they will match PAD entry #3 but will not be allowed to create CHILD SAs with [Q]'s or [B]'s addresses as traffic selectors.
アサートしようとする不正なBTNSノードO [Q] [Sまたは[B]のアドレスは、[Q]または[B]のためのPADのエントリと一致し、[Q]または[B]として認証に失敗するか、その場合に彼らは拒否され、またはそれらは、PADのエントリ＃3にマッチしますが、トラフィックセレクタとして[Q]さんや[B]のアドレスでCHILD SAを作成することはできません。
o A rogue BTNS node attempting to establish an SA whereby the rogue node asserts [C]'s address will succeed at establishing such an SA. Protection for [C] requires additional bindings of [C]'s specific BTNS ID (that is, its public key) to its traffic flows through connection latching and channel binding or through leap-of-faith, none of which are described here.
不正ノードがアサートされるSAを確立しようとする不正なBTNSノードO [C]のアドレスは、SAを確立することに成功します。 [C]の保護は、接続ラッチ及びチャネル結合またはLEAP-の-信仰、ここに記載されているのどれを介して流れるそのトラフィックに[C]の特定BTNS ID（すなわち、その公開鍵である）の追加のバインディングを必要とします。
[Q] is an NFSv4 server.
[Q]はNFSv4サーバです。
[Q] is a native IPsec implementation, and its NFSv4 implementation is IPsec-aware.
[Q]はネイティブのIPsec実装であり、そのNFSv4の実装では、IPSecに対応しています。
[Q] wants to protect all traffic with [A]. [Q] also wants to protect NFSv4 traffic with all peers. Its PAD and SPD are configured as follows:
[Q]は[A]ですべてのトラフィックを保護したいです。 [Q]も、すべてのピアとNFSv4のトラフィックを保護したいと考えています。次のようにそのパッドとSPDが構成されています。
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <[A]'s ID> <[A]'s address> by-IP
2 PUBLICKEY:any ANY by-IP
The last entry is the BTNS entry.
最後のエントリはBTNSエントリです。
Figure 4: [Q] PAD Table
図4：[Q] PAD表
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [Q] [A] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
2 [Q] ANY ANY yes PROTECT(ESP,transport,
with integr+conf)
port 2049
Figure 5: [Q] SPD Table
図5：[Q] SPD表
The same analysis shown above in Section 3.1 applies here with respect to [SG-A], [C], and rogue peers. The second SPD entry permits any BTNS-capable node to negotiate a port-specific SA to port 2049, the port on which NFSv4 runs. Additionally, [SG-B] is treated as a BTNS peer as it is not known to [Q], and therefore any host behind [SG-B] can access the NFSv4 service on [Q]. As [Q] has no formal relationship with [SG-B], rogues can impersonate [B] (i.e., assert [B]'s addresses).
セクション3.1で上記に示した同一の分析は、[SG-A]に対して、[C]、および不正ピアとここに適用されます。第SPDエントリは、ポート2049のポート固有のSA、NFSv4のが動作するポートをネゴシエートするために、任意のBTNS対応ノードを許容します。また、[SG-B]それは[Q]には知られていないようBTNSピアとして扱われ、従って背後にある任意のホスト[SG-B] [Q]のNFSv4サービスにアクセスすることができます。 [Q]は[SG-B]との正式な関係を持たないように、不正は、[B]（すなわち、[B]のアドレスをアサート）偽装することができます。
[C] supports only BTNS and wants to use BTNS to protect NFSv4 traffic. Its PAD and SPD are configured as follows:
[C]はだけBTNSをサポートし、NFSv4のトラフィックを保護するためにBTNSを使用することを望んでいます。次のようにそのパッドとSPDが構成されています。
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 PUBLICKEY:any ANY by-IP
The last (and only) entry is the BTNS entry.
最後の（そして唯一の）エントリーはBTNSエントリです。
Figure 6: [Q] PAD Table
図6：[Q] PAD表
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [C] ANY ANY yes PROTECT(ESP,transport,
with integr+conf)
port
2049
2 [C] ANY ANY N/A BYPASS
2 [C] ANY ANY N / A BYPASS
Figure 7: [SG-A] SPD Table
図7：[SG-A] SPD表
The analysis from Section 3.1 applies as follows:
次のように3.1節からの分析が適用されます。
o Communication with [Q] on port 2049 matches SPD entry number 1. This causes [C] to initiate an IKEv2 exchange with [Q]. The PAD entry on [C] causes it to not care what identity [Q] asserts. Further authentication (and channel binding) could occur within the NFSv4 protocol.
ポート上の[Q]とO通信2049のマッチSPDエントリ番号1これは、[C]が[Q]とのIKEv2交換を開始させます。 [C]のパッドエントリは、それがどのようなアイデンティティ[Q]アサートを気にしないようになります。さらに、認証（およびチャネル結合は）のNFSv4プロトコル内で発生する可能性があります。
o Communication with [A], [B], or any other internet machine (including [Q]), occurs in the clear, so long as it is not on port 2049.
O [A]、[B]、または（[Q]を含む）他のインターネット・マシンとの通信は、あれば、ポート2049上にないように、明確に起こります。
o All analysis about rogue BTNS nodes applies, but they can only assert SAs for port 2049.
O不正BTNSノードに関するすべての分析が適用されますが、彼らは唯一のポート2049のためにSAを主張することができます。
If [SG-A] were not BTNS capable, then it would not have PAD and SPD entries #3 and #4, respectively, in example #1. Then [C] would be rejected as usual under the standard IPsec model [RFC4301].
[SG-A]がBTNSことができなかった場合、それは、例えば＃1に、それぞれPADとSPDエントリ＃3及び＃4を持っていません。次いで、[C]は標準のIPsecモデル[RFC4301]の下で、通常として拒絶されるであろう。
Similarly, if [Q] were not BTNS capable, then it would not have PAD and SPD entries #2 in example #2. Then [C] would be rejected as usual under the standard IPsec model [RFC4301].
[Q]はBTNSことができなかった場合は同様に、それは例2にPADとSPDエントリ＃2を持っていないであろう。次いで、[C]は標準のIPsecモデル[RFC4301]の下で、通常として拒絶されるであろう。
Unauthenticated security association negotiation is subject to man-in-the-middle (MITM) attacks and should be used with care. Where security infrastructures are lacking, this may indeed be better than nothing.
認証されていないセキュリティアソシエーションのネゴシエーションはのman-in-the-middle（MITM）攻撃の対象であり、注意して使用する必要があります。セキュリティインフラが不足している場合、これは確かに何もないよりはましかもしれません。
Use with applications that bind authentication at higher network layers to secure channels at lower layers may provide one secure way to use unauthenticated IPsec, but this is not specified herein.
認証されていないIPsecを使用する1つの安全な方法を提供することができるが、これは本明細書で指定されていない下位層にチャネルを確保するために、より高いネットワーク層での認証をバインドするアプリケーションで使用します。
The BTNS PAD entry must be last and its child SA ID constraints must be non-overlapping with any other PAD entry, as described in Section 2. This will ensure that no BTNS peer can impersonate another IPsec non-BTNS peer.
BTNS PADのエントリが最後でなければならず、これは何のBTNSピアは、別のIPsec非BTNSピアになりすますことができないことを保証します第2節で説明したように、その子SAのID制約は、他のパッド入力と、非重複でなければなりません。
BTNS is subject to MITM attacks. One way to protect against MITM attacks subsequent to initial communications is to use "connection latching" [ConnLatch]. In connection latching, upper layer protocols (ULPs) cooperate with IPsec to bind discrete packet flows to sequences of similar SAs. Connection latching requires native IPsec implementations.
BTNSはMITM攻撃の対象となります。 MITMから保護する1つの方法は、最初の通信に、後続の攻撃は、「接続ラッチング」[ConnLatch]を使用することです。接続ラッチ、上位層プロトコル（のULP）に離散パケットに結合することのIPsecと協働同様のSAの配列に流れます。接続のラッチは、ネイティブのIPsec実装が必要です。
MITMs can be detected by using application-layer authentication frameworks and/or mechanisms, such as the GSS-API [RFC2743], with channel binding [RFC5056]. IPsec "channels" are nothing other than latched connections.
MITMsは[RFC5056]を結合チャネルと、そのようなGSS-API [RFC2743]などのアプリケーション層認証フレームワークおよび/または機構を用いて検出することができます。 IPsecの「チャンネル」はラッチ接続以外の何ものでもありません。
"Leap of faith" is the term generally used when a user accepts the assertion that a given key identifies a peer on the first communication (despite a lack of strong evidence for that assertion), and then remembers this association for future communications. Specifically this is a common mode of operation for Secure Shell [RFC4251] clients. When a server is encountered for the first time, the Secure Shell client may ask the user whether to accept the server's public key. If so, the client records the server's name (as given by the user) and public key in a database.
「信仰のリープ」は、ユーザが所定のキー（そのアサーションのための強力な証拠の欠如にもかかわらず）第一の通信のピアを識別するという主張を受け入れたとき、一般的に使用される用語であり、そして、将来の通信のためにこの関連付けを覚えています。具体的にはこれは、セキュアシェル[RFC4251]クライアントの動作の一般的なモードです。サーバーが初めて遭遇した場合、セキュアシェルクライアントは、サーバの公開鍵を受け入れるかどうかをユーザーに尋ねることができます。その場合、クライアントはサーバの名前（ユーザーによって与えられる）と、データベース内の公開鍵を記録します。
Leap of faith can work in a similar way for BTNS nodes, but it is currently still being designed and specified by the IETF BTNS WG.
信仰のリープはBTNSノードに対して同じように動作することができますが、それは現在も設計されており、IETF BTNS WGによって指定されています。
Thanks to the following reviewer: Stephen Kent.
スティーブン・ケント：次審査に感謝します。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[ConnLatch] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, April 2008.
[ConnLatch]ウィリアムズ、N.、 "IPsecのチャンネル：接続ラッチ"、進歩、2008年4月の作業。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]モーガン、D.、シュナイダー、M.、およびM. Schertler、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[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月。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
[RFC5387]タッチ、J.、ブラック、D.、およびY.王、RFC 5387、2008年11月 "ベター・ザン・ナッシングセキュリティ（BTNS）のための問題と適用に関する声明"。
Authors' Addresses
著者のアドレス
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
Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA
K1Z 5V7 CA ONマイケル・C.・リチャードソンSandelmanソフトウェア作品470ドーソンアベニューオタワ、
EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/
電子メール：mcr@sandelman.ottawa.on.ca URI：http://www.sandelman.ottawa.on.ca/