Network Working Group                     T. Hiller, Lucent Technologies
Request for Comments: 3141                 P. Walsh, Lucent Technologies
Category: Informational                                 X. Chen, Alcatel
                                                               M. Munson
                                               G. Dommety, Cisco Systems
                        S. Sivalingham, Ericsson Wireless Communications
                           B. Lim, LG Information & Communications, Ltd.
                                          P. McCann, Lucent Technologies
                                          H. Shiino, Lucent Technologies
                                                  B. Hirschman, Motorola
                                       S. Manning, Award Solutions, Inc.
                                                  R. Hsu, Qualcomm, Inc.
                        H. Koo, Samsung Telecommunications America, Inc.
                                                  M. Lipford, Sprint PCS
                                      P. Calhoun, Sun Laboratories, Inc.
                                                         C. Lo, Vodafone
                                                     E. Jaques, Vodafone
                      E. Campbell, CommWorks Corporation, A 3Com Company
                                               Y. Xu, WaterCove Networks
                                 S. Baba, Toshiba America Research, Inc.
                                               T. Ayaki, DDI Corporation
                                                 T. Seki, DO Corporation
                                                      A. Hameed, Fujitsu
                                                               June 2001
        
              CDMA2000 Wireless Data Requirements for AAA
        

Status of this Memo

このメモの位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2001). All Rights Reserved.

著作権(C)インターネット協会(2001)。全著作権所有。

Abstract

抽象

This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services.

このメモは、伝統的なPPPとモバイルIPサービスのためのサービス・プロバイダーの間でローミングを支持する第3世代無線アーキテクチャに関連するCDMA2000無線データ・AAA(認証、許可、アカウンティング)の要件を指定します。

1. Introduction
1. はじめに

The architecture is designed for use with a cellular network as an access medium. Sections 1, 2, present a brief high level review of the cdma2000 wireless data architecture. Section 3 presents cdma2000 AAA requirements.

アーキテクチャは、アクセス媒体としてセルラーネットワークで使用するために設計されています。セクション1、2は、CDMA2000無線データ・アーキテクチャの簡単な高レベルのレビューを提示します。第3節では、cdma2000のAAAの要件を提示します。

This document specifies AAA requirements associated with a third generation cdma2000 wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. The architecture is designed for use with a cellular network as an access medium.

この文書では、伝統的なPPPとモバイルIPサービスのためのサービス・プロバイダーの間でローミングをサポートする第三世代のcdma2000無線アーキテクチャに関連したAAAの要件を指定します。アーキテクチャは、アクセス媒体としてセルラーネットワークで使用するために設計されています。

Sections 1 and 2 present a brief, high level review of the cdma2000 wireless data architecture as an aid to interested AAA WG members. Section 3 presents cdma2000 AAA requirements, and is self contained relative to the architecture review.

セクション1および2本興味AAA WGメンバーの補助としてCDMA2000無線データアーキテクチャの簡単な、高レベルの見直し。第3節では、cdma2000のAAAの要件を提示し、自己が建築審査に対する相対含まれています。

1.1. Requirements language
1.1. 要件言語

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].

この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[RFC2119]に記載されているように解釈されるべきです。

Please note that the requirements specified in this document are to be used in evaluating AAA protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted.

この文書で指定された要件は、AAAプロトコルの提出を評価するのに使用されることに注意してください。そのため、要件の言語は、これらのプロトコルの能力を指し、プロトコルドキュメントは、これらの機能は、必要な推奨、またはオプションされているかどうかを指定します。例えば、プロトコルサポートの機密性は、すべてのプロトコルのトラフィックを暗号化することを要求することと同じものではありませんことを要求します。

A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."

それはMUSTの一つ以上を満たすために失敗したか、それが実装する機能のためにはならない要件場合は、プロトコルの提出は準拠していません。すべてのMUSTを満たすプロトコル提案は、およびその機能のための要件は、「無条件に準拠した」と言われてすべきでないてはなりません。すべてのMUSTを満たし、すべてのSHOULDまたはそのプロトコルのための要件が​​あると言われてはならない要件はならずではない一つの「条件付きで準拠しています。」

1.2. General Service Requirements
1.2. 一般的なサービスの要件
      o  Provide service during subscriber visiting between wireless
         networks systems while maintaining a formal customer-service
         provider relation with only one wireless service provider.
        

o Support Traditional PPP and Mobile IP services:

