この文書はRFC2977の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group S. Glass
Request for Comments: 2977 Sun Microsystems
Category: Informational T. Hiller
Lucent Technologies
S. Jacobs
GTE Laboratories
C. Perkins
Nokia Research Center
October 2000
Mobile IP Authentication, Authorization, and Accounting Requirements
モバイルＩＰの認証と認可と課金必要条件
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
概要
The Mobile IP and Authentication, Authorization, Accounting (AAA)
working groups are currently looking at defining the requirements for
Authentication, Authorization, and Accounting. This document
contains the requirements which would have to be supported by a AAA
service to aid in providing Mobile IP services.
モバイルＩＰと認証認可課金（ＡＡＡ）作業グループが、現在、認証と認可
と課金の必要条件の定義を見ています。この文書はモバイルＩＰサービスの
供給を援助するためＡＡＡサービスがサポートしなければならないであろう
必要条件を含んでいます。
1. Introduction
1. はじめに
Clients obtain Internet services by negotiating a point of attachment
to a "home domain", generally from an ISP, or other organization from
which service requests are made, and fulfilled. With the increasing
popularity of mobile devices, a need has been generated to allow
users to attach to any domain convenient to their current location.
In this way, a client needs access to resources being provided by an
administrative domain different than their home domain (called a
"foreign domain"). The need for service from a foreign domain
requires, in many models, Authorization, which leads directly to
Authentication, and of course Accounting (whence, "AAA"). There is
some argument which of these leads to, or is derived from the others,
but there is common agreement that the three AAA functions are
closely interdependent.
クライアントが一般に、サービスのリクエストが作られ実施されるＩＳＰや
たの組織から得られる、「ホームドメイン」への接続点との交渉によって、イ
ンターネットサービスを獲得します。移動装置の人気の増加で、ユーザが現
在の場所に近いドメインに接続することを許す要求が生まれました。このよ
うにして、クライアントがホームドメインと異なる管理者のドメイン（「外部
ドメイン」と呼ばれる）によって供給される資源へのアクセスを必要としま
す。外部ドメインからのサービスの必要は、多くのモデルで、直接認証に導
く認可ともちろん課金（すなわち「ＡＡＡ」）を必要とします。これらから得
られる、あるいは、これらを導くいくつかの議論がありますが、３つのＡＡ
Ａ機能が密接に関係するという共通認識があります。
An agent in a foreign domain, being called on to provide access to a
resource by a mobile user, is likely to request or require the client
to provide credentials which can be authenticated before access to
resources is permitted. The resource may be as simple as a conduit
to the Internet, or may be as complex as access to specific private
resources within the foreign domain. Credentials can be exchanged in
many different ways, all of which are beyond the scope of this
document. Once authenticated, the mobile user may be authorized to
access services within the foreign domain. An accounting of the
actual resources may then be assembled.
移動ユーザへ資源へのアクセスを供給するために呼ばる、外部ドメインのエー
ジェントが、資源へのアクセスが認められる前に許可を証明する資格証明を
供給することをクライアントに求めるかあるいは必要とする可能性が高いで
す。資源はインターネット接続のような単純なものかもしれず、外部ドメイ
ンの特定のプライベート資源へのアクセスのように複雑かもしれません。資
格証明が多くの異なった方法で交換ができ、そしてそのすべてはこの文書の
範囲外です。一度認証されると、移動ユーザは外部ドメイン内でサービスに
アクセスする権限を与えられるかもしれません。実際の資源の課金がそれか
ら組み立てられるかもしれません。
Mobile IP is a technology that allows a network node ("mobile node")
to migrate from its "home" network to other networks, either within
the same administrative domain, or to other administrative domains.
The possibility of movement between domains which require AAA
services has created an immediate demand to design and specify AAA
protocols. Once available, the AAA protocols and infrastructure will
provide the economic incentive for a wide-ranging deployment of
Mobile IP. This document will identify, describe, and discuss the
functional and performance requirements that Mobile IP places on AAA
protocols.
モバイルＩＰはその「ホーム」ネットワークから他のネットワークに、同じ
管理ドメイン内で、あるいは他の管理ドメインにネットワークノード（「移動
ノード」）が移動することを許す技術です。ＡＡＡサービスを必要とするドメ
イン間の動は、ＡＡＡプロトコルの設計と指定の直前の要求を作りました。
一度利用可能になると、ＡＡＡプロトコルとインフラはモバイルＩＰの広範
囲な展開のための経済の誘因を供給するでしょう。この文書は機能的なＡＡ
Ａプロトコル上のモバイルＩＰの機能と性能の必要条件を識別し、記述し、
論じるでしょう。
The formal description of Mobile IP can be found in [13,12,14,17].
モバイルＩＰの正式な記述は[13,12,14,17]で見いだすことができます。
In this document, we have attempted to exhibit requirements in a
progressive fashion. After showing the basic AAA model for Mobile
IP, we derive requirements as follows:
この文書で、我々は革新的方法で必要条件を示そうと試みました。モバイル
ＩＰのための基本的なＡＡＡモデルを見た後で、我々は次のように必要条件
を得ます：
- requirements based on the general model
- 一般的なモデルに基づいた必要条件
- requirements based on providing IP service for mobile nodes
- 移動ノードにＩＰサービスを提供することに基づく必要条件
- requirements derived from specific Mobile IP protocol needs
- 特定のモバイルＩＰプロトコルの要求から生じる必要条件。
Then, we exhibit some related AAA models and describe requirements
derived from the related models.
それから、我々はある関連したＡＡＡモデルを示し、そして関連したモデル
から得らる必要条件を記述します。
2. Terminology
2. 用語
This document frequently uses the following terms in addition to
those defined in RFC 2002 [13]:
この文書はＲＦＣ２００２[13]で定義された用語以外に、しばしば次の用語
を使います：
Accounting The act of collecting information on resource usage
for the purpose of trend analysis, auditing, billing,
or cost allocation.
課金 傾向分析や会計監査や請求処理やコスト配分の目的で、資
源使用についての情報を集める行為。
Administrative Domain
An intranet, or a collection of networks, computers,
and databases under a common administration.
Computer entities operating in a common
administration may be assumed to share
administratively created security associations.
管理ドメイン イントラネットや、共通の管理下のネットワークとコンピュー
タとデータベース集合。共通管理下で運営しているコンピュー
タが管理的に作られたセキュリティアソシエーションを共
有すると仮定されるかもしれません。
Attendant A node designed to provide the service interface
between a client and the local domain.
随行装置 クライアントとローカルドメイン間にサービスインタフェース
を供給するよう意図されたノード。
Authentication
The act of verifying a claimed identity, in the form
of a pre-existing label from a mutually known name
space, as the originator of a message (message
authentication) or as the end-point of a channel
(entity authentication).
認証 相互に周知の名前空間からの事前登録されたラベルを、メッ
セージの生成者（メッセージ認証）やチャネルの終端（エ
ンティティー認証）として、要求された識別子を確かめる
行為。
Authorization
The act of determining if a particular right, such as
access to some resource, can be granted to the
presenter of a particular credential.
認可 特定の資格証明の提出者に、ある資源へのアクセスのよう
な、特定の権利が与えられることを決定する行為。
Billing The act of preparing an invoice.
請求処理 明細書を準備する行為。
Broker An intermediary agent, trusted by two other AAA
servers, able to obtain and provide security services
from those AAA servers. For instance, a broker may
obtain and provide authorizations, or assurances that
credentials are valid.
ブローカー 他の２つのＡＡＡサーバが信頼し、それらのＡＡＡサーバ
からセキュリティサービスを得てまた供給することが可能
な、仲介エージェント。例えば、ブローカが認可や資格証
明が正当であるという保証を得てたり供給するかもしれま
せん。
Client A node wishing to obtain service from an attendant
within an administrative domain.
クライアント 管理ドメイン内で随行装置からサービスを得ることを望ん
でいるノード。
Foreign Domain
An administrative domain, visited by a Mobile IP
client, and containing the AAA infrastructure needed
to carry out the necessary operations enabling Mobile
IP registrations. From the point of view of the
foreign agent, the foreign domain is the local
domain.
外部ドメイン モバイルＩＰクライアントが訪問し、そしてモバイルＩＰ
登録に必要オペレーションを実行するために必要なＡＡＡ
インフラを含む、管理ドメイン。外部エージェントから見
ると、外部ドメインはローカルドメインです。
Inter-domain Accounting
Inter-domain accounting is the collection of
information on resource usage of an entity with an
administrative domain, for use within another
administrative domain. In inter-domain accounting,
accounting packets and session records will typically
cross administrative boundaries.
ドメイン間課金
ドメイン間課金は、他の管理ドメインが使用するために、
管理ドメインでエンティティが使用した資源の情報の収集
です。ドメイン間課金で、課金パケットとセッションレコー
ドが典型的に管理境界を超えるでしょう。
Intra-domain Accounting
Intra-domain accounting is the collection of
information on resource within an administrative
domain, for use within that domain. In intra-domain
accounting, accounting packets and session records
typically do not cross administrative boundaries.
ドメイン内課金
ドメイン内課金は、その管理ドメイン内で使うため、管理
ドメイン内で資源の情報の収集です。ドメイン内課金で、
課金パケットとセッションレコードが典型的に管理境界を
通過しません。
Local Domain
An administrative domain containing the AAA
infrastructure of immediate interest to a Mobile IP
client when it is away from home.
ローカルドメイン
モバイルＩＰクライアントがホームを出た際に直接対応す
るＡＡＡインフラを含む管理ドメイン。
Real-time Accounting
Real-time accounting involves the processing of
information on resource usage within a defined time
window. Time constraints are typically imposed in
order to limit financial risk.
リアルタイム課金
リアルタイム課金は、定義された時間内での資源利用の情
報の処理を含みます。時間制約は典型的に金融リスクを制
限するために課せられます。
Session record
A session record represents a summary of the resource
consumption of a user over the entire session.
Accounting gateways creating the session record may
do so by processing interim accounting events.
セッションレコード
セッションレコードが全部セッションでのユーザの資源消
費の合計を表します。セッションレコードを作る課金ゲー
トウェイは仮課金イベントを処理することで作るかもしれ
ません。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [4].
この文書で、キーワード"MAY"と"MUST"と"MUST NOT"と"optional"と
"recommended"と"SHOULD"と"SHOULD NOT"は[4]で記述されるように解釈します。
3. Basic Model
3. 基本的なモデル
In this section, we attempt to capture the main features of a basic
model for operation of AAA servers that seems to have good support
within the Mobile IP working group. Within the Internet, a client
belonging to one administrative domain (called the home domain) often
needs to use resources provided by another administrative domain
(called the foreign domain). An agent in the foreign domain that
attends to the client's request (call the agent the "attendant") is
likely to require that the client provide some credentials that can
be authenticated before access to the resources is permitted. These
credentials may be something the foreign domain understands, but in
most cases they are assigned by, and understood only by the home
domain, and may be used for setting up secure channels with the
mobile node.
この章で、我々はモバイルＩＰ作業グループで良く検討されているように思
われるＡＡＡサーバのオペレーションの基本的なモデルの主な特徴を得よう
と試みます。インターネットの中で、１つの管理ドメイン（ホームドメイン
と呼ばれる）に属しているクライアントが、しばしば他の管理ドメイン（外
部ドメインと呼ばれる）の供給する資源を使用する必要があります。クライ
アントの要求に対応する外部ドメインのエージェント（エージェントを「随
行装置」と呼んでください）が、クライアントが資源にアクセスするのを認
められる前に、本人証明の資格証明を供給することを要求する可能性が高い
です。これらの資格は外部ドメインが理解する何かであるかもしれませんが、
たいていの場合うそれらはホームドメインが割当てホームドメインだけが理
解でき、そして移動ノードの安全なチャネルを準備するために使われるかも
しれません。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C |- -|- -| A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Figure 1: AAA Servers in Home and Local Domains
図１：ホームとローカルドメインでのＡＡＡサーバ
The attendant often does not have direct access to the data needed to
complete the transaction. Instead, the attendant is expected to
consult an authority (typically in the same foreign domain) in order
to request proof that the client has acceptable credentials. Since
the attendant and the local authority 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.
随行装置はしばしば取引を完了するために必要なデータへの直接のアクセス
を持ちません。その代わりに、随行装置は、クライアントが資格を持つとい
う証明を求めるために（典型的に同じ外部ドメインにある）権威に相談する
ことを期待されます。随行装置とローカルな権威が同じ管理ドメインの一部
であるから、機密性が高い（アクセス）情報を交換し、そして（少なくとも）
訪問している移動ノードからそれを隠す目的のための、安全なチャネルを確
立している、又は必要な期間確立する、ことが期待されます。
The local authority (AAAL) itself may not have enough information
stored locally to carry out the verification for the credentials of
the client. In contrast to the attendant, however, the AAAL is
expected to be configured with enough information to negotiate the
verification of client credentials with external authorities. The
local and the external authorities should be configured with
sufficient security relationships and access controls so that they,
possibly without the need for any other AAA agents, can negotiate the
authorization that may enable the client to have access to any/all
requested resources. In many typical cases, the authorization
depends only upon secure authentication of the client's credentials.
ローカル権威（ＡＡＡＬ）はクライアントの資格証明の証明に十分な情報を
ローカルに持っていないかもしれません。しかしながらＡＡＡＬは、随行装
置と比べて、外部権威とクライアント資格の証明を交渉するのに十分な情報
を設定されることを期待されます。多分他のＡＡＡエージェントの必要なし
で、クライアントが要求した資源の一部／全部にアクセスを持つことができ
るように認可の交渉することができるように、ローカル権威と外部権威は十
分なセキュリティ関係とアクセス制御で配置されるべきです。多くの典型的
な場合に、認可はクライアントの資格のセキュリティが高い認証にだけ依存
します。
Once the authorization has been obtained by the local authority, and
the authority has notified the attendant about the successful
negotiation, the attendant can provide the requested resources to the
client.
認可がローカル権威によって得られ、そして権威が随行装置に交渉成功を通
知したら、随行装置はクライアントに求められた資源を供給することができ
ます。
In the picture, there might be many attendants for each AAAL, and
there might be many clients from many different Home Domains. Each
Home Domain provides a AAAH that can check credentials originating
from clients administered by that Home Domain.
図で、各ＡＡＡＬに多くの随行装置があるかもしれません、そして多くの異
なったホームドメインからの多くのクライアントがあるかもしれません。各
ホームドメインが、そのホームドメインが運営するクライアントの資格証明
を検査できるＡＡＡＨを供給します。
There is a security model implicit in the above figure, and it is
crucial to identify the specific security associations assumed in the
security model.
上記の数字で暗黙のセキュリティモデルがあります、そしてセキュリティモ
デルで仮定された特定のセキュリティアソシエーションを認識する事は重要
です。
First, it is natural to assume that the client has a security
association with the AAAH, since that is roughly what it means for
the client to belong to the home domain.
最初に、クライアントがホームドメインに属すると言えるので、クライアン
トがＡＡＡＨとセキュリティアソシエーションを持っていると想定すること
は自然です。
Second, from the model illustrated in figure 1 it is clear that AAAL
and AAAH have to share a 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 security relationships is, however, in the
end not scalable; the AAA framework MUST provide for more scalable
mechanisms, as suggested below in section 6.
第二に、図１で例示されたモデルからＡＡＡＬとＡＡＡＨがセキュリティア
ソシエーションを共有しなければならないことは明確です、そうでなければ
それらの間で処理されるかもしれない認証成果や認可や課金データさえも転
送できません。しかしながら、このような双方のセキュリティ関係を必要と
することは結局スケーラブルではありません；ＡＡＡ機構は、下記の６章で
提案されるように、スケーラブルなメカニズムに備えなくてはなりません
(MUST)。
Finally, in the figure, it is clear that the attendant can naturally
share a security association with the AAAL. This is necessary in
order for the model to work because the attendant has to know that it
is permissible to allocate the local resources to the client.
最後に、図で、最終的に、数字で、随行装置が当然ＡＡＡＬとセキュリティ
アソシエーションを共有できることは明確です。これはモデルが動作するに
は、クライアントにローカル資源の割当てが許されることを随行装置が知ら
なければならないから、必要です。
As an example in today's Internet, we can cite the deployment of
RADIUS [16] to allow mobile computer clients to have access to the
Internet by way of a local ISP. The ISP wants to make sure that the
mobile client can pay for the connection. Once the client has
provided credentials (e.g., identification, unique data, and an
unforgeable signature), the ISP checks with the client's home
authority to verify the signature, and to obtain assurance that the
client will pay for the connection. Here, the attendant function can
be carried out by the NAS, and the local and home authorities can use
RADIUS servers. Credentials allowing authorization at one attendant
SHOULD be unusable in any future negotiations at the same or any
other attendant.
例えば今日のインターネットで、モバイルコンピュータクライアントがロー
カルＩＳＰ経由でインターネットにアクセスを持つことを許すために、ラディ
ウス[16]を展開してるのを引用できます。ＩＳＰは移動クライアントが接続
に対して支払うことができることを確認することを望みます。クライアント
が資格証明を供給したら（例えば、識別子やユニークデータや偽造できない
署名）ならば、ＩＳＰはクライアントのホーム権威に問い合わせて署名を検
証し、クライアントが接続に対して支払う保証を得ます。ここで、随行装置
機能はＮＡＳによって遂行できます、そしてローカル権威とホーム権威はラ
ディウスサーバを使うことができます。１つの随行装置での認可を許してい
る資格証明は、同じあるいは他の随行装置での、将来の交渉でも使用できな
いべきです(SHOULD)。
From the description and example above, we can identify several
requirements.
上記の記述と例から、我々はいくつかの必要条件を認識できます。
- Each local attendant has to have a security relationship with the
local AAA server (AAAL)
- 各ローカル随行装置がローカルＡＡＡサーバ（ＡＡＡＬ）とのセキュリ
ティ関係を持たなければなりません。
- The local authority has to share, or dynamically establish,
security relationships with external authorities that are able to
check client credentials
- ローカル権威はクライアント資格をチェックすることが可能な外部権威
とのセキュリティ関係を共有するか、あるいはダイナミックに確立しな
ければなりません。
- The attendant has to keep state for pending client requests while
the local authority contacts the appropriate external authority
- 随行装置は、ローカル権威が適切な外部権威と連絡を取る間に、クライア
ント要請の状態を留めておかなければなりません。
- Since the mobile node may not necessarily initiate network
connectivity from within its home domain, it MUST be able to
provide complete, yet unforgeable credentials without ever having
been in touch with its home domain.
- 移動ノードがホームドメインからネットワーク接続を始めないかもしれな
いので、過去にホームドメインと接触しなくても完全な偽造できない資格
証明を供給できなければなりません(MUST)。
- Since the mobile node's credentials have to remain unforgeable,
intervening nodes (e.g., neither the attendant or the local
authority (AAAL) or any other intermediate nodes) MUST NOT be able
to learn any (secret) information which may enable them to
reconstruct and reuse the credentials.
- 移動ノードの資格証明が偽造されてはならないから、中間ノードは資格証
明の再構築や再利用が可能となるいかなる（秘密）情報を学べてはなりま
せん(MUST NOT)。
From this last requirement, we can see the reasons for the natural
requirement that the client has to share, or dynamically establish, a
security relationship with the external authority in the Home Domain.
Otherwise, it is technically infeasible (given the implied network
topology) for the client to produce unforgeable signatures that can
be checked by the AAAH. Figure 2 illustrates the natural security
associations we understand from our proposed model. Note that,
according to the discussion in section 6, there may, by mutual
agreement between AAAL and AAAH, be a third party inserted between
AAAL and AAAH to help them arbitrate secure transactions in a more
scalable fashion.
この最後の必要条件から、我々はクライアントが共有するか、あるいは動的
に確立しなければならない自然の必要条件、ホームドメインの外部権威との
セキュリティ関係の理由を見ることができます。さもなければ、それはクラ
イアントがＡＡＡＨが検査できる偽造できない署名を作り出すことが（暗黙
のネットワークトポロジーの条件下で）技術的に不可能です。図２は我々が
提案するモデルから理解する自然のセキュリティアソシエーションを例示し
ます。それが、６章の論議によれば、ＡＡＡＬとＡＡＡＨ間の相互の合意に
よって、よりスケーラブルな方法でセキュリティ処理を行うのと手伝うため
ＡＡＡＬとＡＡＡＨ間に第三者がいるかもしれないことに注意してください。
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
C = client | | | |
A = attendant | A | | C |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
Figure 2: Security Associations
図２：セキュリティアソシエーション
In addition to the requirements listed above, we specify the
following requirements which derive from operational experience with
today's roaming protocols.
上にリストアップされた必要条件のほかに、我々は今日のローミングプロト
コルの運用経験から生じる次の必要条件を指定します。
- There are scenarios in which an attendant will have to manage
requests for many clients at the same time.
- 随行装置が同時に多くのクライアントの要請を管理しなければならないシ
ナリオがあります。
- The attendant MUST protect against replay attacks.
- 随行装置を再生攻撃から保護しなくてはなりません(MUST)。
- The attendant equipment should be as inexpensive as possible,
since it will be replicated as many times as possible to handle as
many clients as possible in the foreign domain.
- 外部ドメインで可能な限り多くのクライアントを可能な限り何度も処理す
るので、随行装置装置は可能な限り高価でないべきです。
- Attendants SHOULD be configured to obtain authorization, from a
trusted local AAA server (AAAL) for Quality of Service
requirements placed by the client.
- 随行装置がクライアントが求めたサービス品質条件のために、信頼できる
ローカルＡＡＡサーバ（ＡＡＡＬ）から認可を得るように設定されるべき
です(SHOULD)。
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 security associations between the AAA servers to be
beyond the scope of this document. The choices are unlikely even to
depend upon any specific features of the general model illustrated in
figure 1. On the other hand, the security associations needed
between Mobile IP entities will be of central importance in the
design of a suitable AAA infrastructure for Mobile IP. The general
model shown above is generally compatible with the needs of Mobile
IP. However, some basic changes are needed in the security model of
Mobile IP, as detailed in section 5.
２つの別の管理ドメイン（例えばＡＡＡＨとＡＡＡＬ）の中のノードがしば
しば、通信相手の識別子を確かめるか、代わりに通信を補いデータのプライ
バシーを保証するのに、追加の手順を要さなくてはなりません。これらの考
慮が重要なセキュリティ条件を導くが、上記の通りサーバ間のセキュリティ
について、我々はＡＡＡサーバ間のセキュリティアソシエーションの正確な
選択がこの文書の範囲外と考えます。選択は図１で例示した一般的なモデル
の特定の機能に依存はしそうもありません。他方、モバイルＩＰエンティティ
間で必要とされるセキュリティアソシエーションは、モバイルＩＰのために
適当なＡＡＡインフラの設計で中央の重要な装置が必要でしょう。上記の一
般的なモデルは一般にモバイルＩＰの要求と互換性があります。しかしなが
ら、５章で詳述されるように、ある基本的な変更がモバイルＩＰのセキュリ
ティモデルで必要とされます。
Lastly, recent discussion in the mobile-ip working group has
indicated that the attendant MUST be able to terminate service to the
client based on policy determination by either AAAH or AAAL server.
最後に、モバイルＩＰ作業グループでの最近の論議が、付随装置ＡＡＡＨか
ＡＡＡＬサーバの決定したポリシーに基き、クライアントサービスを終端で
きなければならないことを示しました(MUST)。
3.1. AAA Protocol Roaming Requirements
3.1. ＡＡＡプロトコルローミング必要条件。
In this section we will detail additional requirements based on
issues discovered through operational experience of existing roaming
RADIUS networks. The AAA protocol MUST satisfy these requirements in
order for providers to offer a robust service. These requirements
have been identified by TR45.6 as part of their involvement with the
Mobile IP working group.
この章で我々は既存のローミングラディウスネットワークの運用経験を通し
て発見された問題に基づいて追加の必要条件を記述するでしょう。ＡＡＡプ
ロトコルはプロバイダが強靭なサービスを提供するためにこれらの必要条件
を満たさなくてはなりません。これらの必要条件は、モバイルＩＰ作業グルー
プの掛かり合いの一部としてTR４５.６で識別されました(MUST)。
- Support a reliable AAA transport mechanism.
- 信頼性が高いＡＡＡ転送メカニズムをサポート
* There must be an effective hop-by-hop retransmission and
failover mechanism so that reliability does not solely depend
on end-to-end retransmission
* 信頼性がエンドエンド再送に依存しないように、効率的なホップ毎再
送と故障切替メカニズムがあるに違いありません。
* This transport mechanism will be able indicate to an AAA
application that a message was delivered to the next peer AAA
application or that a time out occurred.
* この転送メカニズムはＡＡＡアプリケーションにメッセージが次のピ
アＡＡＡアプリケーションに届けられたか、あるいはタイムアウトが
起こったかを示すことができるでしょう。
* Retransmission is controlled by the reliable AAA transport
mechanism, and not by lower layer protocols such as TCP.
* 再送がＴＣＰのようなより低いレイヤプロトコルによってではなく、
信頼性が高いＡＡＡ転送メカニズムによってコントロールされます。
* Even if the AAA message is to be forwarded, or the message's
options or semantics do not conform with the AAA protocol, the
transport mechanism will acknowledge that the peer received the
AAA message.
* たとえＡＡＡメッセージが転送されるか、メッセージのオプションか
意味がＡＡＡプロトコルに従わないとしても、転送機構は相手がＡＡ
Ａメッセージを受け取ったことを認めるでしょう。
* Acknowledgements SHOULD be allowed to be piggybacked in AAA
messages
* 受取りの通知がＡＡＡメッセージに便乗されることを許されるべきで
す(SHOULD)。
* AAA responses have to be delivered in a timely fashion so that
Mobile IP does not timeout and retransmit
* ＡＡＡ回答がモバイルＩＰがタイムアウトや再送しないようにタイム
リーな方法で届けられなければなりません。
- Transport a digital certificate in an AAA message, in order to
minimize the number of round trips associated with AAA
transactions. Note: This requirement applies to AAA applications
and not mobile stations. The certificates could be used by
foreign and home agents to establish an IPSec security association
to secure the mobile node's tunneled data. In this case, the AAA
infrastructure could assist by obtaining the revocation status of
such a certificate (either by performing online checks or
otherwise validating the certificate) so that home and foreign
agents could avoid a costly online certificate status check.
- ＡＡＡ処理に関連したメッセージの往復回数を最小にするため、ＡＡＡメッ
セージでデジタルの証明書を送信。メモ：この必要条件は移動端末にではな
く、ＡＡＡアプリケーションに当てはまります。証明書は、移動ノードのト
ンネルデータを安全にするＩＰＳｅｃセキュリティアソシエーション確立の
ため外部とホームエージェントで使用できます。この場合、ＡＡＡインフラ
は、ホームと外部エージェントが高価なオンラインの証明書状態検査を避け
ることができるように、このような証明書の廃止状態を得ることを助ける事
ができます（オンライン検査を実行するか、証明書を検証することで）。
- Provide message integrity and identity authentication on a hop-
by-hop (AAA node) basis.
- ホップ毎（ＡＡＡノード）ベースで、メッセージ完全性と固体認証を供給。
- Support replay protection and optional non-repudiation
capabilities for all authorization and accounting messages. The
AAA protocol must provide the capability for accounting messages
to be matched with prior authorization messages.
- すべての認可と課金メッセージのために再生保護と任意(optional)の非拒絶
能力をサポートしてください。ＡＡＡプロトコルは事前の認可メッセージと
課金メッセージを対応させる能力を提供しなくてはなりません。
- Support accounting via both bilateral arrangements and via broker
AAA servers providing accounting clearinghouse and reconciliation
between serving and home networks. There is an explicit agreement
that if the private network or home ISP authenticates the mobile
station requesting service, then the private network or home ISP
network also agrees to reconcile charges with the home service
provider or broker. Real time accounting must be supported.
Timestamps must be included in all accounting packets.
- 両方の双方の取り決めと、提供ネットワークとホームネットワーク間の課
金クリアリングハウスと仲介を供給しているブローカＡＡＡサーバによる、
課金サポート。もしプライベートネットワークとホームＩＳＰがサービス
を求めている移動端末を認証するなら、プライベートネットワークあるい
はホームＩＳＰネットワークが、ホームサービスプロバイダかブローカと
課金を整合させることに同意するという明示的な合意があります。リアル
タイム課金がサポートされなくてはなりません。時刻表示はすべての課金
パケットに含められなくてはなりません。
4. Requirements related to basic IP connectivity
4. 基本的なＩＰ接続性と関係がある必要条件
The requirements listed in the previous section pertain to the
relationships between the functional units, and don't depend on the
underlying network addressing. On the other hand, many nodes (mobile
or merely portable) are programmed to receive some IP-specific
resources during the initialization phase of their attempt to connect
to the Internet.
前の章でリストアップされた必要条件は機能単位間の関係に関係があって、
そして基礎となるネットワークアドレスに依存しません。他方（移動、ある
いはただポータブルな）多くのノードがインターネット接続する試みの初期
化フェーズの間にあるＩＰ特有の資源を受け取るためにプログラムされます。
We place the following additional requirements on the AAA services in
order to satisfy such clients.
我々はこのようなクライアントを満足させるためＡＡＡサービス上に次の追
加の必要条件を設定します。
- Either AAA server MUST be able to obtain, or to coordinate the
allocation of, a suitable IP address for the customer, upon
request by the customer.
- ＡＡＡサーバが顧客の要求で顧客に適切なＩＰアドレスを得るか割当て
を調整することができなければなりません(MUST)。
- AAA servers MUST be able to identify the client by some means
other than its IP address.
- ＡＡＡサーバはＩＰアドレス以外の手段によってクライアントを識別す
ることができなければなりません(MUST)。
Policy in the home domain may dictate that the home agent instead of
the AAAH manages the allocation of an IP address for the mobile node.
AAA servers MUST be able to coordinate the allocation of an IP
address for the mobile node at least in this way.
ホームドメインのポリシーが、ＡＡＡＨの代わりのホームエージェントが移
動ノードのＩＰアドレスの割当を管理することを必要とするかもしれません。
ＡＡＡサーバは少なくともこのようにして移動ノードのＩＰアドレス割当を
調整することができなければなりません(MUST)。
AAA servers today identify clients by using the Network Access
Identifier (NAI) [1]. A mobile node can identify itself by including
the NAI along with the Mobile IP Registration Request [6]. The NAI
is of the form "user@realm"; it is unique and well suited for use in
the AAA model illustrated in figure 1. Using a NAI (e.g.,
"user@realm") allows AAAL to easily determine the home domain (e.g.,
"realm") for the client. Both the AAAL and the AAAH can use the NAI
to keep records indexed by the client's specific identity.
今日のＡＡＡサーバが、ネットワークアクセス識別子（ＮＡＩ）[1]を使う
ことによってクライアントを識別します。移動ノードがモバイルＩＰ登録
要請[6]にＮＡＩを含めることによって、自身を示すことができます。ＮＡ
Ｉは「user@realm」形式です；これは図１で例示したＡＡＡモデルでユニー
クで使用が適切です。ＮＡＩ（例えば「user@realm」）を使うことはＡＡＡ
Ｌが容易にクライアントのホームドメイン（例えば、「realm」）を決定する
ことを許します。ＡＡＡＬとＡＡＡＨの両方がクライアント固有の識別子
でインデックスされたレコードを維持するのにＮＡＩを使うことができます。
5. AAA for Mobile IP
5. モバイルＩＰのためのＡＡＡ
Clients using Mobile IP require specific features from the AAA
services, in addition to the requirements already mentioned in
connection with the basic AAA functionality and what is needed for IP
connectivity. To understand the application of the general model for
Mobile IP, we consider the mobile node (MN) to be the client in
figure 1, and the attendant to be the foreign agent (FA). If a
situation arises that there is no foreign agent present, e.g., in the
case of an IPv4 mobile node with a co-located care of address or an
IPv6 mobile node, the equivalent attendant functionality is to be
provided by the address allocation entity, e.g., a DHCP server. Such
an attendant functionality is outside the scope of this document.
The home agent, while important to Mobile IP, is allowed to play a
role during the initial registration that is subordinate to the role
played by the AAAH. For application to Mobile IP, we modify the
general model (as illustrated in figure 3). After the initial
registration, the mobile node is authorized to continue using Mobile
IP at the foreign domain without requiring further involvement by the
AAA servers. Thus, the initial registration will probably take
longer than subsequent Mobile IP registrations.
モバイルＩＰを使っているクライアントが、基本的なＡＡＡ機能性とＩＰ接
続性のために必要とされるものに関連して、すでに示した必要条件のほかに、
ＡＡＡサービスからの特定の機能を要求します。モバイルＩＰの一般的なモ
デルのアプリケーションを理解するために、我々は移動ノード（ＭＮ）が図
１のクライアントで、随行装置が外部エージェント（ＦＡ）と考えます。も
し外部エージェントが存在しない状態が生ずるなら、例えば気付けアドレス
に位置するＩＰｖ４移動ノードの場合や、ＩＰｖ６移動ノードの場合、等価
な随行装置機能はアドレス割当装置、例えば、ＤＨＣＰサーバによって供給
されるはずです。このような随行装置機能はこの文書の範囲外です。ホーム
エージェントは、モバイルＩＰで重要であるが、ＡＡＡＨが演る役割に従属
する最初の登録の間に役割を演ずることを許されます。モバイルＩＰへ適用
するために、我々は（図３で示すように）一般的なモデルを修正します。最
初の登録の後に、移動ノードはＡＡＡサーバとこれ以上の掛かり合いを必要
としないで外部ドメインでモバイルＩＰを使い続けるために認証されます。
それで、最初の登録は次のモバイルＩＰ登録より恐らく長くかかるでしょう。
In order to reduce this extra time overhead as much as possible, it
is important to reduce the time taken for communications between the
AAA servers. A major component of this communications latency is the
time taken to traverse the wide-area Internet that is likely to
separate the AAAL and the AAAH. This leads to a further strong
motivation for integration of the AAA functions themselves, as well
as integration of AAA functions with the initial Mobile IP
registration. In order to reduce the number of messages that
traverse the network for initial registration of a Mobile Node, the
可能な限りこの余分な時間的オーバーヘッドを減らすために、ＡＡＡサーバ
間の通信のためにとられる時間を減らすことは重要です。この通信遅延時間
の主要素がＡＡＡＬとＡＡＡＨを分ける広域インターネットを通過するため
の時間の可能性は高いです。これはＡＡＡ関数自身の統合と、最初のモバイ
ルＩＰ登録とＡＡＡ機能の統合の、強い動機づけを導きます。
AAA functions in the visited network (AAAL) and the home network
(AAAH) need to interface with the foreign agent and the home agent to
handle the registration message. Latency would be reduced as a
result of initial registration being handled in conjunction with AAA
and the mobile IP mobility agents. Subsequent registrations,
however, would be handled according to RFC 2002 [13]. Another way to
reduce latency as to accounting would be the exchange of small
records.
移動ノードの最初の登録のためにネットワーク通過するメッセージの数を減
らすために、訪問したネットワーク（ＡＡＡＬ）とホームネットワーク（Ａ
ＡＡＨ）でのＡＡＡ機能は、登録メッセージを処理する外部エージェントと
ホームエージェントを接続する必要があります。遅延時間はＡＡＡとモバイ
ルＩＰ移動エージェントを関連して処理する最初の登録の結果として減らさ
れるでしょう。しかしながら、次の登録が、ＲＦＣ２００２[13]に従って処
理されるでしょう。課金について遅延を減らすもう１つの方法が小さいレコー
ドの交換であるでしょう。
As there are many different types of sub-services attendants may
provide to mobile clients, there MUST be extensible accounting
formats. In this way, the specific services being provided can be
identified, as well as accounting support should more services be
identified in the future.
随行装置が移動クライアントに供給するかもしれない多くの異なったタイプ
の副サービスがあるから、拡張可能な課金フォーマットがあるに違いありま
せん(MUST)。このようにして、もしより多くのサービスが将来識別されたな
ら、供給されている特定のサービスは、課金サポートと同じぐらい、識別さ
れることができます。
The AAA home domain and the HA home domain of the mobile node need
not be part of the same administrative domain. Such an situation can
occur if the home address of the mobile node is provided by one
domain, e.g., an ISP that the mobile user uses while at home, and the
authorization and accounting by another (specialized) domain, e.g., a
credit card company. The foreign agent sends only the authentication
information of the mobile node to the AAAL, which interfaces to the
AAAH. After a successful authorization of the mobile node, the
foreign agent is able to continue with the mobile IP registration
procedure. Such a scheme introduces more delay if the access to the
AAA functionality and the mobile IP protocol is sequentialized.
Subsequent registrations would be handled according to RFC 2002 [13]
without further interaction with the AAA. Whether to combine or
separate the Mobile IP protocol data with/from the AAA messages is
ultimately a policy decision. A separation of the Mobile IP protocol
data and the AAA messages can be successfully accomplished only if
the IP address of the mobile node's home agent is provided to the
foreign agent performing the attendant function.
ＡＡＡホームドメインと移動ノードのＨＡホームドメインは同じ管理ドメイ
ンの一部である必要がありません。もし移動ノードのホームアドレスが１つ
のドメイン、例えば移動ユーザがホームで使用するＩＳＰ、から供給され、
認証と課金は他の（専門的な）ドメイン、例えば、クレジットカード会社が
供給する場合に、このような状態が存在できます。外部エージェントはＡＡ
ＡＨと相互作用をするＡＡＡＬにただ移動ノードの認証情報だけを送ります。
移動ノードの認可の成功の後に、外部エージェントはモバイルＩＰ登録手順
を続けることが可能です。このような案が、もしＡＡＡ機能へのアクセスと、
モバイルＩＰプロトコルを順番に行うなら、より多くの遅延を導入します。
次の登録は、ＡＡＡとのこれ以上の相互作用なしで、ＲＦＣ２００２[13]に
従って処理されるでしょう。ＡＡＡメッセージをモバイルＩＰプロトコルデー
タと結合するか分離するかのは、究極的にポリシ決定です。モバイルＩＰプ
ロトコルデータとＡＡＡメッセージの分離が、移動ノードのホームエージェ
ントのＩＰアドレスが随行装置機能を実行する外部エージェントに供給され
る場合に限り、成功し得ます。
All needed AAA and Mobile IP functions SHOULD be processed during a
single Internet traversal. This MUST be done without requiring AAA
servers to process protocol messages sent to Mobile IP agents. The
AAA servers MUST identify the Mobile IP agents and security
associations necessary to process the Mobile IP registration, pass
the necessary registration data to those Mobile IP agents, and remain
uninvolved in the routing and authentication processing steps
particular to Mobile IP registration.
すべての必要なＡＡＡとモバイルＩＰ機能は、一回のインターネットの往復
の間に処理されるべきです(SHOULD)。これは、モバイルＩＰエージェントに
送ったプロトコルメッセージを、ＡＡＡサーバが処理するように要求しない
でされなくてはなりません(MUST)。ＡＡＡサーバは、モバイルＩＰエージェ
ントとモバイルＩＰ登録を処理し、モバイルＩＰエージェントに必要な登録
データを手渡すために必要な、セキュリティアソシエーションを識別して、
そしてモバイルＩＰ登録に特有のルーティングと認証処理ステップに関与し
ないままでいなくてはなりません(MUST)。
For Mobile IP, the AAAL and the AAAH servers have the following
additional general tasks:
モバイルＩＰで、ＡＡＡＬとＡＡＡＨサーバは次の追加の一般的な仕事を持
ちます：
- enable [re]authentication for Mobile IP registration
- モバイルＩＰ登録のための［再］認証を可能にする。
- authorize the mobile node (once its identity has been established)
to use at least the set of resources for minimal Mobile IP
functionality, plus potentially other services requested by the
mobile node
- （すでに認証された）移動ノードに、最小のモバイルＩＰ機能と移動ノー
ドが求める他のサービスのための最小資源を使う権限を与える。
- initiate accounting for service utilization
- サービス使用の課金初期化。
- use AAA protocol extensions specifically for including Mobile IP
registration messages as part of the initial registration sequence
to be handled by the AAA servers.
- ＡＡＡプロトコル拡張、特にＡＡＡサーバが操作する初期登録手順の一部
であるモバイルＩＰ登録メッセージの使用。
These tasks, and the resulting more specific tasks to be listed later
in this section, are beneficially handled and expedited by the AAA
servers shown in figure 1 because the tasks often happen together,
and task processing needs access to the same data at the same time.
これらのタスクと、その結果生じるこのセクションの後にリストアップされ
るより特定のタスクは、タスクがしばしば同時に起きてそしてタスク処理が
同時に同じデータにアクセスを必要とするから、図１で示すＡＡＡサーバに
よって有益に処理と促進されます。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ FA + -- -- -- -- - + HA | |
| | | | | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Figure 3: AAA Servers with Mobile IP agents
図３：モバイルＩＰエージェントを伴うＡＡＡサーバ
In the model in figure 1, the initial AAA transactions are handled
without needing the home agent, but Mobile IP requires every
registration to be handled between the home agent (HA) and the
foreign agent (FA), as shown by the sparse dashed (lower) line in
figure 3. This means that during the initial registration, something
has to happen that enables the home agent and foreign agent to
perform subsequent Mobile IP registrations. After the initial
registration, the AAAH and AAAL in figure 3 would not be needed, and
subsequent Mobile IP registrations would only follow the lower
control path between the foreign agent and the home agent.
図１のモデルで、最初のＡＡＡ処理はホームエージェントを必要とせずに処
理されます、しかし図３の（下の）点線で示されるように、モバイルＩＰは
すべての登録がホームエージェント（ＨＡ）と外部エージェント（ＦＡ）間
で処理される事を要求します。これは最初の登録の間に、ホームエージェン
トと外部エージェントが次のモバイルＩＰ登録を行うことができるようにす
る、何かが起きなければならないことを意味します。最初の登録の後に、図
３のＡＡＡＨとＡＡＡＬは必要ではなく、そして次のモバイルＩＰ登録が外
部エージェントとホームエージェント間の下の制御パスに従うだけでしょう。
Any Mobile IP data that is sent by FA through the AAAL to AAAH MUST
be considered opaque to the AAA servers. Authorization data needed
by the AAA servers then MUST be delivered to them by the foreign
agent from the data supplied by the mobile node. The foreign agent
becomes a translation agent between the Mobile IP registration
protocol and AAA.
ＦＡからＡＡＡＬを通してＡＡＡＨに送られるモバイルＩＰデータは、ＡＡ
Ａサーバが不透明と考えなければばりません(MUST)。ＡＡＡサーバが必要と
した認可データは、移動ノードの供給したデータを使い外部エージェントに
よって配達されなくてはなりません(MUST)。外部エージェントはモバイルＩ
Ｐ登録プロトコルとＡＡＡ間の翻訳のエージェントになります。
As mentioned in section 3, nodes in two separate administrative
domains often must take additional steps to guarantee their security
and privacy,, as well as the security and privacy of the data they
are exchanging. In today's Internet, such security measures may be
provided by using several different algorithms. Some algorithms rely
on the existence of a public-key infrastructure [8]; others rely on
distribution of symmetric keys to the communicating nodes [9]. AAA
servers SHOULD be able to verify credentials using either style in
their interactions with Mobile IP entities.
３章で述べたように、２つの別の管理ドメインのノードがしばしば彼らが交
換しているデータのセキュリティとプライバシのために、セキュリティとプ
ライバシを保証する追加の手順を要さなくてはなりません。今日のインター
ネットで、このようなセキュリティ対策はいくつかの異なったアルゴリズム
で供給されます。あるアルゴリズムが公開鍵インフラ[8]の存在に依存しま
す；他が通信ノードへの対称鍵配布[9]に依存します。ＡＡＡサーバはモバ
イルＩＰエンティティのいずｒうぇかの対話で資格証明を実証することが可
能であるべきです(SHOULD)。
In order to enable subsequent registrations, the AAA servers MUST be
able to perform some key distribution during the initial Mobile IP
registration process from any particular administrative domain.
次の登録を可能にするために、ＡＡＡサーバは特定の管理ドメインからの最
初のモバイルＩＰ登録処理の間にある鍵分配を行うことができなければなり
ません(MUST)。
This key distribution MUST be able to provide the following security
functions:
この鍵分配は次のセキュリティ機能を供給することができなければなりませ
ん(MUST)：
- identify or create a security association between MN and home
agent (HA); this is required for the MN to produce the
[re]authentication data for the MN--HA authentication extension,
which is mandatory on Mobile IP registrations.
- ＭＮとホームエージェント（ＨＡ）間のセキュリティアソシエーションの
識別か生成；これはＭＮがモバイルＩＰで必須のＭＮ−ＨＡ認証拡張の
[再]認証データを生成するために必要です。
- identify or create a security association between mobile node and
foreign agent, for use with subsequent registrations at the same
foreign agent, so that the foreign agent can continue to obtain
assurance that the same mobile node has requested the continued
authorization for Mobile IP services.
- 同じ外部エージェントの次の登録で使う、移動ノードと外部エージェント
間のセキュリティアソシエーションの識別か生成、これで外部エージェン
トは同じ移動ノードがモバイルＩＰサービスの継続認証を要求している保
証を得続けることができます。
- identify or create a security association between home agent and
foreign agent, for use with subsequent registrations at the same
foreign agent, so that the foreign agent can continue to obtain
assurance that the same home agent has continued the authorization
for Mobile IP services for the mobile node.
- 同じ外部エージェントの次の登録で使う、ホームエージェントと外部エー
ジェント間のセキュリティアソシエーションの識別か生成、これで外部エー
ジェントは同じホームエージェントが移動ノードのモバイルＩＰサービス
の認証の継続をしている保証を得続けることができます。
- participate in the distribution of the security association (and
Security Parameter Index, or SPI) to the Mobile IP entities
- モバイルＩＰエンティティへのセキュリティアソシエーション（と保全パ
ラメータインデックスあるいはＳＰＩ）の配布への参加。
- The AAA server MUST also be able to validate certificates provided
by the mobile node and provide reliable indication to the foreign
agent.
- ＡＡＡサーバは移動ノードが供給した証明書を有効にして、外部エージェ
ントに信頼できる表示を供給することができなければなりません(MUST)。
- The AAAL SHOULD accept an indication from the foreign agent about
the acceptable lifetime for its security associations with the
mobile node and/or the mobile node's home agent. This lifetime
for those security associations SHOULD be an integer multiple of
registration lifetime offered by the foreign agent to the mobile
node. This MAY allow for Mobile IP reauthentication to take place
without the need for reauthentication to take place on the AAA
level, thereby shortenning the time required for mobile node
reregistration.
- ＡＡＡＬは外部エージェントから、移動ノードや移動ノードのホームエー
ジェントとのセキュリティアソシエーションで受け入れ可能な寿命の、指
示を受け入れるべきです(SHOULD)。これらのセキュリティアソシエーショ
ンのための寿命は、外部エージェントが移動ノードに示した登録寿命の整
数倍であるべきです(SHOULD)。移動ノード登録での時間短縮の要求のため、
これはＡＡＡレベルでの再認証なしで移動ノードの再認証を許すかもしれ
ません(MAY)。
- The AAA servers SHOULD be able to condition their acceptance of a
Mobile IP registration authorization depending upon whether the
registration requires broadcast or multicast service to the mobile
node tunneled through the foreign agent.
- ＡＡＡサーバは、登録が外部エージェントをトンネルした移動ノードのブ
ロードキャストやマルチキャストサービスを必要とするかどうかによって、
モバイルＩＰ登録認可の受け入れを調整可能であるべきです(SHOULD)。
- In addition, reverse tunneling may also be a necessary requirement
for mobile node connectivity. Therefore, AAA servers SHOULD also
be able to condition their acceptance of Mobile IP registration
authorization depending upon whether the registration requires
reverse tunnelling support to the home domain through the foreign
agent.
- 加えて、逆トンネルが移動ノードの接続性に必要な条件であるかもしれま
せん。それ故に、ＡＡＡサーバは登録が外部エージェント経由でホームド
メインまでのトンネルを必要とするかどうかにより、モバイルＩＰ登録認
可の受け入れを調整可能であるべきです(SHOULD)。
The lifetime of any security associations distributed by the AAA
server for use with Mobile IP SHOULD be great enough to avoid too-
frequent initiation of the AAA key distribution, since each
invocation of this process is likely to cause lengthy delays between
[re]registrations [5]. Registration delays in Mobile IP cause
dropped packets and noticeable disruptions in service. Note that any
key distributed by AAAH to the foreign agent and home agent MAY be
used to initiate Internet Key Exchange (IKE) [7].
モバイルＩＰでも使用するためにＡＡＡサーバが配布したセキュリティアソ
シエーションの寿命は、ＡＡＡ鍵配布の頻繁すぎる開始は[再]登録[5]の際の
遅延を起こす可能性が高いので、頻繁な開始を避けるのに十分なほど大きい
べきです(SHOULD)。モバイルＩＰでの登録遅延はサービスのパケット廃棄と
目立つ中断を起こします。ＡＡＡＨから外部エージェントやホームエージェ
ントに行う鍵交換は、インターネット鍵交換（ＩＫＥ）[7]を始めるために使
われるかもしれないことに注意してください(MAY)。
Note further that the mobile node and home agent may well have a
security association established that does not depend upon any action
by the AAAH.
さらに移動ノードとホームエージェントがＡＡＡＨの動作に依存しない確立
されたセキュリティアソシエーションを持つであろうことに注意してくださ
い。
5.1. Mobile IP with Dynamic IP Addresses
5.1. 動的ＩＰアドレスとモバイルＩＰ
According to section 4, many people would like their mobile nodes to
be identified by their NAI, and to obtain a dynamically allocated
home address for use in the foreign domain. These people may often
be unconcerned with details about how their computers implement
Mobile IP, and indeed may not have any knowledge of their home agent
or any security association except that between themselves and the
AAAH (see figure 2). In this case the Mobile IP registration data
has to be carried along with the AAA messages. The AAA home domain
and the HA home domain have to be part of the same administrative
domain.
４章によれば、多くの人々が彼らの移動ノードが彼らのＮＡＩで識別され、
そして外部ドメインで使用する際に動的に割当てられたホームアドレスを得
ることを好むでしょう。これらの人々は、どのように彼らのコンピュータが
モバイルＩＰを実行するかの細部に無関心で、そして彼らのホームエージェ
ントや、彼ら自身とＡＡＡＨ間を除くセキュリティアソシエーションの知識
も持たないかもしれません（図２参照）。この場合モバイルＩＰ登録データ
はＡＡＡメッセージとともに運ばれなければなりません。ＡＡＡホームドメ
インとＨＡホームドメインは同じ管理ドメインの一部でなければなりません。
Mobile IP requires the home address assigned to the mobile node
belong to the same subnet as the Home Agent providing service to the
mobile node. For effective use of IP home addresses, the home AAA
(AAAH) SHOULD be able to select a home agent for use with the newly
allocated home address. In many cases, the mobile node will already
know the address of its home agent, even if the mobile node does not
already have an existing home address. Therefore, the home AAA
(AAAH) MUST be able to coordinate the allocation of a home address
with a home agent that might be designated by the mobile node.
モバイルＩＰは、移動ノードに割り当てられたホームアドレスが、移動ノー
ドにサービスを供給しているホームエージェントと同じサブネットに属する
ことを要求します。ＩＰホームアドレスの効率的な使用のために、ホームＡ
ＡＡ（ＡＡＡＨ）は新たに割り当てられたホームアドレスで使用するホーム
エージェントを選択することが可能であるべきです(SHOULD)。多くの場合、
たとえ移動ノードが既存のホームアドレスを持っていないとしても、移動ノー
ドはホームエージェントのアドレスを知っているでしょう。それ故に、ホー
ムＡＡＡ（ＡＡＡＨ）は移動ノードが指名するかもしれないホームエージェ
ントとホームアドレス配布を調整することができなければなりません(MUST)。
Allocating a home address and a home agent for the mobile would
provide a further simplification in the configuration needs for the
client's mobile node. Currently, in the Proposed Standard Mobile IP
specification [13] a mobile node has to be configured with a home
address and the address of a home agent, as well as with a security
association with that home agent. In contrast, the proposed AAA
features would only require the mobile node to be configured with its
NAI and a secure shared secret for use by the AAAH. The mobile
node's home address, the address of its home agent, the security
association between the mobile node and the home agent, and even the
identity (DNS name or IP address) of the AAAH can all be dynamically
determined as part of Mobile IP initial registration with the
mobility agent in the foreign domain (i.e., a foreign agent with AAA
interface features). Nevertheless, the mobile node may choose to
include the MN-HA security extension as well as AAA credentials, and
the proposed Mobile IP and AAA server model MUST work when both are
present.
ホームアドレスの割当と移動のホームエージェントは、クライアントの移動
ノードの設定を簡単にするでしょう。現在、標準化中のモバイルＩＰ仕様書
[13]で移動ノードはホームアドレスが設定され、ホームエージェントとセキュ
リティアソシエーションが設定されなければなりません。それと対照的に、
提案されたＡＡＡ機能は、移動ノードはＮＡＩとＡＡＡＨが使う共有秘密鍵
が設定される事を要求されるだけです。移動ノードのホームアドレスと、そ
のホームエージェントのアドレスと、移動ノードとホームエージェント間の
セキュリティアソシエーションと、ＡＡＡＨの識別子（ＤＮＳ名あるいはＩ
Ｐアドレス）さえ、外部ドメインのモバイルエージェント（すなわち、ＡＡ
Ａインタフェース機能を持つ外部エージェント）とのモバイルＩＰ初期登録
の一部として動的に決定できます。にもかかわらず、移動ノードは、ＡＡＡ
資格と同様に、ＭＮ−ＨＡセキュリティ拡張を含む選択をするかもしれませ
ん、そして提案されたモバイルＩＰとＡＡＡサーバモデルは、両方ともがあ
る時に動作しなければなりません(MUST)。
The reason for all this simplification is that the NAI encodes the
client's identity as well as the name of the client's home domain;
this follows existing industry practice for the way NAIs are used
today (see section 4). The home domain name is then available for
use by the local AAA (AAAL) to locate the home AAA serving the
client's home domain. In the general model, the AAAL would also have
to identify the appropriate security association for use with that
AAAH. Section 6 discusses a way to reduce the number of security
associations that have to be maintained between pairs of AAA servers
such as the AAAL and AAAH just described.
このすべての簡略化の理由は、ＮＡＩがクライアントの識別子とクライアン
トのホームドメインの名前をコード化するからです；これはＮＡＩが今日使
われる方法の商用慣習に従います（４章参照）。ホームドメイン名は、クライ
アントのホームドメインであるホームＡＡＡを探すため、ローカルＡＡＡ
（ＡＡＡＬ）によって利用可能です。一般的なモデルで、ＡＡＡＬはＡＡＡ
Ｈと使用する適切なセキュリティアソシエーションを識別しなければならな
いでしょう。６章で、今記述したＡＡＡＬやＡＡＡＨの様な対のＡＡＡサー
バ間で、セキュリティアソシエーションの数を減らす方法を論じます。
5.2. Firewalls and AAA
5.2. ファイアウォールとＡＡＡ
Mobile IP has encountered some deployment difficulties related to
firewall traversal; see for instance [11]. Since the firewall and
AAA server can be part of the same administrative domain, we propose
that the AAA server SHOULD be able to issue control messages and keys
to the firewall at the boundary of its administrative domain that
will configure the firewall to be permeable to Mobile IP registration
and data traffic from the mobile node.
モバイルＩＰがあるファイアウォール通過に関連する展開上の困難に遭遇し
ました；例えば[11]を参照してください。ファイアウォールとＡＡＡサーバ
が同じ管理ドメインの一部であり得るので、移動ノードからのモバイルＩＰ
登録とデータトラフィックをファイアウォールが透過できるように設定する
ため、我々はＡＡＡサーバが管理ドメインの境界のファイアウォールに制御
メッセージと鍵を提示可能にすべきことを提案します(SHOULD)。
5.3. Mobile IP with Local Home Agents
5.3. ローカルホームエージェントを持つモバイルＩＰ
+-------------------------+ +--------------+
| +------+ +------+ | | +------+ |
| | | | | | | | | |
| | HA +----+ AAAL | | | | AAAH | |
| | | | +-------------------+ | |
| +-+----+ +---+--+ | | +------+ |
| | | | | Home Domain |
| | +- - - - - + | +--------------+
+------+ | +-+--+-+ |
| | | | | |
| MN +------+ FA | |
| | | | | Local Domain |
+------+ | +------+ |
+-------------------------+
Figure 4: Home Agent Allocated by AAAL
図４：ＡＡＡＬの割り当てるホームエージェント
In some Mobile IP models, mobile nodes boot on subnets which are
technically foreign subnets, but the services they need are local,
and hence communication with the home subnet as if they were residing
on the home is not necessary. As long as the mobile node can get an
address routable from within the current domain (be it publicly, or
privately addressed) it can use mobile IP to roam around that domain,
calling the subnet on which it booted its temporary home. This
address is likely to be dynamically allocated upon request by the
mobile node.
あるモバイルＩＰモデルで、移動ノードが技術的には外部ドメインのサブネッ
ト起動し、しかし彼らが必要とするサービスはローカルな場合、ホームにい
るかのようにホームサブネットと通信をすることは必要ではありません。移
動ノードが現在のドメイン中でルーチング可能アドレスを得られる限り（公
的アドレスかプライベートアドレス）、移動ノードはそのドメインを動き回る
ためにモバイルＩＰを使うことができ、起動した一時的なホームを呼び出す
事ができます。このアドレスは移動ノードの要求で動的に割り当てられる可
能性が高いです。
In such situations, when the client is willing to use a dynamically
allocated IP address and does not have any preference for the
location of the home network (either geographical or topological),
the local AAA server (AAAL) may be able to offer this additional
allocation service to the client. Then, the home agent will be
located in the local domain, which is likely to be offer smaller
delays for new Mobile IP registrations.
このような状態で、クライアントが動的に割り当てられたＩＰアドレスを使
いたくて、そしてホームネットワークの場所に対する（あるいは地理的な、
あるいはトポロジ的な）優先順位を持っていない時、ローカルなＡＡＡサー
バ（ＡＡＡＬ）はクライアントにこの追加割当サービスを提供可能であるか
もしれません。それなら、ホームエージェントはローカルドメインに位置し、
新しいモバイルＩＰ登録で小さな遅延である可能性が高いです。
In figure 4, AAAL has received a request from the mobile node to
allocate a home agent in the local domain. The new home agent
receives keys from AAAL to enable future Mobile IP registrations.
From the picture, it is evident that such a configuration avoids
problems with firewall protection at the domain boundaries, such as
were described briefly in section 5.2. On the other hand, this
configuration makes it difficult for the mobile node to receive data
from any communications partners in the mobile node's home
administrative domain. Note that, in this model, the mobile node's
home address is affiliated with the foreign domain for routing
purposes. Thus, any dynamic update to DNS, to associate the mobile
node's home FQDN (Fully Qualified Domain Name [10]) with its new IP
address, will require insertion of a foreign IP address into the home
DNS server database.
図４で、ＡＡＡＬは移動ノードからのローカルドメインのホームエージェン
トの割当て要請を受け取りました。新しいホームエージェントは将来のモバ
イルＩＰ登録を可能にするためにＡＡＡＬから鍵を受け取ります。図からこ
のような設定は、５.２章で記述した、ドメイン境界のファイアウォール保護
の問題を避けることは明白です。他方、この設定は移動ノードが移動ノード
のホーム管理ドメインの通信相手からのデータを受け取ることを難しくしま
す。このモデルで、移動ノードのホームアドレスがルーチングの目的で外部
ドメインと関連する事に注意してください。それで、移動ノードのホームＦ
ＱＤＮ（完全に指定されたドメイン名[10]）に関連する、新しいＩＰアドレ
スのＤＮＳダイナミック更新で、ホームＤＮＳサーバデータベースの中に外
部ＩＰアドレスの挿入を必要とするでしょう。
5.4. Mobile IP with Local Payments
5.4. ローカル支払いのあるモバイルＩＰ
Since the AAAL is expected to be enabled to allocate a local home
agent upon demand, we can make a further simplification. In cases
where the AAAL can manage any necessary authorization function
locally (e.g., if the client pays with cash or a credit card), then
there is no need for an AAA protocol or infrastructure to interact
with the AAAH. The resulting simple configuration is illustrated in
figure 5.
ＡＡＡＬが要求次第ローカルホームエージェントを割り当てるために利用可
能であることを期待されるので、我々はより簡単化した物を作ることができ
ます。ＡＡＡＬがローカルに必要な認可機能を処理することができる場合
（例えば、もしクライアントが現金あるいはクレジット・カードで代金を払
うなら）、ＡＡＡＨと対話するＡＡＡプロトコルやインフラが必要がありま
せん。結果として生じている単純な設定は図５で例示されます。
In this simplified model, we may consider that the role of the AAAH
is taken over either by a national government (in the case of a cash
payment), or by a card authorization service if payment is by credit
card, or some such authority acceptable to all parties. Then, the
AAAL expects those external authorities to guarantee the value
represented by the client's payment credentials (cash or credit).
There are likely to be other cases where clients are granted access
to local resources, or access to the Internet, without any charges at
all. Such configurations may be found in airports and other common
この単純化されたモデルで、我々はＡＡＡＨの役割を、国政府（現金払いの
場合）や、もし支払いがクレジット・カードや関係者全員が受け入れるこの
ような権威によるカード認証サービスが、引き継いでると思うかもしれませ
ん。それから、ＡＡＡＬは外部権威がクライアントの支払い証明（現金ある
いはクレジット）が示された価値を保証することを期待します。クライアン
トがローカル資源やインターネットに料金なしでアクセスを与えられる可能
性もあります。このような設定は空港や他のビジネスクライアントが時間を
過ごす可能性が高い公共エリアかもしれません。
+-------------------------+
| +------+ +------+ |
| | | | | |
| | HA +----+ AAAL | |
| | | | | |
| +--+---+ +----+-+ |
| | | |
| +- - - - - + | |
+------+ | +-+--+-+ |
| | | | | |
| MN +- -|- - - - - - - + FA | |
| | | Local Domain | | |
+------+ | +------+ |
+-------------------------+
Figure 5: Local Payment for Local Mobile IP services
図５：ローカルモバイルＩＰサービスのためのローカル支払い
areas where business clients are likely to spend time. The service
provider may find sufficient reward in the goodwill of the clients,
or from advertisements displayed on Internet portals that are to be
used by the clients. In such situations, the AAAL SHOULD still
allocate a home agent, appropriate keys, and the mobile node's home
address.
サービスプロバイダはクライアントの好意で、あるいはクライアントの使う
インターネットの入り口に示された広告から十分な報酬を見いだすかもしれ
ません。このような状態でも、ＡＡＡＬはホームエージェントと適切な鍵と
移動ノードのホームアドレスを割り当てるべきです(SHOULD)。
5.5. Fast Handover
5.5. 速いハンドオーバ
Since the movement from coverage area to coverage area may be
frequent in Mobile IP networks, it is imperative that the latency
involved in the handoff process be minimized. See, for instance, the
Route Optimization document [15] for one way to do this using Binding
Updates. When the mobile node enters a new visited subnet, it would
be desirable for it to provide the previous foreign agent's NAI. The
new FA can use this information to either contact the previous FA to
retrieve the KDC session key information, or it can attempt to
retrieve the keys from the AAAL. If the AAAL cannot provide the
necessary keying information, the request will have to be sent to the
mobile node's AAAH to retrieve new keying information. After initial
authorization, further authorizations SHOULD be done locally within
the Local Domain.
モバイルＩＰネットワークでエリアからエリアの移動は頻繁かもしれないの
で、ハンドオフ処理の遅延を最小化するのは緊急課題です。例えば、結合更
新を使ってこれをする一つの方法の経路最適化文書[15]を見てください。移
動ノードが新しく訪問されたサブネットに入る時、前の外部エージェントの
ＮＡＩを供給することは望ましいでしょう。新しいＦＡは、ＫＤＣセッショ
ン鍵情報を取り戻すためあるいはＡＡＡＬから鍵を検索しようと試みるため、
前のＦＡと連絡を取るためにこの情報を使うことができます。もしＡＡＡＬ
が必要な鍵情報を供給できないなら、要請は新しい鍵情報を得るために移動
ノードのＡＡＡＨに送られなければならないでしょう。最初の認可の後に、
追加の認証はローカルドメイン内でローカルに行われるべきです(SHOULD)。
When a MN moves into a new foreign subnet as a result of a handover
and is now served by a different FA, the AAAL in this domain may
contact the AAAL in the domain that the MN has just been handed off
from to verify the authenticity of the MN and/or to obtain the
session keys. The new serving AAAL may determine the address of the
AAAL in the previously visited domain from the previous FA NAI
information supplied by the MN.
ＭＮがハンドオーバの結果新しい外部サブネットに入り、そして異なるＦＡ
のサービスを受ける時、このドメインのＡＡＡＬはＭＮの認証を確認やセッ
ション鍵を得るために、ハンドオフ前にいたドメインのＡＡＡＬと連絡を取
るかもしれません。新しいＡＡＡＬは、ＭＮが供給する前のＦＡ ＮＡＩ情
報から前に訪問したドメインのＡＡＡＬアドレスを決定するかもしれません。
6. Broker Model
6. ブローカーモデル
The picture in Figure 1 shows a configuration in which the local and
the home authority have to share trust. Depending on the security
model used, this configuration can cause a quadratic growth in the
number of trust relationships, as the number of AAA authorities (AAAL
and AAAH) increases. This has been identified as a problem by the
roamops working group [3], and any AAA proposal MUST solve this
problem. Using brokers solves many of the scalability problems
associated with requiring direct business/roaming relationships
between every two administrative domains. In order to provide
scalable networks in highly diverse service provider networks in
which there are many domains (e.g., many service providers and large
numbers of private networks), multiple layers of brokers MUST be
supported for both of the broker models described.
図１の絵はローカルとホーム権威が信頼を共有しなければならない設定を示
します。使われたセキュリティモデルに依存して、この設定はＡＡＡ権威
（ＡＡＡＬとＡＡＡＨ）の数が増加するにつれて、信頼関係の数の２乗の増
大を起こすことができます。これはroamops作業グループ[3]で問題と認識さ
れました、そしてどんなＡＡＡ案でもこの問題を解かなくてはなりません
(MUST)。ブローカを使うことは２つの管理ドメイン間の直接のビジネス／ロー
ミング関係を必要とすることに関係するスケーラブル問題の多くを解きます。
多くのドメインを含む多くの多様なサービスプロバイダネットワーク（例え
ば、多くのサービスプロバイダと多数のプライベートのネットワーク）でス
ケーラブルなネットワークを供給するために、記述したブローカモデルの両
方で多段のブローカがサポートされなくてはなりません(MUST)。
Integrity or privacy of information between the home and serving
domains may be achieved by either hop-by-hop security associations or
end-to-end security associations established with the help of the
broker infrastructure. A broker may play the role of a proxy between
two administrative domains which have security associations with the
broker, and relay AAA messages back and forth securely.
ホームと提供ドメイン間の情報の完全性あるいはプライバシは、ホップ毎の
セキュリティアソシエーションやブローカインフラの力を借りたエンドエン
ドセキュリティアソシエーションで成し遂げられるかもしれません。ブロー
カが、ブローカとセキュリティアソシエーションを持つ２つの管理ドメイン
間のプロキシの役割を演じて、安全にＡＡＡメッセージを中継してもよいで
す。
Alternatively, a broker may also enable the two domains with which it
has associations, but the domains themselves do not have a direct
association, in establishing a security association, thereby
bypassing the broker for carrying the messages between the domains.
This may be established by virtue of having the broker relay a shared
secret key to both the domains that are trying to establish secure
communication and then have the domains use the keys supplied by the
broker in setting up a security association.
代わりに、ブローカが２つのドメインがアソシエーション持つ事を可能にし
てもよいですが、ドメイン自身は、セキュリティアソシエーションを確立す
るための、ドメインの間でメッセージを運ぶ際にブローカを迂回する直接の
アソシエーションを持ちません。これは安全な通信を確立したいドメイン間
でブローカーが共有秘密鍵を中継し、ブローカによって供給された鍵を使用
してドメインがセキュリティアソシエーションを設立することで、実施でき
るかもしれません。
Assuming that AAAB accepts responsibility for payment to the serving
domain on behalf of the home domain, the serving domain is assured of
receiving payments for services offered. However, the redirection
broker will usually require a copy of authorization messages from the
home domain and accounting messages from the serving domain, in order
for the broker to determine if it is willing to accept responsibility
for the services being authorized and utilized. If the broker does
not accept such responsibility for any reason, then it must be able
to terminate service to a mobile node in the serving network. In the
event that multiple brokers are involved, in most situations all
brokers must be so copied. This may represent an additional burden
on foreign agents and AAALs.
ＡＡＡＢがホームドメインを代表して提供ドメインに支払いする責任を受け
入れると想定し、提供ドメインは供給サービスのための支払いを受け取るこ
とを保証されます。しかしながら、再転送ブローカは、ブローカが認証と利
用のサービスの責任の受理を期待されているかどうか決定するために、通常
ホームドメインからの認証メッセージと、供給ドメインからの課金メッセー
ジのコピーが必要とされます。もしブローカが何かの理由で責任を受け入れ
ないなら、供給ネットワークの移動ノードのサービスを終えることができな
ければなりません。多数のブローカが関係する場合、たいていの状態ですべ
てのブローカはコピーできなければなりません。これは外部エージェントと
ＡＡＡＬに追加の負担を与えるかもしれません。
Though this mechanism may reduce latency in the transit of messages
between the domains after the broker has completed its involvement,
there may be many more messages involved as a result of additional
copies of authorization and accounting messages to the brokers
involved. There may also be additional latency for initial access to
the network, especially when a new security association needs to be
created between AAAL and AAAH (for example, from the use of ISAKMP).
These delays may become important factors for latency-critical
applications.
この機構が、ブローカが関与を完了した後、ドメイン間のメッセージ通過の
遅延を減らすかもしれないけれども、関係ブローカへの認可と課金メッセー
ジの追加のコピーの結果に関連するさらに多くのメッセージがあるかもしれ
ません。特に新しいセキュリティアソシエーションがＡＡＡＬとＡＡＡＨ間
で作る必要があるとき（例えば、ＩＳＡＫＭＰの使用で）、ネットワークに
最初のアクセスのために追加の遅延があるかもしれません。これらの遅延は
遅延が問題となるアプリケーションの重要な要因になるかもしれません。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | +------+ | +------+ |
| | | | | | | | | |
| | AAAL +-------+ AAAB +--------+ AAAH | |
| | | | | | | | | |
| +------+ | +------+ | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C +- -|- -+ A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| | AAAB = broker authority
+--------------+
Figure 6: AAA Servers Using a Broker
図６：ＡＡＡサーバブローカの利用
The AAAB in figure 6 is the broker's authority server. The broker
acts as a settlement agent, providing security and a central point of
contact for many service providers and enterprises.
図６でのＡＡＡＢはブローカの権威サーバです。ブローカは、安全管理と多
くのサービスプロバイダと企業のための集中連絡点を供給する、セツルメン
トエージェントの役を務めます。
The AAAB enables the local and home domains to cooperate without
requiring each of the networks to have a direct business or security
relationship with all the other networks. Thus, brokers offer the
needed scalability for managing trust relationships between otherwise
independent network domains. Use of the broker does not preclude
managing separate trust relationships between domains, but it does
offer an alternative to doing so. Just as with the AAAH and AAAL
(see section 5), data specific to Mobile IP control messages MUST NOT
be processed by the AAAB. Any credentials or accounting data to be
processed by the AAAB must be present in AAA message units, not
extracted from Mobile IP protocol extensions.
ＡＡＡＢは、ネットワークが他の全てのネットワークと直接のビジネスやセ
キュリティの関係を持つことなしに、ローカルとホームドメインが協力でき
るようにします。それで、ブローカ独立なネットワークドメインの間の信頼
関係を処理することに対して必要とされるスケーラビリティを提供します。
ブローカの使用がドメイン間の個別の信頼関係を処理することを妨げず、そ
うする選択肢を提供します。ちょうどＡＡＡＨとＡＡＡＬと同じように（５
章参照）、モバイルＩＰ制御メッセージに固有のデータがＡＡＡＢによって
処理されてはなりません(MUST NOT)。ＡＡＡＢによって処理される資格証明
あるいは課金データがモバイルＩＰプロトコル拡張から抽出されなかったＡ
ＡＡメッセージユニットで存在しているに違いありません。
The following requirements come mostly from [2], which discusses use
of brokers in the particular case of authorization for roaming dial-
up users.
次の必要条件はほとんど[2]から来ていて、これはダイアルアップユーザの
ローミングの認可の特定の場合でのブローカの使用を論じます。
- allowing management of trust with external domains by way of
brokered AAA.
- ブローカＡＡＡを通して外部のドメインとの信頼管理を許します。
- accounting reliability. Accounting data that traverses the
Internet may suffer substantial packet loss. Since accounting
packets may traverse one or more intermediate authorization points
(e.g., brokers), retransmission is needed from intermediate points
to avoid long end-to-end delays.
- 課金信頼性。インターネット通る課金データで相当なパケット紛失がある
かもしれません。課金パケットが複数の中間認証点（例えば、ブローカ）
を通るかも知れず、長いエンドエンド遅延を避けるため中間点での再送が
必要とされます。
- End to End security. The Local Domain and Home Domain must be
able to verify signatures within the message, even though the
message is passed through an intermediate authority server.
- エンドエンドセキュリティ。ローカルドメインとホームドメインは、メッ
セージが中間権威サーバを通して来ても、メッセージ内の署名を検証でき
なければなりません。
- Since the AAAH in the home domain MAY be sending sensitive
information, such as registration keys, the broker MUST be able to
pass encrypted data between the AAA servers.
- ホームドメインのＡＡＡＨが登録鍵のような機密性が高い情報を送ってい
るかもしれない(MAY)ので、ブローカはＡＡＡサーバ間で暗号化されたデー
タを渡すことができなければなりません(MUST)。
The need for End-to-End security results from the following attacks
which were identified when brokered operation uses RADIUS [16] (see
[2] for more information on the individual attacks):
エンドエンドセキュリティは、中間オペレーションがラディウス[16]を使う
時に認識されている次の攻撃の結果にために必要です（個別攻撃については
[2]の情報を見てください）：
+ Message editing
+ メッセージ改竄
+ Attribute editing
+ 属性改竄
+ Theft of shared secrets
+ 共有秘密鍵盗難
+ Theft and modification of accounting data
+ 課金データの盗難と修正
+ Replay attacks
+ 再生攻撃
+ Connection hijacking
+ 接続ハイジャック
+ Fraudulent accounting
+ 偽課金
These are serious problems which cannot be allowed to persist in any
acceptable AAA protocol and infrastructure.
これらは適切ＡＡＡプロトコルとインフラで持続することを許すことができ
ない重大な問題です。
7. Security Considerations
7. セキュリティの考察
This is a requirements document for AAA based on Mobile IP. Because
AAA is security driven, most of this document addresses the security
considerations AAA MUST make on behalf of Mobile IP. As with any
security proposal, adding more entities that interact using security
protocols creates new administrative requirements for maintaining the
appropriate security associations between the entities. In the case
of the AAA services proposed however, these administrative
requirements are natural, and already well understood in today's
Internet because of experience with dial up network access.
これはモバイルＩＰに基づくＡＡＡのための必要条件文書です。ＡＡＡがセ
キュリティのためなので、この文書の大部分がＡＡＡがモバイルＩＰのため
に作らなくてはならない(MUST)セキュリティの考慮を扱います。どのセキュ
リティ提案とも同じように、セキュリティプロトコルを使って相互作用する
より多くの参加者を加えることは参加者間で適切なセキュリティアソシエー
ションを保守するための新しい管理必要条件を作ります。しかしながら提案
されたＡＡＡサービスの場合、これらの管理必要条件は自然なことでダイヤ
ルアップネットワークアクセスの経験から今日のインターネットでよく理解
されています。
8. IPv6 Considerations
8. ＩＰｖ６の考察
The main difference between Mobile IP for IPv4 and Mobile IPv6 is
that in IPv6 there is no foreign agent. The attendant function,
therefore, has to be located elsewhere. Logical repositories for
that function are either at the local router, for stateless address
autoconfiguration, or else at the nearest DHCPv6 server, for stateful
address autoconfiguration. In the latter case, it is possible that
there would be a close relationship between the DHCPv6 server and the
AAALv6, but we believe that the protocol functions should still be
maintained separately.
ＩＰｖ４のモバイルＩＰとモバイルＩＰｖ６の間の主な相違はＩＰｖ６に外
部エージェントがないということです。随行装置機能は、従って、他のとこ
ろに位置していなければなりません。その機能の論理的存在個所は、ステー
トレスアドレス自動設定でローカルルータ、ステートフルアドレス自動設定
では最も近くのＤＨＣＰｖ６サーバです。後者の場合で、ＤＨＣＰｖ６サー
バとＡＡＡＬｖ６間の近い関係があることは可能ですが、しかし我々はプロ
トコル機能がまだ別に持続されるべきであると信じます。
The MN-NAI would be equally useful for identifying the mobile node to
the AAALv6 as is described in earlier sections of this document.
ＡＡＡＬｖ６が移動ノードを識別することに対して、ＭＮ−ＮＡＩは、この
文書の前の章で記述されるように有用であるでしょう。
9. Acknowledgements
9. 謝辞
Thanks to Gopal Dommety and Basavaraj Patil for participating in the
Mobile IP subcommittee of the aaa-wg which was charged with
formulating the requirements detailed in this document. Thanks to N.
Asokan for perceptive comments to the mobile-ip mailing list. Some
of the text of this document was taken from a draft co-authored by
Pat Calhoun. Patrik Flykt suggested text about allowing AAA home
domain functions to be separated from the domain managing the home
address of the mobile computer.
この文書で詳述された必要条件を規定するために作られたaaa-wgのモバイル
ＩＰ小委員会に参加することに対してGopal DommetyとBasavaraj Patilに感
謝します。モバイルＩＰメーリングリストへの鋭いコメントについて
N. Asokanに感謝します。この文書の文書のいくつかがPat Calhounによる共
同執筆されたスケッチから引用されました。Patrik Flyktはモバイルコン
ピュータのホームアドレスを管理するドメインからＡＡＡホームドメイン機
能を分離されることを許すテキストを提案しました。
The requirements in section 5.5 and section 3.1 were taken from a
draft submitted by members of the TIA's TR45.6 Working Group. We
would like to acknowledge the work done by the authors of that draft:
Tom Hiller, Pat Walsh, Xing Chen, Mark Munson, Gopal Dommety,
Sanjeevan Sivalingham, Byng-Keun Lim, Pete McCann, Brent Hirschman,
Serge Manning, Ray Hsu, Hang Koo, Mark Lipford, Pat Calhoun, Eric
Jaques, Ed Campbell, and Yingchun Xu.
５.５章と３.１章での必要条件はＴＩＡのＴＲ４５.６作業グループのメン
バーによって提出されたドラフトから取られました。我々はそのドラフトの
著者によってされた仕事を認めたいです：Tom HillerとPat WalshとXing
ChenとMark MunsonとGopal DommetyとSanjeevan SivalinghamとByng-Keun
LimとPete McCannとBrent HirschmanとSerge ManningとRay HsuとHang Kooと
Mark LipfordとPat CalhounとEric JaquesとEd Campbellとand Yingchun Xu。
References
参考文献
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[2] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[3] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, December 1998.
4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Ramon Caceres and Liviu Iftode. Improving the Performance of
Reliable Transport Protocols in Mobile Computing Environments.
IEEE Journal on Selected Areas in Communications, 13(5):850--
857, June 1995.
[6] Calhoun, P. and C. Perkins, "Mobile IP Network Address
Identifier Extension, RFC 2794, March 2000.
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[8] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999.
[9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[10] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[11] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[12] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[13] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[14] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[15] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP",
Work in Progress.
[16] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[17] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
PPP IPCP", RFC 2290, February 1998.
Addresses
アドレス
The working group can be contacted via the current chairs:
作業グループは現在の議長によって連絡を取られることができます：
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972-894-6709
EMail: Basavaraj.Patil@nokia.com
Phil Roberts
Motorola
1501 West Shure Drive
Arlington Heights, IL 60004
USA
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Questions about this memo can be directed to:
この文書の質問は以下にできます：
Pat R. Calhoun
Network and Security Center
Sun Microsystems Laboratories
15 Network Circle
Menlo Park, California 94025
USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.com
Gopal Dommety
IOS Network Protocols
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1-408-525-1404
Fax: +1 408-526-4952
EMail: gdommety@cisco.com
Steven M. Glass
Sun Microsystems
1 Network Drive
Burlington, MA 01803
USA
Phone: +1-781-442-0504
EMail: steven.glass@sun.com
Stuart Jacobs
Secure Systems Department
GTE Laboratories
40 Sylvan Road
Waltham, MA 02451-1128
USA
Phone: +1 781-466-3076
Fax: +1 781-466-2838
EMail: sjacobs@gte.com
Tom Hiller
Lucent Technologies
Rm 2F-218
263 Shuman Blvd
Naperville, IL 60566
USA
Phone: +1 630 979 7673
Fax: +1 630 713 3663
EMail: tomhiller@lucent.com
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566
USA
Phone: +1 630 713 9359
Fax: +1 630 713 4982
EMail: mccap@lucent.com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（Ｃ）インターネット学会（２０００）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。