[要約] RFC 6345は、PANAリレーエレメントのための認証を伝送するためのプロトコルに関するものであり、PANAセッションの認証情報をリレーエレメント間で伝送するための仕様を提供しています。目的は、ネットワークアクセスの認証を効率的かつ安全に行うための方法を提供することです。
Internet Engineering Task Force (IETF) P. Duffy
Request for Comments: 6345 Cisco
Category: Standards Track S. Chakrabarti
ISSN: 2070-1721 Ericsson
R. Cragie
PG&E
Y. Ohba, Ed.
Toshiba
A. Yegin
Samsung
August 2011
Protocol for Carrying Authentication for Network Access (PANA) Relay Element
ネットワークアクセス（PANA）リレー要素のための認証を運ぶためのプロトコル
Abstract
概要
This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing.
このドキュメントは、ネットワークアクセス（PANA）リレー要素機能の認証を運ぶためのプロトコルを指定します。これにより、PANAクライアント（PAC）と2つのノードが通常のIPルーティングによって互いに到達できないPANA認証エージェント（PAA）の間のパナメッセージングが可能になります。。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6345.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6345で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. PANA Relay Element ..............................................3
3. Security of Messages Sent between PRE and PAA ...................5
4. PANA Messages for Relay Operation ...............................7
4.1. PANA-Relay .................................................7
5. PANA AVPs for Relay Operation ...................................7
5.1. PaC-Information AVP ........................................7
5.2. Relayed-Message AVP ........................................7
6. Security Considerations .........................................8
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
Protocol for carrying Authentication for Network Access (PANA) [RFC5191] is a UDP-based protocol to perform Extensible Authentication Protocol (EAP) authentication between a PANA Client (PaC) and a PANA Authentication Agent (PAA).
ネットワークアクセスの認証を運ぶためのプロトコル（PANA）[RFC5191]は、PANAクライアント（PAC）とPANA認証エージェント（PAA）の間で拡張可能な認証プロトコル（EAP）認証を実行するUDPベースのプロトコルです。
This document specifies PANA Relay Element (PRE) functionality, which enables PANA messaging between a PaC and a PAA where the two nodes cannot reach each other by means of regular IP routing. For example, in ZigBee IP [ZIGBEEIP] that uses 6LoWPAN [RFC4944], a joining node (PaC) can only use a link-local IPv6 address to communicate with a parent node prior to PANA authentication. The PAA typically resides in a 6LowPAN Border Router (6LBR) [6LoWPAN-ND], which is often
このドキュメントは、PANAリレー要素（PRE）機能を指定します。これにより、PACとPAAの間のパナメッセージングが、通常のIPルーティングによって2つのノードが互いに到達できないPAAを可能にします。たとえば、6Lowpan [RFC4944]を使用するZigbee IP [ZigbeeIP]では、結合ノード（PAC）は、Link-Local IPv6アドレスを使用して、パナ認証の前に親ノードと通信できます。PAAは通常、6lowpan Border Router（6LBR）[6lowpan-nd]に存在します。
multiple IP hops away from the PaC. The PRE implemented on the parent node is used for relaying PANA messages between the PaC and the PAA in this scenario.
PACから離れた複数のIPホップ。親ノードに実装された事前に実装されているのは、このシナリオでPACとPAAの間でパナメッセージを中継するために使用されます。
In this document, several words are used to signify the requirements of the specification. These words are capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉は大文字です。「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
A PANA Relay Element (PRE) is a node that is located between a PaC and a PAA. It is responsible for relaying the PANA messages between the PaC and the PAA. The PRE does not need to maintain per-PaC state. From the PaC's perspective, the PRE appears as the PAA. Normal IP routing is performed between the PRE and the PAA. A PAA can communicate with multiple PREs. A PRE can communicate with multiple PAAs, and it will choose one PAA to communicate with for a given PaC. By default, the PaC discovers the PRE using the normal mechanism for PAA discovery as defined in [RFC5192]. PREs are assumed to be configured with the IP address(es) of the PAA(s). Dynamic PAA discovery schemes for PREs are outside the scope of this document.
Pana Relay Element（Pre）は、PACとPAAの間にあるノードです。PACとPAAの間でパナメッセージを中継する責任があります。PREはPACあたりの状態を維持する必要はありません。PACの観点から見ると、PREはPAAとして表示されます。通常のIPルーティングは、PREとPAAの間で実行されます。PAAは複数のPresと通信できます。事前は複数のPAAと通信でき、特定のPACと通信するPAAを1つ選択します。デフォルトでは、PACは[RFC5192]で定義されているPAA発見の通常のメカニズムを使用して事前を発見します。PRESは、PAA（s）のIPアドレス（es）で構成されていると想定されています。Presの動的PAA発見スキームは、このドキュメントの範囲外です。
The PRE and the PAA support the relay operation as follows.
プレとPAAは、次のようにリレー操作をサポートします。
When the PRE receives a PANA message from the PaC, it creates a PANA-Relay (PRY) message (see Section 4.1) containing a Relayed-Message AVP (see Section 5.2) and a PaC-Information AVP (see Section 5.1). The Relayed-Message AVP encapsulates the entire PANA Message received from the PaC. The PaC-Information AVP contains the PaC's IP address and UDP port number used for sending the PANA messages. The PRY message is sent to the PAA.
PACからPANAメッセージを受信すると、リレーされたメッセージAVP（セクション5.2を参照）とPAC情報AVP（セクション5.1を参照）を含むパナレレー（PRY）メッセージ（セクション4.1を参照）を作成します。リレーされたメッサージAVPは、PACから受信したパナメッセージ全体をカプセル化します。PAC-Information AVPには、PACのIPアドレスとPANAメッセージの送信に使用されるUDPポート番号が含まれています。PRYメッセージはPAAに送信されます。
When the PAA receives the PRY message, it retrieves the PaC-originated PANA message from the Relayed-Message AVP and the PaC's IP address and UDP port number from the PaC-Information AVP. The PaC-originated PANA message is processed in the same way as specified in [RFC5191], with the following exceptions:
PAAがPRYメッセージを受信すると、リレーメッサージAVPからのPAC誘発パナメッセージとPAC情報AVPからUDPポート番号を取得します。PAC造影パナメッセージは、[RFC5191]で指定されたものと同じ方法で処理されます。以下の例外を除きます。
(a) The IP address and the port number contained in the PaC-Information AVP and the source IP address and UDP port number of the PRE are used to identify the PaC among multiple PANA-Client-Initiation messages sent from different PaCs through the same PRE
(a) PAC情報AVPとソースIPアドレスとPREのUDPポート番号に含まれるIPアドレスとポート番号を使用して、異なるPACから送信された複数のPANAクライアント開始メッセージ間でPACを識別するために使用されます。
or sent from more than one PaC with the same the IP address and the port number through different PREs.
または、IPアドレスと異なるPresを使用して、同じThe IPアドレスとポート番号で複数のPACから送信されます。
(b) The IP address and the port number contained in the PaC-Information AVP are maintained by the PAA in the PANA session attribute "IP address and UDP port number of the PaC" [RFC5191].
(b) PAC情報AVPに含まれるIPアドレスとポート番号は、PANAセッション属性「IPアドレスとUDPポート番号のPAC」[RFC5191]のPAAによって維持されます。
(c) The IP address and UDP port number of the PRE are maintained by the PAA in a new PANA session attribute "IP address and UDP port number of the PRE". A PANA session is referred to as a relayed PANA session if this attribute has a non-null value.
(c) PREのIPアドレスとUDPポート番号は、PAAによって新しいPANAセッション属性「IPアドレスとUDPポート番号のPRE」で維持されます。この属性に非ヌル値がある場合、パナセッションはリレーされたパナセッションと呼ばれます。
When the PAA originates a PANA message for a relayed PANA session, it sends a PRY message to the PRE's IP address and sets the destination UDP port number to the UDP port number of the PRE maintained in the PANA session attribute "IP address and UDP port number of the PRE". The PRY message includes a Relayed-Message AVP containing the PAA-originated PANA message and also includes a PaC-Information AVP containing the PaC's IP address and UDP port number.
PAAが中継されたパナセッションのパナメッセージを発信する場合、PRYのIPアドレスにPRYメッセージを送信し、宛先UDPポート番号をPANAセッション属性属性 "IPアドレスとUDPポートにメンテナンスしたUDPポート番号に設定しますpreの数」。PRYメッセージには、PAAに導入されたPanaメッセージを含むリレー型メッセージAVPが含まれており、PACのIPアドレスとUDPポート番号を含むPAC情報AVPも含まれています。
When the PRE receives the PRY message, it retrieves the PAA-originated PANA message from the Relayed-Message AVP and the PaC's IP address and UDP port number from and PaC-Information AVPs. The PAA-originated PANA message is sent to the PaC's IP address with the source UDP port number set to the PANA port number (716) and the destination UDP port number set to the UDP port number contained in the Relayed-Message AVP.
PRYがPRYメッセージを受信すると、リレーメッサージAVPおよびPACのIPアドレスとUDPポート番号とPAC情報AVPからPAA誘発パナメッセージを取得します。PAAによって発生したパナメッセージは、PANAポート番号（716）に設定されたソースUDPポート番号と、リレーメッソーAVPに含まれるUDPポート番号に設定された宛先UDPポート番号に設定されたPACのIPアドレスに送信されます。
The Session Identifier and Sequence Number of any PRY message are set to zero. PRY messages are never retransmitted by the PRE or the PAA. Note that the PANA message carried in a Relayed-Message AVP may be retransmitted by the PaC or PAA, leading to transmission of a new PRY message carrying the same Relayed-Message AVP.
PRYメッセージのセッション識別子とシーケンス番号はゼロに設定されています。PRYメッセージは、PREまたはPAAによって再送信されることはありません。リレーされたメッセージAVPで運ばれたパナメッセージは、PACまたはPAAによって再送信され、同じリレーメッセージAVPを運ぶ新しいPRYメッセージの送信につながる可能性があることに注意してください。
A PAA that supports this specification MUST be able to process PRY messages for PaC-initiated PANA sessions.
この仕様をサポートするPAAは、PAC開始パナセッションのPRYメッセージを処理できる必要があります。
This specification assumes there is at most one PRE between the PaC and the PAA. Performing relay operation on a PANA message that is already relayed (i.e., carried inside a PRY message) is out of scope of this specification.
この仕様では、PACとPAAの間にせいぜい1つのプレがあると仮定しています。既にリレーされているパナメッセージでリレー操作を実行する（つまり、こじ開けメッセージ内に持ち込まれている）は、この仕様の範囲外です。
Figure 1 is an example message flow with a PRE.
図1は、PREのメッセージフローの例です。
PaC PRE PAA srcIP:port->dstIP:port
----- ----- ----- ----------------------
1. ---PCI--> IP1:p1 -> IP2a:716
IP1 is the IP address of PaC.
IP1はPACのIPアドレスです。
IP2a and IP2b are the IP addresses of PRE. IP2a is used for communicating with PaC. IP2b is used for communicating with PAA. The two IP address may be the same.
IP2AとIP2Bは、PREのIPアドレスです。IP2Aは、PACとの通信に使用されます。IP2Bは、PAAとの通信に使用されます。2つのIPアドレスは同じかもしれません。
IP3 is the IP address of PAA.
IP3はPAAのIPアドレスです。
p1 is PaC-assigned UDP port number. p2 is PRE-assigned UDP port number.
P1はPAC割り当てられたUDPポート番号です。P2は、事前に割り当てられたUDPポート番号です。
P: PaC-Information AVP R: Relayed-Message AVP
P：PAC情報AVP R：リレーとメッセージAVP
Figure 1: Example Call Message for PANA Relay
図1：パナリレーの呼び出しメッセージの例
PRE/PAA security is OPTIONAL since PANA messages are designed to be used in untrusted networks, but if a cryptographic mechanism is supported, it SHOULD be IPsec. When the device characteristics preclude support for IPsec, an alternative mechanism such as DTLS [RFC4347], or link-layer cryptographic security, etc., may be used instead. This section describes how IPsec [RFC4301] can be used for securing the PANA relay messages.
PANAメッセージは信頼されていないネットワークで使用されるように設計されているため、PRE/PAAセキュリティはオプションですが、暗号化メカニズムがサポートされている場合は、IPSECである必要があります。デバイスの特性がIPSECのサポートを排除する場合、DTLS [RFC4347]、リンク層暗号セキュリティなどの代替メカニズムを代わりに使用できます。このセクションでは、IPSEC [RFC4301]をパナリレーメッセージの固定に使用する方法について説明します。
When IPsec is used, each PRE must have an established pairwise trust relationship with a PAA. That is, if messages from a PaC will be relayed by a PRE to a PAA, the PRE and PAA must be configured to use IPsec for the messages they exchange.
IPSECを使用する場合、各プレはPAAとの確立されたペアワイズトラスト関係を持つ必要があります。つまり、PACからのメッセージがPAAの事前で中継される場合、PARとPAAは、交換するメッセージにIPSECを使用するように構成する必要があります。
PREs and PAAs that support secure PRE to PAA communication use IPsec under the following conditions:
PAA通信の安全な事前をサポートするPRESとPAASは、次の条件下でIPSECを使用します。
Selectors PREs are manually configured with the addresses of the PAAs to which PANA messages are to be forwarded. PAAs that will be using IPsec for securing PANA messages must also be configured with a list of the PREs to which messages will be returned. The selectors for the PREs and PAAs will be the pairs of addresses defining PREs and PAAs that exchange PANA messages on the PANA UDP port 716 in their source or destination port.
セレクターPresは、パナメッセージを転送するPAASのアドレスで手動で構成されています。IPSECを使用してPANAメッセージを保護するPAASは、メッセージが返されるPRESのリストとともに構成する必要があります。PresとPaasのセレクターは、ソースまたは宛先ポートのPana UDPポート716でパナメッセージを交換するPresとPaasを定義するアドレスのペアとなります。
Mode PREs and PAAs use transport mode and ESP. The information in PANA messages is not generally considered confidential, so encryption need not be used (i.e., NULL encryption can be used).
モードPRESとPAASは、トランスポートモードとESPを使用します。パナメッセージの情報は一般に機密とは見なされないため、暗号化を使用する必要はありません（つまり、ヌル暗号化を使用できます）。
Key management Because the PREs and PAA must be manually configured, manually configured key management may suffice, but does not provide defense against replayed messages. Accordingly, IKE with preshared secrets SHOULD be supported. IKE with public keys MAY be supported.
キー管理PresとPAAは手動で構成する必要があるため、手動で構成されたキー管理で十分かもしれませんが、再生されたメッセージに対する防御は提供されません。したがって、Presharedの秘密を持つIkeがサポートされるべきです。パブリックキーを備えたIKEがサポートされる場合があります。
Security policy PANA messages between PREs and PAAs should only be accepted from PANA peers as identified in the local configuration.
PresとPaasの間のセキュリティポリシーパナメッセージは、ローカル構成で特定されたパナピアからのみ受け入れられる必要があります。
Authentication Shared keys, indexed to the source IP address of the received PANA message, are adequate in this application.
このアプリケーションでは、受信したパナメッセージのソースIPアドレスにインデックス付けされた認証共有キーが適切です。
Availability Appropriate IPsec implementations are likely to be available for PAAs and for PREs in more featureful devices used in enterprise and core ISP networks. IPsec is less likely to be available for PREs in low-end devices primarily used in the home or small office markets.
可用性適切なIPSEC実装は、PAASおよびEnterpriseおよびCore ISPネットワークで使用されるより特徴的なデバイスで利用できる可能性があります。IPSECは、主にホームまたは小規模のオフィス市場で使用されているローエンドデバイスでPresで利用できる可能性が低くなります。
The PANA-Relay (PRY) message is sent by the PRE to the PAA or by the PAA to the PRE. It contains one PaC-Information AVP and one Relayed-Message AVP. The PRY message SHOULD NOT carry other AVPs.
Pana-relay（PRY）メッセージは、PAAにPAAまたはPAAによってPEAに送信されます。1つのPAC情報AVPと1つのリレーメッセージAVPが含まれています。PRYメッセージは、他のAVPを運ぶべきではありません。
In a PRE-originated PRY message, the PaC-Information AVP contains an IP address and the UDP port number of the PANA message that was originated by the PaC and is contained in the Relayed-Message AVP.
事前に発作されたPryメッセージで、PAC情報AVPにはIPアドレスと、PACが発信し、リレーメッサージAVPに含まれるPANAメッセージのUDPポート番号が含まれています。
In a PAA-originated PRY message, the information in the PaC-Information AVP MUST be copied from the "IP address and UDP port number of the PaC" attribute of the associated PANA session [RFC5191].
PAAに由来するPRYメッセージでは、PAC情報AVPの情報は、関連するPANAセッション[RFC5191]の「IPアドレスとUDPポート番号」属性からコピーする必要があります。
The Session Identifier and Sequence Number field of any PRY message MUST be set to zero. A PRY message MUST NOT be retransmitted by the PRE or the PAA.
PRYメッセージのセッション識別子とシーケンス番号フィールドは、ゼロに設定する必要があります。PRYメッセージをPREまたはPAAによって再送信してはなりません。
PANA-Relay ::= < PANA-Header: 5 >
{ PaC-Information }
{ Relayed-Message }
*[ AVP ]
The PaC-Information AVP (AVP Code 10) is of type OctetString and contains an IP address (16-octet for an IPv6 address or 4-octet for an IPv4 address) followed by a 2-octet UDP port number of the PaC, both encoded in network-byte order.
PAC-Information AVP（AVPコード10）はタイプのオクテットストリングで、IPアドレス（IPv6アドレスの16-OCTETまたはIPv4アドレスの4-OCTET）が含まれています。ネットワークバイト順序でエンコードされています。
The Relayed-Message (AVP Code 11) is of type OctetString and contains a relayed PANA message excluding the UDP and IP headers.
リレーメス（AVPコード11）はタイプのオクテットストリングで、UDPおよびIPヘッダーを除くリレーされたパナメッセージが含まれています。
A PRE's main objective is to assist transport of PANA messages between the PaC and the PAA. Relay operation performed between the PRE and the PAA forms an additional logical link for relaying the end-to-end PANA messages between the PaC and the PAA. In that sense, a PRE resembles a bridge or a router that sits between the PaC and the PAA when non-relayed PANA [RFC5191] is used.
事前の主な目的は、PACとPAA間のパナメッセージの輸送を支援することです。PREとPAAの間で実行されるリレー操作は、PACとPAAの間のエンドツーエンドのパナメッセージを中継するための追加の論理リンクを形成します。その意味で、プレイが使用されていないパナ[RFC5191]が使用されると、PACとPAAの間にあるブリッジまたはルーターに似ています。
A PRE can pose certain threats to the relayed PANA messages. A PRE can delay or drop PANA messages sent by the PaC or the PAA. It can also spoof or modify PANA messages sent towards the PaC or the PAA. These threats are similar to what an on-path bridge/router (i.e., a man-in-the-middle, MitM) can pose to non-relayed PANA. EAP and PANA protocols are designed to operate over unsecure links where aforementioned threats can already exist. Even though these threats cannot be leveraged to gain unauthorized network access, or compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.), other damages such as preventing authentication to complete, or denial-of service are still possible.
事前は、中継されたパナメッセージに特定の脅威をもたらす可能性があります。PACまたはPAAから送信されたパナメッセージを遅らせるかドロップすることができます。また、PACまたはPAAに送信されるパナメッセージをスプーフィングまたは変更することもできます。これらの脅威は、オンパスブリッジ/ルーター（すなわち、中間者、MITM）が非関連パナにポーズをとることができるものに似ています。EAPおよびPANAプロトコルは、前述の脅威がすでに存在する可能性のある不安定なリンクを操作するように設計されています。これらの脅威を活用して、不正なネットワークアクセスを獲得したり、暗号化キー（MK、MSK、EMSKなど）の妥協を獲得することはできませんが、認証を防止したり、サービスを拒否したり、サービスを拒否するなど、その他の損害が可能です。
Even though the PRE-to-PAA relay path appears to be a separate additional logical link for transporting the PANA messages, the PRE may pose a few additional risks versus traditional on-path bridges and routers. The following explains the risks and mitigations of PRE as a relay device.
PAA前のリレーパスは、パナメッセージを輸送するための別の追加の論理リンクであるように見えますが、プリは、従来のオンパス橋とルーターに対していくつかの追加のリスクをもたらす可能性があります。以下は、リレーデバイスとしてのpreのリスクと緩和を説明しています。
The PRE inserts PaC-Information AVP as the PaC-generated PANA packet is encapsulated in a PRY packet to the PAA. This AVP carries the IP address and the UDP port number values of the PANA packet as sent by the PAC. These values are already carried inside the IP and UDP headers with non-relayed PANA and they are not necessarily secured. EAP and PANA are designed to work in the absence of their protection. Therefore, no additional PANA-layer security is needed when these values are carried as PANA AVPs between the PRE and the PAA. If a future document defines additional payload AVPs for the PRY messages, there may be a need to define additional security for those messages.
PAC生成されたパナパケットがPAAのPRYパケットにカプセル化されているため、PAC情報AVPを挿入します。このAVPには、PACが送信したPANAパケットのIPアドレスとUDPポート番号値が搭載されています。これらの値は、すでに関連性のないパナを備えたIPおよびUDPヘッダー内に既に運ばれており、必ずしも保護されているわけではありません。EAPとパナは、保護がない場合に機能するように設計されています。したがって、これらの値がPREとPAAの間にパナAVPとして運ばれる場合、追加のパナ層セキュリティは必要ありません。将来のドキュメントがPRYメッセージの追加のペイロードAVPを定義している場合、それらのメッセージの追加のセキュリティを定義する必要があるかもしれません。
A rogue PRE can spoof PANA messages on behalf of a victim PaC and receive the PAA response irrespective of the location of the PRE with respect to the network topology. Achieving the same threat with non-relayed PANA requires the rogue node be an MitM, otherwise the spoofed packets may be dropped by the ingress filtering network elements, or the responses would be directly sent to the victim PaC IP address and may not be received by the rogue node. Nevertheless, such a rogue PRE cannot perform full initial authentication on behalf of the victim PaC unless it also holds the PaC's credentials
不正な事前は、犠牲者PACに代わってパナメッセージを吹き飛ばすことができ、ネットワークトポロジに関するPREの位置に関係なくPAA応答を受け取ることができます。非関連パナで同じ脅威を達成するには、RogueノードがMITMである必要があります。そうしないと、イングレスフィルタリングネットワーク要素によってスプーフィングされたパケットがドロップされるか、応答が被害者PAC IPアドレスに直接送信され、受信されない場合があります。ローグノード。それにもかかわらず、そのような不正な事前は、PACの資格情報も保持しない限り、被害者PACに代わって完全な初期認証を実行することはできません
(including the master key). Furthermore, any spoofed PANA messages after the initial authentication will fail the integrity checks at the PAA when a key-generating EAP method is used.
（マスターキーを含む）。さらに、初期認証後にスプーフィングされたパナメッセージは、キー生成EAPメソッドが使用される場合、PAAでの整合性チェックに失敗します。
The only state that can change on the PAA upon a rogue PRE sending a spoofed PRY is the IP address and UDP port number of the PRE stored as PANA session attributes, which impacts where the PAA sends the next PANA packet (i.e., to the rogue PRE instead of the legitimate PRE). The PAA also needs to handle the PaC-Information AVP in addition to the PaC-originated PANA message carried in the Relayed-Message AVP, so use of the PRE may impose additional storage requirements on the PAA. A rogue PRE generating a valid PANA packet requires it be a MitM in order to synch up with the PANA session state and attributes on the PaC. Such a MitM can already disturb the EAP and PANA even without playing the role of a PRE.
スプーフィングされたpryを送信する不正さでPAAで変更できる唯一の状態は、PANAセッション属性として保存された事前保存されたIPアドレスとUDPポート番号であり、PAAが次のパナパケットを送信する場所に影響を与えます（つまり、不正に正当なpreの代わりにpre）。PAAはまた、リレーされたメッセージAVPで運ばれるPAC誘発パナメッセージに加えて、PAC情報AVPを処理する必要があるため、PEAを使用するとPAAに追加のストレージ要件が課される可能性があります。有効なPanaパケットを事前に生成する不正さは、PACのPANAセッションの状態と属性と同期するためにMITMである必要があります。このようなMITMは、プレの役割を果たさなくても、すでにEAPとパナを邪魔する可能性があります。
An unauthorized node pretending as PAA can spoof the relayed PANA messages to the PRE in order to get them delivered to the PaC. While the harm caused by such spoofed packets are limited (due to the EAP and PANA design with unsecured network operation in mind), the processing of bogus packets can cause processing load on the PaC.
PAAのふりをする不正なノードは、リレーしたパナメッセージをPACに配信するためにプリにプラフィングすることができます。そのようなスプーフィングされたパケットによって引き起こされる害は限られていますが（無担保ネットワーク操作を念頭に置いてEAPおよびPANA設計により）、偽のパケットの処理はPACの処理負荷を引き起こす可能性があります。
Some of the risks stemming from the aforementioned threats are already handled by the EAP and PANA as described. The residual risks shall be mitigated using additional physical or cryptographic security in the network hosting the PREs and the PAAs. Access control lists implemented on the PRE, PAA, or intermediary firewalls supported by cryptographic or physical authentication/authorization are needed for protecting legitimate PRE and PAAs against rogue ones. Details of the cryptographic mechanisms using IPsec are specified in Section 3. Use of manually configured preshared keys for IPsec between PREs and PAAs does not defend against replayed PANA messages.
前述の脅威に起因するリスクのいくつかは、説明されているようにEAPとパナによってすでに処理されています。残留リスクは、PRESとPAASをホストするネットワーク内の追加の物理的または暗号化セキュリティを使用して緩和されるものとします。暗号化または物理的認証/認証によってサポートされているPRE、PAA、または中間ファイアウォールに実装されたアクセス制御リストは、不正な事前およびPAAから合法的なPEAとPAAを保護するために必要です。IPSECを使用した暗号化メカニズムの詳細は、セクション3で指定されています。PRESとPAASの間でIPSECの手動で構成された事前に配ッシされたキーの使用は、再生されたPanaメッセージから防御しません。
PREs do not need to maintain per-PaC state; therefore, they are robust against resource consumption DoS (Denial-of-Service) attacks.
PresはPACあたりの状態を維持する必要はありません。したがって、それらはリソース消費DOS（サービス拒否）攻撃に対して堅牢です。
In the relay operation, the IP address of the PAA that is seen by the PaC (i.e., an IP address of the PRE) is different from the IP address of the PAA that is seen by the authentication server. If an EAP channel binding solution uses the IP address of the PAA as part of channel binding parameters, such a solution must take this into account. Note that the same issue arises even when non-relayed PANA is used and the PAA has one IP address configured on its interface facing the PaC and another IP address on the other interface facing the authentication server.
リレー操作では、PAC（つまり、PREのIPアドレス）で見られるPAAのIPアドレスは、認証サーバーで見られるPAAのIPアドレスとは異なります。EAPチャネル結合ソリューションがチャネル結合パラメーターの一部としてPAAのIPアドレスを使用する場合、このようなソリューションはこれを考慮する必要があります。非関連パナが使用され、PAAがPACに面したインターフェイスに1つのIPアドレスと、認証サーバーに面したもう1つのインターフェイスに別のIPアドレスが構成されている場合でも、同じ問題が発生することに注意してください。
As described in Sections 4 and 5, and following the new IANA allocation policy on PANA messages [RFC5872], one Message Type and two PANA AVP Codes have been assigned.
セクション4および5で説明し、パナメッセージ[RFC5872]の新しいIANA割り当てポリシーに従って、1つのメッセージタイプと2つのPANA AVPコードが割り当てられています。
o A Message Type of 5 for PANA-Relay (PRY) message with the 'R' (Request) bit cleared.
o 「R」（リクエスト）ビットがクリアされたパナレイ（PRY）メッセージのメッセージタイプ5。
o A standard AVP Code of 10 for PaC-Information AVP.
o PAC情報AVP用の標準AVPコード10。
o A standard AVP Code of 11 for Relayed-Message AVP.
o リレーメッサージAVPの標準AVPコード11。
The authors would like to thank Vlad Gherghisan, Shohei Watanabe, Richard Kelsey, Rafa Marin Lopez, Margaret Wasserman, Alan DeKok, Ralph Droms, Jari Arkko, Yoshifumi Nishida and Stephen Farrell for their valuable comments.
著者は、Vlad Gherghisan、Shohei Watanabe、Richard Kelsey、Rafa Marin Lopez、Margaret Wasserman、Alan Dekok、Ralph Droms、Jari Arkko、Yoshifumi nishida、Stephen Farrellに貴重なコメントに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Patil、B.、Tschofenig、H。、およびA. Yegin、「ネットワークアクセスの認証を運ぶためのプロトコル（PANA）」、RFC 5191、2008年5月。
[RFC5192] Morand, L., Yegin, A., Kumar, S., and S. Madanapalli, "DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents", RFC 5192, May 2008.
[RFC5192] Morand、L.、Yegin、A.、Kumar、S。、およびS. Madanapalli、「ネットワークアクセス（PANA）認証エージェントの認証を運ぶためのプロトコルのDHCPオプション」、RFC 5192、2008年5月。
[RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5872, May 2010.
[RFC5872] Arkko、J。およびA. Yegin、「ネットワークアクセスのための認証を運ぶためのプロトコルのIANAルール（PANA）」、RFC 5872、2010年5月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944] Montenegro、G.、Kushalnagar、N.、Hui、J。、およびD. Culler、「IEEE 802.15.4ネットワーク上のIPv6パケットの伝送」、RFC 4944、2007年9月。
[6LoWPAN-ND] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Work in Progress, June 2011.
[6lowpan-nd] Shelby、Z.、Chakrabarti、S。、およびE. Nordmark、「低電力と損失のあるネットワークの近隣発見最適化（6lowpan）」、2011年6月の進行中。
[ZIGBEEIP] ZigBee Alliance, "ZigBee IP Specification", ZigBee 095023r10, Work in Progress, July 2010.
[Zigbeeip] Zigbee Alliance、「Zigbee IP仕様」、Zigbee 095023R10、2010年7月の作業。
Authors' Addresses
著者のアドレス
Paul Duffy Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 USA
Paul Duffy Cisco Systems 200ビーバーブルックロードボックスボロー、マサチューセッツ州01719 USA
EMail: paduffy@cisco.com
Samita Chakrabarti Ericsson 300 Holger Way San Jose, CA 95135 USA
サミタ・チャクラバルティ・エリクソン300ホルガー・ウェイ・サンノゼ、カリフォルニア州95135 USA
EMail: samita.chakrabarti@ericsson.com
Robert Cragie Pacific Gas & Electric Gridmerge Ltd., 89 Greenfield Crescent Wakefield, WF4 4WA UK
Robert Cragie Pacific Gas＆Electric Gridmerge Ltd.、89 Greenfield Crescent Wakefield、WF4 4WA UK
EMail: robert.cragie@gridmerge.com
Yoshihiro Ohba (editor) Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
ヨシヒロ・オバ（編集者）東芝コーポレート・リサーチ開発センター1コムカイ・トゥーバ - チョチョ・サイワイ・ク、川崎、川川212-8582日本
Phone: +81 44 549 2127
EMail: yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
Alper Yegin Samsung Istanbul Turkey
EMail: a.yegin@partner.samsung.com