RFC5387 日本語訳
5387 Problem and Applicability Statement for Better-Than-NothingSecurity (BTNS). J. Touch, D. Black, Y. Wang. November 2008. (Format: TXT=71707 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Touch
Request for Comments: 5387 USC/ISI
Category: Informational D. Black
EMC
Y. Wang
Microsoft
November 2008
コメントを求めるワーキンググループJ.接触要求をネットワークでつないでください: 5387年のUSC/ISIカテゴリ: 情報の黒いD.のEMC Y.ワングマイクロソフト2008年11月
Problem and Applicability Statement
for Better-Than-Nothing Security (BTNS)
ないよりましなセキュリティのための問題と適用性証明(BTNS)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
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
要約
The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.
インターネット網セキュリティプロトコル群(IPsec)が通常、ネットワーク層実体の認証を必要とする、アクセスコントロールを可能にして、セキュリティー・サービスを提供するために。 この認証はあらかじめ共有された対称鍵、関連非対称のキーがある証明書、またはケルベロスの使用(キーズ(KINK)のKerberizedインターネットNegotiationを通した)などのメカニズムに基づくことができます。 認証情報を配布する必要性とその関連アイデンティティはIPsecの使用への重要な障害であるかもしれません。
This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol
このドキュメントで、認証なしでIPsecセキュリティー・サービスの使用を可能にするためにインターネット網セキュリティプロトコル群を広げるために原理がわかります。 「ないよりましなセキュリティ」(BTNS)を提供して、これらの拡大がコミュニケーションを保護することを意図します。 拡張子は、一人で(この使用はStandだけBTNS、またはSABと呼ばれる)使用されるか、またはプロトコルの、より高い層で認証できるネットワーク層セキュリティを提供するのに使用されるかもしれません。
Touch, et al. Informational [Page 1] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[1ページ]のRFC5387BTNS問題と適用性2008年11月
stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable.
積み重ねてください(この使用はChannelによって制限されたBTNS、またはCBBと呼ばれます)。 また、ドキュメントで、SAB、そして/または、CBB拡張子の使用が適切である状況がわかります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Authentication .............................................3
1.2. IPsec Channels and Channel Binding .........................4
1.3. BTNS Methods ...............................................6
1.4. BTNS Scope .................................................6
1.5. Structure of This Document .................................7
2. Problem Statement ...............................................7
2.1. Network Layer ..............................................8
2.1.1. Authentication Identities ...........................8
2.1.2. Authentication Methods ..............................8
2.1.3. Current IPsec Limits on Unauthenticated Peers .......9
2.2. Higher Layer Issues ........................................9
2.2.1. Transport Protection from Packet Spoofing ...........9
2.2.2. Authentication at Multiple Layers ..................10
3. BTNS Overview and Threat Models ................................12
3.1. BTNS Overview .............................................12
3.2. BTNS and IPsec Security Services ..........................13
3.3. BTNS and IPsec Modes ......................................14
4. Applicability Statement ........................................15
4.1. Benefits ..................................................16
4.2. Vulnerabilities ...........................................16
4.3. Stand-Alone BTNS (SAB) ....................................17
4.3.1. Symmetric SAB ......................................17
4.3.2. Asymmetric SAB .....................................18
4.4. Channel-Bound BTNS (CBB) ..................................18
4.5. Summary of Uses, Vulnerabilities, and Benefits ............19
5. Security Considerations ........................................20
5.1. Threat Models and Evaluation ..............................20
5.2. Interaction with Other Security Services ..................20
5.3. MITM and Masquerader Attacks ..............................21
5.4. Denial of Service (DoS) Attacks and Resource
Consumptions ..............................................22
5.5. Exposure to Anonymous Access ..............................22
5.6. ICMP Attacks ..............................................22
5.7. Leap of Faith .............................................22
5.8. Connection Hijacking through Rekeying .....................24
5.9. Configuration Errors ......................................25
6. Related Efforts ................................................25
7. Acknowledgments ................................................25
8. Informative References .........................................26
1. 序論…3 1.1. 認証…3 1.2. IPsecチャンネルとチャンネル結合…4 1.3. BTNSメソッド…6 1.4. BTNS範囲…6 1.5. このドキュメントの構造…7 2. 問題声明…7 2.1. ネットワーク層…8 2.1.1. 認証のアイデンティティ…8 2.1.2. 認証メソッド…8 2.1.3. 現在のIPsecはUnauthenticatedで同輩を制限します…9 2.2. より高い層の問題…9 2.2.1. パケットスプーフィングから保護を輸送してください…9 2.2.2. 倍数での認証は層にされます…10 3. BTNS概要と脅威モデル…12 3.1. BTNS概要…12 3.2. BTNSとIPsecセキュリティー・サービス…13 3.3. BTNSとIPsecモード…14 4. 適用性声明…15 4.1. 利益…16 4.2. 脆弱性…16 4.3. スタンドアロンのBTNS(SAB)…17 4.3.1. 左右対称のSAB…17 4.3.2. 非対称のSAB…18 4.4. チャンネル行きのBTNS(CBB)…18 4.5. 用途、脆弱性、および利益の概要…19 5. セキュリティ問題…20 5.1. 脅威モデルと評価…20 5.2. 他のセキュリティー・サービスとの相互作用…20 5.3. MITMと仮面舞踏会参加者攻撃…21 5.4. サービス妨害(DoS)攻撃とリソース肺病…22 5.5. 匿名のアクセスへの暴露…22 5.6. ICMPは攻撃します…22 5.7. 信頼の飛躍…22 5.8. Rekeyingを通した接続ハイジャック…24 5.9. 構成誤り…25 6. 取り組みを関係づけます…25 7. 承認…25 8. 有益な参照…26
Touch, et al. Informational [Page 2] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[2ページ]のRFC5387BTNS問題と適用性2008年11月
1. Introduction
1. 序論
Network security is provided by a variety of protocols at different layers in the stack. At the network layer, the IPsec protocol suite (consisting of IKE (Internet Key Exchange protocol), ESP (Encapsulating Security Payload), and AH (Authentication Header)) is used to secure IP traffic. IPsec, including IKE, offers high levels of security that provide protection from a wide array of possible threats, but authentication is required [5][7][8]. In turn, authentication requires deployment of authentication identities and credentials, which can be an obstacle to IPsec usage. This document discusses this dependency and introduces "Better-Than-Nothing Security" (BTNS) as one solution, whose goal is to provide a generally useful means of applying IPsec security services without requiring network-layer authentication.
さまざまなプロトコルはスタックの異なった層でネットワークセキュリティを提供します。 ネットワーク層では、IPsecプロトコル群(IKE(インターネットKey Exchangeは議定書を作る)、超能力(Securityが有効搭載量であるとカプセル化する)、およびAH(認証Header)から成る)は、IPトラフィックを保証するのに使用されます。 IKEを含むIPsecが可能な脅威の広い勢ぞろいから保護を提供する高いレベルのセキュリティを提供しますが、認証は必要な[5][7][8]です。 順番に、認証は認証のアイデンティティと資格証明書の展開を必要とします。(資格証明書はIPsec用法への障害であるかもしれません)。 このドキュメントは、この依存について議論して、ネットワーク層認証を必要としないでIPsecセキュリティー・サービスを適用する一般に役に立つ手段を提供する目標がことである1つのソリューションとして「ないよりましなセキュリティ」(BTNS)を導入します。
1.1. Authentication
1.1. 認証
There are two primary architectural approaches to authentication: employing out-of-band communications and using pre-deployed information. Out-of-band authentication can be done via a trusted third party, via a separate communication channel to the peer, or via the same channel as the communications to be secured but at a higher layer. Out-of-band authentication requires mechanisms and interfaces to bind the authenticated identities to the secure communication channels, and is out of scope for this document (although it may be possible to extend the channel binding mode of BTNS to work with such mechanisms). Pre-deployed information includes identities, pre- shared secrets, and credentials that have been authenticated by trusted authorities (e.g., a certificate and its corresponding private key).
認証への2つのプライマリ建築アプローチがあります: バンドの外でコミュニケーションを使って、使用は情報をあらかじめ配布しました。 バンドの外では、信頼できる第三者機関を通して認証できます、同輩かしかし、より高い層で保証されるコミュニケーションと同じチャンネルを通した別々の通信チャネルで。 バンドの外に、認証は、安全な通信チャネルへの認証されたアイデンティティを縛るためにメカニズムとインタフェースを必要として、範囲の外にこのドキュメントのためにあります(そのようなメカニズムで働くためにBTNSのモードを縛るチャンネルを広げるのが可能であるかもしれませんが)。 あらかじめ配布している情報はアイデンティティ、プレ共有秘密キー、および信じられた当局によって認証された資格証明書(例えば、証明書とその対応する秘密鍵)を含んでいます。
This form of authentication often requires manual deployment and coordination among communicating peers. Furthermore, obtaining and deploying credentials such as certificates signed by certification authorities (CA) involves additional protocol and administrative actions that may incur significant time and effort to perform.
同輩を伝える中でこの形式の認証はしばしば手動の展開とコーディネートを必要とします。 その上、証明当局(カリフォルニア)によって署名された証明書などの資格証明書を得て、配布すると、働くために重要な時間と取り組みを被るかもしれない追加議定書と管理動作がかかわります。
These factors increase the work required to use IKE with IPsec for peer authentication. Consequently, some users and applications do not use IPsec to protect traffic at the network layer, but rely instead on higher-layer security protocols (e.g., TLS [4]) or operate without any security. As Section 2.2.1 describes, higher-layer security protocols may not be enough to protect against some network-layer attacks.
これらの要素は同輩認証のためにIPsecと共にIKEを使用するのに必要である仕事を増強します。 または、その結果、いくつかのユーザとアプリケーションがネットワーク層でトラフィックを保護するのにIPsecを使用しませんが、代わりにより高い層のセキュリティプロトコルを当てにしてください、(例えば、TLS[4])、セキュリティなしでどんな作動してください。 セクション2.2.1が説明するように、より高い層のセキュリティプロトコルはいくつかのネットワーク層攻撃から守るために十分でないかもしれません。
Touch, et al. Informational [Page 3] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[3ページ]のRFC5387BTNS問題と適用性2008年11月
To improve the situation, one could either reduce the hurdles to obtain and configure authentication information or remove the requirement for authentication in IPsec. The latter approach is the core idea of BTNS, which provides anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers that do not possess requisite authentication credentials. This requires extensions to the IPsec architecture. As the new BTNS modes for IPsec relax the authentication requirement, the impacts, tradeoffs, and risks must be thoroughly understood before applying BTNS to any communications. More specifically, this document addresses the issues of whether and when network-layer authentication can be omitted, the risks of using BTNS, and finally, the impacts to the existing IPsec architecture.
1つは、状況を改善するために、IPsecでの認証のために入手するハードルを減少させて、認証情報を構成するか、または要件を取り除くかもしれません。 後者のアプローチはBTNSの中心となる考えです。(IPsecが必要な認証資格証明書を持っていない同輩と共にセキュリティ協会(SAs)を作成するように、BTNSは匿名(非認証される)の合わせることを提供します)。 これはIPsecアーキテクチャに拡大を必要とします。 新しいBTNSとして、IPsecのためのモードは認証要件を弛緩します、影響、見返り、そして、どんなコミュニケーションにもBTNSを適用する前に、危険を徹底的に理解しなければなりません。 より明確に、このドキュメントは省略していつネットワーク層認証を省略できるか、そして、BTNSを使用するリスク、および最終的に既存のIPsecアーキテクチャへの影響の問題を扱います。
BTNS employs a weaker notion of authenticated identity by comparison to most authentication protocols; this weaker notion is bootstrapped from the security association itself. This notion, called "continuity of association", doesn't mean "Bill Smith" or "owner of shared secret X2YQ", but means "the entity with which I have been communicating on connection #23". Continuity of association is only invariant within a single SA; it is not invariant across SAs, and hence can only be used to provide protection during the lifetime of an SA. This is a core notion used by BTNS, particularly in the absence of higher-layer authentication. Continuity of association can be viewed as a form of authentication in which an identity is not authenticated across separate associations or out-of-band, but does not change during the lifetime of the SA.
BTNSはほとんどの認証プロトコルとの比較で認証されたアイデンティティの、より弱い概念を使います。 このより弱い概念はセキュリティ協会自体から独力で進まれます。 「協会の連続」と呼ばれるこの概念は、「ビル・スミス」か「共有秘密キーX2YQの所有者」を意味しませんが、「私が接続#23インチについて話し合っている実体」を意味します。 協会の連続は独身のSAの中で不変であるだけです。 それは、SAsの向こう側に不変でなく、したがって、SAの生涯保護を提供するのに使用できるだけです。 これは特により高い層の認証がないときBTNSによって使用されたコア概念です。 SAの生涯アイデンティティがバンドの外で別々の協会の向こう側に認証されませんが、変化しない認証のフォームとして協会の連続を見なすことができます。
1.2. IPsec Channels and Channel Binding
1.2. IPsecチャンネルとチャンネル結合
When IPsec security services are used by higher-layer protocols, it is important to bind those services to higher-layer protocol sessions in order to ensure that the security services are consistently applied to the higher-layer traffic involved. The result of this binding is an "IPsec channel", and the act of creating an IPsec channel is an instance of channel binding. Channel binding is discussed in RFC 5056 [27] and in an associated connection latching document [26]. This subsection summarizes the portions of these documents that are essential to understanding certain aspects of BTNS.
IPsecセキュリティー・サービスが上位層プロトコルによって使用されるとき、上位層プロトコルセッションに対するそれらのサービスを縛るのは、セキュリティー・サービスが一貫してトラフィックがかかわったより高い層に適用されるのを確実にするために重要です。 この結合の結果は「IPsecチャンネル」です、そして、IPsecチャンネルを創造する行為はチャンネル結合のインスタンスです。 RFC5056[27]と関連接続かんぬきドキュメント[26]でチャンネル結合について議論します。 この小区分はBTNSのある一定の局面を理解しているのに不可欠のこれらのドキュメントの一部をまとめます。
A secure channel is a packet, datagram, octet stream connection, or sequence of connections between two endpoints that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it [27]. Applying this concept to IPsec, an "IPsec channel" is a packet flow associated with a higher-layer protocol session, such as a TCP connection, where all the packets are protected by IPsec SAs such that:
安全なチャンネルは、暗号の保全を提供する2つの終点の間の接続のパケット、データグラム、八重奏ストリーム接続、または系列です、そして、任意に、データへの秘密性はそれの上で[27]を交換しました。 この概念を適用して、IPsec、「IPsecチャンネル」にはすべてのパケットがIPsec SAsによって保護されるTCP接続などの上位層プロトコルセッションに関連しているパケット流動がある、以下のことのようなもの
Touch, et al. Informational [Page 4] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[4ページ]のRFC5387BTNS問題と適用性2008年11月
o the peer's identity is the same for the lifetime of the packet
flow, and
o そして同輩のアイデンティティがパケット流動の生涯同じである。
o the quality of IPsec protection used for the packet flow's
individual packets is the same for all of them for the lifetime of
the packet flow [26].
o それらのすべてに、パケット流動の個々のパケットに使用されるIPsec保護の品質はパケット流動[26]の生涯、同じです。
The endpoints of an IPsec channel are the higher-layer protocol endpoints, which are beyond the endpoints of the IPsec SAs involved. This creates a need to bind each IPsec SA to the higher-layer protocol session and its endpoints. Failure to do this binding creates vulnerabilities to man-in-the-middle (MITM) attacks, where what appears to be a single IPsec SA for the higher-layer protocol traffic is actually two separate SAs concatenated by the attacker acting as a traffic-forwarding proxy.
IPsecチャンネルの終点は上位層プロトコル終点です。(その終点はかかわったIPsec SAsの終点にあります)。 これは上位層プロトコルセッションとその終点に各IPsec SAを縛る必要性を作成します。 この結合をしない場合、中央の男性(MITM)攻撃に脆弱性を作成します、何が上位層プロトコルトラフィックのための独身のIPsec SAであるように見えるかが、実際にトラフィックを進めるプロキシとして務めている攻撃者によって連結された2別々のSAsであるところで。
The combination of connection latching [26] with channel binding [27] creates IPsec channels and binds IPsec SAs to higher-layer protocols. Connection latching creates an IPsec channel by associating IPsec SAs to higher-layer protocol sessions, and channel binding enables a higher-layer protocol to bind its authentication to the IPsec SAs. Caching of this "latch" across higher-layer protocol sessions is necessary to counter inter-session spoofing attacks, and the channel binding authentication should be performed on each higher-layer protocol session. Connection latching and channel binding are useful not only for BTNS but also for IPsec SAs whose peers are fully authenticated by IKE during creation of the SA.
チャンネル結合[27]で[26]に掛け金をおろしている接続の組み合わせは、上位層プロトコルにIPsecチャンネルを創造して、IPsec SAsを縛ります。 接続かんぬきは上位層プロトコルセッションまでIPsec SAsを関連づけることによって、IPsecチャンネルを創造します、そして、チャンネル結合は上位層プロトコルがIPsec SAsに認証を縛るのを可能にします。 上位層プロトコルセッションの向こう側のこの「掛け金」のキャッシュが相互セッションスプーフィング攻撃に対抗するのに必要です、そして、認証を縛るチャンネルはそれぞれの上位層プロトコルセッションのときに実行されるべきです。 接続かんぬきとチャンネル結合は単にBTNSの役に立つのではなく、同輩がSAの作成の間にIKEによって完全に認証されるIPsec SAsのも役に立ちます。
Channel binding for IPsec is based on information obtained from the SA creation process that uniquely identifies an SA pair. Channel binding can be accomplished by adding this identifying information to higher-layer authentication mechanisms based on one-way hashes, key exchanges, or (public key) cryptographic signatures; in all three cases, the resulting higher-layer authentication resists man-in-the- middle attacks on SA creation. When each IKE peer uses a public- private key pair for IKE authentication to create an SA pair, the pair of public keys used (one for each peer) suffices for channel binding; strong incorporation of this information into higher-layer authentication causes that higher-layer authentication to fail when an MITM attacker has concatenated separate SAs by acting as a traffic-forwarding proxy.
IPsecのためのチャンネル結合は唯一SA組を特定するSA作成プロセスから得られた情報に基づいています。 一方向ハッシュ、主要な交換、または(公開鍵)暗号の署名に基づくより高い層の認証機構にこの身元が分かる情報を追加することによって、チャンネル結合を実行できます。 すべての3つの場合では、結果として起こるより高い層の認証が中の男性に抵抗する、-、-中央はSA作成で攻撃されます。 IKE認証がSA組を創設するのにそれぞれのIKE同輩が公立の秘密鍵組を使用するとき、使用される公開鍵(各同輩あたり1つ)の組はチャンネル結合に十分です。 MITM攻撃者がトラフィックを進めるプロキシとして務めることによって別々のSAsを連結したとき、より高い層の認証へのこの情報の強い編入はそのより高い層の認証に失敗されます。
Touch, et al. Informational [Page 5] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[5ページ]のRFC5387BTNS問題と適用性2008年11月
1.3. BTNS Methods
1.3. BTNSメソッド
There are two classes of scenarios in which BTNS may be used to apply IPsec services without network-layer authentication:
BTNSがネットワーク層認証なしでIPsecサービスを適用するのに使用されるかもしれない2つのクラスのシナリオがあります:
1. Protection of traffic for a higher-layer protocol that does not
use authentication. The resulting protection is "better than
nothing" because once an unauthenticated SA is successfully
created without an MITM, that SA's IPsec security services resist
subsequent MITM attacks even though the absence of authentication
allows the initial creation of the BTNS-based security association
(SA) to be subverted by an MITM. This method of using BTNS is
called Stand-Alone BTNS (SAB) because it does not rely on any
security services outside of IPsec.
1. 認証を使用しない上位層プロトコルのためのトラフィックの保護。 認証の欠如が、BTNSを拠点とするセキュリティ協会(SA)の初期の創設がMITMによって打倒されるのを許容しますが、unauthenticated SAがMITMなしでいったん首尾よく作成されると、そのSAのIPsecセキュリティー・サービスがその後のMITM攻撃に抵抗するので、結果として起こる保護は「ないよりまし。」です。 BTNSを使用するこのメソッドは少しのセキュリティも当てにしないので呼ばれたStandだけBTNS(SAB)がIPsecの外部を修理するということです。
2. Protection of traffic generated by a higher-layer protocol that
uses authentication. The "better-than-nothing" protection in this
case relies on the strength of the higher-layer protocol's
authentication and the channel binding of that authentication with
the BTNS-based SAs. The level of protection may be comparable to
the level afforded by the use of network-layer IKE authentication
when the higher-layer protocol uses strong authentication and
strong channel binding is employed to associate the BTNS-based SA
with that higher-layer authentication. This method of using BTNS
is called Channel-Bound BTNS (CBB) when the combination of the
higher-layer authentication and channel binding is sufficient to
detect an MITM attack on creation of a BTNS-based SA.
2. 認証を使用する上位層プロトコルによって生成されたトラフィックの保護。 「ないよりまし」の保護はこの場合上位層プロトコルの認証の強さとBTNSベースのSAsとのその認証のチャンネル結合に依存します。 保護のレベルは上位層プロトコルが強い認証を使用して、強いチャンネル結合がそのより高い層の認証にBTNSベースのSAを関連づけるのに使われるときネットワーク層IKE認証の使用で提供されたレベルに匹敵しているかもしれません。 より高い層の認証とチャンネル結合の組み合わせがBTNSベースのSAの作成に対するMITM攻撃を検出するために十分であるときに、BTNSを使用するこのメソッドはChannelによって制限されたBTNS(CBB)と呼ばれます。
It is possible to combine IKE authentication for one end of an SA pair with BTNS's absence of network-layer authentication for the other end. The resulting asymmetric authentication creates asymmetric modes of BTNS that are discussed further in Section 3.2 below.
1SA組の片端のためのBTNSのネットワーク層認証の欠如によるIKE認証をもう一方の端に結合するのは可能です。 結果として起こる非対称の認証は以下のセクション3.2で、より詳しく議論するBTNSの非対称のモードを作成します。
1.4. BTNS Scope
1.4. BTNS範囲
The scope of BTNS is to provide a generally useful means of applying IPsec security services that does not require network-level authentication credentials. The following areas are outside this scope of BTNS and hence are not discussed further in this document:
BTNSの範囲はネットワークレベル認証資格証明書を必要としないIPsecセキュリティー・サービスを適用する一般に役に立つ手段を提供することになっています。 以下の領域について、BTNSのこの範囲の外にあって、したがって、さらに本書では議論しません:
1. Use of security frameworks other than IPsec to provide security
services for higher-layer protocols. There are a variety of
security service frameworks other than IPsec, such as TLS [4],
Simple Authentication and Security Layer (SASL) [11], and Generic
Security Service Application Program Interface (GSS-API) [10], as
well as a variety of non-IPsec security mechanisms, such as TCP
1. 上位層プロトコルのためのセキュリティー・サービスを提供するIPsec以外のセキュリティフレームワークの使用。 IPsec以外のさまざまなセキュリティー・サービスフレームワークがあります、TLS[4]、Simple Authentication、およびSecurity Layer(SASL)[11]や、Generic Security Service Application Program Interface(GSS-API)[10]などのように、さまざまな非IPsecセキュリティー対策と同様に、TCPなどのように
Touch, et al. Informational [Page 6] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[6ページ]のRFC5387BTNS問題と適用性2008年11月
MD5 [6], that are described in other documents. BTNS is based on
IPsec by design; it will not always be the most appropriate
solution.
MD5[6]、それは他のドキュメントで説明されます。 BTNSは故意にIPsecに基づいています。 それはいつも最も適切なソリューションになるというわけではないでしょう。
2. Use of the Extensible Authentication Protocol (EAP) for IKE
authentication. Section 1.3 of RFC 3748 clearly restricts EAP's
applicability to network access protocols [1]:
2. 拡張認証プロトコル(EAP)のIKE認証の使用。 RFC3748のセクション1.3は明確にEAPの適用性をネットワークアクセス・プロトコル[1]に制限します:
"EAP was designed for use in network access authentication,
where IP layer connectivity may not be available. Use of EAP
for other purposes, such as bulk data transport, is NOT
RECOMMENDED."
「IP層の接続性が利用可能でないかもしれないところでEAPはネットワークアクセス認証における使用のために設計されました。」 「EAPの大量のデータ伝送などの他の目的の使用はNOT RECOMMENDEDです。」
Hence, EAP authentication for IKE is only applicable to situations
where IKE is being used to establish network access (e.g., create
a Virtual Private Network (VPN) connection). In contrast, the
BTNS goal of general applicability encompasses many areas other
than network access and specifically includes protocols that
transfer large amounts of data, such as iSCSI [19] and NFSv4 [21].
したがって、IKEのためのEAP認証は単にIKEがネットワークアクセスを証明するのに使用されている(例えば、Virtual兵士のNetwork(VPN)接続を創造してください)状況に適切です。 対照的に、一般的な適用性のBTNS目標は、ネットワークアクセス以外の多くの領域を取り囲んで、明確に多量のデータを移すプロトコルを含んでいます、iSCSI[19]やNFSv4[21]のように。
3. Manual keying is not considered for BTNS because manual keying is
unsafe for protocols that transfer large amounts of data (e.g.,
RFC 3723 forbids use of manual keying with the IP Storage
protocols, including iSCSI, for this reason [2]).
3. 多量のデータを移すプロトコルに、手動の合わせるのが危険であるので、マニュアルの合わせることはBTNSのために考えられません。(例えば、RFC3723はIPと共にStorageプロトコルを合わせながら、マニュアルの使用を禁じます、iSCSIを含んでいて、この理由[2])で。
1.5. Structure of This Document
1.5. このドキュメントの構造
The next section discusses the motivations for BTNS, primarily based on the implications of IKE's requirements for network-layer authentication. Section 3 provides a high level overview of BTNS, both SAB and CBB. Section 3 also includes descriptions of the security services offered and the BTNS modes of operation (based on combinations of SAB, CBB, and/or IKE authentication). Section 4 explores the applicability of all of the modes of BTNS. This is followed by a discussion of the risks and other security considerations in Section 5. Section 6 briefly describes other related efforts.
次のセクションはBTNSと、主としてネットワーク層認証のためのIKEの要件の含意に基づいて動機について論じます。 セクション3はBTNSの高い平らな概要、SABとCBBの両方を提供します。 また、セクション3はサービスが提供したセキュリティとBTNS運転モード(SAB、CBB、そして/または、IKE認証の組み合わせに基づいている)の記述を含めます。 セクション4はBTNSのモードのすべての適用性について調査します。 セクション5における、リスクと他のセキュリティ問題の議論はこれのあとに続いています。 セクション6は簡潔に他の関連する取り組みについて説明します。
2. Problem Statement
2. 問題声明
This section describes the problems that motivated the development of BTNS. The primary concern is that IPsec is not widely utilized despite rigorous development effort and emphasis on network security by users and organizations. There are also differing viewpoints on which layer is best for securing network communications and how security protocols at different layers should interact. The following discussion roughly categorizes these issues by layers: network layer and higher layers.
このセクションはBTNSの開発を動機づけた問題について説明します。 プライマリ関心はネットワークセキュリティへの厳しい開発努力と強調にもかかわらず、ユーザと組織によって利用されて、IPsecが広くそうでないということです。 ネットワークコミュニケーションと異なった層のセキュリティプロトコルがどう相互作用するべきであるかを保証するのに、どの層が最も良いかに関してまた、異なった観点があります。 以下の議論は層のそばで手荒くこれらの問題を分類します: ネットワーク層と、より高い層。
Touch, et al. Informational [Page 7] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[7ページ]のRFC5387BTNS問題と適用性2008年11月
2.1. Network Layer
2.1. ネットワーク層
At the network layer, one of the hurdles is to satisfy the authentication requirements of IPsec and IKE. This section discusses some drawbacks of network-layer authentication and the results of these requirements.
ネットワーク層では、ハードルのひとりはIPsecとIKEの認証要件を満たすことになっています。 このセクションはネットワーク層認証のいくつかの欠点とこれらの要件の結果について論じます。
2.1.1. Authentication Identities
2.1.1. 認証のアイデンティティ
Current IPsec authentication supports several types of identities in the Peer Authorization Database (PAD): IPv4 addresses, IPv6 addresses, DNS names, Distinguished Names, RFC 822 email addresses, and Key IDs [8]. All require either certificates or pre-shared secrets to authenticate. The identities supported by the PAD can be roughly categorized as network-layer identifiers or other identifiers.
現在のIPsec認証はPeer Authorization Database(PAD)でいくつかのタイプのアイデンティティをサポートします: IPv4アドレス、IPv6アドレス、DNS名、Distinguished Names、RFC822Eメールアドレス、およびKey ID[8]。 証明書かプレ共有秘密キーのどちらかが認証するのがすべて必要です。 ネットワーク層識別子か他の識別子として手荒くPADによってサポートされたアイデンティティは分類できます。
The first three types of identifiers -- IPv4 addresses, IPv6 addresses and DNS names -- are network-layer identifiers. The main deficiency of IP addresses as identifiers is that they often do not consistently represent the same physical systems due to the increasing use of dynamic address assignments (DHCP) and system mobility. The use of DNS names is also affected because the name to address mapping is not always up to date as a result. Stale mapping information can cause inconsistencies between the IP address recorded in the DNS for a named system and the actual IP address of that system, leading to problems if the DNS is used to cross-check the IP address from which a DNS name was presented as an identifier. DNS names are also not always under the control of the endpoint owner.
最初の3つのタイプに関する識別子(IPv4アドレス、IPv6アドレス、およびDNS名)はネットワーク層識別子です。 識別子としてのIPアドレスの主な欠乏は彼らがダイナミックなアドレス課題(DHCP)とシステムの移動性の増加する使用のためしばしば一貫して同じ物理的なシステムを表すというわけではないということです。 また、アドレス・マッピングへの名前がいつもその結果最新であるというわけではないので、DNS名の使用は影響を受けます。 聞き古したマッピング情報は命名されたシステムのためにDNSに記録されたIPアドレスとそのシステムの実際のIPアドレスの間の矛盾を引き起こす場合があります、DNSがDNS名が識別子として提示されたIPアドレスにクロスチェックするのに使用されるなら問題を引き起こして。 DNS名がいつも終点所有者のいずれのコントロールの下にもあるというわけではありません。
There are two main drawbacks with the other, non-network-layer identifiers defined for the PAD. The PAD functionality can be overly restrictive because there are other forms of identifiers not covered by the PAD specification (EAP does not loosen these restrictions in general; see Section 1.4). Use of any non-network-layer identifiers for IPsec authentication may result in multiple authentications for the same or different identifiers at different layers, creating a need to associate authentications and new error cases (e.g., one of two authentications for the same identifier fails). These issues are also related to channel binding and are further discussed later in this document.
他の、そして、非ネットワーク層の識別子がPADのために定義されている2つの主な欠点があります。 PAD仕様でカバーされなかった他のフォームに関する識別子があるので(EAPは一般に、これらの制限を緩和しません; セクション1.4を見てください)、PADの機能性はひどく制限している場合があります。 どんな非ネットワーク層識別子のIPsec認証の使用も異なった層の同じであるか異なった識別子のための複数の認証をもたらすかもしれません、認証を関連づける必要性と新しい誤り事件を引き起こして(例えば同じ識別子のための2つの認証の1つは失敗します)。 これらの問題について、また、チャンネル結合に関連して、後でさらに本書では議論します。
2.1.2. Authentication Methods
2.1.2. 認証方法
As described earlier, certificates and pre-shared secrets are the only methods of authentication accepted by current IPsec and IKE specifications. Pre-shared secrets require manual configuration and out-of-band communications. The verification process for
より早く説明されるように、証明書とプレ共有秘密キーは現在のIPsecとIKE仕様で受け入れられた認証の唯一のメソッドです。 プレ共有秘密キーは手動の構成とバンドのアウトコミュニケーションを必要とします。 検証は処理します。
Touch, et al. Informational [Page 8] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[8ページ]のRFC5387BTNS問題と適用性2008年11月
certificates is cumbersome, plus there are administrative and potential monetary costs in obtaining certificates. These factors are among the possible reasons why IPsec is not widely used outside of environments with the highest security requirements.
証明書は扱いにくいです、そして、証明書を入手するのにおいて管理の、そして、潜在的の通貨のコストがあります。 IPsecが最も高いセキュリティ要件と共に環境の外で広く使用されない可能な理由の中にこれらの要素があります。
2.1.3. Current IPsec Limits on Unauthenticated Peers
2.1.3. Unauthenticated同輩における現在のIPsec限界
Pre-configuration of Security Policy Database (SPD) "bypass" entries to enable communication with unauthenticated peers only works if the peer IP addresses are known in advance. The lack of unauthenticated IPsec modes often prevents secure communications at the network layer with unauthenticated or unknown peers, even when they are subsequently authenticated in a higher-layer protocol or application. The lack of a channel binding API between IPsec and higher-layer protocols may further force such communications to completely bypass IPsec, leaving the network layer of such communications unprotected.
同輩IPアドレスがあらかじめ知られている場合にだけ、非認証された同輩とのコミュニケーションを可能にするSecurity Policy Database(SPD)「迂回」エントリーのプレ構成は働いています。 unauthenticated IPsecモードの不足は非認証されたか未知の同輩と共にネットワーク層で安全なコミュニケーションをしばしば防ぎます、彼らが次に上位層プロトコルかアプリケーションで認証さえされるとき。 そのようなコミュニケーションはAPIを縛るチャンネルの不足によってIPsecと上位層プロトコルの間にIPsecを完全にさらにやむを得ず迂回させるかもしれません、そのようなコミュニケーションのネットワーク層を保護がない状態でおいて。
2.2. Higher-Layer Issues
2.2. より高い層の問題
For higher layers, the next subsection focuses on whether IPsec is necessary if transport layer security is already in use. The use of IPsec in the presence of transport security provides further motivation for reducing the administrative burdens of using IPsec. This is followed by a discussion of the implications of using authentication at both the network layer and a higher layer for the same connection.
より高い層のために、次の小区分はトランスポート層セキュリティが既に使用中であるならIPsecが必要であるかどうか集中します。 輸送セキュリティがあるときIPsecの使用はIPsecを使用する管理負担を減少させることに関するさらなる動機を提供します。 使用認証の含意の議論は同じ接続のためのネットワーク層と、より高い層の両方でこれのあとに続いています。
2.2.1. Transport Protection from Packet Spoofing
2.2.1. パケットスプーフィングからの輸送保護
Consider the case of transport protocols. Increases in network performance and the use of long-lived connections have resulted in increased vulnerability of connection-oriented transport protocols to certain forms of attacks. TCP, like many other protocols, is susceptible to off-path third-party attacks, such as injection of a TCP RST [24]. The Internet lacks comprehensive ingress filtering to discard such spoofed traffic before it can cause damage. These attacks can affect BGP sessions between core Internet routers, and are thus of significant concern [3][12]. As a result, a number of proposed solutions have been developed, most of which are at the transport layer.
トランスポート・プロトコルに関するケースを考えてください。 長命の接続の性能と使用がもたらしたネットワークの増加は接続指向のトランスポート・プロトコルの脆弱性をある形式の攻撃に増強しました。 他の多くのプロトコルのように、TCPはTCP RST[24]の注射などのオフ経路第三者攻撃に影響されやすいです。 インターネットは損害を与えることができる前にトラフィックであると偽造されたそのようなものを破棄にフィルターにかける包括的なイングレスを欠いています。 その結果、これらの攻撃は、重要な関心[3][12]のコアインターネットルータの間のBGPセッションに影響できて、ものです。 その結果、どれがトランスポート層にあるかについて多くの提案された解決策が最も見いだされました。
Some of these solutions augment the transport protocol by improving its own security, e.g., TCP MD5 [6]. Others modify the core TCP processing rules to make it harder for off-path attackers to inject meaningful packets either during the initial handshake (e.g., SYN cookies) or after a connection is established (e.g., TCPsecure) [15][23]. Some of these approaches are new to TCP, but have already
これらのソリューションのいくつかが、それ自身のセキュリティ、例えばTCP MD5[6]を改良することによって、トランスポート・プロトコルを増大させます。 他のものがオフ経路攻撃者が初期の握手(例えば、SYNクッキー)の間、重要なパケットを注入するのをより困難にするようにコアTCP処理規則を変更するか、または接続の後に、確立した(例えば、TCPsecure)[15][23]があります。 既に新しかったのを除いて、これらのアプローチのいくつかがTCPに新しいです。
Touch, et al. Informational [Page 9] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[9ページ]のRFC5387BTNS問題と適用性2008年11月
been incorporated into other transport protocols (e.g., Stream Control Transmission Protocol (SCTP) [22]) or intermediate (so-called layer 3.5) protocols (e.g., Host Identity Protocol (HIP) [14]).
他のトランスポート・プロトコルに組み入れられる、(例えば、Stream Control Transmissionプロトコル(SCTP)[22])か中間的な(いわゆる層3.5)プロトコル、(例えば、Host Identityプロトコル(HIP)[14])。
TCP MD5 and its potential successor, TCP Auth [25], are based on authentication; TCP-specific modifications that lack authentication are, at best, temporary patches to the ubiquitous vulnerability to spoofing attacks. The obvious solution to spoofing is end-to-end validation of the traffic, either at the transport layer or the network layer. The IPsec suite already provides authentication of a network-layer packet and its contents, but the costs of an authentication infrastructure required for the use of IPsec can be prohibitive. Similarly, TCP MD5 requires pre-shared keys, which can likewise be prohibitive. TCP Auth is currently under development, and may include a BTNS-like mode.
TCP MD5とその潜在的後継者(TCP Auth[25])は認証に基づいています。 認証を欠いているTCP特有の変更はスプーフィング攻撃への遍在している脆弱性へのせいぜい一時的なパッチです。 スプーフィングの明らかな解決法は終わりから終わりへのトランスポート層かネットワーク層におけるトラフィックの合法化です。 IPsecスイートは既にネットワーク層パケットとそのコンテンツの認証を提供しますが、IPsecの使用に必要である認証インフラストラクチャのコストはひどく高い場合があります。 同様に、TCP MD5はあらかじめ共有されたキーを必要とします。(キーは同様に禁止である場合があります)。 TCP Authは現在、開発中であり、BTNSのようなモードを含むかもしれません。
Protecting systems from spoofed packets is ultimately an issue of authentication, ensuring that a receiver's interpretation of the source of a packet is accurate. Authentication validates the identity of the source of the packet. The current IPsec suite assumes that identity is validated either by a trusted third party -- e.g., a certification authority -- or by a pre-deployed shared secret. Such an identity is unique and invariant across associations (pair-wise security configuration), and can be used to reject packets that are not authentic.
結局偽造しているパケットからシステムを保護するのは、認証の問題です、受信機のパケットの源の解釈が確実に正確になるようにして。 認証はパケットの源のアイデンティティを有効にします。 現在のIPsecスイートは、アイデンティティが信頼できる第三者機関(例えば、証明権威)かあらかじめ配布している共有秘密キーによって有効にされると仮定します。 そのようなアイデンティティは、協会(対状セキュリティ設定)の向こう側にユニークであって、不変であり、正統でないパケットを拒絶するのに使用できます。
With regard to BGP in particular, it has been understood that the use of appropriate network- or transport-layer authentication is the preferred protection from TCP spoofing attacks [3]. Authentication at one router by itself does not provide overall BGP security because that router remains at the mercy of all routers it peers with, since it depends on them to also support authentication [25]. The reality is that few Internet routers are configured to support authentication at all, and the result is the use of unsecured TCP for sending BGP packets. BTNS allows an individual router to relax the need for authentication in order to enable the use of protected sessions that are not authenticated. The latter is "better than nothing" in cases where "nothing" is the alternative. Although the routing community has chosen solutions other than BTNS for protection of BGP's TCP connections (e.g., TCP MD5), the discussion of BGP remains in this document because it was a motivation for the development of BTNS.
特にBGPに関して、適切なネットワークかトランスポート層認証の使用が攻撃が[3]であると偽造するTCPからの都合のよい保護であることが理解されています。 そのルータがそれがじっと見るすべてのルータの思うままに残っているので、それ自体で1つのルータにおける認証は総合的なBGPセキュリティを提供しません、また、認証が[25]であるとサポートするためにそれらによるので。 現実はわずかなインターネットルータしか全く認証をサポートするために構成されないということです、そして、結果はunsecured TCPの送付BGPパケットの使用です。 BTNSは、個々のルータに、認証されない保護されたセッションの使用を可能にするために認証の必要性を弛緩させます。 後者は「何でもない」が代替手段である場合で「ないよりまし。」です。 ルーティング共同体はBGPのTCP接続(例えば、TCP MD5)の保護のためのBTNS以外のソリューションを選びましたが、本書ではそれがBTNSの開発に関する動機であったのでBGPの議論は、残っています。
2.2.2. Authentication at Multiple Layers
2.2.2. 複数の層での認証
Some existing protocols used on the Internet provide authentication above the network and transport layers but rely on the IPsec suite for packet-by-packet cryptographic integrity and confidentiality services. Examples of such protocols include iSCSI [19] and the
インターネットで使用されるいくつかの既存のプロトコルが、ネットワークとトランスポート層の上に認証を供給しますが、パケットごとの暗号の保全と秘密性サービスのためにIPsecスイートを当てにします。 そしてそのようなプロトコルに関する例がiSCSI[19]を含んでいる。
Touch, et al. Informational [Page 10] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[10ページ]のRFC5387BTNS問題と適用性2008年11月
remote direct data placement (RDDP) protocols [16][20]. With the current IPsec suite, the result is two authentication operations: one at the IPsec layer using an identity for IKE and an associated secret or key, and another by the higher-layer protocol using a higher-layer identity and secret or key. With the current IPsec specifications, this redundant authentication is necessary because the identity and key formats differ between IPsec and the higher-layer protocol and/or because there is no standard interface to pass authentication results from IPsec up to the higher layer. End-node software is then responsible for ensuring that the identities used for these two authentication operations are consistent in some fashion; determining whether these identities are consistent is an authorization policy decision.
リモートダイレクトデータプレースメント(RDDP)プロトコル[16][20]。 現在のIPsecスイートで、結果は2つの認証操作です: IKEにアイデンティティを使用するIPsec層と関連秘密かキーの1、および、より高い層のアイデンティティと秘密かキーを使用する上位層プロトコルによる別。 現在のIPsec仕様で、アイデンティティと主要な形式がIPsecと上位層プロトコルの間で異なって、標準インターフェースが全くIPsecから認証結果を通過するために、より高い層まで達していないので、この余分な認証が必要です。 次に、これらの2つの認証操作に使用されるアイデンティティが何らかのファッションで一貫しているのを確実にするのにエンドノードソフトウェアは原因となります。 これらのアイデンティティが一貫しているかどうか決定するのは、承認政策決定です。
Failure of the end-node software to enforce appropriate consistency across authentication operations at different layers creates man-in- the-middle attack opportunities at the network layer. An attacker may exploit this omission by interposing as a proxy; rather than impersonate the attacked endpoints, the attacker need only authenticate with identities that are acceptable to the attacked endpoints. The resulting success enables the attacker to obtain full access to the higher-layer traffic by passing the higher-layer authentication operation through without modification. In the complete absence of consistency checks on the identities used at different layers, higher-layer traffic may be accessible to any entity that can successfully authenticate at the network layer.
エンドノードソフトウェアが異なった層での認証操作の向こう側に適切な一貫性を実施しない場合中の人間を創造する、-、-、中央、ネットワーク層における機会を攻撃してください。 攻撃者はプロキシとして挿入することによって、この省略を利用するかもしれません。 むしろ、攻撃者は攻撃された終点をまねるよりまねるだけでよいです。攻撃された終点に許容できるアイデンティティで、認証します。 結果として起こる成功は、攻撃者が変更なしで終えたより高い層の認証操作を通過することによって、より高い層のトラフィックへの完全なアクセスを得るのを可能にします。 異なった層で使用されるアイデンティティにおける一貫性チェックの完全欠損では、より高い層のトラフィックはそれがネットワーク層で首尾よく認証できるどんな実体にもアクセスしやすいかもしれません。
In principle, a single authentication operation should suffice to protect the higher-layer traffic, removing the need for:
原則として、以下の必要性を取り除いて、ただ一つの認証操作は、より高い層のトラフィックを保護するために十分であるべきです。
o the second authentication operation,
o 2番目の認証操作
o configuration and management of the identities and secrets or keys
for the second authentication (even if the identities and secrets
or keys are the same, the two authentication operations may employ
different repositories for identities, secrets, and keys), and
o そして2番目の認証(アイデンティティと秘密かキーが同じであっても、2つの認証操作がアイデンティティ、秘密、およびキーに異なった倉庫を使うかもしれない)のためのアイデンティティと秘密かキーの構成と管理。
o determining in some fashion that the two authenticated identities
are consistent. As noted above, there are significant potential
MITM vulnerabilities if this is not done.
o 2が認証した何らかのファッションで、アイデンティティが一貫していることを決定します。 上で述べたように、これが完了していないなら、大きな潜在的可能性MITM脆弱性があります。
IPsec may not always be present for these higher-layer protocols, and even when present, may not always be used. Hence, if there is a choice, the higher-layer protocol authentication is preferable as it will always be available for use, independent of IPsec.
IPsecはこれらの上位層プロトコルのためにいつも存在していて、プレゼントがいつも使用されてさえいるというわけではないとき、存在しないかもしれません。 したがって、選択があれば、上位層プロトコル認証はいつも使用に利用可能になるように望ましいです、IPsecの如何にかかわらず。
Touch, et al. Informational [Page 11] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[11ページ]のRFC5387BTNS問題と適用性2008年11月
A "better-than-nothing" security approach to IPsec can address this problem by setting up an IPsec security association without an authentication, and then using an extended form of the higher-layer authentication to establish that the higher-layer protocol session is protected by a single IPsec SA. This counters man-in-the-middle (MITM) attacks on BTNS IPsec session establishment by terminating the higher-layer session via an authentication failure when such an attack occurs. The result is that a single authentication operation validates not only the higher-layer peer's identity but also continuity of the security association to that peer. This higher- layer check for a single IPsec SA is referred in this document as "channel binding", thus the name Channel-Bound BTNS (CBB) [27].
IPsecへの「ないよりまし」のセキュリティアプローチは、上位層プロトコルセッションが独身のIPsec SAによって保護されると証明するのに認証なしでIPsecセキュリティ協会を設立して、次に、より高い層の認証の拡張型を使用することによって、このその問題を訴えることができます。 認証失敗を通したそのような攻撃が起こるより高い層のセッションを終えることによって、これはBTNS IPsecセッション設立に対する中央の男性(MITM)攻撃に対抗します。 結果はただ一つの認証操作が、より高い層の同輩のアイデンティティだけではなく、セキュリティ協会の連続もその同輩に有効にするということです。 この独身のIPsec SAには、より高い層のチェックはその結果、本書では「チャンネル結合」、[27]という名前のChannelによって制限されたBTNS(CBB)として参照されます。
3. BTNS Overview and Threat Models
3. BTNS概要と脅威モデル
This section provides an overview of BTNS and the IPsec security services that are offered when BTNS is used. It also describes the multiple operating modes of BTNS.
このセクションはBTNSが使用されているとき提供されるBTNSの概要とIPsecセキュリティー・サービスを提供します。 また、それはBTNSの複数のオペレーティング・モードを説明します。
3.1. BTNS Overview
3.1. BTNS概要
This is an overview of what is needed in IPsec to enable BTNS. The detailed specifications of the extensions are addressed by the relevant protocol specifications.
これは何がBTNSを有効にするのにIPsecで必要であるかに関する概要です。 拡大の仕様詳細は関連プロトコル仕様で扱われます。
The main update to IPsec is adding extensions to security policy that permit secure communications with unauthenticated peers. These extensions are necessary for both IPsec and IKE. For IPsec, the first extension applies to the PAD, which specifies the forms of authentication allowed for each IKE peer. In addition to existing forms of authentication, such as X.509 certificates and pre-shared secrets, the extension adds an unauthenticated category in which the public key presented by the peer serves as its identity (and is authenticated by the peer demonstrating knowledge of the corresponding private key) [28]. The second extension is that a flag is added to each SPD entry to indicate whether BTNS lack of authentication is acceptable for that SPD entry.
IPsecへの主なアップデートは安全保障政策への非認証された同輩との安全なコミュニケーションを可能にする拡大を加えています。 これらの拡大がIPsecとIKEの両方に必要です。 IPsecに関しては、最初の拡大はPADに適用されます。(PADはそれぞれのIKE同輩のために許された認証のフォームを指定します)。 認証のX.509証明書やプレ共有秘密キーなどの既存の形に加えて、拡大は同輩によって提示された公開鍵がアイデンティティとして[28]に役立つ(そして、対応する秘密鍵に関する知識を示す同輩が認証されます)非認証されたカテゴリを加えます。 2番目の拡大は旗がそのSPDエントリーにおいて、認証のBTNS不足が許容できるかどうかを示すためにそれぞれのSPDエントリーに加えられるということです。
The changes to enable channel binding between IPsec and higher-layer protocols or applications are more complex than the policy extensions above. They require specifying APIs and interactions between IPsec and higher-layer protocols. This document assumes such provisions will be developed, but does not address their details.
可能にする変化がIPsecと上位層プロトコルの間に結合を向けるか、またはアプリケーションは上の方針拡大より複雑です。 彼らは、IPsecと上位層プロトコルとのAPIと相互作用を指定するのを必要とします。 このドキュメントは、そのような条項が開発されていると仮定しますが、それらの詳細を扱いません。
Touch, et al. Informational [Page 12] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[12ページ]のRFC5387BTNS問題と適用性2008年11月
3.2. BTNS and IPsec Security Services
3.2. BTNSとIPsecセキュリティー・サービス
The changes and extensions of BTNS primarily affect IPsec policy as described above. Other parts of IPsec and IKE specifications are unchanged. BTNS does not require a separate IPsec implementation, as BTNS can be integrated with any IPsec implementation in a system. The scope of BTNS functionality applies only to the SAs matching the policies that explicitly specify or enable BTNS modes in the PAD and for which the corresponding SPD entries allow BTNS. All other non- BTNS policy entries, including entries in the SPD and the PAD, and non-BTNS SAs are not affected by BTNS.
BTNSの変化と拡大は上で説明されるように主としてIPsec方針に影響します。 IPsecとIKE仕様の他の部分は変わりがありません。 BTNSは、システムのどんなIPsec実装ともBTNSを統合できるので、別々のIPsec実装を必要としません。 BTNSの機能性の範囲は、明らかにPADのBTNSモードを指定するか、または可能にして、対応するSPDエントリーがBTNSを許容する方針を合わせながら、SAsだけに適用されます。 SPDとPADにエントリーを含む他のすべての非BTNSの方針エントリーと非BTNS SAsはBTNSで影響を受けません。
In principle, the result of removing the requirement that all SAs be authenticated is that BTNS can establish secure IPsec connections in a fashion similar to fully authenticated IKE, but BTNS cannot verify or authenticate the peer identities of these SAs. The following is a list of security services offered by the IPsec protocol suite with notes that address the differences created by the addition of BTNS.
原則として、すべてのSAsが認証されるという要件を取り除くという結果がBTNSが完全に認証されたIKEと同様のファッションに安全なIPsec接続を確立できるということですが、BTNSはこれらのSAsの同輩のアイデンティティを確かめることができませんし、認証できません。 ↓これはBTNSの追加によって作成された違いを扱う注意があるIPsecプロトコル群によって提供されたセキュリティー・サービスのリストです。
1. Access Control
1. アクセス制御
BTNS extends IPsec's access control services to allow
unauthenticated connections. These extensions are integrated with
the IPsec PAD and SPD in a fashion that does not affect the access
controls associated with entries that do not use the BTNS
extensions. For Channel-Bound BTNS, the authentication that
applies to the SA is performed at a higher layer in a fashion that
links higher-layer access control policy to IPsec's network-layer
access control mechanisms.
BTNSは、非認証された接続を許すためにIPsecのアクセス制御サービスを広げています。 これらの拡大はIPsec PADとSPDについてBTNS拡張子を使用しないエントリーに関連しているアクセス制御に影響しないファッションで統合しています。 Channelによって制限されたBTNSに関しては、SAに適用される認証は、より高い層で、より高い層のアクセス制御方針をIPsecのネットワーク層アクセス管理機構にリンクするファッションで実行されます。
2. Data Origin Authentication
2. データ発生源認証
Stand-Alone BTNS weakens data origin authentication to continuity
of association, namely the assurance that traffic on an SA
continues to originate from the same unauthenticated source.
スタンドだけBTNSはすなわち、協会、SAの上のトラフィックが、同じ非認証されたソースから発し続けているという保証の連続にデータ発生源認証を弱めます。
Channel-Bound BTNS relies on higher-layer authentication to
provide data origin authentication of protected network traffic.
チャンネルで制限されたBTNSは、保護されたネットワークトラフィックのデータ発生源認証を提供するために、より高い層の認証に依存します。
3. Connectionless Integrity
3. コネクションレスな保全
4. Anti-Replay Protection
4. 反反復操作による保護
5. Confidentiality
5. 秘密性
Touch, et al. Informational [Page 13] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[13ページ]のRFC5387BTNS問題と適用性2008年11月
6. (Limited) Traffic Flow Confidentiality
6. (株式会社) 交通の流れ秘密性
For the security services offered by IPsec that are listed in
items 3 through 6, it is possible to establish secure IPsec
connections with rogue peers via BTNS because authentication is
not required. On the other hand, once a secure connection is
established, the communication is protected by these security
services in the same fashion as a connection established by
conventional IPsec means.
認証は必要でないので、項目3〜6に記載されているIPsecによって提供されたセキュリティー・サービスに、BTNSを通して凶暴な同輩との安全なIPsec接続を確立するのは可能です。 他方では、安全な接続がいったん確立されると、コミュニケーションは従来のIPsec手段で確立された接続と同じファッションでこれらのセキュリティー・サービスで保護されます。
3.3. BTNS and IPsec Modes
3.3. BTNSとIPsecモード
The previous sections have described two ways of using BTNS: Stand- Alone (SAB) and Channel-Bound (CBB). Both of these can also be used either symmetrically, where neither party authenticates at the network layer, or asymmetrically, where only one party does not authenticate at the network layer. There are a number of cases to consider, based on combinations of the endpoint security capabilities of SAB, CBB, and conventional IKE authentication of an identity (denoted as AUTH below). The following tables show all of the combinations based on the capabilities of the two security endpoints:
前項はBTNSを使用する2つの方法を述べました: 単独の(SAB)とチャンネル行きの(CBB)を立ててください。 また、対称的にこれらの両方を使用できます、1つだけがパーティーへ行くところでパーティーがネットワーク層において非対称的に認証しないどちらもそうしないところで。ネットワーク層では、認証します。 考える件数があります、SABの終点セキュリティ能力の組み合わせ、CBB、およびアイデンティティ(以下のAUTHとして、指示される)の従来のIKE認証に基づいて。 以下のテーブルは2つのセキュリティ終点の能力に基づく組み合わせのすべてを示しています:
| AUTH | SAB | | CB-AUTH | CBB |
-----+-------+-------+ -------+---------+---------+
| | | | | |
AUTH | AUTH | A-SAB | CB-AUTH| CB-AUTH | A-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
| | | | | |
SAB | A-SAB | S-SAB | CBB | A-CBB | S-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
| AUTH| サブ| | CB-AUTH| CBB| -----+-------+-------+ -------+---------+---------+ | | | | | | AUTH| AUTH| 1サブです。| CB-AUTH| CB-AUTH| 1CBBです。| | | | | | | -----+-------+-------+ -------+---------+---------+ | | | | | | サブ| 1サブです。| S-サブ| CBB| 1CBBです。| S-CBB| | | | | | | -----+-------+-------+ -------+---------+---------+
No Channel Binding With Channel Binding
チャンネル結合で付くチャンネルがありません。
There are six operating modes that result from the combinations. The first three modes consist of network-layer authentication schemes used without channel binding to higher-layer authentication:
組み合わせから生じる6つのオペレーティング・モードがあります。 最初の3つのモードがチャンネル結合なしで、より高い層の認証に使用されるネットワーク層認証体系から成ります:
1. AUTH: both parties provide and authenticate conventional, IKE-
supported identities.
1. AUTH: 双方が提供して、認証する、従来であり、IKEはアイデンティティをサポートしました。
2. Symmetric SAB (S-SAB): neither party authenticates with a
conventional, IKE-supported identity.
2. 左右対称のSAB(S-SAB): パーティーが従来の、そして、IKEによってサポートされたアイデンティティで認証しないどちらも。
3. Asymmetric SAB (A-SAB): one party does not authenticate with a
conventional, IKE-supported identity, but the other side does
authenticate with such an identity.
3. 非対称のSAB(A-SAB): パーティーがしかし、従来の、そして、IKEによってサポートされたアイデンティティ、反対側で認証しない人はそのようなものでアイデンティティを認証します。
Touch, et al. Informational [Page 14] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[14ページ]のRFC5387BTNS問題と適用性2008年11月
The following three modes combine the network-layer behaviors with channel binding to higher-layer authentication credentials:
以下の3つのモードが、より高い層の認証資格証明書とのチャンネル結合にネットワーク層の振舞いを結合します:
4. CB-AUTH: channel binding is used and both parties authenticate
with conventional, IKE-supported identities.
4. CB-AUTH: 使用される結合と双方が従来の、そして、IKEによってサポートされたアイデンティティで認証するチャンネル。
5. Symmetric CBB (S-CBB): neither party authenticates with a
conventional, IKE-supported identity, but channel binding is used
to bind the SAs to higher-layer authentication operations.
5. 左右対称のCBB(S-CBB): パーティーがしかし、従来の、そして、IKEによってサポートされたアイデンティティ、チャンネル結合で認証するどちらも、より高い層の認証操作にSAsを縛るのに使用されません。
6. Asymmetric CBB (A-CBB): asymmetric SAB (A-SAB) used with channel
binding; at the network layer, one party does not authenticate
with a conventional, IKE-supported identity, but the other party
does authenticate with such an identity. Channel binding is used
to bind the SA to higher-layer authentication operations.
6. 非対称のCBB(A-CBB): チャンネル結合と共に使用される非対称のSAB(A-SAB)。 ネットワーク層では、パーティーがしかし、従来の、そして、IKEによってサポートされたアイデンティティ、他のパーティーと共に認証しない人はそのようなものでアイデンティティを認証します。 チャンネル結合は、より高い層の認証操作にSAを縛るのに使用されます。
There are three security mechanisms involved in BTNS with channel binding:
チャンネル結合でBTNSにかかわる3台のセキュリティー対策があります:
1. BTNS and IPsec at the network layer,
1. ネットワーク層におけるBTNSとIPsec
2. higher-layer authentication, and
そして2. より高い層の認証。
3. the connection latching plus channel binding mechanisms that bind
the higher-layer authentication credentials with the secure IPsec
channel.
3. 安全なIPsecチャンネルで、より高い層の認証資格証明書を縛るメカニズムを縛る接続かんぬきとチャンネル。
Authentication at both the network and higher layers can be either bidirectional (both peers are authenticated) or unidirectional (one of the two peers does not authenticate). In contrast, when channel binding is used, it must be applied at both ends of the communication to prevent MITM attacks. Existing channel binding mechanisms and APIs for this purpose (e.g., as defined in GSS-API [10]) mandate the exchange and verification of the channel binding values at both ends to ensure that correct, non-spoofed channel characteristics are bound to the higher-layer authentication.
ネットワークと、より高い層の両方での認証が双方向である場合があります(両方の同輩は認証されます)、または単方向は(同輩が認証しない2つのものの1つ)を双方向です。 チャンネル結合が使用されているとき、対照的に、MITM攻撃を防ぐためにコミュニケーションの両端でそれを適用しなければなりません。 存在はこのために結合機構とAPIを向けます。(例えば、GSS-API[10])で定義されるように、正しくて、非偽造しているチャネル特性が制限されているのをより高い層の認証に保証するために両端における値を縛るチャンネルの交換と検証を強制してください。
Note: When any Stand-Alone BTNS (SAB) or Channel-Bound BTNS (CBB) is used without being qualified as symmetric or asymmetric, the symmetric mode is the intended default meaning.
以下に注意してください。 どんなStand単独のBTNS(SAB)やChannelによって制限されたBTNS(CBB)も左右対称であるか非対称として資格がなくて使用されるとき、左右対称のモードは意図しているデフォルト意味です。
4. Applicability Statement
4. 適用性証明
BTNS is intended for services open to the public but for which protected associations are desired, and for services that can be authenticated at higher layers in the protocol stack. BTNS can also provide some level of protection for private services when the alternative BTNS is no protection at all.
BTNSは公開されたサービス、保護された協会が望まれている、およびプロトコル・スタックの、より高い層で認証できるサービスのために意図します。 また、代替のBTNSが全くノー・プロテクションであるときに、BTNSは密葬のための何らかのレベルの保護を提供できます。
Touch, et al. Informational [Page 15] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[15ページ]のRFC5387BTNS問題と適用性2008年11月
BTNS uses the IPsec protocol suite, and therefore should not be used in situations where IPsec and specifically IKE are unsuitable. IPsec and IKE incur additional computation overhead, and IKE further requires message exchanges that incur round-trip latency to setup security associations. These may be undesirable in environments with limited computational resources and/or high communication latencies.
BTNSはIPsecプロトコル群を使用して、したがって、IPsecと明確にIKEが不適当である状況で使用するべきではありません。 IPsecとIKEは追加計算オーバーヘッドを被ります、そして、IKEはさらにセキュリティ協会をセットアップするために往復の潜在を被る交換処理を必要とします。 限られたコンピュータのリソース、そして/または、高いコミュニケーション潜在のために、これらは環境において望ましくないかもしれません。
This section provides an overview of the types of applications suitable for various modes of BTNS. The next two sections describe the overall benefits and vulnerabilities, followed by the applicability analysis for each BTNS mode. The applicability statement covers only the four BTNS-specific modes; the AUTH and CB-AUTH modes are out of scope for this discussion.
このセクションはBTNSの様々なモードに適したアプリケーションのタイプの概要を提供します。 次の2つのセクションが総合的な利益と脆弱性について説明します、続いて、それぞれのBTNSモードのための適用性分析について説明します。 適用性証明は4つのBTNS特有のモードだけをカバーしています。 この議論のための範囲の外にAUTHとCB-AUTHモードがあります。
4.1. Benefits
4.1. 利益
BTNS protects security associations after they are established by reducing vulnerability to attacks from parties that are not participants in the association. BTNS-based SAs protect network and transport layers without requiring network-layer authentication. BTNS can be deployed without pre-deployment of authentication material for IPsec or pre-shared information and can protect all transport layer protocols using a common mechanism.
それらが協会の関係者でないパーティーから脆弱性を攻撃に減少させることによって設立された後にBTNSはセキュリティ協会を保護します。 ネットワーク層認証を必要としないで、BTNSベースのSAsはネットワークとトランスポート層を保護します。 BTNSは、IPsecかあらかじめ共有された情報のために認証の材料のプレ展開なしで配布することができて、一般的なメカニズムを使用することですべてのトランスポート層プロトコルを保護できます。
BTNS also helps protect systems from low-effort attacks on higher- layer sessions or connections that disrupt valuable services or resources. BTNS raises the level of effort for many types of network- and transport-layer attacks. Simple transport layer packet attacks are rejected because the malicious packet or packets are not part of an IPsec SA. The attacker is instead forced to establish an unauthenticated IPsec SA and a transport connection for SAB, requiring the attacker to perform as much work as a host engaging in the higher-layer communication. SAB thus raises the effort for a DDoS (Distributed Denial of Service) attack to that of emulating a flash crowd. For open services, there may be no way to distinguish such a DDoS attack from an actual flash crowd.
また、BTNSは、より高い層のセッションか貴重なサービスかリソースを中断する接続に対する低い取り組み攻撃からシステムを保護するのを助けます。 BTNSは多くのタイプのネットワークとトランスポート層攻撃のために取り組みのレベルを上げます。 悪意があるパケットかパケットがIPsec SAの一部でないので、簡単なトランスポート層パケット攻撃は拒絶されます。 攻撃者はSABのために代わりにやむを得ずunauthenticated IPsec SAと輸送接続を確立します、攻撃者が、より高い層のコミュニケーションに従事しているホストと同じくらい多くの仕事をするのが必要であることで。 その結果、SABはDDoS(分散型サービス妨害)攻撃のためにフラッシュ群衆を見習うものに取り組みを上げます。 開いているサービスのために、実際のフラッシュ群衆とそのようなDDoS攻撃を区別する方法は全くないかもしれません。
BTNS also allows individual security associations to be established for protection of higher-layer traffic without requiring pre-deployed authentication credentials.
また、BTNSは、より高い層のトラフィックの保護のために認証資格証明書であるとあらかじめ配布された必要さなしで設立されるべき個別的安全保障協会を許容します。
4.2. Vulnerabilities
4.2. 脆弱性
BTNS removes the requirement that every IPsec SA be authenticated. Hosts connecting to BTNS hosts are vulnerable to communicating with a masquerader throughout the association for SAB, or until higher layers provide additional authentication for CBB. As a result, authentication data (e.g., passwords) sent to a masquerading peer
BTNSはあらゆるIPsec SAが認証されるという要件を取り除きます。 BTNSホストに接するホストが、SABに協会中で仮面舞踏会参加者とコミュニケートするのに被害を受け易いか、または、より高い層まで追加認証をCBBに供給します。 その結果、認証データ(例えば、パスワード)は仮装している同輩に発信しました。
Touch, et al. Informational [Page 16] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[16ページ]のRFC5387BTNS問題と適用性2008年11月
could be disclosed to an attacker. This is a deliberate design tradeoff; in BTNS, network- and transport-layer access is no longer controlled by the identity presented by the other host, opening hosts to potential masquerading and flash crowd attacks. Conversely, BTNS can secure connections to hosts that are unable to authenticate at the network layer, so the network and transport layers are more protected than can be achieved via higher-layer authentication alone.
攻撃者に明らかにすることができました。 これは慎重なデザイン見返りです。 BTNSでは、ネットワークとトランスポート層アクセスはもうもう片方のホストによって提示されたアイデンティティによって制御されません、潜在的仮装とフラッシュ群衆攻撃にホストを開いて。 逆に、BTNSがそれがネットワーク層で認証できないホストに接続を保証できるので、ネットワークとトランスポート層は、より高い層の認証で単独で達成できるより保護されています。
Lacking network-layer authentication information, other means must be used to provide access control for local resources. Traffic selectors for the BTNS SPD entries can be used to limit which interfaces, address ranges, and port ranges can access BTNS-enabled services. Rate limiting can further restrict resource usage. For SAB, these protections need to be considered throughout associations, whereas for CBB they need be present only until higher-layer protocols provide the missing authentication. CBB also relies on the effectiveness of the binding of higher-layer authentication to the BTNS network association.
ネットワーク層認証情報を欠いていて、ローカル資源のためのアクセスコントロールを提供するのに他の手段を使用しなければなりません。 どのインタフェースを制限するかにBTNS SPDエントリーのためのトラフィックセレクタを使用できます、そして、アドレスは及びます、そして、ポート範囲はBTNSによって可能にされたサービスにアクセスできます。 レート制限はさらにリソース用法を制限する場合があります。 SABのために、これらの保護は、協会中で考えられる必要がありますが、CBBに関して、上位層プロトコルがなくなった認証を提供するまでしか、それらは存在している必要はありません。 また、CBBは、より高い層の認証の結合の有効性をBTNSネットワーク協会を当てにします。
4.3. Stand-Alone BTNS (SAB)
4.3. スタンドアロンのBTNS(サブ)
SAB is intended for applications that are unable to use IKE- compatible authentication credentials and do not employ higher-layer authentication or other security protection. SAB is also suitable when the identities of either party are not important or are deliberately omitted, but IPsec security services are desired (see Section 3.2). SAB is particularly applicable to long-lived connections or sessions for which assurance that the entity at the other end of the connection has not changed may be a good enough substitute for the lack of authentication. This section discusses symmetric and asymmetric SAB.
SABはIKEコンパチブル認証資格証明書を使用して、より高い層の認証か他の機密保持を使わないことができないアプリケーションのために、意図します。 また、何れの当事者のアイデンティティが重要でないか、または故意に省略されますが、IPsecセキュリティー・サービスが望まれているとき(セクション3.2を見てください)、SABも適当です。 SABは特に接続のもう一方の端の実体が変化していないというどの保証が認証不足の十分良い代用品であることができるかのための長命の接続かセッションに適切です。 このセクションは左右対称の、そして、非対称のSABについて論じます。
4.3.1. Symmetric SAB
4.3.1. 左右対称のSAB
Symmetric SAB (S-SAB) is applicable when both parties lack network- layer authentication information and that authentication is not available from higher-layer protocols. S-SAB can still provide some forms of protection for network and transport protocols, but does not provide authentication beyond continuity of association. S-SAB is useful in situations where transfer of large files or use of other long-lived connections would benefit from not being interrupted by attacks on the transport connection (e.g., via a false TCP RST), but the particular endpoint identities are not important.
双方がネットワーク層の認証情報を欠いているとき、左右対称のSAB(S-SAB)は適切です、そして、その認証は上位層プロトコルから利用可能ではありません。 S-SABはまだいくつかの形式の保護をネットワークとトランスポート・プロトコルに提供できますが、協会の連続を超えて認証は提供しません。 S-SABは大きいファイルの転送か他の長命の接続の使用が輸送接続(例えば、偽のTCP RSTを通した)に対する攻撃で中断されないのから利益を得るところで状況で役に立ちますが、特定の終点のアイデンティティは重要ではありません。
Open services, such as web servers, and peer-to-peer networks could utilize S-SAB when their identities need not be authenticated but their communication would benefit from protection. Such services might provide files that are either not validated or validated by
彼らのアイデンティティが認証される必要はありませんが、それらのコミュニケーションが保護の利益を得るだろうというとき、ウェブサーバーや、ピアツーピアネットワークなどの開いているサービスはS-SABを利用するかもしれません。 そのようなサービスはそれが有効にされないか、または有効にされるファイルを提供するかもしれません。
Touch, et al. Informational [Page 17] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[17ページ]のRFC5387BTNS問題と適用性2008年11月
other means (e.g., published hashes). These transmissions present a target for off-path attacks that could be mitigated by S-SAB. S-SAB may also be useful for protecting voice-over-IP (VoIP) traffic between peers, such as direct calls between VoIP clients.
他の手段(例えば、ハッシュを発行します)。 これらのトランスミッションはS-SABが緩和できたオフ経路攻撃のための目標を提示します。 また、S-SABもVoIPクライアントの間の直通電話などの同輩の間のナレーターの声IP(VoIP)トラフィックを保護することの役に立つかもしれません。
S-SAB is also useful in protecting any transport protocol when the endpoints do not deploy authentication, for whatever reason. This is the case for BGP TCP connections between core routers, where the protection afforded by S-SAB is better than no protection at all, even though BGP is not intended as an open service.
また、S-SABも終点が認証を配布しないとどんなトランスポート・プロトコルも保護する際にいかなる理由も役に立ちます。 これはコアルータの間のBGP TCP関係のためのそうです、BGPが開いているサービスとして意図しませんが。そこでは、S-SABによって提供された保護が全くノー・プロテクションより良いです。
S-SAB can also serve as an intermediate step towards S-CBB. S-SAB is the effective result when an IPsec channel is used (via connection latching), but the higher-layer authentication is not bound to the IPsec SAs within the channel.
また、S-SABは途中経過としてS-CBBに向かって機能できます。 IPsecチャンネルが使用されているとき(接続かんぬきを通した)、S-SABは有効な結果ですが、より高い層の認証はチャンネルの中にIPsec SAsに縛られません。
4.3.2. Asymmetric SAB
4.3.2. 非対称のSAB
Asymmetric SAB (A-SAB) allows one party lacking network-layer authentication information to establish associations with another party that possesses authentication credentials for any applicable IKE authentication mechanism.
非対称のSAB(A-SAB)はネットワーク層認証情報を欠いているあるパーティーにどんな適切なIKE認証機構のためにも認証資格証明書を持っている別のパーティーとの仲間を設立させます。
Asymmetric SAB is useful for protecting transport connections for open services on the Internet, e.g., commercial web servers, etc. In these cases, the server is typically authenticated by a widely known CA, as is done with TLS at the application layer, but the clients need not be authenticated [4]. Although this may result in IPsec and TLS being used on the same connection, this duplication of security services at different layers is necessary when protection is required from the sorts of spoofing attacks described in Section 2 (e.g., TLS cannot prevent a spoofed TCP RST, as the RST is processed by TCP rather than being passed to TLS).
非対称のSABはインターネット、例えば、市販のウェブサーバーなどに開いているサービスのための輸送の接続を保護することの役に立ちます。 これらの場合では、サーバは応用層のTLSと共にしていた状態でそのままな広く知られているカリフォルニアによって通常認証されますが、クライアントは認証される必要はありません。[4]。 これは同じ接続のときに使用されることでIPsecとTLSをもたらすかもしれませんが、保護がセクション2で説明されたスプーフィング攻撃の種類から必要であるときに(例えば、TLSは偽造しているTCP RSTを防ぐことができません、RSTがTLSに通過されるよりTCPによってむしろ処理されるとき)、異なった層のセキュリティー・サービスのこの複製が必要です。
A-SAB can also secure transport for streaming media such as would be used by webcasts for remote education and entertainment.
また、A-SABは通信教育とエンターテインメントにwebcastsによって使用されるようなストリーミング・メディアのために輸送を保証できます。
4.4. Channel-Bound BTNS (CBB)
4.4. チャンネル行きのBTNS(CBB)
CBB allows hosts without network-layer authentication information to cryptographically bind BTNS-based IPsec SAs to authentication at higher layers. CBB is intended for applications that employ higher- layer authentication but that also benefit from additional network- layer security. CBB provides network-layer security services without requiring authentication at the network layer. This enables IPsec security services for applications that have IKE-incompatible authentication credentials. CBB allows IPsec to be used with
CBBはネットワーク層認証情報のないホストにより高い層での認証にBTNSベースのIPsec SAsを暗号で縛らせます。 CBBは、より高い層の認証を使いますが、また追加ネットワーク層のセキュリティの利益を得るアプリケーションのために意図します。 ネットワーク層で認証を必要としないで、CBBはネットワーク層セキュリティー・サービスを提供します。 これはIKE両立しない認証資格証明書を持っているアプリケーションのためのIPsecセキュリティー・サービスを可能にします。 CBBは、IPsecが使用されるのを許容します。
Touch, et al. Informational [Page 18] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[18ページ]のRFC5387BTNS問題と適用性2008年11月
authentication mechanisms not supported by IKE and frees higher-layer applications and protocols from duplicating security services already available in IPsec.
メカニズムがIKEでサポートして、より高い層のアプリケーションとプロトコルを解放しないIPsecで既に利用可能なセキュリティー・サービスをコピーする認証。
Symmetric CBB integrates channel binding with S-SAB, as does asymmetric CBB with A-SAB. In both cases, the target applications have similar characteristics at the network layer to their non- channel-binding counterparts. The only significant difference is the binding of authentication credentials at a higher layer to the resulting IPsec channels.
左右対称のCBBはA-SABと共に非対称のCBBのようにチャンネル結合をS-SABと統合します。 どちらの場合も、目標アプリケーションは彼らのチャンネルを非縛る対応者にネットワーク層における同様の特性を持っています。 唯一の著しい違いは結果として起こるIPsecチャンネルへの、より高い層の認証資格証明書の結合です。
Although the modes of CBB refer to the authentication at the network layer, higher-layer authentication can also be either asymmetric (one-way) or symmetric (two-way). Asymmetric CBB can be used to complement one-way authentication at a higher layer by providing one- way authentication of the opposite direction at the network layer. Consider an application with one-way, client-only authentication. The client can utilize A-CBB where the server must present IKE- authenticated credentials at the network layer. This form of A-CBB achieves mutual authentication, albeit at separate layers. Many remote file system protocols, such as iSCSI and NFS, fit into this category and can benefit from channel binding with IPsec for better network-layer protection, including prevention of MITM attacks.
CBBのモードはネットワーク層で認証について言及しますが、また、より高い層の認証も、非対称である(一方向)、または左右対称である場合があります(両用)。 より高い層でネットワーク層で逆方向の認証を1つの方法に提供することによって一方向認証の補足となるのに非対称のCBBを使用できます。 一方向クライアントだけ認証によるアプリケーションを考えてください。 クライアントはサーバがネットワーク層で認証された資格証明書をIKEに提示しなければならないA-CBBを利用できます。 別々の層に実現しますが、A-CBBのこのフォームは互いの認証を実現します。 iSCSIやNFSなどの多くのリモートファイルシステムプロトコルが、このカテゴリに収まって、より良いネットワーク層保護のためにIPsecとのチャンネル結合の利益を得ることができます、MITM攻撃の防止を含んでいて。
Mechanisms and interfaces for BTNS channel binding with IPsec are discussed in further detail in [26].
[26]の詳細でIPsecとのBTNSチャンネル結合のためのメカニズムとインタフェースについて議論します。
4.5. Summary of Uses, Vulnerabilities, and Benefits
4.5. 用途、脆弱性、および利益の概要
The following is a summary of the properties of each type of BTNS, based on the previous subsections:
↓これは前の小区分に基づいたBTNSのそれぞれのタイプの特性の概要です:
SAB CBB
--------------------------------------------------------------
Uses Open services Same as SAB but with
Peer-to-peer higher-layer auth.,
Zero-config Infrastructure e.g., iSCSI [19], NFSv4 [21]
サブCBB-------------------------------------------------------------- SABにもかかわらず、Peerから同輩への、より高い層のauthでオープンサービスSameを使用する、Zero-コンフィグInfrastructure、例えば、iSCSI[19]、NFSv4[21]
Vuln. Masqueraders Masqueraders until bound
Needs data rate limit Needs data rate limit
Load on IPsec Load on IPsec
Exposure to open access
Vuln。 バウンドがデータ信号速度限界を必要とするまで、仮面舞踏会参加者Masqueradersは、IPsec Exposureの上のIPsec Loadの上のデータ信号速度限界Loadがアクセスを開く必要があります。
Benefit Protects L3 & L4 Protects L3 & L4
Avoids all auth. keys Avoids L3 auth. keys
Full auth. once bound
利益Protects L3&L4 Protects L3&L4 Avoidsはすべて. キーAvoids L3 authキーFull authをauthします。一度バウンドしてください。
Touch, et al. Informational [Page 19] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[19ページ]のRFC5387BTNS問題と適用性2008年11月
Most of the potential vulnerabilities in the above table have been discussed in previous sections of this document; some of the more general issues, such as the increased load on IPsec processing, are addressed in the Security Considerations section of this document.
このドキュメントの前項で上のテーブルの潜在的脆弱性の大部分について議論しました。 IPsec処理での増強された負荷などの、より一般的な問題のいくつかがこのドキュメントのSecurity Considerations部で扱われます。
5. Security Considerations
5. セキュリティ問題
This section describes the threat models for BTNS and discusses other security issues based on the threat models for different modes of BTNS. Some of the issues were mentioned previously in the document but are listed again for completeness.
このセクションは、BTNSの異なったモードのためにBTNSのために脅威モデルについて説明して、脅威モデルに基づく他の安全保障問題について論じます。 問題のいくつかが、以前に、ドキュメントで言及されましたが、完全性のために再び記載されています。
5.1. Threat Models and Evaluation
5.1. 脅威モデルと評価
BTNS is intended to protect sessions from a variety of threats, including on-path, man-in-the-middle attacks after key exchange, and off-path attacks. It is intended to protect the contents of a session once established, but does not protect session establishment itself. This protection has value because it forces the attacker to target connection establishment as opposed to waiting for a more convenient time; this is of particular value for long-lived sessions.
BTNSが主要な交換の後に経路の中央の男性攻撃を含むさまざまな脅威と経路でのセッション攻撃を保護することを意図します。 それは、一度確立されたセッションのコンテンツを保護することを意図しますが、セッション設立自体を保護しません。 この保護には、より便利な時間待つことと対照的に攻撃者がそれによってやむを得ずコネクション確立を狙うので、値があります。 これには、長命のセッションの間、特定の価値があります。
BTNS is not intended to protect the key exchange itself, so this presents an opportunity for a man-in-the-middle attack or a well- timed attack from other sources. Furthermore, Stand-Alone BTNS is not intended to protect the endpoint from nodes masquerading as legitimate clients of a higher-layer protocol or service. Channel- Bound BTNS can protect from such masquerading, though at a later point after the security association is established, as a masquerade attack causes a client authentication failure at a higher layer.
BTNSが主要な交換自体を保護することを意図しないので、これは他のソースから介入者攻撃かよく調節された攻撃の機会を提示します。 その上、StandだけBTNSが正統の上位層プロトコルの、または、サービスのクライアントのふりをするノードから終点を保護することを意図しません。 チャンネルの制限されたBTNSはそのような仮装から保護できます、攻撃が、より高い層でセキュリティ協会が仮面舞踏会と書き立てられた後に後のポイントでクライアント認証失敗を引き起こしますが。
BTNS is also not intended to protect from DoS (Denial of Service) attacks that seek to overload a CPU performing authentication or other security computations, nor is BTNS intended to provide protection from configuration mistakes. These latter two threat assumptions are also the case for IPsec.
また、BTNSが認証を実行するCPUを積みすぎようとするDoS(サービス妨害)攻撃か他のセキュリティ計算から保護することを意図しないで、またBTNSが構成誤りから保護を提供することを意図しません。 また、これらの2つの後者の脅威仮定がIPsecのためのケースです。
The following sections discuss the implications of the threat models in more details.
以下のセクションはその他の詳細で脅威モデルの含意について論じます。
5.2. Interaction with Other Security Services
5.2. 他のセキュリティー・サービスとの相互作用
As with any aspect of network security, the use of BTNS must not interfere with other security services. Within IPsec, the scope of BTNS is limited to the SPD and PAD entries that explicitly specify BTNS and to the resulting SAD entries. It is incumbent on system administrators to deploy BTNS only where safe, preferably as an alternative to the use of "bypass" SPD entries that exempt specified
ネットワークセキュリティのどんな局面ならも、BTNSの使用は他のセキュリティー・サービスを妨げてはいけません。 IPsecの中では、BTNSの範囲は明らかにBTNSを指定するSPDとPADエントリーと、そして、結果として起こるSADエントリーに制限されます。 システム管理者では、望ましくはそんなに免除されている「迂回」SPDエントリーの使用に代わる手段として安全であるところだけで指定されたBTNSを配布するのは義務です。
Touch, et al. Informational [Page 20] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[20ページ]のRFC5387BTNS問題と適用性2008年11月
traffic from IPsec cryptographic protection. In other words, BTNS should be used only as a substitute for no security, rather than as a substitute for stronger security. When the higher-layer authentication required for CBB is not available, other methods, such as IP address filtering, can help reduce the vulnerability of SAB to exposure to anonymous access.
IPsecの暗号の保護からのトラフィック。 言い換えれば、BTNSは単にセキュリティがない代用品として使用されるべきです、むしろより強いセキュリティの代用品より。 CBBに必要であるより高い層の認証が利用可能でないときに、IPアドレスフィルタリングなどの他のメソッドは、匿名のアクセサリーへの暴露にSABの脆弱性を減少させるのを助けることができます。
5.3. MITM and Masquerader Attacks
5.3. MITMと仮面舞踏会参加者攻撃
Previous sections have described how CBB can counter MITM and masquerader attacks, even though BTNS does not protect key exchange and does not authenticate peer identities at the network layer. Nonetheless, there are some security issues regarding CBB that must be carefully evaluated before deploying BTNS.
前項はCBBがどうMITMと仮面舞踏会参加者攻撃に対抗できるかを説明しました、BTNSは主要な交換を保護しないで、またネットワーク層では同輩のアイデンティティを認証しませんが。 それにもかかわらず、BTNSを配布する前に慎重に評価しなければならないCBBに関するいくつかの安全保障問題があります。
For regular IPsec/IKE, a man in the middle cannot subvert IKE authentication, and hence an attempt to attack an IPsec SA via use of two SAs concatenated by the attacker acting as a traffic-forwarding proxy will cause an IKE authentication failure. On the other hand, a man-in-the-middle attack on IPsec with CBB is discovered later. With CBB, the IKE protocol will succeed because it is unauthenticated, and the security associations will be set up. The man in the middle will not be discovered until the higher-layer authentication fails. There are two security concerns with this approach: possible exposure of sensitive authentication information to the attackers, and resource consumption before attacks are detected.
通常のIPsec/IKEに関しては、中央の男性はIKE認証を打倒できません、そして、したがって、トラフィックを進めるプロキシとして務めている攻撃者によって連結された2SAsの使用でIPsec SAを攻撃する試みはIKE認証の故障を引き起こすでしょう。 他方では、CBBとIPsecにおける介入者攻撃は後で発見されます。 それが非認証されて、セキュリティ協会が設立されるので、CBBと共に、IKEプロトコルは成功するでしょう。 より高い層の認証が失敗するまで、中央の男性は発見されないでしょう。 このアプローチがある2つの安全上の配慮があります: 攻撃が検出される前の攻撃者、およびリソース消費への機密の認証情報の可能な暴露。
The exposure of information depends on the higher-layer authentication protocols used in applications. If the higher-layer authentication requires exchange of sensitive information (e.g., passwords or password-derived materials) that are directly useful or can be attacked offline, an attacker can gain such information even though the attack can be detected. Therefore, CBB must not be used with higher-layer protocols that may expose sensitive information during authentication exchange. For example, Kerberos V AP exchanges would leak little other than the target's krb5 principal name, while Kerberos V AS exchanges using PA-ENC-TIMESTAMP pre-authentication would leak material that can then be attacked offline. The latter should not be used with BTNS, even with Channel Binding. Further, the ways in which BTNS is integrated with the higher-layer protocol must take into consideration vulnerabilities that could be introduced in the APIs between these two systems or in the information that they share.
情報の暴露はアプリケーションで使用されるより高い層の認証プロトコルによります。 より高い層の認証が直接役に立つか、またはオフラインで攻撃できる機密情報(例えば、パスワードかパスワードで誘導された材料)の交換を必要とするなら、攻撃を検出できますが、攻撃者はそのような情報を獲得できます。 したがって、認証交換の間に機密情報を暴露するかもしれない上位層プロトコルと共にCBBを使用してはいけません。 例えば、目標のkrb5の主要な名以外に、ケルベロスV AP交換は少ししか漏らさないでしょう、PA-ENC-TIMESTAMPプレ認証を使用するケルベロスV AS交換が次にオフラインで攻撃できる材料を漏らすでしょうが。 BTNSと、Channel Bindingと共にさえ後者を使用するべきではありません。 さらに、BTNSが上位層プロトコルについて統合している方法はこれらの2台のシステムの間のAPIか共有するという情報で導入できた脆弱性を考慮に入れなければなりません。
The resource consumption issue is addressed in the next section on DoS attacks.
リソース消費問題はDoS攻撃のときに次のセクションで扱われます。
Touch, et al. Informational [Page 21] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[21ページ]のRFC5387BTNS問題と適用性2008年11月
5.4. Denial of Service (DoS) Attacks and Resource Consumptions
5.4. サービス妨害(DoS)攻撃とリソース肺病
A consequence of BTNS deployment is that more traffic requires cryptographic operations; these operations increase the computation required in IPsec implementations that receive protected traffic and/or verify incoming traffic. That additional computation raises vulnerability to overloading, which may be the result of legitimate flash crowds or a DoS or DDoS attack. Although this may itself present a substantial impediment to deployment, it is an issue for all cryptographically protected communication systems. This document does not address the impact BTNS has on such increases in required computation.
BTNS展開の結果は、より多くのトラフィックが暗号の操作を必要とするということです。 これらの操作は保護されたトラフィックを受ける、そして/または、入って来るトラフィックについて確かめるIPsec実装で必要である計算を増強します。 その追加計算は正統のフラッシュ群衆かDoSの結果であるかもしれない積みすぎへの脆弱性かDDoS攻撃を上げます。 これは扱うかもしれません。展開のそれ自体で現在のaかなりの障害、それはすべての暗号で保護された通信系のための問題です。このドキュメントはBTNSが必要な計算のそのような増加のときに持っている影響力は扱いません。
The effects of the increased resource consumption are twofold. The consumption raises the level of effort for attacks such as MITM, but also consumes more resources to detect such attacks and to reject spoofed traffic. At the network layer, proper limits and access controls for resources should be set up for all BTNS SAs. CBB SAs may be granted increased resource access after the higher-layer authentications succeed. The same principles apply to the higher- layer protocols that use CBB SAs. Special care must be taken to avoid excessive resource usage before authentication is established in these applications.
増強されたリソース消費の効果は二つです。 消費は、MITMなどの攻撃のために取り組みのレベルを上げますが、そのような攻撃を検出して、偽造しているトラフィックを拒絶するために、より多くのリソースをまた消費します。 ネットワーク層では、リソースのための適切な限界とアクセス制御はすべてのBTNS SAsに設定されるべきです。 より高い層の認証が成功した後に増強されたリソースアクセスはCBB SAsに承諾されるかもしれません。 同じ原則はCBB SAsを使用するより高い層のプロトコルに適用されます。 認証がこれらのアプリケーションに確立される前に過度のリソース用法を避けるために特別な注意を払わなければなりません。
5.5. Exposure to Anonymous Access
5.5. 匿名のアクセスへの暴露
The use of SAB by a service implies that the service is being offered for open access, since network-layer authentication is not performed. SAB should not be used with services that are not intended to be openly available.
SABのサービスによる使用は、サービスが開架のために提供されているのを含意します、ネットワーク層認証が実行されないので。 オープンに利用可能であることを意図しないサービスと共にSABを使用するべきではありません。
5.6. ICMP Attacks
5.6. ICMP攻撃
This document does not consider ICMP attacks because the use of BTNS does not change the existing IPsec guidelines on ICMP traffic handling [8]. BTNS focuses on the authentication part of establishing security associations. BTNS does not alter the IPsec traffic processing model and protection boundary. As a result, the entire IPsec packet processing guidelines, including ICMP processing, remain applicable when BTNS is added to IPsec.
BTNSの使用がICMPトラフィック取り扱[8]いに関する既存のIPsecガイドラインを変えないので、このドキュメントはICMP攻撃を考えません。 BTNSは設立の認証部分にセキュリティ協会の焦点を合わせます。 BTNSはIPsecトラフィック処理モデルと保護境界を変更しません。 BTNSがIPsecに加えられるとき、その結果、ICMP処理を含む全体のIPsecパケット処理ガイドラインは適切なままで残っています。
5.7. Leap of Faith
5.7. 盲信
BTNS allows systems to accept and establish security associations with peers without authenticating their identities. This can enable functionality similar to "Leap of Faith" authentication utilized in other security protocols and applications such as the Secure Shell Protocol (SSH) [29].
彼らのアイデンティティを認証しないで、BTNSはシステムに同輩とのセキュリティ仲間を受け入れて、設立させます。 これはSecureシェルプロトコル(SSH)[29]などの他のセキュリティプロトコルとアプリケーションで利用された「盲信」認証と同様の機能性を可能にすることができます。
Touch, et al. Informational [Page 22] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[22ページ]のRFC5387BTNS問題と適用性2008年11月
SSH implementations are allowed to accept unknown peer credentials (host public keys) without authentication, and these unauthenticated credentials may be cached in local databases for future authentication of the same peers. Similar to BTNS, such measures are allowed due to the lack of "widely deployed key infrastructure" [29] and to improve ease of use and end-user acceptance.
SSH実装は認証なしで未知の同輩資格証明書(ホスト公開鍵)を受け入れることができます、そして、これらの非認証された資格証明書は同じ同輩の今後の認証のためのローカルのデータベースでキャッシュされるかもしれません。 そして、BTNSと同様です、そのような測定が「広く配布している主要なインフラストラクチャ」[29]の不足のため許されている、使いやすさと利用者受容性を改良するために。
There are subtle differences between SSH and BTNS regarding Leap of Faith, as shown in the following table:
SSHとBTNSの間には、FaithのLeapに関して微妙な違いが以下のテーブルに示されるようにあります:
| SSH | BTNS |
-------------------------------+---------+---------+
Accept unauthenticated | Allowed | Allowed |
credentials | | |
-------------------------------+---------+---------+
Options/Warnings to reject | Yes | No |
unauthenticated credentials | | |
-------------------------------+---------+---------+
Cache unauthenticated |Required | Allowed |
credential for future refs | | |
-------------------------------+---------+---------+
| セキュアシェル (SSH)| BTNS| -------------------------------+---------+---------+は非認証されていた状態で受け入れます。| 許容されています。| 許容されています。| 資格証明書| | | -------------------------------+---------+---------+ 拒絶するオプション/警告| はい| いいえ| 資格証明書を非認証しました。| | | -------------------------------+---------+---------+ キャッシュは非認証されました。|必要です。| 許容されています。| 将来の審判にとって、資格証明です。| | | -------------------------------+---------+---------+
SSH requires proper warnings and options in applications to reject unauthenticated credentials, while BTNS accepts such credentials automatically when they match the corresponding policy entries. Once SSH accepts a credential for the first time, that credential should be cached and can be reused automatically without further warnings. BTNS credentials can be cached for future use, but there is no security advantage to doing so, as a new unauthenticated credential that is allowed by the policy entries will be automatically accepted.
SSHは適切な警告を必要とします、そして、拒絶する申し込みにおけるオプションは資格証明書を非認証しましたが、対応する方針エントリーに合っていると、BTNSは自動的にそのような資格証明書を受け入れます。 SSHが初めていったん資格証明書を受け入れると、さらなる警告なしでその資格証明書をキャッシュするべきであり、自動的に再利用できます。 今後の使用のためにBTNS資格証明書をキャッシュできますが、そうすることへのセキュリティ上の利点が全くありません、自動的に方針エントリーで許容されている新しい非認証された資格証明書を受け入れるとき。
In addition, BTNS does not require IPsec to reuse credentials in a manner similar to SSH. When IPsec does reuse unauthenticated credentials, there may be implementation advantages to caching them.
さらに、BTNSは、IPsecがSSHと同様の方法で資格証明書を再利用するのを必要としません。 IPsecが非認証された資格証明書を再利用するとき、それらをキャッシュする実装利点があるかもしれません。
SSH-style credential caching for reuse with SAB could be addressed by future extension(s) to BTNS; such extension(s) would need to provide warnings about unauthenticated credentials and a mechanism for user acceptance or rejection of them in order to establish a level of authentication assurance comparable to SSH's "Leap of Faith". Such extension(s) would also need to deal with issues caused by the absence of identities in BTNS. At best, a cached BTNS credential reauthenticates the network-layer source of traffic when the credential is reused -- in contrast, SSH credential reuse reauthenticates an identity.
BTNSへの今後の拡大でSABとの再利用のためのSSH-スタイルの資格証明キャッシュを扱うことができるでしょう。 そのような拡張子は、SSHの「盲信」に匹敵する認証保証のレベルを確立するために非認証された資格証明書に関する警告とメカニズムをそれらのユーザ承認か拒絶に提供する必要があるでしょう。 また、そのような拡張子は、BTNSでのアイデンティティの欠如で引き起こされた問題に対処する必要があるでしょう。 資格証明書が再利用されるとき、せいぜい、キャッシュされたBTNS資格証明書はトラフィックのネットワーク層源を再認証します--対照的に、SSHの資格証明再利用はアイデンティティを再認証します。
Touch, et al. Informational [Page 23] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[23ページ]のRFC5387BTNS問題と適用性2008年11月
Network-layer reauthentication for SAB is further complicated by:
SABのためのネットワーク層再認証は以下によってさらに複雑にされます。
o the ability of NATs to cause multiple independent network-layer
sources of traffic to appear to be one source (potentially
requiring acceptance and caching of multiple BTNS credentials),
o NATsがトラフィックの複数の独立しているネットワーク層源が1つのソース(複数のBTNS資格証明書の潜在的に承認を必要として、キャッシュ)であるように見えさせる能力
o the ability of multihoming to cause one network-layer source of
traffic to appear to be multiple sources (potentially triggering
unexpected warnings and requiring re-acceptance of the same BTNS
credential), and
o そしてトラフィックの1つのネットワーク層源がマルチホーミングで複数のソース(潜在的に予期していなかった警告の引き金となって、同じBTNS資格証明書の再承認を必要とする)であるように見える能力。
o interactions with both mobility and address ownership changes
(potentially requiring controlled BTNS credential reassignment
and/or invalidation).
o 移動性とアドレス所有権変化(潜在的に、制御BTNS資格証明再割当て、そして/または、無効にするのを必要とする)の両方との相互作用。
These issues are left to be addressed by possible future work on the addition of "Leap of Faith" functionality to BTNS.
これらの問題によって「盲信」の機能性の追加への可能な今後の活動でBTNSに扱われるのが残されます。
In contrast, for CBB, credential caching and verification are usually done at the higher-layer protocols or applications. Caching credentials for CBB at the BTNS level is not as important because the channel binding will bind whatever credentials are presented (new or cached) to the higher-layer protocol identity.
対照的に、CBBに関して、資格証明キャッシュと通常、上位層プロトコルかアプリケーションのときに確かめます。 何が上位層プロトコルのアイデンティティに資格証明書を提示されても(新しいかキャッシュされた)、チャンネル結合が付くので、CBBのためにBTNSレベルで資格証明書をキャッシュするのは重要ではありません。
5.8. Connection Hijacking through Rekeying
5.8. Rekeyingを通してハイジャックしている接続
Each IPsec SA has a limited lifetime (defined as a time and/or byte count) and must be rekeyed or terminated when the lifetime expires. Rekeying an SA provides a small window of opportunity where an on- path attacker can step in and hijack the new SA created by rekeying by spoofing the victim during rekeying. BTNS, and particularly SAB, simplify this attack by removing the need for the attacker to authenticate as the victim or via the same non-BTNS PAD entry that was used by the victim for the original SA. CBB, on the other hand, can detect such attacks by detecting the changes in the secure channel properties.
寿命が期限が切れるとき、各IPsec SAを限られた生涯(時間、そして/または、バイト・カウントと定義される)を持って、「再-合わせ」られなければならないか、または終えなければなりません。 SAをRekeyingするとどこが機会の小さい窓に供給されるか、オンである、経路攻撃者は、中へ入って、「再-合わせ」ている間、犠牲者を偽造することによって「再-合わせ」ることによって作成された新しいSAをハイジャックできます。 BTNS、および特にSABは、攻撃者が犠牲者かオリジナルのSAに犠牲者によって使用された同じ非BTNS PADエントリーを通って認証する必要性を取り除くことによって、この攻撃を簡素化します。 他方では、CBBは、安全なチャンネルの特性における変化を検出することによって、そのような攻撃を検出できます。
This vulnerability is caused by the lack of inter-session binding or latching of IKE SAs with the corresponding credentials of the two peers. Connection latching, together with channel binding, enables such binding but requires higher-layer protocols or applications to verify consistency of identities and authentication across the two SAs.
この脆弱性は、相互セッション結合の不足によって引き起こされるか、または2人の同輩の対応する資格証明書でIKE SAsに掛け金をおろしています。 チャンネル結合と共に掛け金をおろしている接続は、そのような結合を可能にしますが、2SAsの向こう側にアイデンティティと認証の一貫性について確かめるために上位層プロトコルかアプリケーションを必要とします。
Touch, et al. Informational [Page 24] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[24ページ]のRFC5387BTNS問題と適用性2008年11月
5.9. Configuration Errors
5.9. 構成誤り
BTNS does not address errors of configuration that could result in increased vulnerability; such vulnerability is already possible using "bypass" SPD entries. SPD entries that allow BTNS must be explicitly flagged, and hence can be kept separate from SPD entries that do not allow BTNS, just as "bypass" SPD entries are separate from entries that create SAs with more conventional, stronger security.
BTNSは増強された脆弱性をもたらすことができた構成の誤りを扱いません。 そのような脆弱性は、「迂回」SPDエントリーを使用することで既に可能です。 BTNSを許容するSPDエントリーは、明らかに旗を揚げなければならなくて、したがって、BTNSを許容しないSPDエントリーから別々に保つことができます、ちょうど「迂回」SPDエントリーが、より従来の、そして、より強いセキュリティでSAsを作成するエントリーから別々であるように。
6. Related Efforts
6. 関連取り組み
There have been a number of related efforts in the IETF and elsewhere to reduce the configuration effort of deploying the Internet security suite.
インターネットセキュリティスイートを配布する構成取り組みを減少させるために、多くの関連する取り組みがIETFとほかの場所にありました。
The IETF PKI4IPsec effort focused on providing an automatic infrastructure for the configuration of Internet security services, e.g., to assist in deploying signed certificates and CA information [9]. The IETF KINK effort focused on adapting Kerberos [13] for IKE, enabling IKE to utilize the Kerberos key distribution infrastructure rather than requiring certificates or shared private keys [18]. KINK takes advantage of an existing architecture for automatic key management in Kerberos. Opportunistic Encryption (OE) is a system for automatic discovery of hosts willing to do a BTNS-like encryption, with authentication being exchanged by leveraging existing use of the DNS [17]. BTNS differs from all three in that BTNS is intended to avoid the need for such infrastructure altogether, rather than to automate it.
IETF PKI4IPsec取り組みは、例えば署名入りの証書とカリフォルニア情報が[9]であると配布するのを助けるためにインターネットセキュリティー・サービスの構成に自動インフラストラクチャを提供するのは焦点を合わせました。 IETF KINK取り組みは、IKEのためにケルベロス[13]を適合させるのは焦点を合わせました、IKEが証明書か共有された秘密鍵[18]を必要とするよりむしろケルベロスの主要な分配インフラストラクチャを利用するのを可能にして。 KINKは自動かぎ管理にケルベロスで既存のアーキテクチャを利用します。 便宜主義的なEncryption(OE)はBTNSのような暗号化をしても構わないと思っているホストの自動発見のシステムです、DNS[17]の既存の使用を利用することによって認証を交換している状態で。 BTNSはそれを自動化するよりBTNSが全体で、むしろそのようなインフラストラクチャの必要性を避けることを意図するという点においてすべての3と異なっています。
7. Acknowledgments
7. 承認
This document was inspired by discussions on the IETF TCPM WG about the spoofed RST attacks on BGP routers and various solutions, as well as discussions in the NFSv4 and IPS WGs about how to better integrate with IPsec. The concept of BTNS was the result of these discussions as well as discussions with USC/ISI's T. Faber, A. Falk, and B. Tung, and discussions on the IETF SAAG (Security Area open meeting) mailing list and IPsec mailing list. The authors would like to thank the members of those WGs and lists, as well as the IETF BTNS BOFs and WG and its associated ANONsec mailing list (http://www.postel.org/anonsec) for their feedback -- in particular, Steve Kent, Sam Hartman, Nicolas Williams, and Pekka Savola.
このドキュメントはBGPルータと様々なソリューションに対する偽造しているRST攻撃、およびNFSv4とIPS WGsでの議論に関してどうIPsecと、よりよく統合するかに関してIETF TCPM WGについての議論で奮い立たせられました。 BTNSの概念はUSC/ISIのT.フェーバー、A.フォーク、およびB.タンとの議論、およびIETF SAAG(セキュリティArea公開の会議)メーリングリストとIPsecメーリングリストについての議論と同様にこれらの議論の結果でした。 作者はそれらのWGsとリストのメンバーに感謝したがっています、IETF BTNS BOFs、WG、および彼らのフィードバックのためのその関連ANONsecメーリングリスト( http://www.postel.org/anonsec )と同様に--特にスティーブ・ケント、サム・ハートマン、ニコラス・ウィリアムズ、およびペッカSavola。
This document was prepared using 2-Word-v2.0.template.dot.
このドキュメントは、2Word v2.0.template.dotを使用することで準備されました。
Touch, et al. Informational [Page 25] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[25ページ]のRFC5387BTNS問題と適用性2008年11月
8. Informative References
8. 有益な参照
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[1]AbobaとB.とBlunkとL.とVollbrechtとJ.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
[2] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP", RFC
3723, April 2004.
[2]Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「IPの上でブロックストレージがプロトコルであると機密保護します」、RFC3723(2004年4月)。
[3] CERT Vulnerability Note VU#415294, "The Border Gateway Protocol
relies on persistent TCP sessions without specifying
authentication requirements", 4/20/2004.
[3]CERT脆弱性レポートVU#415294、「Borderゲートウェイプロトコルが永続的なTCPセッションのときに認証要件を指定しながら当てにする」4/20/2004。
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008.
[4] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2008年8月にバージョン1.2インチ、RFC5246について議定書の中で述べます」。
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[5] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[6] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[7] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[7] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[8] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[8] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[9] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[9]Korver、2007年8月のB.、「IKEv1/ISAKMP、IKEv2、およびPKIXのインターネットIPセキュリティPKIプロフィール」RFC4945。
[10] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[10] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」
[11] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication
and Security Layer (SASL)", RFC 4422, June 2006.
[11] メリニコフ、A.、エド、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日
[12] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272,
January 2006.
[12] マーフィー、S.、「BGPセキュリティの脆弱性分析」、RFC4272、2006年1月。
[13] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005.
[13] ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[14] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[14] マスコウィッツ、R.、Nikander、P.、Jokela、P.、エド、T.ヘンダーソン、「ホストアイデンティティプロトコル」、RFC5201、4月2008日
Touch, et al. Informational [Page 26] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[26ページ]のRFC5387BTNS問題と適用性2008年11月
[15] Ramaiah, A., R Stewart, M. Dalal, "Improving TCP's Robustness
to Blind In-Window Attacks", Work in Progress, January 2008.
[15] Ramaiah(A.、Rスチュワート、「窓での盲目の攻撃にTCPの丈夫さを改良する」M.Dalal)は進歩、2008年1月に働いています。
[16] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia,
"A Remote Direct Memory Access Protocol Specification", RFC
5040, October 2007.
[16]RecioとR.とメツラーとB.とCulleyとP.とHilland、J.とD.ガルシア、「リモートダイレクトメモリアクセスプロトコル仕様」RFC5040(2007年10月)。
[17] Richardson, M. and D. Redelmeier, "Opportunistic Encryption
using the Internet Key Exchange (IKE)", RFC 4322, December
2005.
[17] リチャードソンとM.とD.Redelmeier、「インターネット・キー・エクスチェンジ(IKE)を使用する便宜主義的な暗号化」、RFC4322、2005年12月。
[18] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)", RFC 4430,
March 2006.
[18]Sakane、S.、Kamada、K.、トーマス、M.、およびJ.Vilhuber、「キー(もつれ)のKerberizedインターネット交渉」、RFC4430、2006年3月。
[19] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E.
Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
RFC 3720, April 2004.
[19]Satran、J.、メタンフェタミン、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE.Zeidner、「インターネットの小さいコンピュータ・システムは(iSCSI)を連結します」、RFC3720、2004年4月。
[20] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data
Placement over Reliable Transports", RFC 5041, October 2007.
2007年10月の[20] シャーとH.とピンカートンとJ.とRecio、R.とP.Culley、「信頼できる輸送の上のダイレクトデータプレースメント」RFC5041。
[21] 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.
[21] Shepler(S.、キャラハン、B.、ロビンソン、D.、サーロウ、R.、Beame、C.、アイスラー、M.、およびD.Noveck)は「File System(NFS)バージョン4プロトコルをネットワークでつなぎます」、RFC3530、2003年4月。
[22] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC
4960, September 2007.
[22] スチュワート、R.、エド、「ストリーム制御伝動プロトコル」、RFC4960、9月2007日
[23] TCP SYN-cookies, http://cr.yp.to/syncookies.html
[23] TCP SYN-クッキー、 http://cr.yp.to/syncookies.html
[24] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953,
July 2007.
2007年7月の[24] 接触、J.、「スプーフィング攻撃に対する防御しているTCP」RFC4953。
[25] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication
Option", Work in Progress, November 2007.
[25] 接触、J.、A.マンキン、「TCP認証オプション」というR.Bonicaは進歩、2007年11月に働いています。
[26] Williams, N., "IPsec Channels: Connection Latching", Work in
Progress, April 2008.
[26] ウィリアムズ、N.、「IPsecは以下を精神を集中します」。 「接続は掛け金をおろし」て、進歩、2008年4月に働いてください。
[27] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[27] ウィリアムズ、N. 「チャンネルを固定するチャンネル結合の使用」のRFC5056、2007年11月。
[28] Williams, N. and M. Richardson, "Better-Than-Nothing Security:
An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[28] ウィリアムズ、N.、およびM.リチャードソン、「ないよりましなセキュリティ:」 「IPsecのUnauthenticatedモード」、RFC5386、2008年11月。
[29] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[29]YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、1月2006日
Touch, et al. Informational [Page 27] RFC 5387 BTNS Problem and Applicability November 2008
接触、他 情報[27ページ]のRFC5387BTNS問題と適用性2008年11月
Authors' Addresses
作者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
ジョーTouch USC/ISI4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695米国
Phone: +1 (310) 448-9151 EMail: touch@isi.edu
以下に電話をしてください。 +1 (310) 448-9151 メールしてください: touch@isi.edu
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748 USA
デヴィッドL.黒のEMC社176の南通りMA01748ホプキントン(米国)
Phone: +1 (508) 293-7953 EMail: black_david@emc.com
以下に電話をしてください。 +1 (508) 293-7953 メールしてください: black_david@emc.com
Yu-Shun Wang Microsoft One Microsoft Way Redmond, WA 98052 U.S.A.
ワングマイクロソフト1マイクロソフト道をユーと同じくらい避けてください、ワシントン98052レッドモンド(米国)
Phone: +1 (425) 722-6980 EMail: yu-shun.wang@microsoft.com
以下に電話をしてください。 +1 (425) 722-6980 メールしてください: yu-shun.wang@microsoft.com
Touch, et al. Informational [Page 28]
接触、他 情報[28ページ]
一覧
スポンサーリンク
