RFC2906 日本語訳
2906 AAA Authorization Requirements. S. Farrell, J. Vollbrecht, P.Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege,D. Spence. August 2000. (Format: TXT=48618 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Farrell
Request for Comments: 2906 Baltimore Technologies
Category: Informational J. Vollbrecht
Interlink Networks, Inc.
P. Calhoun
Sun Microsystems, Inc.
L. Gommans
Enterasys Networks EMEA
G. Gross
Lucent Technologies
B. de Bruijn
Interpay Nederland B.V.
C. de Laat
Utrecht University
M. Holdrege
ipVerse
D. Spence
Interlink Networks, Inc.
August 2000
コメントを求めるワーキンググループS.ファレル要求をネットワークでつないでください: 2906年のボルチモア技術カテゴリ: 情報のJ.のHoldrege ipVerse D.スペンスInterlink Networks Inc.Vollbrecht Interlink Networks Inc.P.カルフーンサン・マイクロシステムズ・インクL.Gommans Enterasys Networks EMEA G.GrossルーセントテクノロジーズB.de Bruijn InterpayネーデルラントB.V.C.de Laatユトレヒト大学M.2000年8月
AAA Authorization Requirements
AAA承認要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. The requirements have been elicited from a study of a range of applications including mobile-IP, roamops and others.
このドキュメントはAuthentication Authorization Accounting(AAA)プロトコルにインターネットで承認サービスをサポートするために満たされなければならないという要件を指定します。 要件はモバイルIP、roamops、および他のものを含むさまざまなアプリケーションの研究から引き出されました。
Farrell, et al. Informational [Page 1] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [1ページ]情報のRFC2906AAA承認要件2000年8月
Table Of Contents
目次
1. Introduction.................................................2
2. Requirements.................................................3
2.1 Authorization Information..............................3
2.2 Security of authorization information..................7
2.3 Time...................................................9
2.4 Topology..............................................10
2.5 Application Proxying..................................12
2.6 Trust Model...........................................12
2.7 Not just transactions.................................14
2.8 Administration........................................15
2.9 Bytes on-the-wire.....................................16
2.10 Interfaces............................................17
2.11 Negotiation...........................................18
3. Security Considerations.....................................19
4. References..................................................20
Authors' Addresses.............................................20
Full Copyright Statement.......................................23
1. 序論…2 2. 要件…3 2.1 承認情報…3 2.2 承認情報のセキュリティ…7 2.3時間…9 2.4トポロジー…10 2.5 アプリケーションProxying…12 2.6 モデルを信じてください…12 トランザクションだけではなく、2.7…14 2.8政権…15 2.9 バイト、ワイヤ…16 2.10 連結します…17 2.11交渉…18 3. セキュリティ問題…19 4. 参照…20人の作者のアドレス…20 完全な著作権宣言文…23
1. Introduction
1. 序論
This document is one of a series of three documents under consideration by the AAAarch RG dealing with the authorization requirements for AAA protocols. The three documents are:
このドキュメントはAAAプロトコルのための承認要件に対処するAAAarch RGによる考慮での一連の3通のドキュメントの1つです。 3通のドキュメントは以下の通りです。
AAA Authorization Framework [FRMW]
AAA Authorization Requirements (this document)
AAA Authorization Application Examples [SAMP]
AAA Authorization Framework[FRMW]AAA Authorization Requirements(このドキュメント)AAA Authorization Application Examples[挽き割りトウモロコシ]
The work for this memo was done by a group that originally was the Authorization subgroup of the AAA Working Group of the IETF. When the charter of the AAA working group was changed to focus on MobileIP and NAS requirements, the AAAarch Research Group was chartered within the IRTF to continue and expand the architectural work started by the Authorization subgroup. This memo is one of four which were created by the subgroup. This memo is a starting point for further work within the AAAarch Research Group. It is still a work in progress and is published so that the work will be available for the AAAarch subgroup and others working in this area, not as a definitive description of architecture or requirements.
このメモのための仕事が元々IETFのAAA作業部会のAuthorizationサブグループであったグループによって行われました。 MobileIPとNAS要件に焦点を合わせるためにAAAワーキンググループの特許を変えたとき、Authorizationサブグループによって始められた建築仕事を続けて、広げるためにIRTFの中でAAAarch Research Groupをチャーターしました。 このメモはサブグループによって作成された4の1つです。 このメモはAAAarch Research Groupの中のさらなる仕事のための出発点です。 それは、仕事がアーキテクチャか要件の決定的な記述ではなく、この領域で働いているAAAarchサブグループと他のものに利用可能になるように、それでも、処理中の作業であり、発行されます。
The process followed in producing this document was to analyze the requirements from [SAMP] based on a common understanding of the AAA authorization framework [FRMW]. This document assumes familiarity with both the general issues involved in authorization and, in particular, the reader will benefit from a reading of [FRMW] where, for example, definitions of terms can be found.
このドキュメントを製作する際に続くプロセスはAAA承認フレームワーク[FRMW]の一般的な理解に基づく[SAMP]からの要件を分析することになっていました。 このドキュメントは承認にかかわる両方の一般答弁への親しみを仮定します、そして、特に、読者は例えば用語の定義を見つけることができる[FRMW]の読みの利益を得るでしょう。
Farrell, et al. Informational [Page 2] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [2ページ]情報のRFC2906AAA承認要件2000年8月
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
「必要で」、“SHOULD"の、そして、「お勧め」のキーワード“MUST"、およびこのドキュメントの「5月」は[RFC2119]で説明されるように解釈されることになっています。
2. Requirements
2. 要件
Requirements are grouped under headings for convenience; this grouping is not significant.
要件は便宜のための見出しの下で分類されます。 この組分けは重要ではありません。
Definitions and explanations of some of the technical terms used in this document may be found in [FRMW].
定義と本書では使用されるいくつかの専門用語に関する説明は[FRMW]で見つけられるかもしれません。
Each requirement is presented as a succinct (usually a sentence or two) statement. Most are followed by a paragraph of explanatory material, which sometimes contains an example. Fully described examples may be found in [SAMP].
各要件は簡潔な(通常1か2つの文)声明として提示されます。 説明資料のパラグラフは大部分あとに続いています。(説明資料は時々例を含みます)。 完全に説明された例は[SAMP]で見つけられるかもしれません。
The requirements presented are not intended to be "orthogonal", that is, some of them repeat, or overlap, with others.
提示された要件を「直交させていること」を意図しないで、すなわち、それらのいくつかが、他のものに繰り返すか、または重なります。
2.1 Authorization Information
2.1 承認情報
2.1.1 Authorization decisions MUST be able to be based on information about the requestor, the service/method requested, and the operating environment (authorization information). AAA protocols are required to transport this information.
2.1.1 承認決定は要請者の情報、要求されたサービス/メソッド、および操作環境(承認情報)に基づかせることができなければなりません。 AAAプロトコルが、この情報を輸送するのに必要です。
This simply states the requirement for a protocol and an access decision function, which takes inputs, based on the requestor, the resource requested and the environment.
これは単にリソースが要請者に基づいて要求した入力を取るプロトコルとアクセス決定関数のための要件と環境を述べます。
2.1.2 It MUST be possible to represent authorization information as sets of attributes. It MAY be possible to represent authorization information as objects.
2.1.2 属性のセットとして承認情報を表すのは可能であるに違いありません。 オブジェクトとして承認情報を表すのは可能であるかもしれません。
This states that authorization information must be decomposable into sets of attributes. It is not intended to imply any particular mechanism for representing attributes.
これは、承認情報が属性のセットに分解可能であるに違いないと述べます。 それが属性を表すためにどんな特定のメカニズムも含意することを意図しません。
2.1.3 It MUST be possible to package authorization information so that the authorization information for multiple services or applications can be carried in a single message in a AAA or application protocol.
2.1.3 承認情報をパッケージするのは、AAAかアプリケーション・プロトコルのただ一つのメッセージで複数のサービスかアプリケーションのための承認情報を運ぶことができるくらい可能でなければなりません。
This states that a protocol, which always required separate AAA messages/transactions for each service/application, would not meet the requirement. For example, it should be possible for a single AAA message/transaction to be sufficient to allow both network and application access.
これは、プロトコル(各サービス/アプリケーションのためにいつも別々のAAAメッセージ/トランザクションを必要とした)が条件を満たさないと述べます。 例えば、ただ一つのAAAメッセージ/トランザクションがネットワークとアプリケーションの両方にアクセサリーを許容できるくらい可能であるべきです。
Farrell, et al. Informational [Page 3] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [3ページ]情報のRFC2906AAA承認要件2000年8月
2.1.4 Standard attributes types SHOULD be defined which are relevant to many Internet applications/services (e.g. identity information, group information, ...)
2.1.4 標準の属性がSHOULDをタイプする、定義されて、どれが多くのインターネットアプリケーション/サービスに関連しているか。(例えば、アイデンティティ情報、グループ情報)
There are many attributes that are used in lots of contexts, and these should only be defined once, in order to promote interoperability and prevent duplication of effort.
多くの文脈で使用される多くの属性があります、そして、これらは一度定義されるだけであるべきです、相互運用性を促進して、取り組みの複製を防ぐために。
2.1.5 Authorization decisions MUST NOT be limited to being based on identity information, i.e. AAA protocols MUST support the use of non-identifying information, e.g. to support role based access control (RBAC).
2.1.5 承認決定をアイデンティティ情報に基づくのに制限してはいけません、すなわち、AAAプロトコルは例えば、サポートの役割への非身元が分かる情報の使用にベースのアクセスコントロール(RBAC)をサポートしなければなりません。
Authorization based on clearances, roles, groups or other information is required to be supported. A AAA protocol that only carried identity information would not meet the requirement.
クリアランス、役割、グループまたは他の情報に基づいた承認が、サポートされるのに必要です。 アイデンティティ情報を運んだだけであるAAAプロトコルは条件を満たさないでしょう。
2.1.6 Authorization data MAY include limits in addition to attributes which are directly "owned" by end entities.
2.1.6 承認データは終わりの実体によって直接「所有されている」属性に加えて限界を含むかもしれません。
This states that some attributes do not simply represent attributes of an entity, for example a spending limit of IR 1,000 is not an intrinsic attribute of an entity. This also impacts on the access decision function, in that the comparison to be made is not a simple equality match.
これは、いくつかの属性が実体の属性を絶対に表さないと述べます、例えば、IR1,000の支出限界は実体の本質的な属性ではありません。 また、これにアクセス決定関数で影響を与えます、される比較が簡単な平等マッチでないので。
2.1.7 It MUST be possible for other (non-AAA) protocols to define their own attribute types, which can then be carried within an authorization package in a AAA or application protocol.
2.1.7 他の(非AAA)プロトコルがそれら自身の属性タイプを定義するのは、可能であるに違いありません。(次に、承認パッケージの中にAAAかアプリケーション・プロトコルでその属性タイプを運ぶことができます)。
This states that the attributes that are significant in an authorization decision, may be application protocol dependent. For example, many attribute types are defined by [RFC2138] and support for the semantics of these attributes will be required. Of course, only AAA entities that are aware of the added attribute types can make use of them.
これは、承認決定で重要な属性がアプリケーションプロトコル扶養家族であるかもしれないと述べます。 例えば、多くの属性タイプが[RFC2138]が定義されます、そして、これらの属性の意味論のサポートが必要でしょう。 もちろん、加えられた属性タイプを意識しているAAA実体だけが彼らを利用できます。
2.1.8 It SHOULD be possible for administrators of deployed systems to define their own attribute types, which can then be carried within an authorization package in a AAA or application protocol.
2.1.8 それ、SHOULD、配布しているシステムの管理者がそれら自身の属性タイプを定義するのにおいて可能であってください。(次に、承認パッケージの中にAAAかアプリケーション・プロトコルでその属性タイプを運ぶことができます)。
This states that the attributes that are significant in an authorization decision, may be dependent on a closed environment. For example, many organizations have a well-defined scheme of seniority, which can be used to determine access levels. Of course, only AAA entities that are aware of the added attribute types can make use of them.
これは、承認決定で重要な属性に閉じている環境に依存しているかもしれないと述べます。 例えば、多くの組織には、年上明確な体系があります。(アクセスレベルを決定するのに年上を使用できます)。 もちろん、加えられた属性タイプを意識しているAAA実体だけが彼らを利用できます。
Farrell, et al. Informational [Page 4] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [4ページ]情報のRFC2906AAA承認要件2000年8月
2.1.9 It SHOULD be possible to define new attribute types without central administration and control of attribute name space.
2.1.9 それ、SHOULD、属性名前スペースの中央の管理とコントロールなしで新しい属性タイプを定義するのにおいて、可能であってください。
A centralized or distributed registration scheme of some sort is needed if collisions in attribute type allocations are to be avoided. However a AAA protocol which always requires use of such a centralized registration would not meet the requirement. Of course, collisions should be avoided where possible.
ある種の集結されたか分配された登録体系が属性タイプ配分における衝突が避けられることであるなら必要です。 しかしながら、いつもそのような集結された登録の使用を必要とするAAAプロトコルは条件を満たさないでしょう。 もちろん、衝突は可能であるところで避けられるべきです。
2.1.10 It MUST be possible to define attribute types so that an instance of an attribute in a single AAA message can have multiple values.
2.1.10 属性タイプを定義するのは、ただ一つのAAAメッセージの属性のインスタンスが複数の値を持つことができるくらい可能でなければなりません。
This states that a protocol which does not allow multiple instances of an attribute in a message/transaction would not meet the requirement. For example it should be possible to have a "group" attribute which contains more than one groupname (or number or whatever).
これは、メッセージ/トランザクションにおける属性の複数のインスタンスを許容しないプロトコルが条件を満たさないと述べます。 例えば、1groupname(または、数か何でも)を含む「グループ」属性を持っているのは可能であるべきです。
2.1.11 If MUST be possible to distinguish different instances of the same authorization attribute type or value, on the basis of "security domain" or "authority".
2.1.11、同じ承認属性タイプか価値の異なったインスタンスを区別するのにおいて可能であってください、「セキュリティー領域」か「権威」に基づいてそうしなければなりません。
This recognizes that it is important to be able to distinguish between attributes based not only on their value. For example, all NT domains (which use the English language) have an Administrators group, an access decision function has to be able to determine to which of these groups the requestor belongs.
これは、それらの値だけに基づく属性は見分けることができるのが重要であると認めます。 例えば、すべてのNTドメイン(英語を使用する)には、Administratorsグループ(決定関数が要請者がこれらのグループのどれに属するかを決定できるように持っているアクセス)があります。
2.1.12 AAA protocols MUST specify mechanisms for updating the rules which will be used to control authorization decisions.
2.1.12 AAAプロトコルは承認決定を制御するのに使用される規則をアップデートするのにメカニズムを指定しなければなりません。
This states that a AAA protocol that cannot provide a mechanism for distributing authorization rules is not sufficient. For example, this could be used to download ACLs to a PDP.
これは、承認規則を分配するのにメカニズムを提供できないAAAプロトコルが十分でないと述べます。 例えば、ACLsをPDPにダウンロードするのにこれを使用できました。
Note that this is not meant to mean that this AAA protocol mechanism must always be used, simply that it must be available for use. In particular, storing authorization rules in a trusted repository (in many cases an LDAP server) will in many cases be used instead of such a AAA protocol mechanism. Neither does this requirement call for a standardized format for authorization rules, merely that there be a mechanism for transporting these.
これがいつもこのAAAプロトコルメカニズムを使用しなければならなくて、単に、それが使用に利用可能でなければならないことを意味することになっていないことに注意してください。 多くの場合、特に、信じられた倉庫(多くの場合LDAPサーバ)に承認規則を保存するのはそのようなAAAプロトコルメカニズムの代わりに使用されるでしょう。 どちらも、要件が承認のための標準化された形式が単に統治するaのためにそこにそれと呼ぶこれは、これらを輸送するためのメカニズムではありません。
Farrell, et al. Informational [Page 5] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [5ページ]情報のRFC2906AAA承認要件2000年8月
2.1.13 The AAA protocol MUST allow for chains of AAA entities to be involved in an authorization decision.
2.1.13 AAAプロトコルは、AAA実体のチェーンが承認決定にかかわるのを許容しなければなりません。
This states that more than one AAA server may have to be involved in a single authorization decision. This may occur either due to a decision being spread across more than one "domain" or in order to distribute authorization within a single "domain".
これは、1つ以上のAAAサーバがただ一つの承認決定にかかわらなければならないかもしれないと述べます。 これは1「ドメイン」の向こう側に広げられるか、または単一の「ドメイン」の中で承認を分配するためにある決定のため起こるかもしれません。
2.1.14 The AAA protocol MUST allow for intermediate AAA entities to add their own local authorization information to a AAA request or response.
2.1.14 AAAプロトコルは、中間的AAA実体が地元の承認情報をAAA要求か応答に追加するのを許容しなければなりません。
This states that where more than one AAA entity is involved in an authorization decision each of the AAA entities may manipulate the AAA messages involved either by adding more information or by processing parts of the information.
これは、1つ以上のAAA実体がそれぞれAAA実体の承認決定にかかわるところでそれが詳しい情報を加えるか、情報の処理部分でかかわるAAAメッセージを操るかもしれないと述べます。
2.1.15 AAA entities MAY be either be deployed independently or integrated with application entities.
2.1.15 AAA実体は、独自に配布されるか、またはアプリケーション実体と統合されるかもしれません。
This states that the AAA entities may either be implemented as AAA servers or integrated with application entities.
これは、AAA実体がAAAサーバとして実装されるか、またはアプリケーション実体と統合されるかもしれないと述べます。
2.1.16 The AAA protocol MUST support the creation and encoding of rules that are to be active inside one AAA server based on attributes published by another AAA server. The level of authorization of the requesting AAA Server MAY govern the view on attributes.
2.1.16 AAAプロトコルは別のAAAサーバによって発行された属性に基づく1つのAAAサーバでアクティブであることになっている規則の作成とコード化をサポートしなければなりません。要求AAA Serverの承認のレベルは属性に関する意見を支配するかもしれません。
This states that one AAA entity may have to distribute authorization rules to another, and that the AAA entity that receives the rules may only be seeing part of the story.
これは、1つのAAA実体が別のものに承認規則を分配しなければならないかもしれなくて、規則を受け取るAAA実体が話の一部が見えているだけであるかもしれないと述べます。
2.1.17 AAA protocols MAY have to support the idea of critical and non- critical attribute types.
2.1.17 AAAプロトコルは重要で非重要な属性タイプの考えをサポートしなければならないかもしれません。
This is analogous to the use of the criticality flag in public key certificate extensions.
これは公開鍵証明書拡張子における臨界旗の使用に類似しています。
2.1.18 A AAA protocol MUST allow authorization rules to be expressed in terms of combinations of other authorization rules which have been evaluated.
2.1.18 AAAプロトコルは、承認規則が評価された他の承認規則の組み合わせで表されるのを許容しなければなりません。
For example, access may only be granted if the requestor is member of the backup users group and not a member of the administrator's group. Note that this requirement does not state which types of combinations are to be supported.
例えば、アクセスは要請者がアドミニストレータのグループのメンバーではなく、バックアップユーザグループのメンバーである場合にだけ承諾されるかもしれません。 この要件が、どのタイプの組み合わせがサポートされるかことであるかと述べないことに注意してください。
Farrell, et al. Informational [Page 6] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [6ページ]情報のRFC2906AAA承認要件2000年8月
2.1.19 It SHOULD be possible to make authorization decisions based on the geographic location of a requestor, service or AAA entity.
2.1.19 それは要請者、サービスまたはAAA実体の地理的な位置を造の承認決定に基礎づけましたSHOULDが可能である。
This is just an example of an authorization attribute type, notable because it requires different underlying implementation mechanisms.
これはただ異なった基本的な実装メカニズムを必要とするので注目に値する承認属性タイプの例です。
2.1.20 It SHOULD be possible to make authorization decisions based on the identity or the equipment used by a requestor, service or AAA entity.
2.1.20 アイデンティティを造の承認決定に基礎づけたか、SHOULDが可能であるまたは設備は要請者、サービスまたはAAA実体を利用しました。
This is just an example of an authorization attribute type, notable because it may require different underlying implementation mechanisms (if IPSec isn't available).
これはただ承認属性タイプの例です、異なった基本的な実装メカニズムを必要とするかもしれないので(IPSecが利用可能でないなら)、注目に値します。
2.1.21 When there are multiple instances of a given attribute, there must be an unambiguous mechanism by which a receiving peer can determine the value of specified instance.
2.1.21 与えられた属性の複数のインスタンスがあるとき、受信同輩が指定されたインスタンスの値を決定できる明白なメカニズムがあるに違いありません。
2.2 Security of authorization information
2.2 承認情報のセキュリティ
2.2.1 It MUST be possible for authorization information to be communicated securely in AAA and application protocols. Mechanisms that preserve authenticity, integrity and privacy for this information MUST be specified.
2.2.1 AAAでしっかりとコミュニケートするべき承認情報とアプリケーション・プロトコルに、それは可能であるに違いありません。 この情報のために信憑性、保全、およびプライバシーを保持するメカニズムを指定しなければなりません。
This states that there must be a well-defined method for securing authorization information, not that such methods must always be used. Whether support for these mechanisms is to be required for conformance is left open. In particular, mechanisms must be provided so that a service administrator in the middle of a chain cannot read or change authorization information being sent between other AAA entities.
これは、承認情報を保証するための明確なメソッドがあるに違いないと述べて、いつもそのようなメソッドを使用しなければならないというわけではありません。 これらのメカニズムのサポートが順応に必要であるかどうかことであることは開くままにされます。 特に、チェーンの中央のサービス管理者が他のAAA実体の間に送られる承認情報を読むことができませんし、変えることができないように、メカニズムを提供しなければなりません。
2.2.2 AAA protocols MUST allow for use of an appropriate level of security for authorization information. AAA protocols MUST be able to support both highly secure and less secure mechanisms for data integrity/confidentiality etc.
2.2.2 AAAプロトコルは適正水準のセキュリティの承認情報の使用を考慮しなければなりません。 AAAプロトコルは、秘密性データ保全/などのために両方が非常に安全でそれほど安全でないメカニズムであるとサポートすることができなければなりません。
It is important that AAA protocols do not mandate too heavy a security overhead, thus the security mechanisms specified don't always need to be used (though not using them may affect the authorization decision).
AAAプロトコルが重過ぎるセキュリティオーバーヘッドを強制しないのが、重要である、その結果、メカニズムが指定したセキュリティはいつも使用される必要があるというわけではありません(もっとも、それらを使用しないと、承認決定は影響されるかもしれません、)。
2.2.3 The security requirements MAY differ between different parts of a package of authorization information.
2.2.3 セキュリティ要件は承認情報のパッケージの異なった部分の間で異なるかもしれません。
Some parts may require confidentiality and integrity, some may only require integrity. This effectively states that we require something
いくつかの部品が秘密性と保全を必要とするかもしれなくて、或るものは保全を必要とするだけであるかもしれません。 事実上、これは、私たちが何かを必要とすると述べます。
Farrell, et al. Informational [Page 7] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [7ページ]情報のRFC2906AAA承認要件2000年8月
like selective field security mechanisms. For example, information required to gain access to a network may have to be in clear, whilst information required for access to an application within that network may have to be encrypted in the AAA protocol.
選択している分野セキュリティー対策例えばあるネットワークへのアクセスが持っているかもしれない利得に必要である情報のように、クリアしてください、アプリケーションへのアクセスにそのネットワークの中で必要であった情報はAAAプロトコルで暗号化されなければならないかもしれませんが。
2.2.4 AAA protocols MUST provide mechanisms that prevent intermediate administrators breaching security.
2.2.4 AAAプロトコルは中間的管理者がセキュリティを破ることができないメカニズムを提供しなければなりません。
This is a basic requirement to prevent man-in-the-middle attacks, for example where an intermediate administrator changes AAA messages on the fly.
これは介入者攻撃を防ぐという基本的な要件です、例えば、中間的管理者が急いでAAAメッセージを変えるところで。
2.2.5 AAA protocols MUST NOT open up replay attacks based on replay of the authorization information.
2.2.5 AAAプロトコルは承認情報の再生に基づく反射攻撃を開けてはいけません。
For example, a AAA protocol should not allow flooding attacks where the attacker replays AAA messages that require the recipient to use a lot of CPU or communications before the replay is detected.
例えば、AAAプロトコルで、再生が検出される前に攻撃者が受取人が多くのCPUを使用するのを必要とするAAAメッセージかコミュニケーションを再演するところに攻撃をあふれさせるべきではありません。
2.2.6 AAA protocols MUST be capable of leveraging any underlying peer entity authentication mechanisms that may have been applied - this MAY provide additional assurance that the owner of the authorization information is the same as the authenticated entity. For example, if IPSec provides sufficient authentication, then it must be possible to omit AAA protocol authentication.
2.2.6 AAAプロトコルは、どんな基本的な同輩実体も適用されたかもしれない認証機構であると利用することができなければなりません--これは承認情報の所有者が認証された実体と同じであるという追加保証を提供するかもしれません。 例えば、IPSecが十分な認証を提供するなら、AAAプロトコル認証を省略するのは可能であるに違いありません。
2.2.7 End-to-end confidentiality, integrity, peer-entity- authentication, or non-repudiation MAY be required for packages of authorization information.
2.2.7 終わりから終わりへの秘密性、保全、同輩実体認証、または非拒否が承認情報のパッケージに必要であるかもしれません。
This states that confidentiality, (resp. the other security services), may have to be provided for parts of a AAA message, even where it is transmitted via other AAA entities. It does allow that such a AAA message may also contain non-confidential, resp. the other security services), parts. In addition, intermediate AAA entities may themselves be considered end-points for end-to-end security services applied to other parts of the AAA message.
これは、秘密性(resp他のセキュリティー・サービス)がAAAメッセージの部分に提供されなければならないかもしれないと述べます、それが他のAAA実体で伝えられさえするところで。 それが非秘密の状態でまたAAAメッセージが含むかもしれないそのそのようなものを許容して、respもう片方がセキュリティー・サービスである、)、部品。 さらに、中間的AAA実体がそうするかもしれない、自分たち、終わりから終わりへのAAAメッセージの他の部分に適用されたセキュリティー・サービスのためのエンドポイントであると考えられてください。
2.2.8 AAA protocols MUST be usable even in environments where no peer entity authentication is required (e.g. a network address on a secure LAN may be enough to decide).
2.2.8 AAAプロトコルは同輩実体認証が全く必要でない(例えば、安全なLANに関するネットワーク・アドレスが決めることができるかもしれないくらいの)ところで環境でさえ使用可能であるに違いありません。
This requirement (in a sense the opposite of 2.2.6), indicates the level of flexibility that is required in order to make the AAA protocol useful across a broad range of applications/services.
この要件、(ある意味で正反対、2.2 .6) AAAプロトコルを広範囲なアプリケーション/サービスの向こう側に役に立つようにするのに必要である柔軟性のレベルを示します。
Farrell, et al. Informational [Page 8] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [8ページ]情報のRFC2906AAA承認要件2000年8月
2.2.9 AAA protocols MUST specify "secure" defaults for all protocol options. Implementations of AAA entities MUST use these "secure" defaults unless otherwise configured/administered.
2.2.9 AAAプロトコルはすべてのプロトコルオプションのための「安全な」デフォルトを指定しなければなりません。 別の方法で構成されるか、または管理されない場合、AAA実体の実装はこれらの「安全な」デフォルトを使用しなければなりません。
This states that the out-of-the-box configuration must be "secure", for example, authorization decisions should result in denial of access until a AAA entity is configured. Note that the interpretation of "secure" will vary on a case-by-case basis, though the principle remains the same.
これは、独創的な構成が「安全でなければならない」と述べます、例えば、AAA実体が構成されるまで、承認決定はアクセスの否定をもたらすべきです。 原則は同じままで残っていますが、「安全」の解釈がケースバイケースで異なることに注意してください。
2.3 Time
2.3時間
2.3.1 Authorization information MUST be timely, which means that it MUST expire and in some cases MAY be revoked before expiry.
2.3.1 承認情報はタイムリーであるに違いありません(それが期限が切れなければならなくて、いくつかの場合、満期の前に取り消されるかもしれないことを意味します)。
This states that authorization information itself is never to be considered valid for all time, every piece of authorization information must have associated either an explicit or implicit validity period or time-to-live.
これは、承認情報自体が時間中に有効であることは決して考えられないことであると述べて、あらゆる承認情報は明白であるか暗黙の有効期間か生きる時間のどちらかを関連づけたに違いありません。
2.3.2 AAA protocols MUST provide mechanisms for revoking authorization information, in particular privileges.
2.3.2 AAAプロトコルは特定の特権で承認情報を取り消すのにメカニズムを提供しなければなりません。
Where the validity or time-to-live is long, it may be necessary to revoke the authorization information, e.g. where someone leaves a company. Note that this requirement does not mandate a particular scheme for revocation, so that it is not a requirement for blacklists or CRLs.
正当性か生きる時間が長いところでは、承認情報を取り消すのが必要であるかもしれません、例えば、だれかが退職するところで。 この要件が取消しの特定の体系を強制しないことに注意してください、それがブラックリストかCRLsのための要件でないように。
2.3.3 A set of attributes MAY have an associated validity period - such that that the set MUST only be used for authorization decisions during that period. The validity period may be relatively long, (e.g. months) or short (hours, minutes).
2.3.3 1セットの属性は関連有効期間を過すかもしれません--承認決定にその期間セットを使用するだけでよいくらいのそれ。 有効期間は、比較的長いか、(例えば、何カ月も)または短いかもしれません(時間、分)。
This states that explicit validity periods are, in some cases, needed at the field level.
これは、いくつかの場合、明白な有効期間が分野レベルで必要であると述べます。
2.3.4 Authorization decisions MAY be time sensitive. Support for e.g. "working hours" or equivalent MUST be possible.
2.3.4 承認決定は時間敏感であるかもしれません。 例えば、「労働時間」か同等物のサポートは可能であるに違いありません。
This states that the AAA protocol must be able to support the transmission of time control attributes, although it does not mandate that AAA protocols must include a standard way of expressing the "working hours" type constraint.
これは、AAAプロトコルがタイムコントロール属性の送信をサポートすることができなければならないと述べます、AAAプロトコルが「労働時間」タイプ規制を言い表す標準の方法を含まなければならないのを強制しませんが。
Farrell, et al. Informational [Page 9] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [9ページ]情報のRFC2906AAA承認要件2000年8月
2.3.5 It MUST be possible to support authorization decisions that produce time dependent results.
2.3.5 その生産物時間の承認決定に依存する結果をサポートするのは可能であるに違いありません。
For example, an authorization result may be that service should be provided for a certain period. In such cases a AAA protocol must be able to transport this information, possibly as a specific result of the authorization decision, or, as an additional "termination of service" AAA message transmitted later.
例えば、承認結果はある期間にサービスを提供するべきであるということであるかもしれません。 または、「サービスの終了」追加AAAメッセージが後で送られたようにそのような場合AAAプロトコルはことによると承認決定の特定の結果としてこの情報を輸送できなければなりません。
2.3.6 It MUST be possible to support models where the authorization information is issued in well in advance of an authorization decision rather than near the time of the authorization decision.
2.3.6 承認情報が承認決定の時間というよりむしろ承認決定の前に井戸で発行されるモデルをサポートするのは可能であるに違いありません。
This is required in order to support pre-paid (as opposed to subscription) scenarios (e.g. for VoIP).
これが、あらかじめ支払われた(購読と対照的に)シナリオ(例えば、VoIPのための)をサポートするのに必要です。
2.3.7 It SHOULD be possible to support models where the authorization decision is made in advance of a service request.
2.3.7 それは承認決定がサービスのリクエストの前にされるところでサポートにモデル化されますSHOULDが可能である。
This is for some applications such as backup, where actions are scheduled for future dates. It also covers applications that require reservation of resources.
これはバックアップなどのいくつかのアプリケーションのためのものです。(そこでは、動作が将来の期日に予定されています)。 また、それはリソースの予約を必要とするアプリケーションをカバーしています。
2.3.8 A AAA mechanism must allow time stamp information to be carried along with authorization information (e.g. for non-repudiation).
2.3.8 AAAメカニズムは、タイムスタンプ情報が承認情報(例えば、非拒否のための)と共に運ばれるのを許容しなければなりません。
The PKIX WG is developing a time stamp protocol, which can be used as part of a non-repudiation solution. In some environments it may be necessary that certain AAA protocol messages are timestamped (by a trusted authority) and that the timestamps are forwarded within subsequent AAA messages.
PKIX WGはタイムスタンププロトコルを開発しています。(非拒否対策の一部としてそれを使用できます)。 いくつかの環境で、あるAAAプロトコルメッセージをtimestampedして(信じられた権威で)、その後のAAAメッセージの中でタイムスタンプを転送するのが必要であるかもしれません。
2.4 Topology
2.4 トポロジー
2.4.1 AAA protocols MUST be able to support the use of the push, pull and agent models.
2.4.1 AAAプロトコルはプッシュ、牽引力、およびエージェントモデルの使用をサポートすることができなければなりません。
This states that a protocol that only supported one model, say pull, would not meet the requirements of all the applications. The models are defined in [FRMW].
これは、1つをサポートしただけであるプロトコルがモデル化されると述べて、引くように言ってください、そして、すべてのアプリケーションに関する必要条件を満たさないでしょう。 モデルは[FRMW]で定義されます。
2.4.2 In transactions/sessions, which involve more than one AAA entity, each "hop" MAY use a different push/pull/agent model.
2.4.2 トランザクション/セッションのときに、各「ホップ」は異なったプッシュ/牽引力/エージェントモデルを使用するかもしれません。(セッションは1つ以上のAAA実体にかかわります)。
For example, in the mobile IP case, a "foreign" AAA server might pull authorization information from a broker, whereas the broker might push some authorization information to a "home" AAA server.
例えば、モバイルIP場合では、「外国」のAAAサーバはブローカーから承認情報を引くかもしれませんが、ブローカーは「ホーム」AAAサーバに何らかの承認情報を押すかもしれません。
Farrell, et al. Informational [Page 10] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [10ページ]情報のRFC2906AAA承認要件2000年8月
2.4.3 AAA Protocols MUST cater for applications and services where the entities involved in the application or AAA protocols belong to different (security) domains.
2.4.3 AAAプロトコルはアプリケーションかAAAプロトコルにかかわる実体が異なった(セキュリティ)ドメインに属すところにアプリケーションとサービスを満たさなければなりません。
This states that it must be possible for any AAA protocol message to cross security or administrative domain boundaries. Typically, higher levels of security will be applied when crossing such boundaries, and accounting mechanisms may also have to be more stringent.
これは、セキュリティに交差するどんなAAAプロトコルメッセージか管理ドメイン境界にも、それが可能であるに違いないと述べます。 そのような境界に交差するとき、通常、より高いレベルのセキュリティは適用されるでしょう、そして、また、会計機構も、より厳しくなければならないかもしれません。
2.4.4 AAA protocols MUST support roaming.
2.4.4 AAAプロトコルはローミングをサポートしなければなりません。
Roaming here may also be thought of as "away-from-home" operation. For example, this is a fundamental requirement for the mobile IP case.
移動して、また、操作は「ホームから離れている」と考えられるかもしれません。 例えば、これはモバイルIPケースのための基本的な要件です。
2.4.5 AAA protocols SHOULD support dynamic mobility
2.4.5 AAAプロトコルSHOULDはダイナミックな移動性をサポートします。
Dynamic mobility here means that a client moves from one domain to another, without having to completely re-establish e.g. whatever AAA session information is being maintained.
ここのダイナミックな移動性は、クライアントが1つのドメインから別のドメインまで移行することを意味します、例えば、AAAセッション情報が保守されているものなら何でも完全に復職させる必要はなくて。
2.4.6 An authorization decision MAY have to be made before the requestor has any other connection to a network.
2.4.6 ネットワークには要請者がいかなる他の接続もいる前に承認決定をしなければならないかもしれません。
For example, this means that the requestor can't go anywhere on the network to fetch anything and must do requests via an application/service or via an intermediate AAA entity. The AAA protocol should not overexpose such a server to denial-of-service attacks.
例えば、これは、要請者が何もとって来にネットワークで何処にも行くことができないで、アプリケーション/サービスか中間的AAA実体で要求しなければならないことを意味します。 AAAプロトコルはそのようなサーバをサービス不能攻撃に露出しすぎるべきではありません。
2.4.7 AAA protocols MUST support the use of intermediate AAA entities which take part in authorization transactions but which don't "own" any of the end entities or authorization data.
2.4.7 AAAプロトコルは承認トランザクションに参加しますが、終わりの実体のいずれも「所有していない」中間的AAA実体か承認データの使用をサポートしなければなりません。
In some environments (e.g. roamops), these entities are termed brokers (though these are not the same as bandwidth brokers in the QoS environment).
いくつかの環境(例えば、roamops)で、これらの実体はブローカーと呼ばれます(これらがQoS環境で帯域幅ブローカーと同じではありませんが)。
2.4.8 AAA protocols MAY support cases where an intermediate AAA entity returns a forwarding address to a requestor or AAA entity, in order that the requestor or originating AAA entity can contact another AAA entity.
2.4.8 AAAプロトコルは中間的AAA実体が要請者かAAA実体にフォーワーディング・アドレスを返すケースを支えるかもしれません、要請者か起因するAAA実体が別のAAA実体に連絡できるように。
This requirement recognizes that there will be routing issues with AAA servers, and that this requires that AAA protocols are able to help with such routing. For example, in the mobile IP case, a broker may be required, in part to allow the foreign and home AAA servers to get in contact.
この要件は、AAAサーバにはルーティング問題があって、これが、AAAプロトコルがそのようなルーティングで助けることができるのを必要とすると認めます。 例えば、モバイルIP場合では、ブローカーが、一部外国とホームAAAサーバが接触して得られるのを許容するのに必要であるかもしれません。
Farrell, et al. Informational [Page 11] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [11ページ]情報のRFC2906AAA承認要件2000年8月
2.4.9 It MUST be possible for an access decision function to discover the AAA server of a requestor. If the requestor provides information used in this discovery process then the access decision function MUST be able to verify this information in a trusted manner.
2.4.9 アクセス決定関数が要請者のAAAサーバを発見するのは、可能であるに違いありません。 要請者がこの発見プロセスで使用される情報を提供するなら、アクセス決定関数は信じられた方法でこの情報について確かめることができなければなりません。
This states that not only do AAA servers have to be able to find one another, but that sometimes an application entity may have to find an appropriate AAA server.
これは、AAAサーバはお互いを見つけることができるだけでよいのではなく、時々、アプリケーション実体が適切なAAAサーバを見つけなければならないかもしれないと述べます。
2.5 Application Proxying
2.5 アプリケーションProxying
2.5.1 AAA protocols MUST support cases where applications use proxies, that is, an application entity (C), originates a service request to a peer (I) and this intermediary (I) also initiates a service request on behalf of the client (C) to a final target (T). AAA protocols MUST be such that the authorization decision made at T, MAY depend on the authorization information associated with C and/or with I. This "application proxying" must not introduce new security weaknesses in the AAA protocols. There MAY be chains of application proxies of any length.
2.5.1 プロトコルがアプリケーションがプロキシを使用するケースを支えなければならないAAA(すなわち、アプリケーション実体(C))は同輩(I)にサービスのリクエストを溯源します、そして、また、この仲介者(I)は最終的な目標(T)へのクライアント(C)を代表してサービスのリクエストを開始します。 AAAプロトコルは、承認決定がTで作ったそのようなものでなければならなく、Cに関連している承認情報によるかもしれない、そして/または、「アプリケーションproxying I.This」でAAAプロトコルで新しいセキュリティ弱点を導入してはいけません。 どんな長さのアプリケーションプロキシのチェーンもあるかもしれません。
Note that this requirement addresses application layer proxying - not chains of AAA servers. For example, a chain of HTTP proxies might each want to restrict the content they serve to the "outside". As the HTTP GET message goes from HTTP proxy to HTTP proxy, this requirement states that it must be possible that the authorization decisions made at each stage can depend on the user at the browser, and not say, solely on the previous HTTP proxy's identity. Of course there may only be a single AAA server involved, or there may be many.
この要件が応用層proxyingを扱うことに注意してください--AAAサーバのチェーンでない。 例えば、HTTPプロキシのチェーンはそれぞれ、彼らが「外部」に役立つ内容を制限したがっているかもしれません。 HTTP GETメッセージがHTTPプロキシからHTTPプロキシまで行くように、この要件は、各段階でされた承認決定がブラウザでユーザに頼っていて、言うことができないのが、可能であるに違いないと述べます、唯一前のHTTPプロキシのアイデンティティで。 もちろん、かかわったただ一つのAAAサーバがあるだけであるかもしれませんか、または多くがあるかもしれません。
2.5.2 Where there is a chain of application proxies, the AAA protocol flows at each stage MAY be independent, i.e. the first hop may use the push model, the second pull, the third the agent model.
2.5.2 プロトコル流れが各段階でAAAのアプリケーションプロキシのチェーンがあるところでは、独立しているかもしれない、すなわち、最初のホップがプッシュモデルを使用するかもしれません、セカンドプル、3番目。エージェントモデル。
This simply restates a previous requirement (no. 2.4.7), to make it clear that this also applies when application proxying is being used.
これは、また、アプリケーションproxyingが使用していることにされるのであるときこれが適用されると断言するために、単に、前の要件(No.2.4.7)を言い直します。
2.6 Trust Model
2.6 信頼モデル
2.6.1 AAA entities MUST be able to make decisions about which other AAA entities are trusted for which sorts of authorization information.
2.6.1 AAA実体は他のAAA実体がどの種類の承認情報のために信じられる決定をすることができなければなりません。
This is analogous to a requirement in public key infrastructures: Just because someone can produce a cryptographically correct public key certificate does not mean that I should trust them for anything, in particular, I might trust the issuer for some purposes, but not for others.
これは公開鍵認証基盤による要件に類似しています: ただだれかが暗号でaを生産できるので、正しい公開鍵証明書は、私が何のためにもそれらを信じるべきであることを意味しません、特にいくつかの目的のために発行人を信じますが、私は他のもののために信じないかもしれません。
Farrell, et al. Informational [Page 12] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [12ページ]情報のRFC2906AAA承認要件2000年8月
2.6.2 AAA protocols MUST allow entities to be trusted for different purposes, trust MUST NOT be an all-or-nothing issue.
2.6.2 AAAプロトコルが、実体が異なる役割のために信じられるのを許容しなければならなくて、信頼がそうであるはずがない、オール、無、問題。
This relates the packaging (no. 2.1.3) and trust (no. 2.6.1) requirements. For example, a AAA entity may trust some parts of an authorization package but not others.
これはパッケージ(No.2.1.3)と信頼(No.2.6.1)要件について話します。 例えば、AAA実体は他のものではなく、承認パッケージのいくつかの部分を信じるかもしれません。
2.6.3 A confirmation of authorization MAY be required in order to initialize or resynchronize a AAA entity.
2.6.3 承認の確認が、AAA実体を初期化するか、または再連動させるのに必要であるかもしれません。
This states that a AAA entity may need to process some AAA protocol messages in order to initialize itself. In particular, a AAA entity may need to check that a previous AAA message remains "valid", e.g. at boot-time.
これは、AAA実体が、それ自体を初期化するためにいくつかのAAAプロトコルメッセージを処理する必要であるかもしれないと述べます。 特に、AAA実体は、前のAAAメッセージが例えば、ブート時間で「有効な」ままで残っているのをチェックする必要があるかもしれません。
2.6.4 A negation of static authorization MAY be required to shut down certain services.
2.6.4 静的な承認の否定が、あるサービスを止めるのに必要であるかもしれません。
This is the converse of 2.6.5 above. It means that a AAA entity may be "told" by another that a previous AAA message is no longer "valid". See also 2.3.2 and 2.7.6.
これは2.6の逆です。.5 上。 それは、AAA実体が前のAAAメッセージがもう「有効でない」と別のものによって「言われるかもしれないこと」を意味します。 2.3にも.6に.2と2.7を見てください。
2.6.5 It MUST be possible to configure sets of AAA entities that belong to a local domain, so that they are mutually trusting, but so that any external trust MUST be via some nominated subset of AAA entities.
2.6.5 局所領域に属してください、しかし、彼らが互いに信じているようにどんな外部の信頼もAAA実体の何らかの指名部分集合であるに違いないのは、AAA実体のセットを構成するのにおいて可能であるに違いありません。
This states that for efficiency or organizational reasons, it must be possible to set up some AAA servers through which all "external" AAA services are handled. It also states that it must be possible to do this without over-burdening the "internal-only" AAA servers with onerous security mechanisms, just because some AAA servers do handle external relations.
これは、効率か組織的な理由で、すべての「外部」のAAAサービスが扱われるいくつかのAAAサーバをセットアップするのが可能であるに違いないと述べます。 また、それは、煩わしいセキュリティー対策で「内部で唯一」のAAAサーバに負担をかけないでこれをするのが可能であるに違いないと述べます、ただいくつかのAAAサーバが外部の関係を扱うので。
2.6.6 Intermediate AAA entities in a chain MUST be able to refuse a connection approved by an earlier entity in the chain.
2.6.6 チェーンにおける中間的AAA実体はチェーンで以前の実体によって承認された接続を拒否できなければなりません。
For example, in mobile IP the home network may authorize a connection, but the foreign network may refuse to allow the connection due to the settings chosen by the home network, say if the home network will refuse to pay.
外国ネットワークは、ホームネットワークによって選ばれた設定による接続を許すのを拒否するかもしれません、そして、例えば、モバイルIPでは、ホームネットワークは接続に権限を与えるかもしれませんが、ホームネットワークが、支払うのを拒否するかどうか言ってください。
2.6.7 It SHOULD be possible to modify authorization for resources while a session is in progress without destroying other session information.
2.6.7 それ、SHOULD、セッションが進行している間、リソースのために承認を変更するのにおいて、他のセッション情報を無効にしないで、可能であってください。
Farrell, et al. Informational [Page 13] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [13ページ]情報のRFC2906AAA承認要件2000年8月
For example, a "parent" AAA server should be able to modify the authorization state of sessions managed by a "child" AAA server, say by changing the maximum number of simultaneous sessions which are allowed.
例えば「子供」AAAサーバによって管理されたAAAサーバが承認状態を変更できるべきである「親」セッションは、どれが許容されているかを同時のセッションの最大数を変えることによって、言います。
2.7 Not just transactions
2.7 トランザクションであるだけではない
2.7.1 Authorization decisions MAY be context sensitive, AAA protocols MUST enable such decisions.
2.7.1 承認決定が文脈敏感であるかもしれない、AAAプロトコルはそのような決定を可能にしなければなりません。
This states that AAA protocols need to support cases where the authorization depends, (perhaps even only depends), on the current state of the system, e.g. only seven sessions allowed, seventh decision depends on existence of six current sessions. Since the context might involve more than one service, the AAA protocol is likely to have to offer some support.
これは、AAAプロトコルが、承認を依存して、システムの現状、例えば許容された7つのセッションだけに関する(恐らく、よりさえするだけです)の7番目の決定を6の存在に依存するケースに現在のセッションをサポートする必要であると述べます。 文脈が1つ以上のサービスにかかわるかもしれないので、AAAプロトコルは何らかのサポートを提供しなければならない傾向があります。
2.7.2 AAA protocols SHOULD support both the authorization of transactions and continuing authorization of sessions.
2.7.2 AAAプロトコルSHOULDは、両方がトランザクションの承認とセッションの継続する承認であるとサポートします。
This states that AAA entities may have to maintain state and act when the state indicates some condition has been met.
これは州が、いくつかの条件を満たしてあるのを示すとき、AAA実体が状態を維持して、行動しなければならないかもしれないと述べます。
2.7.3 Within a single session or transaction, it MUST be possible to interleave authentication, authorization and accounting AAA messages.
2.7.3 ただ一つのセッションかトランザクションの中では、認証、承認、および会計AAAメッセージをはさみ込むのは可能であるに違いありません。
This states, that e.g. a session may have to use initial authentication, authorization and accounting AAA message(s), but also have to include e.g. re-authentication every 30 minutes, or a continuous "drip-drip" of accounting AAA messages.
これは、また、使用しなければならないのを除いて、例えば、セッションが初期の認証、承認、および会計AAAメッセージを使用しなければならないかもしれないのが例えば、30分毎の再認証、または会計AAAメッセージの連続した「したたりしたたり」を含んでいると述べます。
2.7.4 Authorization decisions may result in a "not ready" answer.
2.7.4 承認決定は「準備ができない」答えをもたらすかもしれません。
This states that yes and no are not the only outcomes of an authorization decision. In particular, if the AAA entity cannot yet give a decision, it might have to return such a result. This is analogous to how public key certification requests are sometimes handled in PKI management protocols.
これは、はいと述べます、そして、承認決定が唯一の結果がありません。 AAA実体がまだ判定を下すことができないなら、特に、それはそのような結果を返さなければならないかもしれません。 これは公開鍵証明要求がPKI管理プロトコルでどう時々扱われるかに類似しています。
2.7.5 A AAA entity MAY re-direct a AAA request that it has received.
2.7.5 AAA実体は受信したというAAA要求を向け直すかもしれません。
This states that if entity "a" asks "b", then "b" may say: "don't ask me, ask 'c'". This is analogous to HTTP re-direction (status code 307).
これは、実体“a"が「b」を尋ねるなら「b」が言うかもしれないと述べます: 「私に尋ねないでください、そして、'c'を尋ねてください。」 これはHTTPリダイレクション(ステータスコード307)に類似しています。
2.7.6 AAA protocols SHOULD allow a AAA entity to "take back" an authorization.
2.7.6 AAAプロトコルSHOULDは、AAA実体が承認を「取り戻すこと」を許容します。
Farrell, et al. Informational [Page 14] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [14ページ]情報のRFC2906AAA承認要件2000年8月
The expectation is that AAA protocols will support the ability of a AAA entity to signal an application or other AAA entity that an authorization (possibly previously granted by a third AAA entity) is no longer valid.
期待はAAAプロトコルがAAA実体が承認(ことによると、以前に、3番目のAAA実体で与える)がもう有効でないことをアプリケーションか他のAAA実体に示す能力をサポートするということです。
2.8 Administration
2.8 政権
2.8.1 It MUST be possible for authorization data to be administered on behalf of the end entities and AAA entities.
2.8.1 承認データが終わりの実体とAAA実体を代表して管理されるのは、可能であるに違いありません。
This requirement indicates that administration of AAA has to be considered as part of protocol design - a AAA protocol, which required all AAA entities act independent of all other AAA entities, would not meet the requirement.
この要件は、AAAの管理がプロトコルデザインの一部であるとみなされなければならないのを示します--AAAプロトコル(他のすべてのAAA実体の如何にかかわらずすべてのAAA実体条例を必要とした)は条件を満たさないでしょう。
2.8.2 Centralizable administration of all features SHOULD be supported.
2.8.2 すべてのCentralizable管理はSHOULDを特集します。サポートされます。
It should be possible (if it meets the domain requirements) to centralize or distribute the administration of AAA.
AAAの管理を集結するか、または分配するのが可能であるべきです(ドメイン要求性を満たすなら)。
2.8.3 AAA protocols SHOULD support cases where the user (as opposed to an administrator) authorizes a transaction.
2.8.3 AAAプロトコルSHOULDはユーザ(管理者と対照的に)がトランザクションを認可するケースを支えます。
For example, a user might want to control anti-spam measures or authorize things like a purchase. In such cases, the user is acting somewhat like an administrator.
例えば、ユーザは、反スパム測定を制御したいか、または購入のようなものを認可したがっているかもしれません。 そのような場合、ユーザはいくらか管理者のように行動しています。
2.8.4 One AAA entity MAY create authorization rules for another AAA entity.
2.8.4 1つのAAA実体が別のAAA実体のために承認規則を作成するかもしれません。
This is required to properly support delegation of authority, however when allowed, this must be able to be done in a secure fashion.
適切に権限の委任をサポートするためにこれを必要として、許容すると、しかしながら、これは安全なファッションですることができなければなりません。
2.8.5 AAA protocols SHOULD support failure recovery when one AAA entity in a chain of AAA entities that maintain state about a session fails.
2.8.5 セッション頃に状態を維持するAAA実体のチェーンにおける1つのAAA実体が失敗すると、AAAプロトコルSHOULDは、失敗が回復であるとサポートします。
For example, in a network access situation it may be required that a AAA server which has crashed be able to determine how many sessions are in progress, in order to make the "next" authorization decision.
例えば、ネットワークアクセス状況で、ダウンしたAAAサーバが、いくつのセッションが進行しているかを決定できるのが必要であるかもしれません、「次」の承認決定をするように。
2.8.6 It SHOULD be possible for a AAA entity to query the authorization state of another AAA entity.
2.8.6 それ、SHOULD、AAA実体が別のAAA実体の承認状態について質問するのにおいて、可能であってください。
This may be required as part of a failure recovery procedure.
これが失敗リカバリ手順の一部として必要であるかもしれません。
Farrell, et al. Informational [Page 15] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [15ページ]情報のRFC2906AAA承認要件2000年8月
2.8.7 AAA protocols MUST be able to support "hot fail-over" for server components without loss of state information.
2.8.7 AAAプロトコルはサーバコンポーネントのために州の情報の損失なしで「熱いフェイルオーバー」をサポートすることができなければなりません。
This states that AAA protocols must be able to support cases where, when a server is no longer operable, a secondary server can automatically be brought "live" without losing important state information.
これは、AAAプロトコルがサーバがもう手術可能でないときに重要な喪失なしで「生きてください」をセカンダリサーバに自動的に持って来ることができるケースに州の情報をサポートすることができなければならないと述べます。
2.9 Bytes on-the-wire
2.9バイト、ワイヤ
2.9.1 Authorization separate from authentication SHOULD be allowed when necessary, but the AAA protocols MUST also allow for a single message to request both authentication and authorization.
2.9.1 必要であるときに、認証SHOULDから別々の承認が許容されて、また、AAAプロトコルだけが認証と承認の両方を要求するただ一つのメッセージを考慮しなければなりません。
AAA protocols have to allow a split between authentication and authorization so that different mechanisms are used for each. This states that sometimes both types of information need to be carried in the same message.
AAAプロトコルが認証と承認の間の分裂を許容しなければならないので、異なったメカニズムはそれぞれに使用されます。 これは、時々両方のタイプの情報が、同じメッセージで運ばれる必要であると述べます。
2.9.2 In order to minimize resource usage (e.g. reduce roundtrips) it MUST be possible to embed AAA PDUs into other protocols.
2.9.2 リソース用法(例えば、往復旅行を抑える)を最小にするために、AAA PDUsを他のプロトコルに埋め込むのは可能でなければなりません。
This states that the AAA protocol authorization packages must be defined so that they can also be carried in other protocols. For example, depending on AAA protocol header information in order to reference an authorization package could cause a protocol to fail to meet the requirement.
これは、また、他のプロトコルでそれらを運ぶことができるようにAAAプロトコル承認パッケージを定義しなければならないと述べます。 例えば、承認パッケージに参照をつけるためにAAAプロトコルヘッダー情報によるのに、プロトコルは条件を満たすことができませんでした。
2.9.3 A AAA protocol MAY provide mechanisms for replication of state information.
2.9.3 AAAプロトコルは州の情報の模写にメカニズムを提供するかもしれません。
This can be required e.g. to support resiliency in cases where hot fail-over is required. Note that AAA protocols are of course, subject to normal protocol design requirements to do with reliability, no single-point-of-failure etc even though these are not all specified here.
これを必要とすることができます、例えば、熱いところで場合における弾性をサポートするために、フェイルオーバーが必要です。 これらがここですべて指定されませんが、AAAプロトコルが信頼性を処理するという正常なプロトコル設計の品質のもちろん失敗の単一のポイントを条件と注意してください。
2.9.4 A AAA protocol SHOULD allow the possibility for implementation of a gateway function between the AAA protocol and other legacy AAA related protocols.
2.9.4 SHOULDがAAAプロトコルと他のレガシーAAAの間のゲートウェイ機能の実装のための可能性を許容するAAAプロトコルはプロトコルを関係づけました。
For example, some form of support for [RFC2138] as a legacy protocol is very likely to be required. Of course, the use of such a gateway is almost certain to mean not meeting some other requirements, (e.g. end-to-end security), for transactions routed through the gateway. There is no implication that such gateway functionality needs to be a separate server.
例えば、レガシープロトコルとしての[RFC2138]のための何らかの形式のサポートが非常に必要でありそうです。 もちろん、そのようなゲートウェイの使用はある他の必要条件を満たすことを意味しないのがほとんど確かです、(例えば、終わりから終わりへのセキュリティ)、ゲートウェイを通して発送されたトランザクションのために。 そのようなゲートウェイの機能性が、別々のサーバである必要があるという含意が全くありません。
Farrell, et al. Informational [Page 16] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [16ページ]情報のRFC2906AAA承認要件2000年8月
2.9.5 A AAA protocol MUST be able to support use of a wide range of primitive data types, including RFC2277.
2.9.5 AAAプロトコルはRFC2277を含むさまざまな基本データ型の使用をサポートすることができなければなりません。
For example, various sized, signed and unsigned integers, possibly including multi-precision integers will almost certainly need to be transported. Floating point support according to ANSI IEEE 754-1985 may also be required.
例えば、様々な大きさで分けられた署名されるのと符号のない整数であり、ことによるとマルチ精度を含んで、整数は、ほぼ確実に輸送される必要があるでしょう。 また、ANSI IEEE754-1985に従った浮動小数点サポートが必要であるかもしれません。
2.9.6 A AAA protocol transport SHOULD support being optimized for a long-term exchange of small packets in a stream between a pair of hosts.
2.9.6 小型小包の長期の交換のために1組のホストの間で絶え間なく最適化されるAAAプロトコル輸送SHOULDサポート。
NASes typically have a high number of transactions/second, so the AAA protocol MUST allow the flow of requests to be controlled in order for the server to make efficient use of it's receive buffers.
NASesには大きい数のトランザクション/秒が通常あるので、AAAプロトコルはサーバがそれの効率的な使用をする命令で制御されているのが、受信バッファであるということであるという要求の流れを許容しなければなりません。
2.9.7 A AAA protocol MUST provide support for load balancing.
2.9.7 AAAプロトコルはロードバランシングのサポートを提供しなければなりません。
In the event that a peer's cannot receive any immediate requests, the AAA protocol MUST allow for an implementation to balance the load of requests among a set of peers.
同輩のものがどんな即座の要求も受け取ることができないなら、AAAプロトコルは、実装が1セットの同輩の中で要求の負荷のバランスをとるのを許容しなければなりません。
2.10 Interfaces
2.10 インタフェース
2.10.1 It SHOULD be possible that authorization data can be used for application purposes.
2.10.1 それ、SHOULD、アプリケーション目的に承認データを使用できるのを可能であってください。
For example, in web access, if the authorization data includes a group name, mechanisms to make this data available to the application so that it can modify the URL originally requested are desirable.
例えば、ウェブアクセスでは、承認データがグループ名を含んでいるなら、元々要求されたURLは変更できるようにこのデータをアプリケーションに利用可能にするメカニズムが望ましいです。
2.10.2 It SHOULD be possible that authorization data can be used to mediate the response to a request.
2.10.2 それ、SHOULD、要求への応答を調停するのに承認データを使用できるのを可能であってください。
For example, with web access the clearance attribute value may affect the content of the HTTP response message.
例えば、ウェブアクセスで、クリアランス属性値はHTTP応答メッセージの内容に影響するかもしれません。
2.10.3 AAA protocols SHOULD be able to operate in environments where requestors are not pre-registered (at least for authorization purposes, but possibly also for authentication purposes).
2.10.3 AAAプロトコルSHOULD、要請者があらかじめ登録されていない環境で作動できてください(少なくとも承認目的にもかかわらず、ことによると認証目的のためにも)。
This is necessary to be able to scale a AAA solution where there are many requestors.
これが、多くの要請者がいるところでAAAソリューションをスケーリングできるように必要です。
2.10.4 AAA protocols MUST be able to support a linkage between authorization and accounting mechanisms.
2.10.4 AAAプロトコルは承認と会計機構の間のリンケージをサポートすることができなければなりません。
Motherhood and apple-pie.
母性とアップルパイ。
Farrell, et al. Informational [Page 17] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [17ページ]情報のRFC2906AAA承認要件2000年8月
2.10.5 AAA protocols MUST be able to support accountability (audit/non-repudiation) mechanisms.
2.10.5 AAAプロトコルは責任(非監査/拒否)メカニズムをサポートできなければなりません。
Sometimes, an authorization decision will be made where the requestor has not authenticated. In such cases, it must be possible that the authorization data used is linked to audit or other accountability mechanisms. Note that this requirement does not call for mandatory support for digital signatures, or other parts of a non-repudiation solution.
認証されて、要請者がしていないところで時々、承認決定をするでしょう。 そのような場合、データが使用した承認が監査か他の責任メカニズムにリンクされるのは、可能でなければなりません。この要件がデジタル署名の義務的なサポート、または非拒否対策の他の部分を求めないことに注意してください。
2.11 Negotiation
2.11 交渉
2.11.1 AAA protocols MUST support the ability to refer to sets of authorization packages in order to allow peers negotiate a common set.
2.11.1 プロトコルが同輩を許容するために承認パッケージのセットについて言及する能力をサポートしなければならないAAAは一般的なセットを交渉します。
Given that peers may support different combinations of authorization attribute types and packages, the requirement states that protocol support is required to ensure that the peers use packages supported by both peers.
同輩が承認属性タイプとパッケージの異なった組み合わせをサポートするかもしれないなら、要件は、プロトコルサポートが同輩が両方の同輩によって支えられたパッケージを使用するのを保証するのに必要であると述べます。
2.11.2 It MUST be possible to negotiate authorization packages between AAA entities that are not in direct communication.
2.11.2 ダイレクトコミュニケーションにないAAA実体の間の承認パッケージを交渉するのは可能であるに違いありません。
This states that where, e.g. a broker is involved, the end AAA servers might still need to negotiate.
これは、どこ、例えばブローカーが伴われるか、そして、エンドAAAサーバが、まだ交渉する必要であるかもしれないと述べます。
2.11.3 Where negotiation fails to produce an acceptable common supported set then access MUST be denied.
2.11.3 交渉がその時許容できる一般的なサポートしているセットを生産しないところでは、アクセスを拒絶しなければなりません。
For example, a server cannot grant access if it cannot understand the attributes of the requestor.
例えば、要請者の属性を理解できないなら、サーバはアクセスを承諾できません。
2.11.4 Where negotiation fails to produce an acceptable common supported set then it SHOULD be possible to generate an error indication to be sent to another AAA entity.
2.11.4 交渉が失敗するところに許容できるコモンが支えた生産物に、その時セットしていた、SHOULD、別のAAA実体に送られる誤り表示を生成するのにおいて、可能であってください。
If negotiation fails, then some administrator intervention is often required, and protocol support for this should be provided.
交渉が失敗するなら、しばしば何らかの管理者介入を必要とします、そして、このプロトコルサポートを提供するべきです。
2.11.5 It MUST be possible to pre-provision the result of a negotiation, but in such cases, the AAA protocol MUST include a confirmation of the "negotiation result".
2.11.5 しかし、交渉の結果、そのような場合AAAプロトコルが「交渉結果」の確認を含まなければならないのは、プレ支給に可能であるに違いありません。
Even if the supported packages of a peer are configured, this must be confirmed before assuming both sides are similarly configured.
同輩のサポートしているパッケージが構成されても、両側が同様に構成されると仮定する前に、これを確認しなければなりません。
Farrell, et al. Informational [Page 18] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [18ページ]情報のRFC2906AAA承認要件2000年8月
2.11.6 For each application making use of a AAA protocol, there MUST be one inter-operable IETF standards-track specification of the authorization package types that are "mandatory to implement".
2.11.6 AAAプロトコルを利用する各アプリケーションのために、「実装するために義務的な」承認パッケージ型式の1つの共同利用できるIETF標準化過程仕様があるに違いありません。
This requirement assures that communicating peers can count on finding at least one IETF specified inter-operable AAA protocol dialect provided they are doing authorization for a common application specific problem domain. This does not preclude the negotiation of commonly understood but private AAA protocol authorization package types (e.g. vendor specific).
この要件は、同輩を伝えるのが、彼らが一般的なアプリケーション特定の問題ドメインに承認をしているなら少なくとも1IETFが共同利用できるAAAプロトコル方言を指定したのがわかるのを頼りにすることができることを保証します。 これは一般的に理解されていますが、個人的なAAAのプロトコル承認パッケージ型式(例えば、ベンダー詳細)の交渉を排除しません。
2.11.7 It SHOULD also be possible to rank AAA negotiation options in order of preference.
2.11.7 それ、SHOULD、また、好みの順にAAA交渉がオプションであると格付けするのにおいて可能であってください。
This states that, when negotiating, peers must be able to indicate preferences as well as capabilities.
これは、交渉するとき、同輩が能力と同様に好みを示すことができなければならないと述べます。
2.11.8 The negotiation mechanisms used by AAA protocols SHOULD NOT be vulnerable to a "bidding-down" attack.
2.11.8 交渉メカニズムはAAAでプロトコルSHOULD NOTを使用しました。「下に入札」攻撃に被害を受け易くいてください。
A "bidding-down" attack is where an attacker forces the negotiating parties to choose the "weakest" option available. This is analogous to forcing 40-bit encryption on a link. The requirement highlights that protocol support is needed to prevent such attacks, for example by including the negotiation messages as part of a later MAC calculation, if authentication has produced a shared secret.
「下に入札」攻撃は攻撃者が交渉パーティーに利用可能な「最も弱い」オプションを強制的に選ばせるところです。 これは40ビットの暗号化をリンクに押しつけるのに類似しています。 サポートについて議定書の中で述べる要件ハイライトがそのような攻撃を防ぐのに必要です、例えば、後のMAC計算の一部として交渉メッセージを含んでいることによって、認証が共有秘密キーを作り出したなら。
2.11.9 A peer MUST NOT send an attribute within an authorization package or attribute that was not agreed to by a prior successful negotiation. If this AAA protocol violation occurs, then it MUST be possible to send an error indication to the misbehaving peer, and generate an error indication to the network operator.
2.11.9 同輩は先のうまくいっている交渉でそれが同意されなかった承認パッケージか属性の中で属性を送ってはいけません。 このAAAプロトコル違反が起こるなら、ふらちな事をしている同輩に誤り表示を送って、ネットワーク・オペレータに誤り表示を生成するのは可能であるに違いありません。
2.11.10 A peer MUST declare all of the sets of the authorization packages that it understands in its initial negotiation bid message.
2.11.10 同輩はそれが初期の交渉付け値のメッセージで理解している承認パッケージのセットのすべてを宣言しなければなりません。
3. Security Considerations
3. セキュリティ問題
This document includes specific security requirements.
このドキュメントは特定のセキュリティ要件を含んでいます。
This document does not state any detailed requirements for the interplay with authentication, accounting or accountability (audit). A AAA protocol, which meets all of the above requirements, may still leave vulnerabilities due to such interactions. Such issues must be considered as part of AAA protocol design.
このドキュメントは認証、会計または責任(監査)で交錯のためのどんな詳細な要件も述べません。 AAAプロトコル(上記の要件のすべてに会う)はそのような相互作用のためまだ脆弱性を残しているかもしれません。 AAAプロトコルデザインの一部であるとそのような問題をみなさなければなりません。
Farrell, et al. Informational [Page 19] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [19ページ]情報のRFC2906AAA承認要件2000年8月
4. References
4. 参照
[FRMW] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D.
Spence, "AAA Authorization Framework", RFC 2904, August
2000.
[FRMW] VollbrechtとJ.とカルフーンとP.とファレルとS.とGommansとL.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認フレームワーク」、RFC2904、2000年8月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[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月。
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2138, April 1997.
[RFC2138]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、1998年1月。
[SAMP] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D.
Spence, "AAA Authorization Application Examples", RFC
2905, August 2000.
[SAMP] VollbrechtとJ.とカルフーンとP.とファレルとS.とGommansとL.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認アプリケーションの例」、RFC2905、2000年8月。
Authors' Addresses
作者のアドレス
Stephen Farrell Baltimore Technologies 61/62 Fitzwilliam Lane Dublin 2, IRELAND
スティーブンファレルボルチモア技術61/62フィッツウィリアムレーンダブリン2(アイルランド)
Phone: +353-1-647-7300 Fax: +353-1-647-7499 EMail: stephen.farrell@baltimore.ie
以下に電話をしてください。 +353-1-647-7300 Fax: +353-1-647-7499 メールしてください: stephen.farrell@baltimore.ie
John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
Vollbrechtが連結するジョンR.はInc.775技術ドライブ、アナーバー、200のスイートMI48108米国をネットワークでつなぎます。
Phone: +1 734 821 1205 Fax: +1 734 821 1235 EMail: jrv@interlinknetworks.com
以下に電話をしてください。 +1 734 821、1205Fax: +1 1235年の734 821メール: jrv@interlinknetworks.com
Farrell, et al. Informational [Page 20] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [20ページ]情報のRFC2906AAA承認要件2000年8月
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA
パットR.カルフーンネットワークとセキュリティリサーチセンター、サン・マイクロシステムズ・インク15がネットワークでつなぐSun研究室はメンローパーク、カリフォルニア94025米国を旋回します。
Phone: +1 650 786 7733 Fax: +1 650 786 6445 EMail: pcalhoun@eng.sun.com
以下に電話をしてください。 +1 650 786、7733Fax: +1 6445年の650 786メール: pcalhoun@eng.sun.com
Leon Gommans Enterasys Networks EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands
レオンGommans EnterasysはEMEA Kerkplein24 2841XM Moordrechtオランダをネットワークでつなぎます。
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
以下に電話をしてください。 +31 182 379279 メール: gommans@cabletron.com かユトレヒト大学で: l.h.m.gommans@phys.uu.nl
George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC2N-D13 Warren, NJ 07059 USA
ジョージM.Grossルーセントテクノロジーズ184リバティコーナーRoad、m.s. LC2N-D13ニュージャージー07059ウォレン(米国)
Phone: +1 908 580 4589 Fax: +1 908-580-4991 EMail: gmgross@lucent.com
以下に電話をしてください。 +1 908 580、4589Fax: +1 908-580-4991 メールしてください: gmgross@lucent.com
Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 LB Utrecht The Netherlands
ベティde Bruijn InterpayネーデルラントB.V.Eendrachtlaan315 3526LBユトレヒトオランダ
Phone: +31 30 2835104 EMail: betty@euronet.nl
以下に電話をしてください。 +31 30 2835104はメールされます: betty@euronet.nl
Farrell, et al. Informational [Page 21] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [21ページ]情報のRFC2906AAA承認要件2000年8月
Cees T.A.M. de Laat Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands Phone: +31 30 2534585 Phone: +31 30 2537555 EMail: delaat@phys.uu.nl
Cees T.午前のde Laat PhysicsとAstronomy dept。 大学Pincetonplein5、ユトレヒト3584CCユトレヒトオランダは以下に電話をします。 +31 30 2534585は以下に電話をします。 +31 30 2537555はメールされます: delaat@phys.uu.nl
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
マットHoldrege ipVerse223Ximeno Ave。 ロングビーチ、カリフォルニア 90803
EMail: matt@ipverse.com
メール: matt@ipverse.com
David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA
スペンスが連結するデヴィッドW.はInc.775技術ドライブ、アナーバー、200のスイートMI48108米国をネットワークでつなぎます。
Phone: +1 734 821 1203 Fax: +1 734 821 1235 EMail: dspence@interlinknetworks.com
以下に電話をしてください。 +1 734 821、1203Fax: +1 1235年の734 821メール: dspence@interlinknetworks.com
Farrell, et al. Informational [Page 22] RFC 2906 AAA Authorization Requirements August 2000
ファレル、他 [22ページ]情報のRFC2906AAA承認要件2000年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Farrell, et al. Informational [Page 23]
ファレル、他 情報[23ページ]
一覧
スポンサーリンク