Oの伝統的なPPPとモバイルIPサービスをサポートしています:

o Support dynamic and static home address assignments for Mobile IP o Support a Home Agent in the mobile's home wireless network, home ISP, or private network. o Support IP Security on the Mobile IP tunnel between Foreign Agent and Home Agent, in order to avoid the overhead of a voluntary tunnel on the radio interface.

モバイルのホームワイヤレスネットワーク、ホームISP、またはプライベートネットワーク内のホームエージェントをサポートしています〇〇モバイルIPのための動的および静的ホームアドレスの割り当てをサポートしています。無線インターフェイス上の自主的なトンネルのオーバーヘッドを回避するために、外部エージェントとホームエージェントとの間のモバイルIPトンネル上のOサポートIPセキュリティ。

o Provide robust authentication, authorization and accounting services (AAA):

O堅牢な認証、許可、アカウンティングサービス(AAA)を提供します:

o Provide separation of airlink resource AAA services and data resource AAA services. o Authenticate and authorize a mobile based on an IMSI and an NAI. The architecture allows for a carrier to determine if billing is based on the IMSI or the NAI. o Support optional AAA broker services between wireless carriers and between wireless carriers and other external data networks. o Allow for distribution of specific Mobile IP security key information to support home agent assignment, fast handoff, and fast HA-FA authentication assignment during registration.

OエアリンクリソースAAAサービスとデータリソースAAAサービスの分離を提供します。 O IMSIとNAIに基づいて、モバイルを認証および認可します。アーキテクチャは、課金は、IMSIまたはNAIに基づいているかどうかを決定するためにキャリアを可能にします。 Oワイヤレスキャリア間の無線キャリアおよび他の外部データネットワークとの間の任意AAAブローカーサービスをサポートします。 O登録時にホームエージェントの割り当てをサポートするために、特定のモバイルIPセキュリティキー情報、高速ハンドオフ、および高速のHA-FA認証の割り当ての配布を許可。

o Provide QoS

O QoSを提供

2. High Level Architecture
2.高レベルのアーキテクチャ

The high level architecture is shown in Figure 1. The six major entities that compose the network are the Home Agent, the PDSN, the AAA Server, the Radio Network, the HLR/VLR, and Mobile Client.

高レベルのアーキテクチャを図1に示されたネットワークを構成する六の大事業体は、ホームエージェント、PDSN、AAAサーバ、無線ネットワーク、HLR / VLR、およびモバイルクライアントです。

            Visited Access              Home Access
            Provider Network           Provider Network
              +--------+                 +--------+
              |        |      SS7        |        |
              |  VLR   |-----------------|  HLR   |
              |        |                 |        |
              +--------+                 +--------+
                  |
                  |
                  |  Visited Access      Broker        Home IP
                  |  Provider Network    Network       Network
                  |     +--------+      +--------+   +--------+
                  |     |        |      |        |   |        |
                  |     |  AAA   |------|  AAA   |---|  AAA   |
                  |     |        |      |        |   |        |
                  |     +--------+      +--------+   +--------+
                  |             \                \       |
                  |              \                \      |
                  |               \                \     |
                  |                \                \    |
                  |                 \                \   |
              +---------+       +---------+       +---------+
              |         |       |         |       |         |
              |   RN    |-------|  PDSN   |-------|  HA     |
              |         |       |         |       |         |
              +---------+       +---------+       +---------+
                  |
                  |   Visited Access            Home Network
                  |  Provider Network           -Private
            Mobile|                             -Visited Provider
              IP  |                             -Home Provider
                  |                             -Home ISP
               +--------+
               | Mobile |
               | Node   |
               +--------+
        

Figure 1: General cdma2000 Wireless IP Architecture

図1:一般的なCDMA2000無線IPアーキテクチャ

2.1. PDSN
2.1. PDSN
      o  Acts as a Foreign Agent;
      o  Establish, maintain, and terminate link layer to the mobile
         client;
      o  Initiate the authentication, authorization and accounting for
         the mobile client;
      o  Optionally, securely tunnel using IP security to the Home
         Agent;
      o  Receives service parameters from AAA for mobile client;
      o  Collect usage data for accounting purposes to be relayed to
         AAA;
      o  Routes packets to external packet data networks or to the HA in
         the case of reverse tunneling;
      o  Maps home address and Home Agent address to a unique link layer
         identifier used to communicate with Radio Network.
        
