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)
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.
この文書では、積極的にどのPANAクライアントが移動してもよいし、別のアクセスネットワーク内の1つのアクセスネットワークと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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 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 . . . . . . . . . . . . . . . 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は、ハンドオーバ期間中にアプリケーションの性能を低下させることなく、シームレスにハンドオーバを実行することが重要です。ハンドオーバが新しいアクセスネットワークにPAAとPANAセッションを確立するためのPaCが必要な場合、PANAセッションを確立するためのシグナリングは、できるだけ速く完了する必要があります。ハンドオーバ待ち時間の要件については、[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が動く可能性があるために別のアクセスネットワーク内のPAA内のPaCとの間の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].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
サービングネットワークに存在し、特定のPaCのネットワークアクセス認証を提供PAA：PAA（SPAA）となります。
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事前認証を参照して前にその認証者[RFC5836]によってサービスアクセスネットワークにおけるピアの到着にオーセンティケータにEAPキーイング材料を事前に確立するEAPの利用として定義されます。この文書では、EAP事前認証は、PACとCPAAの間で行われます。
A PaC that supports pre-authentication may establish a PANA session for each CPAA.
事前認証をサポートしてPACは、各CPAAのためにPANAセッションを確立することができます。
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アドレスは、それらのメカニズムの出力です。 PANAの事前認証は、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」（事前認証）ビットは、PANAヘッダに定義されています。事前認証を行う場合、PANAメッセージの「E」（事前認証）ビットはこのPANA実行が事前認証のためのものであることを示すために設定されています。次のように事前認証の使用が交渉されています。
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.
PACが事前認証を開始すると、O、それはビットセット「E」（事前認証）とPANAクライアント・イニシエーション（PCI）メッセージを送信します。 CPAAは「S」（スタート）と「E」、それは事前認証をサポートしている場合にのみ設定（事前認証）ビットとPANA-Authのリクエスト（PAR）メッセージで応答します。そうでなければ、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.
PaCとCPAAが正常（START）と「E」（事前認証）ビットを「S」を使用して事前認証を行う上でネゴシエートした後、O、後続のPANAメッセージは、それらの間で交換「E」を持たなければならない（事前認証CPAAによってPACのSPAAになるまで）ビットセット。 PACは、複数のCPAAでこの交換を行うことができます。 PaCとCPAAが事前認証を行う上で交渉に失敗した場合、のPaCまたは「S」（START）と「E」（事前認証）の両方にメッセージを送信したCPAAをセットから受信されたメッセージを破棄しなければならないビット最終的にPANAセッション終了になりますこれは、ビットクリア「S」（スタート）ビットセットと「E」（事前認証）とピアリング。
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.
IPの再構成がCPAAに関連付けられたアクセスネットワークで必要とされている場合は、の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が原因のPAC動きに、例えば、SPAAなった場合、PACはP」とのPANA-NOTIFICATION-要求（PNR）とPANA-NOTIFICATION-回答（PNA）メッセージを使用して、変更のPAAを通知します'（Pingが）ビットセットと 『E』（事前認証）は、ビットをクリア。 「E」（事前認証）ビット以降のPANAメッセージでクリアする必要があります。
A PANA SA is required for pre-authentication in order to securely associate the PNR/PNA exchange to the earlier authentication.
PANA SAを確実に以前の認証にPNR / PNA交換を関連付けるために事前認証のために必要とされます。
The PANA session between the PaC and a CPAA is deleted by entering the termination phase of the PANA protocol.
PaCとCPAA間のPANAセッションがPANAプロトコルの終了フェーズを入力することによって削除されます。
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.
事前認証のための例示的なコール・フローは、EAP認証が（完全）「C」を有するものを含む、PARとPANA-AUTH-応答（PAN）の交流を介して実行されることを、図1注記に示されているビットセット。
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」（事前認証）ビット以下のようにPANAヘッダのフラグフィールドに定義されています。
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」（事前認証）ビット：事前認証を行う場合、PANAメッセージの「E」（事前認証）ビットはこのPANA実行が事前認証のためのものであるかどうかを示すために設定されています。このビットの正確な使用量は、ビット6は、IANAによって割り当てられた第3節に記載されています。
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.
次のように事前認証の拡張機能をサポートしていませんPANAエンティティと事前認証の拡張をサポートする別のPANAエンティティ間の下位互換性が維持されています。
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が事前認証の拡張機能をサポートしていないPAAビットをセット「E」（事前認証）でPCIメッセージを送信することにより、PANA事前認証を開始すると、PAAは無視します。 「E」[RFC5191]のセクション6.2に従って（事前認証）ビット、および通常の認証の試みとしてメッセージを処理しようとします。結果として、PACはクリアビット「E」（事前認証）とPARメッセージを受信します。この場合、事前認証の使用に関する交渉が失敗し、第3節で説明したように、最終的PANAセッションが終了します。
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プロトコルに基づいて、それは一つの重要な違いを除いて、同じセキュリティ特性を示すされています。事前認証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はステートレス滞在する方法について説明します。事前認証（[RFC5191]、セクション4.1を参照）、これらのガイドラインに従うべきであることが使用のPaaS。
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.
また、PANA事前認証メッセージが所与の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「E」（事前認証）ビットのためにIANAによって割り当てられています。
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パティル、アッシュートッシュDuttaさん、ジュリアンBournelle、Sasikanth Bharadwaj、Subirダス、ラファマリン・ロペス、ライオネル・モラン、ビクターファハルド、グレン・ソーン、秦呉、ヤリArkko、パシEronen、およびジョセフSaloweyに感謝したいと貴重なフィードバック。
[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月。
[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）の認証を搬送するプロトコル"。
[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ルール"。
[RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed., "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC5836]オオバ、Y.、エド。、ウー、Q.、エド。、及びG.ゾルン、編、 "拡張認証プロトコル（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コンピュータ学会802.21、2008年のLAN MAN標準委員会。
Authors' Addresses
著者のアドレス
Yoshihiro Ohba Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
よしひろ おｈば としば こｒぽらて れせあｒｃｈ あんｄ でゔぇぉｐめんｔ せんてｒ １ こむかいーとしばーちょ さいわいーく、 かわさき、 かながわ ２１２ー８５８２ じゃぱん
Phone: +81 44 549 2230 EMail: yoshihiro.ohba@toshiba.co.jp
電話：+81 44 549 2230 Eメール：yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
アルパースティラーサムスンイスタンブールトルコ
EMail: alper.yegin@yegin.org
メールアドレス：alper.yegin@yegin.org