rfc2904.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

              |      |      |                         |
              +------+      +-------------------------+

                     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