rfc2903.txt

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


RFC 2903                Generic AAA Architecture             August 2000


3.1.  Elements of a Layered Architecture

   At each layer of a layered architecture, a number of elements need to
   be defined.  These elements are discussed in the following sections.

3.1.1.  Service Layer Abstract Interface Primitives

   The service layer n is assumed to present a program interface through
   which its adjacent service layer n+1 can access its services.  The
   types of abstract program service primitives and associated
   parameters exchanged across the boundary between these service layers
   must be specified.

3.1.2.  Service Layer Peer End Point Name Space

   Each service layer is treated as a set of cooperating processes
   distributed across multiple computing systems.  The service layer
   must manage an end point name space that identifies these peer
   processes.  The conventions by which a service layer assigns a unique
   end point name to each such peer process must be specified.

3.1.3.  Peer Registration, Discovery, and Location Resolution

   Along with defining an end point name space, a service layer must
   also specify how its peers:

   -  announce their presence and availability,

   -  discover one another when they first begin operation, and

   -  detect loss of connectivity or service withdrawal.

   It is also necessary to specify what mechanisms, if any, exist to
   resolve a set of service layer specific search attributes into one or
   more peer end point names that match the search criteria.

3.1.4.  Trust Relationships Between Peer End Points

   Once an end point has established its initial contact with another
   peer, it must decide what authentication policy to adapt.  It can
   trust whatever authentication was done on its behalf by a lower
   service layer or, through a pre-provisioning process, implicitly
   trust the peer, or else go through an authentication process with its
   peer.  The supported mechanisms for establishing a service layer's
   end point trust relationships must be specified.






de Laat, et al.               Experimental                     [Page 14]

RFC 2903                Generic AAA Architecture             August 2000


3.1.5.  Service Layer Finite State Machine

   To the extent that a service layer's internal states are externally
   visible, the layer's behavior in terms of a Finite State Machine
   (FSM) should be specified.  Events that can drive the FSM state
   transitions may include:

   -  service layer n+1 interface primitive requests

   -  protocol data unit arrivals from peer service layer n end points
      received through the layer n-1 access point

   -  service layer n-1 interface primitives (e.g. call backs or
      interrupts)

   -  timer expirations

3.1.6.  Protocol Data Unit Types

   Each service layer defines a lexicon of protocol data units (PDUs)
   that communicate between the layer's peer processes the information
   that controls and/or monitors that service layer's distributed state
   and allows the service processes of that layer to perform their
   functions.  Embedded in the PDUs of each layer are the PDUs of the
   higher layers which depend on its services.  The PDUs of each service
   layer must be specified.

3.2.  AAA Application Specific Service Layer

   AAA applications have almost unlimited diversity, but imposing some
   constraints and commonality is required for them to participate in
   this generic AAA architectural framework.  To satisfy these
   constraints, participating AAA applications would derive their
   application specific program logic from a standardized "Authorization
   Server" abstract base object class.  They would also support an
   "Authorized Session" object class.  An Authorization Session object
   instance represents an approved authorization request that has a
   long-lived allocation of services or resources.  The generic AAA
   architecture could be extended to include other abstract base object
   classes in the future (e.g. Authorization Reservation, Authentication
   Server, etc.).  How to implement the derived Authorization Server
   class's public methods for a given problem domain is entirely up to
   the application.  One technique might be to place a software
   "wrapper" around an existing embedded application specific service to
   adapt it to the standardized Authorization Server object paradigm.
   The major Authorization Server class methods are:





de Laat, et al.               Experimental                     [Page 15]

