[要約] RFC 5873は、PANAプロトコルの事前認証サポートに関する仕様です。目的は、ネットワークアクセスの認証を強化し、セキュリティを向上させることです。
Internet Engineering Task Force (IETF) Y. Ohba
Request for Comments: 5873 Toshiba
Category: Experimental A. Yegin
ISSN: 2070-1721 Samsung
May 2010
Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)
ネットワークアクセスのために認証を携帯するためのプロトコルの認証前サポート（PANA）
Abstract
概要
This document defines an extension to the Protocol for Carrying Authentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move.
このドキュメントでは、1つのアクセスネットワーク内のPANAクライアントとPANAクライアントが移動する可能性のある別のアクセスネットワークでPANAクライアントとPANA認証エージェントとの間のPANAセキュリティアソシエーションを積極的に確立するためのネットワークアクセス（PANA）を運ぶためのプロトコルの拡張機能を定義しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。インターネットエンジニアリングステアリンググループ（IESG）によって公開されることが承認されています。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/rfc5873.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5873で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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 . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pre-Authentication Procedure . . . . . . . . . . . . . . . . . 3
4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
The Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] carries Extensible Authentication Protocol (EAP) messages between a PANA Client (PaC) and a PANA Authentication Agent (PAA) in the access network. If the PaC is a mobile device and is capable of moving from one access network to another while running its applications, it is critical for the PaC to perform a handover seamlessly without degrading the performance of the applications during the handover period. When the handover requires the PaC to establish a PANA session with the PAA in the new access network, the signaling to establish the PANA session should be completed as fast as possible. See [RFC5836] for the handover latency requirements.
ネットワークアクセス（PANA）[RFC5191]の認証を運ぶためのプロトコルは、アクセスネットワーク内のPANAクライアント（PAC）とPANA認証エージェント（PAA）の間に拡張可能な認証プロトコル（EAP）メッセージを伝達します。PACがモバイルデバイスであり、アプリケーションを実行中にあるアクセスネットワークから別のアクセスネットワークに移動できる場合、PACがハンドオーバー期間中にアプリケーションのパフォーマンスを低下させることなくシームレスにハンドオーバーを実行することが重要です。ハンドオーバーがPACが新しいアクセスネットワークでPAAとのパナセッションを確立する必要がある場合、パナセッションを確立するためのシグナリングは、できるだけ早く完了する必要があります。ハンドオーバーレイテンシの要件については、[RFC5836]を参照してください。
This document defines an extension to the PANA protocol [RFC5191] used for proactively executing EAP authentication and establishing a PANA SA (Security Association) between a PaC in an access network and a PAA in another access network to which the PaC may move. The extension to the PANA protocol is designed to realize direct pre-authentication defined in [RFC5836]. How to realize authorization and accounting with the use of the pre-authentication extension is out of the scope of this document.
このドキュメントでは、EAP認証を積極的に実行し、アクセスネットワーク内のPACとPACが移動する可能性のある別のアクセスネットワークのPAAの間のPANA SA（セキュリティアソシエーション）を確立するために使用されるPANAプロトコル[RFC5191]の拡張を定義します。PANAプロトコルの拡張は、[RFC5836]で定義されている直接的な事前認証を実現するように設計されています。認可と会計を実現する方法は、認証前拡張を使用してこのドキュメントの範囲外です。
In this document, several words are used to signify the requirements of the specification. These words are often 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]に記載されているように解釈される。
The following terms are used in this document, in addition to the terms defined in [RFC5191].
[RFC5191]で定義されている用語に加えて、このドキュメントでは、次の用語が使用されています。
Serving Network: The access network to which the host is currently attached.
サービングネットワーク：ホストが現在添付されているアクセスネットワーク。
Candidate Network: An access network that is a potential target of the host's handover.
候補ネットワーク：ホストのハンドオーバーの潜在的なターゲットであるアクセスネットワーク。
Serving PAA (SPAA): A PAA that resides in the serving network and provides network access authentication for a particular PaC.
サービングPAA（SPAA）：サービングネットワークに存在し、特定のPACのネットワークアクセス認証を提供するPAA。
Candidate PAA (CPAA): A PAA that resides in a candidate network to which the PaC may move. A CPAA for a particular PaC may be a SPAA for another PaC.
候補PAA（CPAA）：PACが移動する可能性のある候補ネットワークに存在するPAA。特定のPACのCPAAは、別のPACのSPAAである場合があります。
Pre-authentication: Pre-authentication refers to EAP pre-authentication and is defined as the utilization of EAP to pre-establish EAP keying material on an authenticator prior to arrival of the peer at the access network served by that authenticator [RFC5836]. In this document, EAP pre-authentication is performed between a PaC and a CPAA.
事前認証：事前認証とは、EAPの事前認証を指し、EAPの利用として定義され、その認証者が提供するアクセスネットワークにピアが到着する前に、認証器にEAPキーイン素材を事前に確立する[RFC5836]。このドキュメントでは、EAPの事前認証はPACとCPAAの間で実行されます。
A PaC that supports pre-authentication may establish a PANA session for each CPAA.
承認前をサポートするPACは、各CPAAのパナセッションを確立する場合があります。
There may be several mechanisms for a PaC to discover a CPAA. An IP address of the discovered CPAA is the output of those mechanisms. PANA pre-authentication is performed between the PaC and CPAA using the discovered IP address of the CPAA. IEEE 802.21 [802.21] Information Service MAY be used as a CPAA discovery mechanism.
PACがCPAAを発見するためのいくつかのメカニズムがあるかもしれません。発見されたCPAAのIPアドレスは、これらのメカニズムの出力です。パナの事前認証は、CPAAの発見されたIPアドレスを使用して、PACとCPAAの間で実行されます。IEEE 802.21 [802.21]情報サービスは、CPAA発見メカニズムとして使用できます。
There may be a number of criteria for CPAA selection, the timing to start pre-authentication, and the timing as to when the CPAA becomes the SPAA. Such criteria can be implementation-specific and thus are outside the scope of this document.
CPAA選択には、認証前を開始するタイミング、およびCPAAがSPAAになるタイミングには多くの基準がある場合があります。このような基準は実装固有である可能性があるため、このドキュメントの範囲外です。
Pre-authentication is initiated by a PaC in a way similar to normal authentication. A new 'E' (prE-authentication) bit is defined in the PANA header. When pre-authentication is performed, the 'E' (prE-authentication) bit of PANA messages is set in order to indicate that this PANA run is for pre-authentication. Use of pre-authentication is negotiated as follows.
受容前は、通常の認証と同様の方法でPACによって開始されます。新しい「e」（事前認証）ビットは、パナヘッダーで定義されています。事前認証が実行されると、このパナランが免除前のものであることを示すために、パナメッセージの「E」（承認前）ビットが設定されます。認証前の使用は、次のように交渉されます。
o When a PaC initiates pre-authentication, it sends a PANA-Client-Initiation (PCI) message with the 'E' (prE-authentication) bit set. The CPAA responds with a PANA-Auth-Request (PAR) message with the 'S' (Start) and 'E' (prE-authentication) bits set only if it supports pre-authentication. Otherwise, the 'E' (prE-authentication) bit of the PAR message will be cleared according to Section 6.2 of [RFC5191], which results in a negotiation failure.
o PACが事前認証を開始すると、「E」（Pre-authentication）ビットセットを使用して、パナクライアントインイテーション（PCI）メッセージを送信します。CPAAは、Pana-Auth-Request（PAR）メッセージで「S」（START）および「E」（認証前）ビットを使用して応答します。それ以外の場合、PARメッセージの「E」（免除前）ビットは[RFC5191]のセクション6.2に従ってクリアされ、交渉の失敗が生じます。
o Once the PaC and CPAA have successfully negotiated on performing pre-authentication using the 'S' (Start) and 'E' (prE-authentication) bits, the subsequent PANA messages exchanged between them MUST have the 'E' (prE-authentication) bit set until the CPAA becomes the SPAA of the PaC. The PaC may conduct this exchange with more than one CPAA. If the PaC and CPAA have failed to negotiate on performing pre-authentication, the PaC or CPAA that sent a message with both the 'S' (Start) and 'E' (prE-authentication) bits set MUST discard the message received from the peer with 'S' (Start) bit set and the 'E' (prE-authentication) bit cleared, which will eventually result in PANA session termination.
o PACとCPAAが「s」（Start）と「e」（事前認証）ビットを使用して事前認証を実行することに成功裏に交渉したら、それらの間で交換されるその後のパナメッセージには「E」（承認前）が必要ですCPAAがPACのSPAAになるまでビット設定。PACは、複数のCPAAでこの交換を行う場合があります。PACとCPAAが承認前の実行について交渉に失敗した場合、「s」（Start）と 'e」（authentication）セットの両方でメッセージを送信したPACまたはCPAAセットは、受信したメッセージを破棄する必要があります。「S」（Start）BIT SETと「E」（Pre-Authentication）を使用してピアがクリアされ、最終的にパナセッション終了が発生します。
If IP reconfiguration is needed in the access network associated with the CPAA, the 'I' (IP Reconfiguration) bit in PAR messages used for pre-authentication between the PaC and CPAA is also set. The 'I' (IP Reconfiguration) bit in these messages takes effect only after the CPAA becomes the SPAA.
CPAAに関連付けられたアクセスネットワークでIP再構成が必要な場合、PACとCPAA間の事前認証に使用されるPARメッセージの「I」（IP再構成）ビットも設定されています。これらのメッセージの「I」（IP再構成）ビットは、CPAAがSPAAになった後にのみ有効になります。
When a CPAA of the PaC becomes the SPAA, e.g., due to movement of the PaC, the PaC informs the PAA of the change using PANA-Notification-Request (PNR) and PANA-Notification-Answer (PNA) messages with the 'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The 'E' (prE-authentication) bit MUST be cleared in subsequent PANA messages.
PACのCPAAがSPAAになると、たとえばPACの動きにより、PACはPANA-Notification-Request（PNR）とPana-Notification-Answer（PNA）メッセージを使用してPAAに変化を通知します。'（ping）ビットセットと' e '（事前認証）ビットがクリアされました。「e」（事前認証）ビットは、後続のパナメッセージでクリアする必要があります。
A PANA SA is required for pre-authentication in order to securely associate the PNR/PNA exchange to the earlier authentication.
PNA/PNA交換を以前の認証に安全に関連付けるためには、PANA SAが事前認証に必要です。
The PANA session between the PaC and a CPAA is deleted by entering the termination phase of the PANA protocol.
PACとCPAAの間のパナセッションは、パナプロトコルの終了フェーズを入力することにより削除されます。
An example call flow for pre-authentication is shown in Figure 1. Note that EAP authentication is performed over PAR and PANA-Auth-Answer (PAN) exchanges, including the one with the 'C' (Complete) bit set.
事前認証のためのコールフローの例を図1に示します。EAP認証は、「C」（完全）ビットセットを含むPARおよびPANA-Auth-Answer（PAN）交換を介して実行されることに注意してください。
PaC CPAA
| |
+------------------+ |
|Pre-authentication| |
|trigger | |
+------------------+ |
| PCI w/'E' bit set |
|------------------------------------------------>|
| PAR w/'S' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'S' and 'E' bits set |
|------------------------------------------------>|
| PAR-PAN exchange w/'E' bit set |
|<----------------------------------------------->|
| PAR w/'C' and 'E' bits set |
|<------------------------------------------------|
| PAN w/'C' and 'E' bits set |
|------------------------------------------------>|
. . .
. . .
+----------+ |
| Movement | |
+----------+ |
| PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>|
| +-----------------+
| |CPAA becomes SPAA|
| +-----------------+
| PNA w/ 'P' bit set and w/o 'E' bit set |
|<------------------------------------------------|
| |
Figure 1: Pre-Authentication Call Flow
図1：認証前コールフロー
A new 'E' (prE-authentication) bit is defined in the Flags field of the PANA header as follows.
次のように、パナヘッダーのフラグフィールドで新しい「E」（事前認証）ビットが定義されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S C A P I E r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'E' (prE-authentication) bit: When pre-authentication is performed, the 'E' (prE-authentication) bit of PANA messages is set in order to indicate whether this PANA run is for pre-authentication. The exact usage of this bit is described in Section 3. Bit 6 has been assigned by IANA.
'e'（pre-authentication）bit：事前認証が実行されると、このパナランが事前認証のためであるかどうかを示すために、「e」（事前認証）のパナメッセージが設定されます。このビットの正確な使用法は、セクション3で説明されています。ビット6はIANAによって割り当てられています。
Backward compatibility between a PANA entity that does not support the pre-authentication extension and another PANA entity that supports the pre-authentication extension is maintained as follows.
免除前の拡張をサポートしていないパナエンティティと、受精前の拡張をサポートする別のパナエンティティ間の後方互換性は、次のように維持されます。
When a PaC that supports the pre-authentication extension initiates PANA pre-authentication by sending a PCI message with the 'E' (prE-authentication) bit set to a PAA that does not support the pre-authentication extension, the PAA will ignore the 'E' (prE-authentication) bit according to Section 6.2 of [RFC5191], and try to process the message as a normal authentication attempt. As a result, the PaC will receive a PAR message with the 'E' (prE-authentication) bit cleared. In this case, the negotiation on the use of pre-authentication will fail, and eventually the PANA session will be terminated as described in Section 3.
免除前の拡張をサポートするPACが、PCIメッセージを「e」（事前認証）ビットでPCIメッセージを送信してPANAの事前認証を開始すると、PAAに設定されたPAAに設定された場合、PAAは無視します。[RFC5191]のセクション6.2によると、 'e'（事前認証）ビットは、通常の認証試行としてメッセージを処理しようとします。その結果、PACは「e」（免除前）ビットがクリアされたPARメッセージを受け取ります。この場合、認証前の使用に関する交渉は失敗し、最終的にはセクション3で説明されているようにパナセッションが終了します。
This specification is based on the PANA protocol, and it exhibits the same security properties, except for one important difference: Pre-authenticating PaCs are not physically connected to an access network associated with the PAA, but they are connected to some other network somewhere else on the Internet. This distinction can create greater denial-of-service (DoS) vulnerability for systems using PANA pre-authentication if appropriate measures are not taken. An unprotected PAA can be forced to create state by an attacker PaC that merely sends PCI messages.
この仕様はPANAプロトコルに基づいており、同じセキュリティプロパティを示します。ただし、1つの重要な違いを除いて、PACを事前に除去することはPAAに関連付けられたアクセスネットワークに物理的に接続されていませんが、他のどこか他のネットワークに接続されています。インターネット上で。この区別は、適切な措置が取られない場合、Panaの事前認証を使用したシステムのサービス拒否（DOS）の脆弱性を生み出すことができます。保護されていないPAAは、PCIメッセージを単に送信する攻撃者PACによって状態を作成することを余儀なくされる可能性があります。
[RFC5191] describes how the PAA can stay stateless while responding to incoming PCIs. PAAs using pre-authentication SHOULD be following those guidelines (see [RFC5191], Section 4.1).
[RFC5191]は、着信PCIに応答しながらPAAがステートレスを維持する方法を説明しています。受容前のPAASは、これらのガイドラインに従う必要があります（[RFC5191]、セクション4.1を参照）。
Furthermore, it is recommended that PANA pre-authentication messages be only accepted from PaCs originating from well-known IP networks (e.g., physically adjacent networks) for a given PAA. These IP networks can be used with a whitelist implemented on either the firewall protecting the perimeter around the PAA or the PAA itself. This prevention measure SHOULD be used whenever it can be practically applied to a given deployment.
さらに、特定のPAAの有名なIPネットワーク（物理的に隣接するネットワークなど）から発生するPACからのみ受け入れることをお勧めします。これらのIPネットワークは、PAAの周りの境界線またはPAA自体を保護するファイアウォールのいずれかに実装されたホワイトリストで使用できます。この予防措置は、特定の展開に実際に適用できる場合はいつでも使用する必要があります。
As described in Section 4, and following the new IANA allocation policy on PANA messages [RFC5872], bit 6 of the Flags field of the PANA header has been assigned by IANA for the 'E' (prE-authentication) bit.
セクション4で説明されており、PANAメッセージ[RFC5872]に関する新しいIANA割り当てポリシーに従って、PANAヘッダーのフラグフィールドのビット6は、IANAによって「e」（事前認証）ビットのために割り当てられています。
The authors would like to thank Basavaraj Patil, Ashutosh Dutta, Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Lopez, Lionel Morand, Victor Fajardo, Glen Zorn, Qin Wu, Jari Arkko, Pasi Eronen, and Joseph Salowey for their support and valuable feedback.
著者は、Basavaraj Patil、Ashutosh Dutta、Julien Bournelle、Sasikanth Bharadwaj、Subir Das、Rafa Marin Lopez、Lionel Morand、Victor Fajardo、Glen Zorn、Qin Wu、Jari Arkko、Pasi Eronen、Joseph Saloweyに感謝します。貴重なフィードバック。
[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月。
[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月。
[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月。
[RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed., "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC5836] Ohba、Y.、ed。、Wu、Q.、ed。、およびG. Zorn、ed。、「Extensible認証プロトコル（EAP）初期認証問題声明」、RFC 5836、2010年4月。
[802.21] IEEE, "Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", LAN MAN Standards Committee of the IEEE Computer Society 802.21, 2008.
[802.21] IEEE、「ローカルおよびメトロポリタンエリアネットワークの標準：メディア独立ハンドオーバーサービス」、IEEE Computer Society 802.21、2008のLAN Man Standards委員会。
Authors' Addresses
著者のアドレス
Yoshihiro Ohba Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
ヨシヒロ大統領企業研究開発センター1 Komukai-Toshiba-Cho Saiwai-ku、川崎、Kanagawa 212-8582日本
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
Alper Yegin Samsung Istanbul Turkey
EMail: alper.yegin@yegin.org