Network Working Group M. Nakhjiri, Ed.
Request for Comments: 5030 Motorola
Category: Informational K. Chowdhury
Starent Networks
A. Lior
Bridgewater Systems
K. Leung
Cisco Systems
October 2007
Mobile IPv4 RADIUS 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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures.
この文書では、適用性声明だけでなく、モバイルIPv4をサポートするために、リモート認証ダイヤルインユーザーサービス（RADIUS）の拡張子を指定するためのスコープの定義を提供します。目標は、RADIUSの仕様はモバイルIPv4シグナリング手順を支援するために属性をできるようにすることです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
To kick start the Mobile IPv4 [RFC3344] processing of its packets by Mobile IP agents, a mobile node (MN) needs to be able to acquire a pair of home and care of addresses (HoA and CoA, respectively), find a willing agent to act as a Home Agent (HA) for the MN and perform a registration process with the HA. The registration process consists of an exchange of a registration request and a registration reply message between the MN and the HA. The specification in [RFC3344] allows an MN to start the registration process prior to having acquired its home address or the address of its HA. Acquiring those parameters by the MN is typically part of a process referred to as bootstrapping.
モバイルIPv4 [RFC3344]モバイルIPエージェントによって、そのパケットの処理を開始するキックする、モバイルノード（MN）は、（それぞれのHoAとCoA）アドレスの家庭及びケアのペアを取得することができる必要がある、喜んでエージェントを見つけますMNのためのホームエージェント（HA）として機能し、HAの登録処理を実行します。登録処理は、登録要求とMNとHAの間の登録応答メッセージの交換から成ります。 [RFC3344]での指定は、MNは、前の自宅の住所またはそのHAのアドレスを取得したに登録プロセスを開始することができます。 MNによってこれらのパラメータを取得することは、典型的にはブートストラップと呼ばれるプロセスの一部です。
Successful processing of registration request and reply messages, among other things, depends on successful creation and verification of a number of authentication extensions developed specifically to protect the integrity and security of these messages and the entities processing them, i.e., MN, HA and some times, Foreign Agents (FAs) [RFC3344]. Creation as well as verification of these extensions requires existence of trust relationships and shared keys between MN and each of the mobility agents. However, creation of these trust relationships, typically referred to as mobility security associations (MSAs), is considered outside the scope of the base Mobile IPv4 specification defined in [RFC3344]. Avoiding the scalability issues arising from creating static security associations between an MN and all possible mobility agents is desired. Thus, establishing the associations dynamically, using the pre-existing relationship between the MN and the AAA server, is preferred.
成功した登録要求の処理と応答メッセージ、とりわけ、すなわち、これらのメッセージおよびそれらを処理するエンティティの整合性とセキュリティを保護するために特別に開発された認証の拡張機能の数が正常に作成および検証に依存し、MN、HAおよびいくつかの回、フォーリンエージェント（FAS）[RFC3344]。これらの拡張機能の作成だけでなく、検証は、信頼関係の存在とMNとモビリティエージェントのそれぞれとの間で共有鍵が必要です。しかしながら、これらの信頼関係の作成は、典型的には、モビリティセキュリティアソシエーション（のMSA）と呼ばれる、[RFC3344]で定義されたベースモバイルIPv4仕様の範囲外であると考えられます。 MNおよびすべての可能なモビリティエージェント間の静的なセキュリティアソシエーションを作成するに起因するスケーラビリティの問題を避けることが望まれています。したがって、MNとAAAサーバとの間の既存の関係を使用して、動的関連付けを確立する、ことが好ましいです。
To allow for utilization of an existing AAA infrastructure in the bootstrapping of the Mobile IPv4 parameters and security relationships, the Mobile IPv4 working group has developed Mobile IPv4 extensions to allow the MN to authenticate to the home AAA server [RFC4721]. The extensions also allow the MN to request assistance from the AAA server in creation of mobility security associations [RFC3957] with the mobility agents, using the pre-established trust relationship between the MN and its home AAA server.
モバイルIPv4パラメータとセキュリティ関係のブートストラップの既存のAAAインフラストラクチャの利用を可能にするために、モバイルIPv4ワーキンググループは、MNがホームAAAサーバ[RFC4721]への認証できるようにするために、モバイルIPv4拡張を開発しました。拡張子はまた、MNとそのホームAAAサーバの間で事前に確立された信頼関係を使用して、MNは、モビリティエージェントとモビリティセキュリティアソシエーション[RFC3957]の作成中にAAAサーバからの支援を要請することができます。
While Mobile IPv4 extensions are necessary for implementing a utilization of the AAA infrastructure for Mobile IPv4 purposes, they are not sufficient. The interaction between the MN and the mobility agents (HA and FA) is based on Mobile IP signaling. However, the signaling beyond the mobility agents to the AAA server is typically based on AAA protocols. Around the time, when the specification of the aforementioned Mobile IP extensions was being developed, the AAA community was in the process of designing a successor to RADIUS.
モバイルIPv4拡張は、モバイルIPv4の目的のためのAAAインフラストラクチャの利用を実現するために必要ですが、彼らは十分ではありません。 MNとモビリティエージェント（HAとFA）との間の相互作用は、モバイルIPシグナリングに基づいています。しかし、AAAサーバへのモビリティエージェントを超えたシグナリングは通常、AAAプロトコルに基づいています。前述したモバイルIP拡張の仕様が開発されていた時、周り、AAAのコミュニティは、RADIUSの後継を設計する過程にありました。
Thus, the Mobile IP group developed a set of guidelines and requirements from the Mobile IP standpoint [RFC2977] specifically for such a successor (which turned out to be Diameter). These requirements led to the development of a specification for using Diameter in Mobile IPv4 bootstrapping [RFC4004]. The requirements for Mobile IP Authentication, Authorization, and Accounting [RFC2977] were standardized after the standardization of RADIUS [RFC2865].
したがって、モバイルIP基は、具体的には（直径であることが判明した）そのような後継者のためにモバイルIPの観点[RFC2977]のガイドラインおよび要件のセットを開発しました。これらの要件は、モバイルIPv4ブートストラップ[RFC4004]の直径を使用するための仕様の開発につながりました。モバイルIP認証、許可、アカウンティング[RFC2977]のための要件は、RADIUS [RFC2865]の標準化後に標準化しました。
Thus, it is obvious that RADIUS does not and cannot meet all the requirements listed in [RFC2977] without undergoing an extensive design change. Consequently, within IETF no RADIUS attributes have been standardized for Mobile IP support thus far. However, in the absence of IETF standardized RADIUS attributes, different wireless SDOs have taken the path of developing Vendor Specific Attributes (VSAs) for providing Mobile IPv4 support. The use of different vendor specific RADIUS attributes and procedures for the same purpose of Mobile IPv4 bootstrapping at different SDOs is deemed to cause a lack interoperability between these wireless standards, potentially hindering mobility across these wireless networks.
したがって、RADIUSはないと豊富な設計変更を受けることなく、[RFC2977]に記載されているすべての要件を満たすことができないことは明らかです。その結果、IETF内にはRADIUS属性は、これまでモバイルIPをサポートするための標準化されていません。しかしながら、IETF標準化されたRADIUS属性の不在下で、異なる無線のSDOは、モバイルIPv4サポートを提供するために開発ベンダー固有アトリビュート（VSA）のパスをとっています。異なるのSDOのモバイルIPv4ブートストラップの同じ目的のために異なるベンダー固有のRADIUS属性と手順の使用は、潜在的にこれらの無線ネットワーク間のモビリティを妨げ、これらの無線規格間の不足の相互運用性を引き起こすものとみなされます。
To respond to the described issue, it is desired to standardize a set of RADIUS attributes within IETF to allow a consistent and interoperable interaction with RADIUS based AAA infrastructure during the Mobile IPv4 Registration procedure. The bootstrapping attributes can include configuration parameters as well as material used for provisioning security of Mobile IPv4 messaging (authentication) as defined by [RFC4721] and [RFC3957].
説明している問題に対応するために、RADIUSがモバイルIPv4登録手順の間にRADIUSベースのAAAインフラストラクチャとの一貫した相互運用可能な相互作用を可能にするために、IETF内の属性のセットを標準化することが望まれます。ブートストラップ属性は[RFC4721]及び[RFC3957]で定義されるようにモバイルIPv4メッセージング（認証）のセキュリティをプロビジョニングするために使用されるコンフィギュレーションパラメータ、ならびに材料を含むことができます。
As it stands today, RADIUS cannot meet all the requirements in [RFC2977]. The purpose of these requirements is to define a set of goals and non-goals specifically for RADIUS when it comes to assisting mobile nodes and mobility agents in bootstrapping Mobile IPv4 operation.
それが今日の現状では、RADIUSは、[RFC2977]ですべての要件を満たすことができません。これらの要件の目的は、ブートストラップモバイルIPv4動作でモバイルノードと、モビリティエージェントを支援することになるとRADIUSのための具体的目標と非目標のセットを定義することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Since this document serves as a requirement specification for RADIUS extensions that support Mobile IPv4 interaction with RADIUS infrastructure, the goals and non-goals refer to only those RADIUS extensions that are required to support Mobile IPv4.
この文書は、RADIUSインフラストラクチャとモバイルIPv4相互作用をサポートするRADIUS拡張の要求仕様となるため、目標と非目標は、モバイルIPv4をサポートするために必要とされるのみRADIUS拡張を指します。
The scope of the work is to standardize RADIUS attributes and to define the procedure by which the Mobile IPv4 agents (e.g., Home agent (HA) and Foreign Agent (FA)) map the Mobile IP registration message fields into the proposed RADIUS attributes, and vice versa.
仕事の範囲は、RADIUS属性およびモバイルIPv4剤（例えば、ホームエージェント（HA）とフォーリンエージェント（FA））が提案されているRADIUS属性にモバイルIP登録メッセージのフィールドをマップする手順を定義するために標準化することで、逆に。
o RADIUS servers are REQUIRED to be able to understand and process the attributes to be defined for Mobile IPv4 support and to perform verification of authentication extensions specified in [RFC4721]. RADIUS proxies are expected to be able to forward messages including the Mobile IPv4 related attributes as they would with any other RADIUS messages and attributes.
O RADIUSサーバは理解し、処理する属性をモバイルIPv4サポート用に定義すると、[RFC4721]で指定された認証の拡張機能の検証を実行することができるように要求されています。 RADIUSプロキシは、それらが他のRADIUSメッセージや属性と同じように、モバイルIPv4関連の属性を含むメッセージを転送することができると期待されています。
o All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs the following: [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], [RFC3576], [RFC3579], and [RFC3580].
[RFC2865]、[RFC2866]、[RFC2867]、[RFC2868]、[RFC2869]、[RFC3576]、[RFC3579]及び[RFC3580]：OすべてRADIUS作業はRFCに次のことを含む、既存のRADIUSのRFCとの下位互換性がなければなりません。
o Mobile IP agents (FA and HA) are REQUIRED to operate as RADIUS clients (NASes in context of [RFC2865]) when translating RADIUS signaling into Mobile IP signaling, and vice versa. Details on the behavior of Mobile IP agents as RADIUS clients are to be provided by the solution document describing the RADIUS extensions for Mobile IP support.
モバイルIPエージェント（FAとHA）O変換RADIUSモバイルIPシグナリング、およびその逆にシグナリングするときRADIUSクライアント（[RFC2865]の文脈でのNAS）として動作することが要求されています。 RADIUSクライアントとして、モバイルIPエージェントの動作の詳細については、モバイルIPをサポートするためのRADIUS拡張を記述したソリューションの文書により提供されることになります。
The scope of this work is to only standardize RADIUS attributes and to define the procedure by which the Mobile IPv4 agents (e.g., Home agent (HA) and Foreign Agent (FA)) map the Mobile IP registration message fields into the proposed RADIUS attributes, and vice versa. Extension of the functionality of the existing protocol or RADIUS servers is not intended. More specifically, the following are NON-GOALS:
この作業の範囲は、唯一のRADIUS属性とによって、モバイルIPv4剤（例えば、ホームエージェント（HA）とフォーリンエージェント（FA））の手順を定義するために標準化することも提案されているRADIUS属性にモバイルIP登録メッセージのフィールドをマップ、およびその逆。既存のプロトコルまたはRADIUSサーバの機能の拡張を意図したものではありません。具体的には、次のようにNON-目的は次のとおりです。
o Enhancing RADIUS Security: Creating new security properties for RADIUS, such as creating key transport capabilities is not the goal. No new security mechanisms are to be defined for the transport of RADIUS Access Requests in relation to the support of Mobile IPv4 bootstrapping. Existing RADIUS authentication procedures, e.g., Message-Authenticator (80) described in [RFC2869], are used. The security considerations for using RADIUS in bootstrapping Mobile IPv4 are described in a later section of this document.
O強化RADIUSセキュリティ：そのようなキー輸送機能の作成など、RADIUSのための新しいセキュリティプロパティを作成することは目的ではありません。新しいセキュリティメカニズムは、モバイルIPv4のブートストラップのサポートに関連したRADIUSアクセス要求の輸送のために定義されるべきではありません。既存のRADIUS認証手順は、例えば、メッセージオーセンティケータ（80）は[RFC2869]に記載の、使用されています。ブートストラップモバイルIPv4にRADIUSを使用するためのセキュリティ問題は、この文書の後のセクションに記載されています。
o Enhancing RADIUS transport reliability: The transport properties of RADIUS remain intact. No new reliability mechanisms are defined in the transport of such Access Requests.
RADIUS輸送の信頼性を向上○：RADIUSの輸送特性はそのまま残ります。新たな信頼性のメカニズムは、そのようなアクセス要求の輸送に定義されていません。
o Extending RADIUS message set: RADIUS extensions for bootstrapping Mobile IPv4 are not to define new RADIUS messages. The Diameter Mobile IP application [RFC4004] has defined new command codes to support Mobile IP signaling, depending on whether Diameter server is dealing with a Mobile IP HA or an FA. RADIUS currently does not have any messages that correspond to these Diameter commands. Instead, RADIUS extensions for Mobile IPv4 bootstrapping need to provide proposals for new RADIUS attributes that facilitate Diameter-RADIUS messaging translation without defining any new RADIUS messaging. At the same time, the RADIUS extensions for Mobile IPv4 need to re-use Diameter AVPs to the fullest extent possible.
RADIUSメッセージの設定の拡張○：ブートストラップモバイルIPv4用のRADIUS拡張を新しいRADIUSメッセージを定義することはありません。直径モバイルIPアプリケーション[RFC4004] Diameterサーバは、モバイルIP HAまたはFAを扱っているかどうかに応じて、モバイルIPシグナリングをサポートするための新しいコマンドコードを定義しています。 RADIUSは、現在、これらの直径のコマンドに対応したメッセージを持っていません。代わりに、モバイルIPv4ブートストラップ用のRADIUSの拡張機能は、新しいRADIUSメッセージを定義せずに直径-RADIUSメッセージの翻訳を促進する新しいRADIUS属性のための提案を提供する必要があります。同時に、モバイルIPv4のRADIUS拡張が可能な最大限の直径のAVPを再利用する必要があります。
o RFC 2977 compatibility: Extending RADIUS in a way that fulfills the full list of requirements in [RFC2977] will not be attempted.
O RFC 2977の互換性：[RFC2977]に要件の完全なリストを果たす方法で拡張RADIUSが試行されることはありません。
A specification of the RADIUS extensions for Mobile IPv4 needs to describe the full set of attributes required for RADIUS-Mobile IP interaction. While some of the attributes may already be standardized, others will require standardization and IANA type assignments.
モバイルIPv4のためのRADIUS拡張の仕様は、RADIUSモバイルIPの相互作用のために必要な属性の完全なセットを記述する必要があります。属性の一部は、すでに標準化されたかもしれないが、他は標準化とIANAタイプの割り当てが必要になります。
This requirement document does not allocate any numbers, so there are no IANA considerations. On the other hand, future solution documents for RADIUS support of Mobile IPv4 will likely introduce new RADIUS attributes. Thus, those documents will need new attribute type numbers assigned by IANA.
この要件文書は、任意の番号を割り当てていないので、何のIANAの考慮事項はありません。一方、モバイルIPv4のRADIUSサポートのための将来のソリューション文書はおそらく新しいRADIUS属性を紹介します。したがって、これらの文書は、IANAによって割り当てられた新しい属性タイプ番号が必要になります。
Enhancing security properties of RADIUS are a specific non-goal for the RADIUS extensions providing support for Mobile IP. Also, as this is a requirements document and not a solution specification document, no new security considerations are noted, aside from those that already exist for RADIUS. As such, the existing RADIUS security considerations described previously apply, and no additional security considerations are added here. For instance, the assumption in RADIUS is that intermediary nodes are trusted, while at the same time there is a concern on using AAA protocols that use hop-by-hop security to distribute keys. Use of hop-by-hop security for key distribution can be in conflict with some of the requirements stated in [RFC4962], such as the requirement on binding a key to its context and the requirement on limitation of the key scope. The former for instance states that a key MUST be bound to the parties that are expected to have access to the keying material, while the latter implies that parties that do not require access to a key to perform their role MUST not have access to the key. Both of these requirements rule against trusting intermediary nodes and proxies with distribution of keys. Due to lack of end-to-end security mechanisms for RADIUS, imposing a MUST requirement for not trusting proxies is not possible. The RADIUS Extension working group is in the process of specifying procedures for wrapping key materials within RADIUS attributes. For the time being, support of Mobile IP within RADIUS may need to be based on trust of intermediaries, despite the security considerations described.
RADIUSのセキュリティ性を高めることは、モバイルIPのサポートを提供するRADIUSの拡張のための具体的な非目標です。これは要件ドキュメントではなくソリューションの仕様書であるとしても、新たなセキュリティ上の考慮事項は、すでにRADIUSのために存在するものとは別に、指摘されていません。そのため、前述の既存のRADIUSセキュリティの考慮事項が適用され、追加のセキュリティの考慮事項は、ここに追加されません。例えば、RADIUSにおける仮定は、キーを配布するホップバイホップセキュリティを使用するAAAプロトコルを使用して上の懸念があると同時に、中間ノードは、信頼されていることです。鍵配布のためのホップバイホップセキュリティの使用は、そのコンテキストにキーとキー範囲の制限に関する要件を結合に対する要件として、[RFC4962]に記載された要件の一部と競合することができます。例えば、前者は後者が自分の役割を実行するためのキーへのアクセスを必要としない当事者がキーへのアクセス権を持っていなければならないことを意味するときにキーが、鍵材料へのアクセスを有することが期待されるパーティーにバインドする必要があること。これらの要件の両方が鍵の配布と中間ノードとプロキシを信頼に対してルール。 RADIUSのためのエンドツーエンドのセキュリティメカニズムの欠如に、プロキシを信頼しないためのMUST要件を課すことはできません。 RADIUS拡張ワーキンググループは、RADIUS属性内鍵材料を包装するための手順を特定する処理です。当分の間、RADIUS内のモバイルIPのサポートを説明し、セキュリティ上の考慮事項にもかかわらず、仲介者の信頼に基づいてする必要があるかもしれません。
When it comes to protecting attributes in the Access Request, [RFC2868], Section 3.5 provides a mechanism for encrypting RADIUS attributes, such as passwords. There is also work under progress for specifying wrapping of sensitive attributes, such as key material within RADIUS Access Accept messages. This work is currently considered part of RADIUS crypto-agility extensions and when completed can be used in the process of distributing sensitive attributes, such as keying material from RADIUS servers.
それがアクセス要求の属性を保護することになると、[RFC2868]は、3.5節では、パスワードなどのRADIUS属性を暗号化するためのメカニズムを提供します。メッセージを受け入れるRADIUSアクセス内などのキーマテリアルとして、敏感な属性の折り返しを指定するための進捗状況の下で働くもあります。この作品は現在、RADIUS暗号アジリティの拡張子の一部とみなされ、完成したときに、このようなRADIUSサーバから材料をキーイングなどの機密属性を、配布するプロセスで使用することができます。
It is also possible to protect RADIUS transactions using IPsec (e.g., as in RFC3579).
（RFC3579におけるように、例えば）IPsecを使用して、RADIUSトランザクションを保護することも可能です。
The authors would like to thank Alan DeKok for review and feedback, and Pete McCann and Jari Arkko for diligent shepherding of this document.
作者はこのドキュメントの勤勉なシェパディングのためのレビューとフィードバックのためのアランDeKok、そしてピートマッキャンとヤリArkkoに感謝したいと思います。
[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月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867]ソーン、G.、Aboba、B.、およびD.ミトン、 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更"、RFC 2867、2000年6月。
[RFC2977] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[RFC2977]ガラス、S.、ヒラー、T.、ジェイコブス、S.、およびC.パーキンス、 "モバイルIP認証、認可、およびアカウンティング要件"、RFC 2977、2000年10月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[RFC3957]パーキンス、C.とP.カルフーン、 "モバイルIPv4のための認証、許可、アカウンティング（AAA）の登録キー"、RFC 3957、2005年3月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004]カルフーン、P.、ヨハンソン、T.、パーキンス、C.、ヒラー、T.、およびP.マッキャン、 "直径モバイルIPv4アプリケーション"、RFC 4004、2005年8月。
[RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[RFC4721]パーキンス、C.、カルフーン、P.、およびJ. Bharatia、 "モバイルIPv4チャレンジ/レスポンス拡張（改訂版）"、RFC 4721、2007年1月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley氏、R。およびB. Aboba、 "認証、許可、アカウンティング（AAA）キー管理のための指針"、BCP 132、RFC 4962、2007年7月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.、およびI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W.、およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
、RFC 3576、2003年7月[RFC3576]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon氏、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "IEEE 802.1Xのリモート認証ダイヤルインユーザーサービス（RADIUS）使用上のガイドライン"、RFC 3580、2003年9月。
Authors' Addresses
著者のアドレス
Madjid Nakhjiri (editor) Motorola
マジドNakhjiri（編集者）、モトローラ
EMail: madjid.nakhjiri@motorola.com
メールアドレス：madjid.nakhjiri@motorola.com
Kuntal Chowdhury Starent Networks
Kuntalチョードリースタレントネットワークス
EMail: kchowdhury@starentnetworks.com
メールアドレス：kchowdhury@starentnetworks.com
Avi Lior Bridgewater Systems
アビLIORブリッジウォーターシステムズ
EMail: avi@bridgewatersystems.com
メールアドレス：avi@bridgewatersystems.com
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
ケント・レオンシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134米国
EMail: kleung@cisco.com
メールアドレス：kleung@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。