RFC5386 日本語訳
5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec.N. Williams, M. Richardson. November 2008. (Format: TXT=23103 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Williams
Request for Comments: 5386 Sun
Category: Standards Track M. Richardson
SSW
November 2008
コメントを求めるワーキンググループN.ウィリアムズ要求をネットワークでつないでください: 5386年のSunカテゴリ: 標準化過程M.リチャードソンSSW2008年11月
Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
ないよりましなセキュリティ: IPsecのUnauthenticatedモード
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/license-info )へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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 Encapsulating Security有効搭載量(超能力)とIPsec Authentication Header(AH)との使用のために、"非認証"のセキュリティ協会(SAs)をセットアップするためにIKEv1やIKEv2などのインターネット・キー・エクスチェンジ(IKE)プロトコルを使用する方法を指定します。 ワイヤのIKEv2ビットへの変化は全く必要ではありませんが、Peer Authorization Database(PAD)とSecurity Policy Database(SPD)拡張子は指定されます。 Unauthenticated IPsecはポピュラーな頭文字語、「BTNS」(ないよりましなセキュリティ)によってここに示されます。
Williams & Richardson Standards Track [Page 1] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 コンベンションは本書では.2 2を使用しました。 BTNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 用法シナリオ. . . . . . . . . . . . . . . . . . . . . . . 5 3.1。 例#1: セキュリティゲートウェイ. . . . . . . . . . . . . . 5 3.2。 例#2: Mixedエンドシステム. . . . . . . . . . . . . . 7 3.3。 例#3: BTNSだけシステム. . . . . . . . . . . . . . 8 3.4。 その他は.9 4について論評します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 4.1。 接続かんぬきとチャンネル結合. . . . . . . . . 9 4.2。 BTNS. . . . . . . . . . . . . . . 10 5のための盲信(LoF)。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 10
1. Introduction
1. 序論
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]と非認証された公開鍵を使用することでunauthenticated IPsec SAsを設立する方法を説明します。 ワイヤでどんな新しいプロトコル要素も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を実行するのは可能でないかもしれません。
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]で説明されるように本書では解釈されることであるべきですか?
Williams & Richardson Standards Track [Page 2] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[2ページ]。
2. BTNS
2. BTNS
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タイプは加えられます: 'パブリックキー'。 このタイプの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".
o PUBLICKEY IDで合っているPADエントリーは「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エントリーは特定の同輩PUBLICKEY 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に現れるかもしれなくて、存在しているなら、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.
o デジタル署名(秘密鍵で、公開鍵暗号方式に作られている)を伴うIKEv2 AUTH方法を使用するどんな同輩もBTNS PADエントリーに合うかもしれません、非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エントリーが全く見つけられないなら、値として'PUBLICKEY'タイプには同輩の公開鍵と共にあるように同輩のIDを強制しなければなりません。 そして、PADは再び合っているBTNS PADエントリーを捜されます。 これは、BTNS PADエントリーが非BTNS PADエントリーに論理的に続くのを確実にします。 これらの意味論を保存するただ一つの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.
o もちろん、合っているPADエントリーが全く見つけられないなら、IKE SAはいつものように拒絶されます。
Williams & Richardson Standards Track [Page 3] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[3ページ]。
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はアドレスかID(BTNS同輩のためのタイプPUBLICKEYの)によって捜されるかもしれません、IPsec処理モデル[RFC4301]に従って。 IDのそばで探すのはこの場合公開鍵値に縛られるSPDエントリーの創造を必要とします。 例えば「盲信」[RFC5387]の振舞い(セクション4.2を見る)を組み込むのにこれを使用できました。
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]は、彼らが掛け金をおろされた接続のためにSAsを証明するのに使用される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
o そしてワイルドカードBTNS PADエントリーがPADで論理的に最後のエントリーであるに違いない。
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.
上で説明されるように、同輩認証時間に二度PADを捜すことによって、容易に要件を命令する論理的なPADは実行できます: 一度同輩によって断言されたIDを使用して、PUBLICKEY IDとして一度同輩の公開鍵を使用して、それが失敗するなら。 この必要条件を満たすただ一つのパス実現は受入れられます。
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.
二度PADを捜すことによって、容易にBTNSエントリーID規制非オーバラップ要件を実行できます: 一度いつの同輩が認証するBTNS、および再びいつBTNS、同輩は子供SAsを交渉するか。 最初のパスでは、PADは上で説明されるように合っているPADエントリーを捜されます。 2番目では、それは、BTNS同輩が、子供SA交通セレクタが非BTNS PADエントリーと衝突しないと断言したのを確実にするために捜されます。 これらの意味論を保存するただ一つのパス実現は可能です。
Williams & Richardson Standards Track [Page 4] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[4ページ]。
3. Usage Scenarios
3. 用法シナリオ
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]
[Q][R]AS1AS2[A]----+----[SG-A]…+....+.......[SG-B]-------[B]… \ ..パイ。 ----[btns-B]… [Cをbtnsしている] …+....+.......[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台のシステムがあります。6台のシステムがエンドノード(A、B、C、D、Q、およびR)です。 2は[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]を見る、観点はそうです。 3番目の例では、私たちが[C]を見る、観点はそうです。
PI is the Public Internet ("The Wild").
PIはPublicインターネット(「荒野」)です。
3.1. Example #1: A Security Gateway
3.1. 例#1: セキュリティゲートウェイ
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接続に応じるのを構成したいと思うある種のファイアウォール装置)です。
Williams & Richardson Standards Track [Page 5] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[5ページ]。
[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
IDがSPDに検索を許した子供SA Rule Remote ID---- --------- ----------- ------------- 1 <ビーズID><ビーズはIPで少しもIPによるIPによる>2<QのID><Qのホスト>3PUBLICKEY: いずれもネットワークでつなぎます。
The last entry is the BTNS entry.
最後のエントリーはBTNSエントリーです。
Figure 2: [SG-A] PAD Table
図2: [SG-A]パッドテーブル
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.
[SG-A]のPADエントリーには1つの唯一無二のワイルドカードPADエントリーがあることに注意してください: セクション2で説明されるような最後のエントリーとしてのBTNSキャッチすべて、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)
Local Remote Next Layer BTNS Action addr addrプロトコルが間違いないと裁決してください。---- ----- ------ ---------- ---- ----------------------- 1 [A] [R] どんないいえPROTECT(超能力、トンネル、AES、SHA256)3、[A]も少しも少しも、何でも、はい、PROTECT(超能力、トンネル、AES、SHA256)4[A]がないPROTECTをBで網で覆うどんなN/A BYPASS2[A][Q](超能力、輸送、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を合わせませんが、PADエントリー#2に合っています。 PAD処理は止まります、次に、SPDによる[Q]によるIDであるという探されて、ことです。エントリーが#2であることがわかるために。 次に、]のものを[SG-A持っているCHILD SAsが許容されています、そして、[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によって捜されます。 そして、エンドポイントアドレスとして[SG-A]のアドレスとビーズネットワークからのどんなアドレスも持っているCHILD SAsが許容されています。
o [R] does not initiate any IKE SAs; its traffic to [A] is bypassed
by SPD entry #1.
o [R]は少しのIKE SAsも開始しません。 SPDエントリー#1は[A]への交通を迂回させます。
Williams & Richardson Standards Track [Page 6] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[6ページ]。
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が取り組んでいるということです。 次に、[SG-A]のアドレスを持っているCHILD SAsが許容されています、そして、[C]によるエンドポイントアドレスとしてのアドレスです、[C]によるアドレスがどちらの[Q]であるということであればいくらか、[B]、(セクション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.
o [Q]について断言するのを試みる凶暴なBTNSノード、[B] [B]によるアドレスが拒絶されるか、それらがその場合ではPADエントリー#3を合わせますが、[Q]でCHILD SAsを作成できない[Q]か[B]のときに[Q]か[B]とやり損ないが認証するPADエントリーに合うということであるか交通セレクタとしてのアドレスはことです。
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.
o 凶暴なノードが、[C]によるアドレスであると断言するSAを設立するのを試みる凶暴なBTNSノードはそのようなSAを設立するのに成功するでしょう。 [C]が[C]の追加結合を必要とするので、保護は接続かんぬきとチャンネル結合を通した、または、信頼の飛躍を通した交通の流れへの特定のBTNS ID(すなわち、公開鍵)です。そのいずれもここで説明されません。
3.2. Example #2: A Mixed End-System
3.2. 例#2: Mixedエンドシステム
[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交通を保護する必需品も。 そのPADと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
IDがSPDに検索を許した子供SA Rule Remote ID---- --------- ----------- ------------- IPで少しもIPによる>2PUBLICKEY: いずれも記述する1<[A]のID><[A]によることです。
The last entry is the BTNS entry.
最後のエントリーはBTNSエントリーです。
Figure 4: [Q] PAD Table
図4: [Q]パッドテーブル
Williams & Richardson Standards Track [Page 7] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[7ページ]。
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
Local Remote Next Layer BTNS Action addr addrプロトコルが間違いないと裁決してください。---- ----- ------ ---------- ---- ----------------------- 1 [Q] [A] 少しも、PROTECT(超能力、トンネル、AES、SHA256)2[Q]がないはいのいずれもいずれもPROTECT(超能力、integr+confとの輸送)は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]、および凶暴な同輩に関してここに適用されます。 2番目のSPDエントリーは、どんなBTNSできるノードも2049を移植するためにポート特有のSAを交渉することを許可します、NFSv4が走るポート。 さらに、それが[Q]に知られていなくて、したがって、[SG-B]の後ろのどんなホストも[Q]でNFSv4サービスにアクセスできるように[SG-B]はBTNS同輩として扱われます。 [Q]に[SG-B]とのどんな正式な関係もないとき、悪党は[B]をまねることができます(すなわち、[B]によるアドレスであると断言してください)。
3.3. Example #3: A BTNS-Only System
3.3. 例#3: BTNSだけシステム
[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を使用する必需品。 そのPADとSPDは以下の通り構成されます:
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 PUBLICKEY:any ANY by-IP
IDがSPDに検索を許した子供SA Rule Remote ID---- --------- ----------- ------------- 1つのパブリックキー: いずれ、もいずれ、もIP
The last (and only) entry is the BTNS entry.
最後の(単に)エントリーはBTNSエントリーです。
Figure 6: [Q] PAD Table
図6: [Q]パッドテーブル
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [C] ANY ANY yes PROTECT(ESP,transport,
with integr+conf)
port
2049
Local Remote Next Layer BTNS Action addr addrプロトコルが間違いないと裁決してください。---- ----- ------ ---------- ---- ----------------------- 1 [C] 少しも、いずれはい、PROTECT(超能力、integr+confとの輸送)は2049を移植します。
2 [C] ANY ANY N/A BYPASS
2[C]、少しも、なし、何でも、迂回
Figure 7: [SG-A] SPD Table
図7: [SG-A]SPDテーブル
Williams & Richardson Standards Track [Page 8] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[8ページ]。
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.
o ポート2049の[Q]とのコミュニケーションはSPDエントリーNo.1に合っています。 これで、[C]は[Q]とのIKEv2交換を起こします。 [C]のPADエントリーで、それは、アイデンティティ[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にSAsについて断言できるだけです。
3.4. Miscellaneous Comments
3.4. 種々雑多なコメント
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]の下でいつものように拒絶されるでしょう。
4. Security Considerations
4. セキュリティ問題
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.
Unauthenticatedセキュリティ協会交渉は、中央の男性(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.
下層でチャンネルを固定するために、より高いネットワーク層で認証を縛るアプリケーションによる使用はunauthenticated 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エントリーは最後であるに違いありません、そして、子供SA ID規制がいかなる他のPADエントリーへのも非重なることでなければなりません、セクション2で説明されるように。 これは、どんなBTNS同輩も別のIPsec非BTNS同輩をまねることができないのを確実にするでしょう。
4.1. Connection Latching and Channel Binding
4.1. 接続かんぬきとチャンネル結合
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
BTNSはMITM攻撃を受けることがあります。 コミュニケーションに頭文字をつけるためにはその後のMITM攻撃から守る1つの方法は「接続かんぬき[ConnLatch]」を使用することです。 接続かんぬきでは、上側の層のプロトコル(ULPs)は離散的なパケットが注ぐひもにIPsecと協力します。
Williams & Richardson Standards Track [Page 9] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[9ページ]。
sequences of similar SAs. Connection latching requires native IPsec implementations.
同様のSAsの系列。 接続かんぬきはネイティブの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.
チャンネル結合[RFC5056]と共に応用層認証枠組み、そして/または、GSS-APIなどのメカニズム[RFC2743]を使用することによって、MITMsを検出できます。 IPsec「チャンネル」は掛け金をおろされた接続以外の何でもありません。
4.2. Leap-of-Faith (LoF) for BTNS
4.2. BTNSのための盲信(LoF)
"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.
「盲信」は一般に、使用されるユーザが与えられたキーが最初のコミュニケーション(その主張に関する有力な証拠の不足にもかかわらず)で同輩を特定して、次に、将来のコミュニケーションのためにこの協会を覚えているという主張を受け入れる用語です。 明確にこれはSecureシェル[RFC4251]のクライアントのための一般的な運転モードです。 サーバが初めて遭遇するとき、Secureシェルのクライアントは、サーバの公開鍵を受け入れるかどうかユーザに尋ねるかもしれません。 そうだとすれば、クライアントはサーバの名前(ユーザによって与えられているように)と公開鍵をデータベースに記録します。
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によってまだ設計されていて、指定されています。
5. Acknowledgements
5. 承認
Thanks to the following reviewer: Stephen Kent.
以下の評論家をありがとうございます: スティーブン・ケント。
6. References
6. 参照
6.1. Normative References
6.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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
6.2. Informative References
6.2. 有益な参照
[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.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan、D.、シュナイダー、M.、およびM.Schertler、「協会とKey Managementが議定書の中で述べるインターネットセキュリティ(ISAKMP)」、RFC2408、1998年11月。
Williams & Richardson Standards Track [Page 10] RFC 5386 BTNS IPsec November 2008
ウィリアムズとリチャードソンStandardsはBTNS IPsec2008年11月にRFC5386を追跡します[10ページ]。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] リン、J.、「一般的なセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズ、N. 「チャンネルを固定するチャンネル結合の使用」のRFC5056、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.ワング、および「ないよりましなセキュリティ(BTNS)のための問題と適用性証明」、RFC5387、11月2008日
Authors' Addresses
作者のアドレス
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
ニコラスウィリアムズサン・マイクロシステムズ5300Riata跡のCtオースチン(テキサス)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カリフォルニアのマイケルC.リチャードソンSandelmanソフトウェア作品470ドーソン・Avenueオタワ
EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/
メール: mcr@sandelman.ottawa.on.ca ユリ: http://www.sandelman.ottawa.on.ca/
Williams & Richardson Standards Track [Page 11]
ウィリアムズとリチャードソン標準化過程[11ページ]
一覧
スポンサーリンク
