rfc2904.txt

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

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