Network Working Group G. Giaretta
Request for Comments: 5637 Qualcomm
Category: Informational I. Guardini
E. Demaria
Telecom Italia
J. Bournelle
Orange Labs
R. Lopez
University of Murcia
September 2009
Authentication, Authorization, and Accounting (AAA) Goals
for Mobile IPv6
Abstract
抽象
In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface.
商業および企業の展開では、モバイルIPv6は、モビリティサービスプロバイダー（MSP）によって提供されるサービスであることが可能です。この場合には、すべてのプロトコル動作は、モバイルIPv6とAAAインフラストラクチャとの間の相互作用を必要とし、明示的に許可および追跡する必要があるかもしれません。認証、許可、アカウンティング（AAA）インフラ（例えば、ネットワークアクセスサーバとAAAサーバ）を統合することも、モバイルIPv6ブートストラップ用の溶液成分を提供します。この文書は、モバイルIPv6のためのAAAインタフェースが必要とされるさまざまなシナリオを記述する。さらに、そのようなインタフェースの設計目標と要件を示します。
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 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 BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Motivation ......................................................4
4. Bootstrapping Scenarios .........................................4
4.1. Split Scenario .............................................5
4.2. Integrated Scenario ........................................6
5. Goals for AAA-HA Interface ......................................6
5.1. General Goals ..............................................6
5.2. Service Authorization ......................................7
5.3. Accounting .................................................8
5.4. Mobile Node Authentication .................................8
5.5. Provisioning of Configuration Parameters ...................8
6. Goals for the AAA-NAS Interface .................................9
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Mobile IPv6 [1] provides the basic IP mobility functionality for IPv6. When Mobile IPv6 is used in tightly managed environments with the use of the AAA (Authentication, Authorization, and Accounting) infrastructure, an interface between Mobile IPv6 and AAA protocols needs to be defined. Also, two scenarios for bootstrapping Mobile IPv6 service [2], i.e., split [3] and integrated [6] scenarios, require the specification of a message exchange between the Home Agent (HA) and AAA infrastructure for authentication and authorization purposes and a message exchange between the AAA server and the NAS in order to provide the visited network with the necessary configuration information (e.g., Home Agent address).
モバイルIPv6 [1]はIPv6のための基本的なIPモビリティ機能を提供します。モバイルIPv6は、AAA（認証、許可、アカウンティング）インフラストラクチャを使用してしっかりと管理された環境で使用される場合、モバイルIPv6とAAAプロトコル間のインタフェースを定義する必要があります。また、ブートストラップモバイルIPv6サービスのための2つのシナリオは、[2]、すなわち、分割[3]と一体化[6]のシナリオは、認証および許可の目的のためにホームエージェント（HA）とAAAインフラストラクチャとの間のメッセージ交換の仕様であり、Aが必要必要な設定情報（例えば、ホームエージェントアドレス）と訪問先ネットワークを提供するために、AAAサーバとNAS間のメッセージ交換。
This document describes various scenarios where a AAA interface is required. Additionally, it lists design goals and requirements for the communication between the HA and the AAA server and between the NAS and the AAA server needed in the split and integrated scenarios. Requirements are listed in case either IPsec or RFC 4285 [4] is used for Mobile IPv6 authentication.
この文書では、AAAインタフェースが必要とされるさまざまなシナリオについて説明します。さらに、それはHAとAAAサーバ間およびNASと分割と統合シナリオで必要なAAAサーバ間の通信のための設計目標と要件を示します。要件は、ケースIPSecまたはRFC 4285のいずれかに記載されている[4]はモバイルIPv6認証に使用されます。
This document only describes requirements, goals, and scenarios. It does not provide solutions.
この文書では、唯一の要件、目標、およびシナリオについて説明します。これは、ソリューションを提供していません。
Notice that this document builds on the security model of the AAA infrastructure. As such, the end host/user shares credentials with the home AAA server and the communication between the AAA server and the AAA client may be protected. If the AAA server and the AAA client are not part of the same administrative domain, then some sort of contractual relationship between the involved administrative domains is typically in place in the form of roaming agreements.
このドキュメントは、AAAインフラストラクチャのセキュリティモデルに基づいて構築されることに注意してください。そのように、ホームAAAサーバとAAAサーバとAAAクライアント間の通信で、エンドホスト/ユーザー共有の資格情報は保護されていてもよいです。 AAAサーバおよびAAAクライアントが同じ管理ドメインの一部でない場合は、関係する管理ドメイン間の契約関係のいくつかの並べ替えは、ローミング契約の形で所定の位置にあるのが典型的です。
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 RFC 2119 [5], with the qualification that, unless otherwise stated, these words apply to the design of the AAA protocol extension, not its implementation or its usage.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります特に明記しない限り、これらの単語は、AAAプロトコル拡張の設計ではなく、その実装またはその使用に適用資格で、RFC 2119 [5]で説明されるように解釈されます。
The following terms are extracted from [2].
以下の用語は[2]から抽出されます。
o Access Service Authorizer (ASA). A network operator that authenticates a Mobile Node and establishes the Mobile Node's authorization to receive Internet service.
Oアクセスサービスオーソライザ（ASA）。モバイルノードを認証し、移動ノードの認証を確立し、ネットワークオペレータは、インターネットサービスを受信します。
o Access Service Provider (ASP). A network operator that provides direct IP packet forwarding to and from the end host.
Oアクセス・サービス・プロバイダ（ASP）。およびエンドホストから直接IPパケット転送を提供するネットワークオペレータ。
o Mobility Service Authorizer (MSA). A service provider that authorizes Mobile IPv6 service.
Oモビリティサービスオーソライザ（MSA）。モバイルIPv6サービスを認可サービスプロバイダ。
o Mobility Service Provider (MSP). A service provider that provides Mobile IPv6 service. In order to obtain such service, the Mobile Node must be authenticated and prove authorization to obtain the service.
Oモビリティサービスプロバイダー（MSP）。モバイルIPv6サービスを提供するサービスプロバイダ。そのようなサービスを得るためには、モバイルノードが認証され、サービスを取得する権限を証明する必要があります。
Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are provisioned with a set of configuration parameters -- namely, the Home Address and the Home Agent Address, in order to accomplish a home registration. Moreover, MNs and Home Agents (HAs) must share the cryptographic material needed in order to set up IPsec security associations to protect Mobile IPv6 signaling (e.g., shared keys or certificates). This is referred as the bootstrapping problem: as described in [2], the AAA infrastructure can be used as the central element to enable dynamic Mobile IPv6 bootstrapping. In this case, the AAA infrastructure can be exploited to offload the end host's authentication to the AAA server as well as to deliver the necessary configuration parameters to the visited network (e.g., Home Agent address as specified in [6]).
ホーム登録を達成するために、すなわち、ホームアドレスとホームエージェントアドレス - モバイルIPv6の仕様では、[1]の構成パラメータのセットでプロビジョニングされているモバイルノード（MNの）ことが必要です。また、MNのホームエージェント（HAS）が（例えば、共有鍵または証明書）モバイルIPv6シグナリングを保護するためにIPsecセキュリティアソシエーションを設定するために必要な暗号化材料を共有しなければなりません。これは、ブートストラップ問題と呼ばれる。に記載されているように[2]、AAAインフラストラクチャは、動的モバイルIPv6ブートストラップを可能にするために中心的な要素として使用することができます。この場合には、AAAインフラストラクチャは、AAAサーバへのエンドホストの認証をオフロードするだけでなく、訪問先ネットワーク（例えば、ホーム・エージェントは、[6]で指定されるようにアドレス）に必要な構成パラメータを配信するために利用することができます。
Moreover, in case Mobile IPv6 is a service offered by a Mobility Service Provider (MSP), all protocol operations (e.g., home registrations) may need to be explicitly authorized and monitored (e.g., for accounting purposes). This can be accomplished relying on the AAA infrastructure of the Mobility Service Authorizer (MSA) that stores user profiles and credentials.
また、モバイルIPv6は、モビリティサービスプロバイダー（MSP）によって提供されるサービスである場合には、すべてのプロトコルの操作（例えば、自宅の登録は）（会計目的のために、例えば）を明示的に許可して監視する必要があるかもしれません。これは、ユーザープロファイルと資格情報を保存するモビリティサービスオーソライザ（MSA）のAAAインフラストラクチャに頼る達成することができます。
This section describes some bootstrapping scenarios in which communication between the AAA infrastructure of the Mobility Service Provider and the Home Agent is needed. The need of MIPv6-aware communication between the AAA server and the Network Access Server (NAS) is also described. The purpose of this section is only to explain the situation where bootstrapping is required. The actual mechanisms and additional details are specified elsewhere or are left for future work (see, e.g., [2], [3], and [6]).
このセクションでは、モビリティサービスプロバイダとホームエージェントのAAAインフラストラクチャ間の通信が必要とされるいくつかのブートストラップのシナリオを説明します。 AAAサーバとネットワーク・アクセス・サーバ（NAS）の間のMIPv6対応の通信の必要性も記載されています。このセクションの目的は、ブートストラップが必要とされる状況を説明することだけです。実際のメカニズムと追加の詳細は、他で指定され又は（参照例えば、[2]、[3]、[6]）は、将来の仕事のために残されています。
In the split scenario [3], there is the assumption that the mobility service and network access service are not provided by the same administrative entity. This implies that the mobility service is authorized by the MSA that is a different entity from the ASA.
分割シナリオでは、[3]、モビリティサービスおよびネットワーク・アクセス・サービスが同じ管理エンティティによって提供されていないという仮定があります。これは、モビリティサービスはASAは異なる実体であるMSAによって承認されていることを意味します。
In this scenario, the Mobile Node discovers the Home Agent Address using the Domain Name Service (DNS). It queries the address based on the Home Agent name or by service name. In the former case, the Mobile Node is configured with the Fully Qualified Domain Name (FDQN) of the Home Agent. In the latter case, [3] defines a new service resource record (SRV RR).
このシナリオでは、モバイルノードは、ドメインネームサービス（DNS）を使用して、ホームエージェントのアドレスを発見します。これは、ホームエージェント名やサービス名でベースアドレスを照会します。前者の場合、モバイルノードは、ホームエージェントの完全修飾ドメイン名（FDQN）で構成されています。後者の場合には、[3]新しいサービスリソースレコード（SRV RRを）を定義します。
Then the Mobile Node performs an IKEv2 [7] exchange with the HA to set up IPsec Security Associations (SAs) to protect Mobile IPv6 signaling and to configure its Home Address (HoA). Mutual authentication for IKEv2 between Mobile Node and Home Agent can be done with or without use of the Extensible Authentication Protocol (EAP).
その後、モバイルノードは、モバイルIPv6シグナリングを保護するために、そのホームアドレス（HoA）を構成するためにIPsecセキュリティアソシエーション（SA）をセットアップするHAとのIKEv2 [7]の交換を行います。モバイルノードとホームエージェントの間のIKEv2のための相互認証して、または拡張認証プロトコル（EAP）を使用せずに行うことができます。
If EAP is used for authentication, the operator can choose any available EAP methods. Use of EAP with the AAA infrastructure allows the HA to check the validity of each MN's credentials with the AAA infrastructure, rather than having to maintain credentials for each MN itself. It also allows roaming in terms of Mobile IPv6 service where the MSP and MSA belong to different administrative domains. In this case, the HA in the MSP can check the validity of the credentials provided by the MN with the AAA infrastructure of MSA, receiving the relevant authorization information.
EAPは、認証に使用されている場合は、オペレータが使用可能な任意のEAP方式を選択することができます。 AAAインフラストラクチャとのEAPを使用すると、HAは、むしろ各MN自身の資格情報を維持することよりも、AAAインフラストラクチャと、各MNの資格情報の有効性を確認することができます。また、MSPおよびMSAは異なる管理ドメインに属しているモバイルIPv6サービスの面でローミングできます。この場合、MSPにおけるHAは、関連する認証情報を受信、MSAのAAAインフラストラクチャとMNによって提供された資格情報の有効性を確認することができます。
The Mobile Node may also want to update its FQDN in the DNS with the newly allocated Home Address. [3] recommends that the HA performs the DNS entry update on behalf of the Mobile Node. For that purpose, the Mobile Node indicates its FDQN in the IKEv2 exchange (in the IDi field in IKE_AUTH) and adds a DNS Update Option in the Binding Update message sent to the HA.
モバイルノードはまた、新たに割り当てられたホームアドレスとDNSでのFQDNを更新することをお勧めします。 [3] HAは、モバイルノードの代わりにDNSエントリの更新を行うことをお勧めします。その目的のために、モバイルノードは、（IKE_AUTHでのIDIフィールド内）のIKEv2交換そのFDQNを示し、HAに送信されたバインディング更新メッセージ内のDNSアップデートオプションを付加します。
When the Mobile Node uses a Home Agent belonging to a different administrative domain (MSP != MSA), the local HA may not share a security association with the home DNS server. In this case, [3] suggests that the home AAA server is responsible for the update. Thus, the HA should send to the home AAA server the (FDQN, HoA) pair.
モバイルノードが異なる管理ドメイン（MSP！= MSA）に属するホームエージェントを使用すると、ローカルHAは、ホームDNSサーバとのセキュリティアソシエーションを共有することはできません。この場合は、[3]ホームAAAサーバは、更新のために責任があることを示唆しています。したがって、HAはホームAAAサーバに（FDQN、HoAを）ペアを送信する必要があります。
In the integrated scenario, the assumption is that the Access Service Authorizer (ASA) is the same as the Mobility Service Authorizer (MSA). Further details of this type of a scenario are being worked on separately [6].
統合シナリオでは、仮定はアクセスサービスオーソライザ（ASA）はモビリティサービスオーソライザ（MSA）と同じであることです。このタイプのシナリオのさらなる詳細は、別々に働いている[6]。
The Home Agent can be assigned either in the Access Service Provider's network or in the separate network. In the former case, the MSP is the same entity as the ASP, whereas in the latter case the MSP and ASP are different entities.
ホームエージェントは、サービスプロバイダのネットワークまたは別のネットワークのいずれかに割り当てることができます。後者の場合、MSPとASPが異なるエンティティであるのに対し、前者の場合、MSPは、ASPと同じエンティティです。
In this scenario, the Mobile Node discovers the Home Agent Address using DHCPv6. If the user is authorized for Mobile IPv6 service, during the network access authentication the AAAH (the AAA server in the home network) sends the information about the assigned Home Agent to the NAS where the Mobile Node is currently attached. To request Home Agent data, the Mobile Node sends a DHCPv6 Information Request to the All_DHCP_Relay_Agents_and_Servers multicast address. With this request, the Mobile Node can specify if it wants a Home Agent provided by the visited domain (ASP/MSP) or by the home domain (ASA/MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS receives the DHCPv6 Information Request, it passes Home Agent information received from the AAAH server to the DHCP server, for instance using mechanisms defined in [6].
このシナリオでは、モバイルノードは、DHCPv6のを使用してホームエージェントのアドレスを発見します。ユーザーがモバイルIPv6サービスのために許可されている場合は、ネットワークアクセス認証の際にAAAH（ホームネットワーク内のAAAサーバ）は、モバイルノードが現在接続されているNASに割り当てられたホームエージェントに関する情報を送信します。ホームエージェントのデータを要求するには、モバイルノードはAll_DHCP_Relay_Agents_and_ServersマルチキャストアドレスへのDHCPv6情報要求を送信します。それは訪問先ドメイン（ASP / MSP）またはホームドメイン（ASA / MSA）が提供するホームエージェントを望んでいる場合は、この要求に、モバイルノードが指定することができます。両方の場合において、NASは、DHCPv6のリレーとして作用します。 NASは、DHCPv6の情報要求を受信すると、[6]で定義されたメカニズムを使用して、例えばDHCPサーバにAAAHサーバから受信したホームエージェント情報を渡します。
In case the Mobile Node cannot acquire Home Agent information via DHCPv6, it can try the default mechanism based on DNS described in [3]. After the Mobile Node has acquired the Home Agent information, the mechanisms used to bootstrap the HoA, the IPsec Security Association, and the authentication and authorization with the MSA are the same as described in the bootstrapping solution for the split scenario [3].
場合、モバイルノードは、DHCPv6のを経由してホームエージェント情報を取得することができない、それは[3]で説明DNSに基づいてデフォルトのメカニズムを試すことができます。モバイルノードがホームエージェント情報、HoAと、IPsecのセキュリティアソシエーションをブートストラップするために使用されるメカニズム、およびMSAとの認証および承認を取得した後、分割シナリオ[3]のためのブートストラップ溶液中で説明したものと同じです。
Section 4 raises the need to define extensions for the AAA protocol used between the AAA server of the MSA and the HA. The following sections list the goals for such an interface. This communication is needed for both the split and integrated scenarios.
セクション4は、MSAとHAのAAAサーバ間で使用されるAAAプロトコルの拡張を定義する必要性を上昇させます。次のセクションでは、このようなインターフェイスのための目標をリストアップ。この通信は、分割や統合シナリオの両方のために必要とされています。
G1.1 The communication between the AAAH server and the HA MUST reuse existing AAA security mechanisms with regard to authentication, replay, integrity, and confidentiality protection. These communication security mechanisms prevent a number of classical threats, including the alteration of exchanged data (e.g., Mobile IPv6 configuration parameters) and the installation of unauthorized state.
G1.1は、AAAHサーバとHAの間の通信には、認証、リプレイ、完全性、機密性保護に関する既存のAAAセキュリティ・メカニズムを再利用しなければなりません。これらの通信のセキュリティメカニズムは、交換されるデータの変化（例えば、モバイルIPv6設定パラメータ）と不正状態のインストールを含む古典的な脅威の数を防ぎます。
G2.1 The AAA-HA interface MUST allow the use of a Network Access Identifier (NAI) to identify the user.
G2.1は、AAA-HAインタフェースは、ネットワークアクセス識別子（NAI）の使用は、ユーザを識別することを可能にしなければなりません。
G2.2 The HA MUST be able to query the AAAH server to verify Mobile IPv6 service authorization for the Mobile Node.
G2.2は、HAは、モバイルノードのためのモバイルIPv6サービスの認可を確認するために、AAAHサーバを照会することができなければなりません。
G2.3 The AAAH server MAY assign explicit operational limitations and authorization restrictions on the HA (e.g., packet filters, QoS parameters).
G2.3は、AAAHサーバは、HA（例えば、パケットフィルタ、QoSパラメータ）に明示的な操作上の制限および権限の制限を割り当てることができます。
G2.4 The AAAH server MUST be able to send an authorization lifetime to the HA to limit Mobile IPv6 session duration for the MN.
G2.4は、AAAHサーバは、MNのためのモバイルIPv6セッションの継続時間を制限するために、HAへの許可の有効期間を送ることができなければなりません。
G2.5 The HA MUST be able to request that the AAAH server grant an extension of the authorization lifetime to the MN.
G2.5は、HAがAAAHサーバは、MNへの許可の有効期間の延長を許可することを要求することができなければなりません。
G2.6 The AAAH server MUST be able to force the HA to terminate an active Mobile IPv6 session for authorization policy reasons (e.g., credit exhaustion).
G2.6は、AAAHサーバ（例えば、クレジット枯渇）認可ポリシーの理由からアクティブモバイルIPv6セッションを終了するためにHAを強制することができなければなりません。
G2.7 The HA MUST be able to indicate to the AAAH server the IPv6 HoA that will be assigned to the MN.
G2.7は、HAは、MNに割り当てられますAAAHサーバのIPv6 HoAあてに知らせることができなければなりません。
G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6 HoA and MUST indicate that to the HA.
G2.8は、AAAHサーバは、IPv6のHoAを使用するには、MNを承認することができなければならないとHAにそれを示す必要があります。
G2.9 The AAAH server MUST be able to indicate to the HA whether or not the return routability test (HoT (Home Test) and HoTi (Home Test Init)) shall be permitted via the HA for a given MN.
G2.9は、AAAHサーバは、リターン・ルータビリティテスト（HOT（ホーム試験）とのHoTi（ホーム試験開始））は、所与のMNのHAを介して許可されなければならないか否かをHAに指示することができなければなりません。
G2.10 The AAAH server MUST be able to support different levels of Mobile IPv6 authorization. For example, the AAAH server may authorize the MN to use MIPv6 (as defined in [1]) or may authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6 [8].
AAAHサーバは、モバイルIPv6認証の異なるレベルをサポートできなければなりませんG2.10。例えば、AAAHサーバ（[1]で定義されるように）のMIPv6を使用するMNを許可することができる、またはデュアルスタックMIPv6のために割り当てられたIPv4のHoA [8]を利用するMNを許可することができます。
G2.11 The AAAH server MUST be able to indicate to the HA whether the bearer traffic for the MN needs to receive IPsec Encapsulating Security Payload (ESP) protection.
G2.11ザ・AAAHサーバは、MNのためのベアラトラフィックがIPsecのカプセル化セキュリティペイロード（ESP）の保護を受信する必要があるかどうかをHAに知らせることができなければなりません。
G2.12 The HA MUST be able to authenticate the MN through the AAAH server in case a pre-shared key is used in IKEv2 for user authentication. The exact procedure is part of the solution space.
G2.12ザ・HAは、事前共有鍵は、ユーザー認証のためのIKEv2で使用した場合のAAAHサーバを介してMNを認証することができなければなりません。正確な手順は、解空間の一部です。
G3.1 The AAA-HA interface MUST support the transfer of accounting records needed for service control and charging. These include (but may not be limited to): time of binding cache entry creation and deletion, octets sent and received by the Mobile Node in bi-directional tunneling, etc.
G3.1 AAA-HAインターフェースは、サービス制御し、充電に必要な会計記録の転送をサポートしなければなりません。これらは、（これらに限定されない場合があります）：キャッシュエントリの作成と削除、双方向トンネリングでは、モバイルノードによって送信され、受信オクテットなどと結合する時間を
G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through EAP authenticator.
G4.1は、AAA-HAインタフェースは、HAは、パススルーEAP認証器として作用することを可能にしなければなりません。
G4.2 The AAA-HA interface MUST support authentication based on the Mobility Message Authentication Options defined in [4].
G4.2は、AAA-HAインタフェースは、[4]で定義されたモビリティメッセージ認証オプションに基づいて認証をサポートしなければなりません。
G4.3 The AAAH server MUST be able to provide a MN-HA key (or data used for subsequent key derivation of the MN-HA key by the HA) to the HA if requested. Additional data, such as the Security Parameter Index (SPI) or lifetime parameters, are sent along with the keying material.
G4.3は、AAAHサーバは、要求された場合、HAに（HAによってMN-HAキーのその後の鍵導出するために使用されるか、またはデータ）MN-HAキーを提供できなければなりません。そのようなセキュリティパラメータインデックス（SPI）または寿命パラメータなどの追加データは、鍵素材と一緒に送信されます。
G4.4 The HA supporting the Authentication Protocol MUST be able to request that the AAAH server authenticate the MN with the value in the MN-AAA Mobility Message Authentication Option.
G4.4 HAは、認証プロトコルをサポートするには、AAAHサーバは、MN-AAAモビリティメッセージ認証オプションに値をMNを認証することを要求することができなければなりません。
G4.5 The HA MUST include an identifier of the Mobile Node in the AAA transactions with the AAAH server.
G4.5 HAは、AAAHサーバとAAAトランザクションに移動ノードの識別子を含まなければなりません。
o The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN and the FQDN of the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN).
HAは、AAAHサーバにMNに割り当てられたホームアドレスを通信可能とMNのFQDN（例えば、AAAHサーバは、MNに代わってDNS更新を実行させるための）SHOULD O。
o The AAAH server SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. If the AAAH does not indicate to the HA if a MN is authorized to autoconfigure its address, the MN is not authorized.
O AAAHサーバは、MNがそのホームアドレスを自動設定することが許可された場合にHAに指示することができるべきです。 MNは、そのアドレスを自動設定することが許可されている場合AAAHがHAに示していない場合、MNが許可されていません。
In the integrated scenario, the AAA server provides the HA information to the NAS as part of the whole AAA operation for network access.
統合シナリオでは、AAAサーバは、ネットワークアクセスのための全体のAAA操作の一部としてNASにHAの情報を提供します。
G6.1 The AAAH server MUST be able to communicate the Home Agent Information (IP address or FQDN) to the NAS.
G6.1は、AAAHサーバは、NASにホームエージェント情報（IPアドレスまたはFQDN）を通信できる必要があります。
G6.2 The NAS MUST be able to notify the AAAH server if it supports the AAA extensions designed to receive the HA assignment information.
G6.2は、NASは、HAの割り当て情報を受信するように設計AAA拡張をサポートしている場合AAAHサーバに通知することができなければなりません。
G6.3 The ASP/MSP supporting the allocation of a Home Agent MUST be able to indicate to the MSA if it can allocate a Home Agent to the MN. Therefore, the NAS MUST be able to include a suggested HA address in the ASP in the AAA-NAS interaction.
それはMNにホームエージェントを割り当てることができれば、ホームエージェントの割り当てをサポートG6.3 ASP / MSPは、MSAに示すことができなければなりません。したがって、NASは、AAA-NAS相互作用にASPで提案HAアドレスを含むことができなければなりません。
G6.4 The AAA server of the MSA MUST be able to indicate to the NAS whether the MN is authorized to use a local Home Agent (i.e., a Home Agent in the ASP/MSP).
G6.4は、MSAのAAAサーバは、MNがローカルホームエージェント（ASP / MSPで、すなわち、ホームエージェント）を使用することを許可されているかどうかをNASに知らせることができなければなりません。
G6.5 The overall AAA solution for the integrated scenario MUST support the scenario where the AAA server of the ASA/MSA used for network access authentication is different from the AAA server used for mobility service authentication and authorization.
G6.5統合シナリオのための総合的なAAAソリューションは、ネットワークアクセス認証に使用するASA / MSAのAAAサーバは、モビリティサービスの認証および承認に使用AAAサーバと異なるシナリオをサポートしなければなりません。
As stated in Section 5.1, the AAA-HA interface must provide mutual authentication, integrity, and replay protection. Furthermore, if security parameters (e.g., IKE pre-shared key) are transferred through this interface, confidentiality is strongly recommended to be supported. In this case, the links between the HA and the AAA server of the MSA and between the NAS and the AAA server MUST be secure.
5.1節で述べたように、AAA-HAインターフェースは、相互認証、整合性、および再生保護を提供する必要があります。セキュリティパラメータ（例えば、IKEの事前共有鍵）は、このインタフェースを介して転送される場合、さらに、機密性が強く支持されることが推奨されます。この場合には、HA及びMSAのAAAサーバとNASとAAAサーバとの間の間のリンクは安全でなければなりません。
The authors would like to thank James Kempf, Alper Yegin, Vijay Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo, and Madjid Nakhjiri for their comments and feedback. Moreover, the authors would like to thank Hannes Tschofenig for his deep technical and editorial review of the document. Finally the authors would like to thank Kuntal Chowdhury who contributed by identifying the goals related to RFC 4285 authentication.
作者は彼らのコメントやフィードバックのためにジェームス・ケンプ、アルパースYegin、ビジェイDevarapalli、Basavarajパティル、ゴパルDommety、マルセロBagnulo、およびマジドNakhjiriに感謝したいと思います。また、作者は文書の彼の深い技術と編集レビューのためにハンネスTschofenigに感謝したいと思います。最後に著者は、RFC 4285の認証に関連する目標を識別することによって貢献Kuntalチョードリーに感謝したいと思います。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[2]パテル、A.およびG. Giaretta、RFC 4640、2006年9月 "ブートストラップモバイルIPv6（MIPv6の）のための問題文"。
[3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[3] Giaretta、G.、ケンプ、J.、およびV. Devarapalli、 "分割シナリオにおけるモバイルIPv6ブートストラップ"、RFC 5026、2007年10月。
[4] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[4]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のための認証プロトコル"、RFC 4285、2006年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Chowdhury, K., Ed., and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[6]チョードリー、K.、エド。、およびA. Yegin、 "統合シナリオのためのMIP6-ブートストラップ"、進歩、2008年4月の作業。
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[7]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[8] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[8]ソリマン、H.、エド。、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、2009年6月。
Authors' Addresses
著者のアドレス
Gerardo Giaretta Qualcomm 5775 Morehouse Drive San Diego, CA 92109 USA
ヘラルドGiarettaクアルコム5775モアハウスドライブサンディエゴ、CA 92109 USA
EMail: gerardo@qualcomm.com
メールアドレス：gerardo@qualcomm.com
Ivano Guardini Telecom Italia Lab via G. Reiss Romoli, 274 TORINO 10148 Italy
G.ライスRomoli、274 10148 TORINOイタリア経由イバノGuardiniテレコムイタリアラボ
EMail: ivano.guardini@telecomitalia.it
メールアドレス：ivano.guardini@telecomitalia.it
Elena Demaria Telecom Italia Lab via G. Reiss Romoli, 274 TORINO 10148 Italy
G.ライスRomoli、274 10148 TORINOイタリア経由エレナDEMARIAテレコムイタリアラボ
EMail: elena.demaria@telecomitalia.it
メールアドレス：elena.demaria@telecomitalia.it
Julien Bournelle Orange Labs
ジュリアンBournelleオレンジ研究所
EMail: julien.bournelle@gmail.com
メールアドレス：julien.bournelle@gmail.com
Rafa Marin Lopez University of Murcia 30071 Murcia Spain
ムルシア30071ムルシア、スペインのラファ・マリン・ロペス大学
EMail: rafa@dif.um.es
メールアドレス：rafa@dif.um.es