📄 rfc2904.txt
字号:
Network Working Group J. VollbrechtRequest for Comments: 2904 Interlink Networks, Inc.Category: Informational P. Calhoun Sun Microsystems, Inc. S. Farrell Baltimore Technologies 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 AAA Authorization FrameworkStatus of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.Abstract This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.Vollbrecht, et al. Informational [Page 1]RFC 2904 AAA Authorization Framework August 2000Table of Contents 1. Introduction ................................................ 2 2. Authorization Entities and Trust Relationships .............. 4 3. Message Sequences ........................................... 7 3.1. Single Domain Case ..................................... 7 3.1.1. The Agent Sequence .............................. 7 3.1.2. The Pull Sequence ............................... 8 3.1.3. The Push Sequence ............................... 9 3.2. Roaming ................................................ 10 3.3. Distributed Services ................................... 13 3.4. Combining Roaming and Distributed Services ............. 15 4. Relationship of Authorization and Policy .................... 16 4.1. Policy Retrieval ....................................... 16 4.2. Policy Evaluation ...................................... 17 4.3. Policy Enforcement ..................................... 17 4.4. Distributed Policy ..................................... 18 5. Use of Attribute Certificates ............................... 19 6. Resource Management ......................................... 22 6.1. Session Management ..................................... 23 6.2. The Resource Manager ................................... 24 7. AAA Message Forwarding and Delivery ......................... 25 8. End-to-End Security ......................................... 26 9. Streamlined Authorization Process ........................... 27 10. Summary of the Authorization Framework ..................... 28 11. Security Considerations .................................... 28 Glossary ....................................................... 29 References ..................................................... 31 Authors' Addresses ............................................. 32 Full Copyright Statement ....................................... 351. Introduction 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 Authorization Framework (this document) AAA Authorization Requirements [2] AAA Authorization Application Examples [3] There is a demonstrated need for a common scheme which covers all Internet services which offer Authorization. This common scheme will address various functional architectures which meet the requirements of basic services. We attempt to describe these architectures and functions as a basis for deriving requirements for an authorization protocol [2].Vollbrecht, et al. Informational [Page 2]RFC 2904 AAA Authorization Framework August 2000 These architectures include Policy structures, Certificate Authorities, Resource Managers, Inter-Domain and Multi-Domain schemes, and Distributed Services. The requirements are for the expected use of Authorization services across these architectures. A representative set of applications that may use this architecture to support their authorization needs is presented in [3]. The examples in [3] show how this framework may be used to meet a wide variety of different authorization needs. We expect that this work may be extended in the future to a more comprehensive model and that the scheme described here will be incorporated into a framework that includes authentication, accounting and auditing. We have referenced a number of authorization sources, but also recognize that there may be some that we have missed and that should be included. Please notify one of the authors of any such oversight so it can be corrected in a future revision. In general, it is assumed that the parties who are participating in the authorization process have already gone through an authentication phase. The authentication method used by those parties is outside the scope of this document except to the extent that it influences the requirements found in a subsequent authorization process. Likewise, accounting requirements are outside the scope of this document other than recording accounting data or establishing trust relationships during an authorization that will facilitate a subsequent accounting phase. 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. This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4].Vollbrecht, et al. Informational [Page 3]RFC 2904 AAA Authorization Framework August 20002. Authorization Entities and Trust Relationships The following framework is being presented in order to provide a framework for discussing authorization requirements for a large number of applications. The intent is to provide some common vocabulary for the discussion. Terminology is introduced for basic elements in the authorization transaction and for concepts that appear to be common to all (or at least many) authorization proposals. Figure 1, below, identifies the basic conceptual entities that may be participants in an authorization: 1. A User who wants access to a service or resource. 2. A User Home Organization (UHO) that has an agreement with the user and checks whether the user is allowed to obtain the requested service or resource. This entity may carry information required to authorize the User, which might not be known to the Service Provider (such as a credit limit). 3. A Service Provider's AAA Server which authorizes a service based on an agreement with the User Home Organization without specific knowledge about the individual User. This agreement may contain elements that are not relevant to an individual user (e.g., the total agreed bandwidth between the User Home Organization and the Service Provider). 4. A Service Provider's Service Equipment which provides the service itself. This might, for example, be a NAS in dial service, or a Router in the QoS service, or a print server in the Internet Printing service.Vollbrecht, et al. Informational [Page 4]RFC 2904 AAA Authorization Framework August 2000 +------+ +-------------------------+ | | | User Home Organization | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | | | | | | User | +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Service | | | | | | Equipment | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Fig. 1 -- The Basic Authorization Entities These entities will be referenced in the authorization requirements. There may be bilateral agreements between pairs of organizations involved in an authorization transaction. Agreements between organizations may take the form of formal contracts or Service Level Agreements. Figure 2 uses double lines to show relationships that may exist between the User and the User Home Organization and between the User Home Organization and the Service Provider.Vollbrecht, et al. Informational [Page 5]RFC 2904 AAA Authorization Framework August 2000 +------+ +-------------------------+ | | | User Home Organization | | |======| +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | || | | || | | || | User | +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Service | | | | | | Equipment | | | | | +-------------------+ |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -