rfc2903.txt

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

Network Working Group                                         C. de Laat
Request for Comments: 2903                            Utrecht University
Category: Experimental                                          G. Gross
                                                     Lucent Technologies
                                                              L. Gommans
                                                 Enterasys Networks EMEA
                                                           J. Vollbrecht
                                                               D. Spence
                                                Interlink Networks, Inc.
                                                             August 2000


                        Generic AAA Architecture

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo proposes an Authentication, Authorization, Accounting (AAA)
   architecture that would incorporate a generic AAA server along with
   an application interface to a set of Application Specific Modules
   that could perform application specific AAA functions.  A separation
   of AAA functions required in a multi-domain environment is then
   proposed using a layered protocol abstraction.  The long term goal is
   to create a generic framework which allows complex authorizations to
   be realized through a network of interconnected AAA servers.
















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


Table of Contents

   1. Introduction ................................................  2
   2. Generic AAA Architecture ....................................  4
      2.1. Architectural Components of a Generic AAA Server .......  4
           2.1.1. Authorization Rule Evaluation ...................  4
           2.1.2. Application Specific Module (ASM) ...............  5
           2.1.3. Authorization Event Log .........................  6
           2.1.4. Policy Repository ...............................  6
           2.1.5. Request Forwarding ..............................  6
      2.2. Generic AAA Server Model ...............................  6
           2.2.1. Generic AAA Server Interactions .................  7
           2.2.2. Compatibility with Legacy Protocols .............  7
           2.2.3. Interaction between the ASM and the Service .....  9
           2.2.4. Multi-domain Architecture ....................... 10
      2.3. Model Observations ..................................... 10
      2.4. Suggestions for Future Work ............................ 11
   3. Layered AAA Protocol Model .................................. 12
      3.1. Elements of a Layered Architecture ..................... 14
           3.1.1. Service Layer Abstract Interface Primitives ..... 14
           3.1.2. Service Layer Peer End Point Name Space ......... 14
           3.1.3. Peer Registration, Discovery, and Location
           Resolution ............................................. 14
           3.1.4. Trust Relationships Between Peer End Points ..... 14
           3.1.5. Service Layer Finite State Machine .............. 15
           3.1.6. Protocol Data Unit Types ........................ 15
      3.2. AAA Application Specific Service Layer ................. 15
      3.3. Presentation Service Layer ............................. 16
      3.4. AAA Transaction/Session Management Service Layer ....... 17
      3.5. AAA-TSM Service Layer Program Interface Primitives ..... 20
      3.6. AAA-TSM Layer End Point Name Space ..................... 21
      3.7. Protocol Stack Examples ................................ 22
   4. Security Considerations ..................................... 22
   Glossary ....................................................... 23
   References ..................................................... 24
   Authors' Addresses ............................................. 24
   Full Copyright Statement ....................................... 26

