rfc2904.txt

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

   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