2.2. Authentication, Authorization, and Accounting Server
2.2. 認証、認可、アカウンティングサーバ
      o  Interact with the Foreign Agent and other AAA servers to
         authorize, authenticate and perform accounting for the mobile
         client;
      o  Provides mechanism to support security association between
         PDSN/FA and HA and between the MN and PDSN/FA;
      o  For dynamic Home Agent assignment, dynamically identify an HA
         and assign a MN on that HA, and provide the security
         association between the MN and HA;
      o  Provide QoS information to the PDSN;
      o  Optionally, assign dynamic home address.
        
2.3. Radio Network
2.3. 無線ネットワーク
      o  Maps Mobile Client identifier reference to a unique link layer
         identifier used to communicate with PDSN;
      o  Validates Mobile Station for access service;
      o  Manages physical layer connection to the Mobile Client;
      o  Maintain state of reachability for packet service between the
         access radio network and the mobile station;
      o  Buffers packets arriving from the PDSN, when radio resources
         are not in place or are insufficient to support the flow from
         the PDSN;
      o  Relays packets between the mobile station and the PDSN.
        
2.4. Location Registers (VLR/HLR)
2.4. ロケーションレジスタ(VLR / HLR)
      o  Stores authentication and authorization information for the
         radio network.
        
2.5. Home Agent
2.5. ホームエージェント
      o  Maintains user registration and redirects packets to the PDSN;
      o  Optionally, establish an IP secure tunnel to the PDSN/FA;
      o  Supports the dynamic Home Agent assignment;
      o  Optionally, assigns dynamic home address;
      o  Support reverse tunneling.
        
2.6. Mobile Node
2.6. モバイルノード
      o  Support PPP;
      o  Can act as a Mobile IP Node; and support Foreign Agent
         Challenge and NAI;
      o  Interacts with the Radio Network to obtain appropriate radio
         resources from the network for the exchange of packets;
      o  Maintains knowledge of status of radio resources (e.g., active,
         standby, dormant);
      o  Buffers packets when radio resources are not in place or are
         insufficient to support the flow to the network.
        
3. AAA Requirements
3. AAAの要件
3.1. Core AAA Requirements
3.1. コアAAAの要件

The following is a summary of cdma2000 AAA specific requirements. In these requirements, the serving network and home network may or may not have a direct business relationship. In such cases in which there is not a direct business relationship, service may be supported indirectly via broker.

以下は、cdma2000のAAA特定の要件をまとめたものです。これらの要件では、サービング・ネットワークとホーム・ネットワークは、または直接取引関係を持っていない可能性があります。直接の取引関係がないとしたような場合には、サービスはブローカーを介して間接的にサポートすることができます。

o Authenticate and authorize a user NAI in a roaming environment. The NAI is obtained via CHAP (for traditional PPP service) or a Foreign Agent Challenge (for Mobile IP service). A shared secret exists between the mobile and its HAAA. The FAC will typically be computed in a manner consistent with CHAP. o Transport wireless data attributes from the home network to the Serving network. This may often take the form of a user profile. o Encrypt or sign one or more AVPs in an AAA message between home, serving network, or some broker across multiple AAA server hops. o Support a reliable AAA transport mechanism. o 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. o Retransmission is controlled by the reliable AAA transport mechanism, and not by lower layer protocols such as TCP.

認証Oおよびローミング環境でのユーザーNAIを承認。 NAIは、(伝統的なPPPサービス用)CHAPまたは(モバイルIPサービスのための)外部エージェントチャレンジによって得られます。共有秘密は、モバイルとそのHAAAの間に存在します。 FACは、典型的には、CHAPと一致するように計算されます。 Oトランスポート無線データは、サービスネットワークへのホームネットワークからの属性。これは、多くの場合、ユーザープロファイルの形をとることができます。 O、複数のAAAサーバのホップ間のネットワーク、またはいくつかのブローカーを提供し、家庭とのAAAメッセージ内の1つまたは複数のAVPを暗号化または署名。 O信頼性の高いAAA輸送メカニズムをサポートしています。 Oこの輸送機構はできメッセージが次のピアAAAアプリケーションに、またはタイムアウトが発生したことが配信されたAAAアプリケーションに知らせるであろう。 O再送が信頼AAA搬送機構によってではなく、TCPのような下位層プロトコルによって制御されます。

