[要約] RFC 5030は、Mobile IPv4ネットワークでのRADIUSの要件を定義しています。このRFCの目的は、Mobile IPv4ネットワークでの認証、認可、およびアカウンティング（AAA）サービスのためのRADIUSプロトコルの使用を促進することです。
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
モバイルIPv4 RADIUS要件
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）拡張機能を指定するための適用性ステートメントとスコープ定義を提供します。目標は、半径属性の指定を許可して、モバイル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がHome AAAサーバーに認証できるようにモバイルIPv4拡張機能を開発しました[RFC4721]。また、拡張機能により、MNは、MNとHome AAAサーバーの間の事前に確立された信頼関係を使用して、モビリティセキュリティ協会[RFC3957]の作成[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]の要件は、半径の標準化[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内では、これまでのところモバイルIPサポートのために半径属性は標準化されていません。ただし、IETF標準化されたRADIUS属性がない場合、モバイルIPv4サポートを提供するために、さまざまなワイヤレスSDOがベンダー固有の属性（VSA）を開発するパスを取得しています。さまざまなベンダー固有のRADIUS属性と、異なるSDOでのモバイルIPv4ブートストラップと同じ目的での手順の使用は、これらのワイヤレス標準間の不足の相互運用性を引き起こし、これらのワイヤレスネットワーク全体でモビリティを妨げる可能性があるとみなされます。
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].
説明した問題に応答するために、IETF内の一連のRADIUS属性を標準化して、モバイルIPv4登録手順中にRADIUSベースのAAAインフラストラクチャとの一貫した相互運用可能な相互作用を可能にすることが望まれます。ブートストラップ属性には、[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操作のブートストラップでモバイルノードとモビリティエージェントの支援に関して、一連の目標と非ゴールを半径向けに定義することです。
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をサポートするために必要な半径拡張機能のみを指します。
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.
作業の範囲は、半径属性を標準化し、モバイルIPv4エージェント（例：ホームエージェント（HA）および外国エージェント（FA））がモバイルIP登録メッセージフィールドを提案されたRADIUS属性にマッピングする手順を定義することです。逆に。
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 半径サーバーは、モバイル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].
o すべての半径作業は、RFCを含む既存の半径RFCとの後方互換でなければなりません：[RFC2865]、[RFC2867]、[RFC2868]、[RFC2869]、[RFC3576]、[RFC3579]、[RFC3580]、[RFC2869]、[RFC2869]、[RFC3576]、
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.
o モバイルIPエージェント（FAおよびHA）は、RADIUSシグナル伝達をモバイルIPシグナル伝達に変換する際に、RADIUSクライアント（[RFC2865]のコンテキストのNASE）として動作する必要があります。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:
この作業の範囲は、半径属性のみを標準化し、モバイルIPv4エージェント（ホームエージェント（HA）および外国人エージェント（FA））がモバイルIP登録メッセージフィールドを提案されたRADIUS属性にマッピングする手順を定義することです。およびその逆。既存のプロトコルまたはRADIUSサーバーの機能の拡張は意図されていません。より具体的には、以下は非神格です。
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 半径のセキュリティの強化：主要な輸送機能の作成など、半径の新しいセキュリティプロパティの作成は目標ではありません。モバイルIPv4ブートストラップのサポートに関連して、RADIUSアクセス要求の輸送について、新しいセキュリティメカニズムを定義する必要はありません。[RFC2869]で説明されている既存のRADIUS認証手順、例えば、メッセージ - アーセンティケーター（80）が使用されます。モバイルIPv4のブートストラップで半径を使用するためのセキュリティ上の考慮事項については、このドキュメントの後のセクションで説明されています。
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.
o 半径輸送の信頼性の向上：半径の輸送特性はそのままです。このようなアクセス要求の輸送には、新しい信頼性メカニズムは定義されていません。
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.
o RADIUSメッセージセットの拡張：ブートストラップモバイルIPv4のRADIUS拡張機能は、新しいRADIUSメッセージを定義しません。直径モバイルIPアプリケーション[RFC4004]は、直径サーバーがモバイル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]の要件の完全なリストを満たす方法で半径を拡張しても試みられません。
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-Mobile 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.
半径のセキュリティプロパティの強化は、モバイルIPのサポートを提供するRADIUS拡張機能の特定の非ゴールです。また、これは要件文書であり、ソリューション仕様文書ではないため、RADIUSにすでに存在するものを除いて、新しいセキュリティ上の考慮事項は認められません。そのため、以前に説明した既存のRADIUSセキュリティに関する考慮事項が適用され、ここに追加のセキュリティ上の考慮事項は追加されていません。たとえば、半径の仮定は、中間ノードが信頼されているのと同時に、ホップバイホップセキュリティを使用してキーを配布するAAAプロトコルを使用することに懸念があることです。キーディストリビューションのホップバイホップセキュリティの使用は、鍵をそのコンテキストに拘束する要件や、キースコープの制限に関する要件など、[RFC4962]に記載されている要件の一部と矛盾する可能性があります。前者は、たとえば、キーはキーイング素材にアクセスできると予想される当事者に拘束されなければならないと述べていますが、後者は、役割を実行するためにキーにアクセスする必要がない当事者がキーにアクセスしてはならないことを暗示しています。。これらの要件は両方とも、キーの分布を伴う仲介ノードとプロキシを信頼することに対して支配します。半径のエンドツーエンドのセキュリティメカニズムが不足しているため、プロキシを信頼しないために必須の要件を課すことは不可能です。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 Access Acceptメッセージ内の重要な資料など、機密属性のラッピングを指定するための進捗状況もあります。この作業は現在、Radius Crypto-Agility Extensionsの一部と見なされており、RADIUSサーバーのキーイング素材など、敏感な属性を配布するプロセスで完了したときに使用できます。
It is also possible to protect RADIUS transactions using IPsec (e.g., as in RFC3579).
また、IPSECを使用して半径トランザクションを保護することも可能です（たとえば、RFC3579のように）。
The authors would like to thank Alan DeKok for review and feedback, and Pete McCann and Jari Arkko for diligent shepherding of this document.
著者は、レビューとフィードバックについてAlan Dekokと、この文書の勤勉な羊飼いについてPete McCannとJari Arkkoに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867] Zorn、G.、Aboba、B。、およびD. Mitton、「トンネルプロトコルサポートのための半径会計の修正」、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] Glass、S.、Hiller、T.、Jacobs、S.、およびC. Perkins、「モバイルIP認証、認可、および会計要件」、RFC 2977、2000年10月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、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] Perkins、C。およびP. Calhoun、「認証、認可、および会計（AAA）モバイルIPv4の登録キー」、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] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T。、およびP. McCann、「直径モバイルIPv4アプリケーション」、RFC 4004、2005年8月。
[RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[RFC4721] Perkins、C.、Calhoun、P。、およびJ. Bharatia、「Mobile IPv4 Challenge/Response Extensions（改訂）」、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。and 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] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。、およびP. Calhoun、「Radius Extensions」、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.
[RFC3576] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、およびB. Aboba、「リモート認証のダイヤルインユーザーサービス（RADIUS）への動的認証拡張」、RFC 3576、2003年7月。
[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. Calhoun、「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.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、2003年9月。
Authors' Addresses
著者のアドレス
Madjid Nakhjiri (editor) Motorola
Madjid Nakhjiri（編集者）Motorola
EMail: madjid.nakhjiri@motorola.com
Kuntal Chowdhury Starent Networks
Kuntal Chowdhury Starent Networks
EMail: kchowdhury@starentnetworks.com
Avi Lior Bridgewater Systems
Avi Lior Bridgewaterシステム
EMail: avi@bridgewatersystems.com
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
Kent Leung Cisco Systems 170 West Tasman Drive San Jose、CA 95134 US
EMail: kleung@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。