rfc2903.txt

中、英文RFC文档大全打包下载完全版 .

                                  v
                         +------------------+
                         |   Application    |
                         |     Specific     |
                         |      Module      |
                         +------------------+

       The numbers in the links denote types of communication.

              Fig. 2 -- Generic AAA Server Interactions

2.2.2.  Compatibility with Legacy Protocols

   Because of the widespread deployment of equipment that implements
   legacy AAA protocols and the desire to realize the functionality of
   the new AAA protocol while protecting the investment in existing
   infrastructure, it may be useful to implement a AAA gateway function
   that can encapsulate legacy protocol data units within the messages
   of the new protocol.  Use of this technique, for example, would allow
   Radius attribute value pairs to be encapsulated in Application
   Specific Information (ASI) units of the new protocol in such a way
   that the ASI units can be digitally signed and encrypted for end-to-
   end protection between a service provider's AAA server and a home AAA
   server communicating via a marginally trusted proxy AAA server.  The
   service provider's NAS would communicate via Radius to the service



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


   provider's AAA server, but the AAA servers would communicate among
   themselves via the new AAA protocol.  In this case, the AAA gateway
   would be a software module residing in the service provider's AAA
   server.  Alternatively the AAA gateway could be implemented as a
   standalone process.

   Figure 3 illustrates an AAA gateway.  Communication type 4 is the
   legacy protocol.  Communication type 1 is the future standard AAA
   protocol.  And communication type 2 is for application specific
   communication to Application Specific Modules (ASMs) or Service
   Equipment.

                    +-------+
                    |  AAA  |<---1---> to AAA server as in fig. 2
   request <---4--->|GateWay|
                    |       |<---2---> optionally to ASM/service
                    +-------+

   The numbers in the links denote types of communication.

               Fig. 3 -- AAA Gateway for Legacy AAA Protocols






























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


2.2.3.  Interaction between the ASM and the Service

   In a service provider, the Application Specific Module (ASM) and the
   software providing the service itself may be tightly bound into a
   single "Service Application".  In this case, the interface between
   them is just a software interface.  But the service itself may be
   provided by equipment external to the ASM, for example, a router in
   the bandwidth broker application.  In this case, the ASM communicates
   with the service via some protocol.  These two possibilities are
   illustrated in figure 4.  In both cases, we have labeled the
   communication between the ASM and the service as communication type
   5, which of course, is service specific.

                            |                  |
             +--------------|----+             |
             | Service      2    |             2
             | Application  |    |             |
             |  +-------------+  |      +-------------+
             |  | Application |  |      | Application |
             |  |  Specific   |  |      |  Specific   |
             |  |   Module    |  |      |   Module    |
             |  +-------------+  |      +-------------+
             |         |         |             |
             |         5         |             5
             |         |         |             |
             |  +-------------+  |      +-------------+
             |  |   Service   |  |      |   Service   |
             |  |             |  |      |  Equipment  |
             |  +-------------+  |      +-------------+
             +-------------------+

          Fig. 4 -- ASM to Service Interaction (two views)



















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


2.2.4.  Multi-domain Architecture

   The generic AAA server modules can use communication type 1 to
   contact each other to evaluate parts of requests.  Figure 5
   illustrates a network of generic AAA servers in different
   administrative domains communicating via communication type 1.

                                                  +-----+
                                         o--------| AAA |---->...
                                        /         |     |
                                       /          +-----+\
                                      /              |    \+----+
                                     /            +-----+  | RP |
                                    /             | ASM |  +----+
    +--------+      +-----+        /              |     |
    | Client |------| AAA |-------o               +-----+
    +--------+      |     |        \
                    +-----+        \
                       |    +----+  \      +-----+
                    +-----+  | RP |   o-----| AAA |---->...
                    | ASM |  +----+         |     |
                    |     |                 +-----+\
                    +-----+                    |    \+----+
                                            +-----+  | RP |
                                            | ASM |  +----+
                                            |     |
                                            +-----+

      The AAA servers use only communication type 1 to communicate.
      ASM = Application Specific Module
      RP  = Repository

      Fig. 5 -- Multi-domain Multi-type of Service Architecture

2.3.  Model Observations

   Some key points of the generic architecture are:

   1) The same generic AAA server can function in all three
      authorization models: agent, pull, and push [2].

   2) The rule based engine knows how to evaluate logical formulas and
      how to parse AAA requests.

   3) The Generic AAA server has no knowledge whatsoever about the
      application specific services so the application specific
      information it forwards is opaque to it.




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


   4) Communication types 1, 2, and 3 each present their own naming
      space problems.  Solving these problems is fundamental to
      forwarding AAA messages, locating application specific entities,
      and locating applicable rules in the rule repositories.

   5) A standard AAA protocol for use in communication type 1 should be
      a peer-to-peer protocol without imposing client and server roles
      on the communicating entities.

   6) A standard AAA protocol should allow information units for
      multiple different services belonging to multiple different
      applications in multiple different administrative domains to be
      combined in a single AAA protocol message.

