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
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.
この文書は、2つのノードは、通常のIPルーティングによって相互に到達できないPANAクライアント（PAC）とPANA認証エージェント（PAA）との間のPANAメッセージングを可能にするネットワークアクセス（PANA）リレー要素の機能、のための認証を搬送するプロトコルを指定し。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
この文書は、PAC及び2つのノードが定期的なIPルーティングによって相互に到達できないPAA間PANAメッセージングを可能PANAリレー要素（PRE）機能を指定します。例えば、6LoWPAN [RFC4944]を使用するジグビーIP [ZIGBEEIP]で、参加するノード（PAC）は、唯一の前PANA認証に親ノードと通信するためにリンクローカルIPv6アドレスを使用することができます。 PAAは、典型的には、しばしば6LowPANボーダルータ（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.
複数のIPは離れたPaCからホップ。親ノードに実装さPREは、PACとこのシナリオではPAAとの間のPANAメッセージを中継するために使用されます。
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].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの単語は資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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リレー要素（PRE）は、のPaCとPAAとの間に位置するノードです。これは、PACとPAA間でPANAのメッセージを中継する責任があります。 PREごと-PAC状態を維持する必要はありません。 PaCの観点から、PREは、PAAとして表示されます。通常のIPルーティングはPREとPAAとの間で行われます。 PAAは、複数のPREと通信することができます。 PREは、複数のPaaSと通信することができ、それが与えられたのPaCのために通信するために1つのPAAを選択します。デフォルトによって、PACは[RFC5192]で定義されるようにPAA発見のための正常な機構を使用してPREを発見します。 PREは、PAA（単数または複数）のIPアドレス（複数可）で構成されているものとします。 PREの動的PAAディスカバリ方式は、この文書の範囲外です。
The PRE and the PAA support the relay operation as follows.
次のようにPREおよび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.
PREによってPACからPANAメッセージを受信すると、中継され、メッセージAVP（セクション5.2を参照）、PAC-情報AVP（セクション5.1を参照）を含むPANA-リレー（PRY）メッセージ（セクション4.1を参照）を作成します。中継さ-のメッセージAVPがpacから受け取った全体PANAメッセージをカプセル化します。 PAC-情報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メッセージを受信すると、PAC-情報AVPから中継され、メッセージのAVPとPACのIPアドレスとUDPポート番号からPAC-起源PANAメッセージを取得します。 PAC-発信PANAメッセージは、次の例外を除いて、[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 or sent from more than one PaC with the same the IP address and the port number through different PREs.
（a）は、IPアドレスとPAC-情報AVPに含まれるポート番号とPREの送信元IPアドレス及びUDPポート番号が同じを通して異なるPaCのから送信された複数のPANA-クライアント開始メッセージの中のPAC識別するために使用されますPREまたは異なるのPREを通じて同じ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）は、IPアドレスとPAC-情報AVPに含まれるポート番号は、PANAセッション属性「IPアドレスとPACのUDPポート番号」[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ポート番号は、新たなPANAセッションの属性「PREのIPアドレスとUDPポート番号」でPAAによって維持されています。この属性がnull以外の値を持つ場合PANAセッションが中継されるPANAセッションと呼ばれています。
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が中継されるPANAセッションのためのPANAメッセージを発信する場合は、PREのIPアドレスへのPRYメッセージを送信し、IPアドレスとUDPポート」PANAセッションの属性で維持PREの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.
PREがPRYメッセージを受信すると、それが中継され、メッセージAVPとPACのIPアドレスとUDPポート番号からとPAC-情報のAVPからPAA-起源PANAメッセージを取得します。 PAA-発信PANAメッセージは、PANAポート番号（716）と中継され、メッセージのAVPに含まれるUDPポート番号に設定された宛先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に運ばPANAメッセージが同じ中継され、メッセージのAVPを運ぶ新しいPRYメッセージの送信につながるのPaCまたはPAAによって再送信されてもよいことに留意されたいです。
A PAA that supports this specification MUST be able to process PRY messages for PaC-initiated PANA sessions.
この仕様をサポートしているPAAは、PAC-開始PANAセッションの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つのPREがある前提としています。既に中継されるPANAメッセージに中継動作を行う（すなわち、PRYメッセージ内部に運ば）本明細書の範囲外です。
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
2. ---PRY[P{IP1:p1},R{PCI}]--> IP2b:p2 -> IP3:716
3. <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 -> IP2b:p2
4. <--PAR--- IP2a:716 -> IP1:p1
5. ---PAN--> IP1:p1 -> IP2a:716
6. ---PRY[P{IP1:p1},R{PAN}]--> IP2b:p2 -> IP3:716
7. <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 -> IP2b:p2
8. <--PAR--- IP2a:716 -> IP1:p1
9. ---PAN--> IP1:p1 -> IP2a:716
10. ---PRY[P{IP1:p1},R{PAN}]--> IP2b:p2 -> IP3: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：PANAリレーの例コールのメッセージ
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]はPANAリレーメッセージを固定するために使用することができる方法について説明します。
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は使用されている場合は、各PREは、PAAとの確立ペアごとの信頼関係を持っている必要があります。 PaCからのメッセージがPAAにPREによって中継される場合には、PREおよびPAAは、彼らが交換するメッセージのためにIPsecを使用するように設定されている必要があります。
PREs and PAAs that support secure PRE to PAA communication use IPsec under the following conditions:
以下の条件でPAAの通信利用のIPsecへの安全なPREをサポートするのPREとのPaaS：
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.
セレクタのPREを手動PANAメッセージが転送されるべきとのPaaSのアドレスで構成されています。 PANAメッセージを保護するためにIPsecを使用するのPaaSも返されるメッセージにのPREのリストを設定する必要があります。 PREとPaaSのためのセレクタは、その送信元ポートまたは宛先ポートにPANA UDPポート716上のPANAメッセージを交換のPREとの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).
モードのPREとのPaaSは、トランスポートモードとESPを使用しています。 PANAメッセージ内の情報は一般的に機密とはみなされないため、暗号化を使用する必要はありません（つまり、NULL暗号化を使用することができます）。
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.
鍵管理のPREとPAAを手動で設定する必要がありますので、手動で設定されているキー管理が十分であるが、リプレイされたメッセージに対する防御を提供していません。したがって、事前共有秘密を持つIKEがサポートされるべきです。公開鍵とIKEをサポートすることができます。
Security policy PANA messages between PREs and PAAs should only be accepted from PANA peers as identified in the local configuration.
ローカル設定で識別されるのPREとPaaSの間のセキュリティポリシーPANAメッセージはPANAピアから受け入れられるべきです。
Authentication Shared keys, indexed to the source IP address of the received PANA message, are adequate in this application.
受信されたPANAメッセージの送信元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のためと企業とコアISPネットワークで使用される、より高機能のデバイスでのPREのために利用可能である可能性が高いです。 IPsecは、主に家庭や小規模オフィス市場で使用される低エンドデバイスでのPREのために利用可能になりにくいです。
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リレー（PRY）メッセージがPAAにPREによって、またはPREにPAAにより送信されます。これは、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.
PRE-起源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]の属性「PACの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-情報AVP（AVPコード10）はタイプOctetStringにあるとPACの2オクテットUDPポート番号が続くIPアドレス（IPv6アドレスまたはIPv4アドレスの4オクテット16オクテット）が含まれ、両方ネットワークバイト順で符号化されました。
The Relayed-Message (AVP Code 11) is of type OctetString and contains a relayed PANA message excluding the UDP and IP headers.
中継され、メッセージ（AVPコード11）はタイプOctetStringにあり、UDPおよびIPヘッダを除いた中継PANAメッセージを含みます。
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.
PREの主な目的は、PACとPAA間でPANAメッセージの輸送を支援することです。リレー動作がPREとの間で行われるとPAAは、PACとPAA間のエンドツーエンドPANAメッセージを中継するための追加の論理リンクを形成します。その意味では、PREは、ブリッジまたは非中継PANA [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.
PREは、中継されたPANAメッセージに特定の脅威をもたらすことができます。 PREは、PACまたはPAAにより送信されたPANAメッセージを遅らせたりドロップすることができます。それはまたのPaCまたはPAAに向けて送られたPANAメッセージを偽造または変更することができます。これらの脅威は、オンパスブリッジ/ルータ（すなわち、マン・イン・ザ・ミドル、のMitM）非中継PANAにもたらすことができるものと同様です。 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.
PRE-へ-PAA中継経路がPANAメッセージを輸送するための独立した追加の論理リンクのように見えるにもかかわらず、PREは、伝統的にパスブリッジやルータに対していくつかの追加のリスクをもたらす可能性があります。以下は、中継装置として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-生成PANAパケットはPAAにPRYパケットにカプセル化されるPREは、PAC-情報AVPを挿入します。 PACにより送信されたように、このAVPは、IPアドレスとPANAパケットのUDPポート番号の値を運びます。これらの値は、すでに非中継PANAでIPおよびUDPヘッダ内運ばれ、彼らは必ずしも確保されていません。 EAPおよびPANAは、その保護のない状態で動作するように設計されています。これらの値は、PREとPAA間PANAのAVPとして実施される場合、したがって、追加のPANA・レイヤ・セキュリティは必要とされません。将来の文書が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 (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.
不正PREは、被害者のPAC代わっPANAメッセージを偽装し、ネットワークトポロジに対してかかわらずPREの位置のPAA応答を受信することができます。非中継PANAと同じ脅威を達成することは、さもなければスプーフィングされたパケットは、イングレスフィルタリングネットワーク要素によって破棄される可能性があり、または応答が直接被害者のPaC IPアドレスに送信されるであろうとによって受信されない場合があり、不正なノードのMitMことが必要不正ノード。それはまた、（マスターキーを含む）のPaCの資格を保持していない限りそれにもかかわらず、このようローグPREは、被害者のPaCの代わりに、完全な初期認証を実行することはできません。さらに、任意のキー生成EAP方式が使用されている場合PAAで整合性チェックを失敗する初期認証後にPANAメッセージを偽装されました。
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を送信する不正なPRE時にPAAに変更することができる唯一の状態が不正に、PAAは、次のPANAパケット（すなわちを送信影響PANAセッション属性として格納されたPREのIPアドレスとUDPポート番号です代わりに、正当なPREのPRE）。 PAAはまた、PREの使用がPAAに追加のストレージ要件を課すことができるので、中継さ-のメッセージAVPに運ばPAC-起源PANAメッセージに加えて、PAC-情報AVPを処理する必要があります。有効なPANAパケットを生成する不正なPREは、PANAセッション状態とPACの属性にアップ同期させるためにのMitMことが必要です。そのようなMitMはすでにさえPREの役割を再生せずにEAPおよびPANAを乱すことができます。
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に配信を取得するために、PREに中継PANAメッセージを偽装することができます。このよう偽装されたパケットによって引き起こされる害が（原因念頭に保護されていないネットワーク動作と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およびPANAによって処理されます。残留リスクがのPREとのPaaSをホスティングしているネットワークに追加の物理または暗号化セキュリティを使用して軽減されなければなりません。 PRE、PAA、または暗号化または物理的な認証/認可でサポートされている仲介ファイアウォール上に実装されたアクセス制御リストが不正なものに対して正当なPREとのPaaSを保護するために必要とされます。 IPsecを使用して暗号化メカニズムの詳細については、のPREとPaaSの間のIPsecのために手動で構成事前共有キーの3.が再生PANAメッセージを防御しないセクションで指定されています。
PREs do not need to maintain per-PaC state; therefore, they are robust against resource consumption DoS (Denial-of-Service) attacks.
PREごと-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アドレスを使用している場合は、そのような解決策は、これを考慮に入れなければなりません。非中継PANAが使用され、PAAはPaCは、認証サーバが直面している他のインターフェイス上の別のIPアドレスに面するインターフェイスで構成された一つの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に記載され、PANAメッセージ[RFC5872]に新しいIANA割り当てポリシーを以下のように、1つのメッセージタイプ二つPANA AVPコードが割り当てられています。
o A Message Type of 5 for PANA-Relay (PRY) message with the 'R' (Request) bit cleared.
O PANAリレー（PRY）「R」（要求）のメッセージのための5のメッセージタイプをクリアビット。
o A standard AVP Code of 10 for PaC-Information AVP.
PAC-情報AVPのための10のoは標準AVPコード。
o A standard AVP Code of 11 for Relayed-Message AVP.
中継され、メッセージAVPのための11のoは標準AVPコード。
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.
作者は彼らの貴重なコメントをヴラドGherghisan、昌平渡辺、リチャード・ケルシー、ラファマリン・ロペス、マーガレットワッサーマン、アラン・DeKok、ラルフDroms、ヤリArkko、西田佳史とステファン・ファレルに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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]フォースバーグ、D.、オオバ、Y.、パティル、B.、Tschofenig、H.、およびA. Yegin、RFC 5191、2008年5月 "ネットワークアクセス（PANA）の認証を搬送するプロトコル"。
[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]モラン、L.、Yegin、A.、クマー、S.、およびS. Madanapalli、 "ネットワークアクセスの認証を実施するためのプロトコルのためのDHCPオプション（PANA）認証エージェント"、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.
、RFC 5872、2010年5月[RFC5872] Arkko、J.、およびA. Yegin、 "ネットワークアクセス（PANA）の認証を搬送するプロトコルのためのIANAルール"。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、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]モンテネグロ、G.、クシャルナガル、N.、ホイ、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]シェルビー、Z.、Chakrabarti、S.、およびE. Nordmarkと、 "低消費電力とロッシーネットワーク（6LoWPAN）のための近隣探索の最適化"、進歩、2011年6月での作業。
[ZIGBEEIP] ZigBee Alliance, "ZigBee IP Specification", ZigBee 095023r10, Work in Progress, July 2010.
[ZIGBEEIP]ジグビー・アライアンスは、 "ジグビーIP仕様"、ジグビー095023r10は、進捗状況、2010年7月に作業します。
Authors' Addresses
著者のアドレス
Paul Duffy Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 USA
ポール・ダフィーシスコシステムズ200ビーバーブルック・ロードボックスボロー、MA 01719 USA
EMail: paduffy@cisco.com
メールアドレス：paduffy@cisco.com
Samita Chakrabarti Ericsson 300 Holger Way San Jose, CA 95135 USA
Samita Chakrabartiエリクソン300ホルガー・ウェイサンノゼ、CA 95135 USA
EMail: samita.chakrabarti@ericsson.com
メールアドレス：samita.chakrabarti@ericsson.com
Robert Cragie Pacific Gas & Electric Gridmerge Ltd., 89 Greenfield Crescent Wakefield, WF4 4WA UK
ロバートCragieパシフィック・ガス＆エレクトリックGridmerge株式会社、89グリーンフィールドクレセントウェイクフィールド、WF4 4WA英国
EMail: robert.cragie@gridmerge.com
メールアドレス：robert.cragie@gridmerge.com
Yoshihiro Ohba (editor) Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
よしひろ おｈば （えぢとｒ） としば こｒぽらて れせあｒｃｈ あんｄ でゔぇぉｐめんｔ せんてｒ １ こむかいーとしばーちょ さいわいーく、 かわさき、 かながわ ２１２ー８５８２ じゃぱん
Phone: +81 44 549 2127 EMail: yoshihiro.ohba@toshiba.co.jp
電話：+81 44 549 2127 Eメール：yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
アルパースティラーサムスンイスタンブールトルコ
EMail: a.yegin@partner.samsung.com
メールアドレス：a.yegin@partner.samsung.com