Network Working Group C. Perkins
Request for Comments: 3957 Nokia Research Center
Category: Standards Track P. Calhoun
Airespace
March 2005
Authentication, Authorization, and Accounting (AAA)
Registration Keys for Mobile IPv4
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent.
RADIUSやDIAMETERなどの認証、認可、アカウンティング（AAA）サーバは、ダイヤルアップコンピュータの認証および認可サービスを提供するために、インターネット内で使用して、今日あります。 IPv4のモバイルIPは、モバイルノードとそのホームエージェントとの間の強力な認証が必要です。場合は、移動ノードを共有し、ホームAAAサーバとAAAセキュリティアソシエーション、しかし、モバイルノードとそのホームエージェントとの間に、そして再びモバイルノードと外国人の間で派生モビリティセキュリティアソシエーションを作成するために、そのAAAセキュリティアソシエーションを使用することが可能ですエージェントは現在、モバイルノードへの接続性を提供しています。この文書では、モバイルノードとそのホームエージェントとの間、および/または移動ノードと外部エージェント間のモビリティセキュリティアソシエーションを作成するために使用することができるモバイルIP登録メッセージに拡張子を指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operations with Key Generation Nonce Extensions. . 5
4. Mobility Security Associations . . . . . . . . . . . . . . . . 7
5. Key Generation Nonce Creation and Key Derivation . . . . . . . 8
6. Key Generation Extensions. . . . . . . . . . . . . . . . . . . 9
6.1. Generalized MN-FA Key Generation Nonce Request Extension 10
6.2. Generalized MN-FA Key Generation Nonce Reply Extension . 11
6.3. Generalized MN-HA Key Generation Nonce Request Extension 13
6.4. Generalized MN-HA Key Generation Nonce Reply Extension . 14
7. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. AAA Infrastructure. . . . . . . . . . . . . . . . . . . . . 20
B. Message Flow for Requesting and Receiving Registration Keys 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
AAA servers, such as RADIUS [11] and DIAMETER [12], are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be valuable for mobile nodes using Mobile IP for IPv4 [1], when the nodes are attempting to connect to foreign domains with AAA servers. In this document Mobile IP for IPv4 is called "Mobile IPv4" or just "Mobile IP" for short, since no confusion with other versions is expected. Requirements for interactions between AAA and Mobile IP are outlined in RFC 2977 [13]; that document describes an infrastructure which enables AAA servers to authenticate and authorize network access requests from mobile nodes. See also appendix A. The Mobile IP Registration Request is considered to be a request for network access. It is then possible to augment the functionality of the Mobile IP mobility agents so that they can translate between Mobile IP registration messages and the messages used within the AAA infrastructure, as described in RFC 2977. Mobility agents and AAA servers that conform to the requirements of RFC 2977 can be considered as appropriate network entities to support the message types specified in this document. Please consult RFC 2977 [13] for further details.
このようRADIUS [11]とDIAMETER [12]としてAAAサーバは、ダイヤルアップコンピュータの認証および認可サービスを提供するために、インターネット内で使用して、今日あります。ノードはAAAサーバと外部ドメインに接続しようとしている場合、このようなサービスは、[1] IPv4のモバイルIPを用いた移動ノードのために貴重である可能性が高いです。他のバージョンとは混乱が予想されていないため、この文書では、IPv4のモバイルIPは、「モバイルIPv4」または略して単に「モバイルIP」と呼ばれています。 AAAとモバイルIPとの間の相互作用のための要件は、RFC 2977 [13]に概説されています。その文書には、モバイルノードからのネットワークアクセス要求を認証し、認証するためにAAAサーバを可能にするインフラストラクチャについて説明します。モバイルIP登録要求がネットワークにアクセスするための要求であると考えられている付録A.にも参照してください。彼らがモバイルIP登録メッセージとAAAインフラストラクチャ内で使用されるメッセージ間の変換ができるようにRFCで説明したように、の要件に適合2977.モビリティエージェントとAAAサーバを、モバイルIPモビリティエージェントの機能を強化することが可能ですRFC 2977は、この文書で指定されたメッセージの種類をサポートするために、適切なネットワークエンティティとみなすことができます。さらに詳細については、RFC 2977 [13]を参照してください。
This specification makes use of a single AAA Security Association to create derivative Mobility Security Associations. A Mobility Security Association in this specification is a simplex connection that serves to authenticate MIPv4 control traffic between a MN and HA and/or a MN and FA. A Mobility Security Association is identified by the two end points, such as a MN IP address and a HA IP address, and a SPI. Two nodes may have one or more Mobility Security Associations established between each other; however, typically there is no reason to have more than one Mobility Security Association between two nodes.
この仕様は、デリバティブモビリティセキュリティアソシエーションを作成するために、単一のAAAセキュリティアソシエーションを使用しています。本明細書におけるモビリティセキュリティアソシエーションは、MNとHAおよび/またはMNとFAの間のMIPv4制御トラフィックを認証するのに役立つ単純な接続です。モビリティセキュリティアソシエーションは、MNのIPアドレスおよびHA IPアドレス、およびSPIなどの2つのエンドポイントによって識別されます。 2つのノードが互いの間で確立された1つ以上のモビリティセキュリティアソシエーションを有していてもよいです。しかし、一般的に2つのノード間に複数のモビリティセキュリティアソシエーションを持っている理由はありません。
This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the MN and FA and/or MN and HA based on the AAA Security Association between the MN and AAA server. These new Mobility Security Associations may then be used to calculate the Authentication Data needed by authentication extensions used in Mobile IP control messages.
この文書では、MNとAAAサーバの間でAAAセキュリティアソシエーションに基づいてMNとFAおよび/またはMNとHAの間のモビリティセキュリティアソシエーションを作成するために使用することができるモバイルIP登録メッセージへの拡張を指定します。これらの新しいモビリティセキュリティアソシエーションは、モバイルIP制御メッセージで使用される認証の拡張機能で必要な認証データを計算するのに使用することができます。
It is assumed that the security association between the mobile node and its AAA server has been appropriately configured so that the AAA server can provide key material to be used as the basis for the necessary Mobility Security Association(s) between the mobile node and its prospective mobility agents.
AAAサーバは、鍵材料を提供することができるようにモバイルノードとAAAサーバの間でセキュリティアソシエーションが適切にモバイルノードとその将来の間に必要なモビリティセキュリティアソシエーション（単数または複数）の基礎として使用されるように構成されているものとしますモビリティエージェント。
AAA servers typically use the Network Access Identifier (NAI) [2] to uniquely identify the mobile node; the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without having any home address. However, for Mobile IP to work, the mobile node is required to have a home address and a Mobility Security Association [1] with its home agent. When the Mobile IP Registration Reply packet is authenticated by the MN-AAA Authentication Extension [3], the mobile node can verify that the key material contained in the extensions were produced by the AAA server, and thus may be reliably used to create Mobility Security Associations with the home agent and/or the foreign agent.
AAAサーバは、典型的には、[2]一意モバイルノードを識別するためにネットワークアクセス識別子（NAI）を使用します。モバイルノードのホームアドレスは、その機能を提供することは必ずしも必要ではありません。したがって、モバイルノードが自身を認証することが可能であり、任意のホームアドレスを持たず、外部ドメインへの接続を許可します。しかし、モバイルIPが機能するには、モバイルノードはホームアドレスとそのホームエージェントとの移動性セキュリティ協会[1]を有することが要求されます。モバイルIP登録応答パケットがMN-AAA認証拡張[3]によって認証された場合、モバイルノードは、拡張機能に含まれる鍵材料はAAAサーバによって生成されたことを確認することができ、確実モビリティセキュリティを作成するために使用することができますホームエージェントおよび/または外部エージェントとの関連付け。
It is also assumed that the AAA entities involved (i.e., the AAAH, AAAL, and the AAA interface features of the foreign agents and home agents) all have means outside of the scope of this document for exchanging keys. The extensions within this document are intended to work with any AAA protocol suite that allows for such key exchange, as long as it satisfies the requirements specified in RFC 2977 [13]. One such AAA protocol is defined within the Diameter framework [14].
また、関与するAAAエンティティ（すなわち、AAAH、AAAL、及びフォーリンエージェントとホームエージェントのAAAインタフェース機能）すべてのキーを交換するため、この文書の範囲外の手段を有していることが想定されます。本文書内の拡張は、それがRFC 2977 [13]で指定された要件を満たしている限り、そのような鍵交換を可能にする任意のAAAプロトコルスイートで動作するように意図されています。そのようなAAAプロトコルは直径フレームワーク[14]内で定義されています。
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 [4].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[4]で説明されるように解釈されます。
AAA Authentication, Authorization, and Accounting (see [10]).
AAA認証、許可、アカウンティング（[10]参照）。
AAA entity A network node processing AAA messages according to the requirements for AAA protocols (see [10]).
AAAエンティティネットワークノード処理AAAメッセージAAAプロトコルの要件に従って（[10]参照）。
AAA Security Association A security association between a AAA entity and another node needing the services of that AAA entity. In this document all AAA Security Associations are between a mobile node and its home AAA server (AAAH). A mobile node's AAA Security Association with its home AAA server (AAAH) may be based either on the mobile node's IP address or on its NAI [2]. The key is referred to as "AAA-key" in this specification.
AAAセキュリティアソシエーションAAAエンティティとそのAAAエンティティのサービスを必要とする別のノード間のセキュリティアソシエーション。本書では、すべてのAAAセキュリティアソシエーションは、モバイルノードとそのホームAAAサーバ（AAAH）の間にあります。そのホームAAAサーバ（AAAH）とモバイルノードのAAAセキュリティアソシエーションは、モバイルノードのIPアドレスまたはそのNAIのいずれかに基づいてすることができる[2]。キーは、この明細書では「AAA-キー」と呼ばれています。
Key A number, kept secret. Only nodes in possession of the key have any hope of using the security transform to obtain correct results.
キー数は、秘密にしておきます。キーの所持で唯一のノードはセキュリティが正しい結果を得るために変換を使用してのいずれかの希望を持っています。
Key Generation Nonce Nonce data used for the purpose of creating a key.
キーを作成する目的のために使用されるキー生成ナンスナンスデータ。
Mobility Security Association A Mobility Security Association is a simplex connection that applies security services to RFC 3344 MIPv4 control traffic between a MN and HA (or MN and FA) using RFC 3344 Authentication Extensions. A Mobility Security Association is uniquely identified by the peer source and destination IP addresses and an SPI. Two nodes may have one or more Mobility Security Associations; however, typically there is no reason to have more than one Mobility Security Association between two nodes, except as a transient condition during re-keying events.
モビリティセキュリティアソシエーションAモビリティセキュリティアソシエーションは、RFC 3344個の認証拡張機能を使用してMNとHA（またはMNとFA）との間でRFC 3344のMIPv4制御トラフィックにセキュリティサービスを適用する単純な接続です。モビリティセキュリティアソシエーションを一意ピア送信元と送信先のIPアドレスおよびSPIによって識別されます。 2つのノードが一つ以上のモビリティセキュリティアソシエーションを有していてもよいです。しかし、一般的に再キーイングイベント時の過渡状態などを除いて、2つのノード間で複数のモビリティセキュリティアソシエーションを持っている理由はありません。
Registration Key A key used in the MN-FA or MN-HA Mobility Security Association. A registration key is typically only used once or a very few times, and only for the purposes of verifying a small volume of Authentication data.
登録キーMN-FAまたはMN-HAモビリティセキュリティアソシエーションに使用するキー。登録キーは、通常、一度だけか、非常に数回、そして唯一の認証データの少量を検証する目的で使用されています。
Security Algorithm A set of rules for using input data and a secret key for producing data for use in security protocols.
セキュリティアルゴリズムの入力データとセキュリティプロトコルで使用するためのデータを生成するための秘密鍵を使用するためのルールのセット。
SPI Security Parameters Index. The SPI is an arbitrary 32-bit value that assists in the identification of an AAA, IP, or Mobility Security Association.
SPIセキュリティパラメータインデックス。 SPIはAAA、IP、またはモビリティセキュリティアソシエーションの識別に役立つ任意の32ビット値です。
Other terminology is used as defined in the base Mobile IP specification [1]. Furthermore, in order to simplify the discussion, we have used the word "Extension" instead of "Subtype of the Generalized Extension" in many cases. So, for instance, instead of using the phrase "The MN-FA Key Generation Nonce From AAA Subtype of the Generalized MN-FA Key Generation Nonce Reply Extension", we would instead use the phrase "The MN-FA Key Generation Nonce From AAA Extension".
ベースのモバイルIP仕様[1]で定義されるように他の用語が使用されます。さらに、議論を簡単にするために、我々は多くの場合、単語「拡張」の代わりに「一般化拡張のサブタイプ」を使用していました。だから、例えば、代わりにフレーズ使用して、我々は代わりに、フレーズ「AAAからMN-FAキー生成ナンスを使用することになり、「一般化MN-FAキー生成ナンスのAAAサブタイプからMN-FAキー生成ナンスを拡張返信」拡張"。
When a mobile node depends on an AAA infrastructure to obtain authorization for network connectivity and Mobile IP registration, it may lack any pre-existing Mobility Security Associations with either its home agent, or the foreign agent controlling the access to the foreign network. The extensions defined in this document allow a AAA entity to supply key material to mobile nodes to be used as the basis of its Mobility Security Association with mobile agents. The AAA entity that will act on these extensions is part of the AAA infrastructure, and is typically identified within the foreign domain by methods outside the scope of this specification (see appendix A).
モバイルノードは、ネットワーク接続とモバイルIP登録の承認を得るために、AAAインフラストラクチャに依存している場合、それはそのホームエージェント、または外部エージェントのどちらかが外部ネットワークへのアクセスを制御して任意の既存のモビリティセキュリティアソシエーションを欠いている可能性があります。この文書で定義された拡張は、AAAエンティティがモバイルエージェントとの移動性セキュリティ結合の基礎として使用されるように、モバイルノードにキーマテリアルを供給することができます。これらの拡張に作用するAAAエンティティは、AAAインフラストラクチャの一部であり、典型的には（付録A参照）は、この明細書の範囲外の方法により外部ドメイン内で同定されています。
The key material may be requested by the mobile node in new extensions (defined below) to Mobile IP Registration Request messages, and supplied to the mobile node in extensions to the Mobile IP Registration Reply messages. Alternatively, the AAA server MAY provide unsolicited key material via mobility agents to mobile nodes; the mobile node MUST then calculate new keys and update or create its relevant Mobility Security Association. The method by which key material is supplied to the mobility agents themselves is out of scope for this document, and would depend on the particular details of the security architecture for the AAA servers in the foreign and home domains (see RFC 2977 and appendix A). For the purposes of this document, we assume that there is a suitable AAA infrastructure available to the home and foreign agents, and that the mobile node does have an AAA Security Association with at least one AAA server in its home domain.
鍵材料は、モバイルIP登録要求メッセージを（以下に定義）新しい拡張で移動ノードによって要求され、モバイルIP登録応答メッセージに対する拡張でモバイルノードに供給することができます。代替的に、AAAサーバは、モバイルノードにモビリティエージェントを介して迷惑鍵材料を提供するかもしれません。モバイルノードは、新しいキーと更新を計算したり、その関連モビリティセキュリティアソシエーションを作成する必要があります。キー材料は自身がこのドキュメントの範囲外である、と外国と家庭のドメインのAAAサーバのセキュリティアーキテクチャの特定の詳細に依存するモビリティエージェントに供給される方法（RFC 2977および付録Aを参照してください） 。このドキュメントの目的のために、私たちはそこに家と外国人のエージェントが利用可能な、適切なAAAインフラストラクチャであり、モバイルノードがそのホームドメイン内の少なくとも1台のAAAサーバでAAAセキュリティアソシエーションを持っていることと仮定します。
When a mobile node travels away from home, it may not have a Mobility Security Association with its home agent, perhaps because it does not yet have a home address [5]. The protocol and messages in this document are intended to facilitate the following operations which may occur between the mobile node, foreign agent, home agent, and AAA servers in the visited (local) domain (Authentication, Authorization and Accounting Local or AAAL) and in the home domain (Authentication, Authorization, and Accounting Home or AAAH). In the following sequence of messages, the only message flows specified in this document are the Registration Request between the mobile node and the foreign agent, and Registration Reply between the foreign agent and the mobile node. The other messages described here result from the presumed action of the AAA entities as described in RFC 2977. See also appendix B.
モバイルノードがホームから離れて移動するとき、それはまだホームアドレスを持っていないかもしれないので、そのホームエージェントとの移動性セキュリティ結合を持たないかもしれない[5]。この文書に記載されているプロトコルとメッセージが訪問（ローカル）ドメインのモバイルノード、外部エージェント、ホームエージェント、およびAAAサーバの間で発生することがあり、次の操作を容易にすることを意図している（認証、認可およびアカウンティングローカルまたはAAAL）とでホームドメイン（認証、認可、アカウンティングHomeまたはAAAH）。メッセージの次の順序で、メッセージのみがこの文書で指定されたフローは、外部エージェントとモバイルノードの間でモバイルノードと外部エージェント、および登録応答との間の登録要求です。また、Bの付録を参照してくださいRFC 2977.で説明したように、ここで説明する他のメッセージは、AAAエンティティの推定行動から生じます
1. If the mobile node does not have a Mobility Security Association with the foreign agent, it SHOULD include an MN-FA Key Generation Nonce Request extension (see Section 6.1) as part of its Registration Request that it sends to the Foreign Agent.
1.モバイルノードが外国人のエージェントとの移動性セキュリティ結合を持っていない場合、それは外部エージェントに送信し、その登録要求の一部として（6.1項を参照）MN-FAキー生成ナンス要求の拡張子を含めるべきです。
2. If the mobile node does not have a Mobility Security Association with the home agent, it MUST add an MN-HA Key Generation Nonce Request extension (see Section 6.3) as part of its Registration Request that it sends to the Foreign Agent.
モバイルノードがホームエージェントとモビリティセキュリティアソシエーションを持っていない場合2.、それは外部エージェントに送信し、その登録要求の一部として（6.3節を参照）MN-HAキー生成ナンス要求拡張子を追加しなければなりません。
3. If one or more AAA Key Generation Nonce Request extensions were added, the mobile node MUST add the MN-AAA Authentication extension to its Registration Request.
3.一つ以上のAAAキー生成ナンス要求拡張機能が追加された場合は、モバイルノードは、その登録要求にMN-AAA認証拡張を加えなければなりません。
4. By action of the foreign agent, which is presumed to be also a AAA entity, the mobile node's key requests and authentication data are transferred to the local AAA server (AAAL), typically after reformatting to fit into the appropriate AAA messages, which are out of scope for this document.
また、モバイルノードのキーを要求し、認証データをローカルAAAサーバ（AAAL）に転送され、AAAエンティティであると推定される外部エージェント、の作用により4、一般的に適切なAAAメッセージ、に収まるように再フォーマットした後どのこのドキュメントの範囲外です。
5. After the information within the MN-AAA Authentication extension is verified by the AAA server in the home domain (AAAH), it then also generates the key material that has been requested by the mobile node, for the necessary Mobility Security Associations.
5. MN-AAA認証拡張内の情報は、ホームドメイン（AAAH）でAAAサーバによって検証された後、それはその後も必要モビリティセキュリティアソシエーションのために、モバイルノードによって要求されたキーマテリアルを生成します。
6. The respective keys for the Mobility Security Associations are distributed to the Home Agent and Foreign Agent via the AAA protocol.
6.モビリティセキュリティアソシエーションのための各キーは、AAAプロトコルを介してホームエージェントと外部エージェントに配布されています。
7. The mobile node receives the Registration Reply message from the Foreign Agent.
7.モバイルノードは、外部エージェントからの登録応答メッセージを受信します。
8. If a MN-HA Key Generation Nonce Request From AAA extension is present in the Registration Request message, then the mobile node MUST create or update its Mobility Security Association with the Home Agent indicated in the corresponding Registration Reply, using the key computed from the key material in the MN-HA Key Generation Nonce From AAA extension. In this case, if no MN-HA Key Generation Nonce Reply extension is present, the mobile node MUST discard the Registration Reply.
8. AAAの拡張子からMN-HAキー生成ナンス要求が登録要求メッセージ中に存在している場合、移動ノードは、ホームエージェントとの移動性セキュリティ結合を作成または更新しなければならないから計算されたキーを使用して、該当する登録応答に示されていますAAAの拡張子から、MN-HAキー生成ナンスの重要な材料。何のMN-HAキー生成ナンス返信拡張子がない場合は、この場合、移動ノードは登録応答を捨てなければなりません。
9. Using its (perhaps newly created) Mobility Security Association with the home agent, the mobile node authenticates the Registration Reply message by checking the Authentication Data in the Mobile-Home Authentication extension. If the check fails, the MN MUST discard the Registration Reply and the new Mobility Security Association, reverting to the old Mobility Security Association with the home agent, if any.
9.ホームエージェントにその（おそらく、新しく作成された）モビリティセキュリティアソシエーションを使用して、モバイルノードは、モバイル・ホーム認証拡張に認証データをチェックすることにより、登録応答メッセージを認証します。チェックが失敗した場合、もしあれば、MNは、ホームエージェントに古いモビリティセキュリティアソシエーションに戻し、登録返答と新しいモビリティセキュリティアソシエーションを捨てなければなりません。
10. If the Registration Reply passes authentication and contains a MN-FA Key Generation Nonce From AAA extension (see section 6.2), the mobile node generates the registration key using the Key Generation Nonce provided, according to its AAA Security Association with the AAA. The resulting registration key is used to establish the mobile node's Mobility Security Association with its foreign agent, and is used to compute the authentication data used in the Mobile-Foreign authentication extension.
登録応答が認証を通過して、AAAの拡張子（セクション6.2を参照）から、MN-FAキー生成ナンスが含まれている場合10.は、モバイルノードは、AAAとのAAAセキュリティ協会によると、キー生成ナンスを提供して使用して登録キーを生成します。結果の登録キーは、その外国人のエージェントとモバイルノードのモビリティセキュリティアソシエーションを確立するために使用され、およびモバイル・外国認証拡張で使用される認証データを計算するために使用されます。
If verification of the Mobile-Foreign authentication extension
fails, and if the MN-FA Key Generation Nonce Reply extension was
not protected by another, valid authentication extension, the MN
MUST discard the new Mobility Security Association, reverting to
the old Mobility Security Association with the foreign agent, if
any.
Any registration reply containing the MN-HA Key Generation Nonce From AAA extension MUST also contain a subsequent Mobile Home Authentication extension, created using the generated MN-HA key. Similarly, a reply containing the MN-FA Key Generation Nonce From AAA extension MUST also contain a subsequent Mobile Foreign Authentication extension, created using the registration key.
AAAの拡張子から、MN-HAキー生成ナンスを含む任意の登録応答はまた、その後のモバイルホーム認証拡張が含まれて生成されたMN-HAキーを使用して作成しなければなりません。同様に、AAAの拡張子から、MN-FAキー生成ナンスを含む応答はまた、その後のモバイル外国の認証拡張を含まなければならない、登録キーを使用して作成しました。
Mobility Security Associations between Mobile IP entities (mobile nodes, home agents, foreign agents) contain both the necessary cryptographic key information and a way to identify the cryptographic transform that uses the key to produce the authentication information that is present in the Mobile-Home Authentication extension or the Mobile-Foreign Authentication extension. In order for the mobile node to make use of key material created by the AAA server, the mobile node also has to be able to identify and select the appropriate cryptographic transform that uses the key to produce the authentication.
モバイルIPエンティティ間のモビリティセキュリティアソシエーション（モバイルノード、ホームエージェント、外部エージェント）に必要な暗号鍵情報と暗号はそれがモバイル・ホーム認証に存在している認証情報を生成するためにキーを使用して変換する特定する方法の両方を含みます延長またはモバイル外国の認証拡張。 AAAサーバによって作成された鍵材料を利用するモバイルノードのために、モバイルノードはまた、それが認証を生成するために鍵を使用変換適切な暗号を同定し、選択することができなければなりません。
The transform identifiers are the same as those used in IPsec. They are tabulated in the list of Authentication Algorithms allowable as values for the "Attribute Type" (5) (i.e., "Authentication Algorithm"), one of the classifications in the tabulated Attribute Types for "IPsec Security Association Attributes". See http://www.iana.org/assignments/isakmp-registry for the full listing of all Attribute Types and other Attributes for IPsec Security Associations.
変換識別子は、IPsecで使用したものと同じです。彼らは、「属性タイプ」の値として許容される認証アルゴリズムのリストにまとめられている（5）（すなわち、「認証アルゴリズム」）、「IPsecのセキュリティアソシエーションの属性」のための集計属性タイプで分類の一つ。すべての属性タイプとIPsecセキュリティアソシエーションのための他の属性の完全なリストについてはhttp://www.iana.org/assignments/isakmp-registryを参照してください。
Mobility Security Associations shared between mobile nodes and home agents also require a replay protection method. The following table contains the supported replay detection methods.
モビリティセキュリティアソシエーションはまた、リプレイ保護方法を必要とするモバイルノードとホームエージェントの間で共有しました。次の表は、サポートされているリプレイ検出方法が含まれています。
Replay Method Name Reference
-------------- ------------ --------------
0,1 Reserved
2 Timestamps RFC 3344 [1]
3 Nonces RFC 3344 [1]
4-65535 Unallocated
This section contains the procedures followed in the creation of the Key Generation Nonce by AAA servers, and the key derivation procedures used by mobile nodes. Note that the AAA servers will also deliver the keys to the mobility agents (home agent, foreign agent) via the AAA protocol. AAA servers that follow these procedures will produce results that can be understood by mobile nodes. The mobility agents will faithfully transcribe the results into the appropriate Mobile IP extensions.
このセクションでは、AAAサーバ、およびモバイルノードによって使用される鍵導出手順でキー生成ナンスの作成に続く手順が含まれています。 AAAサーバはまた、AAAプロトコルを介してモビリティエージェント（ホームエージェント、外部エージェント）にキーをお届けすることに注意してください。これらの手順に従うAAAサーバは、モバイルノードによって理解することができる結果を生成します。モビリティエージェントは、忠実に適切なモバイルIP拡張に結果を転写します。
The following example uses HMAC-SHA1 [6]. All mobile nodes and mobility agents implementing Mobile IP [1] and implementing the extensions specified in this document MUST implement HMAC-SHA1 [1]. Other message authentication codes or keyed hash functions MAY also be used. The particular algorithm used is configured as part of the AAA Security Association between the MN and the AAAH server, which is in turn indexed by the AAA SPI.
次の例では、HMAC-SHA1を使用する[6]。すべてのモバイルノードと、この文書で指定された拡張子を[1]モバイルIPを実装し、実装するモビリティエージェントは、HMAC-SHA1を実装しなければならない[1]。他のメッセージ認証コードまたは鍵付きハッシュ関数を使用してもよいです。使用される特定のアルゴリズムは、AAA SPIによって索引付け順番にあるMNとAAAHサーバとの間のAAAセキュリティアソシエーションの一部として構成されています。
The following steps are performed on the AAAH server:
次の手順は、AAAHサーバ上で実行されます。
1. The AAA server identifies the mobile node. If the NAI field is present in the Registration Request, then the NAI is used as the mobile node identifier. Otherwise, the Home Address field of the Registration Request is used.
1. AAAサーバは、モバイルノードを識別する。 NAIフィールドは、登録要求に存在する場合、NAIは、モバイルノードの識別子として使用されます。そうでない場合は、登録要求のホームアドレスフィールドが使用されています。
2. The AAA server generates a random [7] value of at least 128 bits to be used as the Key Generation Nonce.
2. AAAサーバは、キー生成ナンスとして使用される少なくとも128ビットのランダム[7]の値を生成します。
3. The AAA server inserts the random value into the Key Generation Nonce Reply extension in the "Key Generation Nonce" field.
3. AAAサーバは、キー生成ナンスにランダムな値を挿入「キー生成ナンス」フィールドに拡張子を返信します。
The following steps are performed by the mobile node (here || represents concatenation):
以下の手順は、モバイルノード（ここで||は連結を表す）によって行われます。
key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || mobile node
identifier})
Here the Key Generation Nonce is from the extension in the Registration Reply, and the mobile node identifier is the MN's NAI, if present in the Registration Request, or the Home Address from the Registration Request otherwise.
ここでキー生成ナンスは、登録応答に内線からのものであり、登録要求、またはそれ以外の場合は登録要求からホームアドレスに存在する場合は、モバイルノード識別子は、MNのNAIです。
2. The mobile node creates the Mobility Security Association(s), using the resulting key and the other relevant information in the Key Generation Nonce Extension.
2.モバイルノードは、結果として、キーとキーの生成nonce拡張内の他の関連する情報を使用して、モビリティ、セキュリティ協会（複数可）を作成します。
The secret key used within the HMAC-SHA1 computation is indicated by the AAA Security Association indexed by the AAA SPI, which has been previously configured as the basis for the AAA Security Association between the mobile node and the AAA server creating the key material.
HMAC-SHA1の計算内で使用される秘密鍵は、以前にモバイルノードと鍵材料を作成AAAサーバの間でAAAセキュリティアソシエーションのベースとして構成されているAAA SPIによってインデックス付けAAAセキュリティアソシエーションによって示されます。
This section defines new Extensions to Mobile IP Registration Requests and Replies [1].
このセクションでは、モバイルIP登録要求と応答に新しい拡張機能を定義します[1]。
Figure 1 illustrates the Generalized MN-FA Key Generation Nonce Request Extension (MN-FA KeyGen Request for short).
図1は、一般化MN-FAキー生成ナンス要求拡張（略してMN-FA鍵生成要求）を示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Request Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Generalized Mobile IP MN-FA Key Generation Nonce Request Extension
図1：一般、モバイルIP MN-FAキー生成ナンス要求拡張
Type 40 (not skippable) (see [1] and section 8)
40（スキップ可能ではない）タイプ（[1]、セクション8を参照）
Subtype A number assigned to identify the way in which the MN-FA Key Generation Nonce Request Subtype Data is to be used when generating the registration key.
MN-FAキー生成ナンス要求サブタイプのデータが登録キーを生成する際に使用されるべき方法を識別するために割り当てられた番号をサブタイプです。
Length The 16-bit Length field indicates the length of the extension. It is equal to the number of bytes in the MN-FA Key Generation Nonce Request Subtype Data plus 4 (for the Mobile Node SPI field).
長さ16ビットの長さフィールドは、拡張の長さを示します。これは、（モバイルノードSPIフィールドの）MN-FAキー生成ナンス要求サブタイプデータと4バイトの数に等しいです。
Mobile Node SPI The Security Parameters Index that the mobile node will assign for the Mobility Security Association created for use with the registration key.
モバイルノードSPI [セキュリティパラメータインデックスモビリティセキュリティアソシエーションが登録キーで使用するために作成するために、モバイルノードが割り当てられますこと。
MN-FA Key Generation Nonce Request Subtype Data Data needed to carry out the creation of the registration key on behalf of the mobile node.
MN-FAキー生成ナンス要求サブタイプデータデータは、モバイルノードに代わって登録キーの作成を行うために必要な。
The MN-FA KeyGen Request defines a set of extensions, identified by subtype, which may be used by a mobile node in a Mobile IP Registration Request message to request that some other entity create a Registration Key for use by the mobile node with the mobile node's new foreign agent.
MN-FA鍵生成要求が他のエンティティは、モバイルとモバイルノードによって使用するための登録キーを作成することを要求するモバイルIP登録要求メッセージにおけるモバイルノードによって使用されてもよいサブタイプによって識別拡張機能のセットを定義しますノードの新しい外部エージェント。
This document defines the subtype 1 for the MN-FA Key Generation Nonce >From AAA Request (MN-FA AAA KeyGen Request for short). The MN-FA AAA KeyGen Request has a zero-length Subtype Data field and MUST appear in the Registration Request before the MN-AAA Authentication extension.
この文書では、AAA要求からMN-FAキー生成ナンス>（略してMN-FA AAA keygenの要求）のためのサブタイプ1を定義します。 MN-FA AAA keygenの要求は長さゼロのサブタイプ・データ・フィールドを持ち、MN-AAA認証拡張する前に登録要求に現れなければなりません。
The Generalized MN-FA Key Generation Nonce Reply extension (MN-FA KeyGen Reply for short) supplies keying material requested by the MN-FA KeyGen Request extension. Figure 2 illustrates the format of the Generalized MN-FA Key Generation Nonce Reply Extension.
一般MN-FAキー生成ナンス返信拡張（略してMN-FA keygenの返信）は、MN-FA keygenの要求拡張によって要求された鍵材料を供給します。図2は、一般化MN-FAキー生成ナンスエクステンション返信のフォーマットを示す図です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Reply Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Generalized Mobile IP MN-FA Key
Generation Nonce Reply Extension
Type 41 (not skippable) (see [1] and section 8)
41（スキップ可能ではない）タイプ（[1]、セクション8を参照）
Subtype A number assigned to identify the way in which the MN-FA Key Generation Nonce Reply Subtype Data is to be used to obtain the registration key.
サブタイプにおけるMN-FAキー生成ナンスの方法を識別するために割り当てられた番号は、サブタイプのデータが登録キーを取得するために使用される返信。
Length The 16-bit Length field is equal to the number of bytes in the MN-FA Key Generation Nonce Reply Subtype Data.
長さ16ビットの長さフィールドは、サブタイプデータ返信MN-FAキー生成ナンスのバイト数に等しいです。
MN-FA Key Generation Nonce Reply Subtype Data An encoded copy of the keying material, along with any other information needed by the recipient to create the designated Mobility Security Association.
MN-FAキー生成ナンスは、指定されたモビリティセキュリティアソシエーションを作成するために、受信者が必要とする他の情報と共に、キーイング材料のサブタイプ・データ・アンエンコードされたコピーを返信します。
For each subtype, the format of the MN-FA Key Generation Nonce Reply Subtype Data has to be separately defined according to the particular method required to set up the Mobility Security Association.
各サブタイプについて、MN-FAキー生成ナンスのフォーマットは、サブタイプ・データを個別モビリティセキュリティアソシエーションを設定するために必要な特定の方法に応じて定義する必要があります返信。
For the subtype defined in this document, the MN-FA Key Generation Nonce supplied in the data for a subtype of this extension may come as a result of a request which was sent using a subtype of the Generalized MN-FA Key Generation Nonce Request Extension. In such cases, the SPI to be used when employing the Mobility Security Association defined by the registration key is the same as given in the original request.
この文書で定義されたサブタイプのため、MN-FAキー生成ナンスは、一般化MN-FAキー生成ナンス要求拡張のサブタイプを使用して送信された要求の結果として来ることができるこの拡張のサブタイプのデータで供給しました。元の要求で与えられたような場合には、登録キーによって定義されたモビリティセキュリティアソシエーションを使用するときに使用するSPIは同じです。
Once the mobile node creates the Mobility Security Association with the foreign agent, by using the transform indexed by the AAA SPI, it stores that Mobility Security Association indexed by the FA SPI in its list of Mobile Security Associations.
モバイルノードが外国人のエージェントとモビリティセキュリティアソシエーションを作成すると、AAA SPIによってインデックス化変換を使用することで、モビリティ、セキュリティ協会は、モバイルセキュリティアソシエーションのリストにFA SPIによってインデックス付けすることを保存します。
If the foreign agent receives a Registration Reply that has no MN-FA Key Generation Nonce Reply extension, and if it has no existing Mobility Security Association with the mobile node, the foreign agent MAY change the Code value of the Registration Reply to MISSING_MN_FA (see section 7), effectively causing the registration to fail.
外国人のエージェントが何のMN-FAキー生成ナンス返信の拡張子を持っていない、そしてそれは、モバイルノードと既存のモビリティセキュリティアソシエーションを持っていない場合は、外国人のエージェントはMISSING_MN_FAへの登録応答のコード値を変更することが登録応答を受信した場合（参照セクション7）、効果的に登録が失敗する原因となります。
This document defines subtype 1 of the MN-FA KeyGen Reply for the MN-FA Key Generation Nonce From AAA extension (MN-FA AAA KeyGen Reply for short), shown in figure 3.
この文書では、図3に示したAAA拡張からMN-FAキー生成ナンス（略してMN-FA AAA鍵生成応答）のためのMN-FAキーゲン返信のサブタイプ1を定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MN-FA Key Generation Nonce From AAA
Subtype-Specific Data
lifetime This field indicates the duration of time (in seconds) for which the keying material used to create the registration key is valid.
一生このフィールドには、登録キーを作成するために使用される鍵素材が有効な時間（秒）の期間を示します。
AAA SPI A 32-bit opaque value, indicating the SPI that the mobile node must use to determine the transform to use for establishing the Mobility Security Association between the mobile node and its prospective foreign agent.
AAA SPI A 32ビットの不透明値、移動ノードは、移動ノードとその将来の外部エージェントとの間のモビリティセキュリティアソシエーションを確立するために使用する変換を決定するために使用しなければならないSPIを示します。
FA SPI The SPI for the Mobility Security Association to the FA that the mobile node creates using the Key Generation Nonce.
FAへのモビリティセキュリティ協会FA SPIザ・SPIモバイルノードは、鍵生成nonceを使用して作成すること。
Algorithm Identifier This field indicates the transform to be used (stored as part of the Mobility Security Association with the foreign agent, and selected from among the values in the "Authentication Algorithm" table cited in section 4), for future computations of the Mobile-Foreign Authentication Extension.
アルゴリズム識別子このフィールドは、（外部エージェントとモビリティセキュリティアソシエーションの一部として記憶され、セクション4で引用した「認証アルゴリズム」テーブル内の値の中から選択される）、Mobile-の将来の計算のために使用される変換を示し外国の認証拡張機能。
Key Generation Nonce A random [7] value of at least 128 bits.
少なくとも128ビットのキー生成ナンスAランダム[7]の値。
The MN-FA AAA KeyGen Reply extension MUST appear in the Registration Reply before the Mobile-Foreign Authentication extension.
MN-FA AAA keygenのは、拡張子がモバイル外国の認証拡張する前に登録応答に現れなければならない返信。
The Key Generation Nonce is provided by the AAA server for use by the mobile node in creating the registration key, which is used to secure future Mobile IP registrations with the same foreign agent.
キー生成ナンスは、同じ外国人のエージェントと将来のモバイルIP登録を固定するために使用される登録キーを作成するには、モバイルノードが使用するAAAサーバによって提供されます。
Figure 4 illustrates the Generalized MN-HA Key Generation Nonce Request Extension (MN-HA KeyGen Request for short).
図4は、一般化MN-HAキー生成ナンス要求拡張（略してMN-HA鍵生成要求）を示します。
Type 42 (not skippable) (see [1] and section 8)
42（スキップ可能ではない）タイプ（[1]、セクション8を参照）
Subtype a number assigned to identify the way in which the MN-HA Key Generation Nonce Request Subtype Data is to be used when generating the registration key.
MN-HAキー生成ナンス要求サブタイプのデータが登録キーを生成する際に使用されるべき方法を識別するために割り当てられた番号をサブタイプです。
Length The 16-bit Length field indicates the length of the extension. It is equal to the number of bytes in the MN-HA Key Generation Nonce Request.
長さ16ビットの長さフィールドは、拡張の長さを示します。これは、MN-HAキー生成ナンス要求のバイト数に等しいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Request Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Generalized Mobile IP MN-HA Key Generation Nonce Request Extension
図4：汎用モバイルIP MN-HAキー生成ナンス要求拡張
Subtype Data plus 4 (for the Mobile Node SPI field).
（モバイルノードSPIフィールドの）サブタイプ・データプラス4。
Mobile Node SPI The Security Parameters Index that the mobile node will assign for the Mobility Security Association created for use with the registration key.
モバイルノードSPI [セキュリティパラメータインデックスモビリティセキュリティアソシエーションが登録キーで使用するために作成するために、モバイルノードが割り当てられますこと。
MN-HA Key Generation Nonce Request Subtype Data Data needed to carry out the creation of the MN-HA key on behalf of the mobile node.
MN-HAキー生成ナンス要求サブタイプデータデータは、モバイルノードの代わりにMN-HAキーの作成を行うために必要な。
The MN-HA KeyGen Request Extension defines a set of extensions, identified by subtype, which may be used by a mobile node in a Mobile IP Registration Request message to request that some other entity create an MN-HA key for use by the mobile node with the mobile node's new home agent.
MN-HA鍵生成要求拡張は、いくつかの他のエンティティは、モバイルノードが使用するためのMN-HAキーを作成することを要求するモバイルIP登録要求メッセージにモバイルノードによって使用されてもよいサブタイプによって識別拡張機能のセットを定義しますモバイルノードの新しいホームエージェントと。
This document defines the subtype 1 for the MN-HA Key Generation Nonce from AAA Request (MN-HA AAA KeyGen Request for short). The MN-HA AAA KeyGen Request has a zero-length Subtype Data field and MUST appear in the Registration Request before the MN-AAA Authentication extension.
この文書では、AAA要求からMN-HAキー生成ナンス（略してMN-HA AAA鍵生成要求）のためのサブタイプ1を定義します。 MN-HA AAA keygenの要求は長さゼロのサブタイプ・データ・フィールドを持ち、MN-AAA認証拡張する前に登録要求に現れなければなりません。
The Generalized MN-HA Key Generation Nonce Reply extension (MN-HA KeyGen Reply for short) supplies keying material requested by the MN-HA KeyGen Request extension. Figure 5 illustrates the format of the Generalized MN-HA Key Generation Nonce Reply Extension.
一般MN-HAキー生成ナンス返信拡張（略してMN-HAキーゲン返信）MN-HA鍵生成要求の拡張によって要求された鍵材料を供給します。図5は、一般化MN-HAキー生成ナンスエクステンション返信のフォーマットを示す図です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Reply Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Generalized Mobile IP MN-HA Key
Generation Nonce Reply Extension
Type 43 (not skippable) (see [1] and section 8)
43（スキップ可能ではない）タイプ（[1]、セクション8を参照）
Subtype a number assigned to identify the way in which the MN-HA Key Generation Nonce Reply Subtype Data is to be used to obtain the MN-HA key.
MN-HAキー生成ナンスは、サブタイプ・データは、MN-HAキーを取得するために使用される返信する方法を識別するために割り当てられた番号をサブタイプです。
Length The 16-bit Length field indicates the length of the extension. It is equal to the number of bytes in the MN-HA Key Generation Nonce Reply Subtype Data plus 4 (for the Lifetime field).
長さ16ビットの長さフィールドは、拡張の長さを示します。これは、MN-HAキー生成ナンスは、サブタイプデータ+ 4（Lifetimeフィールド用）を返信のバイト数に等しいです。
Lifetime This field indicates the duration of time (in seconds) for which the MN-HA key is valid.
ライフタイムこのフィールドは、MN-HAキーが有効な時間（秒）の期間を示します。
MN-HA Key Generation Nonce Reply Subtype Data Data used to derive the MN-HA key, along with any other information needed by the mobile node to create the designated Mobility Security Association with the home agent.
MN-HAキー生成ナンスは、サブタイプデータデータがホームエージェントに指定されたモビリティセキュリティアソシエーションを作成するために、モバイルノードが必要とする他の情報と共に、MN-HAキーを導出するために使用返信。
For each subtype, the format of the MN-HA Key Generation Nonce Reply Subtype Data has to be separately defined according to the particular method required to set up the Mobility Security Association.
各サブタイプについて、MN-HAキー生成ナンスのフォーマットは、サブタイプ・データを個別モビリティセキュリティアソシエーションを設定するために必要な特定の方法に応じて定義する必要があります返信。
This document defines subtype 1 of the MN-HA KeyGen Reply for the MN-HA Key Generation Nonce From AAA extension (MN-HA AAA KeyGen Reply for short), shown in figure 6.
この文書では、図6に示したAAA拡張からMN-HAキー生成ナンス（略してMN-HA AAA鍵生成応答）のためのMN-HA鍵生成応答のサブタイプ1を定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Replay Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The MN-HA Key Generation Nonce From AAA
Subtype-Specific Data
AAA SPI A 32-bit opaque value, indicating the SPI that the mobile node must use to determine the transform to use for establishing the Mobility Security Association between the mobile node and its home agent.
AAA SPI A 32ビットの不透明値、モバイルノードは、モバイルノードとそのホームエージェントとの間のモビリティセキュリティアソシエーションを確立するために使用する変換を決定するために使用しなければならないことをSPIを示しています。
HA SPI The SPI for the Mobility Security Association to the HA that the mobile node creates using the Key Generation Nonce.
HAへのモビリティセキュリティアソシエーションのためのHA SPIザ・SPIモバイルノードは、鍵生成nonceを使用して作成すること。
Algorithm Identifier This field indicates the transform to be used for future computations of the Mobile-Home Authentication Extension (see section 4).
アルゴリズム識別子このフィールドは、（セクション4を参照）モバイルホーム認証拡張の将来の計算のために使用される変換を示しています。
Replay Method This field contains the replay method to be used for future Registration messages (see section 4).
リプレイ方法は、このフィールドは、将来の登録メッセージ（セクション4を参照）に使用する再生方法が含まれています。
Key Generation Nonce A random [7] value of at least 128 bits.
少なくとも128ビットのキー生成ナンスAランダム[7]の値。
The MN-HA AAA KeyGen Reply subtype-specific data is shown in figure 6. The Mobile Node calculates the MN-HA key using the Key Generation Nonce provided by the AAA server. The calculation proceeds by using the key shared between the mobile node and the AAA server that has previously been configured for securing all such communication requirements with the AAA server which will be contacted within the AAA infrastructure (see appendix A). The MN-HA key is intended for use by the mobile node to secure future Mobile IP registrations with its home agent. The MN-HA AAA KeyGen Reply extension MUST appear in the Registration Reply before the MN-HA Authentication extension.
MN-HA AAA鍵生成応答サブタイプ固有のデータは、モバイルノードがAAAサーバによって提供されるキー生成nonceを使用して、MN-HAキーを算出し、図6に示されています。モバイルノードと以前にAAAインフラストラクチャ内で接触するAAAサーバとのすべてのそのような通信要件を固定するように構成されたAAAサーバの間で共有鍵を用いて計算進む（付録A参照）。 MN-HAキーは、そのホームエージェントと将来のモバイルIP登録を確保するために、モバイルノードが使用するためのものです。 MN-HA AAA keygenの返信延長はMN-HA認証拡張する前に登録応答に現れなければなりません。
Once the mobile node creates the MN-HA Key, by using the transform specified in the AAA SPI, it stores the HA Security Information indexed by the HA SPI in its list of Mobile Security Associations. The mobile node uses the Identification field data from the Registration Reply as its initial synchronization data with the home agent.
モバイルノードは、モバイルセキュリティアソシエーションのリストにHA SPIによってインデックス化HAセキュリティ情報を格納し、AAA SPIに指定された変換を使用することにより、MN-HAキーを作成すると。モバイルノードは、ホームエージェントとの最初の同期データとして登録応答からの識別フィールドのデータを使用しています。
Each entry in the following table contains the name of the Code [1] value to be returned in a Registration Reply, the value for that Code, and the section in which the error is first mentioned in this specification.
次の表の各エントリは登録応答で返されるコード[1]の値の名前が含まれ、そのコード値、エラーが最初に本明細書に記載されているセクション。
Error Name Value Section
---------------------- ----- ---------
MISSING_MN_FA 107 6.2
This document defines 4 new extensions (see Section 6) taken from the (non-skippable) numbering space defined for Mobile IP registration extensions defined in RFC 3344 [1] as extended in RFC 2356 [8]. The values for these extensions are:
この文書では、[1] RFC 2356に拡張としてRFC 3344で定義されたモバイルIP登録の拡張のために定義された（スキップ不可）番号空間から取られた4つの新しい拡張機能（セクション6を参照）を定義する[8]。これらの拡張のための値は次のとおりです。
Name Value Section
--------------------- ------- ---------
MN-FA-KeyGen Request 40 6.1
MN-FA-KeyGen Reply 41 6.2
MN-HA-KeyGen Request 42 6.3
MN-HA-KeyGen Reply 43 6.4
IANA has created and will maintain a new registry for the KeyGen Request/Reply subtypes. The initial contents of the registry is a single entry for the subtypes defined in this document:
IANAは、作成しているとkeygenのリクエスト/リプライ・サブタイプのための新しいレジストリを維持します。レジストリの初期内容は、この文書で定義されたサブタイプのための単一のエントリです。
Name Value Section
----------------------------- ------- ---------
KeyGen Request/Reply from AAA 1 6
New subtypes for these two registries are assigned through Standards Action as defined in [9].
[9]で定義されたように、これらの2つのレジストリのための新しいサブタイプが標準化作用を介して割り当てられます。
IANA has assigned a code value for error MISSING_MN_FA, listed in section 7. This value has been taken from the space of error values conventionally associated with rejection by the foreign agent (i.e., 64-127).
IANAは、この値はセクション7に記載されている、エラーMISSING_MN_FAのコード値が割り当てられている従来の外部エージェントによって拒絶（すなわち、64-127）に関連付けられたエラー値の空間から取られています。
IANA has created and will maintain a namespace for the Replay Method Identifier. This specification makes use of 2 and 3; all other values other than zero (0) and (1) are available for assignment, pending review and approval by a Designated Expert [9].
IANAは、作成していると再生方法識別子の名前空間を維持します。この仕様は、2と3を使用しています。指定された専門家によるレビューおよび承認の保留中の他のすべてのゼロ以外の値（0）と（1）の割り当てのために利用可能である、[9]。
The extensions in this document are intended to provide the appropriate level of security for Mobile IP entities (mobile node, foreign agent, and home agent) to calculate the Authentication Data needed by authentication extensions used with Mobile IP registration messages. The Mobility Security Associations resulting from use of these extensions do not offer any higher level of security than what is already implicit in use of the AAA Security Association between the mobile node and the AAAH. In order to deny any adversary the luxury of unbounded time to analyze and break the secrecy of the AAA Security Association between the mobile node and the AAA server, that AAA Security Association MUST be refreshed periodically.
この文書に記載されている拡張機能は、モバイルIP登録メッセージで使用される認証の拡張機能で必要な認証データを計算するために、モバイルIPエンティティ（モバイルノード、外部エージェント、およびホームエージェント）のために適切なレベルのセキュリティを提供することを意図しています。これらの拡張機能の使用に起因するモビリティセキュリティアソシエーションはすでに移動ノードとAAAH間AAAセキュリティアソシエーションの使用に内在するものよりもセキュリティのいずれかのより高いレベルを提供していません。 AAAセキュリティ協会は定期的に更新しなければならないことを、分析し、移動ノードとAAAサーバの間でAAAセキュリティアソシエーションの秘密を破るためにあらゆる敵に無制限の時間の贅沢を否定するために。
The provisioning and refreshing of the AAA key in the MN and AAA server is outside the scope of this document.
プロビジョニングとMNとAAAサーバ内のAAAキーのリフレッシュは、この文書の範囲外です。
Since the Reply extensions defined in this specification only carry Key Generation Nonces, which are used to derive keys, they do not expose any data that could be used in an attack aimed at recovering the key shared between the mobile node and the AAA. The authors do not believe this specification introduces any new security vulnerability.
この仕様で定義された返信用の拡張機能は、キーのみを導出するために使用されるキー生成ナンスは、持ち運びので、移動ノードとAAAとの間で共有されるキーを回復を目的とした攻撃で使用できるすべてのデータを公開していません。著者は、この仕様は、新しいセキュリティの脆弱性を紹介するとは思いません。
Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG for their useful comments. Thanks especially to Tom Hiller who has contributed many textual improvements to later revisions of this document.
フレドリック・ヨハンソン、トム・ヒラー、そして彼らの有益なコメントのためのIESGのメンバーに感謝します。特に、このドキュメントの後の改正に多くのテキストの改善に貢献したトム・ヒラーに感謝します。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[2] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[3] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extension", RFC 3012, November 2000.
[3]パーキンス、C.とP.カルフーン、 "モバイルIPv4チャレンジ/レスポンス拡張"、RFC 3012、2000年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[5]カルフーン、P.とC.パーキンス、 "IPv4のモバイルIPネットワークアクセス識別子拡張"、RFC 2794、2000年3月。
[6] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[6] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[7]イーストレイク、D.、クロッカー、S.、およびJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[8] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[8]モンテネグロ、G.およびV.グプタ、 "モバイルIPのための日のSKIPファイアウォール越え"、RFC 2356、1998年6月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[10] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.
[10]ミットン、D.、St.Johns、M.、バークリー、S.、ネルソン、D.、パティル、B.、スティーブンス、M.、およびB.ヴォルフ、「認証、認可、およびアカウンティング：プロトコル評価」、RFC 3127、2001年6月。
[11] Rigney, C., Willens, S., Rubens, A., and A. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[11] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびA.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[12]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[13] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[13]ガラス、S.、ヒラー、T.、ジェイコブス、S.、およびC.パーキンス、 "モバイルIP認証、認可、およびアカウンティング要件"、RFC 2977、2000年10月。
[14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions", Work in Progress, February 2004.
[14]カルフーン、P.とC.パーキンス、 "DIAMETERモバイルIP拡張"、進歩、2004年2月に作業。
Appendix A. AAA Infrastructure
付録A. AAAインフラストラクチャ
In this appendix, we attempt to capture the main features of a basic model for operation of AAA servers that is assumed for understanding of the use of the Mobile IP registration extensions described in this document. This information has been adapted from the discussion in RFC 2977 [13].
この付録では、我々は、この文書で説明したモバイルIP登録エクステンションの使用を理解するために想定されるAAAサーバの動作のための基本モデルの主な特徴を捉えることを試みています。この情報は、RFC 2977 [13]での議論から適合されています。
Within the Internet, a mobile node belonging to one administrative domain (called the home domain) often needs to use resources provided by another administrative domain (called the foreign domain). A foreign agent that handles the mobile node's Registration Request is likely to require that the mobile node provide some credentials that can be authenticated before access to the resources is permitted. These credentials may be provided as part of the Mobile-AAA Authentication extension [3], relying on the existence of an AAA infrastructure such as is described in this section, and also described in RFC 2977 and RFC 3012 [3]. Such credentials are typically managed by entities within the mobile node's home domain. They may be also used for setting up secure communications with the mobile node and the foreign agent, or between the mobile node and its home agent if necessary.
インターネット内では、（ホームドメインと呼ばれる）1つの管理ドメインに属する移動ノードは、多くの場合、（外部ドメインと呼ばれる）、別の管理ドメインによって提供されるリソースを使用する必要があります。モバイルノードの登録要求を処理する外国人のエージェントは、モバイルノードがリソースへのアクセスが許可される前に認証することができますいくつかの資格情報を提供することを要求する可能性があります。これらの証明書は、RFC 2977及びRFC 3012に記載され、このセクションで説明されており、などのAAAインフラストラクチャの存在に依存する、モバイル-AAA認証拡張[3]の一部として提供することができる[3]。このような資格情報は、典型的には、移動ノードのホームドメイン内のエンティティによって管理されています。必要であれば、彼らはまた、モバイルノードと外国人のエージェントとの安全な通信を設定するための、またはモバイルノードとそのホームエージェントとの間で使用することができます。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | MN = mobile node
| MN |- -|- -| FA | | FA = foreign agent
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Figure 7: AAA Servers in Home and Local Domains
図7：ホームとローカルドメインのAAA Servers
The foreign agent often does not have direct access to the data needed to verify the credentials. Instead, the foreign agent is expected to consult an authority (typically in the same foreign domain) in order to request proof that the mobile node has acceptable credentials. Since the foreign agent and the local authority (AAAL) are part of the same administrative domain, they are expected to have established, or be able to establish for the necessary lifetime, a secure channel for the purposes of exchanging sensitive (access) information, and keeping it private from (at least) the visiting mobile node.
外国人のエージェントは、多くの場合、資格情報を確認するために必要なデータに直接アクセスすることはできません。代わりに、外国人のエージェントは、モバイルノードが許容できる資格情報を持っていることの証明を要求するために、（通常、同じ外部ドメイン内の）権威に相談することが期待されます。外国人のエージェントと地方自治体（AAAL）が同じ管理ドメインの一部であるので、それらが確立していることが予想、または必要な寿命のために確立することができている、敏感な（アクセス）情報を交換する目的のために安全なチャネル、そして訪問モバイルノード（少なくとも）からプライベートそれを維持。
The local authority (AAAL) itself may not have enough information stored locally to carry out the verification for the credentials of the mobile node. In contrast to the foreign agent, however, the AAAL is expected to be configured with enough information to negotiate the verification of mobile node credentials with its home domain. The home and foreign domains should be configured with sufficient IP Security Associations (i.e., IPsec) and access controls so that they can negotiate the authorization, and also enable the mobile node to acquire Mobility Security Associations with the mobility agents within the foreign domain. For the purposes of the key exchanges specified within this document, the authorization is expected to depend only upon secure authentication of the mobile node's credentials.
地方自治体（AAAL）自体は、モバイルノードの資格情報の検証を行うために、ローカルに保存された十分な情報を持っていないかもしれません。外国人のエージェントとは対照的に、しかし、AAALは、そのホームドメインとモバイルノードのクレデンシャルの検証を交渉するのに十分な情報で構成されることが予想されます。彼らは許可を交渉し、また、外部ドメイン内のモビリティエージェントとモビリティセキュリティアソシエーションを取得するために、モバイルノードを有効にすることができるように、家庭と外国のドメインは、十分なIPセキュリティアソシエーション（すなわち、IPsecの）およびアクセス制御を設定する必要があります。この文書内の指定されたキー交換の目的のためには、許可が唯一のモバイルノードの資格情報の安全な認証に依存することが予想されます。
Once the authorization has been obtained by the local authority, and the authority has notified the foreign agent about the successful negotiation, the foreign agent can deliver the Registration Reply to the mobile node along with the key material.
認可が地方自治体によって得られた、と当局が成功交渉について外国人のエージェントを通知した後は、外国人のエージェントは、キーマテリアルと一緒に、モバイルノードへの登録応答を提供することができます。
In figure 7, there might be many mobile nodes from many different Home Domains. Each Home Domain provides a AAAH that can check credentials originating from mobile nodes administered by that Home Domain. There is a security model implicit in figure 7, and it is crucial to identify the specific security associations assumed in the security model. These IP Security Associations are illustrated in figure 8, and are considered to be relatively long-lived security associations.
図7には、多くの異なったホームドメインからの多くのモバイルノードがあるかもしれません。各ホーム・ドメインは、そのホーム・ドメインによって管理モバイルノードから発信資格情報を確認することができますAAAHを提供します。そこセキュリティモデルは、図7に内在する、そしてセキュリティモデルで想定している特定のセキュリティアソシエーションを識別することが重要です。これらのIPセキュリティアソシエーションは、図8に示されているが、比較的長い寿命のセキュリティアソシエーションであると考えられています。
First, it is natural to assume that the mobile node has an AAA Security Association with the AAAH, since that is roughly what it means for the mobile node to belong to the home domain.
まず、それは、モバイルノードがホームドメインに属しているため、それが何を意味するのか大まかであることから、移動ノードがAAAHとAAAセキュリティアソシエーションを持っていると仮定することは自然です。
Second, from the model illustrated in figure 7 it is clear that AAAL and AAAH have to share an IP Security Association, because otherwise they could not rely on the authentication results, authorizations, nor even the accounting data which might be transacted between them. Requiring such bilateral IP Security Associations is, however, in the end not scalable; the AAA framework must provide for more scalable mechanisms, but the methods by which such a broker model is to be created are out of scope for this document. See RFC 2977 for more details.
第二に、図7に示すモデルから、そうでない場合は、認証結果、権限、またそれらの間で取引されるかもしれないとしても、会計データに頼ることができなかったので、AAALとAAAHは、IPセキュリティアソシエーションを共有する必要があることは明らかです。そのような二国間のIPセキュリティアソシエーションを要求することは終わりではないスケーラブルで、しかし、です。 AAAフレームワークは、よりスケーラブルなメカニズムを提供しなければならないが、そのようなブローカー・モデルが作成されることにより、方法は、この文書の範囲外です。詳細については、RFC 2977を参照してください。
Finally, from figure 7, it is clear that the foreign agent can naturally share an IP Security Association with the AAAL. This is necessary in order for the model to work because the foreign agent has to have a way to find out that it is permissible to allocate the local resources to the mobile node, and further to transmit any successful Registration Reply to the mobile node.
最後に、図7から、外国人のエージェントが当然AAALとIPセキュリティアソシエーションを共有できることは明らかです。これは、外国人のエージェントは、モバイルノードへの成功した登録応答を送信するために、モバイルノードにローカルリソースを割り当てることが許され、さらにあることを見つけるための方法を持っている必要があるため、モデルが機能するために必要です。
Figure 8 illustrates the IP Security Associations we understand from our proposed model. Note that there may be, by mutual agreement between AAAL and AAAH, a third party inserted between AAAL and AAAH to help them arbitrate secure transactions in a more scalable fashion. The broker model which has been designed to enable such third-party processing should not have any effect on the Mobile IP extensions specified in this document, and so no description is provided here; see RFC 2977 [13] for more details.
図8は、我々が提案したモデルから理解IPセキュリティアソシエーションを示しています。 AAALとAAAH、それらをよりスケーラブルでセキュアなトランザクションを調停支援するAAALとAAAH間に挿入された第三者との間の相互の合意により、があるかもしれないことに注意してください。 ;この文書で指定されたモバイルIP拡張上の任意の効果を持つべきではない、そのようなサードパーティ製の処理を可能にするために設計されていて、そう何の説明はここで提供されていないブローカー・モデル詳細は、RFC 2977 [13]を参照してください。
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
MN = mobile node | | | |
FA = foreign agent | FA | | MN |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
Figure 8: IP Security Associations
図8：IPセキュリティアソシエーション
Nodes in two separate administrative domains (for instance, AAAH and AAAL) often must take additional steps to verify the identity of their communication partners, or alternatively to guarantee the privacy of the data making up the communication. While these considerations lead to important security requirements, as mentioned above in the context of security between servers, we consider the exact choice of IP Security Associations between the AAA servers to be beyond the scope of this document. The choices are unlikely to depend upon Mobile IP, or any specific features of the general model illustrated in figure 7. On the other hand, the Mobility Security Associations needed between Mobile IP entities are of central importance in the design of the key derivation extensions in this document.
二つの別々の管理ドメイン（例えば、AAAHとAAAL）内のノードは、多くの場合、その通信相手の身元を確認するための追加手順を実行する必要があり、あるいは通信を構成するデータのプライバシーを保証します。サーバ間の安全保障の文脈で前述したように、これらの考慮事項は、重要なセキュリティ要件につながる一方で、我々は、AAAサーバ間のIPセキュリティアソシエーションの正確な選択は、このドキュメントの範囲外であると考えています。選択肢はモバイルIP、または一方、図7に示す一般的なモデルのいずれかの特定の機能に依存しにくい、モバイルIPエンティティ間で必要なモビリティセキュリティアソシエーションは、鍵導出拡張の設計における中心的に重要ですこのドキュメント。
One further detail deserves mention. The Mobility Security Association to be established between the mobile node and the foreign agent has to be communicated to the foreign agent as well as to the mobile node. The following requirements are placed on the mechanism used by the AAA infrastructure to effect key distribution:
一つの更なる詳細は、言及に値します。モバイルノードと外国人のエージェントとの間で確立されるモビリティ、セキュリティ協会が外国人のエージェントにだけでなく、モバイルノードに伝達する必要があります。以下の要件は、鍵配布を行うために、AAAインフラストラクチャによって使用されるメカニズムに配置されています。
- The AAAH must establish strong, fresh session keys.
- AAAHは、強力な、新鮮なセッションキーを確立する必要があります。
- The mechanism must maintain algorithm independence, allowing for the distribution of authentication algorithm identification along with the keys.
- 機構は、キーと一緒に認証アルゴリズム識別子の分布を可能にする、アルゴリズムの独立性を維持しなければなりません。
- The mechanism must include replay detection.
- メカニズムはリプレイ検出を含める必要があります。
- The mechanism must authenticate all parties, including the AAA servers and the FA and HA.
- メカニズムは、AAAサーバとFAとHAを含め、すべての関係者を認証する必要があります。
- The mechanism must provide for authorization of the client, FA, and HA.
- メカニズムは、クライアント、FA、およびHAの認可のために提供しなければなりません。
- The mechanism must not rely on plaintext passwords.
- メカニズムは平文パスワードに依存してはいけません。
- The mechanism must maintain confidentiality of session keys.
- メカニズムは、セッションキーの機密性を維持しなければなりません。
- The mechanism must uniquely name session keys.
- メカニズムは、一意のセッションキーに名前を付ける必要があります。
- The mechanism must be such that the compromise of a single FA and HA cannot compromise any other part of the system, including session keys and long-term keys
- 機構は、単一FAとHAの妥協がセッション鍵と長期キーを含むシステムの他の部分を、妥協することができないようなものでなければなりません
- The mechanism must bind key(s) to an appropriate context
- 機構は、適切なコンテキストにキー（複数可）を結合しなければなりません
- The mechanism must not expose the keys to entities other than the AAAH and FA (or HA in the case of key distribution to the HA).
- 機構（HA鍵配布の場合、またはHA）AAAHとFA以外のエンティティへの鍵を公開してはなりません。
The way that the key is distributed to the foreign agent (or home agent) is expected to be handled as part of the AAA protocol processing between the AAAH and AAAL, and the further AAA protocol processing between the AAAL and the foreign agent. Such processing is outside the scope of this document, but must satisfy the above requirements.
鍵は外部エージェント（又はホームエージェント）へ分配される方法は、AAAHとAAAL、およびAAALと外部エージェントとの間のさらなるAAAプロトコル処理の間のAAAプロトコル処理の一部として扱うことが期待されます。このような処理は、この文書の範囲外であるが、上記の要件を満たさなければなりません。
Appendix B. Message Flow for Requesting and Receiving Registration Keys
登録キーを要求し、受信するためには、付録B.メッセージフロー
In this section, we show message flows for requesting and receiving a registration key from the AAA infrastructure, described in section A. Challenge values, as specified in [3], might be added to the Advertisement and Registration messages for additional replay protection, but are not illustrated here.
このセクションでは、我々は、[3]、追加のリプレイ保護のための広告と登録メッセージに追加されることがありますに指定されたメッセージは、要求およびセクションA.チャレンジ値に記載のAAAインフラストラクチャから登録キーを受信するために流れて示すが、ここには示されていません。
Diagram 9 illustrates the message flow for the case when the mobile node explicitly requests keying material to create registration keys.
図9は、モバイルノードが明示的に登録キーを作成するために、キーイング材料を要求する場合のメッセージフローを示します。
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
|-- RReq+AAA Key Req.-->| |
| |--- RReq + AAA Key Req.--->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 9: Message Flows for Requesting and
Receiving Key Generation Nonce
In diagram 9, the following message flow is illustrated:
図9では、次のメッセージ・フローが示されています。
1. The foreign agent disseminates an Agent Advertisement. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram).
1.外国人のエージェントは、エージェント広告を発信しています。この広告は、モバイルノード（図示せず）からエージェント要請を受信した後に生成されていてもよいです。
2. The mobile node creates a Registration Request including the MN-HA AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as needed, along with an authorization-enabling authentication extension as required by Mobile IP [1].
必要に応じて、モバイルIPによって要求されるように前記モバイルノードは、許可イネーブル認証拡張とともに、MN-HA AAA鍵生成要求及び/又はMN-FA AAA鍵生成要求を含む登録要求を作成する[1]。
3. The foreign agent relays the Registration Request and/or Key Request(s) to its locally configured AAA Infrastructure (see appendix A), according to local policy.
3.外国人のエージェントは、ローカルポリシーに従って、そのローカルに設定されたAAAインフラストラクチャ（付録Aを参照）に登録要求および/またはキーリクエスト（複数可）を中継します。
4. The foreign agent receives a AAA Response with the appropriate indications for authorizing connectivity for the mobile node. Along with this AAA Response, the foreign agent may also receive key material by some secure method appropriate for communications between it and its local AAA infrastructure. At this point if the foreign agent has not relayed the Registration Request, it forwards it directly to the Home Agent and waits for a Registration Reply (not shown in the figure).
4.外部エージェントは、モバイルノードの接続を許可するための適切な指標とAAA応答を受信します。このAAAの応答と共に、外部エージェントはまた、そのローカルAAAインフラストラクチャとの間の通信に適したいくつかの安全な方法で鍵材料を受信することができます。外国人のエージェントが登録要求を中継していない場合は、この時点では、ホームエージェントに直接転送し、登録応答（図示せず）を待ちます。
5. The foreign agent relays the Registration Reply to the mobile node, along with the new AAA KeyGen Reply extensions to be used by the mobile node to establish Mobility Security Associations with the relevant mobility agents (foreign agent and/or home agent).
5.外国人のエージェントは、関連するモビリティエージェント（フォーリンエージェントおよび/またはホームエージェント）とモビリティセキュリティアソシエーションを確立するために、モバイルノードによって使用される新しいAAA keygenの返信拡張に伴い、モバイルノードへの登録応答を中継します。
Diagram 10 illustrates the message flow for the case when the mobile node receives unsolicited keying material from the AAA Infrastructure.
図10は、モバイルノードは、AAAインフラストラクチャから迷惑キーイング材料を受信した場合のメッセージフローを示します。
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
| ------ RReq --------->| |
| |------- RReq ------------->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 10: Message Flow for Receiving Unsolicited Key Generation Nonce
図10：迷惑な鍵生成nonceを受信するためのメッセージフロー
In diagram 10, the following message flow is illustrated:
図10においては、次のメッセージ・フローが示されています。
1. The foreign agent disseminates an Agent Advertisement. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram).
1.外国人のエージェントは、エージェント広告を発信しています。この広告は、モバイルノード（図示せず）からエージェント要請を受信した後に生成されていてもよいです。
2. The mobile node creates a Registration Request including an authorization-enabling authentication extension as required by Mobile IP [1].
前記モバイルノードは、モバイルIP [1]によって必要とされる許可イネーブル認証拡張を含む登録要求を作成します。
3. The foreign agent sends a AAA Request (possibly containing the Registration Request) to its locally configured AAA Infrastructure (see appendix A), according to local policy.
3.外部エージェントは、ローカルポリシーに従って、そのローカルに設定AAAインフラストラクチャにAAA要求を（おそらく登録要求を含む）（付録A参照）を送信します。
4. The foreign agent receives a AAA Response with the appropriate indications for authorizing connectivity for the mobile node. Along with this AAA Response, the foreign agent may also receive key material by some secure method appropriate for communications between it and its local AAA infrastructure. At this point, if the foreign agent has not relayed the Registration Request, it forwards it directly to the Home Agent and waits for a Registration Reply (not shown in the figure).
4.外部エージェントは、モバイルノードの接続を許可するための適切な指標とAAA応答を受信します。このAAAの応答と共に、外部エージェントはまた、そのローカルAAAインフラストラクチャとの間の通信に適したいくつかの安全な方法で鍵材料を受信することができます。外国人のエージェントが登録要求を中継していない場合は、この時点で、それはホームエージェントに直接転送し、登録応答（図示せず）を待ちます。
5. The foreign agent relays the Registration Reply to the mobile node, along with the new KeyGen Reply extensions to be used by the mobile node to establish Mobility Security Associations with the relevant mobility agents (foreign agent and/or home agent).
5.外国人のエージェントは、関連するモビリティエージェント（フォーリンエージェントおよび/またはホームエージェント）とモビリティセキュリティアソシエーションを確立するために、モバイルノードによって使用される新しい鍵生成返信拡張に伴い、モバイルノードへの登録応答を中継します。
Authors' Addresses
著者のアドレス
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキア・リサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1 650 625-2986 Fax: +1 650 625-2502 EMail: charles.perkins@nokia.com
電話：+1 650 625-2986ファックス：+1 650 625-2502 Eメール：charles.perkins@nokia.com
Pat R. Calhoun Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134 USA
パットR.カルフーンのAirespace、Inc.の110 Nortechパークウェイサンノゼ、CA 95134 USA
Phone: +1 408 635 2000 Fax: +1 408 635 2020 EMail: pcalhoun@airespace.com
電話：+1 408 635 2000ファックス：+1 408 635 2020 Eメール：pcalhoun@airespace.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。