2.4.  Suggestions for Future Work

   It is hoped that by using this generic model it will be feasible to
   design a AAA protocol that is "future proof", in a sense, because
   much of what we do not think about now can be encoded as application
   specific information and referenced by policy rules stored in a
   policy repository.  From this model, some generic requirements arise
   that will require some further study.  For example, suppose a new
   user is told that somewhere on a specific AAA server a certain
   authorization can be obtained.  The user will need a AAA protocol
   that can:

   1) send a query to find out which authorizations can be obtained from
      a specific server,

   2) provide a mechanism for determining what components must be put in
      an AAA request for a specific authorization, and

   3) formulate and transmit the authorization request.

   Some areas where further work is particularly needed are in
   identifying and designing the generic components of a AAA protocol
   and in determining the basis upon which component forwarding and
   policy retrieval decisions are made.

   In addition to these areas, there is a need to explore the management
   of rules in a multi-domain AAA environment because the development
   and future deployment of a generic multi-domain AAA infrastructure is
   largely dependent on its manageability.  Multi-domain AAA
   environments housing many rules distributed over several AAA servers
   quickly become unmanageable if there is not some form of automated
   rule creation and housekeeping.  Organizations that allow their
   services to be governed by rules, based on some form of commercial
   contract, require the contract to be implemented with the least



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


   possible effort.  This can, for example, be achieved in a scalable
   fashion if the individual user or user organization requesting a
   service is able to establish the service itself.  This kind of
   interaction requires policy rule establishment between AAA servers
   belonging to multiple autonomous administrative domains.

3.  Layered AAA Protocol Model

   In the previous section, we proposed the idea of a generic AAA server
   with an interface to one or more Application Specific Modules (ASMs).
   The generic server would handle many common functions including the
   forwarding of AAA messages between servers in different
   administrative domains.  We envision message transport, hop-by-hop
   security, and message forwarding as clearly being functions of the
   generic server.  The application specific modules would handle all
   application specific tasks such as communication with service
   equipment and access to special purpose databases.  Between these two
   sets of functions is another set of functions that presumably could
   take place in either the generic server or an ASM or possibly by a
   collaboration of both.  These functions include the evaluation of
   authorization rules against data that may reside in various places
   including attributes from the authorization request itself.  The more
   we can push these functions down into the generic server, the more
   powerful the generic server can be and the simpler the ASMs can be.

   One way of organizing the different functions mentioned above would
   be to assign them to a layered hierarchy.  In fact, we have found the
   layer paradigm to be a useful one in understanding AAA functionality.
   This section explores the use of a layered hierarchy consisting of
   the following AAA layers as a way of organizing the AAA functions:

         Application Specific Service Layer
         Presentation Service Layer
         Transaction/Session Management Service Layer
         Reliable/Secure Transport Service Layer

   Nevertheless, the interface between the generic AAA server and the
   ASMs proposed in the previous section may be more complex than a
   simple layered model would allow.  Even the division of functionality
   proposed in this section goes beyond a strict understanding of
   layering.  Therefore this paper can probably best be understood as
   the beginnings of a work to understand and organize the common
   functionality required for a general purpose AAA infrastructure
   rather than as a mature reference model for the creation of AAA
   protocols.






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


   In our view of AAA services modeled as a hierarchy of service layers,
   there is a set of distributed processes at each service layer that
   cooperate and are responsible for implementing that service layer's
   functions.  These processes communicate with each other using a
   protocol specialized to carry out the functions and responsibilities
   assigned to their service layer.  The protocol at service layer n
   communicates to its peers by depending on the services available to
   it from service layer n-1.  The service layer n also has a protocol
   end point address space, through which the peer processes at service
   layer n can send messages to each other.  Together, these AAA service
   layers can be assembled into an AAA protocol stack.

   The advantage of this approach is that there is not just one
   monolithic "AAA protocol".  Instead there is a suite of protocols,
   and each one is optimized to solve the problems found at its layer of
   the AAA protocol stack hierarchy.

   This approach realizes several key benefits:

   -  The protocol used at any particular layer in the protocol stack
      can be substituted for another functionally equivalent protocol
      without disrupting the services in adjacent layers.

   -  Requirements in one layer may be met without impact on protocols
      operating in other layers.  For example, local security
      requirements may dictate the substitution of stronger or weaker
      "reliable secure transport" layer security algorithms or
      protocols.  These can be introduced with no change or awareness of
      the substitution by the layers above the Reliable/Secure Transport
      layer.

   -  The protocol used for a given layer is simpler because it is
      focused on a specific narrow problem that is assigned to its
      service layer. In particular, it should be feasible to leverage
      existing protocol designs for some aspects of this protocol stack
      (e.g. CORBA GIOP/CDR for the presentation layer).

   -  A legacy AAA protocol message (e.g. a RADIUS message) can be
      encapsulated within the protocol message(s) of a lower layer
      protocol, preserving the investment of a Service Provider or User
      Home Organization in their existing AAA infrastructure.

   -  At each service layer, a suite of alternatives can be designed,
      and the service layer above it can choose which alternative makes
      sense for a given application.  However, it should be a primary
      goal of the AAA protocol standardization effort to specify one
      mandatory to implement protocol at the AAA Transaction/Session
      Management (AAA-TSM) service layer (see section 3.4).



de Laat, et al.               Experimental                     [Page 13]