o 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. However, if the message fails to pass authentication, it will not be acknowledged. o Acknowledgements should be allowed to be piggybacked in AAA messages o The reliable transport mechanism features shall have the capability to detect silent failures of the AAA peer or path to the AAA peer, to manage failure on a proactive basis. o 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. o Support both proxy and non-proxy brokers, where non-proxy brokers imply the broker terminates an entire request and initiates a new request. AAA brokers should have the capability to modify certain parts of AAA messages whereby to operate to in non-proxy or proxy environments. o Provide message integrity and identity authentication on a per hop (AAA node) basis. o 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. o 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. o Provides security between AAA servers, and between AAA server and PDSN or HA via IP security.

O AAAメッセージが転送される、またはメッセージのオプションや意味がAAAプロトコルに準拠していない場合でも、トランスポート・メカニズムは、ピアがAAAメッセージを受け取ったことを認めるだろう。メッセージが認証を渡すために失敗した場合は、それが認められないだろう。 O謝辞は、信頼性の高い搬送機構の特徴は、積極的なベースで、障害を管理するために、AAAピアにAAAピアまたはパスのサイレント障害を検出する能力を持たなければならないoをAAAメッセージに便乗することを許可する必要があります。 O AAAトランザクションに関連付けられたラウンドトリップの数を最小限にするために、AAAメッセージにデジタル証明書をトランスポート。注:この要件は、AAAのアプリケーションではなく、移動局に適用されます。 Oプロキシと非プロキシのブローカーは、ブローカーが要求全体を終了し、新しい要求を開始暗示非プロキシブローカー、両方をサポートしています。非プロキシまたはプロキシ環境で動作するようにすることによりAAAブローカーはAAAメッセージの特定の部分を変更する能力を有するべきです。 Oホップ毎(AAAノード)に基づいて、メッセージの完全性と識別認証を提供します。 Oリプレイ保護し、すべての許可およびアカウンティングメッセージ用のオプションの否認防止機能をサポートしています。 AAAプロトコルは、事前の許可メッセージと照合するアカウンティングメッセージのための機能を提供しなければなりません。 Oの両方の二国間の取り決めを経由して提供し、ホームネットワーク間の会計クリアリングハウスとの和解を提供するブローカーのAAAサーバを経由して会計サポートしています。プライベートネットワークやホームISPがサービスを要求する移動局を認証する場合は、プライベートネットワークやホームISPネットワークはまた、ホームサービスプロバイダまたはブローカーとの電荷を調整することに同意することを明示的な合意があります。リアルタイム会計はサポートされなければなりません。 oはIPセキュリティ経由でAAAサーバの間、およびAAAサーバおよびPDSNまたはHA間のセキュリティを提供します。

3.2. Mobile IP Specific Requirements and AAA
3.2. モバイルIP固有の要件とAAA
3.2.1. Mobile IP Security Discussion
3.2.1. モバイルIPセキュリティディスカッション

Three Mobile IP security extensions are defined in RFC 2002:

3つのモバイルIPセキュリティ拡張は、RFC 2002で定義されています。

        . HA - FA
        . MN - FA
        . HA - MN
        

Therefore, Mobile IP and IPsec security models differ in that Mobile IP provides its own authentication mechanisms calculated within the Mobile IP registration procedures whereas IPsec uses IPsec AH.

したがって、モバイルIPおよびIPSecセキュリティモデルは、モバイルIPは、IPSecがIPSec AHを使用するのに対し、モバイルIP登録手順内で計算独自の認証メカニズムを提供するという点で異なります。

The keys and SPIs associated with the MN-FA and HA-FA extensions need to be dynamically established in a roaming wireless carrier environment. The MN-FA extension is useful for allowing a new FA (PDSN) to quickly authenticate a mobile using the previous foreign agent extension. The HA-FA extension is useful for the HA to ensure that only FAs from carrier's with roaming agreements access the HA. The MN-HA is usually provisioned, but for dynamic Home Agent assignment, this security association must be dynamically created.

MN-FAとHA-FAの拡張子に関連付けられたキーとのSPIは、動的にローミング無線キャリア環境で確立する必要があります。 MN-FAの拡張子は新しいFA(PDSN)はすぐに前の外国人のエージェントの拡張機能を使用してモバイルを認証できるようにするために有用です。 HAは、ローミング契約を結んでいる事業者からの唯一のFAはHAにアクセスすることを確実にするためのHA-FAの拡張に便利です。 MN-HAは通常、プロビジョニングされますが、ダイナミックなホームエージェントの割り当てのために、このセキュリティアソシエーションを動的に作成する必要があります。

