rfc2905.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,576 行 · 第 1/5 页
TXT
1,576 行
Network Working Group J. Vollbrecht
Request 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 Examples
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.
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 2000
Table 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 .............. 35
Vollbrecht, 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 ....................................... 53
1. 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 parameters
Vollbrecht, 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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?