[要約] RFC 5387は、Better-Than-Nothing Security（BTNS）の問題と適用範囲に関する声明であり、BTNSの目的は、低帯域幅ネットワークやリソース制約のある環境でのセキュリティを向上させることです。
Network Working Group J. Touch
Request for Comments: 5387 USC/ISI
Category: Informational D. Black
EMC
Y. Wang
Microsoft
November 2008
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）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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は、アクセス制御を有効にし、セキュリティサービスを提供するために、通常はネットワーク層エンティティの認証を必要とします。この認証は、以前の共有対称キー、関連する非対称キーを含む証明書、またはKerberosの使用などのメカニズムに基づいています（Kerberized Internet Negotiation of Keys（Kink）を介して）。認証情報とその関連するアイデンティティを展開する必要性は、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 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.
このドキュメントでは、認証なしでIPSECセキュリティサービスの使用を可能にするために、インターネットネットワークセキュリティプロトコルスイートを拡張するための根拠を説明しています。これらの拡張機能は、コミュニケーションを保護することを目的としており、「より良いセキュリティ」（BTNS）を提供します。拡張機能は独自に使用できます（この使用はスタンドアロンBTNまたはSABと呼ばれます）、またはプロトコルスタック内のより高いレイヤーによって認証できるネットワークレイヤーセキュリティを提供するために使用できます（この使用はチャネルバウンドと呼ばれますBTN、または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
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（インターネットキーエクスチェンジプロトコル）、ESP（セキュリティペイロードのカプセル）、およびAH（認証ヘッダー）で構成される）を使用して、IPトラフィックを確保します。IKEを含むIPSECは、幅広い可能な脅威からの保護を提供する高レベルのセキュリティを提供しますが、認証が必要です[5] [7] [8]。次に、認証には認証のアイデンティティと資格情報の展開が必要であり、これはIPSEC使用の障害となる可能性があります。このドキュメントでは、この依存関係について説明し、「より良いセキュリティ」（BTNS）を1つのソリューションとして紹介します。その目標は、ネットワーク層認証を必要とせずにIPSECセキュリティサービスを適用する一般的に有用な手段を提供することです。
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つの主要なアーキテクチャアプローチがあります。バンド外通信を採用し、事前に展開された情報を使用しています。帯域外認証は、信頼できるサードパーティを介して、ピアへの個別の通信チャネルを介して、または保護される通信と同じチャネルを介して行うことができますが、より高い層で行うことができます。帯域外認証には、認証されたアイデンティティを安全な通信チャネルに結合するためのメカニズムとインターフェイスが必要であり、このドキュメントの範囲外です（ただし、BTNのチャネル結合モードをそのようなメカニズムで動作させるために拡張することは可能かもしれません）。事前に展開された情報には、信頼できる当局によって認証されたアイデンティティ、事前に共有された秘密、および資格情報が含まれます（例：証明書や対応する秘密鍵）。
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.
この形式の認証には、多くの場合、通信ピア間の手動の展開と調整が必要です。さらに、認定当局（CA）が署名した証明書などの資格情報の取得と展開には、追加のプロトコルと行政措置が含まれ、実行するためにかなりの時間と労力が発生する可能性があります。
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が説明しているように、より高い層のセキュリティプロトコルは、一部のネットワーク層攻撃から保護するのに十分ではないかもしれません。
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.
状況を改善するために、ハードルを減らして認証情報を取得して構成するか、IPSECの認証要件を削除できます。後者のアプローチは、IPSECが必要な認証資格情報を持たないピアとセキュリティ協会（SAS）を作成するための匿名（無慈悲な）キーイングを提供するBTNSの中心的なアイデアです。これには、IPSECアーキテクチャへの拡張が必要です。IPSEC用の新しいBTNSモードは、認証要件を緩和するため、BTNを通信に適用する前に、影響、トレードオフ、リスクを完全に理解する必要があります。より具体的には、このドキュメントは、ネットワーク層認証を省略できるかどうか、いつ省略できるか、BTNを使用するリスク、最後に既存の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の生涯にわたって保護を提供するためにのみ使用できます。これは、特に高層層認証がない場合、BTNが使用するコア概念です。関連性の継続性は、アイデンティティが別々の関連性または帯域外で認証されないが、SAの存続期間中に変化しない認証の形と見なすことができます。
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チャネルを作成する行為はチャネル結合のインスタンスです。チャネル結合は、RFC 5056 [27]および関連する接続ラッチング文書[26]で説明されています。このサブセクションは、BTNの特定の側面を理解するために不可欠なこれらのドキュメントの一部をまとめたものです。
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: o the peer's identity is the same for the lifetime of the packet flow, and
安全なチャネルは、パケット、データグラム、オクテットストリーム接続、または暗号化の完全性を提供する2つのエンドポイント間の接続のシーケンスであり、オプションでは、それを交換するデータに対する機密性を提供します[27]。この概念をIPSECに適用すると、「IPSECチャネル」は、TCP接続などの高層プロトコルセッションに関連付けられたパケットフローです。すべてのパケットは、次のようなIPSEC SASによって保護されています。パケットフローの寿命、および
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.
接続ラッチ[26]とチャネル結合[27]の組み合わせは、IPSECチャネルを作成し、IPSEC SASを高層プロトコルに結合します。接続ラッチングは、IPSEC SASを高層プロトコルセッションに関連付けることによりIPSECチャネルを作成し、チャネルバインディングにより、高層プロトコルがIPSEC SASに認証を結合することができます。セッション間スプーフィング攻撃に対処するには、高層プロトコルセッション全体でこの「ラッチ」のキャッシュが必要であり、各高層プロトコルセッションでチャネル結合認証を実行する必要があります。接続ラッチングとチャネルバインディングは、BTNだけでなく、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ピアがIKE認証に官民キーペアを使用してSAペアを作成すると、使用されるパブリックキーのペア（ピアごとに1つ）では、チャネル結合に十分です。この情報をより高い層認証に強く組み込むことで、MITM攻撃者がトラフィックに向けたプロキシとして機能することにより、個別のSAを連結した場合、より高い層認証が失敗します。
There are two classes of scenarios in which BTNS may be used to apply IPsec services without network-layer authentication:
ネットワーク層認証なしでIPSECサービスを適用するためにBTNを使用できる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. 認証を使用しない高層プロトコルのトラフィックの保護。結果として得られる保護は「Nothing than Nothingよりも優れている」ためです。なぜなら、認証が存在しないとBTNSベースのセキュリティ協会（SA）の最初の作成が可能になった場合でも、SAのIPSECセキュリティサービスがその後のMITM攻撃に抵抗することを許可されていないSAがMITMを使用して正常に作成されるとMITMによって破壊される。BTNSを使用するこの方法は、IPSEC以外のセキュリティサービスに依存していないため、Stand-Alone BTNS（SAB）と呼ばれます。
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を使用するこの方法は、BTNSベースのSAの作成に対するMITM攻撃を検出するのに十分な場合、チャネルバウンド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.
SAペアの一方の端のIKE認証を、BTNSのもう一方の端にネットワーク層認証がないことと組み合わせることができます。結果の非対称認証は、以下のセクション3.2でさらに説明するBTNの非対称モードを作成します。
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セキュリティサービスを適用する一般的に有用な手段を提供することです。次の領域はこの範囲のBTNの範囲外であるため、このドキュメントではこれ以上説明されていません。
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 MD5 [6], that are described in other documents. BTNS is based on IPsec by design; it will not always be the most appropriate solution.
1. IPSEC以外のセキュリティフレームワークを使用して、高層プロトコルにセキュリティサービスを提供します。TLS [4]、Simple認証とセキュリティレイヤー（SASL）[11]、および一般的なセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）[10]など、IPSEC以外のさまざまなセキュリティサービスフレームワークがあります。他のドキュメントで説明されているTCP MD5 [6]など、さまざまな非IPSECセキュリティメカニズム。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. IKE認証のための拡張可能な認証プロトコル（EAP）の使用。RFC 3748のセクション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."
「EAPは、IPレイヤー接続が利用できない場合があるネットワークアクセス認証で使用するように設計されています。バルクデータトランスポートなど、他の目的でEAPを使用することは推奨されません。」
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がネットワークアクセスを確立するために使用されている状況にのみ適用できます（例：仮想プライベートネットワーク（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. マニュアルキーイングは、大量のデータを転送するプロトコルに対してマニュアルキーイングが安全ではないため、BTNの場合は考慮されていません（たとえば、RFC 3723は、この理由でISCSIを含むIPストレージプロトコルとの手動キーイングの使用を禁止しています[2]）。
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.
次のセクションでは、主にネットワーク層認証に対するIKEの要件の意味に基づいて、BTNの動機について説明します。セクション3では、SABとCBBの両方のBTNSの高レベルの概要を説明します。セクション3には、提供されるセキュリティサービスとBTNSモードの操作モードの説明も含まれています（SAB、CBB、および/またはIKE認証の組み合わせに基づきます）。セクション4では、BTNSのすべてのモードの適用性について説明します。これに続いて、セクション5のリスクとその他のセキュリティ上の考慮事項についての議論が続きます。セクション6では、他の関連する取り組みについて簡単に説明します。
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.
このセクションでは、BTNの開発を動機付けた問題について説明します。主な関心事は、厳密な開発努力とユーザーや組織によるネットワークセキュリティに重点を置いているにもかかわらず、IPSECが広く利用されていないことです。また、ネットワーク通信を保護するのに最適なレイヤーと、さまざまなレイヤーのセキュリティプロトコルがどのように相互作用するかについて、視点が異なります。次の議論は、これらの問題をレイヤーごとにほぼ分類しています：ネットワーク層と高層層。
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.
ネットワークレイヤーでは、ハードルの1つは、IPSECとIKEの認証要件を満たすことです。このセクションでは、ネットワーク層認証のいくつかの欠点とこれらの要件の結果について説明します。
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認証は、ピア認証データベース（PAD）のいくつかのタイプのIDをサポートしています：IPv4アドレス、IPv6アドレス、DNS名、著名な名前、RFC 822電子メールアドレス、およびキーID [8]。すべて認証するには、証明書または事前に共有された秘密のいずれかが必要です。パッドでサポートされるアイデンティティは、ネットワーク層識別子または他の識別子として大まかに分類できます。
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.
IPv4アドレス、IPv6アドレス、DNS名の最初の3種類の識別子は、ネットワーク層識別子です。識別子としての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.
パッドに対して定義されている他のネットワーク層識別子の他の主な欠点が2つあります。パッドの仕様でカバーされていない他の形式の識別子があるため、パッド機能は過度に制限される可能性があります（EAPはこれらの制限を一般的に緩めません。セクション1.4を参照）。IPSEC認証にネットワーク層の非識別子を使用すると、異なるレイヤーで同じまたは異なる識別子に対して複数の認証が得られる場合があり、認証と新しいエラーケースを関連付ける必要性が生じます（たとえば、同じ識別子の2つの認証のうちの1つが失敗します）。これらの問題はチャネルの結合にも関連しており、このドキュメントの後半でさらに説明します。
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 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およびIKE仕様によって受け入れられる認証の唯一の方法です。事前に共有された秘密には、手動の構成とバンド外の通信が必要です。証明書の検証プロセスは面倒であり、さらに、証明書を取得する際には、管理および潜在的な金銭的費用があります。これらの要因は、IPSECが最も高いセキュリティ要件を持つ環境外で広く使用されていない可能性のある理由の1つです。
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.
セキュリティポリシーデータベース（SPD）の事前構成「バイパス」エントリを有効にすることを許可されていないピアとの通信を有効にすると、ピアIPアドレスが事前に既知である場合にのみ機能します。認定されていないIPSECモードの欠如は、多くの場合、高層プロトコルまたはアプリケーションでその後認証されている場合でも、認証されていない、または未知のピアとのネットワークレイヤーでのセキュリティを防ぎます。IPSECと高層プロトコル間のチャネル結合APIの欠如は、そのような通信をさらにIPSECを完全にバイパスするように強制する可能性があり、そのような通信のネットワークレイヤーは保護されていません。
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の使用の管理負担を減らすためのさらなる動機を提供します。これに続いて、ネットワークレイヤーと同じ接続の高レイヤーの両方で認証を使用することの意味についての議論が続きます。
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]。インターネットには、そのようなスプーフィングされたトラフィックを損傷を引き起こす可能性がある包括的なイングレスフィルタリングがありません。これらの攻撃は、コアインターネットルーター間のBGPセッションに影響を与える可能性があるため、大きな懸念があります[3] [12]。その結果、多くの提案されたソリューションが開発されており、そのほとんどは輸送層にあります。
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 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]).
これらのソリューションのいくつかは、TCP MD5 [6]など、独自のセキュリティを改善することにより、輸送プロトコルを強化しています。他の人は、コアTCP処理ルールを変更して、オフパス攻撃者が最初の握手（たとえば、Syn Cookie）または接続が確立された後（TCPSECUREなど）意味のあるパケットを注入することを難しくします[15] [23]。これらのアプローチのいくつかはTCPにとって新しいものですが、すでに他の輸送プロトコル（例えば、ストリーム制御伝送プロトコル（SCTP）[22]）または中間（いわゆるレイヤー3.5）プロトコル（例えば、ホストアイデンティティプロトコル（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.
スプーフィングされたパケットからシステムを保護することは、最終的に認証の問題であり、受信者のパケットのソースの解釈が正確であることを保証します。認証は、パケットのソースのIDを検証します。現在の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に関しては、適切なネットワークまたは輸送層認証の使用がTCPスプーフィング攻撃からの好ましい保護であることが理解されています[3]。1つのルーター自体での認証は、そのルーターが認証をサポートすることに依存するため、そのルーターがピアリングするすべてのルーターに慈悲を維持するため、全体的なBGPセキュリティを提供しません[25]。現実には、認証をサポートするように設定されているインターネットルーターはほとんどなく、その結果、BGPパケットを送信するために無担保TCPが使用されます。BTNSを使用すると、個々のルーターが認証の必要性を緩和して、認証されていない保護セッションの使用を可能にすることができます。後者は、「何もない」場合に「何もない」ということです。ルーティングコミュニティは、BGPのTCP接続を保護するためにBTN以外のソリューションを選択していますが（たとえば、TCP MD5）、BTNSの開発の動機であるため、BGPの議論はこのドキュメントに残っています。
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 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.
インターネットで使用される既存のプロトコルの中には、ネットワークおよび輸送層の上に認証を提供しますが、パケットごとの暗号化と機密性サービスのIPSECスイートに依存しています。このようなプロトコルの例には、ISCSI [19]およびリモート直接データ配置（RDDP）プロトコル[16] [20]が含まれます。現在のIPSECスイートでは、2つの認証操作があります。1つはIKEの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とは無関係に、常に使用可能になるため、高層プロトコル認証が望ましいです。
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セキュリティ協会を設定することでこの問題に対処し、その後、高層プロトコルセッションが保護されていることを確立するために拡張された形式の高レイヤー認証を使用することができます。単一のIPSEC SAによって。これは、そのような攻撃が発生したときに認証障害を介して高層セッションを終了することにより、BTNS IPSECセッションの確立に対する中間（MITM）攻撃に対抗します。その結果、単一の認証操作は、高層のピアのアイデンティティだけでなく、そのピアに対するセキュリティ協会の継続性も検証します。単一のIPSEC SAのこの高層チェックは、このドキュメントで「チャネル結合」と呼ばれるため、名前チャネルバウンドBTN（CBB）[27]と呼ばれます。
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セキュリティサービスの概要を説明します。また、BTNの複数の動作モードについても説明しています。
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.
これは、BTNを有効にするために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の場合、最初の拡張機能はパッドに適用されます。これは、各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と高層プロトコルまたはアプリケーション間のチャネル結合を有効にするための変更は、上記のポリシー拡張よりも複雑です。APIを指定し、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.
BTNの変更と拡張は、主に上記のIPSECポリシーに影響します。IPSECおよびIKE仕様の他の部分は変更されていません。BTNSは、システム内のIPSEC実装と統合できるため、個別の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.
原則として、すべてのSAが認証されるという要件を削除した結果は、BTNが完全に認証されたIKEと同様の方法で安全なIPSEC接続を確立できることですが、BTNはこれらのSAのピアアイデンティティを検証または認証することはできません。以下は、BTNの追加によって作成された違いに対処するノートを含む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のアクセス制御サービスを拡張して、認識されていない接続を可能にします。これらの拡張機能は、BTNS拡張機能を使用しないエントリに関連付けられたアクセスコントロールに影響を与えないファッションで、IPSECパッドおよびSPDと統合されています。チャネルバウンドBTNの場合、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 6. (Limited) Traffic Flow Confidentiality
5. 機密性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手段によって確立された接続と同じ方法で、これらのセキュリティサービスによって保護されます。
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:
前のセクションでは、BTNを使用する2つの方法について説明しています：スタンドアロン（SAB）とチャネルバウンド（CBB）。これらは両方とも対称的に使用することもできます。ここでは、どちらの当事者もネットワークレイヤーで認証しないか、非対称で、1つの当事者のみがネットワークレイヤーで認証しない場合です。SAB、CBB、およびIDの従来の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 |
| | | | | |
-----+-------+-------+ -------+---------+---------+
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）：1つの当事者は、従来のIKEサポートされたアイデンティティで認証されませんが、反対側はそのようなアイデンティティで認証します。
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:
チャネル結合を備えたBTNに関与する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.
注：対称または非対称として資格を持たずに、スタンドアロンBTN（SAB）またはチャネルバウンドBTN（CBB）が使用される場合、対称モードは意図したデフォルトの意味です。
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は、一般に公開されているが、保護された関連付けが望まれるサービス、およびプロトコルスタックのより高いレイヤーで認証できるサービスを目的としています。BTNは、代替BTNがまったく保護されていない場合、プライベートサービスのある程度の保護を提供することもできます。
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.
このセクションでは、BTNのさまざまなモードに適したアプリケーションの種類の概要を説明します。次の2つのセクションでは、全体的な利点と脆弱性について説明し、それに続いて各BTNSモードの適用可能性分析が続きます。アプリケーションステートメントは、4つのBTNS固有のモードのみをカバーしています。AUTHとCB-Authモードは、この議論の範囲外です。
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は、ネットワーク層認証を必要とせずにネットワークと輸送層を保護します。BTNは、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は、フラッシュ群衆をエミュレートするDDO（分散拒否拒否）攻撃の努力を提起します。オープンサービスの場合、このようなDDOS攻撃を実際のフラッシュクラウドと区別する方法がない場合があります。
BTNS also allows individual security associations to be established for protection of higher-layer traffic without requiring pre-deployed authentication credentials.
また、BTNSは、事前に展開された認証資格情報を必要とせずに、高層トラフィックを保護するために個々のセキュリティ関連を確立することができます。
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 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は、すべてのIPSEC SAが認証されるという要件を削除します。BTNSホストに接続するホストは、SABの協会全体で仮面舞踏会と通信することに対して、またはCBBの追加認証を提供するまで脆弱です。その結果、仮面舞踏会のピアに送信された認証データ（例：パスワード）が攻撃者に開示される可能性があります。これは意図的なデザイントレードオフです。BTNSでは、ネットワークおよびトランスポート層のアクセスは、他のホストによって提示されたアイデンティティによって制御されなくなり、潜在的なマスカレードとフラッシュクラウドの攻撃にホストを開きます。逆に、BTNは、ネットワークレイヤーで認証できないホストへの接続を確保できます。そのため、ネットワークレイヤーと輸送層は、高層認証だけで達成できるよりも保護されています。
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ネットワークアソシエーションへの高層認証の結合の有効性にも依存しています。
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互換認証資格情報を使用できず、高層認証またはその他のセキュリティ保護を採用していないアプリケーションを対象としています。SABは、いずれかの当事者のアイデンティティが重要ではない、または意図的に省略されている場合にも適していますが、IPSECセキュリティサービスが必要です（セクション3.2を参照）。SABは、接続の反対側のエンティティが変更されていないという保証が認証の欠如に十分な代替品である可能性があるため、長命の接続またはセッションに特に適用できます。このセクションでは、対称的および非対称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は、大きなファイルの転送または他の長寿命の接続の使用が、輸送接続に対する攻撃によって中断されないことから利益を得ることがあるが、特定のエンドポイントのアイデンティティは重要ではない状況で役立ちます。。
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 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.
Webサーバーやピアツーピアネットワークなどのオープンサービスは、アイデンティティを認証する必要がなく、通信が保護の恩恵を受ける場合、S-SABを利用できます。このようなサービスは、他の手段（たとえば公開されたハッシュ）によって検証または検証されていないファイルを提供する場合があります。これらの送信は、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がオープンサービスとして意図していない場合でも、S-SABによって提供される保護がまったく保護よりも優れているコアルーター間のBGP TCP接続の場合です。
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への中間ステップとしても機能します。S-SABは、（接続ラッチングを介して）IPSECチャネルを使用する場合の効果的な結果ですが、高層性認証はチャネル内のIPSEC SASにバインドされていません。
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は、インターネット上のオープンサービスのトランスポート接続を保護するのに役立ちます。たとえば、商用Webサーバーなど。これらの場合、サーバーはアプリケーションレイヤーでTLSで行われるように、広く知られているCAによって認証されますが、クライアントを認証する必要はありません[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は、Webキャストが遠隔教育やエンターテイメントに使用するようなストリーミングメディアの輸送を確保することもできます。
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 authentication mechanisms not supported by IKE and frees higher-layer applications and protocols from duplicating security services already available in IPsec.
CBBを使用すると、ネットワーク層認証情報なしでホストがBTNSベースのIPSEC SASを上級レイヤーで認証に結合することができます。CBBは、より高い層認証を採用しているが、追加のネットワーク層セキュリティの恩恵を受けるアプリケーションを対象としています。CBBは、ネットワークレイヤーで認証を必要とせずにネットワーク層セキュリティサービスを提供します。これにより、IKE-Inccatible認証資格情報を持つアプリケーションのIPSECセキュリティサービスが可能になります。CBBを使用すると、IKESCが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は、非対称CBBとA-SABと同様に、チャネル結合を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のモードは、ネットワークレイヤーでの認証を指しますが、高層層認証は非対称（片道）または対称（双方向）のいずれかです。非対称CBBを使用して、ネットワークレイヤーで反対方向の一元配置認証を提供することにより、より高いレイヤーで一元配置認証を補完できます。一方向のクライアントのみの認証を備えたアプリケーションを検討してください。クライアントは、サーバーがネットワークレイヤーにIKE-Authenticed Credentialsを提示する必要があるA-CBBを使用できます。この形式のA-CBBは、別々のレイヤーではありますが、相互認証を実現します。ISCSIやNFSなどの多くのリモートファイルシステムプロトコルは、このカテゴリに適合し、MITM攻撃の防止を含むネットワーク層保護を改善するために、IPSECとのチャネル結合の恩恵を受けることができます。
Mechanisms and interfaces for BTNS channel binding with IPsec are discussed in further detail in [26].
IPSECによるBTNSチャネル結合のメカニズムとインターフェイスについては、[26]でさらに詳細に説明します。
The following is a summary of the properties of each type of BTNS, based on the previous subsections:
以下は、以前のサブセクションに基づいて、各タイプのBTNのプロパティの概要です。
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]
Vuln. Masqueraders Masqueraders until bound
Needs data rate limit Needs data rate limit
Load on IPsec Load on IPsec
Exposure to open access
Benefit Protects L3 & L4 Protects L3 & L4 Avoids all auth. keys Avoids L3 auth. keys Full auth. once bound
利益保護L3＆L4はL3とL4を保護し、すべての認証を回避します。キーはL3認証を回避します。キーフルオーチング。一度バインドされます
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処理の負荷の増加など、より一般的な問題のいくつかは、このドキュメントのセキュリティに関する考慮事項セクションで対処されています。
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の脅威モデルについて説明し、BTNのさまざまなモードの脅威モデルに基づいて他のセキュリティ問題について説明します。いくつかの問題は文書で以前に言及されましたが、完全性のために再びリストされています。
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は主要な交換自体を保護することを意図していないため、これは中間の攻撃または他のソースからの適切なタイミングの攻撃の機会を提供します。さらに、スタンドアロン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.
次のセクションでは、脅威モデルの影響についてさらに詳しく説明します。
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 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.
ネットワークセキュリティのどの側面と同様に、BTNの使用は他のセキュリティサービスに干渉してはなりません。IPSEC内では、BTNSの範囲は、BTNを明示的に指定するSPDおよびPADエントリ、および結果のSADエントリに限定されています。システム管理者は、IPSEC暗号保護から指定されたトラフィックを免除する「バイパス」SPDエントリの使用に代わる、できれば安全な場合にのみBTNを展開することが義務付けられています。言い換えれば、BTNは、より強力なセキュリティの代替としてではなく、セキュリティなしの代替としてのみ使用する必要があります。CBBに必要な高層認証が利用できない場合、IPアドレスフィルタリングなどの他の方法は、SABの匿名アクセスへの露出に対する脆弱性を減らすのに役立ちます。
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.
BTNSは主要な交換を保護せず、ネットワークレイヤーでピアアイデンティティを認証していない場合でも、以前のセクションでは、CBBがMITMおよび仮面舞踏会攻撃に対抗できる方法について説明しました。それにもかかわらず、BTNを展開する前に慎重に評価する必要がある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認証を破壊することはできません。したがって、トラフィックフォワードプロキシとして機能する攻撃者によって連結された2つのSASを使用して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を使用してはなりません。たとえば、Kerberos v APの交換はターゲットのKRB5の主名以外にほとんど漏れませんが、Kerberos VはPA-ECN-TIMESTAMPの事前認定を使用した交換として、オフラインで攻撃できる材料を漏れます。後者は、チャネル結合であっても、BTNSで使用しないでください。さらに、BTNSが高層プロトコルと統合される方法は、これら2つのシステム間のAPIまたはそれらが共有する情報で導入できる脆弱性を考慮する必要があります。
The resource consumption issue is addressed in the next section on DoS attacks.
リソース消費の問題は、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攻撃の結果である可能性があります。これ自体が展開に大きな障害をもたらす可能性がありますが、暗号化されたすべての通信システムにとって問題です。このドキュメントは、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.
リソース消費の増加の影響は2つあります。消費はMITMなどの攻撃の努力のレベルを上げますが、そのような攻撃を検出し、スプーフィングされたトラフィックを拒否するためのより多くのリソースも消費します。ネットワークレイヤーでは、すべてのBTNS SASに対してリソースの適切な制限とアクセス制御を設定する必要があります。CBB SASは、高層認証が成功した後、リソースアクセスの増加を認められる場合があります。同じ原則は、CBB SASを使用する高層プロトコルに適用されます。これらのアプリケーションで認証が確立される前に、過度のリソースの使用を避けるために特別な注意を払う必要があります。
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は、公然と利用できることを意図していないサービスで使用しないでください。
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トラフィックハンドリングに関する既存のIPSECガイドラインを変更しないため、このドキュメントではICMP攻撃を考慮しません[8]。BTNSは、セキュリティ協会の確立の認証部分に焦点を当てています。BTNSは、IPSECトラフィック処理モデルと保護境界を変更しません。その結果、ICMP処理を含むIPSECパケット処理ガイドライン全体が、BTNSがIPSECに追加された場合、適用可能なままです。
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 Shell Protocol（SSH）[29]などの他のセキュリティプロトコルやアプリケーションで使用される「信仰の飛躍」認証と同様の機能を有効にすることができます。
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の実装は、認証なしで不明なピア資格情報（ホストパブリックキー）を受け入れることができます。これらの認定されていない資格情報は、同じピアの将来の認証のためにローカルデータベースにキャッシュされる場合があります。BTNと同様に、「広く展開されている主要なインフラストラクチャ」[29]の欠如と、使いやすさとエンドユーザーの受け入れを改善するため、このような措置は許可されています。
There are subtle differences between SSH and BTNS regarding Leap of Faith, as shown in the following table:
次の表に示すように、信仰の飛躍に関してSSHとBTNSの間には微妙な違いがあります。
| SSH | BTNS |
-------------------------------+---------+---------+
Accept unauthenticated | Allowed | Allowed |
credentials | | |
-------------------------------+---------+---------+
Options/Warnings to reject | Yes | No |
unauthenticated credentials | | |
-------------------------------+---------+---------+
Cache unauthenticated |Required | Allowed |
credential for future refs | | |
-------------------------------+---------+---------+
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.
さらに、BTNは、SSHと同様の方法で資格情報を再利用するためにIPSECを必要としません。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.
SABで再利用するためのSSHスタイルの資格キャッシュは、将来の拡張（S）からBTNSによって対処できます。このような拡張機能は、SSHの「信仰の飛躍」に匹敵する認証保証を確立するために、認証保証のレベルを確立するために、非認証資格情報とユーザーの受け入れまたは拒否のメカニズムに関する警告を提供する必要があります。このような拡張機能は、BTNにIDがないことによって引き起こされる問題にも対処する必要があります。せいぜい、キャッシュされたBTNS資格情報は、資格情報が再利用されるときにネットワーク層トラフィックのソースを再確認します - 対照的に、SSH資格情報の再利用はアイデンティティを再認証します。
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 NATが複数の独立したネットワーク層のトラフィックソースを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.
これらの問題は、BTNに「信仰の飛躍」機能を追加することに関する将来の作業によって対処されるべきです。
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の場合、資格のキャッシュと検証は通常、高層プロトコルまたはアプリケーションで行われます。BTNSレベルでのCBBのキャッシュ資格情報は、チャネルバインディングが上位層プロトコルのアイデンティティに提示された（新規またはキャッシュされた）すべての資格情報を結合するため、それほど重要ではありません。
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を再キーすると、パスでの攻撃者が介入して、再キーイング中に犠牲者をスプーフィングすることによって作成された新しいSAをハイジャックできる小さな機会を提供します。BTNS、特にSABは、攻撃者が被害者として認証する必要性を削除するか、元のSAで被害者が使用した同じ非BTNSパッドエントリを介してこの攻撃を簡素化します。一方、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のセッション間結合またはラッチングの欠如によって引き起こされます。接続ラッチは、チャネルバインディングとともに、このようなバインディングを可能にしますが、2つのSASにわたるアイデンティティと認証の一貫性を検証するために、高層プロトコルまたはアプリケーションが必要です。
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エントリを使用してすでに可能です。BTNを許可するSPDエントリに明示的にフラグを立てる必要があるため、「バイパス」SPDエントリは、より一般的で強力なセキュリティを持つSASを作成するエントリとは別に、BTNを許可しないSPDエントリとは別に保持できます。
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の取り組みは、たとえば、インターネットセキュリティサービスの構成のための自動インフラストラクチャを提供することに焦点を当てており、例えば、署名された証明書とCA情報の展開を支援します[9]。IETFキンクの取り組みは、IKEのKerberos [13]の適応に焦点を当てており、IKEが証明書や共有のプライベートキーを必要とするのではなく、Kerberosキーディストリビューションインフラストラクチャを利用できるようにしました[18]。Kinkは、Kerberosの自動キー管理のための既存のアーキテクチャを利用しています。日和見的暗号化（OE）は、BTNSのような暗号化を喜んで行うホストの自動発見のシステムであり、DNSの既存の使用を活用することで認証が交換されます[17]。BTNSは、BTNSが自動化するのではなく、そのようなインフラストラクチャの必要性を完全に回避することを目的としているため、3つすべてとは異なります。
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攻撃に関するIETF TCPM WGに関する議論、およびIPSECとのより良い統合方法に関するNFSV4およびIPS WGの議論に触発されました。BTNSの概念は、これらの議論の結果であり、USC/ISIのT. Faber、A。Falk、およびB. Tungとの議論、およびIETF SAAG（セキュリティエリアオープンミーティング）メーリングリストとIPSECメーリングリストに関する議論でした。著者は、これらのWGSとリストのメンバー、IETF BTNS BOFSとWGおよびその関連するANONSECメーリングリスト（http://www.postel.org/anonsec）に感謝したいと思います。スティーブ・ケント、サム・ハートマン、ニコラス・ウィリアムズ、ペッカ・サヴォラ。
This document was prepared using 2-Word-v2.0.template.dot.
このドキュメントは、2ワード-V2.0.template.dotを使用して準備されました。
[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.、Carlson、J。、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、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.、Tseng、J.、Walker、J.、Rangan、V。、およびF. Travostino、「IPを介したブロックストレージプロトコルの保護」、RFC 3723、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 Gateway Protocolは、認証要件を指定せずに永続的なTCPセッションに依存しています」、2004年4月20日。
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[4] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[5] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[6] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[7] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[7] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[8] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[9] Korver、B。、「IKEV1/ISAKMP、IKEV2、およびPKIXのインターネットIPセキュリティPKIプロファイル」、RFC 4945、2007年8月。
[10] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[10] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[11] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[11] Melnikov、A.、ed。、およびK. Zeilenga、ed。、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[12] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[12] マーフィー、S。、「BGPセキュリティ脆弱性分析」、RFC 4272、2006年1月。
[13] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[13] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[14] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[14] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[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 Stewart、M。Dalal、「Window In Window攻撃に対するTCPの堅牢性の向上」、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.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「リモートダイレクトメモリアクセスプロトコル仕様」、RFC 5040、2007年10月。
[17] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
[17] Richardson、M。およびD. Redelmeier、「インターネットキーエクスチェンジ（IKE）を使用した日和見暗号化」、RFC 4322、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.、Thomas、M。、およびJ. Vilhuber、「Kerberized Internet negotiation of Keys（Kink）」、RFC 4430、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.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M。、およびE. Zeidner、「Internet Small Computer Systems Interface（ISCSI）」、RFC 3720、2004年4月。
[20] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[20] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「信頼できる輸送を介した直接データ配置」、RFC 5041、2007年10月。
[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.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 3530、2003年4月。
[22] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[22] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[23] TCP SYN-cookies, http://cr.yp.to/syncookies.html
[23] TCP syn-Cookies、http：//cr.yp.to/syncookies.html
[24] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[24] Touch、J。、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[25] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication Option", Work in Progress, November 2007.
[25] Touch、J.、A。Mankin、R。Bonica、「TCP認証オプション」、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。、「チャネルバインディングの使用に関するチャネルの使用について」、RFC 5056、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の無認定モード」、RFC 5386、2008年11月。
[29] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[29] Ylonen、T。およびC. Lonvick、ed。、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
Authors' Addresses
著者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676 Admiralty Way Marina Del Rey、CA 90292-6695 U.S.A.
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748 USA
David L. Black EMC Corporation 176 South Street Hopkinton、MA 01748 USA
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Yu-Shun Wang Microsoft One Microsoft Way Redmond, WA 98052 U.S.A.
Yu-Shun Wang Microsoft One Microsoft Way Redmond、WA 98052 U.S.A.
Phone: +1 (425) 722-6980
EMail: yu-shun.wang@microsoft.com