AAAARCH Research Group A. Taal INTERNET DRAFT G. Sliepen draft-taal-aaaarch-generic-pol-01.txt A. Hemel D. Spence March 2001 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 RFC 2026. 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. 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 request of a user [OBJMSG]. That policy will determine all requirements that need to be fulfilled before the service asked for will be delivered. We will introduce the concept of a Driving Policy. The Driving Policy A. Taal et al. Expires: September 2001 [Page 1]
Internet Draft Policies in a Generic AAA Environment March 2001 determines what kind of functionality the AAA server provides. The whole behavior of the AAA server, which receives the request, is a result of the evaluation of this Driving Policy [AAAPOL]. 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. 1. AAA environment This section introduces an abstract view of a generic AAA environment [RFC2903], and what kind of component is part of it. Only those parts of a future AAA environment are presented that are necessary to illustrate the discussion in this draft. 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 evaluated by the Rule Based Engine (RBE) of the AAA Server where a Driving Policy resides that needs to be evaluated with respect to the request. A policy is a set of rules to administer, manage, and control access to network resources. An AAA Server manages a Policy Repository (PR) where policies reside. Whether the request will be accepted or rejected depends on the evaluation of the Driving Policy. In general a 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 an Application Specific Module (ASM) for that application. +---+ +---+ |AAA|<=============================================>|AAA| +---+<============= =========>+---+ /\ /\ \\ // /\ /\ || || || || || || || \/ || || || \/ \/ +--+ || || \/ +--+ +---+ |PR| || || +---+ |PR| |ASM| +--+ \/ \/ |ASM| +--+ +---+ +---+ +---+ +---+ |AAA|<=============>|AAA| +---+ +---+ /\ /\ /\ /\ || || || || || \/ || \/ \/ +--+ \/ +--+ +---+ |PR| +---+ |PR| |ASM| +--+ |ASM| +--+ A. Taal et al. Expires: September 2001 [Page 2]
Internet Draft Policies in a Generic AAA Environment March 2001 +---+ +---+ Figure 1. The abstract view of a generic AAA environment A more detailed view of the AAA server itself reveals the Driving Policy. The Driving Policy specifies the behavior of the AAA server. For example, the Driving Policy in a shop AAA server would define the shop functions. The Driving Policies in the PR and the ASMs have a dependency relation, because the policies can refer to an ASM to solve a part of the policy. This means that the content of the PR and the ASMs determine the behavior of the AAA server. A (partial) replacement of the content of the PR and the ASMs will result in a different AAA server. This feature should be dynamically supported to give an administrator the possibility to adjust the behavior of an AAA server without the necessity to recompile the AAA server code /\ /\ /\ || 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| | | --------------- ------ ------ | A. Taal et al. Expires: September 2001 [Page 3]
Internet Draft Policies in a Generic AAA Environment March 2001 | | | | | | -----------+-------+----------+----------+--------------- | 2 | 2 | 3 | 3 --------------- ___ ___ | : | / \ / \ | ASM : ASM | |\___/| |\___/| | : | | Pol | |Event| --------------- |Repos| | Log | | 5 | 5 \___/ \___/ --------------- |Service: Acctng| | Equip :Service| --------------- Figure 2. Generic AAA Server Functional Block Diagram [AAAGEN] 2. Use Case Diagram We will consider the role of a Driving Policy in response to a so called 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. 3. As this is not the right document to fully describe the Use Cases in fig. 3, 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 to be satisfied, the Use Case 'Satisfy request'. 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' - System: Network of AAA servers - Actors: User - Precondition: None In total we distinguish seven Use Cases: - 'Satisfy request' - 'Lookup Driving Policy' - 'Evaluate Driving Policy' - 'Authenticate User' - 'Authorize User' - 'Enforce policy' - 'Accounting' A. Taal et al. Expires: September 2001 [Page 4]
Internet Draft Policies in a Generic AAA Environment March 2001 Between the Use Case 'Satisfy request' and 'Lookup Driving Policy', as well as between 'Satisfy request' and 'Evaluate Driving Policy', there exists an include relationship. The functionality described in 'Satisfy request' always includes the functionality of 'Lookup Driving Policy' and 'Evaluate Driving Policy'. Those last two Use Cases are mandatory for 'Satisfy request'. The extend relationships are interpreted as conditional include relationships. The Use Cases 'Authenticate User' and 'Authorize User' are only performed if some internal condition in the Use Case 'Evaluate Driving Policy' requires it. 2.1. The Use Case 'Satisfy request' This Use Case will describe how an AAA server deals with an AAA request issued by a device acting on the behalf of a real user, and what answers towards the user can be given. Every request is forwarded to the AAA server where the process to satisfy a request actually starts. This AAA server may manage a Policy Repository where the Driving 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. +-+ +-+ +++++++++++++++++ | request + Satisfy request + <<include>> ----- <=============>+ +========== | ===========> +++++++++++++++++ || / \ || || \/ User ||<<extend>> || <<include>> +++++++++++++++++++++ || \/ +Lookup Driving Policy+ || +++++++++++++++++++++++ +++++++++++++++++++++ ++++++++++++++++ +Evaluate Driving Policy+<== +Enforce policy + +++++++++++++++++++++++ \\ <<extend>> ++++++++++++++++ /\ \\ policy requires || || <<extend>> \\ authorization || <<include>> || policy requires \\ \/ || authentication +++++++++++ ++++++++++++ ++++++++++++++ + Authorize + +Accounting + + Authenticate + + User + ++++++++++++ + User + +++++++++++ ++++++++++++++ Figure 3. Use Case diagram for a request 2.2. The Use Case 'Lookup Driving Policy' The AAA Server must retrieve the Driving Policy that needs to be A. Taal et al. Expires: September 2001 [Page 5]
Internet Draft Policies in a Generic AAA Environment March 2001 evaluated before the request can be satisfied. Which policy to retrieve must be clear from the request. Any request will result in a lookup for the Driving Policy in the local Policy Repository (PR). 2.3. The Use Case 'Evaluate Driving 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 evaluate all policies necessary. A complex situation occurs when a request contains a policy that is pushed by the user. If this happens it must be clear what logical relation this policy has with the stored Driving 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 Driving 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(s). Like authentication, authorization is only performed if a Driving Policy requires it. Authorization requires authentication to be performed first. 2.6. The Use Case 'Enforce policy' If the Driving Policy evaluated turns out to be true, the policy will be enforced. The actions of the accepted policy refer to processes A. Taal et al. Expires: September 2001 [Page 6]
Internet Draft Policies in a Generic AAA Environment March 2001 necessary to deliver the service requested. These processes have to be started and provided with the proper information. Figure 3 only hold if actions are postponed until the policy turns out to be true. 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. 3, the behavior of an AAA server is policy driven with respect to a request. In order to expand the Use Case 'Evaluate Driving Policy' it is important to have a model for policies. In this section we will outline such a model. It will have components we think are necessary for any future model. 3.2. Formal model There can be many definitions of a policy grammar. The grammar we propose here is not presented as the official AAA policy grammar. However, we present it here to pinpoint some elements, which will most likely be part of an official AAA policy grammar. We also present it here to facilitate the discussion about AAA policy grammars. The following abbreviated nonterminals, UBOp, BBOp COp, AOp, UnOp, should be respectively read as: Unary Boolean, Binary Boolean, Conditional, Arithmetic, Unary operator. Policy ::= Condition ActionList ActionList Condition ::= [UBOp] Literal | Condition BBOp Condition Literal ::= Policy | ComputedBoolean | RemotePolicy | LocalPolicy ActionList ::= (Action)* Action ::= Actor Task (Param)* A. Taal et al. Expires: September 2001 [Page 7]
Internet Draft Policies in a Generic AAA Environment March 2001 Actor ::= ASM | PEP | ... ComputedBoolean ::= ComputedExpr COp ComputedExpr ComputedExpr ::= ComputedExpr AOp ComputedExpr | UnOp ComputedExpr | Const | Var Var ::= Type Name Source Type ::= CHAR | INT | FLOAT | ... Source ::= AVP | SQL | ASM | LDAP | SNMP | ... RemotePolicy ::= Address Key (Param)* LocalPolicy ::= Key (Param)* UBOp ::= NOT BBOp ::= AND | OR COp ::= LESSTHAN | GREATERTHAN | ... AOp ::= + | - | / | % | ... UnOp ::= ~ // this means negation For Boolean formulas we assume the normal precedence rule (AND binds stronger than OR). A Policy can be viewed as `IF Condition THEN DO ActionList ELSE DO ActionList', where the ActionLists are different. A Condition yields some Boolean value, or at least something that can be evaluated. The definition of Condition allows recursion and gives us the possibility to nest a Policy. An ActionList can consist of zero or more Actions. An Action consists of an Actor (who will execute the action), a Task (a name) and a set of zero or more parameters. Some elements need some extra clarification. Source ::= 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 the Source equals SQL, the policy evaluator issues an SQL-query on a local database. In case the Source is AVP, all information necessary is present. However, the Source attribute alone is not sufficient to issue a SQL query. Take for example this "authentication policy": IF password-AVP = password-in-database THEN ... In order to solve this condition the RBE or an ASM needs to issue a SQL query on the database, like: A. Taal et al. Expires: September 2001 [Page 8]
Internet Draft Policies in a Generic AAA Environment March 2001 SELECT Password FROM Users WHERE UserID='?' wherein ? is a placeholder for the userid-AVP. As this example shows some alternatives of `Source', like SQL, LDAP, need additional information. A remote policy reference, RemotePolicy, might be interpreted as a Remote Procedure Call (RPC). To invoke a RemotePolicy we will need at least the Address (which can take various forms, we haven't decided on one), a unique Key and an optional set of parameters. 3.3. Reducing Policy Ambiguity We are aware that our grammar is ambiguous. The nesting of policies means that we cannot guarantee that evaluation of a policy always will return the same result, i.e. parsing from left to right might have another result compared to a parsing into the opposite direction. Let's for example consider an ActionList in a certain policy. ActionList = (A, B) Suppose that the results of A and B are each other's opposite. Or suppose that A can only be executed successfully if B has been executed. We will present some mechanisms that can possibly control the ambiguity. The first solution is fixing the evaluation order of the elements of a Condition. This would for example mean that elements within a Boolean condition must only be evaluated from left to right, or from right to left. The second solution is to introduce priorities, for example using parentheses or implicit precedence of operators. 3.4. Policy conflicts If policies have to be enforced there are a few issues that should be considered. Until now it is not clearly defined whether actions should be executed immediately or should be postponed. Especially, if the policy contains references to other policies including their actions. A. Taal et al. Expires: September 2001 [Page 9]
Internet Draft Policies in a Generic AAA Environment March 2001 Postponing all actions until evaluating a policy has finished is not a good solution, because certain elements within the policy might only evaluate to `true' if certain actions earlier in the chain have taken place. For example: Precondition: firewall is closed IF openup(firewall) AND sendPacket() THEN do beHappy() Let's assume that a packet can only be sent when the firewall is opened. and that sendPacket() returns true upon successful completion. If all actions were postponed then this policy could never be true. When actions are executed immediately, this policy could be true. A solution is that actions are marked as `execute immediately' or `postpone'. In the case of RemotePolicies the response must contain a list of postponed actions (`if everything goes OK let me do these things'). 3.5. Executing policies in parallel It is well possible that if there are more references to RemotePolicies or LocalPolicies that these will be evaluated in parallel, for example for efficiency of the server. All the problems we mentioned before are also present in this case, combined with things like waiting times (how long should you wait for a response). 3.6. Pushing Policies Pushing policies between AAA servers (note: not inside a AAA server) might pose some problems. We've identified a couple of situations where it is not desirable to push policies. The first situation is policy conflicts. Policies might contradict each other, possibly resulting in unwanted behavior. In the case of pushed policies the problem is more urgent than in the case of local policies contradicting each other (which is a fault of the local administrators). A pushed policy doesn't have knowledge about the local policies. The second situation is that there could be exchange problems. If there's not a common format to describe policies a server might not be able to understand a pushed policy. To give an example, let's say we've got a server that only understands policies in XML and we get a A. Taal et al. Expires: September 2001 [Page 10]
Internet Draft Policies in a Generic AAA Environment March 2001 policy in Java bytecode. We can't understand the policy and have to discard it. A solution for this problem is that a standard has to be defined for pushed policies. The third situation is that a pushed policy can define `unwanted actions', resulting in a (possibly major) security risk. This can result in the server wasting processing time, bandwidth and other resources, leaving it in such a state that it can't process other requests. The fourth situation is when we put a AAA server on a machine with limited computing power and/or bandwidth (for example a smartcard or some sort of hardware token). The machine could easily be swamped when policies are pushed from other machines. We advise that more time is spent on defining a ``Do's and Don'ts'' list for pushing policies. References [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Vollbrecht, "Generic AAA Architecture", RFC 2903, August 2000 [OBJMSG] D. Spence, "Data Objects and Message Types in the Generic AAA Architecture", draft-spence-aaaarch-objmsg-00.txt, Januari 2001 [AAAGEN] C. de Laat, J. Vollbrecht and D. Spence, "Structure of a Generic AAA server", draft-irtf-aaaarch-generic-struct-00.txt, Februari 2001 [AAAPOL] J. Salowey, G. Sliepen, A. Taal and D. Spence, "Policies in AAA", draft-irtf-aaaarch-aaa-pol-01.txt, February 2001 Authors' Addresses Arie Taal Physics and Astronomy department Utrecht University Pincetonplein 5 3584 CC Utrecht Netherlands Phone: +31 30 2537556 Phone: +31 30 2537555 Email: taal@phys.uu.nl Guus Sliepen A. Taal et al. Expires: September 2001 [Page 11]
Internet Draft Policies in a Generic AAA Environment March 2001 Physics and Astronomy department Utrecht University Pincetonplein 5 3584 CC Utrecht Netherlands Phone: +31 30 2537724 Phone: +31 30 2537555 Email: sliepen@phys.uu.nl Armijn Hemel Institute of Information and Computing Sciences Utrecht University Padualaan 14 3584CH Utrecht Netherlands Email: aehemel@cs.uu.nl David W. 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 A. Taal et al. Expires: September 2001 [Page 12]
--