INTERNET DRAFT C. de Laat draft-irtf-aaaarch-generic-struct-00.txt Utrecht University D. Spence Interlink Networks, Inc. February 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 This memo zooms in on the structure of the rule based engine as introduced in RFC 2903, "Generic AAA Architecture". The purpose of de Laat expires August 2001 [Page 1]
INTERNET DRAFT Structure of a Generic AAA Server February 2001 this memo is to describe those parts of the internal structure of that module which are necessary to unambiguously define and understand what parts of the generic AAA process are taking place where. Here we describe the substructures in a Generic Server and the relationships between those substructures and the outside world. 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 ............................ 7 4. Environmental Discussion .................................... 7 5. Server Capabilities ......................................... 7 6. Generic AAA Roles ........................................... 7 7. Security Considerations ..................................... 7 References ..................................................... 7 Authors' Addresses ............................................. 8 1. Introduction [to be supplied] 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 August 2001 [Page 2]
INTERNET DRAFT Structure of a Generic AAA Server February 2001 /\ /\ /\ || 1 || || -----------------++-----------++---------++-------------- | Generic Server || || || | | \/ \/ \/ | | ----- ---------- ------ ------ | | | | | AAA | |Authen| |Authen| | | | Sec |---| Protocol | | Prot | | Prot | | | | | | Driver | | 1 | | 2 | | | ----- ---------- ------ ------ | | | | | | ___ | ------------------------------------- ---- | / \ | | | |Sess| | |\___/| | | Control Module |---| Mgr|--+--|Sess | | | | ---- | | DB | | | --------- -------- | | \___/ | | | State | | Rule | | | ___ | | | Machine | | Based | | | / \ | | | | | Engine | | | |\___/| | | --------- -------- |-----------+--|Trans| | ------------------------------------- | | DB | | | | | | \___/ | | ------ ------ | | | |Local | |Event | | | | |Policy| |Handlr| | | | |Retrvr| | | | | | ------ ------ | | | | | | | --------------- ------ ------ | | | ASM API | | Prot | | Prot | | | | | |Driver| |Driver| | | --------------- ------ ------ | | | | | | | -----------+-------+----------+----------+--------------- | 2 | 2 | 3 | 3 --------------- ___ ___ | : | / \ / \ | ASM : ASM | |\___/| |\___/| | : | | Pol | |Event| --------------- |Repos| | Log | | 5 | 5 \___/ \___/ --------------- |Service: Acctng| | Equip :Service| --------------- Fig. 1 -- Generic AAA Server Functional Block Diagram de Laat expires August 2001 [Page 3]
INTERNET DRAFT Structure of a Generic AAA Server February 2001 The communication between the generic AAA server and other entities is labeled according to the types of communication identified in [2]. 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 even the generic AAA protocol 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) is between a legacy AAA client and a protocol gateway. The gateway may either be embedded in the generic AAA server or be an independent 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. Authentication protocols were not assigned a communication type in [2] and so are not labeled in figure 1. Communication types 2, 3, and 5 are usually intradomain (with the possible exception of communication type 3), while communication type 1 (the generic AAA protocol) and the authentication protocols may be either intradomain or interdomain. Accordingly, in figure 1, single lines represent intradomain communication and double lines represent communication that may either be intradomain or interdomain. The heart of the generic AAA server itself is the control module. The control module processes AAA transactions. Transactions originate on receipt of a communications type 1 message from another AAA server or a communications type 2 message from an ASM. Communication type 1 messages are processed at the protocol level by a generic AAA protocol driver. Communications type 2 messages are processed by the module labeled ASM API. When the control module receives a type 1 or 2 message that originates a new transaction, it processes the message according to the rules in a "driver policy" [3]. In the course of processing, the control module may send messages to other AAA entities via communication types 1, 2, 3, or an authentication protocol. Many of these messages will require a reply, so the state of the transaction de Laat expires August 2001 [Page 4]
INTERNET DRAFT Structure of a Generic AAA Server February 2001 needs to be maintained in a transaction record stored in the transaction database. Later, when a reply is received, it will be matched up with a transaction record and processed with the aid of the state machine and the driver policy. Transaction records live until the transaction is complete -- usually a period of a few milliseconds to a few seconds. The service being authorized and accounted for may be offered over a period of time, possibly many hours. During this time many AAA transactions may be processed to establish, manage, account for, and terminate the service. Services that are offered over time are called sessions. Information relative to the state of a session is maintained in a session record which is stored in a session database. Sessions are managed by a session manager. Information included in a session record includes session state, a list of the AAA entities involved in the session, and a list of the local resources assigned to the session. When a service management message is received, it is matched to a session record and information in the session record is used by the control module, in addition to the driver policy, to determine how the message should be processed. For example if a session termination message is received, the session record is consulted to determine which AAA entities to forward the message to and which resources need to be reclaimed. The AAA server is, among other things, a policy engine. Policies to be evaluated may be received via the generic AAA protocol or retrieved from a local policy repository. If a policy is stored locally it will be retrieved by a local policy retriever. The policies are stored in a policy repository. The policy retriever uses protocol drivers to retrieve policies from the policy repository which may be a database or directory. Protocols such as LDAP and ODBC may be used to retrieve the policies. For auditing purposes, it is important for the AAA server to maintain records of AAA transactions processed. These are stored in the event log by an event handler using an appropriate protocol driver. Protocol security mechanisms are handled by a library of security functions provided by a security module. These include the following capabilities: - 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 de Laat expires August 2001 [Page 5]
INTERNET DRAFT Structure of a Generic AAA Server February 2001 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 knowledge 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 administrative 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, shown in figure 1 as a subcomponent of the control module. Eventually, modules that are service-aware will have to be involved in processing AAA transactions. Such modules are external to the generic server itself and communicate with the generic server via communications type 2. In figure 1, communications type 2 is depicted as consisting of remote procedure calls driven by the ASM API. ASMs are required to configure and provision a service into the service equipment. ASMs may translate high level service policy to the low level device-specific policy required by the service equipment. ASMs may also evaluate "service proprietary" policy -- policy that requires application-specific knowledge in order to evaluate [3]. There will be many ASMs -- one for each application. One ASM is shown in figure 1. It is shown in two halves -- a service de Laat expires August 2001 [Page 6]
INTERNET DRAFT Structure of a Generic AAA Server February 2001 provisioning half on the left, and an accounting half on the right. The two halves are separated by a dotted line. If you remove the dotted line, then there is truly a single ASM with service provisioning and accounting integrated according to the integrated accounting model [4]. If you make the dotted line solid, you get two ASMs in accord with the discrete accounting model [4]. 3. Relationships Among AAA Entities [to be supplied] 4. Environmental Discussion [to be supplied] 5. Server Capabilities [to be supplied] 6. Generic AAA Roles [to be supplied] 7. Security Considerations AAA protocols have a number of security concerns, and any AAA protocol that is designed to meet the needs of the generic AAA infrastructure will have to meet these concerns. This memo, however, does not attempt to define an AAA protocol. Rather it describes, in an abstract way, the structure of a generic AAA server. There are several projects being undertaken by the AAA Architecture Research Group that focus on the security needs of the generic AAA infrastructure. Most of these concerns are outside the scope of this memo. The role of the generic AAA protocol security module is, however, discussed in section 2. References [1] Bradner, Scott, "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. de Laat expires August 2001 [Page 7]
INTERNET DRAFT Structure of a Generic AAA Server February 2001 [2] de Laat, Cees T.A.M., George M. Gross, Leon Gommans, John R. Vollbrecht, David W. Spence, "Generic AAA Architecture", RFC 2903, August 2000. [3] Salowey, Joseph, Guus Sliepen, Arie Taal, David Spence, "Policies in AAA", draft-irtf-aaaarch-aaa-pol-01.txt, February 2001. [4] Carle, Georg, Sebastian Zander, Tanja Zseby, "Policy-based Accounting", draft-irtf-aaaarch-pol-acct-02.txt, February 2001. Authors' Addresses 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 August 2001 [Page 8]
-- _________________________________________________________________________ dr.ir. C.Th.A.M. de Laat, Faculty of Physics and Astronomy, Utrecht University, Princetonplein 5, NL-3584CC Utrecht, The Netherlands. Tel: (31)30-2534585 , mobile: 06-51566438 , Fax:(31)30-2537555 web: http://www.phys.uu.nl/~delaat , mail: c.t.a.m.delaat@phys.uu.nl
