RFC5030 日本語訳

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

ワーキンググループM.Nakhjiri、エドをネットワークでつないでください。コメントのために以下を要求してください。 5030年のモトローラカテゴリ: 情報のK.チョードリStarentはK.レオンシスコシステムズ2007年10月にA.Liorブリッジウォーターシステムをネットワークでつなぎます。

                    Mobile IPv4 RADIUS Requirements

モバイルIPv4半径要件

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をサポートするために中のRemote Authentication Dial User Service(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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 目標と非目標.33.1。 目標. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2。 非目標.4 4。 属性. . . . . . . . . . . . . . . . . . . . . . . . . . 5 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 6 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 7

Nakhjiri, et al.             Informational                      [Page 1]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[1ページ]のRFC5030

1.  Introduction

1. 序論

   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.

アドレス(それぞれHoAとCoA)のモバイルIPエージェント、(ミネソタ)が1組のホームを帯びることができるように必要とするモバイルノード、および注意によるパケットのモバイルIPv4[RFC3344]処理に弾みをつけるために、ミネソタのホームエージェント(HA)として演じられる望んでいるエージェントを見つけてください、そして、HAと共に登録手続を実行してください。 登録手続はミネソタとHAの間の登録要求と登録応答メッセージの交換から成ります。 [RFC3344]の仕様で、ホームアドレスかHAのアドレスを習得する前に、ミネソタは登録手続を始めることができます。 通常、ミネソタのそばでそれらのパラメタを取得するのは、ブートストラップ法と呼ばれたプロセスの一部です。

   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.

登録要求と応答メッセージのうまくいっている処理はうまくいっている作成、特に保全を保護するために発生する多くの認証拡大の検証とこれらのメッセージのセキュリティ、および実体処理にそれらとすなわち、ミネソタとHAと数回Foreignエージェント(FAs)[RFC3344]特によります。 これらの拡大の検証と同様に作成はミネソタと移動性エージェントの各人の間の信頼関係と共有されたキーの存在を必要とします。 しかしながら、移動性セキュリティ協会(MSAs)と通常呼ばれたこれらの信頼関係の作成はモバイルIPv4仕様が[RFC3344]で定義したベースの範囲の外で考えられます。 ミネソタとすべての可能な移動性エージェントとの静的なセキュリティ仲間を創造しながら起こるスケーラビリティ問題を避けるのは望まれています。 したがって、ミネソタと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ワーキンググループはミネソタがホームAAAサーバ[RFC4721]に認証するのを許容するモバイルIPv4拡張子を開発しました。 また、拡大で、ミネソタは移動性エージェントと共に移動性セキュリティ協会の創設[RFC3957]におけるAAAサーバから援助を要請します、ミネソタとそのホーム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インフラストラクチャの利用を実装するのに必要ですが、それらは十分ではありません。 ミネソタと移動性エージェント(HAとFA)との相互作用はモバイルIPシグナリングに基づいています。 しかしながら、AAAサーバへの移動性エージェントを超えたシグナリングはAAAプロトコルに通常基づいています。 時頃の間、RADIUSの後継者を設計することの途中にAAA共同体がありました。その時、前述のモバイルIP拡大の仕様は開発されていました。

Nakhjiri, et al.             Informational                      [Page 2]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[2ページ]のRFC5030

   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グループは特にそのような後継者(Diameterであると判明した)のためにモバイルIP見地[RFC2977]からのマニュアルと要件を発展させました。 これらの要件は[RFC4004]を独力で進みながらモバイルIPv4でDiameterを使用するための仕様の開発につながりました。 モバイルIPのAuthentication、Authorization、およびAccounting[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属性、異なったワイヤレスSDOsは取りました。モバイルIPv4サポートを提供するのに展開しているVendor Specific Attributes(VSAs)の経路で取ります。 異なったベンダー特定のRADIUS属性と手順のモバイルIPv4が異なったSDOsを独力で進む同じ目的の使用がこれらのワイヤレスの規格の間の不足相互運用性を引き起こすと考えられます、これらのワイヤレス・ネットワークの向こう側に潜在的に移動性を妨げて。

   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].

説明された問題に応じるために、モバイルIPv4 Registration手順の間、RADIUSのベースのAAAインフラストラクチャとの一貫して共同利用できる相互作用を許容するためにIETFの中で1セットのRADIUS属性を標準化するのは必要です。 ブートストラップ法属性は[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のための1セットの目標と非目標を定義することです。

2.  Terminology

2. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

3.  Goals and Non-Goals

3. 目標と非目標

   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.

以来、モバイルIPv4がRADIUSインフラストラクチャとの相互作用であるとサポートするRADIUS拡張子のための要件仕様、目標、および非目標がモバイルIPv4をサポートするのに必要であるそれらのRADIUS拡張子だけを示すとき、このドキュメントは役立ちます。

Nakhjiri, et al.             Informational                      [Page 3]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[3ページ]のRFC5030

3.1.  Goals

3.1. 目標

   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)とForeignエージェント(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 RADIUSサーバは[RFC4721]で指定された認証拡大の検証をモバイルIPv4サポートのために定義されて、実行するために属性を理解して、処理できるREQUIREDです。 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 すべてのRADIUS仕事は後方の既存のRADIUS RFCsとのコンパチブル、そして、含んでいるRFCsが以下であったならそうしなければなりません: [RFC2865]、[RFC2866]、[RFC2867]、[RFC2868]、[RFC2869]、[RFC3576]、[RFC3579]、および[RFC3580。]

   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)はモバイルIPシグナリングにRADIUSシグナリングを翻訳するときRADIUSクライアント(状況内において[RFC2865]のNASes)として作動するREQUIREDです、逆もまた同様に。 RADIUSクライアントとしてのモバイルIPエージェントの振舞いに関する詳細はモバイルIPサポートのためのRADIUS拡張子について説明するソリューションドキュメントで提供することです。

3.2.  Non-Goals

3.2. 非目標

   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)とForeignエージェント(FA))がモバイルIP登録メッセージ分野を提案されたRADIUS属性に写像する手順を定義することになっています、逆もまた同様に。 既存のプロトコルかRADIUSサーバの機能性の拡大は意図しません。 より明確に、↓これはNON- GOALSです:

   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 Access Requestsの輸送のためにモバイルIPv4ブートストラップ法のサポートと関連して定義されないことです。 既存のRADIUS認証手順(例えば、[RFC2869]で説明されたMessage-固有識別文字(80))は使用されています。 モバイルIPv4を独力で進む際にRADIUSを使用するためのセキュリティ問題はこのドキュメントの後のセクションで説明されます。

