INTERNET DRAFT                                                C. de Laat
draft-irtf-aaaarch-generic-struct-00.txt              Utrecht University
                                                               D. Spence
                                                Interlink Networks, Inc.
                                                            January 2001



                   Structure of a Generic AAA Server


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This memo describes work in progress within the AAA Architecture
   Research Group.  Comments are welcome and should be submitted to
   AAAarch Research Group <aaaarch@fokus.gmd.de>.

   Distribution of this memo is unlimited.


Copyright Notice

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


Abstract

   <<abstract>>




de Laat                    expires July 2001                    [Page 1]

INTERNET DRAFT     Structure of a Generic AAA Server        January 2001


Table of Contents

<<Insert table of contents here.>>


1.  Introduction

   <<Introduction>>


2.  Functional Model

   Figure 1 shows a block diagram of a Generic AAA Server and its
   relationships to other entities such as Application Specific Modules
   (ASMs), policy repositories, and event logs.




































de Laat                    expires July 2001                    [Page 2]

INTERNET DRAFT     Structure of a Generic AAA Server        January 2001




      <<
      Note: The following diagram needs to be updated, but here is a
      placeholder.
   >>
           +-------------------------------------all-sessions-+
           |+---------------------------one-session-+         |
           || +---+     +-------------+  +-+  +---+ |         |
      1    || |PD |-    |RBE / Control|  |R| -|PD | |         |    1
    =========>|aaa|-----|Module / Req.|--|B|--|aaa|===================>
           || |   |-    |Manager      |  | | -|   | |         |
           || +---+     +-------------+  +-+  +---+ |         |
           ||   |         |  |  |  |            |   |         |
           ||   |        /   |  |   \           |   |         |
           || +---+     /    |  |    \        +---+ |         |
           || |SEC|    |     |   \    \       |SEC| |         |
           || |   |  +---+   |   +--+  \      |   | |  +----+ |
           || +---+  |API|    \  |PD|   \     +---+ |  |Sess| |
           ||        |asm|     \ +--+    \          |  |Man.| |
           ||        +---+     +--+  \    -------------|    | |
           ||         /|\      |PD|   \             |  |    | |
           ||        / | \     +--+    -----        |  +----+ |
           ||       /  |  \        \        \       |         |
           |+------/---|---\--------\--------\------+         |
           |      /    |    \        \        \               |
           +-----/-----|-----\--------\--------\--------------+
                |2     |2     |2       |3       |3
                |      |      |        |        |
              +---+  +---+  +---+   +-----+  +-----+
              |ASM|  |ASM|  |ASM|   |DB   |  |DB   |
              |   |  |   |  |   |   |event|  |pol. |----(Driving Policy)
              +---+  +---+  +---+   |log  |  |repos|
               /|\    /|\5   /|\    +-----+  +-----+
               ...    ...    ...

           Fig. 1 -- Generic AAA Server Functional Block Diagram


   The communication between the generic AAA server and other entities
   is labeled according to the types of communication identified in [A].

   1. Type 1 communication is between AAA servers.  It uses the generic
      AAA protocol (assumed to be standardized).

   2. Type 2 communication is between an AAA server and an ASM.  It is
      not standardized.  It may be an Application Programming Interface
      (API) or it may be a protocol, possibly the generic AAA protocol



de Laat                    expires July 2001                    [Page 3]

INTERNET DRAFT     Structure of a Generic AAA Server        January 2001


   used for type 1 communication.  It is illustrated in figure 1 using
      an API.

   3. Type 3 communication is between an AAA server and a database or
      repository.  It uses available protocols such as LDAP or ODBC.

   4. Type 4 communication (not shown in figure 1) <<could be shown in
      figure 1>> is between a legacy AAA client and a protocol gateway.
      The gateway may either be embedded in the generic AAA server or be
      an independed entity that translates between the type 4 and type 1
      protocols.

   5. Type 5 communication is between an ASM and the service equipment
      to which it is connected.  It typically uses an application
      specific protocol that the service equipment understands.

   The AAA server needs not only to provision and manage the service
   equipment, but needs to communicate with authentication and
   accounting entities as well.  In figure 1, this communication is
   depicted using the ASM interface.  Here, the ASM is not understood as
   being user application specific but specific to the authentication or
   accounting mechanism being used.  For example, there may be one ASM
   to manage Kerberos authentication and another to manage one-time-
   password authentication.

   Alternatively, the authentication ASMs could be brought inside the
   AAA server as Protocol Drivers that would communicate directly with
   authentication servers using authentication protocols as needed.

   The AAA server is seen as a policy engine and so it will need to be
   able to retrieve policies from a policy repository.

   For auditing purposes, it is important for the AAA server to maintain
   records of AAA transactions processed.  These are stored in the event
   log.

   The heart of the generic AAA server itself is the control module. The
   control module processes AAA transactions communicated via
   communication types 1 through 3 <<or 4?>>.  The state of ongoing
   transactions is stored in a transaction data base.

   Incoming and outgoing type 1 protocol messages are handled by a
   protocol driver.  (Ingoing and outgoint protocol drivers are depicted
   separately in figure 1, but in practice may be combined into a single
   software module.)

   Protocol security mechanisms are handled by a library of security
   functions.  These include the following capabilites:



de Laat                    expires July 2001                    [Page 4]

INTERNET DRAFT     Structure of a Generic AAA Server        January 2001


   - Authentication of peer AAA servers,

   - Hop-by-hop integrity protection for data elements exchanged
     directly between AAA peers,

   - Hop-by-hop confidentiality protection for data elements exchanged
     directly between AAA peers,

   - Integrity protection for data elements exchanged between
     nonadjacent AAA servers, and

   - Confidentiality protection for data elements exchanged between
     nonadjacent AAA servers.

   When processing AAA transactions, the generic AAA server has no
   knowlege of the specific service the user is wanting to receive.
   Therefore it will have no hard-coded knowledge of how to process AAA
   transactions.  For instance, if a request for service is received
   from a user, what AAA servers in what adminastrative domains must be
   consulted for authorization?  Where do policies reside which must be
   applied to this request?  How are they indexed?  When accounting
   messages are received for a session, where do they need to be
   forwarded?

   The answers to these questions are encoded in a set of driver
   policies that may be accessed by the server from the policy
   repository. In general, there will be one driver policy per service
   per each message type that can be received over any of the
   communication interfaces.  It is for further study whether the driver
   policy to be executed for type 1 communication messages is selected
   by using the message type and service identifier as key or whether
   the type 1 protocol should carry a remote policy reference to
   identify the appropriate driver policy to use.

   Driver policies and other policies that need to be evaluated by
   generic AAA servers are evaluated by the Rule Based Engine (RBE),
   shown in figure 1 as a subcomponent of the control module.


3.  Relationships Among AAA Entities
   <<

      ASM--AAA (2)
      AAA--AAA (1)
      AAA--Rep (3)
      Rep--PEP?

      Have I already covered this?



de Laat                    expires July 2001                    [Page 5]

INTERNET DRAFT     Structure of a Generic AAA Server        January 2001


   >>


4.  Environmental Discussion
   <<

      Separation of generic from application specific
      Syntax vs. semantics

   >>


5.  Server Capabilities
   <<section text>>


6.  Generic AAA Roles
   <<

      Client Role
      Server Role
      Broker Role

   >>


7.  Security Considerations

   <<security considerations>>


References

   [1]  Bradner, Scott, "The Internet Standards Process -- Revision 3",
        RFC 2026, BCP 9, October 1996.

   [A]  de Laat, Cees T.A.M., George M. Gross, Leon Gommans, John R.
        Vollbrecht, David W. Spence, "Generic AAA Architecture", RFC
        2903, August 2000.


Authors' Addresses









de Laat                    expires July 2001                    [Page 6]

INTERNET DRAFT     Structure of a Generic AAA Server        January 2001



      Cees T.A.M. de Laat
   Physics and Astronomy dept.
   Utrecht University
   Pincetonplein 5,
   3584CC Utrecht
   Netherlands

      Phone: +31 30 2534585
      Phone: +31 30 2537555
      EMail: delaat@phys.uu.nl


      David Spence
   Interlink Networks, Inc.
   775 Technology Drive, Suite 200
   Ann Arbor, MI  48108
   USA

      Phone: +1 734 821 1203
        Fax: +1 734 821 1235
      EMail: dspence@interlinknetworks.com





























de Laat                    expires July 2001                    [Page 7]

                           Table of Contents




   Status of this Memo ............................................    1

   Copyright Notice ...............................................    1

   Abstract .......................................................    1

   1. Introduction ................................................    2

   2. Functional Model ............................................    2

   3. Relationships Among AAA Entities ............................    5

   4. Environmental Discussion ....................................    6

   5. Server Capabilities .........................................    6

   6. Generic AAA Roles ...........................................    6

   7. Security Considerations .....................................    6

   References .....................................................    6

   Authors' Addresses .............................................    6




















de Laat                    expires July 2001                    [Page 1]