It is possible to use IPsec AH between MN and FA, FA and HA, and MN and HA. IKE may be used to establish security associations between these entities. However, use of IKE may pose a problem for smaller mobiles and may introduce unacceptable delays for certain applications (e.g., Voice Over IP). The following three sections outline Mobile IP specific functions that benefit from AAA based key distribution.

MNとFA、FAとHA、およびMNとHA間のIPsec AHを使用することが可能です。 IKEは、これらのエンティティ間のセキュリティアソシエーションを確立するために使用することができます。しかし、IKEの使用が少ない携帯電話のための問題を提起することができ、特定の用途のために許容できない遅延を導入することができる(例えば、ボイスオーバーIP)。次の3つのセクションでは、AAAベースのキー配布恩恵を受けるモバイルIP特定の機能の概要を説明します。

3.2.2. Dynamic Home Agent Assignment
3.2.2. ダイナミックなホームエージェントの割り当て

A visited or home AAA server will optionally be able perform dynamic HA assignment. For dynamically assigned HA, the visited AAA server will indicate to the home AAA server whether it supports dynamic HA assignment in those cases in which the mobile node requests dynamic assignment. If so indicated, the home AAA server may choose to allow the visited AAA server to perform the HA assignment. Otherwise, the home AAA assigns the HA.

訪問やホームAAAサーバは、必要に応じてダイナミックHA割り当てを行うことができるようになります。それは、モバイルノードが動的割り当てを要求するような場合でダイナミックHA割り当てをサポートしているかどうかを動的に割り当てられるHAのために、訪問したAAAサーバは、ホームAAAサーバに指示します。そう示された場合は、ホームAAAサーバは、訪問したAAAサーバがHAの割り当てを行うことを可能にすることもできます。それ以外の場合は、ホームAAAは、HAを割り当てます。

3.2.3. Fast Handoff
3.2.3. 高速ハンドオフ

To achieve a faster handoff, the mobile may attempt to avoid an AAA transaction with the home AAA server. To accomplish this, the mobile may send the PDSN the Previous FA address in the RRQ message from the mobile, along with the MN-FA authentication extension. The new PDSN passes the Previous FA address and MN-FA authentication extension to the visited AAA server. If the visited AAA server is able authenticate the MN-FA authentication extension for the mobile, then the visited AAA may be able to avoid an actual transaction to the home AAA server.

より高速ハンドオフを実現するために、モバイルは、ホームAAAサーバとのAAAトランザクションを避けるために試みることができます。これを達成するために、モバイルは、MN-FA認証拡張に伴い、モバイルからのRRQメッセージにPDSNに前のFAアドレスを送信することができます。新しいPDSNは、訪問したAAAサーバに前のFAアドレスとMN-FA認証拡張を渡します。訪問したAAAサーバは、モバイル用MN-FA認証拡張を認証できるようであれば、訪問したAAAは、ホームAAAサーバへの実際の取引を避けることができるかもしれません。

3.2.4. HA-FA Authentication
3.2.4. HA-FA認証

To achieve a fast registration for the case of a mobile station with a Home Agent, the PDSN and HA may receive from the AAA mechanism a HA-FA key and SPI that is used to authenticate the PDSN and the HA to each other.

ホームエージェントと移動局の場合のための高速登録を達成するために、PDSNとHAは、AAAメカニズムから互いにPDSNとHAを認証するために使用されるHA-FAキーとSPIを受けることができます。

3.2.5. Key Distribution
3.2.5. キー配布

These functions are primarily useful in a wireless environment in which handoffs may occur rapidly (implying a need for low latency), or where mobile devices have limited computing power. To achieve these functions, AAA will be used to securely pass keys and SPIs between the serving network and target network in encrypted form. These keys are then used for the specific functions outlined in this document.

これらの関数は、ハンドオフは、(低遅延の必要性を意味する)、急速に起こる可能性のある無線環境において主に有用である、またはモバイルデバイスは、計算能力が限られている場合。これらの機能を達成するために、AAAを確実に暗号化された形式でサービングネットワークとターゲット・ネットワークとの間でキーおよびSPIを渡すために使用されるであろう。これらのキーは、この文書で概説され、特定の機能に使用されています。

