INTERNET DRAFT A. Taal draft-taal-aaaarch-generic-pol-00.txt G. Sliepen Utrecht University D. Spence Interlink Networks, Inc. November 2000 Policies in a Generic AAA Environment 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 AAAarch Research Group. Comments are welcome and should be submitted to aaaarch@fokus.gmd.de. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Taal expires May 2001 [Page 1] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 Abstract In this document a formal model of a policy is presented in the context of a generic AAA environment. We will focus our attention on that kind of policy that is evaluated in response to a service request of a user. That policy will determine all requirements that need to be fulfilled before the service asked for will be delivered. The whole behavior of the AAA server, which receives the request, is a result of the evaluation of that policy. In order to make the behavior of the AAA server policy driven, the definition of a policy must provide recursion. This means a policy must be able to reference another policy. Furthermore, a policy must allow distribution, i.e. parts of the policy may be stored at a remote AAA server. Table of Contents Status of this Memo ............................................ 1 Copyright Notice ............................................... 1 Abstract ....................................................... 2 1. AAA environment ............................................. 3 2. Use Case Diagram ............................................ 4 2.1. The Use Case 'Satisfy request for service' ............. 5 2.2. The Use Case 'Lookup policy' ........................... 6 2.3. The Use Case 'Evaluate policy' ......................... 7 2.4. The Use Case 'Authenticate User' ....................... 7 2.5. The Use Case 'Authorize User' .......................... 7 2.6. The Use Case 'Enforce policy' .......................... 7 2.7. The Use Case 'Accounting' .............................. 8 3. Policies .................................................... 8 3.1. Introduction ........................................... 8 3.2. Formal model ........................................... 8 3.3. Local Versus Remote Literals ........................... 11 3.4. The Topology ........................................... 11 3.5. Decision Graph of a Policy ............................. 11 3.6. Distributed Policies ................................... 14 3.7. Policy Evaluation Termination .......................... 15 3.8. Inter-PDP Communication ................................ 15 3.9. User Request ........................................... 16 4. Security Considerations ..................................... 16 References ..................................................... 17 Authors' Addresses ............................................. 17 Taal expires May 2001 [Page 2] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 1. AAA environment This section introduces an abstract view of a generic AAA environment [2], and what kind of component is part of it. Only those parts of a future AAA environment necessary to develop a formal model of a policy are identified. The network of generic cooperating AAA servers can be partitioned into Administrative Domains (AD). An Administrative Domain is a collection of AAA servers under the same administrative control and grouped together for administrative purposes. Each AAA server belongs to one AD, whereas each AD might have more than one AAA server. An AAA server may receive a request from an entity operating on a user's behalf. The content of the request contains what kind of service the user wants. This request is forwarded to a so-called Policy Decision Point (PDP) where a policy resides that needs to be evaluated with respect to the service requested. A policy is a set of rules to administer, manage, and control access to network resources. A PDP can be viewed as an AAA server that manages a Policy Repository (PR) where policies reside. Each AD has at least one PDP. Whether the request will be accepted or rejected depends on the evaluation of the policy. In general an AAA server has to communicate with other AAA servers for a full acceptance or rejection of the request. This occurs when the policy to be evaluated is a distributed policy. Some parts of a policy may only be solved by a specialized application. In that case the AAA server resorts to the Application Specific Module (ASM) for that application. Taal expires May 2001 [Page 3] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 +---+ + +---+ |AAA|<========|====================================>|AAA| +---+<========+==== =========>+---+ /\ /\ | \\ // /\ /\ || || +--+-||-+--+--+--+ || || || || \/ | || | || || \/ \/ +--+ + || + || \/ +--+ +---+ |PR| | || | || +---+ |PR| |ASM| +--+ + \/ + \/ |ASM| +--+ +---+ / +---+ | +---+ +---+ + |AAA|<=========+===>|AAA| / +---+ | +---+ + /\ /\ + /\ /\ / || || | || || + || \/ + || \/ / \/ +--+ / \/ +--+ + +---+ |PR| + +---+ |PR| / |ASM| +--+ / |ASM| +--+ + +---+ + +---+ / | AD boundary Figure 1. The abstract view of a generic AAA environment 2. Use Case Diagram We are considering the role of a policy in response to a service request. To illustrate the scope of this policy in the generic AAA environment, we present a UML Use Case diagram for a future system of AAA servers, fig. 2. As this is not the right document to fully describe the Use Cases in fig. 2, only a concise description is presented. We define a single Actor, called User, as an entity that speaks the AAA protocol. This generalized user wants a request for a service to be satisfied, the Use Case 'Satisfy request for service'. The relationship between the Actor and this Use Case is a bi- directional association. It depicts the participation of the Actor in the Use Case. This association is bi-directional because the User expects an answer to his request. At the highest level we have: - Use Case: 'Satisfy request for service' - System: Network of AAA servers - Actors: User Taal expires May 2001 [Page 4] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 - Precondition: None In total we distinguish seven Use Cases: - 'Satisfy request for service' - 'Lookup policy' - 'Evaluate policy' - 'Authenticate User' - 'Authorize User' - 'Enforce policy' - 'Accounting' Between the Use Case 'Satisfy request for service' and 'Lookup policy', as well as between 'Satisfy request for service' and functionality described in 'Satisfy request for service' always includes the functionality of 'Lookup policy' and 'Evaluate policy'. Those last two Use Cases are mandatory for 'Satisfy request for service'. The extend relationships are interpreted as conditional include relationships. The Use Cases 'Authenticate User' and the Use Case 'Evaluate policy' requires it. 2.1. The Use Case 'Satisfy request for service' This Use Case will describe how an AAA server deals with an AAA service request issued by a device acting on the behalf of a real user, and what answers towards the user can be given. Every service request is forwarded to the AAA server where the process to satisfy a request actually starts, it is the Policy Decision Point associated with the request. This AAA server may manage a Policy Repository where a policy resides that needs evaluation. The AAA server evaluates the policy and formulates a response. It is of importance that the requester is well informed about the outcome of his request, especially when his request is rejected. Taal expires May 2001 [Page 5] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 +-+ +-+ +++++++++++++++++ | service request + Satisfy request + <> ----- <=============>+ for service +=========== | ===========> +++++++++++++++++ || / \ || || \/ User ||<> || <> +++++++++++++++ || \/ + Lookup policy + || +++++++++++++++++ +++++++++++++++ ++++++++++++++++ + Evaluate policy +<==== + Enforce policy + +++++++++++++++++ \\ <> ++++++++++++++++ /\ \\ policy requires || || <> \\ authorization || <> || policy requires \\ \/ || authentication +++++++++++ ++++++++++++ ++++++++++++++ + Authorize + + Accounting + + Authenticate + + User + ++++++++++++ + User + +++++++++++ ++++++++++++++ Figure 2. Use Case diagram for a service request If a request is rejected, the user is informed about the reason why. If more than one AAA server is involved in approving a request, (error) messages from AAA servers down the decision chain have to be part of the answer returned to the user. If the user is offered the option of negotiating about the rejected request, the answer will provide him information for an adjusted request. For instance, if a user asks for a 3 hour connection but the service can only deliver 2 hours, the user can be informed of the 2 hour maximum. In case a request is accepted, one of the following responses might be given. 1) The user is asked to confirm the accepted request before the requested service will be delivered. 2) The request is accepted but the user is asked to accept a condition before the service will be delivered. 3) The service requested will be provided without further negotiation with the user. In all cases, the user will be informed about the service activated. 2.2. The Use Case 'Lookup policy' The AAA server must retrieve the policy that needs to be satisfied before the service can be delivered. Which policy to retrieve must be clear from the request. Any request for a service will result in a policy lookup in the local Policy Repository (PR). Taal expires May 2001 [Page 6] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 2.3. The Use Case 'Evaluate policy' Policies can either be used in a stand-alone fashion or they can refer to other policies. It is the task of the AAA server to retrieve all policies necessary. A complex situation occurs when a service request for a PDP may contain a policy, a policy pushed by the user. If this happens it must be clear what logical relation this policy has with the stored policy, and whether this pushed policy contains conditions the user is not authorized to push. The request may contain Attribute Value Pairs (AVP), which values have to be substituted for free variables occurring in the policy. Some free variables in the policy may only be solved by a specific application. For those free variables the AAA server resorts to the Application Specific Module (ASM) for that application. The AAA server substitutes these values at the proper place into the policy. After the AAA server has substituted all it knows, it decides whether the policy is false, true or undecided yet. It is the responsibility of the AAA server to keep track of the decision process and combine the answers retrieved into an answer for the user. 2.4. The Use Case 'Authenticate User' The authentication of the user is the process of verifying the proof of his identity. Authentication of the user is only performed if the policy under evaluation requires it. When that is the case, the request must contain information about necessary policy variables with respect to authentication. Furthermore, the request may contain a certificate or password, his proof of identity. In order to be sure the user is the one he says he is, his proof of identity needs to be verified. 2.5. The Use Case 'Authorize User' Comparing the user's authenticated identity against the service requested, an AAA server performs authorization of a user's request, i.e. whether the user is allowed to obtain the requested service or resource. Like authentication, authorization is only performed if a policy requires it. Authorization requires authentication to be performed first. 2.6. The Use Case 'Enforce policy' If the policy evaluated turns out to be true, the policy will be enforced at a Policy Enforcement Point (PEP). The actions of the accepted policy refer to processes necessary to deliver the service requested. These processes have to be started and provided with the proper information. Processes consume resources that are monitored by Resource Managers. Data about resources consumed must be Taal expires May 2001 [Page 7] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 available during and after service has been delivered. 2.7. The Use Case 'Accounting' Accounting is the collection of all the data about resource consumption. Intermediate accounting or accounting indication informs the user about currently used resources. Resource Managers resort to Meters that capture data about resource consumption in the network. 3. Policies 3.1. Introduction As can be derived from the Use Case diagram in fig. 2, the behavior of an AAA server is policy driven with respect to a service request. In order to expand the Use Case 'Evaluate policy' it is important to have a model for policies. In this section we will outline such a model. 3.2. Formal model In its most abstract representation a policy can be viewed as a Boolean formula like: e[1] e[2] e[3] e[4] e[5] OR e[1] e[2] e[3] e[4] ~e[5] e[6] wherein the binary AND-operator is implicitly applied by the juxtaposition of two Boolean variables, and the unary NOT-operator is represented by a '~' before the variable. This Boolean formula is called to be written in disjunctive normal form (DNF), it is the disjunction (or) of terms. To be more specific it is in 6-DNF; we define k-DNF to be the set of Boolean formulae in disjunctive normal form where each term contains at most k literals (each variable e[i] is associated with two literals: e[i] itself and its negation ~e[i]).Another way a policy can appear is in conjunctive normal form, it is the conjunction of clauses, like: ( e[1] OR e[2] OR e[3] ) ( e[4] OR e[5] ) ( ~e[5] OR e[6] ) We define k-CNF to be the set of Boolean formulae in conjunctive normal form where each clause contains at most k literals. The formula shown is in 3-CNF. Both representations of a Boolean formula, DNF and CNF, are equally valid. Without loss of generality we will adhere to the DNF representation of a policy, during the following discussion. Taal expires May 2001 [Page 8] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 So far the definition of a policy does not imply the meaning of recursion and distribution. By recursion we mean that a literal may be a reference to a policy, this would allow the notion of policy groups [3]. Furthermore policies can be distributed, this means a literal may also be a reference to a policy stored at a remote policy repository. A policy may also contain expressions like "cost <= max_cost", these are called predicates and contain free variables, like cost and 'max_cost'. To accommodate these features the following definition of a (service) policy is proposed: policy = condition ==> action condition = term [ OR condition ] term = literal [ AND term ] literal = local_policy_reference | remote_policy_reference | computed_expression computed_expression = predicate ==> action predicate = (free_variable operator free_variable) | (free_variable operator constant) free_variable = (name, variable_type) A policy is viewed as 'IF condition THEN action'. The condition is a Boolean expression in k-DNF. An action is the definition of what is to be done when it is decided to be true, i.e. to enforce it. A literal can be a reference to a locally stored policy, PDP, 'remote_policy_reference', or a computed expression, predicate THEN action'. A free variable is a 2-tuple ('name', retrieved. For example: variable_type = AVP | ASM | LDAP | SQL | SNMP The value AVP gives a policy evaluator the information that a value for the free variable is an AVP in the request, and the name component provides the information which AVP is needed. In case an SQL-query on a local database. A remote policy reference might be interpreted as an Remote Procedure Call(RPC). Suppose the following function Max is a RPC with arguments i,j and return value r Taal expires May 2001 [Page 9] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 Max( int i, int j ) int r pre: true post: ( r = i OR r = j ) AND i <= r AND j <= r The first line defines the name of the RPC along with the arguments needed and the return value. The second line is the pre-condition, it expresses the requirements the caller has to meet, in this case nothing is required. The last line is the post-condition, it expresses what the caller can expect if the pre-condition is met. In analogy to an RPC a remote policy reference should contain the following: 1 Which PDP has access to the policy referenced 2 The arguments needed 3 Information about the response Let's consider a policy p, p: condition ==> action, with condition having a single term of three literals, say e[1]e[2]e[3]. Let e[1] be a computed expression, e[2] and e[3] references to a policy. Suppose that e[2] and e[3] do have literals referring to a policy, but are a computed expression. Then the policy p looks logically like: (((predicate[1]==>action[1])(condition[2]==>action[2]) (condition[3]==>action[3]))==>action) which expands to (((predicate[1]==>action[1])((predicate[21]==>action[21])=>action[2]) ((predicate[31]==>action[31])==>action[3]))==>action) The logical expression 'a==>b' should NOT be interpreted as a conditional statement with the following truth table from the field of proposition calculus: a | b | a==>b ------------------- T | T | T T | F | F F | T | T F | F | T with T = True, F = False. If a = F and b = T, i.e. the condition is false and the action can be Taal expires May 2001 [Page 10] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 enforced, 'a==>b' should NOT be true, but false. And if a = F and b = F, 'a==>b' should also be false. If a literal refers to a remote policy, the response should contain the action if the remote policy is decided to be true. The actions of remote policies should not be enforced. It is the responsibility of a policy administrator to store policies that in expanded form do not contain conflicting actions. Neither should a policy in extended form be tautology or a contradiction. A policy is a tautology if its true for any truth value of its components, and a policy is a contradiction if it is false for any truth value of its components. 3.3. Local Versus Remote Literals A local literal can be decided locally, that means no request for another AAA server is needed. 3.4. The Topology We are not interested in the underlying network connecting the AAA servers, but are only interested in the communication between AAA servers. In the simplest view of the network any AAA server may send a request to any other AAA server. This would mean that the topology of AAA servers as a fully connected graph G=(V, E). In practice the topology G of AAA servers will not be a fully connected graph, since there are specialized AAA servers only known to a limited number of other servers. A vertex will be assigned to each couple of an AAA server and its PR. An edge between two vertices u,v in V, represents the possibility that the AAA server at u and v can communicate with each other directly. How the information travels over the Internet is not of our concern. When an AAA server has to deal with a distributed policy, it has to communicate with other servers, which in their turn may have to communicate again. Any policy results in a graph G'=(V', E'), the decision graph of the policy, with E' consisting of all AAA servers necessary for the decision of the policy. This graph G' will be a sub-graph of the directed version of G , with V'<=V. A directed edge (v[i], v[j]), v[i] ,v[j] in V', means that in the decision process of the policy the AAA server at v[i] sends a question to the server at vertex v[j]. 3.5. Decision Graph of a Policy As stated above to each distributed policy a decision graph is associated. This graph is a result from the PRs that play a role in the decision of the policy. In fig. 3 such a decision graph is depicted for a distributed policy at vertex A with remote literals Taal expires May 2001 [Page 11] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 e[j], e[j+1], ...,e[j+5]. Of those literals e[j] and e[j+1] are decidable at vertex B, e[j+2] at C, e[j+3] at D and e[j+4] and e[j+5] at vertex E. This graph is a result of the fact that in the PR of vertex A the entries of e[j] and e[j+1] yield the address of B, entries of e[j+2] e[j+3] and e[j+4] that of C, and the entry of e[j+5] that of E. At C both e[j+3] and e[j+4] are forwarded to D and E, respectively.Some remarks can be made about the decision graph of fig. 3. The first and most important notice is that this graph belongs to a distributed policy that is decidable, and that the graph is a directed acyclic graph (DAG). Therefore, vertex A is the only vertex with a zero in-degree, it has only outgoing edges, we will call this the root of the decision graph. Furthermore, the decision graph has the following properties. The remote literals at A are partitioned over the requests r along the outgoing edges of A. At a vertex with a zero out-degree ( vertex B, D, or E ) the literals of the requests along the incoming edges are decidable at that vertex. At those vertices with a non-zero in-degree and out-degree ( vertex C ), the literals of the requests along the incoming edges are partitioned over the vertex itself and the requests along the outgoing edges or are partitioned over the requests along the outgoing edges exclusively. Taal expires May 2001 [Page 12] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 {e[j+4],e[j+5]} +-+ r(e[j+5]) +-+ |A|==================================>|E| +-+ +-+ // \\ /\ r(e[j],e[j+1]) // \\ // // \\ r(e[j+2],e[j+3],e[j+4]) // // \\ // || \\ // r(e[j+4]) \/ \\ // +-+ || // |B| || // +-+ \/ // {e[j],e[j+1]} +-+ // |C|==================// {e[j+2]} +-+ \\ \\ r(e[j+3]) \\ || \/ +-+ |D| {e[j+3]} +-+ Figure 3 A decision graph of a distributed, decidable policy Now we will give a definition of a decision graph for a distributed policy. Here we apply the following restriction: A remote literal is not allowed to spawn a new policy. This restriction is only made to keep the discussion in this document simple. Def. Suppose the network of AAA servers forms a graph G=(V, E). Let s in V to be the vertex representing a PDP where a policy P resides. Furthermore, let P contain a nonempty set R of remote literals. Then the decision graph of the distributed policy P is a subgraph G' of the directed version of G, G'=(V', E'), V' <= V, such that the following properties hold. V' has at least two vertices, with s in V' and s has at least one outgoing edge. The requests along the outgoing edges of s are a partition of the set R of remote literals. Each other vertex of the graph has at least one incoming edge, and the literals of the requests along the incoming edges have each a nonempty entry at the PR. The requests along the outgoing edges are a partitioning of a nonempty subset of the literals of the requests along the incoming edges. Taal expires May 2001 [Page 13] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 This definition allows a decision graph for an undecidable policy. If in fig. 3 vertex D forwards r(ej+3) to A again, the decision never stops. A distributed policy at a vertex A is decidable if its decision graph is a directed acyclic graph. We assume that the answers to the remote literals follow the opposite route, i.e. in the decision graph the directed edges change direction. Thus, the answer to r(e[j+4]) , a(e[j+4]), travels form E via C back to A. +-+ a(e[j+5]) +-+ |A|<==================================|E| +-+ +-+ /\ /\ // a(e[j],e[j+1]) || || // // \\ a(e[j+2],e[j+3],e[j+4]) // // \\ // // \\ // a(e[j+4]) || \\ // +-+ \\ // |B| || // +-+ || // +-+ // |C|<==================// +-+ /\ || a(e[j+3]) \\ || || +-+ |D| +-+ Figure 4. The aggregation of the answers for the situation in fig. 3 3.6. Distributed Policies A distributed policy has a decision graph with at least two vertices. Thus a distributed policy is the set of all policies involved in the evaluation of a request. Taal expires May 2001 [Page 14] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 3.7. Policy Evaluation Termination If a literal may spawn a new policy two situations can be distinguished when the original policy gives rise to a chain of spawned policies. Firstly, more than one of the spawned policies reside at the same PR. Secondly, more than one of the spawned policies reside at different PDPs. In principal the evaluation of a policy may lead to an avalanche of policies and evaluation may go on forever. To guarantee termination of the second kind, the introduction of a maximal PDP count may be appropriate. In order to limit the number of policies spawned at the same PDP the AAA server may keep track of this number and set a limit. Still this does not guarantee that policy evaluation terminates within a certain time span. A limit on the evaluation time suffices. The question is who is responsible for that limit. If the policy turns out to be a distributed policy the AAA server at the root of the decision tree inserts the time (sec) into any outgoing request that may be spent on the evaluation. As soon as an AAA server down the decision chain discovers that the local evaluation exceeds the time in the receiving request it ignores the request. There is no need to inform the AAA server up the decision chain about this ignorance. The AAA server at the root of the decision tree just informs the User about the failure of his request when an answer to an outstanding request failed to come in during the time span set. 3.8. Inter-PDP Communication Evaluation of a distributed policy involves the communication among different PDPs. As long as the PDPs belong to the same Administrative Domain, the PDPs may consider each other as a Trusted Node. We assume that all AAA servers (PDPs) within the same Administrative Domain see each other as a Trusted Node. When hop-by-hop authentication is performed and it turns out that the requesting node is a Trusted Node, there are no restrictions on the contents of the request. The situation may differ when the communication between PDPs transverse the boundary of an Administrative Domain. In that case restrictions on the content of a request may be applied, that e.g. are specified in a Service Level Agreement (SLA). Taal expires May 2001 [Page 15] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 {e[j+4],e[j+5]} +-+ r(e[j+5]) + - |A|=======================/==========>||E|| +-+ + - // \\ / /\ r(e[j],e[j+1]) // \\ + // // \\ r(e[j+2],e[j+3],e[j+4]) // // \\ + // || \\ / // r(e[j+4]) \/ \\ + // +-+ || / // |B| || + // +-+ \/ / // {e[j],e[j+1]} +-+ + // |C|===/==========// {e[j+2]} +-+ + \\/ +-\\ r(e[j+3]) / \\ +-+-+-+-+ || AD boundary / \/ + - / ||D|| {e[j+3]} + - Figure 5. Decision graph: nodes in different Administrative Domains 3.9. User Request Any service request issued by a User speaking the AAA protocol contains at least the following items: 1 Policy reference 2 [time limit on policy evaluation] 3 [AVPs for free variables] e.g. userid [,passw] [,certificate] in case an authentication policy is involved 4 [policy] 4. Security Considerations This memo identifies a basic set of AAA functions that are general in nature and common to many different AAA applications. We propose Taal expires May 2001 [Page 16] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 that a standard set of security mechanisms should be defined as part of a base AAA protocol which would include such things as public key encryption and digital signatures that could be applied to individual information units within an AAA message. References [1] Bradner, Scott, "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [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] Distributed Management Task Force, "CIM Core Policy Model", http://www.dmtf.org/spec/Whitepapers/CIM_Policy24_wp.htm. Authors' Addresses Arie Taal Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands Phone: +31 30 2537556 Phone: +31 30 2537555 EMail: taal@phys.uu.nl Guus Sliepen Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands Phone: +31 30 2537724 Phone: +31 30 2537555 EMail: g.sliepen@phys.uu.nl Taal expires May 2001 [Page 17] INTERNET DRAFT Policies in a Generic AAA Environment November 2000 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 Taal expires May 2001 [Page 18]