RFC 2903                Generic AAA Architecture             August 2000


   -  Publish an advertisement that describes the Authorization Server's
      service attributes and its application specific service layer end
      point address.  Once the Authorization Server has registered, peer
      processes can discover its presence or send messages addressed to
      it.

   -  Application Specific Authorization Decision Function (AS-ADF)
      method takes a User's application specific authorization request
      and returns a decision of approve, deny, or conditionally approve
      with referral to another stakeholder.  In the latter case, the
      application may create a reservation for the requested services or
      resources.  This method represents the "condition" side of a
      policy rule's condition/action pair.

   -  Commit a service or set of resources to a previously conditionally
      approved authorization decision.  For those authorization requests
      that have a long-term lifecycle (as opposed to being
      transactions), this method mobilizes a reservation into an
      Authorized Session object instance.  This method represents the
      "action" side of a policy rule's condition/action pair.

   -  Cancel a previously conditionally approved Authorization request.
      This method releases any associated reservations for services or
      resources.

   -  Withdraw the Authorization Server's service advertisement.

   A key motivation for structuring an AAA application as an
   Authorization Server object instance is to separate the generic
   authorization decision logic from the application-specific
   authorization decision logic.  In many cases, the application can be
   divorced from the AAA problem altogether, and its AAA responsibility
   can be assigned to an external rules based generic AAA Server.  (The
   idea is similar to that of a trust management policy server as
   defined in [5].)  This would facilitate a security administrator
   deploying AAA policy in a central repository.  The AAA policy is
   applied consistently across all users of the applications, resources,
   and services controlled by the AAA server.  However, it is recognized
   that for many problem domains, there are unique rules intrinsic to
   the application.  In these cases, the generic AAA Server must refer
   the User's authorization request to the relevant Application Specific
   Module.

3.3.  Presentation Service Layer

   The presentation service layer solves the data representation
   problems that are encountered when communicating peers exchange
   complex data structures or objects between their heterogeneous



de Laat, et al.               Experimental                     [Page 16]

RFC 2903                Generic AAA Architecture             August 2000


   computing systems.  The goal is to transfer semantically equivalent
   application layer data structures regardless of the local machine
   architecture, operating system, compiler, or other potential inter-
   system differences.

   One way to better understand the role of the presentation layer is to
   evaluate an existing example.  The Generic Inter-ORB Protocol (GIOP)
   and its Common Data Representation (CDR) is a presentation service
   layer protocol developed by the Object Management Group (OMG)
   industry consortium.  GIOP is one component within the Common Object
   Request Broker Architecture (CORBA).  Peer Object Request Brokers
   (ORB) executing on heterogeneous systems use GIOP to invoke remote
   CORBA object interface methods.  GIOP encodes an object method's
   input and output parameters in the Common Data Representation (CDR).
   While there are other presentation service layer protocols in the
   industry, GIOP in combination with CDR represents a mature,
   comprehensive solution that exhibits many of the presentation service
   layer requirements that are applicable within the AAA protocol model.

   In the context of Internet access AAA protocols, RADIUS and its
   successors use the Attribute Value Pair (AVP) paradigm as the
   presentation service layer encoding scheme.  While such an approach
   is versatile, it is also prone to becoming splintered into many ad
   hoc and vendor specific dialects.  There is no structure imposed or
   method to negotiate the constraints on which AVPs are combined and
   interpreted for a given conversation in a consistent way across AAA
   protocol implementations or problem domains.  At run-time, it can be
   hard for the communicating peers to negotiate to a common inter-
   operable set of AVPs.

   To avoid this pitfall, a primary presentation service layer
   responsibility is the ability to let peers negotiate from a base
   Authorization Server object class towards a commonly understood
   derived Authorization Server object class that both presentation
   service layer peers have implemented for their application specific
   problem domain.  This negotiation implies a requirement for a
   globally registered and maintained presentation service layer
   hierarchy of Authorization Server object class names.

3.4.  AAA Transaction/Session Management Service Layer

   The AAA Transaction/Session Management (AAA-TSM) service layer is a
   distributed set of AAA Servers, which typically reside in different
   administrative domains.  Collectively they are responsible for the
   following three services:






de Laat, et al.               Experimental                     [Page 17]