3.3. IKE and AAA
3.3. IKEおよびAAA

The use of IKE in the cdma2000 wireless architecture requires the use of certificates. However, the AAA servers may be able to distribute a pre- shared key to the Mobile IP Agents for use during Phase 1 ISAKMP exchanges. This may lessen the need for on-line revocation checks.

CDMA2000無線アーキテクチャでのIKEの使用は、証明書を使用する必要があります。しかしながら、AAAサーバは、フェーズ1 ISAKMP交換中に使用するためのモバイルIPエージェントに事前共有キーを配布することができるかもしれません。これは、オンライン失効チェックの必要性を軽減することがあります。

3.4. Interoperability with RADIUS
3.4. RADIUSとの相互運用性

Users with a home AAA server based on RADIUS may desire to roam into a wireless carrier network that uses "new" AAA servers based on the requirements in this document, and vice verse. The AAA protocol should be designed in a way so as to make conversions to and from RADIUS messages straight forward. This will allow for the development of gateway processes to aid in interoperability. Note: The features of the new AAA protocols which are beyond the feature set of the RADIUS protocol will not be available for users while on home or serving networks based on RADIUS.

RADIUSに基づいたホームAAAサーバを持つユーザーは、この文書の要件、およびその逆をもとに、「新しい」AAAサーバを使用してワイヤレスキャリアネットワークにローミングすることを望むかもしれません。まっすぐRADIUSメッセージから変換を行うようにAAAプロトコルは、方法で設計されるべきです。これは、相互運用性を支援するためのゲートウェイ・プロセスの開発が可能になります。注:RADIUSに基づいて、家庭でのネットワークやサービスを提供しながら、RADIUSプロトコルの機能セットを超えて新しいAAAプロトコルの機能は、ユーザーのために使用することはできません。

4. References
4.参考文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

5. Security Considerations
5.セキュリティについての考慮事項

This document is very much about security. These requirements do not require the serving and home networks to not be in the same domain nor must they have a direct relationship. The serving network requires authorization from the home network so that the serving network obtains proof it will get paid for services rendered to the mobile. This implies the home network must authenticate the user. AAA functions must be performed in a secure manner. The requirements contained in section 2 outline the security required.

この文書では、セキュリティについて非常に多くのです。これらの要件は、同じドメイン内ではないと給仕や家庭のネットワークを必要としないも、彼らは直接的な関係を持っている必要があります。サービングネットワークは、それがモバイルに提供されたサービスに対して支払われます証明を取得するようにサービスネットワークは、ホームネットワークからの許可が必要です。これは、ホームネットワークがユーザーを認証する必要がありますを意味します。 AAA機能は、安全な方法で実行されなければなりません。セクション2に含まれる要件は、必要なセキュリティを概説します。

Mobile IP supports authentication mechanisms outside IP Security. These mechanism may be enhanced in a cellular wireless environment by allowing a home AAA server to distribute keys to the serving network. Additionally, the home AAA server may be able to send a pre-shared key to be used in Phase 1 ISAKMP security association establishment between FA and HA. These keys would sent in encrypted form from the home network to the serving network. As supported in the requirements contained in section 2, the encryption could be handled via public cryptography and certificates.

モバイルIPは、IPセキュリティ外部の認証メカニズムをサポートしています。これらのメカニズムは、ホームAAAサーバは、サービングネットワークにキーを配布できるようにすることで、携帯無線環境で強化することができます。また、ホームAAAサーバは、FAとHA間のフェーズ1 ISAKMPセキュリティアソシエーションの確立に使用する事前共有キーを送信することができるかもしれません。これらのキーは、サービングネットワークにホームネットワークから暗号化された形式で送信されます。セクション2に含まれる要件ではサポートとして、暗号化は、公開暗号と証明書を介して処理することができます。

6. IANA Considerations
6. IANAの考慮事項

This document does not create any new number spaces for IANA administration.

このドキュメントは、IANAの投与のための任意の新しい番号のスペースを作成しません。

7. Acknowledgements
7.謝辞

The authors are active members of the TIA TR45.6 committee.

著者は、TIA TR45.6委員会のメンバーです。

8. Authors' Addresses
8.著者のアドレス

Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025 USA

パットR.カルフーンネットワークとセキュリティ研究センター、日Labsのサン・マイクロシステムズ株式会社15ネットワークサークルメンロパーク、CA 94025 USA

