Architectural Components of a Generic AAA Server are :(1)Authorization Rule Evaluation;(2) Application Specific Module (ASM); (3)Authorization Event Log; 4) Policy Repository; (5) Request Forwarding.

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:

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

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

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

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) 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.

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.

It is hoped that by using this generic model it will be feasible to design a AAA protocol that is "future proof". 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.

Then we explore 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.

In addition, it may be necessary to encrypt or sign an entire AAA message on a hop-by-hop basis. This could be handled by a standard, lower layer protocol such as IPSEC. If so, then certain auditing requirements will have to be met so that it can be established later that the messages relative to some specific session ID were, in fact, protected in a particular way. Alternatively, hop-by-hop security mechanisms may be built into the base AAA protocol itself.