Nakhjiri, et al.             Informational                      [Page 4]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[4ページ]のRFC5030

   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 RADIUSを高めて、信頼性を輸送してください: RADIUSの輸送量は元の状態のままになります。 どんな新しい信頼性のメカニズムもそのようなAccess Requestsの輸送で定義されません。

   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メッセージを定義しないことです。 DiameterのモバイルIPアプリケーション[RFC4004]はモバイルIPシグナリングをサポートするために新しいコマンドコードを定義しました、DiameterサーバがモバイルIP HAかFAに対処しているかどうかによって。 RADIUSには、現在、これらのDiameterコマンドに対応するどんなメッセージもありません。 代わりに、モバイルIPv4ブートストラップ法のためのRADIUS拡張子は、どんな新しいRADIUSメッセージングも定義しないでDiameter-RADIUSメッセージング翻訳を容易にする新しいRADIUS属性のための提案を提供する必要があります。 同時に、モバイルIPv4のためのRADIUS拡張子は、Diameter AVPsを可能な最もふくよかな範囲まで再使用する必要があります。

   o  RFC 2977 compatibility: Extending RADIUS in a way that fulfills
      the full list of requirements in [RFC2977] will not be attempted.

o RFC2977の互換性: [RFC2977]に要件に関する完全リストを実現させる方法でRADIUSを広げるのは試みられないでしょう。

4.  Attributes

4. 属性

   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は課題をタイプします。

5.  IANA Considerations

5. 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が新しい属性形式数を割り当てる必要があるでしょう。

6.  Security Considerations

6. セキュリティ問題

   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

セキュリティを高めて、RADIUSの特性はモバイルIPのサポートを提供するRADIUS拡張子の特定の非目標です。 また、これがソリューション仕様ドキュメントではなく、要件ドキュメントであるので、どんな新しいセキュリティ問題も有名ではありません、RADIUSのために既に存在するものは別として。 そういうものとして、以前に説明された既存のRADIUSセキュリティ問題は適用されます、そして、追加担保問題は全くここで加えられません。 例えば、RADIUSの仮定は仲介者ノードが信じられるということです、キーを分配するのにホップごとのセキュリティを使用するAAAプロトコルを使用するとき、同時に、関心がありますが。 ホップごとのセキュリティのキーの使用

Nakhjiri, et al.             Informational                      [Page 5]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[5ページ]のRFC5030

   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.

