[要約] RFC 3957は、Mobile IPv4における認証、認可、および会計（AAA）登録キーに関する規格です。このRFCの目的は、Mobile IPv4ネットワークでのセキュリティとアクセス制御を向上させるためのAAA登録キーの使用方法を定義することです。
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
モバイル IPv4 の認証、認可、およびアカウンティング (AAA) 登録キー
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) サーバーは、今日インターネット内でダイヤルアップ コンピュータに認証および認可サービスを提供するために使用されています。Mobile IP for IPv4 では、モバイル ノードとそのホーム エージェントの間に強力な認証が必要です。ただし、モバイル ノードがホーム 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 サーバーは、ダイヤルアップ コンピュータに認証および認可サービスを提供するために、今日インターネット内で使用されています。このようなサービスは、Mobile IP for IPv4 [1] を使用するモバイル ノードが AAA サーバーを使用して外部ドメインに接続しようとしている場合に役立つ可能性があります。他のバージョンとの混同が予想されないため、このドキュメントでは、Mobile IP for IPv4 を「Mobile IPv4」または略して単に「Mobile IP」と呼びます。AAA とモバイル IP の間の対話の要件は、RFC 2977 [13] に概説されています。この文書では、AAA サーバーがモバイル ノードからのネットワーク アクセス要求を認証および許可できるようにするインフラストラクチャについて説明しています。付録 A も参照してください。モバイル IP 登録要求は、ネットワーク アクセスの要求とみなされます。RFC 2977 で説明されているように、モバイル IP モビリティ エージェントの機能を拡張して、モバイル IP 登録メッセージと AAA インフラストラクチャ内で使用されるメッセージの間で変換できるようにすることができます。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 アドレスなどの 2 つのエンドポイントと SPI によって識別されます。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 サーバーは通常、ネットワーク アクセス識別子 (NAI) [2] を使用してモバイル ノードを一意に識別します。モバイル ノードのホーム アドレスは、その機能を提供するために必ずしも必要というわけではありません。したがって、モバイル ノードはホーム アドレスを持たずに自身を認証し、外部ドメインへの接続を許可されることが可能です。ただし、モバイル 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 プロトコルの 1 つは、Diameter フレームワーク内で定義されています [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].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。[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」と呼びます。
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.
Key Generation Nonce キーを作成する目的で使用される Nonce データ。
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.
モビリティ セキュリティ アソシエーション モビリティ セキュリティ アソシエーションは、RFC 3344 認証拡張機能を使用して、MN と HA (または MN と FA) 間の RFC 3344 MIPv4 制御トラフィックにセキュリティ サービスを適用するシンプレックス接続です。モビリティ セキュリティ アソシエーションは、ピアの送信元 IP アドレスと宛先 IP アドレス、および SPI によって一意に識別されます。2 つのノードに 1 つ以上のモビリティ セキュリティ アソシエーションがある場合があります。ただし、キー再生成イベント中の一時的な条件を除いて、通常は 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 Mobility Security Association で使用されるキー。登録キーは通常、1 回またはごく少数の回数だけ使用され、少量の認証データを検証する目的でのみ使用されます。
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] で定義されているように使用されます。さらに、議論を簡単にするために、多くの場合、「一般化された拡張のサブタイプ」ではなく「拡張」という言葉を使用しています。したがって、たとえば、「一般化された MN-FA 鍵生成ノンス応答拡張の AAA サブタイプからの 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 サーバは、モビリティ エージェントを介して未承諾の鍵マテリアルをモバイル ノードに提供してもよい（MAY）。その後、モバイル ノードは新しいキーを計算し、関連するモビリティ セキュリティ アソシエーションを更新または作成しなければなりません (MUST)。キー マテリアルがモビリティ エージェント自体に提供される方法は、このドキュメントの範囲外であり、外部ドメインおよびホーム ドメインの 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]。この文書のプロトコルとメッセージは、訪問先 (ローカル) ドメイン (認証、認可、およびアカウンティング ローカルまたは AAAL) およびローカル ドメイン内のモバイル ノード、外部エージェント、ホーム エージェント、および AAA サーバー間で発生する可能性のある次の操作を容易にすることを目的としています。ホーム ドメイン (認証、認可、およびアカウンティング ホームまたは AAAH)。以下の一連のメッセージでは、この文書で指定されているメッセージ フローは、モバイル ノードと外部エージェント間の登録要求、および外部エージェントとモバイル ノード間の登録応答のみです。ここで説明する他のメッセージは、RFC 2977 で説明されている AAA エンティティの推定アクションから生じます。付録 B も参照してください。
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. モバイルノードが外部エージェントとのモビリティセキュリティアソシエーションを持たない場合、モバイルノードは外部エージェントに送信する登録要求の一部として、MN-FA Key Generation Nonce Request 拡張（セクション 6.1 を参照）を含めるべきです（SHOULD）。
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. モバイル ノードがホーム エージェントとのモビリティ セキュリティ アソシエーションを持たない場合、モバイル ノードは、外部エージェントに送信する登録要求の一部として、MN-HA キー生成ノンス要求拡張 (セクション 6.3 を参照) を追加しなければなりません (MUST)。
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. 1 つ以上の AAA Key Generation Nonce Request 拡張が追加された場合、モバイル ノードは MN-AAA Authentication 拡張をその登録要求に追加しなければなりません (MUST)。
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.
4. AAA エンティティでもあると推定される外部エージェントのアクションにより、モバイル ノードのキー要求と認証データは、通常は適切な AAA メッセージに適合するように再フォーマットされた後、ローカル AAA サーバー (AAAL) に転送されます。この文書の範囲です。
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 キー生成ノンス要求が登録要求メッセージに存在する場合、モバイル ノードは、キーから計算されたキーを使用して、対応する登録応答で示されたホーム エージェントとのモビリティ セキュリティ アソシエーションを作成または更新しなければなりません (MUST)。MN-HA Key Generation Nonce From AAA 拡張のマテリアル。この場合、MN-HA Key Generation Nonce Reply拡張機能が存在しない場合、モバイルノードはRegistration Replyを破棄しなければなりません(MUST)。
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 は登録応答と新しいモビリティ セキュリティ アソシエーションを破棄し、ホーム エージェントがある場合はホーム エージェントとの古いモビリティ セキュリティ アソシエーションに戻さなければなりません(MUST)。
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.
10. 登録応答が認証に合格し、AAA 拡張からの MN-FA キー生成ノンス (セクション 6.2 を参照) を含む場合、モバイル ノードは、AAA との AAA セキュリティ アソシエーションに従って、提供されたキー生成ノンスを使用して登録キーを生成します。結果として得られる登録キーは、モバイル ノードの外部エージェントとのモビリティ セキュリティ アソシエーションを確立するために使用され、Mobile-Foreign 認証拡張で使用される認証データを計算するために使用されます。
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.
Mobile-Foreign 認証拡張の検証が失敗し、MN-FA Key Generation Nonce Reply 拡張が別の有効な認証拡張で保護されていない場合、MN は新しいモビリティ セキュリティ アソシエーションを破棄し、古いモビリティ セキュリティ アソシエーションに戻らなければなりません(MUST)。外国代理人（存在する場合）。
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.
MN-HA Key Generation Nonce From AAA 拡張を含む登録応答には、生成された MN-HA 鍵を使用して作成された後続の Mobile Home Authentication 拡張も含めなければなりません (MUST)。同様に、MN-FA Key Generation Nonce From AAA 拡張を含む応答には、登録キーを使用して作成された後続のモバイル外部認証拡張も含まれなければなりません (MUST)。
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 エンティティ (モバイル ノード、ホーム エージェント、外部エージェント) 間のモビリティ セキュリティ アソシエーションには、必要な暗号キー情報と、そのキーを使用してモバイル ホーム認証に存在する認証情報を生成する暗号変換を識別する方法の両方が含まれています。拡張機能または Mobile-Foreign Authentication 拡張機能。モバイル ノードが 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 で使用されるものと同じです。これらは、「IPsec セキュリティ アソシエーション属性」の表化された属性タイプの分類の 1 つである「属性タイプ」(5) (つまり、「認証アルゴリズム」) の値として許可される認証アルゴリズムのリストに表化されています。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] を使用します。モバイル IP [1] を実装し、この文書で指定された拡張機能を実装するすべてのモバイル ノードとモビリティ エージェントは、HMAC-SHA1 [1] を実装しなければなりません (MUST)。他のメッセージ認証コードまたは鍵付きハッシュ関数も使用できます(MAY)。使用される特定のアルゴリズムは、MN と AAAH サーバー間の AAA セキュリティ アソシエーションの一部として設定され、AAA SPI によってインデックスが付けられます。
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 サーバは、「Key Generation Nonce」フィールドの Key Generation Nonce Reply 拡張機能にランダムな値を挿入します。
The following steps are performed by the mobile node (here || represents concatenation):
次の手順はモバイル ノードによって実行されます (ここで || は連結を表します)。
1. The mobile node calculates
1. モバイルノードは計算します
key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || mobile node identifier})
key = HMAC-SHA1 (AAA-key, {キー生成ナンス || モバイル ノード識別子})
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. モバイル ノードは、結果として得られるキーと、キー生成ナンス拡張機能内のその他の関連情報を使用して、モビリティ セキュリティ アソシエーションを作成します。
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 SPI によってインデックス付けされた AAA セキュリティ アソシエーションによって示されます。これは、モバイル ノードとキーマテリアルを作成する AAA サーバ間の 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 KeyGen 要求) を示しています。
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 ビットの長さフィールドは、拡張の長さを示します。これは、MN-FA キー生成ノンス要求サブタイプ データのバイト数に 4 (モバイル ノード SPI フィールドの場合) を加えたものに等しくなります。
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 KeyGen 要求は、サブタイプによって識別される一連の拡張機能を定義します。これは、モバイル 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.
この文書は、MN-FA Key Generation Nonce >From AAA Request (略して MN-FA AAA KeyGen Request) のサブタイプ 1 を定義します。MN-FA AAA KeyGen 要求には長さ 0 のサブタイプ データ フィールドがあり、登録要求内で MN-AAA 認証拡張の前に出現しなければなりません (MUST)。
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.
Generalized MN-FA Key Generation Nonce Reply 拡張機能 (略して MN-FA KeyGen Reply) は、MN-FA KeyGen Request 拡張機能によって要求されたキーイング素材を提供します。図 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
図 2: 一般化されたモバイル IP MN-FA キー生成ノンス応答拡張
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 に変更してもよい(MAY) (「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 に示す、MN-FA Key Generation Nonce From AAA 拡張機能 (略して MN-FA AAA KeyGen Reply) の MN-FA KeyGen Reply のサブタイプ 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
図 3: AAA サブタイプ固有のデータからの MN-FA 鍵生成ナンス
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 モバイル ノードとその予想される外部エージェントの間でモビリティ セキュリティ アソシエーションを確立するために使用する変換を決定するためにモバイル ノードが使用する必要がある SPI を示す 32 ビットの不透明な値。
FA SPI The SPI for the Mobility Security Association to the FA that the mobile node creates using the Key Generation Nonce.
FA SPI モバイル ノードがキー生成ナンスを使用して作成する、FA へのモビリティ セキュリティ アソシエーションの SPI。
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 で引用されている「認証アルゴリズム」テーブルの値の中から選択される) を示します。外部認証拡張機能。
Key Generation Nonce A random [7] value of at least 128 bits.
Key Generation Nonce 少なくとも 128 ビットのランダム [7] 値。
The MN-FA AAA KeyGen Reply extension MUST appear in the Registration Reply before the Mobile-Foreign Authentication extension.
MN-FA AAA KeyGen Reply 拡張は、Mobile-Foreign Authentication 拡張の前に登録応答に表示されなければなりません (MUST)。
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.
キー生成ノンスは、モバイル ノードが登録キーを作成する際に使用するために AAA サーバによって提供されます。登録キーは、同じ外部エージェントへの将来のモバイル IP 登録を保護するために使用されます。
Figure 4 illustrates the Generalized MN-HA Key Generation Nonce Request Extension (MN-HA KeyGen Request for short).
図 4 は、一般化された MN-HA 鍵生成ノンス要求拡張 (略して MN-HA KeyGen 要求) を示しています。
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 Key Generation Nonce 要求のバイト数と同じです。
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).
サブタイプ データに 4 を加えたもの (モバイル ノード SPI フィールド用)。
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 KeyGen 要求拡張は、サブタイプによって識別される一連の拡張を定義します。これは、モバイル ノードがモバイル IP 登録要求メッセージ内で使用して、他のエンティティがモバイル ノードで使用する MN-HA キーを作成することを要求します。モバイルノードの新しいホームエージェントを使用します。
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 KeyGen 要求) のサブタイプ 1 を定義します。MN-HA AAA KeyGen 要求には長さ 0 のサブタイプ データ フィールドがあり、登録要求内で MN-AAA 認証拡張の前に出現しなければなりません (MUST)。
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.
Generalized MN-HA Key Generation Nonce Reply 拡張機能 (略して MN-HA KeyGen Reply) は、MN-HA KeyGen Request 拡張機能によって要求されたキーイング素材を提供します。図 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
図 5: 一般化されたモバイル IP MN-HA キー生成ノンス応答拡張
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 This field indicates the duration of time (in seconds) for which the MN-HA key is valid.
Lifetime このフィールドは、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 に示す、MN-HA Key Generation Nonce From AAA 拡張機能 (略して MN-HA AAA KeyGen Reply) の MN-HA KeyGen Reply のサブタイプ 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
図 6: AAA サブタイプ固有のデータからの MN-HA 鍵生成ナンス
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 モバイル ノードとそのホーム エージェント間のモビリティ セキュリティ アソシエーションの確立に使用する変換を決定するためにモバイル ノードが使用する必要がある SPI を示す 32 ビットの不透明な値。
HA SPI The SPI for the Mobility Security Association to the HA that the mobile node creates using the Key Generation Nonce.
HA SPI モバイル ノードがキー生成ナンスを使用して作成する、HA へのモビリティ セキュリティ アソシエーションの SPI。
Algorithm Identifier This field indicates the transform to be used for future computations of the Mobile-Home Authentication Extension (see section 4).
アルゴリズム識別子 このフィールドは、Mobile-Home Authentication Extension の将来の計算に使用される変換を示します (セクション 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.
Key Generation Nonce 少なくとも 128 ビットのランダム [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 KeyGen Reply サブタイプ固有のデータを図 6 に示します。モバイル ノードは、AAA サーバーによって提供される鍵生成ナンスを使用して MN-HA 鍵を計算します。計算は、モバイル ノードと、AAA インフラストラクチャ内で接続される AAA サーバーとのすべての通信要件を保護するために事前に設定された AAA サーバー間で共有されるキーを使用して進行します (付録 A を参照)。MN-HA キーは、モバイル ノードがホーム エージェントへの将来のモバイル IP 登録を保護するために使用することを目的としています。MN-HA AAA KeyGen Reply 拡張は、MN-HA Authentication 拡張の前に登録応答に表示されなければなりません (MUST)。
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.
モバイル ノードは、AAA SPI で指定された変換を使用して MN-HA キーを作成すると、HA SPI によってインデックス付けされた 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:
この文書は、RFC 3344 [1] で定義され、RFC 2356 [8] で拡張されたモバイル IP 登録拡張用に定義された (スキップ不可能な) 番号付けスペースから取られた 4 つの新しい拡張 (セクション 6 を参照) を定義します。これらの拡張子の値は次のとおりです。
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].
これら 2 つのレジストリの新しいサブタイプは、[9] で定義されている標準化活動を通じて割り当てられます。
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 セキュリティ アソシエーションを定期的に更新しなければなりません (MUST)。
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.
この仕様で定義されている Reply 拡張機能は、鍵の導出に使用される Key Generation Nonce のみを伝送するため、モバイル ノードと 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.
Fredrik Johansson、Tom Hiller、および IESG のメンバーの有益なコメントに感謝します。特に、この文書のその後の改訂に多くのテキストの改善に貢献してくれた Tom Hiller に感謝します。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1] Perkins, C. 編、「IPv4 の IP モビリティ サポート」、RFC 3344、2002 年 8 月。
[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[2] Ababa, B. および M. Beadles、「The Network Access Identifier」、RFC 2486、1999 年 1 月。
[3] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extension", RFC 3012, November 2000.
[3] Perkins, C. および P. Calhoun、「Mobile IPv4 Challenge/Response Extension」、RFC 3012、2000 年 11 月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[5] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[5] Calhoun, P. および C. Perkins、「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.、Bellare, M.、および R. Canetti、「HMAC: Keyed-Hashing for Message Authentication」、RFC 2104、1997 年 2 月。
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[7] Eastlake, D.、Crocker, S.、および J. Schiller、「セキュリティのためのランダム性の推奨事項」、RFC 1750、1994 年 12 月。
[8] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[8] Montenegro, G. および V. Gupta、「モバイル IP のための Sun の 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. Alvestruct、「RFC で 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] Mitton, D.、St.Johns, M.、Barkley, S.、Nelson, D.、Patil, B.、Stevens, M.、および B. Wolff、「認証、認可、およびアカウンティング: プロトコルの評価」、RFC3127、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.、Willens, S.、Rubens, A.、および A. Simpson、「リモート認証ダイヤルイン ユーザー サービス (RADIUS)」、RFC 2865、2000 年 6 月。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[12] Calhoun, P.、Loughney, J.、Guttman, E.、Zorn, G.、および J. Arkko、「Diameter Base Protocol」、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] Glass, S.、Hiller, T.、Jacobs, S.、および C. Perkins、「Mobile IP Authentication, Authorization, and Accounting Requirements」、RFC 2977、2000 年 10 月。
[14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions", Work in Progress, February 2004.
[14] Calhoun, P. および C. Perkins、「DIAMETER モバイル IP 拡張機能」、進行中の作業、2004 年 2 月。
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 [3] でも説明されているような AAA インフラストラクチャの存在に依存して、Mobile-AAA 認証拡張 [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 サーバー
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 セキュリティ アソシエーションを共有する必要があることは明らかです。そうしないと、AAAL と AAAH の間で取引される可能性のある認証結果、認可、さらにはアカウンティング データさえも信頼できなくなるからです。ただし、このような双方向の 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.
2 つの別個の管理ドメイン (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:
さらにもう 1 つの詳細について言及する価値があります。モバイル ノードと外部エージェントの間で確立されるモビリティ セキュリティ アソシエーションは、モバイル ノードだけでなく外部エージェントにも伝達される必要があります。キー配布を行うために 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).
- このメカニズムは、AAAH および FA (または HA への鍵配布の場合は HA) 以外のエンティティに鍵を公開してはなりません。
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 間の AAA プロトコル処理、および AAAL と外部エージェント間のさらなる AAA プロトコル処理の一部として処理されることが期待されます。このような処理はこの文書の範囲外ですが、上記の要件を満たす必要があります。
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.
このセクションでは、セクション A で説明した、AAA インフラストラクチャから登録キーを要求および受信するためのメッセージ フローを示します。[3] で指定されているチャレンジ値は、追加のリプレイ保護のためにアドバタイズメントおよび登録メッセージに追加される場合がありますが、ここでは図示されていません。
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
図 9: 鍵生成ナンスを要求および受信するためのメッセージ フロー
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. 外部エージェントはエージェント アドバタイズメントを配布します。この広告は、モバイル ノード (図には示されていない) からエージェント要請を受信した後に生成されてもよい (MAY)。
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].
2. モバイル ノードは、必要に応じて、MN-HA AAA KeyGen 要求および/または MN-FA AAA KeyGen 要求を含む登録要求を、モバイル IP で要求される承認を有効にする認証拡張子とともに作成します [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 Reply 拡張機能とともに、Registration Reply をモバイル ノードに中継します。
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: 要求されていないキー生成ナンスを受信するためのメッセージ フロー
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. 外部エージェントはエージェント アドバタイズメントを配布します。この広告は、モバイル ノード (図には示されていない) からエージェント要請を受信した後に生成されてもよい (MAY)。
2. The mobile node creates a Registration Request including an authorization-enabling authentication extension as required by Mobile IP [1].
2. モバイル ノードは、モバイル 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 インフラストラクチャ (付録 A を参照) に AAA 要求 (おそらく登録要求を含む) を送信します。
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. 外部エージェントは、モバイル ノードが関連するモビリティ エージェント（外部エージェントおよび/またはホーム エージェント）とモビリティ セキュリティ アソシエーションを確立するために使用する新しい KeyGen Reply 拡張機能とともに、登録応答をモバイル ノードに中継します。
Authors' Addresses
著者の住所
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Pat R. Calhoun Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134 USA
Pat R. Calhoun Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134 USA
Phone: +1 408 635 2000
Fax: +1 408 635 2020
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。