Phone: (650) 786-7733 EMail: pcalhoun@eng.sun.com

電話:(650)786-7733 Eメール:calhoun@eng.sub.com

Ed Campbell CommWorks Corporation, A 3Com Company 3800 Golf Road Rolling Meadows, IL 60008

エド・キャンベルCommWorks社、3Comの会社3800ゴルフの道ローリングメドウズ、IL 60008

Phone: (847)262-2325 E-Mail: ed_campbell@commworks.com

電話番号:(847)262-2325 Eメール:ed_campbell@commworks.com

Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA

ゴパルDommetyシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA

EMail: gdommety@cisco.com

メールアドレス:gdommety@cisco.com

Tom Hiller Rm 2F-218 263 Shuman Dr. Lucent Technologies Naperville, IL USA

トム・ヒラーRmの2F-218 263シューマン博士ルーセント・テクノロジーズネーパーヴィル、IL USA

Phone: (630) 979-7673 EMail: tom.hiller@lucent.com

電話:(630)979-7673 Eメール:tom.hiller@lucent.com

Raymond T. Hsu Qualcomm Inc. 6455 Lusk Blvd. San Diego, CA 92121 USA

レイモンド・T.・スークアルコム社6455ラスクブルバードサンディエゴ、CA 92121 USA

Phone: (619) 651-3623 EMail: rhsu@qualcomm.com

電話:(619)651-3623 Eメール:rhsu@qualcomm.com

Mark A. Lipford Sprint PCS 15405 College Blvd. Lenexa, KS 66219

マーク・A. LipfordスプリントPCS 15405カレッジ・ブルバードレネクサ、KS 66219

Phone: (913) 890-4248 EMail: mlipfo01@sprintspectrum.com

電話:(913)890-4248 Eメール:mlipfo01@sprintspectrum.com

Serge Manning Award Solutions, Inc. 800 E. Campbell Rd., Suite 120 Richardson, TX 75081

セルジュ・マニング賞ソリューションズ社800 E.キャンベルRdを。、スイート120リチャードソン、TX 75081

Phone: (972) 664-0727 x350 EMail: serge@awardsolutions.com

電話:(972)664-0727 x350メール:serge@awardsolutions.com

Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA

ピーター・J.マッキャンルーセント・テクノロジーズRmの2Z-305 263シューマンブルバードネーパーヴィル、IL 60566 USA

Phone: (630) 713 9359 EMail: mccap@lucent.com

電話:(630)713 9359 Eメール:mccap@lucent.com

Mark Munson 1371 Winding Branch Circle Atlanta, Georgia 30338 USA

支店サークルアトランタ、ジョージア30338 USA巻マーク・マンソン1371

Phone: (678) 339-4439 EMail: mmunson@gte.net

電話:(678)339-4439 Eメール:mmunson@gte.net

Haeng Koo Samsung Telecommunications America, Inc. 1130 E. Arapaho Road Richardson, TX 75081 USA

Haengクーサムスン通信アメリカ、Inc.の1130 E.アラパホー・ロード・リチャードソン、TX 75081 USA

Phone: (972)761-7755 EMail: hskoo@sta.samsung.com

電話:(972)761-7755 Eメール:hskoo@sta.samsung.com

Pat Walsh Lucent Technologies 263 Shuman Blvd. 1F-545 Naperville, IL

パット・ウォルシュルーセント・テクノロジーズ263シューマンブルバード1F-545ネーパーヴィル、IL

Phone: +1 630-713-5063 EMail: walshp@lucent.com

電話:+1 630-713-5063電子メール:walshp@lucent.com

Yingchun Xu WaterCove Networks One Century Centre, Suite 550 1750 E. Golf Road Schaumburg, IL

Yingchun徐WaterCoveネットワークの一つセンチュリーセンター、スイート550 1750 E.ゴルフロードショームバーグ、IL

Phone: +1 847-477-9280 EMail: yxu@watercove.com

電話:+1 847-477-9280電子メール:yxu@watercove.com

Brent Hirschman 1501 Shure Dr. Arlington Heights, IL 60006 USA

ブレントハーシュマン1501 Shureの博士アーリントンハイツ、IL 60006 USA

Phone: (847) 632-1563 EMail: qa4053@email.mot.com

電話:(847)632-1563 Eメール:qa4053@email.mot.com