分配は[RFC4962]に述べられている要件のいくつかとの闘争中であることができます、文脈のキーを縛ることに関する要件や主要な範囲の限界に関する要件のように。 例えば、前者は、合わせることの材料に近づく手段を持っていると予想されるパーティーにキーを縛らなければならないと述べます、後者は、彼らの役割を実行するためにキーへのアクセスを必要としないパーティーがキーに近づく手段を持ってはいけないのを含意しますが。 これらの要件の両方がキーの分配で仲介者ノードを信じて、プロキシに不利な判決を下します。 終わりから終わりへのRADIUS、印象的なaのためのメカニズムがそうしなければならないセキュリティの不足のために、プロキシを信じないための要件は可能ではありません。 RADIUS属性の中で主要資材を包装するための手順を指定することの途中にRADIUS Extensionワーキンググループがあります。 当分の間、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.

Access Requestの属性、[RFC2868]を保護することとなると、セクション3.5はRADIUS属性を暗号化するのにメカニズムを提供します、パスワードなどのように。 敏感な属性のラッピングを指定するための進歩の下に仕事もあります、RADIUS Access Acceptメッセージの中の主要な材料などのように。 現在RADIUS暗号機敏さ拡張子の一部であるとこの仕事を考えます、そして、完成されると、敏感な属性を分配することの途中に使用できます、RADIUSサーバから材料を合わせるのなどように。

   It is also possible to protect RADIUS transactions using IPsec (e.g.,
   as in RFC3579).

また、IPsecを使用するRADIUSトランザクションを保護するのも可能です(例えば、RFC3579のように)。

7.  Acknowledgements

7. 承認

   The authors would like to thank Alan DeKok for review and feedback,
   and Pete McCann and Jari Arkko for diligent shepherding of this
   document.

作者はこのドキュメントを勤勉な見張るためにレビュー、フィードバック、ピートマッキャン、およびヤリArkkoについてアランDeKokに感謝したがっています。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2866] Rigney、C.、「半径会計」、RFC2866、2000年6月。

Nakhjiri, et al.             Informational                      [Page 6]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[6ページ]のRFC5030

   [RFC2867]  Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
              Modifications for Tunnel Protocol Support", RFC 2867,
              June 2000.

[RFC2867] ゾルン、G.、Aboba、B.、およびD.ミットン、「トンネルプロトコルサポートのための半径会計変更」、RFC2867、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認証、承認、および会計要件」、RFC2977(2000年10月)。

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」

   [RFC3957]  Perkins, C. and P. Calhoun, "Authentication,
              Authorization, and Accounting (AAA) Registration Keys for
              Mobile IPv4", RFC 3957, March 2005.

[RFC3957] パーキンスとC.とP.カルフーン、「モバイルIPv4"、RFC3957、2005年3月のための認証、承認、および会計(AAA)登録キー。」

   [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アプリケーション」、RFC4004、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挑戦/応答拡大(改訂される)」、RFC4721、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)Key Managementのための指導」BCP132、RFC4962(2007年7月)。

8.2.  Informative References

8.2. 有益な参照

   [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.とライファーとD.とルーベンとA.とシュライバーとJ.とHoldrege、M.とI.Goyret、「トンネルプロトコルサポートのための半径属性」RFC2868(2000年6月)。

   [RFC2869]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS
              Extensions", RFC 2869, June 2000.

[RFC2869] RigneyとC.とWillats、W.とP.カルフーン、「半径拡大」、RFC2869、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] 千葉、M.、Dommety、G.、エクルンド、M.、ミットン、D.、およびB.Aboba、「リモート認証へのダイナミックな承認拡大はユーザでサービス(半径)にダイヤルします」、RFC3576、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.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(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] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(2003年9月)。

Nakhjiri, et al.             Informational                      [Page 7]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[7ページ]のRFC5030

Authors' Addresses

作者のアドレス

   Madjid Nakhjiri (editor)
   Motorola

Madjid Nakhjiri(エディタ)モトローラ

   EMail: madjid.nakhjiri@motorola.com

メール: madjid.nakhjiri@motorola.com

   Kuntal Chowdhury
   Starent Networks

KuntalチョードリStarentネットワーク

   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の西タスマン・Driveケントカリフォルニア95134サンノゼ(米国)

   EMail: kleung@cisco.com

メール: kleung@cisco.com

Nakhjiri, et al.             Informational                      [Page 8]

RFC 5030            Mobile IPv4 RADIUS Requirements         October 2007

Nakhjiri、他 IPv4半径要件2007年10月のモバイルの情報[8ページ]のRFC5030

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Nakhjiri, et al.             Informational                      [Page 9]

Nakhjiri、他 情報[9ページ]