[要約] 要約：RFC 4016は、PANA（Protocol for Carrying Authentication and Network Access）の脅威分析とセキュリティ要件に関するプロトコルです。 目的：このRFCの目的は、PANAプロトコルのセキュリティ上の脅威を分析し、適切なセキュリティ要件を定義することです。
Network Working Group M. Parthasarathy
Request for Comments: 4016 Nokia
Category: Informational March 2005
Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements
認証とネットワークアクセス（PANA）の脅威分析とセキュリティ要件を運ぶためのプロトコル
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) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol.
このドキュメントでは、ネットワークアクセスのために認証を運ぶために使用されるプロトコルに対する脅威について説明します。これらの脅威から生じるセキュリティ要件は、IPベースのネットワークアクセス認証プロトコルを設計するためのネットワークアクセス（PANA）ワーキンググループを運ぶためのプロトコルへの追加の入力として使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Definitions. . . . . . . . . . . . . . . . . . 2
4. Usage Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 3
5. Trust Relationships. . . . . . . . . . . . . . . . . . . . . . 4
6. Threat Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. PAA Discovery. . . . . . . . . . . . . . . . . . . . . . 6
6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 6
6.3. PaC Leaving the Network. . . . . . . . . . . . . . . . . 9
6.4. Service Theft. . . . . . . . . . . . . . . . . . . . . . 10
6.5. PAA-EP Communication . . . . . . . . . . . . . . . . . . 11
6.6. Miscellaneous Attacks. . . . . . . . . . . . . . . . . . 12
7. Summary of Requirements. . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
The Protocol for Carrying Authentication for Network Access (PANA) Working Group is developing methods for authenticating clients to the access network using IP based protocols. This document discusses the threats to such IP based protocols.
ネットワークアクセス（PANA）ワーキンググループの認証を運ぶためのプロトコルは、IPベースのプロトコルを使用してアクセスネットワークにクライアントを認証する方法を開発しています。このドキュメントでは、そのようなIPベースのプロトコルに対する脅威について説明します。
A client wishing to get access to the network must carry on multiple steps. First, it needs to discover the IP address of the PANA authentication agent (PAA) and then execute an authentication protocol to authenticate itself to the network. Once the client is authenticated, there might be other messages exchanged during the lifetime of the network access. This document discusses the threats in these steps without discussing any solutions. The requirements arising out of these threats will be used as input to the PANA Working Group. The use of word co-located in this document means that the referred entities are present on the same node.
ネットワークへのアクセスを希望するクライアントは、複数の手順を実行する必要があります。まず、PANA認証エージェント（PAA）のIPアドレスを発見し、認証プロトコルを実行してネットワークに認証する必要があります。クライアントが認証されると、ネットワークアクセスの存続期間中に他のメッセージが交換される可能性があります。このドキュメントでは、解決策を議論することなく、これらのステップの脅威について説明します。これらの脅威から生じる要件は、パナワーキンググループへの入力として使用されます。このドキュメントで共同配置された単語の使用は、紹介されたエンティティが同じノードに存在することを意味します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
Client Access Device
クライアントアクセスデバイス
A network element (e.g., notebook computer, PDA) that requires access to a provider's network.
プロバイダーのネットワークへのアクセスを必要とするネットワーク要素（ノートブックコンピューター、PDAなど）。
Network Access Server (NAS)
ネットワークアクセスサーバー（NAS）
Network device that provides access to the network.
ネットワークへのアクセスを提供するネットワークデバイス。
PANA Client (PaC)
パナクライアント（PAC）
An entity in the edge subnet that seeks to obtain network access from a PANA authentication agent within a network. A PANA client is associated with a device and a set of credentials to prove its identity within the scope of PANA.
ネットワーク内のパナ認証エージェントからネットワークアクセスを取得しようとするエッジサブネットのエンティティ。PANAクライアントは、パナの範囲内でそのアイデンティティを証明するためのデバイスと資格情報のセットに関連付けられています。
PANA Authentication Agent (PAA)
パナ認証エージェント（PAA）
An entity whose responsibility is to authenticate the PANA client and to grant network access service to the client's device.
PANAクライアントを認証し、クライアントのデバイスにネットワークアクセスサービスを付与する責任を負うエンティティ。
Authentication Server (AS)
認証サーバー（AS）
An entity that authenticates the PANA client. It may be co-located with the PANA authentication agent or part of the back-end infrastructure.
Panaクライアントを認証するエンティティ。パナ認証エージェントまたはバックエンドインフラストラクチャの一部と共同で開催される場合があります。
Device Identifier (DI)
デバイス識別子（di）
The identifier used by the network to control and police the network access of a client. Depending on the access technology, the identifier might contain the IP address, link-layer address, switch port number, etc., of a device. The PANA authentication agent keeps a table for binding device identifiers to the PANA clients. At most one PANA client should be associated with a DI on a PANA authentication agent.
ネットワークで使用される識別子は、クライアントのネットワークアクセスを制御および警察します。アクセステクノロジーに応じて、識別子には、デバイスのIPアドレス、リンク層アドレス、スイッチポート番号などが含まれる場合があります。PANA認証エージェントは、PANAクライアントにバインディングデバイス識別子のテーブルを保持します。せいぜい1つのパナクライアントは、パナ認証エージェントのDIに関連付けられる必要があります。
Enforcement Point (EP)
執行ポイント（EP）
A node capable of filtering packets sent by the PANA client by using the DI information authorized by PANA authentication agent.
PANA認証エージェントによって承認されたDI情報を使用して、PANAクライアントが送信したパケットをフィルタリングできるノード。
Compound methods
複合方法
Authentication protocol in which methods are used in a sequence one after another or in which methods are tunneled inside another independently established tunnel between the client and server [TUN-EAP].
次々にメソッドがシーケンスで使用される認証プロトコル、またはクライアントとサーバーの間の別の独立して確立されたトンネル内でメソッドがトンネル化される[Tun-EAP]。
PANA is intended to be used in an environment where there is no a priori trust relationship or security association between the PaC and other nodes, such as the PAA and EP. In these environments, one may observe the following:
PANAは、PACやPAAやEPなどの他のノードとの間にアプリオリの信頼関係またはセキュリティ関連がない環境で使用されることを目的としています。これらの環境では、次のことを観察することができます。
o The link between PaC and PAA may be a shared medium (e.g., Ethernet) or may not be a shared medium (e.g., DSL network).
o PACとPAAの間のリンクは、共有媒体（イーサネットなど）であるか、共有媒体（DSLネットワークなど）ではない場合があります。
o All the PaCs may be authenticated to the access network at layer 2 (e.g., 3GPP2 CDMA network) and share a security association with a layer 2 authentication agent (e.g., BTS). The PaCs still don't trust each other; any PaC can pretend to be a PAA, spoof IP addresses, and launch various other attacks.
o すべてのPACは、レイヤー2のアクセスネットワーク（3GPP2 CDMAネットワークなど）に認証され、セキュリティ関連をレイヤー2認証エージェント（BTSなど）と共有できます。PACはまだお互いを信頼していません。どんなPACでも、PAAのふりをしたり、IPアドレスをスプーフィングしたり、他のさまざまな攻撃を開始したりできます。
The scenarios mentioned above affect the threat model of PANA. This document discusses the various threats in the context of the above network access scenarios for a better understanding of the threats. In the following discussion, any reference to a link that is not shared (or non-shared) is assumed to be physically secure. If such an assumption cannot be made about the link, then the case becomes the same as that for a link being shared by more than one node.
上記のシナリオは、パナの脅威モデルに影響します。このドキュメントでは、脅威をよりよく理解するために、上記のネットワークアクセスシナリオのコンテキストでさまざまな脅威について説明します。以下の議論では、共有されていない（または共有非共有）リンクへの言及は、物理的に安全であると想定されています。リンクについてそのような仮定を行うことができない場合、ケースは複数のノードで共有されるリンクの場合と同じになります。
PANA authentication involves a client (PaC), a PANA agent (PAA), an Authentication server (AS), and an Enforcement point (EP). The AS here refers to the AAA server that resides in the home realm of the PaC.
PANA認証には、クライアント（PAC）、PANAエージェント（PAA）、認証サーバー（AS）、および執行ポイント（EP）が含まれます。このように、PACのホーム領域にあるAAAサーバーを指します。
The entities that have a priori trust relationships before PANA begins are as follows:
パナが始まる前にアプリオリの信頼関係を持つエンティティは次のとおりです。
1) PAA and AS: The PaC belonging to the same administrative domain that the AS does often has to use resources provided by a PAA that belongs to another administrative domain. A PAA authenticates the PaC before providing local network access. The credentials provided by the PaC for authentication may or may not be understood by the PAA. If the PAA does not understand the credentials, it needs to communicate with the AS in a different domain to verify the credentials. The threats in the communication path between the PAA and AS are already covered in [RAD-EAP]. To counter these threats, the communication between the PAA and AS is secured by using a static or dynamic security association.
1) PAAおよびAS：PACは、他の管理ドメインに属するPAAが提供するリソースを使用することがよくあるのと同じ管理ドメインに属するPACです。PAAは、ローカルネットワークアクセスを提供する前にPACを認証します。認証のためにPACが提供する資格情報は、PAAによって理解される場合と理解されない場合があります。PAAが資格情報を理解していない場合、資格情報を検証するために別のドメインでASと通信する必要があります。PAAとASの間の通信パスの脅威は、[rad-eap]ですでにカバーされています。これらの脅威に対抗するために、静的または動的セキュリティ協会を使用してPAAとASの間のコミュニケーションが確保されます。
2) PAA and EP: The PAA and EP belong to the same administrative domain. Hence, the network operator can set up a security association to protect the traffic exchanged between them. This document discusses the threats in this path.
2) PAAとEP：PAAとEPは同じ管理ドメインに属します。したがって、ネットワークオペレーターは、セキュリティ協会を設定して、それらの間で交換されるトラフィックを保護できます。このドキュメントでは、このパスの脅威について説明します。
3) PaC and AS: The PaC and AS belong to the same administrative domain and share a trust relationship. When the PaC uses a different domain than its home for network access, it provides its credentials to the PAA in the visited network for authentication. The information provided by the PaC traverses the PaC-PAA and PAA-AS paths. The threats in the PAA-AS path are already discussed in [RAD-EAP]. This document discusses the threats in the PaC-PAA path.
3) PACおよびAS：PACおよびASは同じ管理ドメインに属し、信頼関係を共有します。PACがネットワークアクセスのためにホームとは異なるドメインを使用する場合、認証のために訪問されたネットワークでPAAに資格情報を提供します。PACが提供する情報は、PAC-PAAとPAA-ASパスを横断します。PAA-ASパスの脅威は、[rad-eap]ですでに説明されています。このドキュメントでは、PAC-PAAパスの脅威について説明します。
It is possible that some of the entities such as the PAA, AS, and EP are co-located. In those cases, it can be safely assumed that there are no significant external threats in their communication.
PAA、AS、およびEPなどの一部のエンティティが共同住宅化されている可能性があります。そのような場合、彼らのコミュニケーションに重要な外部の脅威はないと安全に想定することができます。
The entities that do not have any trust relationship before PANA begins are as follows:
パナが始まる前に信頼関係がないエンティティは次のとおりです。
1) PaC and PAA: The PaC and PAA normally belong to two different administrative domains. They do not necessarily share a trust relationship initially. They establish a security association in the process of authentication. All messages exchanged between the PaC and PAA are subject to various threats, which are discussed in this document.
1) PACとPAA：PACとPAAは通常、2つの異なる管理ドメインに属します。彼らは必ずしも最初に信頼関係を共有するわけではありません。彼らは、認証の過程でセキュリティ協会を設立します。PACとPAAの間で交換されるすべてのメッセージは、このドキュメントで説明されているさまざまな脅威の対象となります。
2) PaC and EP: The EP belongs to the same administrative domain as the PAA. Hence, the PaC and EP do not necessarily share a trust relationship initially. When the PaC is successfully authenticated, it may result in key establishment between the PaC and PAA, which can be further used to secure the link between the PaC and EP. For example, the EAP keying framework, [EAP-KEY], defines a three party EAP exchange in which the clients derive the transient sessions keys to secure the link between the peer and NAS in their final step. Similarly, PANA will provide the ability to establish keys between the PaC and EP that can be used to secure the link further. This is discussed further in Section 6.4 below.
2) PACおよびEP：EPは、PAAと同じ管理ドメインに属します。したがって、PACとEPは必ずしも最初に信頼関係を共有するとは限りません。PACが正常に認証されると、PACとPAAの間に重要な設立が発生する可能性があり、PACとEPの間のリンクを確保するためにさらに使用できます。たとえば、EAPキーイングフレームワーク[EAP-Key]は、クライアントが一時的なセッションキーを導き出して、最終ステップでピアとNASの間のリンクを確保する3つのパーティーEAP交換を定義します。同様に、Panaは、リンクをさらに保護するために使用できるPACとEPの間にキーを確立する機能を提供します。これについては、以下のセクション6.4でさらに説明します。
First, the PaC needs to discover the PAA. This involves either sending solicitations or waiting for advertisements. Once it has discovered the PAA, the two will enter authentication exchange. Once the access is granted, the PaC will most likely exchange data with other nodes in the Internet. These steps are vulnerable to man-in-the-middle (MITM), denial of service (DoS), and service theft attacks, which are discussed below.
まず、PACはPAAを発見する必要があります。これには、勧誘を送信するか、広告を待つことが含まれます。PAAが発見されると、2人は認証交換を入力します。アクセスが許可されると、PACはおそらくインターネット内の他のノードとデータを交換します。これらの手順は、中間者（MITM）、サービス拒否（DOS）、およびサービス盗難攻撃に対して脆弱であり、以下で説明します。
The threats are grouped by the various stages the client goes through to gain access to the network. Section 6.1 discusses the threats related to PAA discovery. Section 6.2 discusses the threats related to authentication itself. Section 6.3 discusses the threats involved when leaving the network. Section 6.4 discusses service theft. Section 6.5 discusses the threats in the PAA-EP path. Section 6.6 discusses the miscellaneous threats.
脅威は、ネットワークにアクセスするためにクライアントが通過するさまざまな段階によってグループ化されます。セクション6.1では、PAA発見に関連する脅威について説明します。セクション6.2では、認証自体に関連する脅威について説明します。セクション6.3では、ネットワークを離れる際の脅威について説明します。セクション6.4では、サービスの盗難について説明します。セクション6.5では、PAA-EPパスの脅威について説明します。セクション6.6では、その他の脅威について説明します。
Some of the threats discussed in the following sections may be specific to shared links. The threat may be absent on non-shared links. Hence, it is only required to prevent the threat on shared links. Instead of specifying a separate set of requirements for shared links and non-shared links, this document specifies one set of requirements with the following wording: "PANA MUST be able to prevent threat X". This means that the PANA protocol should be capable of preventing threat X. The feature that prevents threat X may or may not be used depending on the deployment.
次のセクションで説明されている脅威のいくつかは、共有リンクに固有の場合があります。非共有リンクには脅威がない場合があります。したがって、共有リンクの脅威を防ぐためにのみ必要です。共有リンクと非共有リンクの個別の要件を指定する代わりに、このドキュメントは、次の言葉遣いで1つの要件を指定します。「パナは脅威Xを防ぐことができなければなりません」。これは、Panaプロトコルが脅威Xを防ぐことができる必要があることを意味します。脅威Xを防ぐ機能は、展開に応じて使用される場合と使用できない場合があります。
The PAA is discovered by sending solicitations or receiving advertisements. The following are possible threats.
PAAは、勧誘または広告を受け取ることによって発見されます。以下は考えられる脅威です。
T6.1.1: A malicious node can pretend to be a PAA by sending a spoofed advertisement.
T6.1.1：悪意のあるノードは、スプーフィングされた広告を送信することでPAAのふりをすることができます。
In existing dial-up networks, the clients authenticate to the network but generally do not verify the authenticity of the messages coming from Network Access Server (NAS). This mostly works because the link between the device and the NAS is not shared with other nodes (assuming that nobody tampers with the physical link), and clients trust the NAS and the phone network to provide the service. Spoofing attacks are not present in this environment, as the PaC may assume that the other end of the link is the PAA.
既存のダイヤルアップネットワークでは、クライアントはネットワークに認証しますが、通常、ネットワークアクセスサーバー（NAS）からのメッセージの信頼性を確認しません。これは、デバイスとNASの間のリンクが他のノードと共有されていないため（物理的なリンクを締めくく人はいないと仮定して）、クライアントがNASと電話ネットワークを信頼してサービスを提供するため、これは主に機能します。PACはリンクのもう一方の端がPAAであると仮定する可能性があるため、この環境にはスプーフィング攻撃は存在しません。
In environments where the link is shared, this threat is present, as any node can pretend to be a PAA. Even if the nodes are authenticated at layer 2, the threat remains present. It is difficult to protect the discovery process, as there is no a priori trust relationship between the PAA and PaC. In deployments where EP can police the packets that are sent among the PaCs, it is possible to filter out the unauthorized PANA packets (e.g., PAA advertisements sent by PaC) to prevent this threat.
リンクが共有される環境では、どのノードもPAAのふりをすることができるため、この脅威が存在します。ノードがレイヤー2で認証されている場合でも、脅威は存在しています。PAAとPACの間に先験的な信頼関係がないため、発見プロセスを保護することは困難です。EPがPACの間で送信されるパケットを警察できる展開では、この脅威を防ぐために、許可されていないパナパケット（PACが送信したPAA広告など）を除外することができます。
The advertisement may be used to include information (such as supported authentication methods) other than the discovery of the PAA itself. This can lead to a bidding down attack, as a malicious node can send a spoofed advertisement with capabilities that indicate authentication methods less secure than those that the real PAA supports, thereby fooling the PaC into negotiating an authentication method less secure than would otherwise be available.
広告は、PAA自体の発見以外の情報（サポートされている認証方法など）を含めるために使用される場合があります。悪意のあるノードは、実際のPAAがサポートしているものよりも安全性が低い認証方法を示す機能を備えたスプーフィングされた広告を送信する可能性があるため、これにより入札攻撃につながる可能性があります。。
Requirement 1
要件1
PANA MUST not assume that the discovery process is protected.
パナは、発見プロセスが保護されていると想定してはなりません。
This section discusses the threats specific to the authentication protocol. Section 6.2.1 discusses the possible threat associated with success/failure indications that are transmitted to PaC at the end of the authentication. Section 6.2.2 discusses the man-in-the-middle attack when compound methods are used. Section 6.2.3 discusses the replay attack, and Section 6.2.4 discusses the device identifier attack.
このセクションでは、認証プロトコルに固有の脅威について説明します。セクション6.2.1では、認証の終わりにPACに送信される成功/失敗の表示に関連する可能性のある脅威について説明します。セクション6.2.2は、複合方法が使用されている場合の中間攻撃について説明します。セクション6.2.3では、リプレイ攻撃について説明し、セクション6.2.4では、デバイス識別子攻撃について説明します。
Some authentication protocols (e.g., EAP) have a special message to indicate success or failure. An attacker can send a false authentication success or failure message to the PaC. By sending a false failure message, the attacker can prevent the client from accessing the network. By sending a false success message, the attacker can prematurely end the authentication exchange, effectively denying service for the PaC.
一部の認証プロトコル（EAPなど）には、成功または失敗を示す特別なメッセージがあります。攻撃者は、誤認証の成功または失敗メッセージをPACに送信できます。虚偽の障害メッセージを送信することにより、攻撃者はクライアントがネットワークにアクセスするのを防ぐことができます。誤った成功メッセージを送信することにより、攻撃者は認証交換を早期に終了し、PACのサービスを効果的に拒否できます。
If the link is not shared, then this threat is absent, as ingress filtering can prevent the attacker from impersonating the PAA.
リンクが共有されていない場合、攻撃者がPAAになりすましないようにすると、この脅威はありません。
If the link is shared, it is easy to spoof these packets. If layer 2 provides per-packet encryption with pair-wise keys, it might make it hard for the attacker to guess the success or failure packet that the client would accept. Even if the node is already authenticated at layer 2, it can still pretend to be a PAA and spoof the success or failure.
リンクが共有されている場合は、これらのパケットを簡単に呼び起こすことができます。レイヤー2がペアワイズキーを使用してパケットごとの暗号化を提供する場合、攻撃者がクライアントが受け入れる成功または失敗パケットを推測することを難しくする可能性があります。ノードが既にレイヤー2で認証されている場合でも、PAAのふりをして成功または失敗を促進することができます。
This attack is possible if the success or failure indication is not protected by using a security association between the PaC and the PAA. In order to avoid this attack, the PaC and PAA should mutually authenticate each other. In this process, they should be able to establish keys to protect the success or failure indications. It may not always be possible to protect the indication, as the keys may not be established prior to transmitting the success or failure packet. If the client is re-authenticating to the network, it can use the previously established security association to protect the success or failure indications. Similarly, all PANA messages exchanged during the authentication prior to key establishment may not be protected.
この攻撃は、PACとPAAのセキュリティ関連を使用して成功または失敗の兆候が保護されない場合に可能です。この攻撃を回避するために、PACとPAAは相互に認証する必要があります。このプロセスでは、成功または失敗の兆候を保護するための鍵を確立できるはずです。成功または失敗のパケットを送信する前にキーを確立しない可能性があるため、常に兆候を保護することができるとは限りません。クライアントがネットワークに再認識している場合、以前に確立されたセキュリティ協会を使用して、成功または失敗の兆候を保護できます。同様に、主要な施設の前に認証中に交換されるすべてのパナメッセージは保護されていない場合があります。
Requirement 2
要件2
PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST be able to establish keys between the PaC and PAA to protect the PANA messages.
パナは、PACとPAAを相互に認証できる必要があります。パナは、PANAメッセージを保護するために、PACとPAAの間にキーを確立できる必要があります。
A malicious node can claim to be the PAA to the real PaC and claim to be the PaC to the real PAA. This is a man-in-the-middle (MITM) attack, whereby the PaC is fooled to think that it is communicating with the real PAA and the PAA is fooled to think that it is communicating with the real PaC.
悪意のあるノードは、実際のPACのPAAであると主張し、実際のPAAのPACであると主張できます。これは、中間の（MITM）攻撃であり、PACは実際のPAAと通信していると考えるのがだまされ、PAAは実際のPACと通信していると考えることにだまされます。
If the link is not shared, this threat is absent, as ingress filtering can prevent the attacker from acting as a man-in-the-middle.
リンクが共有されていない場合、イングレスフィルタリングは攻撃者が中間の男として行動することを妨げる可能性があるため、この脅威はありません。
If the link is shared, this threat is present. Even if the layer 2 provides per-packet protection, the attacker can act as a man-in-the-middle and launch this attack. An instance of MITM attack, in which compound authentication methods are used is described in [TUN-EAP]. In these attacks, the server first authenticates to the client. As the client has not proven its identity yet, the server acts as the man-in-the-middle, tunneling the identity of the legitimate client to gain access to the network. The attack is possible because there is no verification that the same entities participated among the compound methods. It is not possible to do such verification if compound methods are used without being able to create a cryptographic binding among them. This implies that PANA will be vulnerable to such attacks if compound methods are used without being able to cryptographically bind them. Note that the attack does not exist if the keys derived during the tunnel establishment are not used to authenticate the client (e.g., tunnel keys are used for just protecting the identity of the client).
リンクが共有されている場合、この脅威が存在します。レイヤー2がパケットごとの保護を提供したとしても、攻撃者は中間の男として行動し、この攻撃を開始できます。複合認証方法が使用されるMITM攻撃のインスタンスは、[Tun-EAP]で説明されています。これらの攻撃では、サーバーは最初にクライアントに認証されます。クライアントはまだそのアイデンティティを証明していないため、サーバーはミドルの男として動作し、正当なクライアントのIDをトンネルしてネットワークにアクセスできます。同じエンティティが複合法に参加したという検証がないため、攻撃が可能です。複合方法が暗号化結合を作成できずに使用される場合、そのような検証を行うことはできません。これは、暗号化できるように結合することができずに複合方法が使用された場合、パナはそのような攻撃に対して脆弱であることを意味します。トンネル設立中に導出されたキーがクライアントの認証に使用されない場合、攻撃は存在しないことに注意してください（たとえば、クライアントの身元を保護するためにトンネルキーが使用されます）。
Requirement 3
要件3
When compound authentication methods are used in PANA, the methods MUST be cryptographically bound.
パナで複合認証方法が使用される場合、メソッドは暗号化されたバインドされている必要があります。
A malicious node can replay the messages that caused authentication failure or success at a later time to create false failures or success. The attacker can also potentially replay other messages of the PANA protocol to deny service to the PaC.
悪意のあるノードは、誤った障害または成功を生み出すために、後で認証の失敗または成功を引き起こしたメッセージを再生できます。攻撃者は、PACへのサービスを拒否するために、パナプロトコルの他のメッセージを再生する可能性があります。
If the link is not shared, this threat is absent, as ingress filtering can prevent the attacker from impersonating the PAA to replay the packets.
リンクが共有されていない場合、イングレスフィルタリングにより攻撃者がPAAになりすましてパケットを再生することができないため、この脅威はありません。
If the link is shared, this threat is present. If the packets are encrypted at layer 2 by using pair-wise keys, it will make it hard for the attacker to learn the unencrypted (i.e., original) packet that needs to be replayed. Even if layer 2 provides replay protection, the attacker can still replay the PANA messages (layer 3) for denying service to the client.
リンクが共有されている場合、この脅威が存在します。パケットがペアワイズキーを使用してレイヤー2で暗号化されている場合、攻撃者が再生する必要がある暗号化されていない（つまり、元の）パケットを学習することが難しくなります。レイヤー2がリプレイ保護を提供している場合でも、攻撃者はクライアントへのサービスを拒否するためにパナメッセージ（レイヤー3）を再生できます。
Requirement 4
要件4
PANA MUST be able to protect itself against replay attacks.
パナは、リプレイ攻撃から身を守ることができなければなりません。
When the client is successfully authenticated, the PAA sends access control information to the EP for granting access to the network. The access control information typically contains the device identifier of the PaC, which is either obtained from the IP headers and MAC headers of the packets exchanged during the authentication process or carried explicitly in the PANA protocol field. The attacker can gain unauthorized access into the network by taking the following steps.
クライアントが正常に認証されると、PAAはネットワークへのアクセスを付与するためにアクセス制御情報をEPに送信します。アクセス制御情報には通常、PACのデバイス識別子が含まれます。これは、認証プロセス中に交換されたパケットのIPヘッダーとMACヘッダーから取得されるか、PANAプロトコルフィールドで明示的に運ばれます。攻撃者は、次の手順を実行することにより、ネットワークへの不正アクセスを取得できます。
o An attacker pretends to be a PAA and sends advertisements. The PaC is fooled and starts exchanging packets with the attacker.
o 攻撃者はPAAのふりをして広告を送信します。PACはだまされ、攻撃者とパケットを交換し始めます。
o The attacker modifies the IP source address on the packet, adjusts the UDP/TCP checksum, and forwards the packet to the real PAA. It also does the same on return packets.
o 攻撃者は、パケットのIPソースアドレスを変更し、UDP/TCPチェックサムを調整し、パケットを実際のPAAに転送します。また、返品パケットでも同じことができます。
o When the real PaC is successfully authenticated, the attacker gains access to the network, as the packets contained the IP address (and potentially the MAC address also) of the attacker.
o 実際のPACが正常に認証されると、攻撃者は攻撃者のIPアドレス（および潜在的にMACアドレスも）を含んでいたため、攻撃者がネットワークへのアクセスを獲得します。
If the link is not shared, this threat is absent, as the attacker cannot impersonate the PAA and intercept the packets from the PaC.
リンクが共有されていない場合、攻撃者はPAAになりすましてPACからパケットを傍受することができないため、この脅威はありません。
If the link is shared, this threat is present. If the layer 2 provides per-packet protection, it is not possible to change the MAC address, and hence this threat may be absent in such cases if EP filters on both the IP and MAC address.
リンクが共有されている場合、この脅威が存在します。レイヤー2がパケットごとの保護を提供する場合、MACアドレスを変更することはできません。したがって、この場合、IPアドレスとMACアドレスの両方にEPフィルターを使用する場合、この脅威は存在しない可能性があります。
Requirement 5
要件5
PANA MUST be able to protect the device identifier against spoofing when it is exchanged between the PaC and PAA.
PANAは、PACとPAAの間で交換される場合、デバイス識別子をスプーフィングから保護できる必要があります。
When the PaC leaves the network, it can inform the PAA before disconnecting from the network so that the resources used by PaC can be accounted properly. The PAA may also choose to revoke the access anytime it deems necessary. The following are possible threats:
PACがネットワークを離れると、PACが使用するリソースを適切に考慮できるように、ネットワークから切断する前にPAAに通知できます。PAAは、必要と思われるアクセスを取り消すこともできます。以下は考えられる脅威です。
T6.3.1: A malicious node can pretend to be a PAA and revoke the access to PaC.
T6.3.1：悪意のあるノードは、PAAのふりをしてPACへのアクセスを取り消すことができます。
T6.3.2: A malicious node can pretend to be a real PaC and transmit a disconnect message.
T6.3.2：悪意のあるノードは、実際のPACのふりをして、切断メッセージを送信できます。
T6.3.3: The PaC can leave the network without notifying the PAA or EP (e.g., the Ethernet cable is unplugged, system crash). An attacker can pretend to be the PaC and start using the network.
T6.3.3：PACは、PAAまたはEPに通知せずにネットワークを離れることができます（たとえば、イーサネットケーブルはプラグが解除され、システムがクラッシュします）。攻撃者はPACのふりをして、ネットワークの使用を開始できます。
If the link is not shared, threats T6.3.1 and T6.3.2 are absent. Threat T6.3.3 may still be present. If there is no layer 2 indication, or if the layer 2 indication cannot be relied upon, then threat T6.3.3 is still present on non-shared links.
リンクが共有されていない場合、T6.3.1およびT6.3.2の脅威は存在しません。脅威T6.3.3はまだ存在する可能性があります。レイヤー2の表示がない場合、またはレイヤー2の適応症が依存できない場合、脅威T6.3.3は非共有リンクにまだ存在します。
If the link is shared, all of the above threats are present, as any node on the link can spoof the disconnect message. Even if layer 2 has per-packet authentication, the attacker can pretend to be a PaC (e.g., by spoofing the IP address) and disconnect from the network. Similarly, any node can pretend to be a PAA and revoke the access to the PaC. Therefore, T6.3.1 and T6.3.2 are possible even on links where layer 2 is secured. Threat T6.3.3 can be prevented if layer 2 provides per-packet authentication. The attacker cannot subsume the PaC that left the network without knowing the keys that protect the packet at layer 2.
リンクが共有されている場合、上記の脅威はすべて存在します。リンク上のノードは、切断メッセージを押し付ける可能性があるためです。レイヤー2にパケットごとの認証がある場合でも、攻撃者はPAC（たとえば、IPアドレスをスプーフィングすることにより）のふりをしてネットワークから切断することができます。同様に、どのノードもPAAのふりをして、PACへのアクセスを取り消すことができます。したがって、レイヤー2が固定されているリンクでも、T6.3.1およびT6.3.2が可能です。レイヤー2がパケットごとの認証を提供する場合、脅威T6.3.3を防ぐことができます。攻撃者は、レイヤー2のパケットを保護するキーを知らずに、ネットワークを離れたPACを覆うことはできません。
Requirement 6
要件6
PANA MUST be able to protect disconnect and revocation messages. PANA MUST NOT depend on the PaC sending a disconnect message.
パナは、切断および取り消しメッセージを保護できる必要があります。パナは、切断メッセージを送信するPACに依存してはなりません。
An attacker can gain unauthorized access into the network by stealing the service from another client. Once the real PaC is successfully authenticated, the EP will have filters in place to prevent unauthorized access into the network. The filters will be based on something that will be carried on every packet. For example, the filter could be based on the IP and MAC addresses, where the packets will be dropped unless the packets coming with certain IP addresses also match the MAC addresses. The following are possible threats:
攻撃者は、別のクライアントからサービスを盗むことにより、ネットワークへの不正アクセスを取得できます。実際のPACが正常に認証されると、EPはネットワークへの不正アクセスを防ぐためにフィルターを導入します。フィルターは、すべてのパケットに掲載されるものに基づいています。たとえば、フィルターはIPアドレスとMACアドレスに基づいている可能性があります。特定のIPアドレスに搭載されているパケットがMACアドレスと一致しない限り、パケットがドロップされます。以下は考えられる脅威です。
T6.4.1: An attacker can spoof both the IP and MAC addresses of an authorized client to gain unauthorized access. The attacker can launch this attack easily by just sniffing the wire for IP and MAC addresses. This lets the attacker use the network without any authorization, getting a free service.
T6.4.1：攻撃者は、許可されたクライアントのIPアドレスとMACアドレスの両方に、不正アクセスを得ることができます。攻撃者は、IPおよびMACアドレスのワイヤーを嗅ぐだけで、この攻撃を簡単に起動できます。これにより、攻撃者は許可なしにネットワークを使用し、無料サービスを取得できます。
T6.4.2: The PaC can leave the network without notifying the PAA or EP (e.g., the Ethernet cable is unplugged, system crash). An attacker can pretend to be the PaC and start using the network.
T6.4.2：PACは、PAAまたはEPに通知せずにネットワークを離れることができます（たとえば、イーサネットケーブルがプラグが解除され、システムクラッシュがありません）。攻撃者はPACのふりをして、ネットワークの使用を開始できます。
Service theft allows the possibility of exploiting the weakness in other authentication protocols that use IP address for authentication. It also allows the interception of traffic destined for other nodes by spoofing the IP address.
サービスの盗難により、認証にIPアドレスを使用する他の認証プロトコルの弱点を活用する可能性があります。また、IPアドレスをスプーフィングすることにより、他のノードに向けられたトラフィックの傍受が可能になります。
If the link is not shared, T6.4.1 is absent, as there is only one client on the link, and ingress filtering can prevent the use of the authorized IP and MAC addresses by the attacker on another link. Threat T6.4.2 exists, as the attacker can use the IP or MAC address of the real PaC to gain access to the network.
リンクが共有されていない場合、T6.4.1はリンクに1つのクライアントしかないため、攻撃者による承認されたIPおよびMACアドレスの使用を防ぐことができます。攻撃者は実際のPACのIPまたはMACアドレスを使用してネットワークにアクセスできるため、脅威T6.4.2が存在します。
If the link is shared, both the threats are present. If layer 2 provides per-packet protection using pair-wise keys, both the threats can be prevented.
リンクが共有されている場合、両方の脅威が存在します。レイヤー2がペアワイズキーを使用してパケットごとに保護を提供する場合、両方の脅威を防ぐことができます。
Requirement 7
要件7
PANA MUST securely bind the authenticated session to the device identifier of the client, to prevent service theft. PANA MUST be able to bootstrap a shared secret between the PaC and PAA that can be further used to set up a security association between the PaC and EP to provide cryptographic protection against service theft.
パナは、サービスの盗難を防ぐために、認証されたセッションをクライアントのデバイス識別子にしっかりと結合する必要があります。Panaは、PACとPAAの間の共有秘密をブートストラップできる必要があります。PAAとPAAをさらに使用して、PACとEPの間にセキュリティアソシエーションを設定して、サービス盗難に対する暗号化保護を提供することができます。
After a successful authentication, the PAA needs to communicate the access control information of the PaC to the EP so that the PaC will be allowed to access the network. The information communicated would contain at least the device identifier of the PaC. If strong security is needed, the PAA will communicate a shared secret known only to the PaC and PAA, for setting up a security association between the PaC and EP. The following are possible threats:
認証が成功した後、PAAはPACのアクセス制御情報をEPに通信して、PACがネットワークにアクセスできるようにする必要があります。通信された情報には、少なくともPACのデバイス識別子が含まれます。強力なセキュリティが必要な場合、PAAは、PACとEPの間にセキュリティ協会を設定するために、PACとPAAにのみ知られている共有秘密を伝えます。以下は考えられる脅威です。
T6.5.1: An attacker can eavesdrop to learn the information communicated between the PAA and EP. The attacker can further use this information to spoof the real PaC and also to set up security association for gaining access to the network. This threat is absent if the attacker cannot eavesdrop on the link; e.g., the PAA and EP communicate on a link separate from that of visiting PaCs.
T6.5.1：攻撃者は、PAAとEPの間で伝えられた情報を学習するために盗聴できます。攻撃者は、この情報をさらに使用して、実際のPACを広げ、ネットワークへのアクセスを得るためにセキュリティ協会を設定することもできます。攻撃者がリンクを盗聴できない場合、この脅威はありません。たとえば、PAAとEPは、訪問PACのリンクとは別のリンクで通信します。
T6.5.2: An attacker can pretend to be a PAA and send false information to an EP to gain access to the network. In the case of stronger security, the attacker has to send its own device identifier and also a shared secret, so that the EP will let the attacker access the network.
T6.5.2：攻撃者は、PAAのふりをして、誤った情報をEPに送信してネットワークにアクセスできます。より強力なセキュリティの場合、攻撃者は独自のデバイス識別子と共有秘密を送信する必要があり、EPが攻撃者にネットワークにアクセスできるようにします。
If the communication between the PAA and EP is protected, these threats are absent.
PAAとEPの間の通信が保護されている場合、これらの脅威は存在しません。
Requirement 8
要件8
The communication between the PAA and EP MUST be protected against eavesdropping and spoofing attacks.
PAAとEPの間のコミュニケーションは、盗聴およびスプーフィング攻撃から保護されなければなりません。
T6.6.1: There are various forms of DoS attacks that can be launched on the PAA or AS. A few are mentioned below. As it is hard to defend against some of the DoS attacks, the protocol should be designed carefully to mitigate or prevent such attacks.
T6.6.1：PAAまたはASで起動できるDOS攻撃にはさまざまな形式があります。以下にいくつか説明します。一部のDOS攻撃から防御することは困難であるため、そのような攻撃を緩和または防止するために、プロトコルを慎重に設計する必要があります。
o An attacker can bombard the PAA with lots of authentication requests. If the PAA and AS are not co-located, the PAA may have to allocate resources to store some state about the PaC locally before it receives the response from the back-end AS. This can deplete memory resources on the PAA.
o 攻撃者は、多くの認証リクエストでPAAを攻撃することができます。PAAおよびASが共同住宅されていない場合、PAAは、バックエンドのASから応答を受信する前に、PACに関する状態を局所的に保存するためにリソースを割り当てる必要がある場合があります。これにより、PAAのメモリリソースが枯渇する可能性があります。
o With minimal effort, an attacker can force the PAA or AS to make computationally intensive operations with minimal effort, that can deplete the CPU resources of the PAA or AS.
o 最小限の労力で、攻撃者はPAAを強制したり、PAAまたはASのCPUリソースを枯渇させる可能性のある最小限の労力で計算集中的な操作を行うことができます。
T6.6.2: PaC acquires an IP address by using stateful or stateless mechanisms before PANA authentication begins [PANAREQ]. When the IP addresses are assigned before the client authentication, it opens up the possibility of DoS attacks in which unauthenticated malicious nodes can deplete the IP address space by acquiring multiple IP addresses or deny allocation to others by responding to every duplicate address detection (DAD) query.
T6.6.2：PACは、PANA認証が開始される前に、ステートフルまたはステートレスメカニズムを使用してIPアドレスを取得します[Panareq]。IPアドレスがクライアント認証の前に割り当てられると、複数のIPアドレスを取得することにより、認知度のない悪意のあるノードがIPアドレススペースを枯渇させるか、すべてのアドレス検出（DAD）に応答することで他の人への割り当てを拒否することにより、DOS攻撃の可能性が開きます。クエリ。
Depleting a /64 IPv6 link-local address space or a /8 RFC1918 private address space requires a brute-force attack. Such an attack is part of a DoS class that can equally target the link capacity or the CPU cycles on the target system by bombarding arbitrary packets. Therefore, solely handling the IP address depletion attack is not going to improve the security, as a more general solution is needed to tackle the whole class of brute-force attacks.
A /64 IPv6リンクローカルアドレススペースまたはA /8 RFC1918プライベートアドレススペースの枯渇には、ブルートフォース攻撃が必要です。このような攻撃は、任意のパケットを砲撃することにより、ターゲットシステムのリンク容量またはCPUサイクルを等しくターゲットにできるDOSクラスの一部です。したがって、Brute-Force攻撃のクラス全体に取り組むにはより一般的なソリューションが必要であるため、IPアドレスの枯渇攻撃のみを処理することはセキュリティを改善するものではありません。
The DAD attack can be prevented by deploying secure address resolution that does not depend on the client authentication, such as [SEND]. The attack may also be prevented if the EP is placed between the PaCs to monitor the ND/ARP activity and to detect DAD attacks (excessive NA/ARP replies). If none of these solutions are applicable to a deployment, the PaCs can send arbitrary packets to each other without going through the EP, which enables a class of attacks that are based on interfering with the PANA messaging (See T6.1.1). Since there will always be a threat in this class (e.g., insecure discovery), it is not going to improve the overall security by addressing DAD.
お父さんの攻撃は、[送信]などのクライアント認証に依存しない安全なアドレス解決を展開することにより、防止できます。EPがPACの間に配置されてND/ARPアクティビティを監視し、DAD攻撃を検出する場合、攻撃は防止される場合があります（過剰なNA/ARP応答）。これらのソリューションが展開に適用できない場合、PACSはEPを通過せずに任意のパケットを相互に送信できます。これにより、パナメッセージングの干渉に基づいた攻撃のクラスが可能になります（T6.1.1を参照）。このクラスでは常に脅威があるので（例：不安定な発見など）、お父さんに対処することによって全体的なセキュリティを改善することはありません。
1. PANA MUST not assume that the discovery process is protected.
1. パナは、発見プロセスが保護されていると想定してはなりません。
2. PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST be able to establish keys between the PaC and PAA to protect the PANA messages.
2. パナは、PACとPAAを相互に認証できる必要があります。パナは、PANAメッセージを保護するために、PACとPAAの間にキーを確立できる必要があります。
3. When compound authentication methods are used in PANA, the methods MUST be cryptographically bound.
3. パナで複合認証方法が使用される場合、メソッドは暗号化されたバインドされている必要があります。
4. PANA MUST be able to protect itself against replay attacks.
4. パナは、リプレイ攻撃から身を守ることができなければなりません。
5. PANA MUST be able to protect the device identifier against spoofing when it is exchanged between the PaC and PAA.
5. PANAは、PACとPAAの間で交換される場合、デバイス識別子をスプーフィングから保護できる必要があります。
6. PANA MUST be able to protect disconnect and revocation messages. PANA MUST NOT depend on whether the PaC sends a disconnect message.
6. パナは、切断および取り消しメッセージを保護できる必要があります。パナは、PACが切断メッセージを送信するかどうかに依存してはなりません。
7. PANA MUST securely bind the authenticated session to the device identifier of the client, to prevent service theft. PANA MUST be able to bootstrap a shared secret between the PaC and PAA that can be further used to set up a security association between the PaC and EP to provide cryptographic protection against service theft.
7. パナは、サービスの盗難を防ぐために、認証されたセッションをクライアントのデバイス識別子にしっかりと結合する必要があります。Panaは、PACとPAAの間の共有秘密をブートストラップできる必要があります。PAAとPAAをさらに使用して、PACとEPの間にセキュリティアソシエーションを設定して、サービス盗難に対する暗号化保護を提供することができます。
8. The communication between the PAA and EP MUST be protected against eavesdropping and spoofing attacks.
8. PAAとEPの間のコミュニケーションは、盗聴およびスプーフィング攻撃から保護されなければなりません。
This document discusses various threats with IP based network access authentication protocol. Though this document discusses the threats for shared and unshared links separately, it may be difficult to make such a distinction in practice (e.g., a dial-up link may be a point-to-point IP tunnel). Hence, the link should be assumed to be a shared link for most of the threats in this document.
このドキュメントでは、IPベースのネットワークアクセス認証プロトコルを使用したさまざまな脅威について説明します。このドキュメントでは、共有リンクと非共有リンクの脅威について個別に説明していますが、実際にこのような区別をすることは困難かもしれません（たとえば、ダイヤルアップリンクはポイントツーポイントIPトンネルである可能性があります）。したがって、このドキュメントのほとんどの脅威のリンクは共有リンクであると想定する必要があります。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[PANAREQ] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology", Work in Progress, August 2004.
[Panareq] Yegin、A.、ed。、Ohba、Y.、Penno、R.、Tsirtsis、G。、およびC. Wang、「ネットワークアクセス（PANA）要件と用語のための認証を運ぶためのプロトコル」、進行中の作業、2004年8月。
[EAP-KEY] Aboba, B., et al., "EAP keying framework", Work in Progress.
[Eap-Key] Aboba、B.、et al。、「Eap Keying Framework」、進行中の作業。
[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[rad-eap] Aboba、B。and P. Calhoun、「Radius（リモート認証ダイヤルユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[TUN-EAP] Puthenkulam, J., et al., "The compound authentication binding problem", Work in Progress.
[Tun-eap] Puthenkulam、J.、et al。、「化合物認証結合問題」、進行中の作業。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[送信] Arkko、J.、ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
The author would like to thank the following people (in no specific order) for providing valuable comments: Alper Yegin, Basavaraj Patil, Pekka Nikander, Bernard Aboba, Francis Dupont, Michael Thomas, Yoshihiro Ohba, Gabriel Montenegro, Tschofenig Hannes, Bill Sommerfeld, N. Asokan, Pete McCan, Derek Atkins, and Thomas Narten.
著者は、Alper Yegin、Basavaraj Patil、Pekka Nikander、Bernard Aboba、Francis Dupont、Michael Thomas、Yoshihiro Ohba、Gabriel Montenegro、Tschofenig Hannes、Bill Sommerfeld、Bill Somerfeld、Bill Sommerfeld;N. Asokan、Pete McCan、Derek Atkins、Thomas Narten。
Author's Address
著者の連絡先
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA-94303
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View、CA-94303
EMail: mohanp@sbcglobal.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。