RFC3957 日本語訳
3957 Authentication, Authorization, and Accounting (AAA) RegistrationKeys for Mobile IPv4. C. Perkins, P. Calhoun. March 2005. (Format: TXT=63576 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Perkins
Request for Comments: 3957 Nokia Research Center
Category: Standards Track P. Calhoun
Airespace
March 2005
コメントを求めるワーキンググループC.パーキンス要求をネットワークでつないでください: 3957年のノキアリサーチセンターカテゴリ: 2005年の標準化過程P.カルフーンAirespace行進
Authentication, Authorization, and Accounting (AAA)
Registration Keys for Mobile IPv4
モバイルIPv4のための認証、承認、および会計(AAA)登録キー
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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などの認証、Authorization、およびAccounting(AAA)サーバは、今日、ダイヤルアップコンピュータのための認証と承認サービスを提供するためにインターネットの中で使用中です。 IPv4のためのモバイルIPはモバイルノードとそのホームのエージェントの間の強い認証を必要とします。 モバイルノードがホームAAAサーバとAAA Security Associationを共有するとき、しかしながら、それは、モバイルノードとそのホームのエージェントの間で派生しているMobility Security Associationsを作成するのにそのAAA Security Associationを使用するのにおいて可能であり、再び現在モバイルノードに接続性を提供するモバイルノードと外国人のエージェントの間で共有します。 このドキュメントはモバイルノードと、そして、モバイルノードとそのホームのエージェント、外国人のエージェントの間でMobility Security Associationsを作成するのに使用できるモバイルIP登録メッセージに拡大を指定します。
Perkins & Calhoun Standards Track [Page 1] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[1ページ]RFC3957AAAキー
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. キー生成の一回だけの拡大との操作の概要。 . 5 4. 移動性セキュリティ協会. . . . . . . . . . . . . . . . 7 5。 キー生成の一回だけの作成と主要な派生. . . . . . . 8 6。 キー生成拡大。 . . . . . . . . . . . . . . . . . . 9 6.1. ミネソタ-ファのキー生成の一回だけの要求拡張子10 6.2を一般化しました。 ミネソタ-ファのキー生成の一回だけの回答拡大. 11 6.3を一般化しました。 総合、Mn、-、ハ、キー生成の一回だけの要求拡張子13 6.4 総合、Mn、-、ハ、キー生成の一回だけの回答拡大. 14 7 誤りは.168を評価します。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 16 9. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 17 10. 承認. . . . . . . . . . . . . . . . . . . . . . . 18 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1。 引用規格. . . . . . . . . . . . . . . . . . 18 11.2。 有益な参照. . . . . . . . . . . . . . . . . 19付録. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20A.AAAインフラストラクチャ。 . . . . . . . . . . . . . . . . . . . . 登録キー24作者を要求して、受けるための流れが.26の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 27を扱う20B.メッセージ
1. Introduction
1. 序論
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サーバは、今日、ダイヤルアップコンピュータのための認証と承認サービスを提供するためにインターネットの中で使用中です。 そのようなサービスはモバイルノードにIPv4[1]にモバイルIPを使用することで貴重である傾向があります、ノードが、AAAサーバで外国ドメインに接続するのを試みているとき。 IPv4のための本書ではモバイルのIPは「モバイルIPv4"かまさしく略して他のバージョンへの混乱がないの以来の「モバイルIP」が予想されます。」と呼ばれます。 AAAとモバイルIPとの相互作用のための要件はRFC2977[13]に概説されています。 そのドキュメントはAAAサーバがモバイルノードからのネットワークアクセス要求を認証して、認可するのを可能にするインフラストラクチャについて説明します。 また、モバイルIP Registration Requestがネットワークアクセサリーを求める要求であると考えられる付録A.を見てください。 次に、モバイルIP移動性エージェントの機能性を増大させるのは彼らがモバイルIP登録メッセージとAAAインフラストラクチャの中で使用されたメッセージの間で翻訳できるくらい可能です、RFC2977で説明されるように。 メッセージが本書では指定されたタイプであるとサポートするために適切なネットワーク実体であるとRFC2977の要件に従う移動性エージェントとAAAサーバをみなすことができます。 [13] さらに詳しい明細についてはRFC2977に相談してください。
Perkins & Calhoun Standards Track [Page 2] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[2ページ]RFC3957AAAキー
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.
この仕様は、派生しているMobility Security Associationsを作成するのに独身のAAA Security Associationを利用します。 この仕様によるMobility Security AssociationはミネソタとHA、そして/または、ミネソタとFAの間のMIPv4コントロールトラフィックを認証するのに勤めるシンプレクス接続です。 Mobility Security Associationは2つのエンドポイントによって特定されます、ミネソタIPアドレスや、HA IPアドレスや、SPIなどのように。 2つのノードで、互いの間に1Mobility Security Associationsを設立するかもしれません。 しかしながら、2つのノードの間に1Mobility Security Associationを持つ理由が全く通常ありません。
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.
このドキュメントはミネソタとAAAサーバの間でAAA Security Associationに基づくミネソタとFA、そして/または、ミネソタとHAの間でMobility Security Associationsを作成するのに使用できるモバイルIP登録メッセージに拡大を指定します。次に、これらの新しいMobility Security Associationsは、モバイルIPコントロールメッセージで使用される認証拡張子で必要であるAuthentication Dataについて計算するのに使用されるかもしれません。
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サーバがモバイルノードとその将来の移動性エージェントの間の必要なMobility Security Association(s)の基礎として使用されるために主要な材料を供給できるようにモバイルノードとその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サーバは唯一モバイルノードを特定するのにNetwork Access Identifier(NAI)[2]を通常使用します。 モバイルノードのホームアドレスが、その機能を提供するのにいつも必要であるというわけではありません。 したがって、モバイルノードがそれ自体を認証して、接続のために外国ドメインに認可されるのは、可能です、どんなホームアドレスも持っていなくて。 しかしながら、モバイルIPが働くように、モバイルノードには、ホームアドレスとMobility Security Association[1]がホームのエージェントと共にいなければなりません。 モバイルIP Registration Replyパケットがミネソタ-AAA Authentication Extension[3]によって認証されるとき、モバイルノードは、ホームのエージェント、そして/または、外国人のエージェントと共にMobility Security Associationsを作成するために拡大に含まれた主要な材料が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インタフェースの特徴)がキーを交換するためのこのドキュメントの範囲の外に手段をすべて持っていると思われます。 このドキュメントの中の拡大はどんなAAAプロトコル群によるそのような主要な交換を考慮する仕事にも意図します、RFC2977[13]で指定された要件を満たす限り。 そのようなプロトコルのAAA1つはDiameterフレームワーク[14]の中で定義されます。
Perkins & Calhoun Standards Track [Page 3] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[3ページ]RFC3957AAAキー
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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実体Aはノード処理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 Security Association Aセキュリティ協会。 モバイルノードとそのホームAAAサーバ(AAAH)の間には、本書ではすべてのAAA Security Associationsがあります。 ホームAAAサーバ(AAAH)があるモバイルノードのAAA Security Associationはモバイルノードの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.
秘密にされた主要なA番号。 キーの所持のノードだけで、セキュリティを使用するというどんな望みも、正しい結果を得るために変形します。
Key Generation Nonce
Nonce data used for the purpose of creating a 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.
移動性Security Association A Mobility Security AssociationはRFC3344Authentication Extensionsを使用することでミネソタとHA(または、ミネソタとFA)の間のRFC3344MIPv4コントロールトラフィックへのセキュリティー・サービスを適用するシンプレクス接続です。 Mobility Security Associationは同輩ソース、送付先IPアドレス、およびSPIによって唯一特定されます。 2つのノードには、1Mobility Security Associationsがあるかもしれません。 しかしながら、2つのノードの間に1Mobility Security Associationを持つ理由が全く通常ありません、イベントを再合わせる間の一時的な状態を除いて。
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.
ミネソタ-FAかミネソタ-HA Mobility Security Associationで使用される登録Key Aキー。 登録キーは一度か、ほんのわずかな回と、単にAuthenticationデータのわずかなボリュームについて確かめる目的に通常使用されるだけです。
Perkins & Calhoun Standards Track [Page 4] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[4ページ]RFC3957AAAキー
Security Algorithm
A set of rules for using input data and a secret key
for producing data for use in security protocols.
Algorithm Aが設定する使用のための規則のセキュリティはデータとセキュリティプロトコルにおける使用のためのデータを作り出すための秘密鍵を入力しました。
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、またはMobility Security Associationの識別を助ける任意の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]に基づき定義されるように使用されています。 その上、多くの場合、議論を簡素化するために、私たちは「一般化された拡大のSubtype」の代わりに「拡大」という言葉を使用しました。 そのように、そして、例えば、「一般化されたミネソタ-ファキー生成一回だけの回答拡大のAAA Subtypeからのミネソタ-ファキー生成一回だけ」という句を使用することの代わりに、私たちは代わりに「AAA拡大からのミネソタ-ファキー生成一回だけ」という句を使用するでしょう。
3. Overview of Operations with Key Generation Nonce Extensions
3. キー生成の一回だけの拡大との操作の概要
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インフラストラクチャによるとき、それは、ホームのエージェントか外国人のエージェントのどちらかが外国ネットワークへのアクセスを制御しているMobility Security Associationsを先在させながら、いずれも欠くかもしれません。 本書では定義された拡大で、AAA実体は、モバイルエージェントと共にMobility Security Associationの基礎として使用されるために主要な材料をモバイルノードに供給できます。 これらの拡大に影響する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 Registration Requestメッセージに要求して(以下では、定義されます)、モバイルIP Registration Replyメッセージへの拡大でモバイルノードに供給するかもしれません。 あるいはまた、AAAサーバはモバイルノードへの移動性エージェントを通して求められていない主要な材料を供給するかもしれません。 モバイルノードは、関連Mobility Security Associationを次に、新しいキーについて計算して、アップデートしなければならないか、または作成しなければなりません。 主要な材料が自分たちで移動性エージェントに提供されるメソッドは、範囲の外にこのドキュメントのためにあって、AAAサーバのために外国とホームドメインでセキュリティー体系の特定の詳細によるでしょう(RFC2977と付録Aを見てください)。 このドキュメントの目的のために、私たちはホームと外国人のエージェントにとって、利用可能な適当なAAAインフラストラクチャがあって、モバイルノードには少なくとも1つのAAAサーバがホームドメインにある状態でAAA Security Associationがあると思います。
Perkins & Calhoun Standards Track [Page 5] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[5ページ]RFC3957AAAキー
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.
モバイルノードが遠くをホームから旅するとき、ホームのエージェントがいるMobility Security Associationを持っていないかもしれません、恐らくそれにはホームアドレス[5]がまだないので。 本書では、プロトコルとメッセージが訪問された(地方の)ドメイン(認証かAuthorizationとAccounting LocalかAAAL)とホームドメイン(認証か、Authorizationと、AccountingホームかAAAH)にモバイルノードと、外国人のエージェントと、ホームのエージェントと、AAAサーバの間に起こるかもしれない以下の操作を容易にすることを意図します。 メッセージの以下の系列では、本書では指定された唯一のメッセージ流れが、モバイルノードと外国人のエージェントの間のRegistration Requestと、外国人のエージェントとモバイルノードの間のRegistration Replyです。 他のメッセージはRFC2977で説明されるようにここで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. モバイルノードがそうしないなら、外国人のエージェントがいるMobility Security Associationを持ってください、それ。SHOULDはそれがForeignエージェントに送るRegistration Requestの一部としてミネソタ-FA Key Generation Nonce Request拡張子(セクション6.1を見る)を含んでいます。
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. モバイルノードにホームのエージェントがいるMobility Security Associationがないなら、それはそれがForeignエージェントに送るRegistration Requestの一部としてミネソタ-HA Key Generation Nonce Request拡張子(セクション6.3を見る)を加えなければなりません。
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拡張子が加えられたなら、モバイルノードはミネソタ-AAA Authentication拡張子をRegistration Requestに加えなければなりません。
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サーバ(AAAL)にモバイルノードの主要な要求と認証データを移します、通常、適切なAAAメッセージに収まるように再フォーマットした後に。また、そのエージェントは、あえて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. 次に、また、ミネソタ-AAA Authentication拡張子の中の情報がホームドメイン(AAAH)のAAAサーバによって確かめられた後に、モバイルノードによって要求される主要な材料を生成します、必要なMobility Security Associationsのために。
6. The respective keys for the Mobility Security Associations are
distributed to the Home Agent and Foreign Agent via the AAA
protocol.
6. Mobility Security AssociationsのためのそれぞれのキーはAAAプロトコルでホームのエージェントとForeignエージェントに分配されます。
7. The mobile node receives the Registration Reply message from the
Foreign Agent.
7. モバイルノードはForeignエージェントからRegistration Replyメッセージを受け取ります。
Perkins & Calhoun Standards Track [Page 6] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[6ページ]RFC3957AAAキー
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. ミネソタ-HA Key Generation Nonce Request From AAA拡張子がRegistration Requestメッセージに存在しているなら、モバイルノードは、Mobility Security Associationを作成しなければならないか、またはホームのエージェントが対応するRegistration Replyで示されている状態で、アップデートしなければなりません、主要な材料からミネソタ-HA Key Generation Nonce From AAA拡張子で計算されたキーを使用して。 この場合、どんなミネソタ-HA Key Generation Nonce Reply拡張子も存在していないなら、モバイルノードはRegistration Replyを捨てなければなりません。
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. ホームのエージェントがいる(恐らく新たに作成されています)の移動性Security Associationを使用して、モバイルノードは、モバイルホームAuthentication拡張子でAuthentication Dataをチェックすることによって、Registration Replyメッセージを認証します。 チェックが失敗するなら、ミネソタはRegistration Replyと新しいMobility Security Associationを捨てなければなりません、ホームのエージェントと共に古いMobility Security Associationにもしあれば戻って
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. Registration Replyが認証を通過して、ミネソタ-FA Key Generation Nonce From AAA拡張子を含んでいるなら(セクション6.2を見てください)、モバイルノードは、AAA Security Associationに応じてAAAに提供されたKey Generation Nonceを使用することで登録キーを生成します。 結果として起こる登録キーは、外国人のエージェントと共にモバイルノードのMobility Security Associationを証明するのに使用されて、モバイルに外国の認証拡大に使用される認証データを計算するのに使用されます。
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.
モバイルに外国の認証拡大の検証が失敗して、ミネソタ-FA Key Generation Nonce Reply拡張子が別のものによって保護されなかったなら、有効な認証拡大、ミネソタは新しいMobility Security Associationを捨てなければなりません、外国人のエージェントと共に古いMobility Security Associationにもしあれば戻って
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.
また、ミネソタ-HA Key Generation Nonce From AAA拡張子を含むどんな登録回答も発生しているミネソタ-HAキーを使用することで作成されたその後のモバイルホームAuthentication拡張子を含まなければなりません。 また、同様に、ミネソタ-FA Key Generation Nonce From AAA拡張子を含む回答は登録キーを使用することで作成されたその後のモバイルForeign Authentication拡張子を含まなければなりません。
4. Mobility Security Associations
4. 移動性セキュリティ協会
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
モバイルIP実体(モバイルノード、ホームのエージェント、外国人のエージェント)の間の移動性Security Associationsは必要な暗号化キー情報とモバイルホームAuthentication拡張子かモバイルに外国のAuthentication拡張子で存在している認証情報を作り出すのにキーを使用する暗号の変換を特定する方法の両方を含んでいます。 モバイルの注文で
Perkins & Calhoun Standards Track [Page 7] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[7ページ]RFC3957AAAキー
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.
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セキュリティ協会属性」のための表にされたAttribute Typesでの分類の1つ)のために値として許容できるAuthentication Algorithmsのリストに表にされます。 すべてのAttribute Typesと他のAttributesの詳細な一覧表のためにIPsec Security Associationsに関して 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.
移動性Security Associationsはモバイルノードを平等に割り当てました、そして、また、ホームのエージェントは反復操作による保護メソッドを必要とします。 以下のテーブルはサポートしている再生検出メソッドを含んでいます。
Replay Method Name Reference
-------------- ------------ --------------
0,1 Reserved
2 Timestamps RFC 3344 [1]
3 Nonces RFC 3344 [1]
4-65535 Unallocated
再生メソッド名前参照-------------- ------------ -------------- 0、1は2つのタイムスタンプRFC3344[1]3一回だけRFC3344[1]4-65535Unallocatedを予約しました。
5. Key Generation Nonce Creation and Key Derivation
5. キー生成の一回だけの作成と主要な派生
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サーバでKey Generation Nonceの作成で従った手順を含んで、モバイルノードで手順が使用した主要な派生を含みます。 また、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]であると実装しなければなりません。 また、他のメッセージ確認コードか合わせられたハッシュ関数が使用されるかもしれません。 使用される特定のアルゴリズムはミネソタとAAAHサーバの間のAAA Security Associationの一部として構成されます。(Security AssociationはAAA SPIによって順番に索引をつけられます)。
Perkins & Calhoun Standards Track [Page 8] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[8ページ]RFC3957AAAキー
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分野がRegistration Requestに存在しているなら、NAIはモバイルノード識別子として使用されます。 さもなければ、Registration RequestのホームAddress分野は使用されています。
2. The AAA server generates a random [7] value of at least 128 bits
to be used as the Key Generation Nonce.
2. AAAサーバは、Key Generation Nonceとして使用されるために少なくとも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 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})
主要な=HMAC-SHA1(主要なGeneration Nonce| | AAAキー、モバイルノード識別子)
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.
ここで、Key Generation NonceはRegistration Replyで拡大から来ています。そうでなければ、Registration Request、またはホームAddressにRegistration Requestから存在しているなら、モバイルノード識別子はミネソタの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. モバイルノードはMobility Security Association(s)を作成します、Key Generation Nonce Extensionの結果として起こるキーと他の関連情報を使用して。
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 Security Associationの基礎としてモバイルノードとAAAサーバの間で構成されたAAA SPIによって索引をつけられたAAA Security Associationによって示されます。
6. Key Generation Extensions
6. キー生成拡大
This section defines new Extensions to Mobile IP Registration Requests and Replies [1].
このセクションはモバイルIP Registration RequestsとReplies[1]と新しいExtensionsを定義します。
Perkins & Calhoun Standards Track [Page 9] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[9ページ]RFC3957AAAキー
6.1. Generalized MN-FA Key Generation Nonce Request Extension
6.1. 一般化されたミネソタ-ファキー生成一回だけの要求拡張子
Figure 1 illustrates the Generalized MN-FA Key Generation Nonce Request Extension (MN-FA KeyGen Request for short).
図1はGeneralizedミネソタ-FA Key Generation Nonce Request Extension(略してミネソタ-FA KeyGen Request)を例証します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Subtype| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | モバイルノードSPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ミネソタ-ファのキー生成の一回だけの要求Subtypeデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Generalized Mobile IP MN-FA Key Generation
Nonce Request Extension
図1: 一般化されたモバイルIPミネソタ-ファキー生成一回だけの要求拡張子
Type 40 (not skippable) (see [1] and section 8)
40(skippableしない)をタイプしてください。([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.
登録キーを生成するときミネソタ-FA Key Generation Nonce Request Subtype Dataによって使用されていることになっている方法を特定するために割り当てられたSubtype A番号。
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ビットのLengthがさばく長さは拡大の長さを示します。 それはミネソタ-FA Key Generation Nonce Request Subtype Dataと4(モバイルNode 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.
モバイルノードが使用のために作成されたMobility Security Associationのために登録キーで割り当てるモバイルNode SPI Security Parameters Index。
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.
ミネソタ-FA Key Generation Nonce Request Subtype Data Dataは、モバイルノードを代表して主要な登録の作成を行う必要がありました。
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.
ミネソタ-FA KeyGen Requestはある他の実体が使用のためにモバイルノードの新しい外国人のエージェントと共にモバイルノードでRegistration Keyを作成するよう要求するモバイルIP Registration Requestメッセージのモバイルノードによって使用されるかもしれない「副-タイプ」によって特定された1セットの拡張子を定義します。
Perkins & Calhoun Standards Track [Page 10] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[10ページ]RFC3957AAAキー
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.
このドキュメントはミネソタ-FA Key Generation Nonce>From AAA Request(略してミネソタ-FA AAA KeyGen Request)のために「副-タイプ」1を定義します。 ミネソタ-FA AAA KeyGen Requestはゼロ・レングスSubtype Data分野を持って、ミネソタ-AAA Authentication拡張子の前にRegistration Requestに現れなければなりません。
6.2. Generalized MN-FA Key Generation Nonce Reply Extension
6.2. 一般化されたミネソタ-ファキー生成一回だけの回答拡大
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ミネソタ-FA Key Generation Nonce Reply拡張子(略してミネソタ-FA KeyGen Reply)は材料がミネソタ-FA KeyGen Request拡張子で要求した合わせることを供給します。 図2はGeneralizedミネソタ-FA Key Generation Nonce Reply Extensionの形式を例証します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Subtype| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ミネソタ-ファのキー生成の一回だけの回答Subtypeデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Generalized Mobile IP MN-FA Key
Generation Nonce Reply Extension
図2: 一般化されたモバイルIPミネソタ-ファキー生成一回だけの回答拡大
Type 41 (not skippable) (see [1] and section 8)
41(skippableしない)をタイプしてください。([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.
ミネソタ-FA Key Generation Nonce Reply Subtype Dataが登録キーを入手するのに使用されることになっている方法を特定するために割り当てられたSubtype A番号。
Length The 16-bit Length field is equal to the number of bytes in
the MN-FA Key Generation Nonce Reply Subtype Data.
16ビットのLengthがさばく長さはミネソタ-FA Key Generation Nonce Reply Subtype Dataのバイト数と等しいです。
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.
ミネソタ-FA Key Generation Nonce Reply Subtype Data Anは合わせることの材料のコピーをコード化しました、指定されたMobility Security Associationを作成するために受取人によって必要とされたいかなる他の情報と共にも。
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.
各「副-タイプ」に関しては、Mobility Security Associationをセットアップするのに必要である特定のメソッドに従って、ミネソタ-FA Key Generation Nonce Reply Subtype Dataの書式は別々に定義されなければなりません。
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
本書では定義された「副-タイプ」に関しては、この拡大の「副-タイプ」のためのデータで供給されたミネソタ-FA Key Generation NonceはGeneralizedミネソタ-FA Key Generation Nonce Request Extensionの「副-タイプ」が使用させられた要求の結果、来るかもしれません。 そのようなもので
Perkins & Calhoun Standards Track [Page 11] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[11ページ]RFC3957AAAキー
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.
ケース、登録キーによって定義されたMobility Security Associationを使うとき使用されるべき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によって索引をつけられた変換を使用することによって保存する外国人のエージェントがいるMobility Security AssociationがモバイルSecurity AssociationsのリストでFA SPIで索引をつけたMobility Security Associationを作成します。
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.
外国人のエージェントがミネソタ-FA Key Generation Nonce Reply拡張子を全く持っていないRegistration Replyを受け取って、モバイルノードのどんな既存のMobility Security Associationも持っていないなら、外国人のエージェントはRegistration ReplyのCode値を_MISSING_ミネソタ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.
このドキュメントは図に示されたミネソタ-FA Key Generation Nonce From AAA拡張子(略してミネソタ-FA AAA KeyGen Reply)のためのミネソタ-FA KeyGen Replyの「副-タイプ」1つの3を定義します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トリプルA SPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ファSPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アルゴリズム識別子| キー生成一回だけ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MN-FA Key Generation Nonce From AAA
Subtype-Specific Data
図3: AAAのSubtype特有のデータからのミネソタ-ファキー生成一回だけ
lifetime This field indicates the duration of time (in seconds) for
which the keying material used to create the registration
key is valid.
生涯This分野は材料が登録キーを作成するのに使用した合わせるのが有効である時(秒の)の持続時間を示します。
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.
モバイルノードが使用しなければならないSPIを示す変換がモバイルノードとその将来の外国人のエージェントの間のMobility Security Associationを設立するのに使用することを決定するAAA SPIのA32ビットの不透明な価値。
FA SPI The SPI for the Mobility Security Association to the FA
that the mobile node creates using the Key Generation
Nonce.
Key Generation Nonceを使用するモバイルノードが作成するFAへのMobility Security AssociationのためのFA SPI SPI。
Perkins & Calhoun Standards Track [Page 12] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[12ページ]RFC3957AAAキー
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.
アルゴリズムIdentifier This分野は使用される(外国人のエージェントと共にMobility Security Associationの一部として保存されて、セクション4で引用された「認証アルゴリズム」テーブルの値の中で選び抜かれる)ために変換を示します、モバイルに外国のAuthentication Extensionの今後の計算のために。
Key Generation Nonce
A random [7] value of at least 128 bits.
少なくとも128ビットの主要なGeneration Nonce A無作為の[7]価値。
The MN-FA AAA KeyGen Reply extension MUST appear in the Registration Reply before the Mobile-Foreign Authentication extension.
ミネソタ-FA AAA KeyGen Reply拡張子はモバイルに外国のAuthentication拡張子の前にRegistration Replyに現れなければなりません。
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サーバは登録キーを作成するのにKey Generation Nonceを提供します。(キーは、同じ外国人のエージェントと共に将来のモバイルIP登録証明書を保証するのに使用されます)。
6.3. Generalized MN-HA Key Generation Nonce Request Extension
6.3. 総合、Mn、-、ハ、キー生成の一回だけの要求拡張子
Figure 4 illustrates the Generalized MN-HA Key Generation Nonce Request Extension (MN-HA KeyGen Request for short).
図4はGeneralizedミネソタ-HA Key Generation Nonce Request Extension(略してミネソタ-HA KeyGen Request)を例証します。
Type 42 (not skippable) (see [1] and section 8)
42(skippableしない)をタイプしてください。([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.
登録キーを生成するときミネソタ-HA Key Generation Nonce Request Subtype Dataによって使用されていることになっている方法を特定するために割り当てられたSubtype a番号。
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ビットのLengthがさばく長さは拡大の長さを示します。 それはミネソタ-HA Key Generation Nonce Requestのバイト数と等しいです。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Subtype| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | モバイルノードSPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mn、-、ハ、キー生成の一回だけの要求Subtypeデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Generalized Mobile IP MN-HA Key Generation
Nonce Request Extension
図4: 一般化されたモバイルIP、Mn、-、ハ、キー生成の一回だけの要求拡張子
Subtype Data plus 4 (for the Mobile Node SPI field).
Subtype Dataと4(モバイルNode SPI分野への)。
Perkins & Calhoun Standards Track [Page 13] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[13ページ]RFC3957AAAキー
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.
モバイルノードが使用のために作成されたMobility Security Associationのために登録キーで割り当てるモバイルNode SPI Security Parameters Index。
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.
ミネソタ-HA Key Generation Nonce Request Subtype Data Dataは、モバイルノードを代表してミネソタ-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.
ミネソタ-HA KeyGen Request Extensionはある他の実体が使用に、モバイルノードでモバイルノードの新しいホームのエージェントにとって、主要なミネソタ-HAを作成するよう要求するモバイルIP Registration Requestメッセージのモバイルノードによって使用されるかもしれない「副-タイプ」によって特定された1セットの拡張子を定義します。
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.
このドキュメントはミネソタ-HA Key Generation NonceのためにAAA Request(略してミネソタ-HA AAA KeyGen Request)から「副-タイプ」1を定義します。 ミネソタ-HA AAA KeyGen Requestはゼロ・レングスSubtype Data分野を持って、ミネソタ-AAA Authentication拡張子の前にRegistration Requestに現れなければなりません。
6.4. Generalized MN-HA Key Generation Nonce Reply Extension
6.4. 総合、Mn、-、ハ、キー生成の一回だけの回答拡大
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ミネソタ-HA Key Generation Nonce Reply拡張子(略してミネソタ-HA KeyGen Reply)は材料がミネソタ-HA KeyGen Request拡張子で要求した合わせることを供給します。 図5はGeneralizedミネソタ-HA Key Generation Nonce Reply Extensionの形式を例証します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Subtype| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mn、-、ハ、キー生成の一回だけの回答Subtypeデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Generalized Mobile IP MN-HA Key
Generation Nonce Reply Extension
図5: 一般化されたモバイルIP、Mn、-、ハ、キー生成の一回だけの回答拡大
Type 43 (not skippable) (see [1] and section 8)
43(skippableしない)をタイプしてください。([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.
ミネソタ-HA Key Generation Nonce Reply Subtype Dataがミネソタ-HAキーを入手するのに使用されることになっている方法を特定するために割り当てられたSubtype a番号。
Perkins & Calhoun Standards Track [Page 14] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[14ページ]RFC3957AAAキー
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ビットのLengthがさばく長さは拡大の長さを示します。 それはミネソタHA Key Generation Nonce Reply Subtype Dataと4(Lifetime分野への)におけるバイト数と等しいです。
Lifetime This field indicates the duration of time (in seconds) for
which the MN-HA key is valid.
生涯This分野はミネソタ-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.
ミネソタ-HA Key Generation Nonce Reply Subtype Data Dataは以前はよくミネソタ-HAキーを引き出していました、ホームのエージェントと共に指定されたMobility Security Associationを作成するためにモバイルノードによって必要とされたいかなる他の情報と共にも。
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.
各「副-タイプ」に関しては、Mobility Security Associationをセットアップするのに必要である特定のメソッドに従って、ミネソタ-HA Key Generation Nonce Reply Subtype Dataの書式は別々に定義されなければなりません。
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.
このドキュメントは図に示されたミネソタ-HA Key Generation Nonce From AAA拡張子(略してミネソタ-HA AAA KeyGen Reply)のためのミネソタ-HA KeyGen Replyの「副-タイプ」1つの6を定義します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トリプルA SPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハ、SPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アルゴリズム識別子| 再生メソッド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キー生成一回だけ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The MN-HA Key Generation Nonce From AAA
Subtype-Specific Data
図6: Mn、-、ハ、AAAのSubtype特有のデータからのキー生成一回だけ
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.
モバイルノードが使用しなければならないSPIを示す変換がモバイルノードとそのホームのエージェントの間のMobility Security Associationを設立するのに使用することを決定するAAA SPIのA32ビットの不透明な価値。
HA SPI The SPI for the Mobility Security Association to the HA
that the mobile node creates using the Key Generation
Nonce.
Key Generation Nonceを使用するモバイルノードが作成するHAへのMobility Security AssociationのためのHA SPI SPI。
Perkins & Calhoun Standards Track [Page 15] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[15ページ]RFC3957AAAキー
Algorithm Identifier
This field indicates the transform to be used for future
computations of the Mobile-Home Authentication Extension
(see section 4).
アルゴリズムIdentifier This分野は、モバイルホームAuthentication Extensionの今後の計算に使用されるために変換を示します(セクション4を見てください)。
Replay Method
This field contains the replay method to be used for
future Registration messages (see section 4).
再生Method This分野は将来のRegistrationメッセージに使用されるべき再生メソッドを含んでいます(セクション4を見てください)。
Key Generation Nonce
A random [7] value of at least 128 bits.
少なくとも128ビットの主要なGeneration Nonce 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.
ミネソタ-HA AAAのKeyGen Reply subtype特有のデータは6が中で計算するのが示されます。 モバイルNodeは、AAAサーバによって提供されたKey Generation Nonceを使用することでミネソタ-HAキーについて計算します。計算は、AAAインフラストラクチャの中で連絡されるAAAサーバでそのようなすべてのコミュニケーションが要件であると機密保護するのにモバイルノードと以前に構成されたAAAサーバの間で共有されたキーを使用することによって、続きます(付録Aを見てください)。 ミネソタ-HAキーはモバイルノードによる使用がホームのエージェントと共に将来のモバイルIP登録証明書を保証することを意図します。 ミネソタ-HA AAA KeyGen Reply拡張子はミネソタ-HA Authentication拡張子の前にRegistration Replyに現れなければなりません。
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 Keyを作成すると、AAA SPIで指定された変換を使用することによって、それはモバイルSecurity AssociationsのリストでHA SPIによって索引をつけられたHA Security情報を保存します。 モバイルノードはホームのエージェントと共に初並列データとしてRegistration ReplyからのIdentificationフィールド・データを使用します。
7. Error Values
7. 誤り値
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.
以下のテーブルの各エントリーはRegistration Replyで返されるCode[1]値、そのCodeのための値、および誤りが最初にこの仕様で言及されるセクションの名前を含んでいます。
Error Name Value Section
---------------------- ----- ---------
MISSING_MN_FA 107 6.2
エラー名値の部---------------------- ----- --------- なくなった_ミネソタ_ファ107 6.2
8. IANA Considerations
8. IANA問題
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:
このドキュメントはRFC2356[8]の広げられるとしてのRFC3344[1]で定義されたモバイルIP登録拡大のために定義された(非skippable)の付番スペースから取られた4つの新しい拡大(セクション6を見る)を定義します。 これらの拡大のための値は以下の通りです。
Perkins & Calhoun Standards Track [Page 16] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[16ページ]RFC3957AAAキー
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
名前値の部--------------------- ------- --------- MnファKeyGen要求40 6.1MnファKeyGen回答41 6.2、ハ、ミネソタKeyGen、要求42 6.3、ハ、ミネソタKeyGen、回答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 Request/回答血液型亜型のために新しい登録であると主張するでしょう。 登録の初期のコンテンツは本書では定義された血液型亜型のための単一のエントリーです:
Name Value Section
----------------------------- ------- ---------
KeyGen Request/Reply from AAA 1 6
名前値の部----------------------------- ------- --------- AAA1 6からのKeyGen要求/回答
New subtypes for these two registries are assigned through Standards Action as defined in [9].
これらの2つの登録への新しい血液型亜型は[9]で定義されるようにStandards Actionを通して割り当てられます。
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は_誤りMISSING_ミネソタFAへのセクション7で記載されたコード値を割り当てました。 この値は外国人のエージェント(すなわち、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は、作成して、Replay Method Identifierのために名前空間であることを支持するでしょう。 この仕様は2と3を利用します。 (0)と(1)がないのを除いた他のすべての値がDesignated Expert[9]で課題、未定のレビュー、および承認に利用可能です。
9. Security Considerations
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.
本書では、拡大が認証拡大で必要であるAuthentication DataがモバイルIPと共に登録メッセージを使用したと見込むためにモバイルIP実体(モバイルノード、外国人のエージェント、およびホームのエージェント)にセキュリティの適正水準を提供することを意図します。 これらの拡張子の使用から生じるMobility Security Associationsは既にAAA Security Associationを使用で暗黙であることのことより高いどんなレベルのセキュリティもモバイルノードとAAAHの間に提供しません。 モバイルノードとAAAサーバの間のAAA Security Associationの秘密保持を分析して、壊す限りない時間のぜいたくをどんな敵に対しても否定するために、定期的にそのAAA Security Associationをリフレッシュしなければなりません。
The provisioning and refreshing of the AAA key in the MN and AAA server is outside the scope of this document.
このドキュメントの範囲の外にミネソタと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
この仕様に基づき定義されたReply拡張子がKey Generation Nonces(キーを引き出すのに使用される)を運ぶだけであるので、それらは回復が目的とされた攻撃に使用できた少しのデータも暴露しません。
Perkins & Calhoun Standards Track [Page 17] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[17ページ]RFC3957AAAキー
the key shared between the mobile node and the AAA. The authors do not believe this specification introduces any new security vulnerability.
キーはモバイルノードとAAAを平等に割り当てました。 作者は、この仕様がどんな新しいセキュリティの脆弱性も導入すると信じていません。
10. Acknowledgements
10. 承認
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のメンバー。 特にこのドキュメントの後の改正への多くの原文の改良を寄付したトム・ヒラーをありがとうございます。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[1] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[2]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[3] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response
Extension", RFC 3012, November 2000.
[3] パーキンスとC.とP.カルフーン、「モバイルIPv4挑戦/応答拡大」、RFC3012、2000年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000.
[5] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
[6] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[6]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
1994年12月の[7] イーストレークとD.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750。
[8] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[8] モンテネグロ、G.、および「モバイルIPのためのSunのスキップファイアウォール縦断」、RFC2356、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Perkins & Calhoun Standards Track [Page 18] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[18ページ]RFC3957AAAキー
11.2. Informative References
11.2. 有益な参照
[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.、セントジョンズ、M.、バークリー、S.、ネルソン、D.、パティル、B.、スティーブンス、M.、B.ヴォルフ、「認証、承認、以下を説明すること」。 「プロトコル評価」、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.、ウィレンス、S.、ルーベン、A.、およびA.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[12] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、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認証、承認、および会計要件」、RFC2977(2000年10月)。
[14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions",
Work in Progress, February 2004.
[14] カルフーンとP.とC.パーキンス、「DIAMETERのモバイルIP拡張子」、Progress、2004年2月のWork。
Perkins & Calhoun Standards Track [Page 19] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[19ページ]RFC3957AAAキー
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サーバの操作のために基本型の主な出し物を得るのを試みます。 この情報はRFC2977[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つの管理ドメイン(ホームドメインと呼ばれる)に属すモバイルノードは、しばしば別の管理ドメイン(外国ドメインと呼ばれる)のそばで調達資金を使用する必要があります。 モバイルノードのRegistration Requestを扱う外国人のエージェントがモバイルノードがリソースへのアクセスが受入れられる前に認証できるいくつかの資格証明書を備えるのが必要でありそうです。 モバイルAAA Authentication拡張子[3]の一部としてこれらの資格証明書を提供するかもしれません、このセクションで説明されて、また、RFC2977で説明されるようなAAAインフラストラクチャとRFC3012[3]の存在を当てにして。 そのような資格証明書はモバイルノードのホームドメインの中で実体によって通常管理されます。 また、それらは、必要なら、モバイルノードと外国人のエージェントか、モバイルノードとそのホームのエージェントとの安全なコミュニケーションをセットアップするのに使用されるかもしれません。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | MN = mobile node
| MN |- -|- -| FA | | FA = foreign agent
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
局所領域ホームドメイン+--------------+ +----------------------+ | +------+ | | +------+ | | | | | | | | | | | AAAL| | | | AAAH| | | | +-------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------------+ +------+ | +---+--+ | | | | | | | ミネソタはモバイルノードと等しいです。| ミネソタ|- -|- -| ファ| | FAは外国人のエージェントと等しいです。| | | | | | AAALは地方公共団体+と等しいです。------+ | +------+ | AAAHはホーム権威と等しいです。| | +--------------+
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
外国人のエージェントはしばしば資格証明書について確かめるのに必要であるデータにダイレクトに近づく手段を持っているというわけではありません。 代わりに、外国人のエージェントがモバイルノードには許容できる資格証明書があるという証拠を要求するために、権威(通常同じ外国ドメインの)に相談すると予想されます。 外国人のエージェントと地方公共団体(AAAL)が同じ管理ドメインの一部であるので、彼らは持つために期待しています。
Perkins & Calhoun Standards Track [Page 20] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[20ページ]RFC3957AAAキー
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.
設立されるか、必要な生涯、機密の(アクセス)情報を交換する目的のための安全なチャンネルのために設立できて、または(少なくとも)訪問のモバイルノードから個人的にそれを保っています。
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が構成されると予想されます。 ホームと外国ドメインは、承認を交渉して、また、モバイルノードが外国ドメインの中の移動性エージェントと共にMobility Security Associationsを獲得するのを可能にすることができるように十分なIP Security Associations(すなわち、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.
いったん地方公共団体で承認を得て、権威がうまくいっている交渉に関して外国人のエージェントに通知すると、外国人のエージェントは主要な材料に伴うモバイルノードにRegistration Replyを提供できます。
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図には、多くの異なったホームDomainsからの多くのモバイルノードがあるかもしれません。 それぞれのホームDomainはそのホームDomainによって管理されたモバイルノードから発する資格証明書をチェックできるAAAHを提供します。 7図に内在している機密保護モデルがいます、そして、機密保護モデルで想定された特定のセキュリティ協会を特定するのは重要です。 これらのIP Security Associationsはエイト環で例証されて、比較的長命のセキュリティ協会であると考えられます。
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 Security Associationがあると仮定するのは当然です、それがおよそモバイルノードがホームドメインに属すそれが意味することであるので。
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.
2番目に、図で例証されたモデルから7はそのAAALをきれいにします、そして、AAAHはIP Security Associationを共有しなければなりません、さもなければ、彼らが認証結果、承認、およびそれらの間で商取引されるかもしれない会計データさえ当てにすることができなかったので。 しかしながら、そのような双方のIP Security Associationsを必要とするのは結局、スケーラブルではありません。 AAAフレームワークは、よりスケーラブルなメカニズムに備えなければなりませんが、このドキュメントのための範囲の外にそのようなブローカーモデルが創造されることになっているメソッドがあります。 その他の詳細に関してRFC2977を見てください。
Perkins & Calhoun Standards Track [Page 21] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[21ページ]RFC3957AAAキー
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図から、外国人のエージェントが自然にIP Security AssociationをAAALと共有できるのは、明確です。 に加えてそして、外国人のエージェントにはモバイルノードにローカル資源を割り当てるのが許されているのを見つける方法がなければならないのでモデルが働くのにこれが必要である、あらゆるうまくいっているRegistration Replyをモバイルノードに伝えてください。
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.
エイト環は私たちが私たちの提案されたモデルから理解したIP Security Associationsを例証します。 彼らが、よりスケーラブルなファッションで安全なトランザクションを仲裁するのを助けるためにAAALとAAAHの間に挿入された第三者がAAALとAAAHの間の合意でいるかもしれないことに注意してください。 そのような第三者処理を可能にするように設計されているブローカーモデルがモバイルIP拡大へのどんな効果も本書では指定させるべきでないので、記述を全くここに提供しません。 その他の詳細のためのRFC2977[13]を見てください。
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
MN = mobile node | | | |
FA = foreign agent | FA | | MN |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
+------+ +------+ | | | | | AAAL+--------------+ AAAH| | | | | +---+--+ +--+---+ | | | | +---+--+ +--+---モバイル+ ミネソタ=ノード| | | | FAは外国人のエージェントと等しいです。| ファ| | ミネソタ| AAALは地方公共団体と等しいです。| | | | AAAHはホーム権威+と等しいです。------+ +------+
Figure 8: IP Security Associations
エイト環: 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 Security Associationsの正確な選択がこのドキュメントの範囲を超えていると考えます。 選択がモバイルIPに頼りそうにはありませんか、または例証された一般的なモデルのどんな特定の特徴も7について計算します。 他方では、モバイルIP実体の間で必要であるMobility Security Associationsは主要な派生拡大のデザインで中央に本書では重要です。
Perkins & Calhoun Standards Track [Page 22] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[22ページ]RFC3957AAAキー
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つの詳細が言及に値します。 モバイルノードと外国人のエージェントの間に設立されるべきMobility Security Associationはモバイルノードに関してまた、外国人のエージェントに伝えられなければなりません。 以下の要件は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プロトコル処理としてキーが外国人のエージェント(または、ホームのエージェント)に分配される方法が扱われると予想されます。 そのような処理は、このドキュメントの範囲の外にありますが、上記の要件を満たさなければなりません。
Perkins & Calhoun Standards Track [Page 23] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[23ページ]RFC3957AAAキー
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.Challenge値で説明されたAAAインフラストラクチャから主要な登録を要求して、受けるためにメッセージ流れを示していますが、追加反復操作による保護のためにAdvertisementとRegistrationメッセージに追加されるかもしれませんが、ここで例証されません。
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.--| |
| | |
MnファAAAインフラストラクチャ| | | | <、-、-- 広告-----| | | (必要であるなら) | | | | | |-- RReq+AAAの主要なReq、-->|、|、| |--- RReq+AAAの主要なReq。--->|、|、|、|、| | <、-、-- RRep+AAA Key下院議員---| | <-- RRep+AAA Key下院議員--| | | | |
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. 外国人のエージェントはエージェントAdvertisementを広めます。 モバイルノード(ダイヤグラムで、目立たない)からエージェントSolicitationを受けた後に、この広告は製作されたかもしれません。
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. モバイルノードは必要に応じて必要に応じて承認のエネイブリングである認証拡大と共にモバイルIP[1]でミネソタ-HA AAA KeyGen Request、そして/または、ミネソタ-FA AAA KeyGen Requestを含むRegistration Requestを作成します。
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 InfrastructureにRegistration Request、そして/または、Key Request(s)をリレーします(付録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
4. 外国人のエージェントはモバイルノードのために接続性を認可するための適切な指摘でAAA Responseを受け取ります。 また、このAAA Responseと共に、外国人のエージェントはそれとそのローカルのAAAインフラストラクチャとのコミュニケーションに、適切な何らかの安全なメソッドで主要な材料を受け取るかもしれません。 ここ
Perkins & Calhoun Standards Track [Page 24] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[24ページ]RFC3957AAAキー
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).
外国人のエージェントがRegistration Requestをリレーしていなくて、それは、直接ホームのエージェントにそれを送って、Registration Reply(図では、目立たない)を待っています。
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. 外国人のエージェントは、モバイルノードによって使用されて、関連移動性エージェント(外国人のエージェント、そして/または、ホームのエージェント)と共にMobility Security Associationsを設立するために新しい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.
モバイルノードがAAA Infrastructureから求められていない合わせることの材料を受けるとき、ダイヤグラム10はケースのためにメッセージ流動を例証します。
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
| ------ RReq --------->| |
| |------- RReq ------------->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
MnファAAAインフラストラクチャ| | | | <、-、-- 広告-----| | | (必要であるなら) | | | | | | ------ RReq--------->|、|、| |------- RReq------------->|、|、|、|、| | <、-、-- RRep+AAA Key下院議員---| | <-- RRep+AAA Key下院議員--| | | | |
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. 外国人のエージェントはエージェントAdvertisementを広めます。 モバイルノード(ダイヤグラムで、目立たない)からエージェントSolicitationを受けた後に、この広告は製作されたかもしれません。
2. The mobile node creates a Registration Request including an
authorization-enabling authentication extension as required by
Mobile IP [1].
2. モバイルノードは必要に応じてモバイルIP[1]で承認のエネイブリングである認証拡大を含むRegistration Requestを作成します。
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 Request(ことによると、Registration Requestを含んでいる)を局所的に構成されたAAA Infrastructureに送ります(付録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
4. 外国人のエージェントはモバイルノードのために接続性を認可するための適切な指摘でAAA Responseを受け取ります。 また、このAAA Responseと共に、外国人のエージェントはそれとそのローカルのAAAインフラストラクチャとのコミュニケーションに、適切な何らかの安全なメソッドで主要な材料を受け取るかもしれません。 ここにエージェントが外国であるならRegistration Requestをリレーしていない、それ
Perkins & Calhoun Standards Track [Page 25] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[25ページ]RFC3957AAAキー
forwards it directly to the Home Agent and waits for a
Registration Reply (not shown in the figure).
直接ホームのエージェントにそれを送って、Registration Reply(図では、目立たない)を待っています。
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. 外国人のエージェントは、モバイルノードによって使用されて、関連移動性エージェント(外国人のエージェント、そして/または、ホームのエージェント)と共にMobility Security Associationsを設立するために新しいKeyGen Reply拡張子に伴うモバイルノードにRegistration Replyをリレーします。
Authors' Addresses
作者のアドレス
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625-2986 Fax: +1 650 625-2502 EMail: charles.perkins@nokia.com
以下に電話をしてください。 +1 650 625-2986Fax: +1 650 625-2502 メールしてください: charles.perkins@nokia.com
Pat R. Calhoun Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134 USA
パットR.カルフーンAirespace Inc.110Nortech Parkwayカリフォルニア95134サンノゼ(米国)
Phone: +1 408 635 2000 Fax: +1 408 635 2020 EMail: pcalhoun@airespace.com
以下に電話をしてください。 +1 408 635、2000Fax: +1 2020年の408 635メール: pcalhoun@airespace.com
Perkins & Calhoun Standards Track [Page 26] RFC 3957 AAA Keys for Mobile IPv4 March 2005
モバイルIPv4 March 2005のためのパーキンスとカルフーン標準化過程[26ページ]RFC3957AAAキー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Perkins & Calhoun Standards Track [Page 27]
パーキンスとカルフーン標準化過程[27ページ]
一覧
スポンサーリンク