RFC 2903                Generic AAA Architecture             August 2000


   Authentication -- Execute the procedure(s) needed to confirm the
      identity of the other parties with which the AAA TSM entity has a
      trust relationship.

   Authorization -- Make an authorization decision to grant or deny a
      User's request for services or resources.  The generic rules based
      policy engine described earlier in this document executes the
      authorization decision function.  When the User's request is
      instantaneous and transient, then its authorization approval is
      treated as an ephemeral transaction.  If the authorization
      approval implies a sustained consumption of a service or
      resources, then the request is transformed into an Authorized
      Session.  For the duration of the Authorized Session's lifetime:

      -  its state may be queried and reported, or

      -  it may be canceled before service is completed, or

      -  the service being delivered may be modified to operate under
         new parameters and conditions, or

      -  the service may complete on its own accord.

      In each of these cases, the AAA-TSM service layer must synchronize
      the Authorized Session's distributed state across all of those AAA
      Servers which are implementing that specific Authorized Session.

   Accounting -- Generate any relevant accounting information regarding
      the authorization decision and the associated Authorized Session
      (if any) that represents the ongoing consumption of those services
      or resources.

   The peer AAA servers and their AAA-TSM end points exchange AAA-TSM
   messages to realize these AAA functions.  A central AAA-TSM concept
   is that there is a set of one or more AAA Server stakeholders who are
   solicited to approve/disapprove a User request for application layer
   services.  The AAA-TSM service layer routes the User's request from
   one stakeholder to the next, accumulating the requisite approvals
   until they have all been asked to make an authorization decision.

   The AAA Servers may also do User authentication (or re-
   authentication) as part of this approval process.  The overall flow
   of the routing from one stakeholder to another may take the form of
   the "push", "pull", or "agent" authorization models developed in [2].
   However, in principle, it is feasible to have an arbitrary routing
   path of an AAA-TSM authorization request among stakeholders. Once the
   final approval is received, the AAA-TSM service layer commits the
   requested service by notifying all of those stakeholders that require



de Laat, et al.               Experimental                     [Page 18]

RFC 2903                Generic AAA Architecture             August 2000


   a confirmation (i.e. turn on a pending reservation and do a
   transaction commit).  Alternatively, any stakeholder among those on
   the consent list can veto the authorization request.  In that case,
   all stakeholders who previously approved the request and had asked
   for a confirmation are told that the request has been denied (i.e.,
   cancel reservation and do a transaction rollback).

   The AAA-TSM authorization request payload must carry its own "Context
   State", such that when an AAA server receives it, there is sufficient
   information that it is essentially self-contained.  Embedding the
   Context State within the AAA-TSM message provides two benefits.
   First, the message can be immediately processed with respect to the
   AAA Server's local policy, and this minimizes or altogether avoids
   the need for the AAA Server to exchange additional AAA-TSM messages
   with its peers to complete its piece of the overall authorization
   decision.  The other benefit is that the AAA Server minimizes the
   amount of state information resources that it commits to a user's
   pending request until it is fully approved.  This helps protect
   against denial of service attacks.

   One can envision many possible message elements that could be part of
   the Context State carried within an AAA-TSM request message:

   -  AAA-TSM session identifier, a unique handle representing this
      authorization request.  All AAA servers who participate in a
      request's approval process and its subsequent monitoring
      throughout its Session lifetime refer to this handle.

   -  permission lists stating which AAA Servers are allowed to modify
      which parts of the message.

   -  User's authorization request, encoded as a presentation layer PDU.

   -  User authentication information, (e.g. an X.509 public key
      certificate).

   -  User credentials information, or else a pointer to where that
      information can be found by an AAA server. An example of such
      credentials would be an X.509 attributes certificate.

   -  the list of AAA Server stakeholders who have yet to be visited to
      gain full approval of the User's authorization request.  Each
      element in that list contains a presentation layer message
      encoding how the user authorization request should be evaluated by
      its application specific Authorization Decision Function (ADF).

   -  the current position in the list of AAA Server stakeholders to be
      visited.



de Laat, et al.               Experimental                     [Page 19]

RFC 2903                Generic AAA Architecture             August 2000


   -  a list of those AAA servers which have already conditionally
      approved the User's authorization request, but which have
      predicated their approval on the request also completing its
      approval from those stakeholders who have not yet seen the
      request.  Each element in the list has a digital signature or
      comparable mechanism by which their approval can be subsequently
      verified.

   -  an expiration time stamp, expressed in a universally understood
      time reference, which sets a lifetime limit on the AAA-TSM
      message's validity.  This offers some replay attack protection,
      and inhibits messages from circulating indefinitely seeking the
      completion of a request's approval.

   -  a message payload modification audit trail, tracing which parties
      introduced changes into the User's authorization request terms and
      conditions.

   -  an AAA-TSM message integrity check, computed across the whole
      message rather than its individual elements, and signed by the
      most recent AAA-TSM layer end point process to modify the AAA-TSM
      message before its transmission to its AAA-TSM peer.  This
      function may be delegated to the underlying Reliable Secure
      Transport layer connection to that destination peer.