doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc2904.txt b/doc/rfc/rfc2904.txt
new file mode 100644
index 0000000..f57e5c2
--- /dev/null
+++ b/doc/rfc/rfc2904.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                      J. Vollbrecht
+Request 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 Framework
+
+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 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 2000
+
+
+Table 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 ....................................... 35
+
+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 (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 2000
+
+
+2.  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     |  |
+              |      |      |  +-------------------+  |
+              |      |      |                         |
+              +------+      +-------------------------+
+
+                     Fig. 2 -- Service Agreements
+
+   Authorization is based on these bilateral agreements between
+   entities. Agreements may be chained, as shown in figure 2.  The User
+   has an agreement with the User Home Organization (e.g., the User may
+   have access to the service between 9:00 a.m. and 11:00 a.m. daily).
+   The User Home Organization has an agreement with the Service Provider
+   (e.g., that all requests for access will be granted, except between
+   5:00 a.m. and 10:00 a.m. on Sunday).  The fulfillment of the User's
+   request depends on both agreements being honored.
+
+   Note that these agreements may be implemented by hand configuration
+   or by evaluation of Policy data stored in a Policy database.  The
+   point is that there must be a set of known rules in place between
+   entities in order for authorization transactions to be executed.
+
+   Trust is necessary to allow each entity to "know" that the policy it
+   is authorizing is correct.  This is a business issue as well as a
+   protocol issue.  Trust is often established through third party
+   authentication servers (such as Kerberos), via a certificate
+   authority, by configuring shared secrets or passwords, or by sharing
+   a common facility (such as a connecting wire between processors).
+   These "static" trust relationships are necessary for authorization
+
+
+
+Vollbrecht, et al.           Informational                      [Page 6]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   transactions to take place.  Static trust relationships are used in
+   an authorization sequence to establish a "dynamic" relationship
+   between the User and the Service Equipment.  Several possible
+   authorization sequences are possible, each of which use the static
+   trust "chain" to have the user first be approved by the User Home
+   Organization, and then have the Service Provider accept the request
+   based on its trust of the User Home Organization.
+
+3.  Message Sequences
+
+   In general, the User Home Organization and the Service Provider are
+   different entities or different "administrative domains".  In the
+   simplest case, however, the User Home Organization and the Service
+   Provider may be combined as a single entity.  This case will be used
+   to describe three authorization sequences possible with the simple
+   case.
+
+   In following sections these concepts will be applied to more
+   complicated cases involving separate User Home Organization and
+   Service Provider entities (as in roaming) and multiple Service
+   Providers each with their own AAA Servers and Service Equipment (as
+   in distributed services).
+
+3.1.  Single Domain Case
+
+   This case includes the User, the Service Provider's AAA Server, and
+   the Service Provider's Service Equipment.  Examples of this case
+   include a NAS supported by a standalone RADIUS server, or a QoS
+   Router supported by a local bandwidth broker.
+
+   The sequences considered in the following figures are the "agent",
+   "pull", and "push" sequences for the single domain case.
+
+3.1.1.  The Agent Sequence
+
+   In the agent sequence (see figure 3), the Service Provider AAA Server
+   functions as an agent between the User and the service itself.  The
+   AAA Server receives a request from the User and forwards
+   authorization and possibly configuration information to the Service
+   Equipment.  In this model, the User sends a request to the Service
+   Provider's AAA Server (1), which will apply a policy associated with
+   the User and the particular service being requested.  The AAA Server
+   sends a request to the Service Equipment, and the Service Equipment
+   sets up whatever is requested (2).  The Service Equipment then
+   responds to the AAA Server acknowledging that it has set up the
+   Service for the user (3).  The AAA Server replies to the User telling
+   it that the Service is set up (4).
+
+
+
+
+Vollbrecht, et al.           Informational                      [Page 7]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   Depending on the nature of the service, further communication may
+   take place between the User and the Service Equipment.  For this to
+   occur, there needs to be a binding between the User and the
+   authorized service.  This requires further study.
+
+                          +-------------------------+
+            +------+      | Service Provider        |
+            |      |   1  |  +-------------------+  |
+            |      |------+->|    AAA Server     |  |
+            |      |<-----+--|                   |  |
+            |      |   4  |  +-------------------+  |
+            | User |      |          |  /|\         |
+            |      |      |          |2  |3         |
+            |      |      |         \|/  |          |
+            |      |      |  +-------------------+  |
+            |      |      |  |      Service      |  |
+            |      |      |  |     Equipment     |  |
+            |      |      |  +-------------------+  |
+            +------+      |                         |
+                          +-------------------------+
+
+                     Fig. 3 -- Agent Sequence
+
+   Example: A regular user may ask for 1 Mb/s bandwidth (1).  The
+   bandwidth broker (AAA Server) tells the router (Service Equipment) to
+   set this user into the 1Mb/s "queue" (2).  The router responds that
+   it has done so (3), and the bandwidth broker tells the User the
+   bandwidth is set up (4).
+
+3.1.2.  The Pull Sequence
+
+   The pull sequence (figure 4) is what is typically used in the Dialin
+   application, in the Mobile-IP proposal, and in some QoS proposals.
+   The User sends a request to the Service Equipment (1), which forwards
+   it to the Service Provider's AAA Server (2), which evaluates the
+   request and returns an appropriate response to the Service Equipment
+   (3), which sets up the service and tells the User it is ready (4).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                      [Page 8]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+                          +-------------------------+
+            +------+      | Service Provider        |
+            |      |      |  +-------------------+  |
+            |      |      |  |    AAA Server     |  |
+            |      |      |  |                   |  |
+            |      |      |  +-------------------+  |
+            | User |      |         /|\  |          |
+            |      |      |          |2  |3         |
+            |      |      |          |  \|/         |
+            |      |   1  |  +-------------------+  |
+            |      |------+->|      Service      |  |
+            |      |<-----+--|     Equipment     |  |
+            |      |   4  |  +-------------------+  |
+            +------+      |                         |
+                          +-------------------------+
+
+                     Fig. 4 -- Pull Sequence
+
+3.1.3.  The Push Sequence
+
+   The push sequence (figure 5) requires that the User get from the
+   Service Provider's AAA Server a ticket or certificate verifying that
+   it is o.k. for the User to have access to the service (1,2).   The
+   User includes the ticket in the request (3) to the Service Equipment.
+   The Service Equipment uses the ticket to verify that the request is
+   approved by the Service Provider's AAA Server.  The Service Equipment
+   then sends an o.k. to the User (4).
+
+   The ticket the user gets from the Service Provider's AAA Server will
+   typically have some time limit on it.  It may contain an indication
+   of service location, and in some applications, it might be used for
+   more than one request.
+
+   In the push sequence the communication between the AAA Server and the
+   Service Equipment is relayed through the User rather than directly
+   between themselves.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                      [Page 9]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+                            +-------------------------+
+              +------+      | Service Provider        |
+              |      |   1  |  +-------------------+  |
+              |      |------+->|    AAA Server     |  |
+              |      |<-----+--|                   |  |
+              |      |   2  |  +-------------------+  |
+              | User |      |                         |
+              |      |      |                         |
+              |      |      |                         |
+              |      |   3  |  +-------------------+  |
+              |      |------+->|      Service      |  |
+              |      |<-----+--|     Equipment     |  |
+              |      |   4  |  +-------------------+  |
+              +------+      |                         |
+                            +-------------------------+
+
+                     Fig. 5 -- Push Sequence
+
+3.2.  Roaming -- the User Home Organization is not the Service Provider
+
+   In many interesting situations, the organization that authorizes and
+   authenticates the User is different from the organization providing
+   the service.  This situation has been explored in the Roaming
+   Operations (roamops) Working Group.  For purposes of this discussion,
+   any situation in which the User Home Organization is different from
+   the Service Provider is considered to be roaming.
+
+   Examples of roaming include an ISP selling dialin ports to other
+   organizations or a Mobile-IP provider allowing access to a user from
+   another domain.
+
+   The same agent, pull and push sequences are possible with roaming.
+   If the Service Provider's AAA Server and the Service Equipment are
+   grouped as a logical entity for purposes of description, then the
+   following figures illustrate these cases.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 10]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+            +------+      +-------------------------+
+            |      |   1  | User Home Organization  |
+            |      |----->|  +-------------------+  |
+            |      |      |  |    AAA Server     |  |
+            |      |<-----|  |                   |  |
+            |      |   4  |  +-------------------+  |
+            |      |      |                         |
+            |      |      +-------------------------+
+            |      |                 |  /|\
+            |      |                 |2  |3
+            |      |                \|/  |
+            | User |      +-------------------------+
+            |      |      | Service Provider        |
+            |      |      |  +-------------------+  |
+            |      |      |  |    AAA Server     |  |
+            |      |      |  |                   |  |
+            |      |      |  +-------------------+  |
+            |      |      |                         |
+            |      |      |  +-------------------+  |
+            |      |      |  |      Service      |  |
+            |      |      |  |     Equipment     |  |
+            |      |      |  +-------------------+  |
+            |      |      |                         |
+            +------+      +-------------------------+
+
+                 Fig. 6 -- Roaming Agent Sequence
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 11]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+            +------+      +-------------------------+
+            |      |      | User Home Organization  |
+            |      |      |  +-------------------+  |
+            |      |      |  |    AAA Server     |  |
+            |      |      |  |                   |  |
+            |      |      |  +-------------------+  |
+            |      |      |                         |
+            |      |      +-------------------------+
+            |      |                /|\  |
+            |      |                 |2  |3
+            |      |                 |  \|/
+            |      |      +-------------------------+
+            |      |      | Service Provider        |
+            | User |      |  +-------------------+  |
+            |      |      |  |    AAA Server     |  |
+            |      |   1  |  |                   |  |
+            |      |----->|  +-------------------+  |
+            |      |      |                         |
+            |      |<-----|  +-------------------+  |
+            |      |   4  |  |      Service      |  |
+            |      |      |  |     Equipment     |  |
+            |      |      |  +-------------------+  |
+            |      |      |                         |
+            +------+      +-------------------------+
+
+                 Fig. 7 -- Roaming Pull Sequence
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 12]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+            +------+      +-------------------------+
+            |      |   1  | User Home Organization  |
+            |      |----->|  +-------------------+  |
+            |      |      |  |    AAA Server     |  |
+            |      |<-----|  |                   |  |
+            |      |   2  |  +-------------------+  |
+            |      |      |                         |
+            |      |      +-------------------------+
+            |      |
+            |      |
+            |      |
+            | User |      +-------------------------+
+            |      |      | Service Provider        |
+            |      |      |  +-------------------+  |
+            |      |      |  |    AAA Server     |  |
+            |      |   3  |  |                   |  |
+            |      |----->|  +-------------------+  |
+            |      |      |                         |
+            |      |<-----|  +-------------------+  |
+            |      |   4  |  |      Service      |  |
+            |      |      |  |     Equipment     |  |
+            |      |      |  +-------------------+  |
+            |      |      |                         |
+            +------+      +-------------------------+
+
+               Fig. 8 -- Roaming Push Sequence
+
+3.3.  Distributed Services
+
+   To provide a complete service to a user, offerings from several
+   service providers may need to be combined.  An example would be a
+   user who requires a QoS service for a session that crosses multiple
+   ISPs.  Any service that is provided by more than one Service Provider
+   acting in concert is a distributed service.  Figure 9 illustrates
+   distributed services.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 13]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+                 +-------------------+      +-------------------+
+   +------+      | Org1              |      | Org2              |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |  | AAA Server  |  |      |  | AAA Server  |  |
+   |      |      |  |             |  |      |  |             |  |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   | User |======|                   |======|                   |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |  |   Service   |  |      |  |   Service   |  |
+   |      |      |  |  Equipment  |  |      |  |  Equipment  |  |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   +------+      |                   |      |                   |
+                 +-------------------+      +-------------------+
+
+                  Fig. 9 -- Distributed Services
+
+   The agreements between entities in figure 9 imply that the request
+   from the User will be authenticated and authorized by the first
+   organization, then forwarded to the second organization.  Note that
+   the sequence between User and Org1 may be different than between Org1
+   and Org2.  The first might use a pull sequence, and the second might
+   use an agent sequence.  This example is illustrated in figure 10.
+
+                 +-------------------+      +-------------------+
+   +------+      | Org1              |      | Org2              |
+   |      |      |  +-------------+  |   3  |  +-------------+  |
+   |      |      |  | AAA Server  |--+------+->| AAA Server  |  |
+   |      |      |  |             |<-+------+--|             |  |
+   |      |      |  +-------------+  |   6  |  +-------------+  |
+   | User |      |       /|\  |      |      |        |  /|\     |
+   |      |      |        |2  |7     |      |        |4  |5     |
+   |      |      |        |  \|/     |      |       \|/  |      |
+   |      |   1  |  +-------------+  |      |  +-------------+  |
+   |      |------+->|   Service   |  |      |  |   Service   |  |
+   |      |<-----+--|  Equipment  |  |      |  |  Equipment  |  |
+   |      |   8  |  +-------------+  |      |  +-------------+  |
+   +------+      |                   |      |                   |
+                 +-------------------+      +-------------------+
+
+             Fig. 10 -- A Possible Distributed Sequence
+
+   There are a number of other ways that authorization sequences for
+   distributed services can be set up.  For example, it is possible
+   that, in order to reduce delay time in setting up a session, Org1
+   could send a response to the user before receiving a verification
+   that Org2 has authorized the service.  In that case Org1 would need
+   to be able to revoke the authorization sent earlier if Org2 does not
+   send the authorization in some amount of time.
+
+
+
+Vollbrecht, et al.           Informational                     [Page 14]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+3.4.  Combining Roaming and Distributed Services
+
+   Figure 11 shows a combination of Roaming and Distributed Services.
+   Contract and trust relationships may be set up in number of ways,
+   depending on a variety of factors, especially the business model.
+
+   +------+      +-------------------+      +-------------------+
+   |      |      | User Home Org     |      | SuperOrg          |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |  | AAA Server  |  |      |  | AAA Server  |  |
+   |      |      |  |             |  |      |  |             |  |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |                   |      |                   |
+   |      |      +-------------------+      +-------------------+
+   |      |
+   |      |
+   |      |      +-------------------+      +-------------------+
+   | User |      | Org1              |      | Org2              |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |  | AAA Server  |  |      |  | AAA Server  |  |
+   |      |      |  |             |  |      |  |             |  |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |                   |      |                   |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |  |   Service   |  |      |  |   Service   |  |
+   |      |      |  |  Equipment  |  |      |  |  Equipment  |  |
+   |      |      |  +-------------+  |      |  +-------------+  |
+   |      |      |                   |      |                   |
+   +------+      +-------------------+      +-------------------+
+
+            Fig. 11 -- Roaming and Distributed Services
+
+   New entities that combine or add capabilities can be created to meet
+   business needs.   In figure 11, one such possibility, a SuperOrg
+   entity is shown.  The idea is that this entity would provide
+   authentication and authorization for organizations that are providing
+   services to end-users. It could be considered to be a wholesaler or
+   broker.  While not all authorization will require having a broker,
+   authorization protocols should allow such entities to be created to
+   meet legitimate requirements.
+
+   Having considered the basic players and how they interact, we will
+   now consider different ways that authorization data may be stored in
+   the network.
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 15]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+4.  Relationship of Authorization and Policy
+
+   The Policy Framework (policy) Working Group is seeking to provide a
+   framework to represent, manage, and share policies and policy
+   information in a vendor-independent, interoperable, scalable manner.
+   [5],[6],[7].  This section explores the relationship of policy and
+   authorization and sets the stage for defining protocol requirements
+   for supporting policy when included as part of multi-domain
+   authorization.  The work presented here builds on the policy
+   framework, extending it to support policy across multiple domains.
+
+   One view of an authorization is that it is the result of evaluating
+   policies of each organization that has an interest in the
+   authorization decision.  In this document the assumption is that each
+   administration may have policies which may be indexed by user, by
+   service, or by other attributes of the request.  The policies of each
+   administration are defined independently of other administrations.
+
+   Each independent policy must be 1) retrieved, 2) evaluated, and 3)
+   enforced.
+
+4.1.  Policy Retrieval
+
+   Policy definitions are maintained and stored in a policy repository
+   [5] by (or on behalf of) the organization that requires them.  The
+   Policy Framework WG is working on a way to describe policy [7].
+   Other implementations describe policy as a set of ACL lists.  Policy
+   definitions must be retrieved in order to be evaluated and enforced.
+   Policy Definitions can be indexed by requester, by service attribute,
+   or by some other key.  The organization requiring the policy is also
+   responsible for determining which policy is to be applied to a
+   specific authorization request.
+
+   Policy retrieval is typically done by the administration that defines
+   the policy or by an agent acting for that administration.  Thus a
+   policy defining the times of day that a particular User is allowed to
+   connect to the network is maintained and retrieved by the User
+   Organization.  A policy defining a time that ports will be unusable
+   because of maintenance is maintained and retrieved by the Service
+   Provider.
+
+   Note that some implementation may choose to have the Service Provider
+   retrieve a policy from the User Home Organization using a distributed
+   directory access protocol.  This may be appropriate in some cases,
+   but is not a general solution.  To understand why, suppose the remote
+   administration and the home administration communicate via a broker
+   which proxies their communications.  In this case the remote and home
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 16]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   administrations have no prior relationship, and therefore the home
+   administration directory is unlikely to be open for access by the
+   remote administration and vice versa.
+
+4.2.  Policy Evaluation
+
+   Evaluation of policy requires access to information referenced by the
+   policy.  Often the information required is not available in the
+   administration where the policy is retrieved.  For example, checking
+   that a user is allowed to login at the current time can readily be
+   done by the User Home Organization because the User Home Organization
+   has access to current time.  But authorizing a user requiring a 2Mb/s
+   path with less than 4 hops requires information available at a
+   Service Provider and not directly available to the UHO, so the UHO
+   must either 1) have a way to query a remote administration for the
+   needed information or 2) forward the policy to the remote
+   administration and have the remote administration do the actual
+   evaluation or 3) attempt somehow to "shadow" the authoritative source
+   of the information (e.g by having the Service Provider send updates
+   to the UHO).
+
+   Applications might support either 1) or 2), and a general
+   authorization protocol must allow both.  Case 3) is not considered
+   further as shadowing seems too "expensive" to be supported by an AAA
+   protocol.
+
+   An example of case 1 is when a Service Provider forwards a request to
+   a UHO which includes a query for the clearance code of the User.  The
+   Service Provider policy includes reference to the clearance code and
+   the information in the reply is used as input to that policy.
+
+   An example of case 2 is when the UHO approves an authorization
+   conditional on the Service Provider confirming that there is
+   currently a specific resource available for its use.  The UHO
+   includes the "policy" along with a conditional authorization to the
+   Service Provider.
+
+4.3.  Policy Enforcement
+
+   Policy Enforcement is typically done by the Service Provider on the
+   Service Equipment.  The Service Equipment is equivalent to the Policy
+   Target described in the Policy Framework [5].  Thus a NAS may enforce
+   destination IP address limits via "filters" and a Router may enforce
+   QoS restrictions on incoming packets.  The protocol that sends the
+   information between the Service Equipment and the Service Provider
+   AAA Server may be specific to the Service Equipment, but it seems
+   that the requirements are not different in kind from what is required
+   between other AAA servers.
+
+
+
+Vollbrecht, et al.           Informational                     [Page 17]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   In particular, an AAA Server could send a "policy" to the Service
+   Equipment stating what the equipment should do under various
+   situations.  The Service equipment should either set up to "enforce"
+   the policy or reject the request.
+
+   The AAA Server could also send a query to the Service Equipment for
+   information it requires to evaluate a policy.
+
+4.4.  Distributed Policy
+
+   A policy is retrieved by a Policy Retrieval Point (PRP) from a Policy
+   Repository, evaluated at a Policy Decision Point (PDP) or Policy
+   Consumer, and enforced at a Policy Enforcement Point (PEP) or Policy
+   Target [5].
+
+   Generally, any of the AAA Servers involved in an authorization
+   transaction may retrieve a policy or evaluate a policy, and any of
+   the Service Equipment may enforce a policy.  Policy Repositories may
+   reside on any of the AAA Servers or be located elsewhere in the
+   network.
+
+   Information against which policy conditions are evaluated (such as
+   resource status, session state, or time of day) are accessible at
+   Policy Information Points (PIPs) and might be accessed using Policy
+   Information Blocks (PIBs). An interesting question in any
+   authorization application that uses policy is where are the PDPs,
+   PRPs, PIPs  and PEPs?
+
+   Figure 12 shows which policy elements may be available at different
+   points in the model.  In distributed services, there may be multiple
+   Service Providers involved in the authorization transaction, and each
+   may act as the policy elements shown below.
+
+   Note that the User (or requester) may also be a PRP (e.g. use policy
+   description to specify what service is being requested), a PIP (have
+   information needed by other entities to evaluate their policy), and a
+   PDP (decide if it will accept a service with specific parameters).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 18]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+            +------+      +------------------------------+
+            |      |      | User Home Organization       |
+            |      |      |  +-------------------+  PRP  |
+            |      |      |  |    AAA Server     |  PIP  |
+            |      |      |  |                   |  PDP  |
+            |      |      |  +-------------------+       |
+            |      |      |                              |
+            |      |      +------------------------------+
+            |      |
+            |      |
+            |      |      +------------------------------+
+            | User |      | Service Provider             |
+            |      |      |  +-------------------+  PRP  |
+            | PRP  |      |  |    AAA Server     |  PIP  |
+            | PIP  |      |  |                   |  PDP  |
+            | PDP  |      |  +-------------------+       |
+            |      |      |                              |
+            |      |      |  +-------------------+       |
+            |      |      |  |      Service      |  PIP  |
+            |      |      |  |     Equipment     |  PEP  |
+            |      |      |  +-------------------+       |
+            |      |      |                              |
+            +------+      +------------------------------+
+
+              PRP = Policy Retrieval Point
+              PIP = Policy Information Point
+              PDP = Policy Decision Point
+              PEP = Policy Enforcement Point
+
+       Fig. 12 -- Where Different Policy Elements May be Located
+
+   An AAA protocol must be able to transport both policy definitions and
+   the information needed to evaluate policies.  It must also support
+   queries for policy information.
+
+5.  Use of Attribute Certificates to Store Authorization Data
+
+   This section outlines another mechanism that could be used for
+   securely transporting the attributes on which an authorization
+   decision is to be made.   Work on X.509 Attribute Certificates is
+   currently being undertaken in the Public Key Infrastructure (PKIX)
+   Working Group [8].  This proposal is largely based on that work.
+
+   When considering authorization using certificate-based mechanisms,
+   one is often less interested in the identity of the entity than in
+   some other attributes, (e.g. roles, account limits etc.), which
+   should be used to make an authorization decision.
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 19]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   In many such cases, it is better to separate this information from
+   the identity for management, security, interoperability or other
+   reasons. However, this authorization information may also need to be
+   protected in a fashion similar to a public key certificate.  The name
+   used here for such a structure is an Attribute Certificate (AC) which
+   is a digitally signed (certified) set of attributes.
+
+   An AC is a structure that is similar to an X.509 public key
+   certificate [9] with the main difference being that it contains no
+   public key.  The AC typically contains group membership, role,
+   clearance and other access control information associated with the AC
+   owner.  A syntax for ACs is also defined in the X.509 standard.
+
+   When making an access decision based on an AC, an access decision
+   function (in a PEP, PDP or elsewhere) may need to ensure that the
+   appropriate AC owner is the entity that has requested access.  The
+   linkage between the request and the AC can be achieved if the AC has
+   a "pointer" to a Public Key Certificate (PKC) for the requester and
+   that the PKC has been used to authenticate the request.  Other forms
+   of linkage can be defined which work with other authentication
+   schemes.
+
+   As there is often confusion about the difference between public key
+   certificates (PKC's) and attribute certificates (ACs), an analogy may
+   help. A PKC can be considered to be like a passport: it identifies
+   the owner, it tends to be valid for a long period, it is difficult to
+   forge, and it has a strong authentication process to establish the
+   owner's identity.  An AC is more like an entry visa in that it is
+   typically issued by a different authority than the passport issuing
+   authority, and it doesn't have as long a validity period as a
+   passport.  Acquiring an entry visa typically requires presenting a
+   passport that authenticates that owner's identity.  As a consequence,
+   acquiring the entry visa becomes a simpler procedure.  The entry visa
+   will refer to the passport as a part of how that visa specifies the
+   terms under which the passport owner is authorized to enter a
+   country.
+
+   In conjunction with authentication services, ACs provide a means to
+   transport authorization information securely to applications.
+   However, there are a number of possible communication paths that an
+   AC may take.
+
+   In some environments, it is suitable for a client to "push" an AC to
+   a server.  This means that no new connections between the client and
+   server domains are required.  It also means that no search burden is
+   imposed on servers, which improves performance.
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 20]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   In other cases, it is more suitable for a client simply to
+   authenticate to the server and for the server to request the client's
+   AC from an AC issuer or a repository.  A major benefit of the this
+   model is that it can be implemented without changes to the client and
+   client/server protocol.  It is also more suitable for some inter-
+   domain cases where the client's rights should be assigned within the
+   server's domain, rather than within the client's "home" domain.
+
+   There are a number of possible exchanges that can occur, and there
+   are three entities involved: client, server, and AC issuer.  In
+   addition the use of a directory service as a repository for AC
+   retrieval may be supported.
+
+   Figure 13 shows an abstract view of the exchanges that may involve
+   ACs. Note that the lines in the diagram represent protocols which
+   must be defined, not data flows.  The PKIX working group will define
+   the required acquisition protocols.  One candidate for the lookup
+   protocols is LDAP (once an LDAP schema exists which states where an
+   AC is to be found).
+
+      +--------------+                        +---------------+
+      |  AAA Server/ |                        |               |
+      |  AC Issuer   +----+                   |   Directory   |
+      |              |    |                   |               |
+      +--+-----------+    | Server            +-------+-------+
+         |                | Acquisition               |
+         |Client          |                           |Server
+         |Acquisition     +----------------------+    |Lookup
+         |                                       |    |
+      +--+-----------+                        +--+----+-------+
+      |              |     AC in application  |   Service     |
+      |     User     +------------------------+  Equipment/   |
+      |              |        protocol        | AAA Server    |
+      +--+-----------+                        +---------------+
+         |
+         | Client Lookup
+      +--+-----------+
+      |              |
+      |  Directory   |
+      |              |
+      +--------------+
+
+                       Fig. 13 -- AC Exchanges
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 21]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   Figure 14 shows the data flows which may occur in one particular
+   case, that termed "push" above (section 2.1.3).
+
+      +--------------+
+      |  AAA Server/ |
+      |  AC Issuer   |
+      |              |
+      +--+-----------+
+         |
+         |Client
+         |Acquisition (1)
+         |
+      +--+-----------+                        +---------------+
+      |              |     AC in application  |   Service     |
+      |     User     +------------------------+  Equipment/   |
+      |              |        protocol (2)    | AAA Server    |
+      +--------------+                        +---------------+
+
+              Fig. 14 -- One example of an AC exchange
+
+   In the diagram, the user first contacts the AC Issuer and then
+   incorporates the AC into the application protocol.  The Service
+   Equipment must then validate the AC and use it as the basis for the
+   access decision (this functionality may be distributed between a PEP
+   and PDP).
+
+6.  Resource Management
+
+   Authorization requests may be chained through a set of servers, as
+   described in previous sections.  Each of the servers may have a
+   contractual relationship with servers on either side of it in the
+   chain.  In many of the applications being considered, the
+   authorization results in establishing of an ongoing service which we
+   call a session.  Each of the servers involved in the authorization
+   may also want to keep track of the state of the session, and be able
+   to effect changes to the session if required.  To make it simple to
+   discuss this capability, we assume that each AAA Server MAY have a
+   Resource Manager component.  Resource Managers tracking the same
+   session need to be able to initiate changes to the session, and to
+   inform other Resource Managers when changes occur.  Communication
+   between Resource Managers creates requirements for an authorization
+   protocol.
+
+   An example of the use of resource management might be a user which
+   sets up a QoS path through two ISPs, and while this path is active,
+   one of the ISPs gets a request for more bandwidth from a higher
+   priority user.  The ISP may need to take some bandwidth from a the
+   lower priority user's previously allocated session and give it to the
+
+
+
+Vollbrecht, et al.           Informational                     [Page 22]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   new request.  To do this, each of the administrations in the
+   authorization path must be informed and agree to the change (this
+   could be considered to be "authorizing the new value").
+
+6.1.  Session Management and State Synchronization
+
+   When an AAA Server grants authorization of some resource to an AAA
+   requester (either a User or another AAA Server), the server may need
+   to maintain session state information.  This is used to make
+   decisions about new sessions based on the state of current sessions,
+   and to allow monitoring of sessions by all interested AAA Servers.
+
+   Each session is identified by a session identifier, which must be
+   unique within each AAA Server.  Communication between AAA Servers
+   must include the session identifier.  It is desirable that the
+   session identifier is the same across all AAA servers, otherwise each
+   server will have to map identifiers from other servers to its own
+   identifiers.  A single session identifier significantly simplifies
+   auditing and session control functions.
+
+   Maintaining session state across AAA administrative boundaries
+   increases the complexity of the problem, especially if each AAA
+   Server in the trust chain must keep state as well.  This can be
+   viewed as an interdomain database replication problem.  The protocol
+   must include tools to help manage replicated state.  Some of the
+   problems to be addressed are:
+
+   a) Service Equipment must be able to notify its Resource Manager when
+      a session terminates or changes state in some other way.  The
+      Resource Manager must inform other Resource Managers which keep
+      state for this session.
+
+   b) The Resource Manager will need to set a time limit for each
+      session which must be refreshed by having the Resource Manager
+      query for authoritative status or by having the authoritative
+      source send periodic keep alive messages that are forwarded to all
+      Resource Managers in the authorization chain.  Determining the
+      appropriate session lifetime may be application specific and
+      depends on the acceptable level of risk.  If the service being
+      offered is billed based on time, the session lifetime may need to
+      be relatively small; if the service is billed on usage, the
+      lifetime may be relatively large.
+
+   c) Any Resource Manager in the chain must have the ability to
+      terminate a session.  This requires the Resource Manager to have
+      knowledge of at least the adjacent AAA Servers in the
+      authorization chain.
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 23]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   An example of how resource management can be used is in the PPP
+   dialin application.  A home ISP may wish to restrict the number of
+   concurrent sessions that a user can have at any given time.  This is
+   particularly important when service providers give all-you-can-eat
+   Internet access.  The possibility for fraud is quite large, since a
+   user could provide his or her username/password to many people,
+   causing a loss of revenue.  Resource management would allow the home
+   ISP AAA server to identify when a user is active and to reject any
+   authorization request for the user until termination indication is
+   received from the NAS or until the session expires.
+
+6.2.  The Resource Manager
+
+   This section describes the functions of the Resource Manager in more
+   detail.
+
+   The Resource Manager is the component which tracks the state of
+   sessions associated with an AAA Server or Service Equipment.  It also
+   may allocate resources to a session (e.g. IP addresses) and may track
+   use of resources allocated by peer resource managers to a session
+   (e.g. bandwidth in a foreign administrative domain).  The resource
+   manager also provides interfaces to allow the User to acquire or
+   release authorized sessions.
+
+   The Resource Manager maintains all session specific AAA state
+   information required by the AAA Server.  That state information may
+   include pointers to peer Resource Managers in other administrative
+   domains that possess additional AAA state information that refers to
+   the same session.  The Resource Manager is the anchor point in the
+   AAA Server from which a session can be controlled, monitored, and
+   coordinated even if that session is consuming network resources or
+   services across multiple Service Provider administrative domains.
+
+   The Resource Manager has several important functions:
+
+   a) It allows a Service Provider operations staff to inspect the
+      status of any of the allocated resources and services including
+      resources that span foreign Service Provider administrative
+      boundaries.  The peer Resource Managers will cooperatively share
+      only the state information subset that is required to assist in
+      diagnosing cross-domain trouble tickets.  The network operator may
+      also modify or altogether cancel one of the User's active
+      authorizations.
+
+   b) It is the process contacted by other Resource Managers to inform
+      the AAA Server that a specific session has been cancelled.  This
+      information is relayed to the other peer Resource Managers that
+      also know about that session and hence must cancel it.
+
+
+
+Vollbrecht, et al.           Informational                     [Page 24]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   c) The Resource Manager conceals the identity and location of its
+      private internal AAA components from other administrative domains
+      and from the User, while at the same time facilitating cooperation
+      between those domains.
+
+   d) The Resource Manager cooperates with "policy servers" or Policy
+      Decision Points (PDPs).  The Resource Manager maintains internal
+      state information, possibly complex cross-administrative domain
+      information, supported by dialogues with its peer Resource
+      Managers.  A policy server can use the state information when
+      evaluating a particular policy.
+
+   e) The separation of the Resource Manager and the policy server into
+      two distinct architectural components allows a single session to
+      span multiple administrative domains, where each administrative
+      domain has one or more policy server cooperating with its Resource
+      Manager.
+
+   AAA resource managers will normally use the same trust relationships
+   needed for authorization sequences.  It is possible for independent
+   relationships to be established, but that is discouraged.
+
+7.  AAA Message Forwarding and Delivery
+
+   An AAA Server is responsible for securely forwarding AAA messages to
+   the correct destination system or process in the AAA infrastructure.
+   Two well known examples are forwarding AAA messages for a roaming AAA
+   service, and forwarding AAA messages for a distributed AAA service.
+   The same principle can also be applied to intra-domain
+   communications.  The message forwarding is done in one of two modes.
+
+   The first mode is when an AAA server needs to forward a message to a
+   peer AAA server that has a known "logical destination address" that
+   must be resolved by an application-specific procedure into its actual
+   network address.  Typically the forwarding procedure indexes into a
+   database by an application-specific identifier to discover the peer's
+   network address.  For example, in the roaming dialin application, the
+   application-specific identifier may be an NAI. A bandwidth brokerage
+   application would use other search indices unique to its problem
+   domain to select the addressed peer AAA server. After the address
+   resolution procedure has completed successfully, then the AAA server
+   transmits the message to its peer over the connection associated with
+   that destination network address.
+
+   The second mode is when the AAA server already has an established
+   session representing an authorization.  The session's state contains
+   the addressing and context used to direct the message to its
+   destination peer AAA server, PDP, PEP, or User.  The message is sent
+
+
+
+Vollbrecht, et al.           Informational                     [Page 25]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   over the AAA server's connection to that destination peer,
+   multiplexed with other session's messages. The message must be
+   qualified by a session identifier that is understood by both end
+   points.  The AAA message's destination may be either intra-
+   administrative domain, or inter-administrative domain.  In the former
+   case, the destination process may reside on the same system as the
+   AAA server.
+
+   In addition to the above message forwarding processing, the
+   underlying message delivery service must meet the following
+   requirements:
+
+   -  Unicast capability -- An end system can send a message to any
+      other end system with minimal latency of session setup/disconnect
+      overhead messages, and no end system overhead of keeping state
+      information about every potential peer.
+
+   -  Data integrity and error detection -- This data transport protocol
+      assumes an underlying datagram network layer service that includes
+      packet discard on error detection, and data integrity protection
+      against third party modifications.
+
+   -  Reliable data transport assurance -- When an end system
+      successfully receives a message marked receipt requested, it must
+      acknowledge that message to the sending system by either
+      piggybacking the acknowledgement on an application-specific reply
+      message, or else as a standalone acknowledgement message.  The
+      sending system maintains a retry timer; when the timer expires,
+      the sending system retransmits a copy of its original message. It
+      gives up after a configurable number of unsuccessful retries.
+
+   -  Sequenced data delivery -- If multiple messages are sent between a
+      pair of end systems, those messages are delivered to the addressed
+      application in the same order as they were transmitted.
+      Duplicates are silently suppressed.
+
+   -  Responsive to network congestion feedback -- When the network
+      enters into congestion, the end systems must detect that
+      condition, and they must back off their transmission rate until
+      the congestion subsides.  The back off and recovery algorithms
+      must avoid oscillations.
+
+8.  End-to-End Security
+
+   When AAA servers communicate through intermediate AAA servers, such
+   as brokers, it may be necessary that a part of the payload be secure
+   between the originator and the target AAA server.  The security
+   requirement may consist of one or more of the following: end-to-end
+
+
+
+Vollbrecht, et al.           Informational                     [Page 26]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   message integrity, confidentiality, replay protection, and
+   nonrepudiation.  Furthermore, it is a requirement that intermediate
+   AAA servers be able to append information such as local policy to a
+   message before forwarding the message to its intended destination.
+   It may also be required that an intermediate AAA Server sign such
+   appended information.
+
+   This requirement has been clearly documented in [10], which describes
+   many current weaknesses of the RADIUS protocol [11] in roaming
+   networks since RADIUS does not provide such functionality.  One
+   well-known attack is the ability for the intermediate nodes to modify
+   critical accounting information, such as a session time.
+
+   Most popular security protocols (e.g. IPSec, SSL, etc.) do not
+   provide the ability to secure a portion of the payload. Therefore, it
+   may be necessary for the AAA protocol to implement its own security
+   extensions to provide end-to-end security.
+
+9.  Streamlined Authorization Process
+
+   The techniques described above allow for great flexibility in
+   distributing the components required for authentication and
+   authorization.  However, working groups such as Roamops and MobileIP
+   have identified requirements to minimize Internet traversals in order
+   to reduce latency.  To support these requirements, data fields
+   necessary for both authentication and authorization SHOULD be able to
+   be carried in a single message set.  This is especially important
+   when there are intermediate servers (such as Brokers) in the AAA
+   chain.
+
+   Furthermore, it should be possible for the Brokers to allow end-to-
+   end (direct) authentication and authorization.  This can be done as
+   follows. The User Home Organization generates a ticket which is
+   signed using the UHO's private key.  The ticket is carried in the
+   accounting messages. The accounting messages must flow through the
+   Broker since the Broker is acting as the settlement agent and
+   requires this information.  There are Brokers that will require to be
+   in the authentication and authorization path as well since they will
+   use this information to detect fraudulent activity, so the above
+   should be optional.
+
+   In order for end-to-end authentication and authorization to occur, it
+   may be necessary for the Broker to act as a certificate authority.
+   All members of the roaming consortium would be able to trust each
+   other (to an extent) using the certificates.  A Service Provider's
+   AAA server that sends a request to the Broker should be able to
+   receive a redirect message which would allow the two peers (Service
+   Provider and UHO) to interact directly.  The redirect message from
+
+
+
+Vollbrecht, et al.           Informational                     [Page 27]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   the Broker should include the UHO's certificate, which eliminates the
+   Service Provider from accessing the certificate archive.  The request
+   from the Service Provider could include its own certificate, and a
+   token from the Broker's redirect message that is timestamped and
+   guarantees that the Service Provider is in good standing with the
+   Broker.  This eliminates the home domain from accessing the
+   Certificate Revocation List (CRL).
+
+10.  Summary of the Authorization Framework
+
+   The above has introduced the basic players in an authorization
+   transaction as User, User Home Organization, Service Provider's AAA
+   Server, and Service Equipment.  It has discussed relationships
+   between entities based on agreements or contracts, and on "trust".
+   Examples of authorization sequences have been given.
+
+   Concepts of roaming and distributed services have been briefly
+   described.  Combination of roaming and distributed services was also
+   considered and the concept of a "wholesaler" or Broker was
+   introduced. We have considered the use of policies and attribute
+   certificates to store and transmit authorization data.  We discussed
+   the problem of managing the resources to which access has been
+   authorized including the problem of tracking state information for
+   session-oriented services, and we defined the Resource Manager
+   component of a AAA Server.  We considered the problem of forwarding
+   AAA messages among servers in possibly different administrative
+   domains.  We considered the need for end-to-end security of portions
+   of the payload of authorization messages that pass through
+   intermediate AAA Servers.  Finally we stressed the need for support
+   of a streamlined authorization process that minimizes delay for
+   latency-sensitive applications.
+
+   The intent is that this will provide support for discussing and
+   understanding requirements of specific applications that need
+   authorization services.
+
+11.  Security Considerations
+
+   Authorization is itself a security mechanism.  As such, it is
+   important that authorization protocols cannot easily be abused to
+   circumvent the protection they are intended to ensure.  It is the
+   responsibility of protocol designers to design their protocols to be
+   resilient against well-known types of attacks.  The following are
+   some considerations that may guide protocol designers in the
+   development of authorization protocols.
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 28]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   Authorization protocols must not be susceptible to replay attacks.
+   If authentication data is carried with the authorization data, for
+   example, the authentication protocol used must either be impervious
+   to replay or else the confidentiality of the authentication data must
+   be protected.
+
+   If proxying is required, the authorization protocol must not be
+   susceptible to man-in-the-middle attacks.
+
+   If the push model is used, the confidentiality of the authorization
+   data must be ensured so that it may not be hijacked by third parties
+   and used to obtain a service fraudulently.
+
+   If the agent model is used, the binding between the authorization and
+   the service itself must be protected to prevent service authorized to
+   one party from being fraudulently received by another.
+
+   In addition to guarding against circumvention, authorization
+   protocols designed according to this framework will have some
+   intrinsic security requirements.  These are included among the
+   requirements in [2] and summarized briefly below.
+
+   Among the intrinsic security needs is the fact that authorization
+   protocols may carry sensitive information.  It is necessary to
+   protect such information from disclosure to unauthorized parties
+   including (as discussed in section 8) even certain parties involved
+   in the authorization decision.
+
+   We have discussed the use of multi-party trust chains involving
+   relaying of authorization data through brokers or other parties.  In
+   such cases, the integrity of the chain must be maintained.  It may be
+   necessary to protect the data exchanged between parties using such
+   mechanisms as encryption and digital signatures.
+
+   Finally, because authorization will be necessary to gain access to
+   many Internet services, a denial of service attack against an
+   authorization server can be just as effective as a denial of service
+   attack against the service equipment itself in preventing access to
+   Internet services.
+
+Glossary
+
+   Attribute Certificate -- structure containing authorization
+      attributes which is digitally signed using public key
+      cryptography.
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 29]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   Contract Relationship -- a relation established between two or more
+      business entities where terms and conditions determine the
+      exchange of goods or services.
+
+   Distributed Service -- a service that is provided by more than one
+      Service Provider acting in concert.
+
+   Dynamic Trust Relationship -- a secure relationship which is
+      dynamically created between two entities who may never have had
+      any prior relationship. This relationship can be created if the
+      involved entities have a mutually trusted third party. Example: A
+      merchant trusts a cardholder at the time of a payment transaction
+      because they both are known by a credit card organization.
+
+   Policy Decision Point (PDP) -- The point where policy decisions are
+      made.
+
+   Policy Enforcement Point (PEP) -- The point where the policy
+      decisions are actually enforced.
+
+   Resource Manager -- the component of an AAA Server which tracks the
+      state of sessions associated with the AAA Server or its associated
+      Service Equipment and provides an anchor point from which a
+      session can be controlled, monitored, and coordinated.
+
+   Roaming -- An authorization transaction in which the Service Provider
+      and the User Home Organization are two different organizations.
+      (Note that the dialin application is one for which roaming has
+      been actively considered, but this definition encompasses other
+      applications as well.)
+
+   Security Association -- a collection of security contexts, between a
+      pair of nodes, which may be applied to protocol messages exchanged
+      between them. Each context indicates an authentication algorithm
+      and mode, a secret (a shared key, or appropriate public/private
+      key pair), and a style of replay protection in use. [12]
+
+   Service Equipment -- the equipment which provides a service.
+
+   Service Provider -- an organization which provides a service.
+
+   Static Trust Relationship -- a pre-established secure relationship
+      between two entities created by a trusted party.  This
+      relationship facilitates the exchange of AAA messages with a
+      certain level of security and traceability. Example: A network
+      operator (trusted party) who has access to the wiring closet
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 30]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+      creates a connection between a user's wall outlet and a particular
+      network port.  The user is thereafter trusted -- to a certain
+      level -- to be connected to this particular network port.
+
+   User -- the entity seeking authorization to use a resource or a
+      service.
+
+   User Home Organization (UHO) -- An organization with whom the User
+      has a contractual relationship which can authenticate the User and
+      may be able to authorize access to resources or services.
+
+References
+
+   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [2]  Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross,
+        G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
+        Authorization Requirements", RFC 2906, August 2000.
+
+   [3]  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.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Stevens, M., "Policy Framework", Work in Progress.
+
+   [6]  Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core
+        Information Model -- Version 1 Specification", Work in Progress.
+
+   [7]  Strassner, John, et al, "Policy Framework LDAP Core Schema",
+        Work in Progress.
+
+   [8]  Farrell, Stephen and Russell Housley, "An Internet Attribute
+        Certificate Profile for Authorization", Work in Progress.
+
+   [9]  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
+        Public Key Infrastructure -- Certificate and CRL Profile", RFC
+        2459, January 1999.
+
+   [10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+        Implementation in Roaming", RFC 2607, June 1999.
+
+   [11] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+        Authentication Dial In User Service (RADIUS)", RFC 2138, April
+        1997.
+
+
+
+Vollbrecht, et al.           Informational                     [Page 31]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   [12] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
+
+   [13] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
+        Policy-based Admission Control", RFC 2753, January 2000.
+
+Authors' Addresses
+
+   John R. Vollbrecht
+   Interlink Networks, Inc.
+   775 Technology Drive, Suite 200
+   Ann Arbor, MI  48108
+   USA
+
+   Phone: +1 734 821 1205
+   Fax:   +1 734 821 1235
+   Mail: jrv@interlinknetworks.com
+
+
+   Pat R. Calhoun
+   Network and Security Research Center, Sun Labs
+   Sun Microsystems, Inc.
+   15 Network Circle
+   Menlo Park, California, 94025
+   USA
+
+   Phone:  +1 650 786 7733
+   Fax:    +1 650 786 6445
+   EMail:  pcalhoun@eng.sun.com
+
+
+   Stephen Farrell
+   Baltimore Technologies
+   61 Fitzwilliam Lane
+   Dublin 2
+   Ireland
+
+   Phone:  +353 1 647 7406
+   Fax:    +353 1 647 7499
+   EMail:  stephen.farrell@baltimore.ie
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 32]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   Leon Gommans
+   Enterasys Networks EMEA
+   Kerkplein 24
+   2841 XM  Moordrecht
+   The Netherlands
+
+   Phone: +31 182 379279
+   email: gommans@cabletron.com
+          or at University of Utrecht:
+          l.h.m.gommans@phys.uu.nl
+
+
+   George M. Gross
+   Lucent Technologies
+   184 Liberty Corner Road, m.s. LC2N-D13
+   Warren, NJ 07059
+   USA
+
+   Phone:  +1 908 580 4589
+   Fax:    +1 908-580-4991
+   Email:  gmgross@lucent.com
+
+
+   Betty de Bruijn
+   Interpay Nederland B.V.
+   Eendrachtlaan 315
+   3526 LB Utrecht
+   The Netherlands
+
+   Phone: +31 30 2835104
+   EMail: betty@euronet.nl
+
+
+   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
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 33]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+   Matt Holdrege
+   ipVerse
+   223 Ximeno Ave.
+   Long Beach, CA 90803
+
+   EMail: matt@ipverse.com
+
+
+   David W. Spence
+   Interlink Networks, Inc.
+   775 Technology Drive, Suite 200
+   Ann Arbor, MI  48108
+   USA
+
+   Phone: +1 734 821 1203
+   Fax:   +1 734 821 1235
+   EMail: dspence@interlinknetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 34]
+
+RFC 2904              AAA Authorization Framework            August 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vollbrecht, et al.           Informational                     [Page 35]
+