discussion points and questions:
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]
| CdL - feb 2h 2001 | Visitors of this page: |
|