rfc2905.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,607 行 · 第 1/5 页
TXT
1,607 行
Network Working Group J. VollbrechtRequest for Comments: 2905 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 Application ExamplesStatus 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 describes several examples of applications requiring authorization. Each application is described in terms of a consistent framework, and specific authorization requirements of each application are given. This material was not contributed by the working groups responsible for the applications and should not be considered prescriptive for how the applications will meet their authorization needs. Rather the intent is to explore the fundamental needs of a variety of different applications with the view of compiling a set of requirements that an authorization protocol will need to meet in order to be generally useful.Vollbrecht, et al. Informational [Page 1] RFC 2905 AAA Authorization Application Examples August 2000Table of Contents 1. Introduction ................................................ 3 2. PPP Dialin with Roaming ..................................... 4 2.1. Descriptive Model ...................................... 4 2.2. Authorization Requirements ............................. 6 3. Mobile-IP ................................................... 6 3.1. Relationship to the Framework .......................... 10 3.2. Minimized Internet Traversal ........................... 10 3.3. Key Distribution ....................................... 10 3.4. Mobile-IP Authorization Requirements ................... 11 4. Bandwidth Broker ............................................ 12 4.1. Model Description ...................................... 13 4.2. Components of the Two-Tier Model ....................... 13 4.3. Identification of Contractual Relationships ............ 13 4.3.1. Single-Domain Case .............................. 14 4.3.2. Multi-Domain Case ............................... 15 4.4. Identification of Trust Relationships .................. 16 4.5. Communication Models and Trust Relationships ........... 18 4.6. Bandwidth Broker Communication Models .................. 19 4.6.1. Concepts ........................................ 19 4.6.1.1. Intra-Domain Authorization ............... 19 4.6.1.2. Inter-Domain Authorization ............... 19 4.6.2. Bandwidth Broker Work Phases .................... 20 4.6.3. Inter-Domain Signaling .......................... 20 4.6.3.1. Phase 0 .................................. 20 4.6.3.2. Phase 1 .................................. 20 4.6.4. Bandwidth Broker Communication Architecture ..... 22 4.6.5. Two-Tier Inter-Domain Model ..................... 23 4.6.5.1. Session Initialization ................... 23 4.6.5.2. Service Setup ............................ 23 4.6.5.3. Service Cancellation ..................... 24 4.6.5.4. Service Renegotiation .................... 24 4.6.5.5. RAR and RAA .............................. 24 4.6.5.6. Session Maintenance ...................... 24 4.6.5.7. Intra-domain Interface Protocol .......... 24 4.7. Requirements ........................................... 24 5. Internet Printing ........................................... 25 5.1. Trust Relationships .................................... 26 5.2. Use of Attribute Certificates .......................... 27 5.3. IPP and the Authorization Descriptive Model ............ 28 6. Electronic Commerce ......................................... 29 6.1. Model Description ...................................... 30 6.1.1. Identification of Components .................... 30 6.1.2. Identification of Contractual Relationships ..... 31 6.1.3. Identification of Trust Relationships ........... 32 6.1.3.1. Static Trust Relationships ............... 33 6.1.3.2. Dynamic Trust Relationships .............. 35Vollbrecht, et al. Informational [Page 2] RFC 2905 AAA Authorization Application Examples August 2000 6.1.4. Communication Model ............................. 35 6.2. Multi Domain Model ..................................... 37 6.3. Requirements ........................................... 38 7. Computer Based Education and Distance Learning .............. 40 7.1. Model Description ...................................... 40 7.1.1. Identification of Components .................... 40 7.1.2. Identification of Contractual Relationships ..... 41 7.1.3. Identification of Trust Relationships ........... 43 7.1.4. Sequence of Requests ............................ 44 7.2. Requirements ........................................... 46 8. Security Considerations ..................................... 47 Glossary ....................................................... 47 References ..................................................... 48 Authors' Addresses ............................................. 50 Full Copyright Statement ....................................... 531. 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 [2] AAA Authorization Requirements [3] AAA Authorization Application Examples (this document) In this memo, we examine several important Internet applications that require authorization. For each application, we present a model showing how it might do authorization and then map that model back to the framework presented in [2]. We then present the authorization requirements of the application as well as we presently understand them. The requirements presented in this memo have been collected together, generalized, and presented in [3]. The intent of this memo is to validate and illustrate the framework presented in [2] and to motivate the requirements presented in [3]. This work is intended to be in alignment with the work of the various working groups responsible for the authorization applications illustrated. This memo should not, however, be regarded as authoritative for any of the applications illustrated. Where authoritative documents exist or are in development, they are listed in the references at the end of this document.Vollbrecht, et al. Informational [Page 3] RFC 2905 AAA Authorization Application Examples August 2000 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].2. PPP Dialin with Roaming In this section, we present an authorization model for dialin network access in terms of the framework presented in [2]. Included in the model are the multi-domain considerations required for roaming [5]. Detailed requirements for network access protocols are presented in [6].2.1. Descriptive Model The PPP dialin application uses the pull sequence as discussed in [2]. The roaming case uses the roaming pull sequence, also discussed in [2]. This sequence is redrawn using dialin roaming terminology in figure 1, below.Vollbrecht, et al. Informational [Page 4] RFC 2905 AAA Authorization Application Examples August 2000 +------+ +-------------------------+ | | | Home ISP | | | | (User Home Organization)| | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | /|\ | | | | +--------------+---+------+ | | | | | | |3 |4 | | | | | | +--------------+---+------+ | | | Visited ISP | | | | | | | \|/ | | User | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | /|\ | | | | | |2 |5 | | | | | \|/ | | | 1 | +-------------------+ | | |------+->| NAS (Service | | | |<-----+--| Equipment) | | | | 6 | +-------------------+ | | | | (Service Provider) | +------+ PPP +-------------------------+ Fig. 1 -- Dialin Authorization Based on Roaming Pull Sequence In this model, the User dials in to a Network Access Server (NAS) provided by the visited (or foreign) ISP (the Service Provider in the general model). The User is authenticated using a protocol such as PAP, CHAP, or EAP which is encapsulated in PPP frames (1). Because the User has not yet gained access to the network, he or she cannot send IP datagrams to a AAA server. At this point, the User can only communicate with the NAS (Service Equipment). The NAS forwards the User's authentication/ authorization request including the Network Access Identifier (NAI) [7] to a AAA server in its own domain via RADIUS [8] or a successor AAA protocol (2). The visited ISP's AAA server examines the realm from the NAI and forwards the request to the User's home domain AAA server (3). The home domain AAA server authenticates the user and authorizes access according to a roaming agreement. The home domain AAA server may return service parametersVollbrecht, et al. Informational [Page 5] RFC 2905 AAA Authorization Application Examples August 2000 (e.g. Idle-Timeout) to the visited ISP's AAA server (4) which forwards them to the NAS, possibly adding additional service parameters (5). The NAS completes PPP session initialization (6). In the future, this model may be expanded in several ways [9]. For instance, Authentication and Authorization may be done in separate passes using different servers in order to support specialized forms of authentication. Or to better support roaming, a broker may be inserted between the visited ISP and the home ISP. Or authorization may be supported based on other identifiers such as the caller ID and called ID obtained from the PSTN (e.g., using ANI and DNIS).2.2. Authorization Requirements The following requirements are identified in [9] for authorizing PPP dialin service using roaming. - Authorization separate from authentication should be allowed when necessary, but the AAA protocol MUST allow for a single message to request both authentication and authorization. - The AAA protocol MUST be "proxyable", meaning that a AAA Server or PDP MUST be able to forward the request to another AAA Server or PDP, which may or may not be within the same administrative domain. - The AAA protocol MUST allow for intermediate brokers to add their own local Authorization information to a request or response. - When a broker is involved, the protocol MUST provide end to end security. - The broker MUST be able to return a forwarding address to a requester, allowing two nodes to communicate together. - The protocol MUST provide the following features (per user⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?