Eric Jaques Vodafone 2999 Oak Road, MS-750 Walnut Creek, CA 94596 USA

エリック・ジャックボーダフォン2999オークロード、MS-750ウォルナットクリーク、CA 94596 USA

Phone: +1-925-210-3900 EMail: ejaques@akamail.com

電話:+ 1-925-210-3900 Eメール:ejaques@akamail.com

Sanjeevan Sivalingham Ericsson Wireless Communications Inc., Rm Q-356C 6455 Lusk Blvd San Diego, CA 92126 USA

Sanjeevan Sivalinghamエリクソンワイヤレスコミュニケーションズ株式会社、RmのQ-356C 6455ラスクブルバードサンディエゴ、CA 92126 USA

Phone: (858) 332-5670 EMail: s.sivalingham@ericsson.com

電話:(858)332-5670 Eメール:s.sivalingham@ericsson.com

Xing Chen Alcatel USA 1000 Coit Road Plano, TX 75075 USA

興チェンアルカテルUSA 1000年コイトロードプラノ、TX 75075 USA

Phone: 972-519-4142 Fax: +1 972-519-3300 EMail: xing.chen@usa.alcatel.com

電話:972-519-4142ファックス:+1 972-519-3300電子メール:xing.chen@usa.alcatel.com

Byung-Keun Lim LG Electronics Inc. 533, Hogye-dong, Donan-Ku, Anyang-shi, Kyungki-do, 431-080, Korea

びゅんgーけうん ぃm LG えぇctろにcs いんc。 533、 ほぎぇーどんg、 どなんーく、 あにゃんgーし、 きゅんgきーど、 431ー080、 これあ

Phone: +82-31-450-7199 Fax: +82-31-450-7050 EMail: bklim@lge.com

電話:+ 82-31-450-7199ファックス:+ 82-31-450-7050 Eメール:bklim@lge.com

Hajime Shiino Lucent Technologies Japan Ltd. 25 Mori Bldg. 1-4-30 Roppongi, Minato-ku Tokyo Japan

はじめ しいの ぅせんt てchのぉぎえs じゃぱん Ltd。 25 もり Bldg。 1ー4ー30 ろっぽんぎ、 みなとーく ときょ じゃぱん

Phone: +81-3-5561-3695 EMail: hshiino@lucent.com

電話:+ 81-3-5561-3695 Eメール:hshiino@lucent.com

Shinichi Baba Toshiba America Research, Inc. PO Box 136, Convent Station, NJ 07961-0136 USA

真一馬場東芝アメリカ研究、株式会社私書箱136、コンベントステーション、NJ 07961から0136 USA

Phone: (973) 829-4795 EMail: sbaba@tari.toshiba.com

電話:(973)829-4795 Eメール:sbaba@tari.toshiba.com

Takahiro Ayaki DDI corporation Ichibancho FS Bldg. 8, Ichibancho, Chiyoda-ku Tokyo Japan

たかひろ あやき っぢ こrぽらちおん いちばんちょ FS Bldg。 8、 いちばんちょ、 ちよだーく ときょ じゃぱん

Phone: +81-3-3221-9682 EMail: ayaki@ddi.co.jp

電話:+ 81-3-3221-9682 Eメール:ayaki@ddi.co.jp

Alan Hameed Fujitsu 2801 Telecom Parkway Richardson, Texas 75082 USA

アラン・ハミード富士通2801テレコムパークウェイリチャードソン、テキサス州75082 USA

Phone: (972) 479-2089

電話:(972)479-2089

Charles N. Lo Vodafone AirTouch 2999 Oak Rd Walnut Creek, CA 94596 USA

チャールズN.ローボーダフォンAirTouch 2999オークRdのウォルナットクリーク、CA 94596 USA

Phone: (925) 210-3460 EMail: Charles.Lo@vodafone-us.com

電話:(925)210-3460 Eメール:Charles.Lo@vodafone-us.com

Takuo Seki IDO Corporation Gobancho YS Bldg. 12-3, Gobancho, Chiyoda-ku Tokyo Japan

たくお せき いど こrぽらちおん ごばんちょ YS Bldg。 12ー3、 ごばんちょ、 ちよだーく ときょ じゃぱん

Phone: +81-3-3263-9660 EMail: t-seki@kddi.com

電話:+ 81-3-3263-9660 Eメール:t-seki@kddi.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

著作権(C)インターネット協会(2001)。全著作権所有。

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.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。