1.  Introduction

   The work for this memo was done by a group that originally was the
   Authorization subgroup of the AAA Working Group of the IETF.  When
   the charter of the AAA working group was changed to focus on MobileIP
   and NAS requirements, the AAAarch Research Group was chartered within
   the IRTF to continue and expand the architectural work started by the
   Authorization subgroup.  This memo is one of four which were created
   by the subgroup.  This memo is a starting point for further work
   within the AAAarch Research Group.  It is still a work in progress



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


   and is published so that the work will be available for the AAAarch
   subgroup and others working in this area, not as a definitive
   description of architecture or requirements.

   The authorization subgroup of the AAA Working Group proposed an "AAA
   Authorization Framework" [2] illustrated with numerous application
   examples [3] which in turn motivates a proposed list of authorization
   requirements [4].  This memo builds on the framework presented in [2]
   by proposing an AAA infrastructure consisting of a network of
   cooperating generic AAA servers communicating via a standard
   protocol.  The protocol should be quite general and should support
   the needs of a wide variety of applications requiring AAA
   functionality.  To realize this goal, the protocol will need to
   operate in a multi-domain environment with multiple service providers
   as well as entities taking on other AAA roles such as User Home
   Organizations and brokers.  It should be possible to combine requests
   for multiple authorizations of different types in the same
   authorization transaction.  The AAA infrastructure will be required
   to forward the components of such requests to the appropriate AAA
   servers for authorization and to collect the authorization decisions
   from the various AAA servers consulted.  All of this activity is
   perfectly general in nature and can be realized in the common
   infrastructure.

   But the applications requiring AAA services will each have their own
   unique needs.  After a service is authorized, it must be configured
   and initialized.  This will require application specific knowledge
   and may require application specific protocols to communicate with
   application specific service components.  To handle these application
   specific functions, we propose an application interface between a
   generic AAA server and a set of one or more Application Specific
   Modules (ASMs) which can carry out the unique functionality required
   by each application.

   Since the data required by each application for authentication,
   authorization, or accounting may have unique structure, the standard
   AAA protocol should allow the encapsulation of opaque units of
   Application Specific Information (ASI).  These units would begin with
   a standard header to allow them to be forwarded by the generic
   infrastructure.  When delivered to the final destination, an ASI unit
   would be passed by a generic AAA server across its program interface
   to an appropriate ASM for application specific processing.
   Nevertheless, it remains a goal of the design for information units
   to be encoded in standard ways as much as possible so as to enable
   processing by a generic rule based engine.






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


   The interactions of the generic AAA server with the Application
   Specific Modules and with each other to realize complex AAA functions
   is explored in section 2.  Then, in section 3, we attempt to further
   organize the AAA functions into logical groups using a protocol
   layering abstraction.  This abstraction is not intended to be a
   reference model ready to be used for protocol design.  At this point
   in the work, there are numerous questions that need to be addressed
   and numerous problems that remain to be solved.  It may be that an
   abstraction other than layering will prove to be more useful or, more
   likely, that the application layer will require some substructure of
   its own.

   Finally, in section 4, we show how the security requirements
   identified in [4] can be met in the generic server and the
   Application Specific Modules by applying security techniques such as
   public key encryption or digital signatures to the Application
   Specific Information units individually, so that different
   stakeholders in the AAA server network can protect selected
   information units from being deciphered or altered by other
   stakeholders in an authentication, authorization, or accounting
   chain.

2.  Generic AAA Architecture

   For the long term we envision a generic AAA server which is capable
   of authenticating users, handling authorization requests, and
   collecting accounting data.  For a service provider, such a generic
   AAA server would be interfaced to an application specific module
   which manages the resource for which authorization is required.
   Generic AAA components would also be deployed in other administrative
   domains performing authorization functions.

2.1.  Architectural Components of a Generic AAA Server

2.1.1.  Authorization Rule Evaluation

   The first step in the authorization process is for the user or an
   entity operating on the user's behalf to submit a well-formatted
   request to an AAA server.  A generic AAA server has rules (logic
   and/or algebraic formulas) to inspect the request and come to an
   authorization decision.  The first problem which arises is that
   Application Specific Information (ASI) has to be separated from the
   underlying logic for the authorization.  Ideally the AAA server would
   have a rule based engine at this point which would know the logic
   rules and understand some generic information in the request, but it
   would not know anything about application specific information except
   where this information can be evaluated to give a boolean or
   numerical value.  It should be possible to create rules that refer to



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


   data elements that were not considered when the application was
   created.  For example, one could request to do a remote virtual
   control room experiment from home using a dialin provider. The
   request would only be successful if the dialin access server allows
   it and if there is bandwidth available (bandwidth broker) and if the
   experimenter has the money to pay for it (E-Commerce).  Possibly the
   people who specified the bandwidth broker protocol did not think of
   combining quality of service with a network service authorization in
   a single AAA request, but this generic model would allow it.

   +------+      +-------+      +-------+      +-------+      +-------+
   |      | auth |       | auth |       | auth |       | auth |       |
   |      |<---->|  AAA  |<---->|  AAA  |<---->|  AAA  |<---->|  AAA  |
   |      |      |       |      |       |      |       |      |       |
   |      |      +-------+      +-------+      +-------+      +-------+
   | User |          |              |              |              |
   |      |          |          +-------+      +-------+      +-------+
   |      |          |          |  BB   |      |  BB   |      |Budget |
   |      |          |          +-------+      +-------+      +-------+
   |      |          |              |              |
   |      |      +-------+          |              |
   |      |      |dial in|      +-------+      +-------+
   |      |<====>|service|<====>|network|<====>|network|<===> Experiment
   +------+      +-------+      +-------+      +-------+

     user <-> dialin <-> backbone with BB <-> <remote experiment>

     Fig. 1 -- Example of a Multi Domain Multi Type of Server Request

2.1.2.  Application Specific Module (ASM)

   Ultimately an AAA server needs to interact with an application
   specific module (ASM).  In a service provider, the ASM would manage
   resources and configure the service equipment to provide the
   authorized service.  It might also involve itself in the
   authorization decision because it has the application specific
   knowledge required.  A user home organization (UHO) may require ASMs
   as well, to perform application specific user authorization
   functions.  For example, a UHO ASM might be required to access
   certain application specific databases or interpret application
   specific service level specifications.

   Whatever the role of an administration relative to an authorization
   decision,  the capabilities of the generic AAA server and the
   interface between it and the ASMs remains the same.  This interface
   may be an Application Program Interface (API) or could even be a
   protocol based interface.  In this model, however, the application




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


   specific module is regarded as as separate architectural component
   from the generic AAA server.  As such, it must be addressable and
   must therefore be part of a global naming space.

2.1.3.  Authorization Event Log

   For auditing purposes, the generic server must have some form of
   database to store time-stamped events which occur in the AAA server.
   This database can be used to account for authorizations which were
   given, but it can also be used in rules.  One can imagine rules in
   which an authorization is only given if some other event was logged
   in the past.  With the aid of certificates, this database could
   support non-repudiation.

2.1.4.  Policy Repository

   A database containing the available services and resources about
   which authorization decisions can be made and the policy rules to
   make them is also needed.  Here too, the naming space for the
   services and resources is important since they must be addressable
   from other AAA servers to be able to build complex authorization
   requests.

2.1.5.  Request Forwarding

   Due to the multiple administrative domain (multi-kingdom) nature of
   the AAA problem, a mechanism to forward messages between AAA servers
   is needed.  The protocol by which two AAA servers communicate should
   be a peer-to-peer protocol.

2.2.  Generic AAA Server Model

   With the implementation of the above mentioned components, the AAA
   server would be able to handle AAA requests.  It would inspect the
   contents of the request, determine what authorization is requested,
   retrieve the policy rules from the repository, perform various local
   functions, and then choose one of the following options to further
   process each of the components of the request:

   a) Let the component be evaluated by an attached ASM.

   b) Query the authorization event log or the policy repository for the
      answer.

   c) Forward the component(s) to another AAA server for evaluation.

   In the following sections we present the generic model.




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


2.2.1.  Generic AAA Server Interactions

   Figure 2 illustrates a generic AAA Server with connections to the
   various architectural components described above. In this model, the
   user or another AAA server contacts the AAA server to get
   authorization, and the AAA server interacts with the service.  The
   request is sent to the AAA server using the future AAA protocol.  The
   server interacts with the service via a second protocol which we have
   labeled as type "2" in the figure.  We say no more of the type 2
   protocol than that it must support some global naming space for the
   application specific items.  The same holds for the type 3
   communication used to access the repository.

                         +------------------+
                         |                  |
   request  <-----1----->|Generic AAA Server|<---1---> AAA server
                         |Rule based engine |
                         |                  |\
                         +------------------+ 3 +------------+
                                  ^            \| Policy and |
                                  |             | event      |
                                  2             | repository |
                                  |             +------------+